Inverse search/sync fails when using Touying or Polylux to make slides

Describe the bug
The inverse search/sync (from preview to code) fails when using Touying or Polylux to make slides.
The forward search/sync (from code to preview) is fine.
#import "@preview/touying:0.5.3": *
#import themes.simple: *

#show: simple-theme.with(aspect-ratio: "16-9")

= Title

== First Slide

Hello, Touying!

#pause

Hello, Typst!

However, the following scenarios are OK:

Using the same Touying or Polylux code in Typst's official online editor
Writing a normal text in VSCode with tinymist

The following is the language server output:
[2024-10-27T14:04:34Z INFO  tinymist] tinymist LSP version information: [["Build Timestamp", "2024-10-19T17:12:03.217404000Z"], ["Build Git Describe", "v0.12.0"], ["Commit SHA", "4437b3bffb5f01f06bd64e4e424480ba72a88619"], ["Commit Date", "None"], ["Commit Branch", "None"], ["Cargo Target Triple", "aarch64-apple-darwin"], ["Typst Version", "0.12.0"], ["Typst Source", "git+https://github.com/Myriad-Dreamin/typst.git?tag=tinymist-v0.12.0#58426a90a7ef721738a01be09793d33e55eb75a9"]]
[2024-10-27T14:04:34Z INFO  tinymist] starting LSP server: LspArgs {
        mirror: MirrorArgs {
            mirror: "",
            replay: "",
        },
        font: CompileFontArgs {
            font_paths: [],
            ignore_system_fonts: false,
        },
    }
[2024-10-27T14:04:34Z INFO  sync_lsp] handling initialize - (0) at Instant { tv_sec: 108130, tv_nsec: 817631541 }
[2024-10-27T14:04:34Z INFO  tinymist::init] preferred theme: Some("light") {"compileStatus": String("enable"), "dragAndDrop": String("enable"), "exportPdf": String("never"), "formatterMode": String("disable"), "formatterPrintWidth": Number(120), "onEnterEvent": Bool(true), "outputPath": String(""), "preferredTheme": String("light"), "preview": Object {"cursorIndicator": Bool(false), "fontPaths": Array [], "invertColors": Null, "partialRendering": Bool(true), "pinPreviewFile": Bool(false), "refresh": String("onType"), "scrollSync": String("onSelectionChangeByMouse"), "sysInputs": Object {}, "systemFonts": Bool(true)}, "previewFeature": String("enable"), "semanticTokens": String("enable"), "showExportFileIn": Null, "systemFonts": Bool(true), "trace": Object {"server": String("off")}, "typstExtraArgs": Array []}
[2024-10-27T14:04:34Z INFO  tinymist::server] LanguageState: initialized with config Config { const_config: ConstConfig { position_encoding: Utf16, cfg_change_registration: true, notify_will_rename_files: true, tokens_dynamic_registration: true, tokens_overlapping_token_support: false, tokens_multiline_token_support: false, doc_line_folding_only: true, doc_fmt_dynamic_registration: true }, compile: CompileConfig { roots: [], output_path: PathPattern(""), export_pdf: Never, root_path: None, font_opts: CompileFontArgs { font_paths: [], ignore_system_fonts: false }, system_fonts: Some(true), font_paths: [], fonts: OnceCell(Uninit), notify_status: true, periscope_args: None, typst_extra_args: Some(CompileExtraOpts { root_dir: None, entry: None, inputs: {}, font: CompileFontArgs { font_paths: [], ignore_system_fonts: false }, creation_timestamp: None, cert: None }), preferred_theme: Some("light"), has_default_entry_path: false, lsp_inputs: {"x-preview": "{\"version\":1,\"theme\":\"light\"}"} }, semantic_tokens: Enable, formatter_mode: Disable, formatter_print_width: Some(120) }
[2024-10-27T14:04:34Z INFO  tinymist::actor] TypstActor: creating server for primary, entry: EntryState { rooted: false, root: None, main: None }, inputs: {"x-preview": "{\"version\":1,\"theme\":\"light\"}"}
[2024-10-27T14:04:34Z INFO  tinymist::init] creating SharedFontResolver with CompileFontArgs { font_paths: [], ignore_system_fonts: false }
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  initialize - (0) in 1.14ms
[2024-10-27T14:04:34Z INFO  sync_lsp] notifying initialized - at Instant { tv_sec: 108130, tv_nsec: 851104083 }
[2024-10-27T14:04:34Z INFO  tinymist::server] server initialized
[2024-10-27T14:04:34Z INFO  sync_lsp] notifing initialized succeeded in 7.21ms
[2024-10-27T14:04:34Z INFO  sync_lsp] handling workspace/executeCommand - (1) at Instant { tv_sec: 108130, tv_nsec: 858327166 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  workspace/executeCommand - (1) in 1.37ms
[2024-10-27T14:04:34Z INFO  sync_lsp] notifying textDocument/didOpen - at Instant { tv_sec: 108130, tv_nsec: 859706875 }
[2024-10-27T14:04:34Z INFO  tinymist::server] did open Url { scheme: "file", cannot_be_a_base: false, username: "", password: None, host: None, port: None, path: "/Users/xiaoweiz/Downloads/test.typ", query: None, fragment: None }
[2024-10-27T14:04:34Z INFO  tinymist::server] create source: "/Users/xiaoweiz/Downloads/test.typ"
[2024-10-27T14:04:34Z INFO  tinymist::actor::typ_client] the entry file of TypstActor(primary) is changing to EntryState { rooted: true, root: Some("/Users/xiaoweiz/Downloads"), main: Some(/test.typ) }
[2024-10-27T14:04:34Z INFO  tinymist::server] file focused[implicit,o]: Some("/Users/xiaoweiz/Downloads/test.typ")
[2024-10-27T14:04:34Z INFO  sync_lsp] notifing textDocument/didOpen succeeded in 82.46µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handling workspace/executeCommand - (2) at Instant { tv_sec: 108130, tv_nsec: 862564416 }
[2024-10-27T14:04:34Z INFO  tinymist::cmd] first manual focusing is coming
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  workspace/executeCommand - (2) in 43.29µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handling workspace/executeCommand - (3) at Instant { tv_sec: 108130, tv_nsec: 959172375 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  workspace/executeCommand - (3) in 520.54µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/codeAction - (4) at Instant { tv_sec: 108130, tv_nsec: 967458708 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/documentLink - (5) at Instant { tv_sec: 108130, tv_nsec: 967527375 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/documentColor - (6) at Instant { tv_sec: 108130, tv_nsec: 967903500 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/inlayHint - (7) at Instant { tv_sec: 108130, tv_nsec: 967927500 }
[2024-10-27T14:04:34Z INFO  sync_lsp] notifying $/cancelRequest - at Instant { tv_sec: 108130, tv_nsec: 994471916 }
[2024-10-27T14:04:34Z WARN  sync_lsp] unhandled notification: $/cancelRequest
[2024-10-27T14:04:34Z INFO  sync_lsp] notifying $/cancelRequest - at Instant { tv_sec: 108130, tv_nsec: 994948666 }
[2024-10-27T14:04:34Z WARN  sync_lsp] unhandled notification: $/cancelRequest
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/codeAction - (8) at Instant { tv_sec: 108130, tv_nsec: 995331708 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/documentLink - (9) at Instant { tv_sec: 108131, tv_nsec: 126182291 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/foldingRange - (10) at Instant { tv_sec: 108131, tv_nsec: 160836291 }
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 24.042µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/foldingRange - (10) in 162.08µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/documentSymbol - (11) at Instant { tv_sec: 108131, tv_nsec: 171305250 }
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 10.583µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/documentSymbol - (11) in 73.08µs
[2024-10-27T14:04:34Z INFO  tinymist::actor::editor] received status request(primary) Compiling
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/codeAction - (4) in 243.47ms
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/documentColor - (6) in 243.05ms
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/documentLink - (9) in 84.78ms
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/documentLink - (5) in 243.45ms
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/codeAction - (8) in 215.65ms
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 16.291µs
[2024-10-27T14:04:34Z INFO  tinymist::actor::editor] received diagnostics from primary:4: diag(Some(0))
[2024-10-27T14:04:34Z INFO  tinymist::actor::editor] received status request(primary) CompileSuccess
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 6.5µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 18.959µs
[2024-10-27T14:04:34Z INFO  tinymist::task::cache] CacheEvictTask: evict cache in 90.917µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 1.622209ms
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 929.375µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 161.25µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 483.625µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 77.334µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 340.333µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 227.584µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 8µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 32.666µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 140.541µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 191.5µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 252.083µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 230.917µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 235.083µs
[2024-10-27T14:04:34Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 282.833µs
[2024-10-27T14:04:34Z INFO  tinymist_query::analysis::tyck] Type checking on @preview/touying:0.5.3/src/exports.typ took 792ns
[2024-10-27T14:04:34Z INFO  tinymist::actor::editor] received status request(primary) Compiling
[2024-10-27T14:04:34Z INFO  tinymist::actor::editor] received diagnostics from primary:5: diag(Some(0))
[2024-10-27T14:04:34Z INFO  tinymist::actor::editor] received status request(primary) CompileSuccess
[2024-10-27T14:04:34Z INFO  tinymist::task::cache] CacheEvictTask: evict cache in 49.375µs
[2024-10-27T14:04:34Z INFO  tinymist_query::analysis::tyck] Type checking on @preview/touying:0.5.3/src/core.typ took 4.675ms
[2024-10-27T14:04:34Z INFO  tinymist_query::analysis::tyck] Type checking on @preview/touying:0.5.3/src/configs.typ took 13.000416ms
[2024-10-27T14:04:34Z INFO  tinymist_query::analysis::tyck] Type checking on @preview/touying:0.5.3/src/slides.typ took 210.583µs
[2024-10-27T14:04:34Z INFO  tinymist_query::analysis::tyck] Type checking on @preview/touying:0.5.3/themes/simple.typ took 13.953708ms
[2024-10-27T14:04:34Z INFO  tinymist_query::analysis::tyck] Type checking on /test.typ took 13.995875ms
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/inlayHint - (7) in 281.55ms
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/documentLink - (12) at Instant { tv_sec: 108131, tv_nsec: 363298541 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/documentLink - (12) in 130.92µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/codeAction - (13) at Instant { tv_sec: 108131, tv_nsec: 399271458 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/codeAction - (13) in 158.00µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/semanticTokens/full - (14) at Instant { tv_sec: 108131, tv_nsec: 417445625 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/semanticTokens/full - (14) in 83.96µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/codeLens - (15) at Instant { tv_sec: 108131, tv_nsec: 428893000 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/codeLens - (15) in 117.25µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/codeAction - (16) at Instant { tv_sec: 108131, tv_nsec: 476038541 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/documentLink - (17) at Instant { tv_sec: 108131, tv_nsec: 476071916 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handling textDocument/documentColor - (18) at Instant { tv_sec: 108131, tv_nsec: 476104125 }
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/codeAction - (16) in 94.63µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/documentLink - (17) in 96.08µs
[2024-10-27T14:04:34Z INFO  sync_lsp] handled  textDocument/documentColor - (18) in 100.63µs
[2024-10-27T14:04:35Z INFO  sync_lsp] handling textDocument/foldingRange - (19) at Instant { tv_sec: 108131, tv_nsec: 674348583 }
[2024-10-27T14:04:35Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 27.25µs
[2024-10-27T14:04:35Z INFO  sync_lsp] handled  textDocument/foldingRange - (19) in 64.42µs
[2024-10-27T14:04:35Z INFO  sync_lsp] handling textDocument/documentSymbol - (20) at Instant { tv_sec: 108131, tv_nsec: 773724916 }
[2024-10-27T14:04:35Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 12.917µs
[2024-10-27T14:04:35Z INFO  sync_lsp] handled  textDocument/documentSymbol - (20) in 66.46µs
[2024-10-27T14:04:35Z INFO  sync_lsp] handling textDocument/inlayHint - (21) at Instant { tv_sec: 108131, tv_nsec: 834794791 }
[2024-10-27T14:04:35Z INFO  sync_lsp] handled  textDocument/inlayHint - (21) in 101.46µs
[2024-10-27T14:04:35Z INFO  sync_lsp] handling workspace/executeCommand - (22) at Instant { tv_sec: 108132, tv_nsec: 212358291 }
[2024-10-27T14:04:35Z INFO  tinymist::tool::preview] PreviewTask(lv8): arguments: PreviewCliArgs {
        preview: PreviewArgs {
            enable_partial_rendering: true,
            invert_colors: "never",
            task_id: "lv8",
            refresh_style: OnType,
        },
        compile: CompileOnceArgs {
            input: Some(
                "/Users/xiaoweiz/Downloads/test.typ",
            ),
            root: None,
            inputs: [],
            font: CompileFontArgs {
                font_paths: [],
                ignore_system_fonts: false,
            },
            creation_timestamp: None,
            certification: None,
        },
        preview_mode: Document,
        data_plane_host: "<IP_ADDRESS>:0",
        control_plane_host: "<IP_ADDRESS>:23626",
        static_file_host: "",
        not_as_primary: false,
        dont_open_in_browser: false,
    }
[2024-10-27T14:04:35Z INFO  typst_preview] Previewer: typst actor spawned
[2024-10-27T14:04:35Z INFO  typst_preview] Previewer: editor actor spawned
[2024-10-27T14:04:35Z DEBUG typst_preview::actor::typst] TypstActor: waiting for message
[2024-10-27T14:04:35Z INFO  tinymist::tool::preview] preview server listening on http://<IP_ADDRESS>:60539
[2024-10-27T14:04:35Z INFO  tinymist::tool::preview] PreviewTask(lv8): preview server listening on: <IP_ADDRESS>:60539
[2024-10-27T14:04:35Z INFO  sync_lsp] handled  workspace/executeCommand - (22) in 2.51ms
[2024-10-27T14:04:35Z INFO  tinymist::actor::editor] received status request(primary) Compiling
[2024-10-27T14:04:35Z INFO  tinymist::actor::editor] received diagnostics from primary:6: diag(Some(0))
[2024-10-27T14:04:35Z INFO  tinymist::actor::editor] received status request(primary) CompileSuccess
[2024-10-27T14:04:35Z INFO  tinymist::task::cache] CacheEvictTask: evict cache in 79.667µs
[2024-10-27T14:04:35Z INFO  sync_lsp] handling workspace/executeCommand - (23) at Instant { tv_sec: 108132, tv_nsec: 254275208 }
[2024-10-27T14:04:35Z INFO  sync_lsp] handled  workspace/executeCommand - (23) in 17.08µs
[2024-10-27T14:04:35Z DEBUG typst_preview::actor::render] RenderActor: waiting for message
[2024-10-27T14:04:35Z DEBUG typst_preview::actor::render] OutlineRenderActor: waiting for message
[2024-10-27T14:04:35Z DEBUG typst_preview::actor::render] OutlineRenderActor: received message: RenderFullLatest
[2024-10-27T14:04:35Z DEBUG typst_preview::actor::render] RenderActor: has_full_render: true
[2024-10-27T14:04:35Z DEBUG typst_preview::actor::render] OutlineRenderActor: sending outline
[2024-10-27T14:04:35Z DEBUG typst_preview::actor::render] OutlineRenderActor: waiting for message
[2024-10-27T14:04:35Z DEBUG typst_preview::actor::render] RenderActor: waiting for message
[2024-10-27T14:04:35Z INFO  sync_lsp] handling textDocument/inlayHint - (24) at Instant { tv_sec: 108132, tv_nsec: 426840208 }
[2024-10-27T14:04:35Z INFO  sync_lsp] handled  textDocument/inlayHint - (24) in 59.04µs
[2024-10-27T14:04:36Z INFO  sync_lsp] notifying $/setTrace - at Instant { tv_sec: 108132, tv_nsec: 793885750 }
[2024-10-27T14:04:36Z WARN  sync_lsp] unhandled notification: $/setTrace
[2024-10-27T14:04:36Z INFO  sync_lsp] notifying workspace/didChangeConfiguration - at Instant { tv_sec: 108132, tv_nsec: 793905375 }
[2024-10-27T14:04:36Z INFO  sync_lsp] notifing workspace/didChangeConfiguration succeeded in 32.63µs
[2024-10-27T14:04:36Z INFO  tinymist::init] preferred theme: Some("light") {"compileStatus": String("enable"), "exportPdf": String("never"), "fontPaths": Null, "formatterMode": String("disable"), "formatterPrintWidth": Number(120), "hoverPeriscope": Null, "outputPath": String(""), "preferredTheme": String("light"), "rootPath": Null, "semanticTokens": String("enable"), "systemFonts": Bool(true), "typstExtraArgs": Array []}
[2024-10-27T14:04:36Z INFO  tinymist::server] new settings applied
[2024-10-27T14:04:36Z INFO  sync_lsp] handling textDocument/documentSymbol - (25) at Instant { tv_sec: 108132, tv_nsec: 796033833 }
[2024-10-27T14:04:36Z INFO  tinymist_query::syntax::lexical_hierarchy] lexical hierarchy analysis took 18µs
[2024-10-27T14:04:36Z INFO  sync_lsp] handled  textDocument/documentSymbol - (25) in 82.83µs
[2024-10-27T14:04:36Z INFO  sync_lsp] handling textDocument/codeAction - (26) at Instant { tv_sec: 108132, tv_nsec: 798727916 }
[2024-10-27T14:04:36Z INFO  sync_lsp] handled  textDocument/codeAction - (26) in 292.83µs
[2024-10-27T14:04:38Z INFO  sync_lsp] handling textDocument/inlayHint - (27) at Instant { tv_sec: 108134, tv_nsec: 791534166 }
[2024-10-27T14:04:38Z INFO  sync_lsp] handled  textDocument/inlayHint - (27) in 78.96µs
[2024-10-27T14:04:40Z INFO  sync_lsp] handling workspace/executeCommand - (28) at Instant { tv_sec: 108137, tv_nsec: 20787708 }
[2024-10-27T14:04:40Z INFO  sync_lsp] handled  workspace/executeCommand - (28) in 16.63µs
[2024-10-27T14:04:42Z INFO  sync_lsp] handling workspace/executeCommand - (29) at Instant { tv_sec: 108139, tv_nsec: 540702708 }
[2024-10-27T14:04:42Z INFO  sync_lsp] handled  workspace/executeCommand - (29) in 45.75µs
[2024-10-27T14:04:50Z INFO  typst_preview::actor::render] RenderActor: resolving span: [ElementPoint { kind: 4, index: 2, fingerprint: "" }, ElementPoint { kind: 1, index: 0, fingerprint: "" }, ElementPoint { kind: 1, index: 2, fingerprint: "" }, ElementPoint { kind: 0, index: 2, fingerprint: "" }, ElementPoint { kind: 5, index: 8, fingerprint: "" }]
[2024-10-27T14:04:50Z DEBUG typst_preview::actor::render] OutlineRenderActor: received message: ResolveSpan(ResolveSpanRequest([ElementPoint { kind: 4, index: 2, fingerprint: "" }, ElementPoint { kind: 1, index: 0, fingerprint: "" }, ElementPoint { kind: 1, index: 2, fingerprint: "" }, ElementPoint { kind: 0, index: 2, fingerprint: "" }, ElementPoint { kind: 5, index: 8, fingerprint: "" }]))
[2024-10-27T14:04:50Z DEBUG typst_preview::actor::render] OutlineRenderActor: sending outline
[2024-10-27T14:04:50Z DEBUG typst_preview::actor::render] OutlineRenderActor: waiting for message
[2024-10-27T14:04:50Z INFO  typst_preview::actor::render] RenderActor: failed to resolve span: not found: with []
[2024-10-27T14:04:50Z DEBUG typst_preview::actor::render] RenderActor: has_full_render: false
[2024-10-27T14:04:50Z DEBUG typst_preview::actor::render] RenderActor: waiting for message
[2024-10-27T14:04:55Z INFO  sync_lsp] handling workspace/executeCommand - (30) at Instant { tv_sec: 108151, tv_nsec: 819442791 }
[2024-10-27T14:04:55Z INFO  sync_lsp] handled  workspace/executeCommand - (30) in 50.29µs
[2024-10-27T14:05:34Z INFO  sync_lsp] handling workspace/executeCommand - (31) at Instant { tv_sec: 108190, tv_nsec: 947315791 }
[2024-10-27T14:05:34Z INFO  sync_lsp] handled  workspace/executeCommand - (31) in 58.88µs
[2024-10-27T14:05:34Z INFO  sync_lsp] handling workspace/executeCommand - (32) at Instant { tv_sec: 108190, tv_nsec: 961772708 }
[2024-10-27T14:05:34Z INFO  sync_lsp] handled  workspace/executeCommand - (32) in 53.67µs
[2024-10-27T14:05:34Z DEBUG typst_preview::actor::editor] EditorActor: received message from editor: SrcToDocJumpRequest { filepath: "/Users/xiaoweiz/Downloads/test.typ", line: 11, character: 6 }
[2024-10-27T14:05:34Z DEBUG typst_preview::actor::typst] TypstActor: processing src2doc: SrcToDocJumpRequest { filepath: "/Users/xiaoweiz/Downloads/test.typ", line: 11, character: 6 }
[2024-10-27T14:05:34Z INFO  tinymist::actor::editor] received status request(primary) Compiling
[2024-10-27T14:05:34Z INFO  tinymist::actor::typ_client] TypstActor: already notified for revision 6 <= 6
[2024-10-27T14:05:34Z INFO  sync_lsp] handling textDocument/documentHighlight - (33) at Instant { tv_sec: 108190, tv_nsec: 972019208 }
[2024-10-27T14:05:34Z INFO  sync_lsp] handled  textDocument/documentHighlight - (33) in 113.96µs
[2024-10-27T14:05:34Z INFO  sync_lsp] handling textDocument/documentHighlight - (34) at Instant { tv_sec: 108190, tv_nsec: 973296083 }
[2024-10-27T14:05:34Z INFO  sync_lsp] handled  textDocument/documentHighlight - (34) in 130.33µs
[2024-10-27T14:05:34Z INFO  sync_lsp] handling textDocument/codeLens - (35) at Instant { tv_sec: 108191, tv_nsec: 209102208 }
[2024-10-27T14:05:34Z INFO  sync_lsp] handled  textDocument/codeLens - (35) in 109.25µs
[2024-10-27T14:05:34Z INFO  sync_lsp] handling textDocument/codeAction - (36) at Instant { tv_sec: 108191, tv_nsec: 435778583 }
[2024-10-27T14:05:34Z INFO  sync_lsp] handled  textDocument/codeAction - (36) in 253.71µs
[2024-10-27T14:05:34Z INFO  sync_lsp] handling textDocument/documentHighlight - (37) at Instant { tv_sec: 108191, tv_nsec: 614423583 }
[2024-10-27T14:05:34Z INFO  sync_lsp] handled  textDocument/documentHighlight - (37) in 217.42µs
[2024-10-27T14:05:35Z INFO  sync_lsp] handling textDocument/codeAction - (38) at Instant { tv_sec: 108191, tv_nsec: 855535916 }
[2024-10-27T14:05:35Z INFO  sync_lsp] handled  textDocument/codeAction - (38) in 164.00µs
[2024-10-27T14:06:21Z INFO  sync_lsp] handling textDocument/documentHighlight - (39) at Instant { tv_sec: 108238, tv_nsec: 453550875 }
[2024-10-27T14:06:21Z INFO  sync_lsp] handled  textDocument/documentHighlight - (39) in 407.50µs
[2024-10-27T14:06:21Z INFO  sync_lsp] handling textDocument/codeLens - (40) at Instant { tv_sec: 108238, tv_nsec: 641160750 }
[2024-10-27T14:06:21Z INFO  sync_lsp] handled  textDocument/codeLens - (40) in 159.17µs
[2024-10-27T14:06:23Z INFO  sync_lsp] handling workspace/executeCommand - (41) at Instant { tv_sec: 108239, tv_nsec: 893074375 }
[2024-10-27T14:06:23Z INFO  sync_lsp] handled  workspace/executeCommand - (41) in 53.50µs

Package/Software version:
tinymist extension version: v0.12.0. Get it by tinymist --version in terminal.
tinymist
Build Timestamp:     2024-10-19T17:12:03.217404000
Build Git Describe:  v0.12.
Commit SHA:          4437b3bffb5f01f06bd64e4e424480ba72a88619
Commit Date:         None
Commit Branch:       None
Cargo Target Triple: aarch64-apple-darwin
Typst Version:       0.12.0

Just checked. The issue didn't exist in version 0.11.32.

If by reverse sync you mean clicking on the preview window to scroll the code window, can you tell me how to enable that feature. I came looking for that.

Possibly related: https://github.com/Myriad-Dreamin/tinymist/pull/728
You can install the extension built in the related GitHub Action page to check it.


tests: skip iscsi-gw nodes on jewel

On stable-3.0 we can't test iscsi-gw nodes on jewel because it's not
implemented yet.
Signed-off-by: Guillaume Abrioux<EMAIL_ADDRESS>

jenkins test pipeline

jenkins test pipeline

jenkins test pipeline

jenkins test pipeline

jenkins test pipeline

jenkins test pipeline


OpenLayers 3.6.0 jsfiddle and copy examples codes are not working

Just got confused by this for a bit. Root reason seems to be that they give links to https://cdnjs.cloudflare.com/ajax/libs/ol3/3.6.0/ol.js and https://cdnjs.cloudflare.com/ajax/libs/ol3/3.6.0/ol.css But cloudflare doesn't have 3.6.0 (yet?). The 3.5.0 examples work fine.

Unfortunately we cannot trigger a cdnjs build, and it takes up to 24 hours for the new version to be available on cdnjs. This is why I did not announce the release on Twitter yet.
I think next time we'll wait with updating the website until the new version is available on cdnjs.

An alternative would be to just use the openlayers.org hosted builds.
$ curl -w @curl-format.txt -o /dev/null -s http://openlayers.org/en/v3.5.0/build/ol.js
    time_namelookup:  2.537
       time_connect:  2.542
    time_appconnect:  0.000
   time_pretransfer:  2.542
      time_redirect:  0.000
 time_starttransfer:  9.049
                    ----------
         time_total:  9.049

Compare to the cloudflare time:
$ curl -w @curl-format.txt -o /dev/null -s https://cdnjs.cloudflare.com/ajax/libs/ol3/3.5.0/ol.js
    time_namelookup:  2.541
       time_connect:  4.569
    time_appconnect:  7.986
   time_pretransfer:  7.986
      time_redirect:  0.000
 time_starttransfer:  10.240
                    ----------
         time_total:  11.308

(These with curl-format.txt from this post.)
(And you can now see why I don't work from home.)

this is now working. I'd agree with @ahocevar that it would be better to hold off updating the website until the new cdnjs version is available.

if so, we should add this to the release procedure

I noticed that this new procedure was followed with 3.7. I think this issue can be closed

Agreed. I just added a note to the release procedure.


Added identifier for package nodes

The nodes that includes packages will now have '(P)' appended in their filename.

@Rishav159 Thanks! @jdaguil your to review

@Rishav159 could there be another way may be with an icon for the node rather than adding extra characters to the node name?

@jdaguil what do you think?

@pombredanne @jdaguil I changed the color of the text-background to green instead of appending '(P)' in the filenames, to identify if the files contain package information.
Please review.

Hi @Rishav159 I'll review this soon. For any pull requests, we would want to merge them into the develop branch and not master.

@jdaguil Okay. I will make the PR again to the develop branch.


YARN-11023. Extend the root QueueInfo with max-parallel-apps in Capac…

…ityScheduler.
Change-Id: I2235e5a6b45d469ad39e2006a82caf4c13d42ec4

Description of PR
How was this patch tested?
For code changes:

[ ] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 36s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
32m 23s

trunk passed

+1 :green_heart:
compile
1m  6s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 58s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 48s

trunk passed

+1 :green_heart:
mvnsite
1m  3s

trunk passed

+1 :green_heart:
javadoc
0m 52s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 45s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 54s

trunk passed

+1 :green_heart:
shadedclient
20m 55s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 53s

the patch passed

+1 :green_heart:
compile
0m 57s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
0m 57s

the patch passed

+1 :green_heart:
compile
0m 49s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
0m 49s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 39s
/results-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager: The patch generated 1 new + 69 unchanged - 0 fixed = 70 total (was 69)

+1 :green_heart:
mvnsite
0m 52s

the patch passed

+1 :green_heart:
javadoc
0m 39s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 36s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 58s

the patch passed

+1 :green_heart:
shadedclient
20m 50s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
96m 32s
/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
hadoop-yarn-server-resourcemanager in the patch passed.

+1 :green_heart:
asflicense
0m 33s

The patch does not generate ASF License warnings.

186m 10s

Reason
Tests

Failed junit tests
hadoop.yarn.server.resourcemanager.webapp.TestRMWebServicesSchedulerActivities

hadoop.yarn.server.resourcemanager.webapp.TestRMWebServicesCapacitySched

hadoop.yarn.server.resourcemanager.webapp.TestRMWebServicesForCSWithPartitions

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3737/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3737

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 37e7936755b6 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 50fc2d968f728475d1f118ee5ff1e8633a8d3be4

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3737/1/testReport/

Max. process+thread count
947 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3737/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 53s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
34m 39s

trunk passed

+1 :green_heart:
compile
1m  3s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 57s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 47s

trunk passed

+1 :green_heart:
mvnsite
1m  3s

trunk passed

+1 :green_heart:
javadoc
0m 50s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 44s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 55s

trunk passed

+1 :green_heart:
shadedclient
21m 49s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  0s

the patch passed

+1 :green_heart:
compile
1m  0s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
1m  0s

the patch passed

+1 :green_heart:
compile
0m 51s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
0m 51s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 39s
/results-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager: The patch generated 1 new + 73 unchanged - 0 fixed = 74 total (was 73)

+1 :green_heart:
mvnsite
0m 55s

the patch passed

+1 :green_heart:
javadoc
0m 44s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 38s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 58s

the patch passed

+1 :green_heart:
shadedclient
22m 41s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
96m 17s

hadoop-yarn-server-resourcemanager in the patch passed.

+1 :green_heart:
asflicense
0m 35s

The patch does not generate ASF License warnings.

191m 29s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3737/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3737

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 99364c594963 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / b31b7e32f3d18ac6742c0415d9939fca82080744

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3737/2/testReport/

Max. process+thread count
945 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3737/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Hi @tomicooler ,
Thanks for working on this.
Patch LGTM, committed to trunk.


fix: cheffile declaration outdated

Since the chef version 12 has been released, the metadata should have 'name' property (https://github.com/chef/chef/issues/2435). I noticed that it was fixed in version 0.10.1, but README.md still point to v0.9.0.

Thank you @cristianoliveira for your contribution, totally missed this in the README

Thanks you for this cookbook. ^^

Trying to keep it alive. Finally carving out some quality time for it. :+1:


Add text shadow to follows-you text on mobile

Fix for #1903, adds text shadow to follows-you text on mobile.

It shouldn't be mobile only. Follows you should have shadow if user has cover photo, similar to this:
https://github.com/kirkins/busy/blob/528e61210a3b9809378cbc162defa1864c86e7fb/src/client/components/UserHeader.less#L23-L34

I'm not sure if this change is what you want.
I see these classes for that text.
Follows you

The only one referencing cover is UserHeader__follows-you-cover-text-color so I'm targeting that now. New to using less.

You can just add .UserHeader__follows-you here (same as rank, handle, more etc.)
  &--cover {
    background-color: darken(@primary-color, 25%) !important;

    .UserHeader__rank,
    .UserHeader__rank & > i,
    .UserHeader__handle,
    .UserHeader__more,
    .UserHeader__user__username {
      color: #ffffff !important;
      text-shadow: 0 0 4px rgba(0, 0, 0, 0.8);
    }
  }


SupportsGet properties values not change when navigating between pages

I have built a search razor page using ASP.NET Core following Microsoft Documentation exactly. The search is working as expected on my page but I am facing an issue in the following scenario:

I searched for a first value and the result appeared.
I searched for a second value.
When going back to the previous page "the first value search result" by browser back button, all the data displayed successfully except the search value which is a Model property that is defined that way same as the example in the Microsoft documentation.
[BindProperty(SupportsGet = true)] public string searchValue { get; set; }
The query string is changed and all the search results refreshed except that value which is confusing.
Appreciate any help.

Hello @Kawthar-Ebrahim ...
Please re-open this issue using the This page feedback button and form at the bottom of the English-US topic. Use of the This page feedback form adds metadata to cross-link the topic to your issue and automatically pings the author.


[BUG] Nostr NIP-5 extension Issues

Describe the bug

Paid Local Part registrations aren't being activated if paid for by a remote LNbits node:

e.g.
from:

to

And Success! Your username is now active at<EMAIL_ADDRESS>Please add this to your nostr profile accordingly. If you ever need to rotate your keys, you can still keep your identity!
but crazynoisybizarretown (ID KkD479tGBVg9HZFaErbbRn) isn't active:

But there is no such problem if paid from an account in the same usr.

When using the active NIP-5 validation Failed to verify NIP05 identifier on server is the result.

https://nostriches.verifiableclaims.nz/.well-known/nostr.json?name=crazynoisybizarretown
Expected behavior

That wherever the payment was made, if successful the NIP-05 would be active.
That the NIP-05 would be accepted by Nostr clients.

Desktop (please complete the following information):

LNbits version: aafd955bb42c5affd032f5b296e6f9dec4d4dd31
Database: sqlite

Additional context
I would love a NIP-05 server validator.

Transferred issue this repo.
The issue is fixed, but I will close it after the next release is out.

Transferred issue this repo. The issue is fixed, but I will close it after the next release is out.

Just did a test of 2.6, issue still seems to persist, after payment the nip-05 is still active false

There might be an issue with extension upgrade. Can you please restart your LNbits instance.
I have re-tested and it works as expected.
Do you have any errors in the logs?

i'll try a fresh instance, might be the upgrades, also thanks for these upgrades this extension is becoming serious 🔥

Ran a fresh 12.10 copy, set with Alby wallet
2024-08-08 12:49:33.74 | INFO | <IP_ADDRESS>:62910 - "GET /nostrnip5/api/v1/domain/kpEf4e3CfaAsCoE4hzpiAb/payments/cec017fbc8f6f748d21a07211f259d3abddb143a80ab91a492a0bf158b527774 HTTP/1.1" 200 2024-08-08 12:49:36.62 | DEBUG | Checking incoming pending payment cec017fbc8f6f748d21a07211f259d3abddb143a80ab91a492a0bf158b527774 2024-08-08 12:49:36.71 | DEBUG | Status: success 2024-08-08 12:49:36.72 | INFO | Marking 'in' cec017fbc8f6f748d21a07211f259d3abddb143a80ab91a492a0bf158b527774 as not pending anymore: success 2024-08-08 12:49:36.78 | INFO | <IP_ADDRESS>:62910 - "GET /nostrnip5/api/v1/domain/kpEf4e3CfaAsCoE4hzpiAb/payments/cec017fbc8f6f748d21a07211f259d3abddb143a80ab91a492a0bf158b527774 HTTP/1.1" 200 2024-08-08 12:49:47.20 | INFO | <IP_ADDRESS>:62914 - "GET /nostrnip5/ HTTP/1.1" 200 2024-08-08 12:49:47.36 | INFO | <IP_ADDRESS>:62920 - "GET /nostrnip5/static/image/nostrnip5.png HTTP/1.1" 200 2024-08-08 12:49:47.38 | ERROR | Exception: No response returned. 2024-08-08 12:49:47.39 | ERROR | Exception in ASGI application
Seems to be fine but after payment they still remains false, could it depend on the funding source ?
I'll try to look into it a bit better in the next few days

Forgot to give an update but all works as expected, was just expecting a full list to appear on the nostr.json route but seems that going through the name query works fine. Great work !


Tech debt: pypi action not reading new version #

need to look into this if we make another release.

This seems to be fine nowadays? I see 2.1.0 on https://pypi.org/project/cumulus-library-covid/ like I expect.
Optimistically closing, but please re-open if I misunderstood.

i suspect this was fixed in part due to the cutover to __init__.py and dynamic versioning in the pyproject.toml.


(Instructor) Assignment Grades Retrigger

As an instructor, I can visit an assignment info page and see a button that says "Retrigger Grading for All" that, when clicked, re-triggers the grading procedure for all students.

Note: Scan course organization repos, and for each that corresponds to the naming convention for this specific assignment, manually trigger the grading job.

Corollary: Single student manual retrigger (should be a subset of this issue)


Support certificate type

It would be great if the tool could understand the certificate type and deploy it before everything else, so that the pod can use it.

Hi @tobsch thanks for opening an issue. We hope this tool is helpful for you. Kubernetes has several certs, so I'd like to make sure I understand which one you're talking about. Can you provide a link to the resource doc. It would also be helpful to understand your deploy flow to make sure this resource gets supported in a way that makes sense.
Since its easy to miss, this tool isn't for cluster bootstrapping and the bar for supporting non-namespaced resources is high.


[SMALLFIX] Add 'maprfs:///' to 'alluxio.underfs.hdfs.prefixes'

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12885/
Test PASSed.

LGTM


Adding language environment variable to fix IO encoding for Python 3

lgtm

Thanks, can you trigger a rebuild of the image on your end?

OK, just kicked the build off.


Mapping Issue

Someone raised an error on my repo about mapping functionality which I think belongs here: https://github.com/PBI-David/Deneb-Showcase/issues/2
To recreate, open attached.pbix and on "Gantt - PowerBI" report page, remove completion field from the Deneb field well. Add it back and then edit Deneb. You'll be prompted to remap the field which will already be in the correct place. Click apply.

See the following error.

For some reason lines like 738 which are originally
"text": {
"signal": "datum.completionLabel"
},
are replaced with
"text": {
"signal": "datum['completion']Label"
},
which doesn't exist.
Gantt.pbix.zip

Duplicate of #276.


pgpool: fix darwin build

Description of changes
Fix the darwin build by removing the included copy from the Makefiles.
ZHF: #230712
(Ideally this would be fixed upstream by making this file conditional, but contributing there is... not trivial)
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

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

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

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

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

[x] Fits CONTRIBUTING.md.


Feature request: Add "positive" at least once verifier

Background:
It would be great to verify that a request has gone through the proxy. This can be very handy when testing to verify that a specific callback has been called for example. In this case there would be an error if the verifier has still not matched any request/response when GET http://martian.proxy/verify is called.
Example interface:
Verifier:
{
  "atLeastOnce.Verifier": {
    "scope": ["request"],
    "host": "example.com",
    "path": "/testing"
  }
}

Error:
{
  "errors" : [
    {
      "message": "request(http://example.com/testing) call verify failure"
    }
  ]
}

I think pingback.Verifier will do what you want. Will that work for what you need or is it missing some functionality?

You are exactly right. pingback has this exact behavior. Looks like I was just confused by the terminology. Thanks!


[WIP] - Allows generating code from IDL in jars and submodules

This is the solution that I've found for generating code from IDL present in jar files and submodules and you're running an application (or generating a fat jar).
In the srcJarNames you need to specify not only the jars but also the submodule names that contain the IDL files.
Potentially, we'd need to change the setting name for something like srcIdlNames or something like that. This also filters the files copied to srcGenSourceFromJarsDir, so probably we wouldn't need the mappings in (Compile, packageBin) ~= { _.filter(!_._1.getName.endsWith(".class")) } filter anymore.
Thoughts?

Closed in favor of #246


Failing delete

$> curl --data-binary<EMAIL_ADDRESS>localhost:5000/v1/insert
$> curl --data-binary<EMAIL_ADDRESS>localhost:5000/v1/delete/ee6fb8de-8ebd-4df6-95dd-83a44d21dfc7
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>500 Internal Server Error</title>

Internal Server Error

The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

Output from the server:
ERROR    Exception on /v1/delete/ee6fb8de-8ebd-4df6-95dd-83a44d21dfc7 [POST]
Traceback (most recent call last):
  File "/home/morten/miniconda3/envs/dmci/lib/python3.9/site-packages/flask/app.py", line 2447, in wsgi_app
    response = self.full_dispatch_request()
  File "/home/morten/miniconda3/envs/dmci/lib/python3.9/site-packages/flask/app.py", line 1952, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/home/morten/miniconda3/envs/dmci/lib/python3.9/site-packages/flask/app.py", line 1821, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/home/morten/miniconda3/envs/dmci/lib/python3.9/site-packages/flask/_compat.py", line 39, in reraise
    raise value
  File "/home/morten/miniconda3/envs/dmci/lib/python3.9/site-packages/flask/app.py", line 1950, in full_dispatch_request
    rv = self.dispatch_request()
  File "/home/morten/miniconda3/envs/dmci/lib/python3.9/site-packages/flask/app.py", line 1936, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/home/morten/metno_repos/discovery-metadata-catalog-ingestor/dmci/api/app.py", line 73, in post_delete
    err = self._distributor_wrapper(worker)
  File "/home/morten/metno_repos/discovery-metadata-catalog-ingestor/dmci/api/app.py", line 164, in _distributor_wrapper
    status, valid, _, failed, skipped, failed_msg = worker.distribute()
  File "/home/morten/metno_repos/discovery-metadata-catalog-ingestor/dmci/api/worker.py", line 123, in distribute
    obj = self.CALL_MAP[dist](
TypeError: dmci.distributors.file_dist.FileDist() got multiple values for keyword argument 'metadata_id'
<IP_ADDRESS> - - [04/May/2022 14:24:11] "POST /v1/delete/ee6fb8de-8ebd-4df6-95dd-83a44d21dfc7 HTTP/1.1" 500 -

Problem is Worker.init has metadata_id as keyword argument, and kwargs is unpacked further down to FileDist, which has metadata_id as positional argument.


[Bug]: new .cache folder not opening Chrome

Bug description
Steps to reproduce the problem:

composer require spatie/browsershot
npm install puppeteer
Call Browsershot with .pdf(), e.g. Browsershot::html(..some view..)->pdf();

Browsershot uses puppeteer under the hood, but puppeteer can't seem to find the Chromium that it downloaded into the .cache directory. Going into the node_modules/puppeteer folder and running npm install gives the output:
"Chromium is already in [ ..local path.. ].cache\puppeteer\chrome\win64-1045629; skipping download."
Downgrading Puppeteer for v15.5 with no other changes fixes the probem.
Puppeteer version
19.0.0
Node.js version
19.0.0
npm version
8.19.2
What operating system are you seeing the problem on?
Windows
Relevant log output
Error: Could not find expected browser (chrome) locally. Run npm install to download the correct Chromium revision (1022525)

I would run this by Browsershot since this is more of a compatibility issue with Browsershot and the latest version of Puppeteer.


LLama 3/3.1 70B Outputting "!!!!!!"; Shorter Context

System Info
text-generation-launcher --env
2024-07-26T03:39:42.960734Z  INFO text_generation_launcher: Runtime environment:
Target: x86_64-unknown-linux-gnu
Cargo version: 1.79.0
Commit sha: 3905f854ed49b0bc50e6c983d3e6b254fcf02288
Docker label: sha-3905f85
nvidia-smi:
Fri Jul 26 03:39:42 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.183.01             Driver Version: 535.183.01   CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce RTX 3090        Off | 00000000:0E:00.0 Off |                  N/A |
| 49%   62C    P2             113W / 350W |  22668MiB / 24576MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA GeForce RTX 3090        Off | 00000000:0F:00.0 Off |                  N/A |
| 30%   53C    P2             102W / 350W |  21924MiB / 24576MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
+---------------------------------------------------------------------------------------+
xpu-smi:
N/A
2024-07-26T03:39:42.960780Z  INFO text_generation_launcher: Args {
model_id: "bigscience/bloom-560m",
revision: None,
validation_workers: 2,
sharded: None,
num_shard: None,
quantize: None,
speculate: None,
dtype: None,
trust_remote_code: false,
max_concurrent_requests: 128,
max_best_of: 2,
max_stop_sequences: 4,
max_top_n_tokens: 5,
max_input_tokens: None,
max_input_length: None,
max_total_tokens: None,
waiting_served_ratio: 0.3,
max_batch_prefill_tokens: None,
max_batch_total_tokens: None,
max_waiting_tokens: 20,
max_batch_size: None,
cuda_graphs: None,
hostname: "4e90e37e133c",
port: 80,
shard_uds_path: "/tmp/text-generation-server",
master_addr: "localhost",
master_port: 29500,
huggingface_hub_cache: Some(
"/root/.cache",
),
weights_cache_override: None,
disable_custom_kernels: false,
cuda_memory_fraction: 1.0,
rope_scaling: None,
rope_factor: None,
json_output: false,
otlp_endpoint: None,
otlp_service_name: "text-generation-inference.router",
cors_allow_origin: [],
watermark_gamma: None,
watermark_delta: None,
ngrok: false,
ngrok_authtoken: None,
ngrok_edge: None,
tokenizer_config_path: None,
disable_grammar_support: false,
env: true,
max_client_batch_size: 4,
lora_adapters: None,
disable_usage_stats: false,
disable_crash_reports: false,
}
I am using Ubuntu 22.04
I have two RTX 3090s.
I am using the latest docker images as of 7/25/24.
Output from pip list:
Package                                  Version

accelerate                               0.29.3
aiohttp                                  3.9.5
aiosignal                                1.3.1
annotated-types                          0.7.0
archspec                                 0.2.3
async-timeout                            4.0.3
attrs                                    23.2.0
bitsandbytes                             0.43.2
boltons                                  24.0.0
Brotli                                   1.1.0
certifi                                  2024.7.4
cffi                                     1.16.0
charset-normalizer                       3.3.2
click                                    8.1.7
cloudpickle                              3.0.0
colorama                                 0.4.6
conda                                    24.5.0
conda-libmamba-solver                    24.1.0
conda-package-handling                   2.2.0
conda_package_streaming                  0.9.0
datasets                                 2.20.0
Deprecated                               1.2.14
dill                                     0.3.8
diskcache                                5.6.3
distro                                   1.9.0
einops                                   0.6.1
filelock                                 3.15.4
frozendict                               2.4.4
frozenlist                               1.4.1
fsspec                                   2024.5.0
gmpy2                                    2.1.5
googleapis-common-protos                 1.63.2
grpc-interceptor                         0.15.4
grpcio                                   1.65.1
grpcio-reflection                        1.62.2
grpcio-status                            1.62.2
grpcio-tools                             1.62.2
hf_transfer                              0.1.8
huggingface-hub                          0.23.5
idna                                     3.7
importlib_metadata                       7.1.0
interegular                              0.3.3
Jinja2                                   3.1.4
joblib                                   1.4.2
jsonpatch                                1.33
jsonpointer                              2.4
jsonschema                               4.23.0
jsonschema-specifications                2023.12.1
lark                                     1.1.9
libmambapy                               1.5.8
llvmlite                                 0.43.0
loguru                                   0.6.0
mamba                                    1.5.8
MarkupSafe                               2.1.5
menuinst                                 2.0.2
mpmath                                   1.3.0
multidict                                6.0.5
multiprocess                             0.70.16
mypy-protobuf                            3.6.0
nest-asyncio                             1.6.0
networkx                                 3.3
numba                                    0.60.0
numpy                                    1.26.4
nvidia-nccl-cu12                         2.22.3
opentelemetry-api                        1.25.0
opentelemetry-exporter-otlp              1.25.0
opentelemetry-exporter-otlp-proto-common 1.25.0
opentelemetry-exporter-otlp-proto-grpc   1.25.0
opentelemetry-exporter-otlp-proto-http   1.25.0
opentelemetry-instrumentation            0.46b0
opentelemetry-instrumentation-grpc       0.46b0
opentelemetry-proto                      1.25.0
opentelemetry-sdk                        1.25.0
opentelemetry-semantic-conventions       0.46b0
outlines                                 0.0.34
packaging                                24.1
pandas                                   2.2.2
peft                                     0.10.0
pillow                                   10.4.0
pip                                      24.0
platformdirs                             4.2.0
pluggy                                   1.4.0
prometheus_client                        0.20.0
protobuf                                 4.25.3
psutil                                   6.0.0
py-cpuinfo                               9.0.0
pyarrow                                  17.0.0
pyarrow-hotfix                           0.6
pycosat                                  0.6.6
pycparser                                2.22
pydantic                                 2.8.2
pydantic_core                            2.20.1
PySocks                                  1.7.1
python-dateutil                          2.9.0.post0
pytz                                     2024.1
PyYAML                                   6.0.1
referencing                              0.35.1
regex                                    2024.5.15
requests                                 2.32.3
rpds-py                                  0.19.1
ruamel.yaml                              0.18.6
ruamel.yaml.clib                         0.2.8
safetensors                              0.4.3
scipy                                    1.13.1
sentencepiece                            0.1.99
setuptools                               71.1.0
six                                      1.16.0
sympy                                    1.13.0
text-generation-server                   2.0.5.dev0
texttable                                1.7.0
tokenizers                               0.19.1
torch                                    2.4.0
tqdm                                     4.66.4
transformers                             4.43.1
triton                                   3.0.0
truststore                               0.8.0
typer                                    0.6.1
types-protobuf                           <IP_ADDRESS>40626
typing_extensions                        4.12.2
tzdata                                   2024.1
urllib3                                  2.2.2
wheel                                    0.43.0
wrapt                                    1.16.0
xxhash                                   3.4.1
yarl                                     1.9.4
zipp                                     3.19.2
zstandard                                0.22.0
Information

[X] Docker
[ ] The CLI directly

Tasks

[X] An officially supported command
[ ] My own modifications

Reproduction
Run TGI like the following:
--model-id meta-llama/Meta-Llama-3.1-70B-Instruct --huggingface-hub-cache /root/.cache/huggingface/hub  --trust-remote-code --max-input-length 2047 --max-total-tokens 2048 --quantize bitsandbytes-nf4
Query the model and notice that a high percentage of the time you get "!!!!" but not always.
Also, I use to be able to run LLama 3 70B models with 5k context with dual 3090s.  Now I can not run the LLama 2 70B models without error most of the time, but It won't even fully load unless I drop the context window to something like 4k
Expected behavior
I expect to be able to use the model as expected and the context window should expand or stay the same with updates, not go down.

This just happened with the 8B model too. I am thinking it may have something to do with bits and bytes but I am not sure.

Happening when not using quantization as well.  Still pseudo-random.

Rebooting somtimes helps.  Maybe its a hardware issue.

Interesting. I haven't found this issue with 8B on A10g or 405B H100. Would be curious to know if it's indeed a hardware issue.

It didn't happen on previous versions so if it is hardware related, it's a recent development or it's a bug introduced.

I am having an issue with the quality, they are not as good as Llama-3-70B.


allDocs: include_docs: true is not default per docs

I needed to specify options.allDocs.include_docs: true in order for a collection to actually fetch the document details.  That's contrary to my understanding of the docs, which indicate that include_docs should already default to true.
var Todo = Backbone.Model.extend({
  sync: BackbonePouch.sync({
    db: todoDb
  }),
});
Todo.prototype.idAttribute = "_id";
var TodoCollection = Backbone.Collection.extend({
  model: Todo,
  parse: function(result) {
    return _.pluck(result.rows, 'doc');
  },
  sync: BackbonePouch.sync({
    db: todoDb,
    options: {
      allDocs: {
        include_docs: true
        # ^^^^^^^^^^^^^^^^ doesn't include docs without this setting
      }
    }
  })
});
var todos = new TodoCollection();
todos.fetch();

I prefer to stay with PouchDBs defaults and try to introduce as less logic as possible.


Best way to migrate from 3.1.1 to 4.0.4

DBFlow Version:
Issue Kind (Bug, Question, Feature):
Please note if you are using Instant Run, there may be bugs where generated classes are not created. Ensure you are using
the apt or kapt plugins and that incremental compilation is off.
Description:
I have been using 3.1.1 version and having too many foriegnkeycontainer
current version doesn't support foriegnkeycontianer any best for this kind of migration ?

ForeignKeyContainer is replaced with @ForeignKey(stubbedRelationship = true). Use Model.load() to get same functionality as before, without the confusion. Meaning that you can remove the ForeignKeyContainer objects and reference the actual object. Just ensure if you need all of its data, call load() before using.


[ZEPPELIN-5193] Describe table using full table name in FlinkSQL can  not work

What is this PR for?
Simple PR to make describing table via full table name in flink sql work. Just split full table name via dot separator. So that flink api can recognize it correctly. See unit test for more details.
What type of PR is it?
[ Improvement]
Todos

[ ] - Task

What is the Jira issue?

https://issues.apache.org/jira/browse/ZEPPELIN-5193

How should this be tested?

CI pass

Screenshots (if appropriate)
Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

Will merge if no more comment


Allow to specify type in /info/<entry-endpoint>

To be able to dynamically and effectively handle (especially) provider-specific resource properties, e.g., _exmpl_some_energy, it would be useful to know the value type expected.
It would make most sense to add this under the entry-endpoint's specific informational endpoint, e.g., /info/structures for the /structures entry-endpoint.
It could then be a key (type) alongside description, unit, and sortable.
It should be OPTIONAL.
I don't think many would be against adding this, the only tricky thing I see, which could spark a bit of discussion, is the allowed/recognized values.
I would propose to use JSON-typed values, since our spec leans heavily on the JSON API v1.0 already. However, I wouldn't mind custom types either, as long as they have clear and unique links to major programming language types. In this, the JSON types may not even be suitable, and we should instead look towards OpenAPI's extended JSON types to better distinguish between an array, an array with unique entries, an ordered array, etc.

I really like this suggestion as it instantly makes clients more useful for exploring a particular implementation.
I would personally prefer to stick to the JSON API types, just so we don't mix standards in the spec. Are the OpenAPI types a superset of JSON types, or do they also change the meaning of some terms?

I would personally prefer to stick to the JSON API types, just so we don't mix standards in the spec. Are the OpenAPI types a superset of JSON types, or do they also change the meaning of some terms?

I think they are a superset, making use of not having single-word types, but defining them through a JSON object with the base type as the value for a type key, and then a "modifier" through other keys. This actually already exists in JSON for numbers.
In writing up the PR, I actually remembered that we have defined types in the spec, using list instead of array, and more. I will update the PR using these OPTIMADE-defined types.

I agree with the general idea.
I guess I am the one who to disagree with JSON types. OPTIMADE has its own set of types for 'Entry properties' in section 2.1. I think those should be used here.
We essentially have these defined for the entry types in section 7 under 'Type'. It is just a question how we "typograhpically" should represent things like 'list of strings' and 'list of list of floats or unknown values'. Should those just be 'list', or?
Edit: I see now that @CasperWA added a comment just as I was writing this, essentially making the same observation about types.

We essentially have type data defined for each entry type in section 7 under 'Type'. It is just a question how we "typograhpically" should represent things like 'list of strings' and 'list of list of floats or unknown values'. Should those just be 'list', or? It would be nice with a machine readable format that can validate the data that comes out.

This is a great question I didn't really consider.
As I see it, there are two clear options:

Only consider the "outermost" type, i.e., "list of list of floats or unknown values" becomes "list".
Apply an OpenAPI-esque type definition, where the value of type then essentially becomes an infinite dict (or JSON object) with keys type and content or similar, where content's value can then be another JSON object with keys type and content, etc., etc.
content is then only allowed if the value of type represents a "container", e.g., list, otherwise the value of content´ should be null` or the key should not be supplied.

However, there is most probably another way to do this, I just see those as the obvious ones.

Since you already were on the idea of reporting JSON types, I think I would be OK with a specification of type per output format. In that case the JSON output format could really use OpenAPI to specify a validateable JSON types.
But if so it would be quite nice if also the OPTIMADE types were specified somewhere, so we'd still have the original problem :)

Since you already were on the idea of reporting JSON types, I think I would be OK with a specification of type per output format. In that case the JSON output format could really use OpenAPI to specify a validateable JSON types.

So you would add OpenAPI lingo into this endpoint under a new top-level key type_by_format (or incorporate it into output_fields_by_format) or do you mean to add this into each property's type value, so one would specify the type according to the format?

But if so it would be quite nice if also the OPTIMADE types were specified somewhere, so we'd still have the original problem :)

Hehe, yeah - then one format would be optimade which is just jibberish, kind of.

So you would add OpenAPI lingo into this endpoint under a new top-level key type_by_format (or incorporate it into output_fields_by_format) or do you mean to add this into each property's type value, so one would specify the type according to the format?

Thinking this through, no option seem particularly elegant. It feels odd to separate out type information into a separate top key, if everything else is grouped together by property. To completely re-structure property info under these endpoints into an output_fields_by_format structure is also not a great option at this point. On the other hand, sticking what could be a massive data structure with one field per conceivable output format inside the property dictionaries seems a bulky option.
And all this for providing info that is anyway intended to be redundant with the OPTIMADE type information. Furthermore, isn't the OpenAPI type representation also already present in the JSON schema for the output?
Hence, after thinking more about this, I lean towards only giving OPTIMADE type info in a machine-readable format, and that we provide a library algorithm that maps that onto a OpenAPI schema fragment for the JSON output. Similar algorithms can then be created for other formats, e.g., to HDF5 types, etc.

So you would add OpenAPI lingo into this endpoint under a new top-level key type_by_format (or incorporate it into output_fields_by_format) or do you mean to add this into each property's type value, so one would specify the type according to the format?

Thinking this through, no option seem particularly elegant. It feels odd to separate out type information into a separate top key, if everything else is grouped together by property. To completely re-structure property info under these endpoints into an output_fields_by_format structure is also not a great option at this point. On the other hand, sticking what could be a massive data structure with one field per conceivable output format inside the property dictionaries seems a bulky option.

Yeah, I tend to agree.

And all this for providing info that is anyway intended to be redundant with the OPTIMADE type information. Furthermore, isn't the OpenAPI type representation also already present in the JSON schema for the output?

I don't think so. The OpenAPI type representation is (as I understand) an extension of the JSON type representation and only present in the openapi.json schemas. Nor are there any explicit type representation otherwise.
However, there is of course the implicit representation (as when you would decode a JSON into Python type formats or similar).

Hence, after thinking more about this, I lean towards only giving OPTIMADE type info in a machine-readable format, and that we provide a library algorithm that maps that onto a OpenAPI schema fragment for the JSON output. Similar algorithms can then be created for other formats, e.g., to HDF5 types, etc.

I like this. We should then think about extending the spec with this info - or even better, have some proper documentation that fleshes out the spec more with examples and such. In that way we can maybe even thin out the actual spec, removing some examples and redundant text.
However, for me the question still stands:

Have only a single type value for each property, it being the "outermost" one, or
Support "nested" property types à la my example above
?

On another note, the OPTIMADE data types does not take lists of unique elements into account (sets in Python).
This is also not a necessity to have (I think?), it is merely an observation. And I wonder if it's an oversight on our part originally?

@CasperWA Yes, there is no 'set' type in OPTIMADE, only lists. Any set can be represented as a list of the elements, so the need for this as a separate data type hasn't come up yet. IMO the distinction is more relevant in programming languages than for 'data transport' in API requests and responses. You are free to cast to/from sets as you wish in your implementation.

Furthermore, isn't the OpenAPI type representation also already present in the JSON schema for the output?
I don't think so. The OpenAPI type representation is (as I understand) an extension of the JSON type representation and only present in the openapi.json schemas. Nor are there any explicit type representation otherwise.

Do we presently not do any form of validation that a JSON response containing property data confirms to an expected JSON data type for that property? We probably should do that.

However, for me the question still stands:
Have only a single type value for each property, it being the "outermost" one, or
Support "nested" property types à la my example above?

Personally I'm in favor of encoding the nested types if we can do it consistently. We already specify it in the specification, so it seems odd to throw away information.

Furthermore, isn't the OpenAPI type representation also already present in the JSON schema for the output?
I don't think so. The OpenAPI type representation is (as I understand) an extension of the JSON type representation and only present in the openapi.json schemas. Nor are there any explicit type representation otherwise.

Do we presently not do any form of validation that a JSON response containing property data confirms to an expected JSON data type for that property? We probably should do that.

I don't think we do, no.
Maybe we do do it in the OPTIMADE Validator, which is a part of the optimade-python-tools repository? But most likely it is implicit. What do you reckon @ml-evs?

Personally I'm in favor of encoding the nested types if we can do it consistently. We already specify it in the specification, so it seems odd to throw away information.

I agree, and will update #270 accordingly.

@CasperWA Yes, there is no 'set' type in OPTIMADE, only lists. Any set can be represented as a list of the elements, so the need for this as a separate data type hasn't come up yet. IMO the distinction is more relevant in programming languages than for 'data transport' in API requests and responses. You are free to cast to/from sets as you wish in your implementation.

I can agree with this sentiment.

All right. So as a first suggestion for nested types, I have this example for three custom properties:

_exmpl_list_prop: list of list of floats or unknown values
_exmpl_dict_prop: list of dictionaries with keys:

name: string
occupation: list of floats

_exmpl_entry_version: int

{
  "data": {
    // ...
    "properties": {
      "_exmpl_entry_version": {
        // ...
        "type": "integer"
      },
      "_exmpl_list_prop": {
        // ...
        "type": {
          "type": "list",
          "content": {
            "type": "list",
            "content": "float"
          }
        }
      },
      "_exmpl_dict_prop": {
        // ...
        "type": {
          "type": "list",
          "content": {
            "type": "dictionary",
            "content": {
              "name": "string",
              "occupation": {
                "type": "list",
                "content": "float"
              }
            }
          }
        }
      }
      // ... <more properties>
    }
  }
  // ...
}

The only loss of information now is the possibility of a collection type containing more than a single type (so the information for _exmpl_list_prop about unknown values is lost).
I guess this could be solved by letting content have a list value also, instead of either string or another dictionary? But I refrained from this at this point, since it would clutter it up too much, I think.
I don't know if this makes sense and is good-enough, or we should instead try to appropriate the OpenAPI nomenclature/data structure for describing a field's type?

I don't think we do, no.
Maybe we do do it in the OPTIMADE Validator, which is a part of the optimade-python-tools repository? But most likely it is implicit. What do you reckon @ml-evs?

It's implicit in the deserialization step to our pydantic models in the validator, though this may be more lenient than we want, as pydantic just uses standard Python type coercion under the hood. (e.g. bools, str and numerical types will all be essentially interchangeable, but structured types should be validated properly).

All right. So as a first suggestion for nested types, I have this example for three custom properties:
* `_exmpl_list_prop`: list of list of floats or unknown values

* `_exmpl_dict_prop`: list of dictionaries with keys:

  * `name`: string
  * `occupation`: list of floats

* `_exmpl_entry_version`: int

...
The only loss of information now is the possibility of a collection type containing more than a single type (so the information for _exmpl_list_prop about unknown values is lost).
I guess this could be solved by letting content have a list value also, instead of either string or another dictionary? But I refrained from this at this point, since it would clutter it up too much, I think.
I don't know if this makes sense and is good enough, or we should instead try to appropriate the OpenAPI nomenclature/data structure for describing a field's type?

I like this approach. We don't have any mixed types in collections aside from unknown values, which are clearly described in the descriptions of fields that allow them.
At a later date, we could even add an additional flag to fields, something like allow_unknown to standardize this more rigorously across the spec?

I like this approach. We don't have any mixed types in collections aside from unknown values, which are clearly described in the descriptions of fields that allow them.
At a later date, we could even add an additional flag to fields, something like allow_unknown to standardize this more rigorously across the spec?

Cheers.
And I like the idea of the allow_unknown flag. However, if we intend to allow collections with mixed types, it may be better to properly implement this from the start? I'm not completely sure.
For me, mixed types in collections kind of defeats some of the automation a bit, but not completely of course, since everything is still ordered...
But I would still prefer not to do this, and instead simply have the allow_unknown flag 👍

I have been arguing previously that we should commit to never mix types, apart from allowing nulls (and even this we should be somewhat careful with). We are trying to create a standard that spans backend and response format representations, and for some of those mixed formats may be tricky and/or very non-optimal to represent.

I'm really sorry but somehow I missed this issue before.
If I understand right there are four use cases when the machine-readable format of a property could be useful:

When you want to support autocompletion  eg. in python notebooks
or when you want to read/load/adapt the result of a query itself
or when you want to validate the data before you put it into the database
or when you want to do a query using database-specific properties (like STARTS on a string and > on floats and HAS on arrays etc.) (which would be extremely useful in the future)

I think a solution which supports all of these use-cases would be great but:

In the first case, I think only the dict type provides you with useful information. The concrete and list types are not relevant here, but I think it is not a good idea to support nested properties (see below)

In this case, many formats (like hdf5) already stores the types alongside the data.
In the case of JSON, the type of data can be inferred from the representation itself. Of course, in this case, it is possible to have weird cases (like "1" is a string, integer or a float question) but they usually cause only minor issues. If you really want to utilise all the type information you have to build your own JSON Decoder which can hit hard on your performance (even if you are only using custom validators in pydantic). I'm just saying you should trust in the data that you get by the query and ideally you should be able to use it as it is.

I think this case the use of the type information would definitely help to check the data before you push into the database but realistically there are too many options to do that. It is also quite tricky to implement a validator which gets their specification from the web through an API (which is not very realistic). Obviously, you can use the

I think types would be the most important in this case (and it will be), but now you can always try to do the query and allow to fail. Of course, it would be nice to have well-formatted error message but not convinced that would worth it.

In conclusion, I completely agree that the types are very important and in science a value doesn't mean anything without its context (definition, unit, type etc). I'm just saying that at the end this information is more useful for the human than for the machine :)
I would rather use a simple but still usefull representation like:

type: any, bool, int, float, string, dict
shape: [1] (scalar as default), [3], ["natoms"], [null], [3, 3], ["natoms", 3], [null, 3]

Notes:

array[any], array[float] etc. can be introduce to be more verbose.
null would mean arbitrary number (I would prefer ... notation bu tit is not permitted in json)

The type would describe the type of the data and the shape its shape :)
Obviously, an array is just a list of list of something but that definition doesn't give me any information about its shape.
Of course, in this case, there is no way to describe nested data structures like a dictionary but I would rather allow having a nested property (like _exmpl.energy.total) rather than allowing to define nested properties types. In this case, every property in the dictionary can be described if it is needed otherwise it can be handled as any or dict
Small remarks:

I would use any instead of unknown just because it sounds more permissive...

I would say that it should be completely optional to define types (default can be any) Every extra information is welcomed but it just adds an extra layer of complexity to implement it and currently provide only a very small reward...

I don't agree with the nested type structure. At the end it allows you to define your whole database as a single dictionary, which is nice but I'm not sure is useful at all.

In the case of a dictionary, it is very important that the key itself can be other than a string (like int, datetime, or any other hashable object). It is always a key-value pair where the key and the value has its own type.

similarly to dict if you have tuples you can easily end up having multiple types (like [1, "H", [213.23 12.32 324.32]]).

I know a lot of decision has been already done for a reason (like not allowing the nested properties) so in that case please ignore those remarks without explaining it to me and just use those ones which are relevant for you.

@fekad I should probably point you towards @CasperWA's PR #270 which has some concrete suggestions, especially for dealing with nested properties (which are allowed, some OPTIMADE properties themselves are nested, like species). The discussion on that PR also been extended to providing descriptions for provider-specific fields.

@ml-evs Thanks, of course, I checked the PR before and I still have the same confusion namely:

Where do you want to use this type definition?
I also understand the species has a  list of dictionary structure which is nice but can you please given an example how would you query that property?

Of course, that list of dictionary structure can be useful in many other cases I just can't see when would need to have the information about the types. (Querying is very difficult and as far as I know in other cases like autocompletion won't work either because you hate to use indices )
For example, the autocomplete won't work in the following cases:

structure.propery.species[1].name: this works should return wit a value
structure.propery.species[:2].name: Is this a list of the name both the first 2 elements?
structure.propery.species.name: Is this a list of the names of all elements? In python, you will see an error saying that the list doesn't have name attributes and its right...

For me, the original motivation and use case is your 4th stated use case above.
Essentially, I have and am developing a client, which you can find here: https://dev-tools.materialscloud.org/optimadeclient/
In it, I would like, e.g., a filter tab to be called "Advanced" or "Provider-specific".
Here, I would then add input filters depending on the provider-specific fields. Dynamically.
There would be some behind the scenes logic to figure out if it's possible or not (if it's too nested or a certain combination of nestings), but most probably, it will just look for specific types that I have specific input handlers (widgets) for, e.g., str or int, and otherwise not include an allowable input for it.
You're comments above seem to go a bit above and beyond, I think, but touches on some crucial concepts.
Since my use case was only for what I've outlined here, I didn't really consider this discussion in the context of other use cases. If we go forward with this implementation of a type key, we should make clear the use case, i.e., the intended use for it, and spell it out in the spec, perhaps?
Personally, I don't think the goal should be to use this as response validation. I think we have better tools for that in the optimade-python-tools repository. Or at least that's the hope and intention.
And for your second use case (handling the result of a query, i.e., a response), I think that's (to an extent) highly related to the handler language of choice. It's the issue of that particular taste and not a responsibility of OPTIMADE.

I also understand that nested properties are allowed to be used but as far as I can know there is no way to describe them in info/structures endpoint. I just don't understand why is it good to describe the first layers as properties and the rest as type definition?
The same applies to even simpler structures like: _odbx_dft_parameters
In this case, you would have a single key element which contains a dictionary which contains a type definition which describes the nested structure...
I'm just saying I would use the nested structure from the beginning...

I also understand that nested properties are allowed to be used but as far as I can know there is no way to describe them in info/structures endpoint. I just don't understand why is it good to describe the first layers as properties and the rest as type definition?

In the PR there is a suggestion on how this can be mitigated and describe the nested properties as well.

I also understand that nested properties are allowed to be used but as far as I can know there is no way to describe them in info/structures endpoint. I just don't understand why is it good to describe the first layers as properties and the rest as type definition?

In the PR there is a suggestion on how this can be mitigated and describe the nested properties as well.

I was mainly looking 5.3.2   Entry Listing Info Endpoints and  I missed the suggestions but I will continue there :)

Cheers @fekad. And I appreciate you continuing the discussion in this issue as well (instead of the PR).
I'd like to see if we can keep the PR clear and only about suggested changes to the content (although I already kind of blew that one...).
So that the issue becomes "design" and the PR becomes "implementation". Because otherwise I fear we'll lose complete track of the discussion details.

@fekad
So with the example in the PR I finally understand your intended use of type in combination with shape. While it's a little tricky to wrap my head around when type describes the "first order" or "second order" type, I see the value in adding linked restrictions in the shape. But as I understand it, the addition of "links" in this way would be the main thing gained by using shape?
Also, I don't think I see the major difference in using a list instead of a dictionary with the "name" as key? A property name has already been defined to be [a-z_][a-z_0-9]*, so it must be a string, so if JSON has issues with a key not being a string (I forget if it does), then that shouldn't be an issue :)

@fekad
So with the example in the PR I finally understand your intended use of type in combination with shape. While it's a little tricky to wrap my head around when type describes the "first order" or "second order" type, I see the value in adding linked restrictions in the shape. But as I understand it, the addition of "links" in this way would be the main thing gained by using shape?

Mainly yes and it is also simpler to represent something likelist of list of list of floats structures in the case of a 3D array.

Also, I don't think I see the major difference in using a list instead of a dictionary with the "name" as key? A property name has already been defined to be [a-z_][a-z_0-9]*, so it must be a string, so if JSON has issues with a key not being a string (I forget if it does), then that shouldn't be an issue :)

I defined as a list of dictionaries mainly because of philosophical reason. I think the name, the definition theunits etc. simply belongs together ...
Are you saying that the following dictionary cannot be hosted by the OTPMADE API?
_odbx_dft_parameters.my_nice_dict: {
    "0": "H",
    "1": "H"
}

Of course in the python representation, the keys (0,1,...) would be integers and not strings
I'm not saying that this example is useful at all but ...
I also admit that my proposed solution would be only defined as generaldict

Are you saying that the following dictionary cannot be hosted by the OTPMADE API?
_odbx_dft_parameters.my_nice_dict: {
    "0": "H",
    "1": "H"
}

The key would not be allowed due to the . (period). But there are no restrictions on the value (except mixed values in "containers" are not allowed/discouraged).

Are you saying that the following dictionary cannot be hosted by the OTPMADE API?
_odbx_dft_parameters.my_nice_dict: {
    "0": "H",
    "1": "H"
}

The key would not be allowed due to the . (period). But there are no restrictions on the value (except mixed values in "containers" are not allowed/discouraged).

Sorry, example was not precise enough (it is not about the .period but rather about the restriction on the property name [a-z_][a-z_0-9]*):
"_odbx_dft_parameters":{
    "my_nice_dict": {
        "0": "H",
        "1": "H",
    }
}

But thanks for the reply anyway, this question does not belong to this issue anyway so might be better to discuss it somewhere else...
Back to the original concept, I do think about the type and shape as "first order" or "second order" type definition. I would also say that an array is NOT a list of list of something rather an array with a specific shape and type. Usually, an array is stored contiguously rather than a linked list.
I know in the case of JSON an array is just a list of list of something, but you can find this type+shape concept in many programming languages:

C++: int my_array [3][5];
numpy in python: my_array=np.zeros((2,3)); my_array.dtype, my_array.shape
juliad: my_array = zeros(2,3); typeof(my_array), size(my_array)
HDF5, etc.

IMO, in the field of scientific computing, it also makes more sense...

Are you saying that the following dictionary cannot be hosted by the OTPMADE API?
_odbx_dft_parameters.my_nice_dict: {
    "0": "H",
    "1": "H"
}

The key would not be allowed due to the . (period). But there are no restrictions on the value (except mixed values in "containers" are not allowed/discouraged).

Sorry, example was not precise enough (it is not about the .period but rather about the restriction on the property name [a-z_][a-z_0-9]*):
"_odbx_dft_parameters":{
    "my_nice_dict": {
        "0": "H",
        "1": "H",
    }
}

I presume this restriction only exists for "top-level" properties, i.e., not for values with dicts. For these, the only limitations are what the response format allows. But I don't think this has ever been truly addressed.

But thanks for the reply anyway, this question does not belong to this issue anyway so might be better to discuss it somewhere else...

Yes, please.

Back to the original concept, I don't think about the type and shape as "first order" or "second order" type definition. I would also say that an array is NOT a list of list of something rather an array with a specific shape and type. Usually, an array is stored contiguously rather than a linked list.
I know in the case of JSON an array is just a list of list of something, but you can find this type+shape concept in many programming languages:

C++: int my_array [3][5];
numpy in python: my_array=np.zeros((2,3)); my_array.dtype, my_array.shape
juliad: my_array = zeros(2,3); typeof(my_array), size(my_array)
HDF5, etc.

IMHO, in the field of scientific computing, it also makes more sense...

Sure!
I wasn't trying to talk against it, as much as trying to wrap my head around its limitations and connotations.
I think, my initial question about it was only what would be gained (or lost) by adding also shape. And in this, I think we've nailed the pros, in terms of the inter-property links/restraints, as well as the simpler way of describing heavily nested properties.
What are the cons then? Expecting the providers to deliver too much information? That we're turning the /info/<entry-endpoint> into a schema validation endpoint? I don't know whether these are cons or how difficult it would be for everyone to provide this information. But what I want to get at is, how much can we demand to be added here before it becomes too much of a hassle for new providers, while still meeting the goals of the most common use cases?

I believe the combination of #376 and #282 allow this to be closed, after lots of great discussion!


ADD some char features

ADD NCurses::Window#add_char
ADD NCurses.flush_input
ADD convenient #get_max_x/#get_max_y

@jreinert Maybe you missed my comment, i had a question concerning the Point struct. But for now, I pushed the raw changes that you asked. Is this PR ok for you ? Maybe we can push further your Point idea in another PR ?

Sorry for the delay. This is fine. We can add the Point struct later.


Loading time 3 Minutes for 5000 Games

I have approximately 5000 games across multiple systems loaded onto my Vita and when first opening the RetroFlow Launcher it takes around three minutes to load (I timed it)
Is there Any room for optimization for those of us with larger libraries?
Thanks,
Arch

Of the 5,000 games, is it mostly Vita?

Less than 10 vita games, mostly old retro titles (NES/SNES/GG/MS/MD, etc)

.

I've released a new version with resolves the issue:
https://github.com/jimbob4000/RetroFlow-Launcher/releases/tag/v3.0


vit support

What does this PR do?
Adds ViT family to BetterTransformer integration
Replaces #469
cc @fxmarty @michaelbenayoun

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Avoid infinite hang BuildCookRun commandlet due to OSVR server connec…

…t failure
For #81
Didn't include switching plugin module Types to "RuntimeNoCommandlet"

Thank you! Could you add this line just before the return?
UE_LOG(OSVREntryPointLog, Display, TEXT("OSVREntryPoint::OSVREntryPoint(): running as commandlet or dedicated server - skipping client context startup."));

Also, could you add a null check to the destructor? This prevents OSVR from logging an error:

Added


Fix font rebuild

also updated imgui to 1.89.6

Can't merge in master, it contains many conflicts

can you merge it to branch revert-839-revert-769-feature/its_all_about_fonts first, then merge https://github.com/maximegmd/CyberEngineTweaks/pull/840
this should resolve the conflicts


Bot is sharing session response

I have integrated bot on my website using nodejs SDK and I have injected the webchat on my page using "Easy: In your non-React website, run WebChat inline" method from here : https://github.com/Microsoft/BotFramework-WebChat
But the problem is, when more than 1 person is talking with bot in-parallel. In this scenario bot is taking the input from user 1 and validating that from database after that if user 2 is is giving some wrong info then also bot is going to further steps and replying user 2 with the inputs given through bot to user 1.
I am using waterfall model and as we are receiving inputs from bot using "args.response", I'm not understanding why it is sharing the session.

This sounds like a question for StackOverflow, so please ask there. I'm going to close this issue, but as a  parting thought I'm going to speculate that you are using the same user id when creating the WebChat, and  that your bot is storing info in userData.


Develop

Coverage remained the same at 16.087% when pulling e922b58d08dfea69bb2f1c4ea89494210f0e777c on develop into 8442b6e97a78beeeab10dc6a5114ab4727e0e3ea on master.