WIP: Syntax Highlighting

I've implemented a basic version of syntax highlighting and am looking for feedback (whether the overall approach is good).
Highlighting with tree sitter:

Highlighting with font lock:

Currently I'm not really taking advantage of the more context sensitive tree sitter information, and am just using the default font lock faces.
I'm not sure how to best distribute this highlights.scm file, currently users need to specify the path to this_repo/grammars, from which the highlights.scm file for the given language is then read.
~The only major bug I've noticed, is that while typing, sometimes code isn't immediatetly highlighted. For example, when I type~
union X {
    a: i32,
    b: i32;
}
// or
fn foo() {
    let z = 1337;
}

~Manually calling tree-sitter-highlight--highlight fixes that however, so I'm thinking it might have something to do with the comment on the after-change function in tree-sitter.el. My tree-sitter-highlight--handle-change isn't being called for unions or lets inside functions, but if I type the same let on the top level it is, I'm not quite sure what's causing that as I'm not familiar with tree sitter.~
Edit: I've fixed this, changed_ranges had a bug. Even if this PR isn't merged, that one commit (6bed1e1) should definetly be merged.
My current config for using this looks like this:
(use-package f)

(add-to-list 'load-path "/vm/dev/github.com/th0rex/emacs-tree-sitter")

(require 'tree-sitter)
(seq-do #'ts-require-language '(c cpp go python rust))

;; Path to <this_repo>/grammars
(setq tree-sitter-highlight-query-dir "/vm/dev/github.com/th0rex/emacs-tree-sitter/grammars")
(require 'tree-sitter-highlight)

(defun enable-ts-hl ()
  (tree-sitter-highlight-mode))

(add-hook 'c-mode-common-hook #'enable-ts-hl)
(add-hook 'python-mode-hook #'enable-ts-hl)
(add-hook 'rust-mode-hook #'enable-ts-hl)

This PR looks great! I've been playing around with it and it works quite nicely. One thing I have noticed is that for some situations multiple faces are being applied to the same region. For example in Python:
p = Package(...)

The Package should be highlighted as Constructor based on the Python highlights.scm but when I inspect, the word is highlighted with (tree-sitter-variable-face tree-sitter-function-face tree-sitter-constructor-face nil). I will be digging into the code over the coming days and see whether I can help :)

Thanks, this is great progress!
I changed the parameter order of ts-changed-ranges's and updated its docstring so that it's consistent with the Rust/C APIs.
I also pushed the fixes for ts-make-query, ts-query-captures, ts-query-matches.

I'm not sure how to best distribute this highlights.scm file, currently users need to specify the path to this_repo/grammars, from which the highlights.scm file for the given language is then read.

Ideally this file should be distributed together with the compiled language description (e.g. rust.so). Initially it could be a separate package that bundles multiple languages together. If/when tree-sitter becomes established enough that there are major modes based on it, it will be the job of the major modes to distribute these artifacts.

This PR looks great! I've been playing around with it and it works quite nicely. One thing I have noticed is that for some situations multiple faces are being applied to the same region. For example in Python:
p = Package(...)

The Package should be highlighted as Constructor based on the Python highlights.scm but when I inspect, the word is highlighted with (tree-sitter-variable-face tree-sitter-function-face tree-sitter-constructor-face nil). I will be digging into the code over the coming days and see whether I can help :)

I know that multiple faces are added, but that's actually intended. For me when I try doing x = Package(...), then the constructor face is added last (i.e. it's first in the list) ((tree-sitter-constructor-face tree-sitter-constant-face tree-sitter-function-face tree-sitter-variable-face nil)).
The reason I'm wanting to add multiple properties is that highlighted regions generally may overlap:
#[derive(Debug)]

the Debug is both a constructor but also inside an attribute, I'm sorting the query results such that larger things are added first (i.e. the attribute in this case), and more specific things later. At least for the rust implementation of querying the regions to highlight the sort is stable, i.e. if two things apply for the exact same range, the order is kept as given to use by the tree sitter api, which should (I think) reflect the order they're declared in a highlights.scm file.
If you could paste more of the python code for which the faces are being applied in the wrong order (because it doesn't happen in my python files/your code that i just pasted) that would be great. Maybe it's also caused by some incremental highlighting thing, see what happens after you've just openend that buffer and it was highlighted completely, whether the order is the same etc.

I was obtaining a different result as I was using the elisp implementation. Using the Rust implementation, I obtain the expected results.
I believe the difference in behaviour is due to this portion in highlights.rs:
for (i, (node, capture_index)) in vec.into_iter().rev().enumerate() {
    v.set(i, env.vector((capture_index, root_node.map(|_| node)))?)?;
}

The captures are reversed before they are passed to add-face-text-property. In the elisp version, the order of the captures are not reversed. I have tested adding a reverse call to tree-sitter-highlight--lisp at L240 and it seems to have fixed the issue.
I'm quite new to all of this so please let me know if I have misunderstood the code somewhere.

Oh yeah seems like I've just forgotten that in the elisp version then, I only use that to play around with changes anyway because I don't need to restart emacs to reload the rust code.

Just wondering, what is the state of the branch atm? I tried to load it in this morning, but I'm unable to get updated code to appear formatted by tree-sitter. For example, activating tree-sitter-highlight-mode colors the file but also outputs this in the messages buffer:
helm-M-x: Wrong number of arguments: (2 . 2), 4Invalid face reference: nil
Invalid face reference: nil [727 times]

And then anytime code is updated or even navigated, the Invalid face reference: nil error count increments wildly. Is this a error I can mitigate on my end?

The code works decently well for me, I've been using it for the past two weeks in Rust and C without any huge problems. I've never seen that error, it could be my fault, I don't really know how faces work in emacs, but settings the face to nil should be allowed. In what language are you getting that error? I've also briefly been using helm/ivy with this and didn't have any problems there.

Using Emacs 26.3, tried Python highlighting and ran into this error.
I started with a standard setup, downloaded your fork, ran make build and make ensure/python. Both succeeded just fine. Along with the relevant setup code you gave in the first comment in this PR, I was able to load the fork just fine.
When I opened up a Python file however, it would not automatically turn on tree-sitter-highlight-mode even though I added it as a hook. That's fine, I can just turn it on manually. As soon as I do M-x tree-sitter-highlight-mode, I run into those errors above.
I'm not really sure how to debug this.
I'll try testing this on a clean Emacs setup and see if it is Helm related or something else on my end.

@th0rex I turned on debugging, and this is the trace I get:
Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 4)
  #f(compiled-function (var val) "Set variable VAR to value VAL in current buffer." #<bytecode 0x2238cf>)(font-lock-fontify-buffer-function (lambda nil (tree-sitter-highlight--jit (point-min) (point-max))) font-lock-fontify-region-function (lambda (start end _verbose) (tree-sitter-highlight--jit start end)))
  (setq-local font-lock-fontify-buffer-function (lambda nil (tree-sitter-highlight--jit (point-min) (point-max))) font-lock-fontify-region-function (lambda (start end _verbose) (tree-sitter-highlight--jit start end)))
  tree-sitter-highlight--enable()
  (prog1 (tree-sitter-highlight--enable) (setq err nil))
  (unwind-protect (prog1 (tree-sitter-highlight--enable) (setq err nil)) (if err (progn (setq tree-sitter-highlight-mode nil))))
  (let ((err t)) (unwind-protect (prog1 (tree-sitter-highlight--enable) (setq err nil)) (if err (progn (setq tree-sitter-highlight-mode nil)))))
  (if tree-sitter-highlight-mode (let ((err t)) (unwind-protect (prog1 (tree-sitter-highlight--enable) (setq err nil)) (if err (progn (setq tree-sitter-highlight-mode nil))))) (tree-sitter-highlight--disable))
  (let ((last-message (current-message))) (setq tree-sitter-highlight-mode (if (eq arg (quote toggle)) (not tree-sitter-highlight-mode) (> (prefix-numeric-value arg) 0))) (tree-sitter-mode) (if tree-sitter-highlight-mode (let ((err t)) (unwind-protect (prog1 (tree-sitter-highlight--enable) (setq err nil)) (if err (progn (setq tree-sitter-highlight-mode nil))))) (tree-sitter-highlight--disable)) (run-hooks (quote tree-sitter-highlight-mode-hook) (if tree-sitter-highlight-mode (quote tree-sitter-highlight-mode-on-hook) (quote tree-sitter-highlight-mode-off-hook))) (if (called-interactively-p (quote any)) (progn nil (if (and (current-message) (not (equal last-message (current-message)))) nil (let ((local " in current buffer")) (message "Tree-Sitter-Highlight mode %sabled%s" (if tree-sitter-highlight-mode "en" "dis") local))))))
  tree-sitter-highlight-mode()
  enable-ts-hl()
  run-hooks(change-major-mode-after-body-hook prog-mode-hook python-mode-hook)
  apply(run-hooks (change-major-mode-after-body-hook prog-mode-hook python-mode-hook))
  run-mode-hooks(python-mode-hook)
  python-mode()
  set-auto-mode-0(python-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer min_spaces_composed_str.py> "~/cart/codereview/min_spaces_composed_str.py" nil nil "~/cart/codereview/min_spaces_composed_str.py" (3937650 66306))
  find-file-noselect("~/cart/codereview/min_spaces_composed_str.py" nil nil t)
  find-file("~/cart/codereview/min_spaces_composed_str.py" t)
  funcall-interactively(find-file "~/cart/codereview/min_spaces_composed_str.py" t)
  call-interactively(find-file nil nil)
  command-execute(find-file)

I'm wondering if I missed some installation step with regards to the rust/elisp code. This is my setup in a clean Emacs launch:
(require 'f)
(add-to-list 'load-path "/somefolder/repos/emacs-tree-sitter")
(require 'tree-sitter)
(ts-require-language 'python)

(setq tree-sitter-highlight-query-dir "/somefolder/repos/emacs-tree-sitter/grammars")
(require 'tree-sitter-highlight)

(defun enable-ts-hl ()
  (tree-sitter-highlight-mode))

(add-hook 'python-mode-hook 'enable-ts-hl)

Before loading this, I do the usual make build, make ensure/python commands in the tree-sitter directory. Any insight would be appreciated!

Seems like setq-local only supports one variable and value form instead of arbitrary many in all released emacs versions, and I've been using emacs compiled from git directly and thus had support for arbitrary many. That should be fixed now.
The elisp version referred to the actual highlighting (which now is all in rust), I've since removed that as I've only used it to quickly experiment with changes.

@th0rex Thanks for figuring that out! I guess I should eventually upgrade to 27, but that's good to know.
I now have the highlighting working, and am really enjoying it. I'll let you know if I find anything else.

A suggestion for default behavior-- I prefer operators to be highlighted the same as keywords. Correct me if I'm wrong, but I believe this is how highlighters other this PR would treat them as well. I've made the following change to get the behavior I like:
(defface tree-sitter-operator-face '((default :inherit font-lock-keyword-face))
  "Face used for operator"
  :group 'tree-sitter-highlight-faces)

Just a heads-up, if you are still working on this: I reorganized the directory structure a bit, moving all Lisp code to lisp/. You may want to rebase this branch.

Currently I'm not working on this anymore, but I will again in the future (at most ~6 months from now) and I hope to get a better version done then. You were correct regarding the comment about font-lock, in fact sometimes highlighting got out of sync and some regions were left unfontified during the time I was using this but font-lock thought they were fontified, which is likely a result of font-lock and tree-sitter disagreeing on what region needs to be updated.
In general I'm still not quite sure how to clear highlights correctly after a change without causing "flickering", which was the reason for trying to use font/jit-lock. Using after-change-hook and immediately clearing ts-changed-ranges and then re-applying the faces according to the query results is correct, however as soon as your code has syntax errors in it (which happens often during editing), a really large region of text was cleared and the faces were only re-applied to the point at which the syntax error was.

Using after-change-hook and immediately clearing ts-changed-ranges and then re-applying the faces according to the query results is correct

Yes, this sounds like the right approach to me; you should always be able to highlight based on the current syntax tree, regardless of whether there's a syntax error or what. That's what Atom does. There should be no need for any state besides the tree itself.

however as soon as your code has syntax errors in it (which happens often during editing), a really large region of text was cleared

I'm curious about this. Syntax errors shouldn't cause noticeable problems for syntax highlighting. If they are, you might be hitting a bug in the query system, or a parsing bug. What language are you using? What highlights are you seeing? If you get a chance, could you try to reproduce the problem with the tree-sitter command line tool, either via tree-sitter parse, or tree-sitter web-ui?

I'm curious about this. Syntax errors shouldn't cause noticeable problems for syntax highlighting. If they are, you might be hitting a bug in the query system, or a parsing bug. What language are you using? What highlights are you seeing? If you get a chance, could you try to reproduce the problem with the tree-sitter command line tool, either via tree-sitter parse, or tree-sitter web-ui?

@maxbrunsfeld
I'm fairly certain this isn't a bug but rather my fault, however I wasn't (and still am not) sure how to do this correctly. This was basically the code in question:
(defun tree-sitter-highlight--handle-change (change)
  "Called for each CHANGE after an edit."
  (let* ((start-byte (aref change 0))
         (end-byte   (aref change 1))
         (node       (ts-get-descendant-for-byte-range (ts-root-node tree-sitter-tree) start-byte end-byte))
         (matches    (ts-query-captures tree-sitter-highlight--queries node tree-sitter-highlight--query-cursor nil #'ts-node-text)))
    (set-text-properties (ts-node-start-position node) (ts-node-end-position node) nil)
    (seq-do #'tree-sitter-highlight--apply-match matches)))

(defun tree-sitter-highlight--after-change (old-tree)
  "Called with the OLD-TREE after the buffer has changed."
  (let* ((changes (ts-changed-ranges tree-sitter-tree old-tree)))
    (seq-do #'tree-sitter-highlight--handle-change changes)))

As far as I can remember, this worked well (it was always correct), however was rather slow since on (some) syntax errors in rust (which I tested this most on since I was mostly writing rust) the ts-get-descendant-for-byte-range would return the whole buffer or most of the buffer, which resulted in a noticeable slowdown (at least on my fairly old processor) while typing. Thus I tried implementing that in Rust, however that also didn't speed things up too much (maybe emacs isn't too fast with removing and applying faces on these large ranges). I then tried various ways of somehow only highlighting the visible region, but most of them were broken in one way or the other (i.e. after some amount of editing all of them resulted in a region of code always being unhighlighted), this was also my fault.
The syntax errors do not (as far as I noticed) cause any errors in the tree that propagate too far or result in broken queries etc, but they caused me (since I don't know of a better way) to re-highlight most of the buffer most of the time, which was slow. I do not know how to correctly determine which part I should clear and run queries on after changes, that do not result in the whole buffer being rehighlighted on some syntax errors. I've also tried looking at how atom does this but couldn't really find anything.

@th0rex Thanks for the reply.
I haven't checked how this is exposed to elisp, but I would think that you could use one of these APIs to confine your query to the visible screen range, so that they query would not take too long.
And then, on top of that, I think you could cache the result of highlighting individual lines, and invalidate/splice that cache based on the ts-changed-ranges. That way, for a given frame, you would only run the query on code that is both:

not yet cached
on screen

I'm not familiar with the emacs APIs, so there might be some details that make this difficult that I'm not taking into account.

Ok so I've just retried this, now using the "proper" (I think) way to determine what's visible after scrolling took place. Even without caching the performance (in pure lisp now) seems to be a lot better, and it also seems to always correctly highlight now. I don't really remember why I didn't do this the first time but seems like I should have. Thanks @maxbrunsfeld
I'll still eventually implement caching however.
I've also "rebased".

Just a quick update: I've rebased on the latest master again, cleaned up the code, fixed two other bugs (although this makes scrolling slower now, but its fine if the file is byte compiled) and added changes suggested Stefan Monnier.

Is it possible to use the compiled language binaries (eg. python.so) instead of the .scm file for highlighting? More generally, is it possible to combine both functions to use the same set of language specifications? It seems like a possible redundancy to distribute both scm and so files in the eventual future of this package.

The .so files are parsers, and the .scm files are "tree queries" that specify how syntax highlighting should be applied to the syntax tree. They serve two different purposes, and I think both are needed for syntax highlighting.

Thanks for clarifying, I figured that was the case.

I've now switched to using font-lock again (as per the suggestion of Stefan Monnier), however there are still lags for large buffers where ts-changed-ranges or
ts-get-descendant-for-position-range return a range spanning the whole buffer, but it still is at least always correctly highlighted now. This has nothing to do with font-lock however, and I'm absolutely not sure how to fix this. I can reliably makets-changed-ranges produce the whole buffer as a range by just inserting a ( in one rust source file at line ~1000 of ~1500, and I don't really have the time to find out how to work around that. Everything I've tried is either incorrect or slows down in that file (it's not some kind of stress test file btw, just one of the only ones where I've noticed it until now).
Initially I thought tree-sitter would somehow always emit only "small" changed ranges
(I didn't expect to have to implement caching on top of tree-sitter and thought it would only emit "small" updates when possible, instead of wanting to re-query all 1500 lines). I know this is a hard problem to solve and I don't mean to shit on the tree-sitter devs, but like I said I currently do not have any more time for this.
If anyone wants to continue this work, they're free to use all my code (if it's useful anyway) in any way they'd like. Like I said, the highlighting with font-lock should at least always be correct now, but may be slow for some files while doing some edits. Maybe this is also a problem with how the grammar is specified and not with tree-sitter itself and it would be working perfectly with other files, or I'm still using tree-sitter wrong, I'm not sure.

I think the solution would be to only highlight ranges that are both: 1. changed and 2. on screen.

I've tried that in many different variations, the problems were always with things like
r#"

// screen becomes visible here, because we scrolled down

// we new close the raw string literal:
"#;

As far as I can see I need to run the query on the whole buffer to highlight that correctly. Running the query on the window doesn't produce highlights for the raw string literal (I guess because the whole node isn't contained in the window?).

@th0rex Thank you for all your hard work experimenting with this!
I'm sorry to bother you with one more request. I understand that you are frustrated and don't want to work on this anymore. I just want to get more info to continue on this. Can you send me these:

The example Rust file with the issue, and the location to insert (. I get the same behavior on one of the project's files, but I want to have as similar a starting point as possible.
The patches that Stefan sent you.
If possible, the code you tried to limit the ranges to rehighlight.

Running the query on the window doesn't produce highlights for the raw string literal (I guess because the whole node isn't contained in the window?).

I think extending the window range a bit with ts-get-descendant-for-position-range  should work.

It is kind of slow, maybe it's also the interop between rust and emacs

This is an issue with Emacs dynamic's modules in general, more so with the Rust binding (because it includes a workaround for a safety bug in Emacs's GC, which will supposedly be fixed in Emacs 27). Calling ts--query-cursor-matches with index-only seems to be significantly faster in my quick test. I'll try making it return indexes and byte offsets only: no capture names, no nodes.

The example Rust file with the issue, and the location to insert (. I get the same behavior on one of the project's files, but I want to have as similar a starting point as possible.

Sadly I can't since it's from a project for work.

The patches that Stefan sent you.

https://gist.github.com/th0rex/64a48204f5129c0cd293bd90932bd018
That patch didn't work immediately, but the current state of this PR should be similar enough to it.

If possible, the code you tried to limit the ranges to rehighlight.

https://github.com/th0rex/emacs-tree-sitter/blob/only_hl_visible_query_reported/lisp/tree-sitter-highlight.el
It does some maybe hacky things related to the issue with multiline string literals I mentioned above, doesn't use font-lock and in my testing also was always correct, but it still lags for those certain edits.

Calling ts--query-cursor-matches with index-only seems to be significantly faster in my quick test. I'll try making it return indexes and byte offsets only: no capture names, no nodes.

If this would indeed fix it, it would be very nice.
Thank you for looking into this as well.

Running the query on the window doesn't produce highlights for the raw string literal (I guess because the whole node isn't contained in the window?).

That's surprising to me. That's not the intended behavior of  ts_query_cursor_set_byte_range and ts_query_cursor_set_point_range, and it's not the behavior that I see in the web playground. The TSQueryCursor is supposed to return matches for any nodes that overlap the specified range.
It sounds like you're hitting a bug in Tree-sitter, or the Tree-sitter rust binding maybe? If anyone is interested and has time, it would be great to get a reproducible bug report for this.

I'm continuing the work here.
I'm using it locally, and haven't noticed any slowdown so far. It feels than font-lock-mode sometimes.
Here are the updates to some of the previous issues.
The main slowness was due to the highlighting code adding the same face multiple times. As a result, the face attribute becomes a very long list. Emacs's display is very slow when this happens.

I can reliably make ts-changed-ranges produce the whole buffer as a range by just inserting a (

I got this with Rust code as well. It seems specific to the Rust grammar. I could never reproduce it in C code. Scoping the queries to the invalidated regions (roughly the visible region) works for me though.

Running the query on the window doesn't produce highlights for the raw string literal (I guess because the whole node isn't contained in the window?).

I couldn't reproduce this. I did get large chunks of text not being fontified, but the cause turned out to be the intricate interactions between Emacs's font-lock and jit-lock. These interactions are gnarly and poorly documented, probably because they have been effectively "internal" for so many years. For example, returning (jit-lock-bounds beg . end) is the correct way, not setting 'fontified directly.

That's surprising to me. That's not the intended behavior of ts_query_cursor_set_byte_range and ts_query_cursor_set_point_range, and it's not the behavior that I see in the web playground. The TSQueryCursor is supposed to return matches for any nodes that overlap the specified range. The nodes shouldn't need to be fully contained by the range.

This is the behavior I've observed so far (no full containment needed). However, I did get some other interesting cases involving ts_tree_get_changed_ranges and ts_query_cursor_set_point_range. They are very edge cases though, as they happen for queries more complex than those currently used in the language repos. One of them seems to be triggered by a specific bug in the Rust grammar.  I'm still investigating them, and will open an issue on tree-sitter later.


PHP 7.2 compatibility

Is PHP 7.2 supported?

See #115

cc @hlu2

@josephzidell It is supported. Thanks


STRONG BUY priority

I'm currently configure my monitoring for 1m/15 candles and TradingView summary of 1h (I'm not sure if this is the best configuration for making profits), when it bought something in STRONG BUY, I really gained the profit in short period, but TV would give STONG BUY signals once in a while, if I only check for buy STRONG BUY only, it will need to wait until a STRONG BUY appears, so I think there should be a priority feature, if there are some STRONG BUY signals, wait for their price to reach the the trigger price first and buy them, then buy the normal BUY signals when there are no STRONG BUY left.

@bangbaew
If your issue is answered, please close the issue.


[graphiql] Upgrade to @graphiql/react breaks unit tests

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
We are getting the error
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
 - /local/myproject/node_modules/@graphiql/react/src/utility/context.ts:24:58
 - /local/myproject/node_modules/@graphiql/plugin-explorer/dist/index.js:1:2531
 - /local/myproject/node_modules/react-dom/cjs/react-dom.development.js:16305:18
 - /local/myproject/node_modules/react-dom/cjs/react-dom.development.js:20074:13
 - /local/myproject/node_modules/react-dom/cjs/react-dom.development.js:21587:16
 - /local/myproject/node_modules/react-dom/cjs/react-dom.development.js:4164:14
 - /local/myproject/node_modules/happy-dom/src/event/EventTarget.ts:223:42
 - /local/myproject/node_modules/happy-dom/src/nodes/element/Element.ts:1171:29
 - /local/myproject/node_modules/happy-dom/src/event/EventTarget.ts:132:9
 - /local/myproject/node_modules/happy-dom/src/nodes/element/Element.ts:1171:29

We had previously been using
"@graphiql/plugin-explorer": "1.0.3",
"graphiql": "3.1.0",

Upon upgrading our packages, @graphiql/plugin-explorer upgraded to 1.0.4 and @graphiql/react to 0.20.4, the above error started occurring.
Expected Behavior
Out tests were previously been passing so I would expect them to continue with no changes
Steps To Reproduce
Open this environment
https://stackblitz.com/edit/vitejs-vite-kkpoqd?file=vite.config.ts
Run npx vitest.
Environment

GraphiQL Version: 3.1.0
OS: Linux
Browser: N/A
Bundler: ESBuild
react Version: N/A
graphql Version: 3.1.0

Anything else?
No response

Hi, did you ever resolve this issue? What versions of graphiql/react, graphiql, and graphiql/plugin-explorer don't cause this issue?

Oops never mind! Just use the versions of graphiql and graphiql/plugin-explorer above and upgrade graphiql/react to 0.22.4. That worked for me.


Tensorborad show Learning rate on every batch

First:
class LRTensorBoard(TensorBoard):
    # add other arguments to __init__ if you need
    def __init__(self, log_dir, **kwargs):
        super().__init__(log_dir=log_dir, **kwargs)

    def on_epoch_end(self, epoch, logs=None):
        logs = logs or {}
        logs.update({'lr': K.eval(self.model.optimizer.lr)})
        super().on_epoch_end(epoch, logs)

    def on_batch_end(self, batch, logs=None):
        logs = logs or {}
        logs.update({'lr': K.eval(self.model.optimizer.lr)})
        super().on_batch_end(batch, logs)

And Then when train:
callbacks = [
            LRTensorBoard(log_dir='./logs', histogram_freq=1, update_freq="batch")]
model.fit(..., callbacks=callbacks)

Last:

there's not batch_lr. why?
Thanks

@yajunDai,
To expedite the trouble-shooting process, could you please provide a complete code snippet and the TensorFlow version you are using. Thank you!

@yajunDai,
Code shared is full of indentation errors, please share a colab gist with issue reported or simple stand alone indented code with all dependencies such that we can replicate the issue reported. Thank you!


Extra digit on iPhone

card number:
When typing e.g. 5100 on iPhone (chrome, safari)
The result will be 5100 0 (the 4th digit is entered twice)
update:
fixed in PR by @jribble

Same issue here on iPad. Chrome or Safari.

Looks merged and fixed in 1.2.4 to me.

I think it should be closed, as commented by @gavmck updating library resolves issue


Disable issues in the odh-manifests repo and redirect users to the odh-community issues repository

Originally the odh-manifests repo was the source of truth for every component that was deployed in ODH since we defaulted to the Kubeflow model of using a single forked gitops mono-repo to customize and deploy all of the ODH components.  Now that each ODH component has it's own repo under opendatahub-io, the operator has been redesigned and we are using the opendatahub-community/issues board as the initial issue tracking board tracking issues in odh-manifests has been made obsolete and redundant.
We need to disable issues in odh-manifests and redirect all Open Data Hub issues to  opendatahub-community/issues as the unified.  Any feedback (bugs, features, ...) with ODH deployment or installation, should be tracked in opendatahub-operator/issues.  Other issues related to component functionality will be redirected to opendatahub-community/issues or the affected component.
Additional Info
GitHub supports linking issues to pull requests across repositories in an org.  So there is no loss of builting GitHub issue automation when specifying that a PR in repository ABC Closes opendatahub-io/repository-XYZ#789
See Linking a pull request to an issue using a keyword

All issues filed in odh-manifest have been disabled or transferred to appropriate repos where appropriate.
The odh-manifests repo will be archived (#117) when opendatahub-io/opendatahub-operator/issues/338 is complete as there will be no need to have a dedicated repository for kustomize manifests


Issue#60

Add Address info to FHIRPatientAdapter

Please fix mapping district => county, and create a new pull request.


Don't show RBR if workspace is archived

Details

If there is a expense error but the workspace is archived, we don't want to show the RBR.
Fixed Issues

$ https://github.com/Expensify/App/issues/50573
PROPOSAL: https://github.com/Expensify/App/issues/50573#issuecomment-2405603382
Tests

Same as QA Steps

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

Offline tests

Same as QA Steps
QA Steps

Open a workspace chat
Submit an expense that will show RBR (for example scan expense with a random image)
Delete the workspace
Verify the workspace chat doesn't show RBR anymore

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

PR Author Checklist

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

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

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

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

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

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

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

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

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

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

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

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/user-attachments/assets/9cdccff7-b664-478c-8083-703216944432

Android: mWeb Chrome

https://github.com/user-attachments/assets/ba1b548b-a665-41a5-a945-91a4901b96f3

iOS: Native

https://github.com/user-attachments/assets/6a6bd9f2-919e-413c-b0f2-307cb0268287

iOS: mWeb Safari

https://github.com/user-attachments/assets/feeb5562-771a-46c0-8606-8163f8baf26d

MacOS: Chrome / Safari

MacOS: Desktop

@allgandalf done

I didn't include the focus mode because it's not required to repro the issue, unless I misunderstood something.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.


Travis build broken

https://travis-ci.org/pclausen/fortran/builds/658030086?utm_medium=notification&utm_source=email
Not quite sure what is going wrong here... Seems to be something more central to the travis script. Fortran files build and execute succesfully.
gzip: stdin: not in gzip format

tar: Child returned status 1

tar: Error is not recoverable: exiting now

The command "bin/fetch-configlet" exited with 2.

0.00s$ bin/configlet lint .

/home/travis/.travis/functions: line 109: bin/configlet: No such file or directory

The command "bin/configlet lint ." exited with 127.

Over in the Python repo we’re working on a Python-based drop-in replacement for the fetch-configlet script that will back off when the API endpoint is rate limited... I’m still not totally sure that’s the problem on the server end, but it should help.
Wait to see our experience once we’ve merged https://github.com/exercism/python/pull/2186... bit of that works we may want to replace the original bash script in all the tracks that use it.


Update sbt-scoverage to 2.2.2

About this PR
📦 Updates org.scoverage:sbt-scoverage from 2.2.1 to 2.2.2
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scoverage", artifactId = "sbt-scoverage" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scoverage", artifactId = "sbt-scoverage" }
}]

labels: sbt-plugin-update, early-semver-patch, semver-spec-patch, commit-count:1

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 48.19%. Comparing base (08a3e1a) to head (6b5c013).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #599   +/-   ##
========================================
  Coverage    48.19%   48.19%
========================================
  Files            5        5
  Lines           83       83
  Branches         6        6
========================================
  Hits            40       40
  Misses          43       43

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


Don't log unimportant messages when verbose logging is off

Please explain the suggested feature in detail.
Disable the logging of unimportant messages such as "Transport initialized" or "Server: Start port=...". So far I have not seen an option to hide these messages other than manually editing the source.
How exactly does this keep you from releasing your game right now?
It doesn't; But makes paying attention to actual important messages harder as the console is pretty much spammed with these logs.
Can you suggest a possible solution?
Moving these logs to inside Verbose level.

I second this. Every new build I go and comment all the debug statements in Telelpathy Transport out.

This was addressed with the new logging system.


Fix error message for "User is not permitted to upload files"

Bug: Currently if the user doesn't have permission to upload files to lib.reviews, it incorrectly gives the following error
There was a problem completing the requested action, sorry! This may be an Internet connection issue, or a coding error on our end.

Problem
If a user that doesn't have permission to upload a file attempts to upload a file, then the website UI gives them a misleading error message.
But, in fact, if you open the browser debugger then you can see a request to upload the file to https://lib.reviews/api/actions/upload returned a 400 error with the following  JSON response
{"message":"Could not perform action.","errors":["User 'maltfield' is not permitted to upload files."]}

Steps to reproduce

Create a new user (by default, it seems, new users don't have upload permission)
Create a new review
Click on the "Rich Text" tab of the Review input textarea
Click the Upload and insert media button
Click Select file
Choose a file
Enter something text into the description input textarea
Check the box that says This file is my own work. I agree to release it under the CC-BY-SA license.
Click Start upload

Solution
If the server returns an error because the user doesn't have permission to upload the files, then the UI should output an error message that very clearly indicates that this is a permission issue.
Ideally, it would literally include the contents of the errors key that's returned by the server. For example, the UI should say
User 'maltfield' is not permitted to upload files.

Ah, good catch - you're exactly right, by default new users aren't marked as trusted yet, and this is a case that isn't handled yet. Will poke.
BTW, your own account has been marked as trusted for a while, so you should no longer be hitting this.

I figured it'd be nicer to just hide the button (as we do for the other upload button) until the user is trusted, so they don't try to upload only to be hit by an error message. So that's what I've done for now.


Add faucet bot filter

This PR fix #14

@hoonsubin Please review again :)

@hoonsubin thank you for your comment. I quickly fixed it, so review it again please 👍

@y-shijo the linter and formatter seem to be strange. I'll format the code


Removing css overrides from non responsive templates

Removing css overrides from non responsive templates
Testing

Visit http://localhost:8000/practitioner-resources/students/ and verify the menu isn't huge.
Visit http://localhost:8000/fair-lending/ and verify the menu isn't ginormous.

Screenshots
Notes

Todos

Checklist

[ ] PR has an informative and human-readable title
[ ] Changes are limited to a single goal (no scope creep)
[ ] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the development playbook
[ ] Passes all existing automated tests
[ ] Any change in functionality is tested
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged / future todos are captured in comments
[ ] Visually tested in supported browsers and devices (see checklist below :point_down:)
[ ] Project documentation has been updated
[ ] Reviewers requested with the Reviewers tool :arrow_right:

Testing checklist
Browsers

[ ] Chrome
[ ] Firefox
[ ] Safari
[ ] Internet Explorer 8, 9, 10, and 11
[ ] Edge
[ ] iOS Safari
[ ] Chrome for Android

Accessibility

[ ] Keyboard friendly
[ ] Screen reader friendly

Other

[ ] Is useable without CSS
[ ] Is useable without JS
[ ] Flexible from small to large screens
[ ] No linting errors or warnings
[ ] JavaScript tests are passing

Does this mean we can delete nemo/_/c/v1-nonresponsive-header.css and nemo/_/c/v1-nonresponsive-footer.css too?

Does this mean we can delete nemo//c/v1-nonresponsive-header.css and nemo//c/v1-nonresponsive-footer.css too?

maybe, I need to make sure there isn't some external template depending on it.


Directly rewrite filters on RHS join columns into LHS equivalents

This PR allows JoinFilterAnalyzer to directly rewrite filters on RHS join columns into filters on the equivalent LHS join columns, allowing these filters to be pushed down to base tables.
To supports this two new methods are added to Filter:

supportsRequiredColumnRewrite
rewriteRequiredColumns

These methods are used to pass a map of column name rewrites to a Filter, which the Filter will use to return a copy of itself that operates on different columns.
Current restrictions on such rewrites:

Only filters that reference a single column currently support such rewrites
Expression, Javascript, AND/OR, and Spatial filters are not currently supported

For expression and javascript rewrites, we would need a good way to replace the identifiers for the new filter

This PR has:

[x] been self-reviewed.
[ ] added documentation for new or modified features or behaviors.
[x] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[ ] added or updated version, license, or notice information in licenses.yaml
[x] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[x] added unit tests or modified existing tests to cover new code paths.
[ ] added integration tests.
[ ] been tested in a test Druid cluster.

I think it's a little hard to follow what's going on in JoinFilterAnalyzer, the class is now up to 1000+ lines, could you re-structure it into smaller classes that are linked to each other to make it a little easier to understand the dependencies / flow in the class.

I definitely agree that's a good idea, I'll do that in a follow-on PR though, since I find that including such refactors in a PR together with functional changes makes it hard to identify the functional changes.

I'm curious why the value type is Optional vs just treating nulls as missing keys. Are Optional.absent() and null values (missing keys) treated in different ways?

Hm, using Optional was pointless there, I adjusted to just use null here


Autosuggestbox border is blurry with a shadow effect

Describe the bug
Have a close look at the Autosuggestbox:

Steps to reproduce the bug
<AutoSuggestBox PlaceholderText="Search" QueryIcon="Find">
    <AutoSuggestBox.Resources>
        <SolidColorBrush x:Key="TextControlBorderBrush" Color="Red" />
    </AutoSuggestBox.Resources>
</AutoSuggestBox>

Expected behavior
Why is there a shadow? I've also tried setting the border to 1px, but that does not help.
Version Info
WinUI 2.4 for UWP
I've also installed the nuget package for winui 2.5, but it seems Autosuggestbox is not available in this package (why?)
https://github.com/microsoft/microsoft-ui-xaml/blob/release/2.4/dev/AutoSuggestBox/AutoSuggestBox_themeresources.xaml

The problem is that the rounded border gets blurred. This is tracked by #4021. Closing as a dup of that issue.
Note: this issue has been fixed for a future version of Windows, and will also be fixed in WinUI 3.


[Localization] Improve French translation

Summary of the Pull Request
What is this about:
Remove extra space before extension name
Before --> ( .pdf)
After --> (.pdf)

What is included in the PR:
Remove extra space before extension name
How does someone test / validate:
GitHub actions will do the test.
Quality Checklist

[X] Linked issue: #15008
[ ] Communication: I've discussed this with core contributors in the issue.
[ ] Tests: Added/updated and all pass
[ ] Installer: Added/updated and all pass
[X] Localization: All end user facing strings can be localized
[ ] Docs: Added/ updated
[ ] Binaries: Any new files are added to WXS / YML

[ ] No new binaries
[ ] YML for signing for new binaries
[ ] WXS for installer for new binaries

Contributor License Agreement (CLA)
A CLA must be signed. If not, go over here and sign the CLA.

Sadly will have to close this out. Loc has to go through an Internal system


Is this on purpose?myTransforms.Scale(1280, 720) not (1280,640)

Hi,
I notice that the code below, and am wondering whether the scale 720  is on purpose (not 512*1.25)
train/main.py: https://github.com/sacmehta/ESPNet/blob/afe71c38edaee3514ca44e0adcafdf36109bf437/train/main.py#L227
trainDataset_scale2 = myTransforms.Compose([
myTransforms.Normalize(mean=data['mean'], std=data['std']),
myTransforms.Scale(1280, 720), # <<<<<<<<<< 512*1.25 == 640 ?
myTransforms.RandomCropResize(100),
myTransforms.RandomFlip(),
#myTransforms.RandomCrop(64),
myTransforms.ToTensor(args.scaleIn),
#
])

There is no specific reason behind this choice. We just selected it to have 720p resolution.


Integration of ImPlot, ImNodes and ImGuizmo

This PR adds support for ImPlot(#191), ImNodes(#201) and ImGuizmo(#200).
What has been done:

Added ImPlot.NET, ImNodes.NET and ImGuizmo.NET projects
Modified CodeGenerator to generate code for cimplot, cimnodes and cimguizmo
Added definition files from cimplot, cimnodes and cimguizmo
Added ImPlot demo window to sample program

Until now I only did minimal testing. Binaries including cimplot, cimnodes and cimguizmo are missing. For testing I manually compiled a cimgui.dll including cimplot. I am not sure if you prefer one binary including all projects or separate binaries.
Please let me know what you think about this PR. Feel free to change this PR in any way that is necessary to include it. If you need me to change anything let me know.

This is fantastic stuff, thanks for putting this together @TillAlex. I definitely want to support this in some form, and in general most of the changes here look reasonable.
One question is how the native portions should be organized and delivered. As far as I can tell, all of these libraries are intended to be compiled and included together in a single native DLL. That's obviously possible here as well based on your testing, but it would be better if we could separate them out into 4 dynamic libraries (libcimgui, libimplot, libimnodes, and libimguizmo). This would allow users of ImGui.NET alone to avoid including extra libraries that they aren't interested in.
The new libraries would need to be built against a particular version of libcimgui (and thus would need to be used w/ a particular version of ImGui.NET), but I can't think of any technical reason why this wouldn't work. Functionally, this would mean expanding ImGui.NET-nativebuild to cover the new libraries, in a way that produced 4 compatible dynamic libs from source.
Long-term, I'd like to see the extra libraries moved out of this repo into separate ones, but I don't feel very strongly about that initially. The fact that all of them will need CodeGenerator means that a larger restructuring would be needed for that to work. Along these lines, it would be nice if CodeGenerator was a little less aware of the quirks of each individual project (e.g. now it knows about things like ImPlotContext specifically). CodeGenerator is filled with its fair share of hacks, a lot of this could probably be cleaned up and fixed at the same time. It would be great if CodeGenerator could be used as a utility for any cimgui-based library without needing tons of modifications to it.

Thanks for your comments!
On 1) I think you are totally right that split native libraries are the better solution and it shouldn't be to complicated to integrate that into  ImGui.NET-nativebuild. I am not a cmake pro, but I will give it a try.
On 2) I understand your point about ImNodes, but I also think it's sad not to have a nodes editor for ImGui.NET. Perhaps we should just generate wrappers for all the cimxxx projects so that the user can choose from at least two of the three nodes editors. If @sonoro1234 decides to include imgui-node-editor as well we can add that as well.
Hopefully I will find some time this evening to work on some of the points from your comments.

Hi Allex,
could you please provide your pre-build native libs? I would love to test this but don't want to spent to much time on building the native libs :).
Best regards,
//cbaal

@cbaal83 Here are x64 binaries I just built: binaries.zip
Included are separate binaries of the current versions of cimgui, cimplot, cimnodes and cimguizmo. I changed this PR to work with these. Until now I only tested the demo window of ImPlot used in ImGui.NET.SampleProgram. It works as long as you replace the original cimgui with the one in the zip, because cimplot.dll is built against ImGui 1.79.
I am not sure if my way of building separate binaries is correct. Let me know if they work for you.

@TillAlex
Thank you very much! Will test today! If something is buggy i will post it here.
//cbaal

at ImGuiNET.ImPlotNative.ImPlot_BeginPlot(Byte* title_id, Byte* x_label, Byte* y_label, Vector2 size, ImPlotFlags flags, ImPlotAxisFlags x_flags, ImPlotAxisFlags y_flags, ImPlotAxisFlags y2_flags, ImPlotAxisFlags y3_flags)
at ImGuiNET.ImPlot.BeginPlot(String title_id, String x_label, String y_label) in S:\Dev\github\ImGui.NET\src\ImPlot.NET\Generated\ImPlot.gen.cs:line 377
at ImGuiNET.SampleProgram.XNA.SampleGame.ImGuiLayout() in S:\Dev\github\ImGui.NET\src\ImGui.NET.SampleProgram.XNA\SampleGame.cs:line 84
at ImGuiNET.SampleProgram.XNA.SampleGame.Draw(GameTime gameTime) in S:\Dev\github\ImGui.NET\src\ImGui.NET.SampleProgram.XNA\SampleGame.cs:line 63
at Microsoft.Xna.Framework.Game.DoDraw(GameTime gameTime)
at Microsoft.Xna.Framework.Game.Tick()
at Microsoft.Xna.Framework.SdlGamePlatform.RunLoop()
at Microsoft.Xna.Framework.Game.Run(GameRunBehavior runBehavior)
at ImGuiNET.SampleProgram.XNA.Program.Main(String[] args) in S:\Dev\github\ImGui.NET\src\ImGui.NET.SampleProgram.XNA\Program.cs:line 7

I have just added thoose 2 lines to the XNA SampleGame on line 84
ImPlot.BeginPlot("Testplot", "x", "y");
ImPlot.EndPlot();

I've also tested Implot.CreateContext() and implot.SetImGuiContext() (inside ImguiRenderer ctor), doesn't work.
Do i miss something obvious here?
//cbaal83

Just tested the same and it works. Found two potential problems you could be running into:

I had to add the following to ImGuiRenderer after line 46:
IntPtr implotContext = ImPlot.CreateContext(); ImPlot.SetCurrentContext(implotContext); ImPlot.SetImGuiContext(context);

Be sure to use the cimgui.dll I provided. It tends to be replaced every time you build.

Yep, i haven't done all three together. It's working now :).
Will test now! Thanks!
//cbaal

Ok, quick question:
How iam supposed to pass in the values? All of them accepting a "ref float" value, which should be an array.
I tried passing a pointer to it, still doesnt work like so:
                        ```

var min = typed.Min(x => x.Price);
var max = typed.Max(x => x.Price);
var avg = typed.Average(x => x.Price);
float[] value = new float[] { min, max, (float)avg };
unsafe
{
fixed (float* ptr = value)
{
ImPlot.PlotBars("values", ref *ptr, 3);
                            }
                        }

Another issue:
Even if i pass in a single value like so:
ImPlot.PlotBars("min", ref min, 1);
Value of that bar is always 1 (min is NOT 1 ;) ).
I have the feel iam doing something wrong here :D.

Sorry!

I can not check at the moment if this works, but you can try
ImPlot.PlotBars("values", ref value[0], 3);

Both works, the safe and unsafe way.
I was missing the following piece:

@TillAlex
Im missing some functions which are defined in implot_internal.h:
Implot.BeginItem
Implot.EndItem,
Implot.GetCurrentItem,
Implot.FitThisFrame,
Implot.FitPoint
which are necessary for custom graphs.
Any chance you add them?
//cbaal

@cbaal83 As far as I understand cimplot does not wrap the internal api of implot. @sonoro1234 Is this correct?

@cbaal83 As far as I understand cimplot does not wrap the internal api of implot. @sonoro1234 Is this correct?

Yes.

@sonoro1234
Any chance implot_internal will be added?

https://github.com/cimgui/cimplot/tree/internal just added
Main problem for using it is time_t being long in 32bits and long long in 64bits

@TillAlex Mind helping me getting these to work with viewports?
I have a fork here in which I've managed to get viewport working, and I can call the initialization functions (for instance ImNodes.Initialize() or ImPlot context creation and setup), but if I try to actually draw anything from the extensions (i.e. Implot demo window) the application crashes due to access violation, so I maybe the context isn't being generated correctly?
I am using the binaries you shared, so maybe it's missing something specific to viewports. I also tried compiling my own dlls, but I have little knowledge of c/c++, so I think I may have screwed up somewhere and couldn't get it to work
Any help would be deeply appreciated!

@bootzin Looking at your branch I found that you added cimplot.dll, cimnodes.dll and cimguizmo.dll, but did not replace cimgui.dll with the one I shared. This is a problem, because the libraries I shared are built against ImGui 1.79, but the DLL from ImGui.NET ist 1.78. Not replacing cimgui.dll results in access violations during my tests.
If you need to build your own DLLs have a look at https://github.com/mellinoe/ImGui.NET-nativebuild/pull/3. This PR adds a CMake file for building all four libraries.

That was silly of me, I was sure I was using the one you provided...
Anyway, I changed it and pushed it, and now ImPlot works just fine, but I'm still getting access violations when calling either ImGuizmo.BeginFrame() or ImNodes.BeginNodeEditor()

ImNodes.BeginNodeEditor()

Did you called imnodes_EditorContextCreate() before?

Not directly, but I've called ImNodes.Initialize(), which creates and sets the editor context

@sonoro1234 , I just pushed a fix for AddTicksTime https://github.com/epezent/implot/commit/24b543839be2761a0a8d1b764f7527dccf6060a8. Was there anything else specifically you wanted me to look at?

@bootzin I am not sure about this, but the problem could be, that the ImGui context is not explicitly passed to ImNodes and ImGuizmo. This works as long as they are compiled together in a single library, but not for separate libraries (https://github.com/ocornut/imgui/issues/3169).
There are two solutions to this problem: Pass the context implicitly (like it is done in ImPlot) or compile into a single library.

Btw @TillAlex and others, this is awesome work! I'm really excited to see this get merged.

Was there anything else specifically you wanted me to look at?

@epezent All is for wrapping implot_internal (which I am not sure if is really necessary)
The other issue is that being LabelTickTime seems to be a problem in linking (https://github.com/mellinoe/ImGui.NET/pull/218#issuecomment-736482969)

There are two solutions to this problem: Pass the context implicitly (like it is done in ImPlot) or compile into a single library.

@TillAlex  I see.. I've asked the authors to expose a method that allow setting the imgui context, but since there's no such thing right now, I guess the only way to get it to work would be compiling into a single dll
That complicates things a little bit regarding this PR though, right? Considering neither ImGuizmo nor ImNodes work as is, and @mellinoe doesn't want them compiled into a single dll...
Maybe having separate branches?

compiled into a single dll...

This is what is done in LuaJIT-ImGui. Avoids also problems mixing dll for different imgui versions

ImGuizmo has already merged the change:  https://github.com/CedricGuillemet/ImGuizmo/issues/146

Managed to get everything working in my branch. Essentially, I just included the SetImGuiContext function in each library and regenerated the necessary files. Did some preliminary testing, and so far everything seems to be working just fine, so if we want to have separate dlls, this seems to be the way to go

Was there anything else specifically you wanted me to look at?

@epezent All is for wrapping implot_internal (which I am not sure if is really necessary)
The other issue is that being LabelTickTime seems to be a problem in linking (#218 (comment))
undefined reference to ImPlot::LabelTickTime(ImPlotTick&, ImGuiTextBuffer&, ImPlotTime const&, ImPlotDateTimeFmt)'`

I removed the inline in the source file (not sure why that was there). Should be good to go.

I removed the inline in the source file (not sure why that was there). Should be good to go.

@epezent Thanks for that. Do you think that exposing implot internal is a good choice?

I removed the inline in the source file (not sure why that was there). Should be good to go.

@epezent Thanks for that. Do you think that exposing implot internal is a good choice?

If it doesn't require a lot of effort to setup or maintain the binding for it, sure why not? Sounds like imgui_internal is available, so I think it's fine.

implot internal already generated
If Nelarius/imnodes dont have SetImGuiContext I could manually add it to cimnodes.

@mellinoe let me know if you want me to:

Remove ImNodes
Add the other cim* projects as well
Leave everything as it is

I will add the built libraries from ImGui.NET-nativebuild as soon as there is a SetContext method for ImNodes as well or we decide to drop ImNodes.
Anything else that has to be done before accepting this PR?

Hm, I'm having some issues with it. It's most likely due to the fact I'm running it on Unity, but whenever I try and use ImPlot, i get an access violation. ImGui works perfectly fine, but the second I try and call ImPlot, crash. Am I missing something here?
                IntPtr implotContext = ImPlot.CreateContext();         ImPlot.SetCurrentContext(implotContext);         ImPlot.SetImGuiContext(ImGui.GetCurrentContext());         ImPlot.ShowDemoWindow(ref _showImPlotDemoWindow);

Are you sure you are using the cimgui.dll compiled together with your cimplot.dll? Mixing a cimplot.dll compiled against a different version of imgui than cimgui.dll usually results in access violations.

I took the precompiled binaries from your post earlier, where they're seperate dlls. Should I compile them myself?

You do not have to compile them yourself, but you  really have to make sure you are using the precompiled cimgui.dll and the cimplot.dll. The compiler tends to replace cimgui.dll with the one from the repository during compilation.

Alright, I got it working! Thank you all so much!

What was the problem? Wrong DLL?

Yeah, wrong dll. I had forgotten to replace it. Took some more tweaking with the Unity ImGui package I was using after that, but I've never been so happy to see a graph in my life. Thanks a ton for this PR man, truly appreciated!

Any progress on this?
tables was just merged into imgui master branch, seems like a good time to upgrade :>
Thank you for all your work, this is awesome!

Any progress on this?
tables was just merged into imgui master branch, seems like a good time to upgrade :>
Thank you for all your work, this is awesome!

Hey guys
Just an update on this: Nelarius updated imnodes recently to include the SetImGuiContext() function, so we should probably be able to merge this in now without too much trouble

cimplot wraps implot_internal by default now

Nelarius updated imnodes recently to include the SetImGuiContext()

cimnodes also regenerated

Cimgui 1.82 generated

Recent native libraries can be found in the AppVeyor build artifacts of mellinoe/ImGui.NET-nativebuild#3.

Awesome :D Thank you!

It seems that I took the non docking definitions.json. Will fix this later on....

Was just about to ask if you had it working with docking as well :)

Definitions for cimgui from docking_inter brach are used again. Just did a short test with docking enabled and it seems to work. I will add a merge request to ImGui.NET-nativebuild based on docking branch later on.

I switched my branch of ImGui.NET-nativebuild to master accidently. Now it's using docking_inter branch again. Here is the corresponding pull request:
https://github.com/mellinoe/ImGui.NET-nativebuild/pull/3
The appveyor pipeline there generates working native libraries for windows and linux.

@TillAlex I've merged this with a few adjustments applied in follow-up commits. I have not pushed any official packages using this yet, but I'd like to do that soon for the core library, because it's overdue for an update.

@mellinoe Thanks for merging!

Ok I red whole thread, but I am still confused - how do I get to include Implot (and others) into docking version?
If I understand, everything is available already, just binaries are missing?
I wish to make this available for Unity, normal docking Imgui is working already :).

Ok, got it working on Windows/Unity by downloading this repo: https://github.com/TillAlex/ImGui.NET-nativebuild/tree/additional_libraries and running build-native.cmd


Make CoreHealthMonitor a library

This PR makes CoreHealthMonitor a library. Maestro and Helix-service will be able to use this library to create their own MaestroCoreHealthMonitor and HelixCoreHealthMonitor, simply by registering a stateless service with
host.RegisterStatelessService<CoreHealthMonitorService>("CoreHealthMonitorType");

and
CoreHealthMonitorService.Configure(services)

https://github.com/dotnet/arcade/issues/13286

This looks pretty cool and nothing in the changes looks concerning to me. Should we add some documentation somewhere on how to use this library?
Have we tried using it in a test to see if it's just that easy as advertised to get this into a CoreHealthMonitorService?

This looks pretty cool and nothing in the changes looks concerning to me. Should we add some documentation somewhere on how to use this library?

Not yet, but I think we want to create a wiki page that will describe all libraries we have: https://github.com/dotnet/arcade/issues/13395

Have we tried using it in a test to see if it's just that easy as advertised to get this into a CoreHealthMonitorService?
Not in a test, no, but Helix-Service is already doing this, just slightly different. I will try to spin up Maestro locally to test this


Crash in rendering thread when adding multiple markers

I have been playing with code that adds a few dozens markers in a loop in one function call and I am getting very frequent crashes in the GL thread which is attempting to render partially set markers
(I am not talking about different threads concurrently adding markers).
I haven't digged very deep yet but based on the Android example code (and the c++ interface code below) I haven't seen any mutex I should lock when creating markers.
Is that a known limitation ?
I have seen that @matteblair comment in the PR in which markers where introduced back in september which might allude to what's causing my problem:
I've kind of punted on synchronization for markers at present. If we care about thread safety here then there's a lot we'll need to guard - so let's make that a follow-up task.

Can you share the code that's producing these crashes (particularly the c++ interface)?

I understood what's going on in my code:
I am adding a few dozens markers then wipe them out and add a new batch.
It's the wiping out that's causing the trouble with the render thread: as that thread iterates over std::unique_ptr some have been removed by my application thread and became null.
I see there is not mutex for markers like there is for tiles to protect access to markerManager.markers().
So it's crashing in places like this (tangram.cpp, around line 490)
```
for (const auto& marker : impl->markerManager.markers()) {
if(marker)
style->draw(impl->renderState, *marker);
}

And in places where we check the ease etc.

Ok I think I understand. In our Android interface, most application logic happens on the UI thread while rendering happens on the GL thread. To guard against concurrent access, most of our JNI methods are designated synchronized. For other platform targets, there's no need to incur those synchronization costs so we don't perform synchronization inside the core library. Tile sets, however, must be synchronized in the core library because we access them from worker threads.
For Android applications that don't go through the Java interface we provide, you would need to provide your own synchronization mechanism to prevent concurrent access from the UI thread and GL thread.
Does this answer your questions?

Makes sense, thanks! I am going to add synchronization on my end then.
I feel this should really be pushed down to the c++ API though as it's a cross platform concern.
Maybe it will get introduced as part of #1034 then.


About owning and maintaining Flasgger

Hi,
httbin is based on Flasgger, the lib I created to generate swagger UI for Flask APIs.
I am NO MORE maintaining Flasgger, in 20 days I am going to archive the repository.
So, I am looking for someone to take care of it, as you @postmanlabs owns httpbin, perhaps you are interested in owning Flasgger.
Let me know if you guys want to take this repo and I will transfer it also I'll give ownersip of PyPI namespace.
https://github.com/rochacbruno/flasgger
Thanks

Flasgger has been transfered to own org with other owners. thanks


Boostrap 5 deprecated CSS

When bundleing the scss, my cosole returns multiple warnings.
It would be good to update for those that want to upgrade to Bootstap 5.
WARNING: text-emphasis-variant() has been deprecated as of v4.4.0. It will be removed entirely in v5.

Hello @damiencal,
We will address this issue in an upcoming update in Q2. Thank you.


distance and location objects?

First of all - thanks for you job, find-my-phone adapter is one of most important adapter in my smart home system.
But, after reinstalling iobroker and installing find-my-phone adapter, i dont see a distance and location objects at objects that were created by adapter after installation. How can i fix it?

This issue was moved to iobroker-community-adapters/ioBroker.find-my-iphone-community#7


blockParse.py overlapping probes

https://github.com/beliveau-lab/OligoMiner/blob/master/blockParse.py#L672
Can the spacing be set to a negative number to encourage there to be some level of overlap? I tried making a minor adaptation to have this work while accounting for indices below the length of the length of a probe and it just hung

Yes, just flag '-O' or '--OverlapMode and the spacing parameter will be ignored. There is currently no way to tune the amount of overlap allowed, but if that is desired one could simply parse the output and filter from there (eg with pandas or bedtools)


Nothing to share?

I've followed the installation instructions, installed the plugin, setup App Groups, enabled the entitlements, added them to my provisioning profiles, built my app. I've added a handler to my app and see the output in the Xcode console when initialised like this:
[OpenWithPlugin.m][onReset]
[OpenWithPlugin.m][setVerbosity] 0
openwith: init()
[OpenWithPlugin.m][setLogger] OpenWithPlugin252748709
[OpenWithPlugin.m][setHandler] OpenWithPlugin252748710
[OpenWithPlugin.m][init]
[OpenWithPlugin.m][checkForFileToShare]
[OpenWithPlugin.m][checkForFileToShare] Nothing to share
openwith: addHandler()
openwith: initSuccess()
openwith init success!

When opening the Photos app and selecting a photo to share, I see my app in the share with menu. Tapping it opens my app but the console just says:
[OpenWithPlugin.m][onResume]
[OpenWithPlugin.m][checkForFileToShare]
[OpenWithPlugin.m][checkForFileToShare] Nothing to share
PBItemCollectionServicer connection disconnected.

My handler has the console.log output from the demo project so should display the details of any intent received but seems it's not fired at all. I have exhausted all of the help/documentation provided... any ideas what I can do to debug this?

I'm also facing the same issue while sharing files from other apps, My app opens fine but my handler code never gets executed and xcode logs show 'Nothing to share' as in attached screenshot.

I know it's been a while. Did you guys found a solution?

I have the same issue. I was able to fix it, the problem was my iOS app didn't have correctly set the SHAREEXT_GROUP_IDENTIFIER you can check if it's well defined on the file: ShareViewController.h

I am having such a UTI defined in ShareViewController.h
#define SHAREEXT_UNIFORM_TYPE_IDENTIFIER @"com.tinkamo.lineapp.line"

And the identical setup in the project settings

But I still got "Nothing to share" when I open the file from another app.
2022-10-23 02:11:38.311494+0800 Tinkamo Line[16616:2070973] [OpenWithPlugin.m][onResume]
2022-10-23 02:11:38.311599+0800 Tinkamo Line[16616:2070973] [OpenWithPlugin.m][checkForFileToShare]
2022-10-23 02:11:38.311666+0800 Tinkamo Line[16616:2070973] [OpenWithPlugin.m][checkForFileToShare] Nothing to share


Minor CSS Problem - Maintenance text off center on toggling sidebar

Browser: Safari Version 9.1.1
On large screen view, after collapsing the sidebar and then opening it back up, this happens.

This is the wrong repo. Please reopen in the admin plugin issue tracker as we can't move it.

I fixed this in admin anyway.


--bigendian is included in the README but not implemented

It looks like the --bigendian flag is not implemented based on a quick glance at the code and the fact that using it doesn't change the output image. It should be removed as an argument and from the README until it's implemented to avoid any confusion.

Yes, you're right, it does not do anything like in the original work. I have removed the flag and plan to add the implementation for flags vflip and hflip.


host_path is missing

Hello, and thank you for posting this repo.
Doing vagrant up I get an issue :
There are errors in the configuration of this machine. Please fix
the following errors and try again:
vm:

The host path of the shared folder is missing: [~/Projects/magento-vagrant2/]

But that is where the installation is.
Does it need to be in a different format?
i.e : "~/Projects/magento-vagrant2" ( no brackets ?)
Thank you in advance for your time.
Christian

I am having the same issue.
Would you have any insight ?

Hello, thank you for letting me know this issue. The host_path is defined in the "Vagrantfile.config.yml" file, It points to the guest path "/magento-dev/", which should be an existing folder on your host computer, and the "magento-dev" folder should resides in the same directory as "Vagrantfile". To make it easier for you, I will add the folder into the repo.

That's awesome !
Thank you. I'll try it again and let you know the result.
Christian
On Thu, Sep 14, 2017 at 6:01 PM Xianshun Chen<EMAIL_ADDRESS>wrote:

Hello, thank you for letting me know this issue. The host_path is defined
in the "Vagrantfile.config.yml" file, It points to the guest path
"/magento-dev/", which should be an existing folder on your host computer,
and the "magento-dev" folder should resides in the same directory as
"Vagrantfile". To make it easier for you, I will add the folder into the
repo.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/chen0040/vagrant-magento-2.16/issues/1#issuecomment-329631868,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUAuojDTREG9NkzVVwh7vPOx881mai_ks5sibAvgaJpZM4PXm6x
.

--
Christian Matias Dominguez BushidoWarehouse.com


Update README.md

Added codecov badge

Codecov Report

Merging #66 (bfe04a4) into main (6267d1d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #66   +/-   ##
=======================================
  Coverage   97.16%   97.16%
=======================================
  Files           7        7
  Lines         353      353
=======================================
  Hits          343      343
  Misses         10       10

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Apply appropriate type conversion for viz form_data

Problem
On the Dashboard view, the form_data is passed in as a regular dict.  This is then passed as **kwargs to WTForms which as the note below describes doesn't do proper type conversion.  u'false' becomes True which is not what we want.  This is not currently impacting users because slices always pull data from the json_endpoint but should still be fixed because the data inside the rendered html is inconsistent.
Solution
If passing just one parameter as form_data, the WTForms constructor will do proper type conversion as if the form_data came from a POST.  This is why this bug doesn't surface when using the json_endpoint to get slice data, but it does on the dashboard page.  The fix is to pass the form_data parameter rather than as **kwargs.
Example reproduction steps:

Open Genders sample data slice in explore page.
Save as a donut chart
Save again as a pie chart
Go to dashboard page, add Genders slice
Inspect data-dashboard in the markup.  Note that form_data.donut is true when it should be false.

You have to save as donut and then back to pie to reproduce because initially donut isn't in the params object.  You'll note that the Genders slice still renders as a pie correctly without this fix, but only because internally slices render using data from json_endpoint in which form_data always follows the form = form_class(form_data) code path instead of being used as a **kwargs.  This fix is still important because the form_data is out of sync with the real values and could be problematic in the future or in the present to people who are extending Caravel to use form_data now (which is how I discovered it).

Note Backing-store objects and kwargs are both expected to be provided with the values being already-coerced datatypes. WTForms does not check the types of incoming object-data or coerce them like it will for formdata as it is expected this data is defaults or data from a backing store which this form represents. See the section on using Forms for more information.

WTForms docs
@mistercrunch

@leebailey88 why closing this?


[Feature]In Neovim, it is possible to throw an error when a variable does not exist in a template.

What problem does this feature solve?
Thanks to the contributions of the Volar team, Volar can now run very smoothly in Neovim. However, there's a slight imperfection: when a variable is missing or does not exist, it does not throw an error in the template.

All other functions are working very normally.

What does the proposed solution look like?
work likes vscode.
BTW, @RayGuo-ergou I'm very sorry to ping you, but I was hoping you could help take a look on your end to see if your configuration is experiencing the same issue.

This is already implemented, set strictTemplates to true
https://github.com/vuejs/language-tools/blob/master/packages/language-core/schemas/vue-tsconfig.schema.json#L43-L47

This has already been implemented, set strictTemplates to true
https://github.com/vuejs/language-tools/blob/master/packages/language-core/schemas/vue-tsconfig.schema.json#L43-L47

could you give me same configuration case. for me to add this option.


⚠ ClamAV has degraded performance

In 650f6fb, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 107 ms

Resolved: ClamAV performance has improved in 5fe33a3.


[SPARK-36148][SQL] Fix input data types check for regexp_replace

What changes were proposed in this pull request?
RegExpReplace overrides checkInputDataTypes but doesn't do the basic type check.
This PR adds the type check so that the error message is more readable.
Why are the changes needed?
bugfix
Does this PR introduce any user-facing change?
no
How was this patch tested?
newly added test case

Test build #141062 has started for PR 33357 at commit d5f6bab.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/45577/

+1, LGTM. Merging to master.
Thank you, @linhongliu-db .

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/45577/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/45577/

@MaxGekk, thanks for your super quick review.

Test build #141062 has finished for PR 33357 at commit d5f6bab.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/141062/


Fixing the toy image generator

When implementing the concentrations features, I found that the toy image generator was severely broken.

The given intensity is not reproduced, the showers are much, much too bright.

Width and Length are taken as variance, not standard deviation

The cleaning for the test event is far from optimal.

Here is the image that is used for the hillas tests:

The maximum pixel value is over 9000!
Just kidding, it's over 2000.

This is the test image after the fix:

The hillas tests are now failing because some methods report a psi rotated by 180 degrees.

The tests are passing again, because I coerced the psi angles in the test to the [-90, 90] interval.
Maybe we should think about adding this in the hillas_functions themselves but we will also not keep 5 hillas_functions, right?

Somehow the installation of pyqt fails on travis for python 3.6


bump release 0.2.5

Codecov Report

Merging #243 (4c0e177) into master (f167419) will increase coverage by 0.33%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #243      +/-   ##
==========================================
+ Coverage   70.41%   70.74%   +0.33%
==========================================
  Files          41       41
  Lines        7381     7383       +2
==========================================
+ Hits         5197     5223      +26
+ Misses       1674     1654      -20
+ Partials      510      506       -4

Impacted Files
Coverage Δ

model/ranking/data.go
86.11% <100.00%> (+0.22%)
:arrow_up:

storage/data/mongodb.go
76.37% <100.00%> (+1.37%)
:arrow_up:

storage/data/sql.go
77.90% <100.00%> (+1.47%)
:arrow_up:

master/task_manager.go
91.91% <0.00%> (+3.67%)
:arrow_up:

Continue to review full report at Codecov.

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