👀 Editor View

The Editor View lives in CodeEditTextView and features a basic implementation of tree-sitter using SwiftTreeSitter.

Overview
We need to implement a fully featured editor view. This view sits inside the Workspace UI (#346). We need to determine if we should roll our own or use an existing solution.
Features
Our code editor view should include the following features

[x] Syntax Highlighting

https://github.com/CodeEditApp/CodeEditLanguages/issues/10

[x] CodeEditApp/CodeEdit#189
[ ] CodeEditApp/CodeEditTextView#31
[x] CodeEditApp/CodeEdit#98
[ ] CodeEditApp/CodeEditTextView#30
[ ] CodeEditApp/CodeEditTextView#46
[ ] CodeEditApp/CodeEditTextView#47
[ ] CodeEditApp/CodeEditTextView#29
[ ] CodeEditApp/CodeEditTextView#32
[ ] Code Validation
[ ] Messages - errors, warnings, info
[ ] CodeEditApp/CodeEditTextView#33
[x] Line Numbers
[x] CodeEditApp/CodeEditTextView#34
[ ] Change Indicator
[ ] Diff comparison

Resources

Tree-sitter
SwiftTreeSitter
STTextView
Neon

Packages to consider

CodeEditorView
CodeViewer
CodeEditor
Sourceful
SavannaKit
CotEditor

I'll dump some resources to consider here:

https://github.com/mchakravarty/CodeEditorView
https://github.com/dwarvesf/CodeViewer
https://github.com/ZeeZide/CodeEditor
https://github.com/twostraws/Sourceful
https://github.com/louisdh/savannakit

I've spoken to the developer of CodeEditorView and added https://github.com/mchakravarty/CodeEditorView/issues/43 and https://github.com/mchakravarty/CodeEditorView/issues/44. I also left some comments on https://github.com/mchakravarty/CodeEditorView/issues/3.

Let's reopen because this editor is just a start. I assume based on PR comments that it will not support #46

I'm actively working on a custom solution built over Highlightr.js!

@MarcoCarnevali Hello! It looks like you've already found something you want to use, but I thought I'd let you know what we're up to just in case.
My app (Chime) does highlighting (and indentation) using tree-sitter. We've open sourced a low-level library for working with it in Swift.
However, Chime has a huge amount of infrastructure on top of that for its actual implementation. We were actually in the process of pulling out another layer in the system now. A few others have asked about this before, so it was something we wanted to do anyways.
If any of this sounds interesting, let me know and we can discuss more!

@mattmassicotte I'm currently using a wrapper around highlightjs but happy to change it to something better! I would definitely love to discuss more on that, seems interesting!

I'm not familiar with highlight.js, but it looks like a great tool!
I've taken many different paths along my syntax highlighting journey. Right now, Chime uses a hybrid tree-sitter + LSP semantic tokens.
Tree-sitter's support for incremental parsing gives it really good performance characteristics.  Plus, it supports generalized syntax-tree queries, which we use for structure highlighting (matching if-{-}) and precise indentation calculations. Tree-sitter is awesome, but very complex.
LSP also has a syntax highlighting system called semantic tokens. Glueing together both of these is tricky. But, it's desirable because semantic tokens can provide better information, but is slower and always asynchronous. Tree-sitter isn't as precise, but is faster and can be used synchronously if needed. It also works well in the face of syntax errors, which is the common case during editing.
I was just in the process of pulling out some more of the tree sitter system we use, it will be here: TreeSitterClient . But, I'll need some more time to finish that. And, even when done, that's just perf/convenience around the system, not a full highlighting implementation...

That's definitely something we need, the current system it's not really scalable and good performances wise. What do you think would the timeline be like?

Pulling out stuff like this is always a little easier said that done, haha. I'm making progress, but I have some higher-priority stuff going on this week. I'm hoping by next week!
However, I do want to stress that this is not a drop-in highlighting library. It just makes it much easier to connect a text storage system (like one backed by NSTextStorage) to tree-sitter in a performant way. The incremental stuff will just work, and could be helpful right from the beginning. But, background processing is necessary for low-latency with large documents. That is much more complex, and requires maintaining a stable and thread-safe view of your text across user edits. I do this a few different ways, but BufferingTextStorage from TextStory may be interesting here.
Progressive highlighting (multiple passes of varying latency/quality) also really helps for performance and user perception, but is an entirely different thing.
Do you have any highlighting performance/quality targets for your first release?

Just a quick update: after some thought, we decided that it just made more sense to build a project around working with syntax as a whole. The core tree-sitter abstraction is now available. https://github.com/ChimeHQ/Neon

Do you have any highlighting performance/quality targets for your first release?

Good question! We've recently merged a new PR with a custom editor built around highlghtr, I would say the performances are good/usable for now so anything that matches that would be very good! But we would definitely need something more performant in the future

Just a quick update: after some thought, we decided that it just made more sense to build a project around working with syntax as a whole. The core tree-sitter abstraction is now available. https://github.com/ChimeHQ/Neon

That's awesome, I'll definitely try this soon, is there an usage example? and btw our current solution uses a NSTextStorage to have a performant real-time highlighting

I took a bit of time to study Highlightr and highlight.js, just to see what was up. I'm really glad to hear it's working out!
If you do want to start looking for higher performance/correctness in the future, I'm lurking in the discord, and generally available. I would love to help out! And in the mean time, I'm going to continue, here and there, pulling stuff out of Chime into Neon. The exercise has already been helpful. And, as I do, I'll put a little more effort into explaining how to use it.

FYI, I just pinned this issue and updated the description to track other issues.

@glaucocustodio wrote,

Not via LSP, what does that imply for new languages wanting support in our editor? The idea of the LSP is effortless support. Would that not increase the barrier to entry?

It does imply that the editor needs basic awareness (= configuration) for every supported language. That is quite standard AFAIK and I don't see how to get around it.
The issue is simply the following. There are some things where you want an immediate per keystroke response. For example, if you comment out a line, you want syntax highlighting to reflect that immediately without any delay. (That might sound simple, but in the presence of nested comments, multiline strings, etc. it is quite involved.)
On the other hand, there are things that might deserve highlighting, but that do require a sophisticated language-dependent analysis of the code, such as whether an identifier is locally bound or globally, or whether an identifier refers to a variable or a function. (In C even something like whether an identifier is a typedef or variable, which requires knowing all included headers including macro expansion.) All this requires the kind of static code analysis that the frontend of a compiler performs.
I can't see how you can have both, the immediate response on a per keystroke basis and the sophisticated code analysis-based highlighting, in one system. It requires two: (1) fast, synchronous syntax analysis in the editor itself and (2) slow, asynchronous code analysis via LSP, SourceKit, or a similar system. You can see that in Xcode how some highlighting is immediate and some of it happens with a delay.

In talking about this with @MarcoCarnevali who has put in place our current temporary editor solution, it sounds like we are waiting until we have a clearer understanding regarding extension architecture (#76, #180).
@mchakravarty so we need to support things like code completion, hover suggestions, decorations like color swatches next to hex values, etc. Is this something that we can easily control and extend with CodeEditorView?
If so, I personally think we should start building this out now so we will be ready for extensions when it is ready. Thoughts?

@austincondiff wrote,

so we need to support things like code completion, hover suggestions, decorations like color swatches next to hex values, etc. Is this something that we can easily control and extend with CodeEditorView?

These are features that still need to be implemented in CodeEditorView. Code completion is of course crucial. I am less sure about hover suggestions — I guess, I am partial to the way Xcode behaves. However, it is certainly something to discuss as an optional feature.
Important, from an architectural POV, is that all this is a lot of data, which is also frequently changing, that needs to be fed into the editor view and it needs to lend itself to fast lookups. Moreover, completions need lookups on prefixes and/or close matches. Hence, this needs some thinking about appropriate data structures.

Current State of the Editor
I just want to publicly share what the current state of development of our core feature - the editor - is.
Current Implementation
Currently we have a temporary solution in place which uses Hightlightr for syntax highlighting. Highlightr is based on highlight.js - a javascript based parser.
Syntax Highlighting
Our plan is to base our syntax highlighting on tree-sitter - an incremental parser written in C. Due to its incremental parsing it is very efficient when processing changes in the syntax tree. And since it is written in C instead of Javascript it is extremely fast and low cost on performance.
We already looked into existing Swift wrappers for tree-sitter like SwiftTreeSitter/Neon and based on some proof-of-concept code it is working pretty nicely.
Existing Libraries vs. Our Own Implementation
SwiftTreeSitter is pretty enhanced already. The only drawback is, that it is based on a closed-source framework tree-sitter-xcframework which we have no control over.
Since the editor is the most crucial part of our app we decided to not rely on dependencies (especially closed-source ones). We will write our own implementation of a tree-sitter wrapper which will definitely take more time initially but will pay off later when we need to enhance features and also when implementing our plugin ecosystem.
We know that this definitely isn't the easy path to go but it's the most future proof way we can think of.
I also want to note that Simon just launched an awesome text editor for iOS & iPadOS - Runestone. He open-sourced the backbone of Runestone as well, and we might take some inspiration from his implementation of tree-sitter too.
Also I want to thank @mattmassicotte for helping me understand the basics of tree-sitter which is quite a complex topic.
Resources:

https://github.com/raspu/Highlightr
https://highlightjs.org
https://tree-sitter.github.io/tree-sitter/
https://github.com/ChimeHQ/SwiftTreeSitter
https://github.com/ChimeHQ/Neon
https://github.com/krzyzanowskim/tree-sitter-xcframework
https://runestone.app
https://github.com/simonbs/runestone

I'm not stunned to see that the xcframework was what tripped you up. It's of course open source, but is pre-compiled. SPM provides limited options here, and this was the only one we could find that offered drop-in functionality.
But is that really the only issue? This seems completely solvable. And whatever solution you come up with for the actual binary tree-sitter dependencies may work better for others. I'd like to find a way to manage the binary dependencies without relying on a pre-compiled binary too!
How do you plan on actually building/bundling those pieces?

I got interested, so I played around with SPM-izing tree-sitter directly. I was inspired by how Simon did it with Runestone. Note that tree-sitter produces some warnings during its build, so these spill over to the project when used via SPM. This should be fixable, but I haven't yet investigated.
I was also able to do this for a single parser. But that should be enough of a proof-of-concept that it can be done for all of them. I don't have anything public for this yet.
Here's the fork of tree-sitter that supports SPM directly:
https://github.com/mattmassicotte/tree-sitter/tree/feature/swift-package
And here's the fork of SwiftTreeSitter that depends on it, and not on a pre-built binary:
https://github.com/ChimeHQ/SwiftTreeSitter/tree/feature/no-xcframework
So, this is a complete built-from-source tree-sitter library. And, it should now be possible to select languages as desired, and just include them as SPM dependencies. I think I like this approach better, so I'm going to start moving towards this.
But, you should absolutely feel ok deciding to take control whichever parts you need to. This is your project and you need to proceed in the way that makes the most sense.

Thanks a lot @mattmassicotte! This is great! With this in mind, do we want to follow a similar path for our editor @lukepistrol?

Basic implementation of tree-sitter using SwiftTreeSitter and STTextView is now available on feature/new-editor branch.
Contributions are welcome on the editor package CodeEditTextView! Documentation is available here.
Thanks to @mattmassicotte for creating SwiftTreeSitter and for helping me with questions.
Also big thanks to Marcin Krzyzanowski for creating STTextView as an alternative to NSTextView.

Note that STTextView is still in active development and if some features are missing you might consider contributing there as well.

#701
#699

Those two don't really pertain to the editor view itself.

Closing because we have mostly implemented this


Can't create project when using Magyar (Hungarian) language

Hello!
version: 1.0.11
I can't create new project when using Magyar (Hungarian) language for user or the whole site.

It's fixed in the development branch.
The problem was coming from a duplicate column name. In the translation file the column name "Kész" was present two times.
So I renamed the column "Done" to "Csinált" with Google translate.
Diff: https://github.com/fguillot/kanboard/commit/8fde5df4f829e9ea2c3a9262512a34a584e4b4e5
Thanks to report the issue.

Thx. I will update the hungarian translation in a week.


nixos/caddy: Add rfc42 settings option

Description of changes
Add rfc42 settings option to Caddy.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] 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.11 Release Notes (or backporting 23.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

I am not in favor of this.
Most end-users should mainly interact with Caddy via Caddyfile.
I'd argue, this change suggests, that the json config is preferred.
Which it isn't :(

Would you be ok with the change if the docstring were more explicit that usually using the other options (which assemble a Caddyfile) is preferred?
I think we should provide a rfc42 style settings option for the json config, because it means that we can utilize the module system to merge json configs. If you need features from the json config, you currently have to do something like
configFile = pkgs.writeText "caddy.json" (builtins.toJSON {
  …
});

which then can't be merged or overridden anymore.

Is the change fine for you, @emilylange? Anything left to do?

Push. CC @emilylange

Whoops, sorry, will try to look into this soon.

@ofborg test caddy


Trying to run FSRT following EcoScanner vulnerability detection

I ran this command:
fsrt ./my-project

Where my-project is the path towards the app I wish to test.
I expected this to happen:
The scanner evaluates the app and reports any issues
Instead, this happened:
The program exits with errors:

thread 'main' panicked at crates/forge_analyzer/src/definitions.rs:359:18:
expected class

fsrt --version:
fsrt 0.1.0

Backtrace

thread 'main' panicked at crates/forge_analyzer/src/definitions.rs:359:18:
expected class

stack backtrace:
   0: rust_begin_unwind
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:597:5
   1: core::panicking::panic_fmt
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:72:14
   2: <forge_analyzer::definitions::Lowerer as swc_ecma_visit::Visit>::visit_var_declarator
   3: swc_ecma_visit::visit_decl
   4: <forge_analyzer::definitions::Lowerer as swc_ecma_visit::Visit>::visit_var_declarator
   5: swc_ecma_visit::visit_decl
   6: forge_analyzer::definitions::run_resolver
   7: fsrt::scan_directory
   8: fsrt::main

I'm facing the same panic error when trying to run the scanner after seeing that Atlassian announced it'd start running the scanner on deployed marketplace applications. I'm simply running it locally to get a leg up on any warnings it may give. Here's the specific error I'm seeing:
[repos]$ RUST_BACKTRACE=1 fsrt ./jmcf-cloud
thread 'main' panicked at crates/forge_analyzer/src/definitions.rs:411:18:
expected class
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: <forge_analyzer::definitions::Lowerer as swc_ecma_visit::Visit>::visit_var_declarator
   3: swc_ecma_visit::visit_decl
   4: forge_analyzer::definitions::run_resolver
   5: fsrt::scan_directory
   6: fsrt::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

BTW, I'm running on macos 13.6.1 after installing rust 1.75.0 via Homebrew. I installed FSRT via cargo as directed:
cargo install --git https://github.com/atlassian-labs/FSRT
The installation showed a lot of warnings (see attached) but I didn't see any errors
fsrt_install.txt

Hi @sebD, @jeffryan-appfire,
Sorry about the late reply. Would you be able to provide a minimal reproduction of the app that causes the crash? You can also provide me with the app ID of a deployed app that FSRT's crashing on and I can take a look at it.

Also, @sebD, as for your concern about the custom fields route, we've had this question come up a lot, and we definitely agree that the ADMIN permission is a bit too heavy handed for that API endpoint.
That being said, the main Authorization that needs to happen is to check if the user can access a custom field in the first place, since users shouldn't be able to view fields if they aren't in a project where the field exists. There unfortunately isn't a simple way to authorize the user in this case. The simplest way to check if a user can access a field is to GET the fields with asUser and check if the supplied field key or field id is contained within the list of returned fields. There's probably other ways to do it, however, this is the simplest one we've found and have explicitly added logic to FSRT to allow access to custom field endpoints once this check is done. That being said, if you wish to do this check another way, let me know and I can see if I can update FSRT to also recognize your approach.
Also, if you do perform this type of check, but FSRT isn't recognizing it, you can reach out on the ticket if you have one and I'll close it manually, so you don't have to wait.

I have the same issue trying to run FSRT on Windows - inside a Docker container using the repository's Dockerfile (modified a bit for it to work - didn't use the FROM gcr.io/distroless/cc base container which can't run the binaries):
Here's a more detailed stack trace while running the app built as debug instead of release.
Details

thread 'main' panicked at crates/forge_analyzer/src/definitions.rs:412:18:
expected class
stack backtrace:
   0:     0x5601021eb7dc - std::backtrace_rs::backtrace::libunwind::trace::h67a838aed1f4d6ec
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x5601021eb7dc - std::backtrace_rs::backtrace::trace_unsynchronized::h1d1786bb1962baf8
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x5601021eb7dc - std::sys_common::backtrace::_print_fmt::h5a0b1f807a002d23
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x5601021eb7dc - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf84ab6ad0b91784c
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x560102216f3c - core::fmt::rt::Argument::fmt::h28f463bd1fdabed5
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/fmt/rt.rs:138:9
   5:     0x560102216f3c - core::fmt::write::ha37c23b175e921b3
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/fmt/mod.rs:1114:21
   6:     0x5601021e794e - std::io::Write::write_fmt::haa1b000741bcbbe1
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/io/mod.rs:1763:15
   7:     0x5601021eb5c4 - std::sys_common::backtrace::_print::h1ff1030b04dfb157
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x5601021eb5c4 - std::sys_common::backtrace::print::hb982056c6f29541c
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x5601021ecc33 - std::panicking::default_hook::{{closure}}::h11f92f82c62fbd68
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:272:22
  10:     0x5601021ec954 - std::panicking::default_hook::hb8810fe276772c66
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:292:9
  11:     0x5601021ed1b5 - std::panicking::rust_panic_with_hook::hd2f0efd2fec86cb0
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:731:13
  12:     0x5601021ed066 - std::panicking::begin_panic_handler::{{closure}}::h3651b7fc4f61d784
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:601:13
  13:     0x5601021ebd06 - std::sys_common::backtrace::__rust_end_short_backtrace::hbc468e4b98c7ae04
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/sys_common/backtrace.rs:170:18
  14:     0x5601021ece02 - rust_begin_unwind
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:597:5
  15:     0x560101ce1975 - core::panicking::panic_fmt::h979245e2fdb2fabd
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:72:14
  16:     0x560101da8efd - forge_analyzer::definitions::DefKind<F,O,I>::expect_class::h0f47e04e5b28b74e
                               at /app/crates/forge_analyzer/src/definitions.rs:412:18
  17:     0x560101da8efd - <forge_analyzer::definitions::Lowerer as swc_ecma_visit::Visit>::visit_var_declarator::h6549ca7d80f913d7
                               at /app/crates/forge_analyzer/src/definitions.rs:2852:41
  18:     0x560101db36c7 - swc_ecma_visit::visit_var_declarators::{{closure}}::hacc78e89e42c351f
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  19:     0x560101db36c7 - <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::for_each::h71237299a5665abb
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/slice/iter/macros.rs:254:21
  20:     0x560101db36c7 - swc_ecma_visit::visit_var_declarators::h07e32fa79e588e70
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  21:     0x560101db36c7 - swc_ecma_visit::Visit::visit_var_declarators::h3fc0f51b5f200cac
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  22:     0x560101db36c7 - swc_ecma_visit::visit_var_decl::h267e425848fbb8a2
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  23:     0x560101db36c7 - swc_ecma_visit::Visit::visit_var_decl::hbe254143ba42ceb4
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  24:     0x560101db36c7 - swc_ecma_visit::visit_decl::h0e5c644a44e068dd
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  25:     0x560101dacbbd - swc_ecma_visit::Visit::visit_stmt::h187f991d990d811e
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  26:     0x560101dacbbd - swc_ecma_visit::visit_module_item::h752b5486d72354c8
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  27:     0x560101dacbbd - swc_ecma_visit::Visit::visit_module_item::h1c2675c2b8e8c056
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  28:     0x560101dacbbd - swc_ecma_visit::visit_module_items::{{closure}}::h52dd213da0163963
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  29:     0x560101dacbbd - <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::for_each::h5fdb14aa53c16a23
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/slice/iter/macros.rs:254:21
  30:     0x560101dacbbd - swc_ecma_visit::visit_module_items::h7a73d8b5be4e1249
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  31:     0x560101dacbbd - swc_ecma_visit::Visit::visit_module_items::h9d9d6cbfef038079
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  32:     0x560101dacbbd - swc_ecma_visit::visit_module::hda74e272d2903de5
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  33:     0x560101dacbbd - swc_ecma_visit::Visit::visit_module::h5941ea5668c106d8
                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  34:     0x560101dacbbd - <swc_ecma_ast::module::Module as swc_ecma_visit::VisitWith<V>>::visit_with::h42b4d4cb542c9c23                               at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_visit-0.96.10/src/lib.rs:537:1
  35:     0x560101dacbbd - forge_analyzer::definitions::run_resolver::ha941e658d4b0fc2b
                               at /app/crates/forge_analyzer/src/definitions.rs:200:9
  36:     0x560101cee0f1 - fsrt::ForgeProject::with_files_and_sourceroot::h72fc4e94794acfef
                               at /app/crates/fsrt/src/main.rs:131:19
  37:     0x560101d04652 - fsrt::scan_directory::h6614de740ad451b8
                               at /app/crates/fsrt/src/main.rs:217:9
  38:     0x560101cffefa - fsrt::main::ha80e9f2dc21f6ef1
                               at /app/crates/fsrt/src/main.rs:448:9
  39:     0x560101ce6483 - core::ops::function::FnOnce::call_once::he71b31390560dd39
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/ops/function.rs:250:5  40:     0x560101ce6483 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5b279bee94f8cef5
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/sys_common/backtrace.rs:154:18
  41:     0x560101d4081d - std::rt::lang_start::{{closure}}::h97a8219a047f0ac3
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/rt.rs:166:18
  42:     0x5601021e221b - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hf9057cfaeeb252e2
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/ops/function.rs:284:13
  43:     0x5601021e221b - std::panicking::try::do_call::h629e203a624883e4
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:504:40
  44:     0x5601021e221b - std::panicking::try::h7b61614724d6a4f1
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:468:19
  45:     0x5601021e221b - std::panic::catch_unwind::h354ac1c0268491d8
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panic.rs:142:14
  46:     0x5601021e221b - std::rt::lang_start_internal::{{closure}}::h919fee3c5ba8f617
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/rt.rs:148:48
  47:     0x5601021e221b - std::panicking::try::do_call::h54583f67455bff32
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:504:40
  48:     0x5601021e221b - std::panicking::try::hb0e12c4e01d39dc2
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:468:19
  49:     0x5601021e221b - std::panic::catch_unwind::h367b6339e3ca9a3b
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panic.rs:142:14
  50:     0x5601021e221b - std::rt::lang_start_internal::ha5ce8533eaa0fda8
                               at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/rt.rs:148:20
  51:     0x560101d0a5fc - main
  52:     0x7f39591211ca - <unknown>
  53:     0x7f3959121285 - __libc_start_main
  54:     0x560101ce2241 - _start
  55:                0x0 - <unknown>

Alright so I've investigated a bit more, as running it on the test apps was working properly, so I knew I could modify our manifest / code until it works.
I found the piece of code that can make FSRT crash. It's a typescript.ts file with simple pseudocode inside it as follows:
const Something = {
  someFunction() {
  }
}
export default Something;

It appears that declaring functions that way make FSRT crash. Here's a modification that now makes it work:
const Something = {
  someFunction: function() {
  }
}
export default Something;

I hope this helps!

@jwong101 If you'd like to run against our appid here it is:
id: ari:cloud:ecosystem::app/8b5ff96a-a06c-40e4-a906-57a8888a75dd

Thanks! I'll take a look at those apps.

This commit should resolve the crash for ari:cloud:ecosystem::app/8b5ff96a-a06c-40e4-a906-57a8888a75dd. Let me know if it works for you @jeffryan-appfire.

@MaxTheBean your issue should be fixed by this commit. Let me know if it works for you.

My apologies @jwong101 for not responding earlier - we were buried at the moment but your closure of the issues prompted me to look at it again. I updated my version of rust and reinstalled the scanner. It now seems to be successfully completing however it runs very, very fast - to the point that I wonder if it really did anything. I also tried the callgraph option but do not see any output. So I am not sure if I am running it properly. Another thing I noticed is that although the install works and I no longer see the error it looks like the app version hasn't changed as fsrt --version still reports 0.1.0
Here's what I am seeing when I run the app.
[repos]$ RUST_BACKTRACE=1 fsrt ./jmcf-cloud
{"vulns":[],"scanner":"FSRT","started_at":"2024-07-01T20:12:11.679117Z","ended_at":"2024-07-01T20:12:11.679988Z","scanned":[""],"errors":false}
[repos]$ RUST_BACKTRACE=1 fsrt ./jmcf-cloud --callgraph
{"vulns":[],"scanner":"FSRT","started_at":"2024-07-01T20:15:58.469473Z","ended_at":"2024-07-01T20:15:58.470244Z","scanned":[""],"errors":false}

Hi @jeffryan-appfire,

My apologies @jwong101 for not responding earlier - we were buried at the moment but your closure of the issues prompted me to look at it again.

No worries!

I also tried the callgraph option but do not see any output. So I am not sure if I am running it properly.

Ah the --callgraph and --cfg are unimplemented at the moment. (The --cfg option used to
be implemented, but it was removed for reasons that I can't remember). I'll remove those flags from the README.md and --help output to reflect this.
You can check the status of the scanner by doing FORGE_LOG=debug fsrt. For your particular app, I checked the source, and the secret scanner and authentication scanner being quick is expected.
For the secret scanner, since your app doesn't use any common sinks, it shouldn't run at all.
For the authentication scanner, the webtrigger function is small, so that should run scanner.
However, for the authorization scanner, there's a current limitation of the scanner where we only identify API calls via asApp/asUser if we know for certain what the invoking function is. While this is resilient against shadowing, renaming, etc, the scanner currently doesn't try to resolve the function if it's dependent on a conditional. For instance[^1]:
// assume useAsApp isn't constant and api is the default import from '@forge/api'
const func = useAsApp ? api.asApp : api.asUser;
func().requestJira(...);

Since FSRT doesn't know what the exact function being invoked is, it classifies it as a 'regular' function call instead of a Forge intrinsic. Ideally, we should determine the various Forge intrinsics during the actual dataflow analysis instead of when creating FSRT's intermediate representation. However, since FSRT can't at the moment, the authorization scanner ends up running pretty quickly on your app, since it can't find any Forge API call intrinsics.
We will be undertaking a project over the next couple of months to FSRT's accuracy, and I'll add this particular code pattern as something we should detect.
Let me know if you have any further questions, and I hope this explanation of FSRT's current limitation makes sense.
[^1]: The jmcf-cloud app contains a more complicated version of this pattern, but FSRT currently fails on this simple one.


Move modules.load.d directory from /etc to /usr/lib and prefix with priority

For packages /usr/lib/modules-load.d/*.conf is the correct location. The file should also be prefixed with a priority. Please see here:
https://www.freedesktop.org/software/systemd/man/modules-load.d.html

Thanks @nudgegoonies. I agree that the place where the sysbox install package places the "shiftfs.conf" file is not the correct one (i.e., "/etc/modules-load.d/shiftfs.conf").
Reading the man page you referenced, I see:
"Packages should install their configuration files in /usr/lib/ (distribution packages) or /usr/local/lib/ (local installs)."
Thus, I am thinking the right directory is "/usr/local/lib/modules-load.d", rather than "/usr/lib/modules-load.d". Do you agree?
Thanks again!

Agree with you @nudgegoonies. The file in question is "sysbox-configfs.conf".
Now, concerning the ideal location, i find linux FHS a bit ambiguous on this matter:

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

Locally compiled/installed software would fully fit the above description. Now, we are distributing Sysbox in a distro-package, so we don't need to worry about "being overwritten when the system software is updated", coz the package subsystem (either deb or rpm) prevent that from happening. This seems to be the stance taken by Redhat folks:

In Red Hat Enterprise Linux, the intended use for the /usr/local/ directory is slightly different from that specified by the FHS. The FHS says that /usr/local/ should be where software that is to remain safe from system software upgrades is stored. Since software upgrades can be performed safely with RPM Package Manager (RPM), it is not necessary to protect files by putting them in /usr/local/. Instead, the /usr/local/ directory is used for software that is local to the machine.

On the other hand, Sysbox is not yet part of an official distro-package repository, so you could argue that Sysbox is what FHS refers to as "local install" ...

As we need to be consistent with the location of our binaries and config-files, and we were already considering to move Sysbox binaries to /usr/bin (issue #221), i think it makes sense to stick to /usr/lib/modules-load.d as the proper location to install Sysbox's *.conf files.

In my view the correct location is /usr/local/* for these, as Sysbox is not a distribution package (yet).

Let's talk.

In my view the correct location is /usr/local/* for these, as Sysbox is not a distribution package (yet).

I think not there is no difference between official distribution packages and "other" packages. When using /usr as the base even for "other" packages the workflow that a local administrator can install a higher version manually with "make install" into /usr/local/. And even "other" packages should not overwrite anything in /usr/local i think.

Yep, agree @nudgegoonies.

I think not there is no difference between official distribution packages and "other" packages.

I see; let's stick with /usr/bin then.

Using /usr/lib/modules-load.d directory the file sysbox-configfs.conf can be removed from the conffiles list in the package.
Regarding the prefix i am unsure. Maybe 50-?

Yep, 50-? sounds good. But why are you saying that sysbox-configfs.conf file can be removed from the package? That file would still be needed to enforce the configfs module dependency that Sysbox has.

No, not the "sysbox-configfs.conf" file. That file and its content must stay. I mean the "entry" for this file in the "conffiles" debian package configuration file can be removed. The "sysbox-configfs.conf" file does not need to be "marked" as a configuration file.

Oh yes, "conffiles" is gone now as there's no need for it anymore.
These changes will be present in our next release -- just a very few weeks from now. Please let me know if we can close this issue now.
Btw, thanks for all your suggestions + PRs @nudgegoonies, we really appreciate that!

Thank you very much. Yes, can be closed!

Fixed as part of various enhancements made in the Sysbox installer. Closing issue now.


Support flow control via URI and tagged strategy

Supports parsing fc tag on publication and rtag on subscription.
Adds the tagged flow control strategy and associated supplier.
Retrieves 8-byte receiver tag from status messages when received.
Adds unit tests for flow control strategies and flow control option parsing.
Enables the system tests to running against the C media driver for tagged flow control.

TODO:

Parse group count.
Default rtag value for publishers from system properties.

The code looks good to me. The tests keep failing, though, on Windows in the flow_control_test.


Snapshot functionality does not work properly

1 - If no snapshots are present. Then snapshot list modal should be closed
2 - Clicking on cancel should not remove snapshot
3 - If disk snapshot creation is in progress, then the user should not be able to create another snapshot
4 - removing snapshot in snapshots modal should remove it from the list

TBD in #630


Updating GDSCN theme

This PR gets the template set up with GDSCN style and updates.

Removes ITCR and Data Trail style sets (not needed)
Adds GDSCN style
Modifies the Sync file to:

sync relevant gdscn files (like _output.yml)
divide up AnVIL and GDSCN repos so each is only listed once (opinion here that we don't want to have other users worry about adding the same repo in multiple locations.

One sorta bug..
The test-repo-sync.yml by defauly runs all the groupings in the sync.yml file. You can comment out the one you don't want to test but that isn't ideal. Raised an OTTR issue here: https://github.com/jhudsl/OTTR_Template/issues/558

@avahoffman Thanks for working on this.  I was actually going to try rearranging the style-sets a bit to make it easier to swap out styles.  I think I can set things up so that the only thing people need to switch between AnVIL and GDSCN is _output.yml .  I'm going to experiment with that in another branch, and then check back in?

@KatherineCox sounds great!

Superseded by #151


500 Internal server error when posting a new post or searching for channels.

There are actually 2 errors I am getting when I post
Error1
I am getting this error at all times when I post a new article. The submission windows do not close but if I refresh the website the post appears. and I am getting a 500 internal server error. I am getting this error when I delete a post too

Error2
I am getting this error from time to time when I post a new article. On top of the 500 Internal server error, I get 2 extra errors about the fields being undefined.  This error can come up when I try to search for channels in the submission window too but sometimes the search for channels just works.
Any good way to debug this?

I managed to fix this issue. The errors were caused because I didn't use the right algolia API key. The right one is the admin key. In the process I found this tool. It works really well when it comes to viewing debugging errors related to laravel.
https://github.com/rap2hpoutre/laravel-log-viewer


Extended API for use in DVC

We don't need special API in the DVC. If we need it, we can directly use client anyway.


[install error] sdotsub.f:(.text+0x7): undefined reference to `sdot_'

Linux + blas
I have put libblas.a  libcblas.a to /usr/local/lib, when I make, the cmd complains:
outside_built/gcc4.9.0/bin/g++ -DMSHADOW_FORCE_STREAM -Wall -O3 -I./mshadow/ -I./dmlc-core/include -fPIC -Iinclude -msse3 -funroll-loops -Wno-unused-parameter -Wno-unknown-pragmas -DMSHADOW_USE_CUDA=0 -DMSHADOW_USE_CBLAS=1 -DMSHADOW_USE_MKL=0 -DMSHADOW_RABIT_PS=0 -DMSHADOW_DIST_PS=0 -DMXNET_USE_OPENCV=1 pkg-config --cflags opencv -fopenmp   -o bin/im2rec tools/im2rec.cc build/resource.o build/c_api/c_api.o build/c_api/c_api_error.o build/c_api/c_predict_api.o build/common/mxrtc.o build/common/tblob_op_registry.o build/engine/engine.o build/engine/naive_engine.o build/engine/threaded_engine.o build/engine/threaded_engine_perdevice.o build/engine/threaded_engine_pooled.o build/io/io.o build/io/iter_csv.o build/io/iter_image_recordio.o build/io/iter_mnist.o build/kvstore/kvstore.o build/ndarray/ndarray.o build/ndarray/ndarray_function.o build/ndarray/unary_function.o build/operator/activation.o build/operator/batch_norm.o build/operator/block_grad.o build/operator/concat.o build/operator/convolution.o build/operator/cross_device_copy.o build/operator/cudnn_batch_norm.o build/operator/deconvolution.o build/operator/dropout.o build/operator/elementwise_binary_op.o build/operator/elementwise_binary_scalar_op.o build/operator/elementwise_sum.o build/operator/embedding.o build/operator/fully_connected.o build/operator/identity_attach_KL_sparse_reg.o build/operator/leaky_relu.o build/operator/lrn.o build/operator/native_op.o build/operator/ndarray_op.o build/operator/operator.o build/operator/pooling.o build/operator/regression_output.o build/operator/reshape.o build/operator/slice_channel.o build/operator/softmax_activation.o build/operator/softmax_output.o build/operator/swapaxis.o build/operator/upsampling.o build/optimizer/optimizer.o build/optimizer/sgd.o build/storage/storage.o build/symbol/graph_executor.o build/symbol/static_graph.o build/symbol/symbol.o dmlc-core/libdmlc.a -pthread -lm -lcblas -lrt -lcblas pkg-config --libs opencv
/usr/local/lib/libcblas.a(sdotsub.o): In function sdotsub_': sdotsub.f:(.text+0x7): undefined reference to sdot_'
/usr/local/lib/libcblas.a(cblas_sgemm.o): In function cblas_sgemm': cblas_sgemm.c:(.text+0x13c): undefined reference to sgemm_'
cblas_sgemm.c:(.text+0x1e6): undefined reference to `sgemm_'
collect2: error: ld returned 1 exit status
make: *** [bin/im2rec] Error 1

What do you mean "I have put libblas.a libcblas.a to /usr/local/lib"? Where did they come from? Which blas library are you using?

Was due to incomplete installation of blas, consider change blas version to for example open blas, might be the quickest way to solve the issue

Hi, I have tried openblas, and fixed the problem. Thank you


Pairwise analysis will fail after performing single system analysis

Reproduce: (production)

select one system to perform single system analysis
select two systems to perform pairwise analysis

log:
An error occurred in the analysis.
If you are doing a pair-wise analysis, double check if the selected systems use the same dataset.
If you found a bug, kindly open an issue on [our GitHub repo](https://github.com/neulab/explainaboard_web). Thanks!

closed this due to https://github.com/neulab/explainaboard_web/issues/532


New version: AutocorrelationShell v0.1.2

Registering package: AutocorrelationShell
Repository: https://github.com/ShozenD/AutocorrelationShell.jl
Created by: @ShozenD
Version: v0.1.2
Commit: df3242f715ac7cc59ab25aa7d4f1c8ff4d104cd2
Reviewed by: @ShozenD
Reference: https://github.com/ShozenD/AutocorrelationShell.jl/issues/1#issuecomment-793441727

@giordano I have talked with some people about the license issue. Is the JuliaRegistry willing to accept packages with a BSD license with an added restriction on commercialization? While we would like to keep this package open-source(in the name of science) and on the JuliaRegistry, it was developed in part under a university grant and this requires an added clause.

Unfortunately, the license must be in the list of licenses approved by the OSI. A full list is here: https://opensource.org/licenses/alphabetical
Are there any licenses in that list that would be acceptable for your use case?

Maybe something like the GPL or AGPL would work for your purposes? Both of those are OSI-approved.

To be clear, a license like GPL does allow commercialisation, but its nature makes commercialisation of a GPL software relatively impractical.
Also, to explain the rationale of sticking to OSI-approved license: this registry is maintained by volunteers, we don't have a legal team that can thoroughly review any added clause, as simple as it may seem to you.  Restriction of use (like no commercialisation), however, often goes against some definitions of open source software (it certainly violates one of the freedoms in the definition of free software).  Simply using OSI-approved licenses with no added custom clauses is the best way for us to ensure we have packages legally sounding license.

@DilumAluthge @giordano Thank you very much for your suggestions and clarifications! and I see your point. I'm currently in contact with the software license/patent office at the university to see if we can use the license you suggested!

I will add here that any "no commercialization" clause is almost certain to conflict with the GPL: the GPL requires that the derived work be available under terms compatible with the GPL, which guarantees a wide range of freedoms, regardless of the nature of the application. Since Julia by default ships with GPL libraries, it is very likely that any work derived from this a package with this license would be illegal. While it's probably ok to have the end user load the package themselves, it is likely that any application that includes the package would not be legal. It would be necessary to compile a no-GPL version of Julia from source in order to legally create a work derived from the package.
This is one of the reasons we don't allow non-OSI licenses: it is very easy accidentally wander into legally murky territory when combining common OSI licenses like GPL with non-OSI licenses and we don't want to subject Julia users to that hazard when installing packages registered in General. Even within OSI, there are combinations of OSI licenses which are not legal to use, such as GPL2 with Apache2. Fortunately these days Julia itself is mostly GPL-free and the remaining GPL dependency (SuiteSparse) is GPL2+ which is compatible with Apache2 since GPL3 was carefully crafted to avoid the incompatibility. I'm not aware of any OSI-approved licenses that are incompatible with Julia, but essentially any non-open clause is incompatible because of the GPL2+ dependency on SuiteSparse. Even if we completely removed all GPL dependencies from Julia itself (a long-standing project), since there are GPL packages in General, we would still not allow non-OSI packages since they are so likely to be illegal to combine with GPL packages in General.


Metal Archives handling of lyrics

This is just to chime in on your message to H2Swine about having Openlyrics continue to search past Metal Archives if the results produce a "(lyrics not available)" return.
The Metal Archives website returns the message "(lyrics not available)" if an Advanced Search (Band and song title) DOES find a hit for that band and song on the website but the lyrics for that song are not available to them.  In that case, clicking on the "Lyrics" column in the Search results will show the "(lyrics not available)" message below the search results line.  A full example is below:

It would be nice if OpenLyrics could interpret that as a non-hit and just continue to another provider.  Another popular source that behaves like this is SongLyrics, which in the same circumstance will return a message "We do not have have the lyrics for (song title) yet" and the search stops. Example from website:

Thanks for the examples. Tagging @H2Swine for visibility in case they'd like to add anything or track this.
For completeness, the comment you're referring to is in #253 (specifically this one)

Just for simple examples in the Metal Archives lyrics URL format:
Available: https://www.metal-archives.com/release/ajax-view-lyrics/id/1234
Not available: https://www.metal-archives.com/release/ajax-view-lyrics/id/12345

@jacquesh show a popup to notify user of new features and sources I just remembered metal-archived is added


vcard and json API

It should be easy to (read-only) access the user data and the data of his/her followees by an API. We start with these common formats:

vCard 3.0 (https://en.wikipedia.org/wiki/VCard)
JSON

The URL to access this API should start with /api/v1.0/ and than follows the normal route.
Examples:

/api/v1.0/users/:slug.vcard
/api/v1.0/users/:slug.json
/api/v1.0/users/:slug/followees/index.json

I'm going to start with jcard, commit, and work on vcard 3.0 later.

http://jsonapi.org/

resources "/vcard" is wrong. It should be /api/1.0/users/stefan.wintermeyer.json. Please have a look at http://jsonapi.org/ to get an idea. Any developer who uses the normal website should be able to use the API by just knowing the prefix /api/1.0/.

I have implemented the vcard (jcard) export according to http://jsonapi.org/ in commit 27554de. Before I continue to build onto the API let me know if you'd like me to do anything different.

The URL is wrong. It shouldn't be http://localhost:4000/api/1.0/users/stefan.wintermeyer/vcard but http://localhost:4000/api/1.0/users/stefan.wintermeyer.vcard for my account. Plus the vcard format is not right yet. A vcard file doesn't use the JSON format. It looks like this:
BEGIN:VCARD
VERSION:3.0
N:Gump;Forrest;;Mr.
FN:Forrest Gump
ORG:Bubba Gump Shrimp Co.
TITLE:Shrimp Man
PHOTO;VALUE=URI;TYPE=GIF:http://www.example.com/dir_photos/my_photo.gif
TEL;TYPE=WORK,VOICE:(111) 555-1212
TEL;TYPE=HOME,VOICE:(404) 555-1212
ADR;TYPE=WORK,PREF:;;100 Waters Edge;Baytown;LA;30314;United States of Amer
 ica
LABEL;TYPE=WORK,PREF:100 Waters Edge\nBaytown\, LA 30314\nUnited States of
 America
ADR;TYPE=HOME:;;42 Plantation St.;Baytown;LA;30314;United States of America
LABEL;TYPE=HOME:42 Plantation St.\nBaytown\, LA 30314\nUnited States of Ame
 rica
<EMAIL_ADDRESS>REV:2008-04-24T19:52:43Z
END:VCARD


Simple tasks implementation

How to use:
mix.task('login-page', () => {
    mix.js('resources/assets/js/pages/auth/login.js', 'public/assets/js/pages')
        .sass('resources/assets/sass/pages/auth/login.scss', 'public/assets/css/pages')
});

mix.task('register-page', () => {
    mix.js('resources/assets/js/pages/auth/register.js', 'public/assets/js/pages')
        .sass('resources/assets/sass/pages/auth/register.scss', 'public/assets/css/pages')
});

mix.extract(['vue']);
mix.sass('resources/assets/sass/main/app.scss', 'public/assets/css');

// Combined task. Running this task will cause in running all tasks specified in second argument.
mix.task('auth', ['login-page', 'register-page']);

To run specific tasks: node run dev -- --env.tasks=login-page or node run dev -- --env.tasks=login-page,register-page. Or you can use special task keyword "all" for run all defined tasks.
Unfortunately, i didn't find the more convenient way for providing tasks into script. In my opinion --env.tasks = looks some ugly. If somebody knows how the same can be achieved in another way, please say)

webpack freaks out if you pass unknown arguments to it, so --env is pretty much the only option that could be done from the command-line in mix's current form. (Technically, I believe you could use cross-env and process.env if you wanted, i.e., cross-env tasks=login-page npm run dev)

Would many of you use this feature? I'm trying to think when I would personally want this.

My humble opinion in support)
This is just possibility to build a part of your application. For example, i change only one line in styles and want to deploy this to production. With tasks i can just run specific task, which suited for buildings styles, without need to rebuild all assets (why i need to rebuild js if fix styles :thinking: ). Also i think this is more component way approach)

@JeffreyWay YES! Build main app and admin panel separately, for example. Or different parts of an app, if it is modular (happens sometimes), or compile separate themes

+1

My instinct for now is to say no.  But we can always come back to this later.


Edit instructor added and made editable

Coverage increased (+0.1%) to 81.303% when pulling 004bd151d77fad8af409b20d4744af9dfaea5feb on thesisshow into 5e739f4d438c934b9fa8c1482cca9bc1d39155da on master.


Pin packages for lustre-ldiskfs-zfs

fixed by: https://github.com/whamcloud/lustre-ldiskfs-zfs/pull/21


bug: TypeScript type reduced to 'never' (GitHub integration)

Provide environment information
System:
OS: Linux 5.15 Ubuntu 20.04.4 LTS (Focal Fossa)
CPU: (20) x64 12th Gen Intel(R) Core(TM) i7-12700K
Memory: 6.85 GB / 9.71 GB
Container: Yes
Shell: 5.8 - /usr/bin/zsh
Binaries:
Node: 18.17.1 - ~/.nvm/versions/node/v18.17.1/bin/node
Yarn: 1.22.19 - ~/.yarn/bin/yarn
npm: 9.6.7 - ~/.nvm/versions/node/v18.17.1/bin/npm
pnpm: 8.10.4 - ~/.local/share/pnpm/pnpm
bun: 1.0.0 - ~/.bun/bin/bun
Describe the bug
Trying to use the GitHub integration and saw this error appear.  This happens when trying to access anything on the issue property.

Property 'number' does not exist on type 'never'.
  The intersection 'Issue & { state: "open"; closed_at: null; }' was reduced to 'never' because property 'closed_at' has conflicting types in some constituents.

Reproduction repo
N/A
To reproduce
Create a new job with a GitHub integration, and attempt to use a method that relies on Issue type.
Additional information
No response

Thanks for reporting this!
Your tsconfig needs to have strict or at the very least strictNullChecks enabled for types to work as they should. They come straight from Octokit.
Reproduction:

Fails with strictNullChecks disabled
Works with strictNullChecks enabled

Thanks for reporting this!
Your tsconfig needs to have strict or at the very least strictNullChecks enabled for types to work as they should. They come straight from Octokit.
Reproduction:

Fails with strictNullChecks disabled
Works with strictNullChecks enabled

Ah, that did it! Yeah, I had stricky: true but strictNullChecks: false. Flipping that did the job 🎉


Update cacher table tblSummoners to include regional identifier

Regional identifier is not currently saved nor checked against when pulling a given summoner id from the cache.
Lets change this as in cases where the same summoner id is found in multiple regions (fairly common), the cacher has no way to differentiate between the summoner names.

Will be done in 2.0


Stack backtrace is printed after shell prompt

...
0.000000 INFO  (7/10) running `filter_list32_std`...
└─ integration::tests::__defmt_test_entry @ tests/integration.rs:73
0.000000 INFO  (8/10) running `filter_list32_ext`...
└─ integration::tests::__defmt_test_entry @ tests/integration.rs:73
0.000000 INFO  (9/10) running `dequeue_lower_priority_frame`...
└─ integration::tests::__defmt_test_entry @ tests/integration.rs:73
0.000000 INFO  (10/10) running `ext_roundtrip`...
└─ integration::tests::__defmt_test_entry @ tests/integration.rs:73
^C⏎
~/dev/bxcan/testsuite *master> stack backtrace:
   0: core::ptr::read_volatile
        at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:1042
   1: vcell::VolatileCell<T>::get
        at /home/jonas/.cargo/registry/src/github.com-1ecc6299db9ec823/vcell-0.1.2/src/lib.rs:32
   2: bxcan::pac::generic::Reg<U,REG>::read
        at /home/jonas/dev/bxcan/src/pac/generic.rs:52
   3: bxcan::Tx<I>::is_idle
        at /home/jonas/dev/bxcan/src/lib.rs:589
   4: bxcan::Can<I>::is_transmitter_idle
        at /home/jonas/dev/bxcan/src/lib.rs:385
   5: integration::tests::ext_roundtrip
        at tests/integration.rs:417
   6: main
        at tests/integration.rs:73
   7: Reset
        at /home/jonas/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rt-0.6.13/src/lib.rs:526

Note how the shell prompt shows up between the defmt output and the stacktrace. Not really sure what causes this behavior, but we might need to add a flush somewhere?

Were these the tests you were running? https://github.com/stm32-rs/bxcan/blob/master/testsuite/tests/integration.rs

Yeah


Fixes "return null" problem in issue #1509.

Changed so that functions that could return a value also could return null.

I think you should change {% if operation.HasResultType %} to {% if operation.HasResultType and SupportsStrictNullChecks %} so that this is only rendered for supported TS versions...

(I know that probably no one still uses that old versions :-)

What do you think?
Anyway thanks for the PR!

Ah, you’re right :-) I didn’t know such check existed :-) I will change it later today or tomorrow.

Ok, I've made the change. Thanks for the PR!


Pinning of seven_zip dependency using ~> prevents users from selecting version 3.0.0

The current seven_zip dependency declaration is impacting our ability to use the most current version of the seven_zip cookbook.
Consider using >= 2.0.0 instead of ~> 2.0.0

Hi @estenrye,
Thank you for reporting this issue. I fixed it in version v2.0.3


deepin.dtkcore: <IP_ADDRESS> -> <IP_ADDRESS>

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/dtkcore/versions.
meta.description for deepin.dtkcore is: '"Deepin tool kit core modules"'.
Compare changes on GitHub

Checks done (click to expand)

built on NixOS

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found <IP_ADDRESS> with grep in /nix/store/vga4dxa8mmsbyqmzddrl9fqk57wkdr25-dtkcore-<IP_ADDRESS>

directory tree listing: https://gist.github.com/1c1a357eb8d9a61b396680a9a0d45198

du listing: https://gist.github.com/d3743e0237eafef03f3b6268f72eb182

Rebuild report (if merged into master) (click to expand)

33 total rebuild path(s)
11 package rebuild(s)
11 x86_64-linux rebuild(s)
11 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
11 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
deepin.dde-calendar
deepin.dde-session-ui
deepin.deepin-image-viewer
deepin.deepin-menu
deepin.deepin-movie-reborn
deepin.deepin-shortcut-viewer
deepin.deepin-terminal
deepin.dtkcore
deepin.dtkwidget
deepin.dtkwm
deepin.qt5integration

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/vga4dxa8mmsbyqmzddrl9fqk57wkdr25-dtkcore-<IP_ADDRESS> \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A deepin.dtkcore https://github.com/r-ryantm/nixpkgs/archive/587ec2e939c89faeb54d38f0ce5bcc4333530167.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/vga4dxa8mmsbyqmzddrl9fqk57wkdr25-dtkcore-<IP_ADDRESS>
ls -la /nix/store/vga4dxa8mmsbyqmzddrl9fqk57wkdr25-dtkcore-<IP_ADDRESS>/bin

cc @romildo for testing.

I am preparing updates, new packages and fixes for deepin. So I would like to not have this update merged.


Error Help: Payment system must be installed to perform this action

Hi I am trying to get gdx-pay integrated into my project but am running into a strange error I cant seem to understand the cause of.
I setup the pay library as outlined in the wiki and sample project page, I am only trying to use test ids (android.test.purchased) on android phone which is on version 7.1.1, but keep getting the following error?
public final static String productID_fullVersion = "android.test.purchased";

06-02 16:42:56.783 31061-31085/com.mygdx.enso.android I/GdxPay/IAP: IAP: gdx-pay successfully instantiated.
06-02 16:42:56.783 31061-31085/com.mygdx.enso.android E/myPurchaseSystem:: com.badlogic.gdx.pay.android.googleplay.AndroidGooglePlayPurchaseManager@fcaa47f
    Canceltestpurchases supported!
06-02 16:42:56.813 31061-31085/com.mygdx.enso.android E/AndroidRuntime: FATAL EXCEPTION: GLThread 3933
    Process: com.mygdx.enso.android, PID: 31061
    com.badlogic.gdx.pay.android.googleplay.GdxPayException: Payment system must be installed to perform this action.
        at com.badlogic.gdx.pay.android.googleplay.AndroidGooglePlayPurchaseManager.assertInstalled(AndroidGooglePlayPurchaseManager.java:312)
        at com.badlogic.gdx.pay.android.googleplay.AndroidGooglePlayPurchaseManager.purchase(AndroidGooglePlayPurchaseManager.java:192)
        at com.badlogic.gdx.pay.PurchaseSystem.purchase(PurchaseSystem.java:148)
        at com.mygdx.enso.PlatformResolver.requestPurchase(PlatformResolver.java:47)
        at com.mygdx.enso.screens.ScreenLeaderboards$11.clicked(ScreenLeaderboards.java:330)
        at com.badlogic.gdx.scenes.scene2d.utils.ClickListener.touchUp(ClickListener.java:89)
        at com.badlogic.gdx.scenes.scene2d.InputListener.handle(InputListener.java:59)
        at com.badlogic.gdx.scenes.scene2d.Stage.touchUp(Stage.java:351)
        at com.badlogic.gdx.InputMultiplexer.touchUp(InputMultiplexer.java:96)
        at com.badlogic.gdx.backends.android.AndroidInput.processEvents(AndroidInput.java:383)
        at com.badlogic.gdx.backends.android.AndroidGraphics.onDrawFrame(AndroidGraphics.java:493)
        at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1548)
        at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1259)

I am calling these methods on button click when the error occurs when calling requestPurchase():
if (PurchaseSystem.hasManager())
Gdx.app.error("myPurchaseSystem:", PurchaseSystem.getManager().toString());

PurchaseManager manager = PurchaseSystem.getManager();
if (manager instanceof PurchaseManagerTestSupport) {
//((PurchaseManagerTestSupport) manager).cancelTestPurchases();
Gdx.app.error("myPurchaseSystem:", "Canceltestpurchases supported!");
}

topControlRef.getPlatformResolver().requestPurchase(topControlRef.productID_fullVersion);

I also called AndroidGooglePlayPurchaseManager.isRunningViaGooglePlay() which returned true and the error seems to be related to this following method in AndroidGooglePlayPurchaseManager :
 private void assertInstalled() {
        if (!installed()) {
            throw new GdxPayException("Payment system must be installed to perform this action.");
        }
    }

   @Override
    public boolean installed() {
        return googleInAppBillingService.isListeningForConnections();
    }

Also noticed the following message in logcat:
06-02 18:16:29.273 1554-1554/com.mygdx.enso.android D/GdxPay/V3GoogleIABS: start onServiceConnected(), isConnected() is: false

any help would be greatly appreciated.....

Fixed: calling PurchaseSystem.onAppRestarted(); at the incorrect location in code seems to have been the cause of the problem. :)


Plans for Draft 2019-09 and 2020-12

Hi,
I'm just writing to get a little bit of insight into AJV's plans for updating the default schema specification (currently to draft-07) and what the key indicators are for the AJV project to consider updating the default specification to either draft-2019-09 or draft-2020-12.
I'm actually not too familiar with how JSON schema drafts work these days. Would the AJV project be waiting on some finalized specification for draft-8 or are JSON schema drafts rolling out on the current year-month scheme for future publishing of the specification?
I guess my question is, if JSON-schema is rolling out on year-month specs from this point forward, would this mean that AJV will continue on the require("ajv/dist/2019") approach to retro fit updates on the spec over draft-7, or is AJV just waiting on a possible draft-8 to be finalized before moving over to that as a default?
I actually have some downstream projects that would like to rely on some of the features of the 2019-09 draft, but unsure if it's worth taking the 2019 functionality in it's current form, or waiting until some of these newer features roll into the default specification for AJV.
Any insights you can provide would be very helpful.
Many Thanks
S

draft-2019-09 was a big change from draft-07, and draft-2020-12 introduced another major breaking change for “items”.
I’d like to see it stabilising - I think that the change for items in 2020 is quite unintuitive and hopefully will be reverted by the time it gets to RFC.
Neither is a criteria to make it a default in Ajv though, and if they become default I wouldn’t see it as an indication of their longevity in JSON schema spec…
The reason draft-07 is the default is that draft-2019/2020 compilation needs to add extra code even if it’s new features are not used - so it will remain opt-in rather than default, as many users don’t need these features.
I’m not sure what to suggest to be honest - if you do need to use draft2019 (or 2020) features you should use respective exports - both are stable implementations.
For simple API validation I am using JTD lately, but for any advanced scenarios 2019 is often better - this trade off is in the docs (Choosing schema language)

@epoberezkin Hey, thanks for the insights. I don't work very closely with emerging JSON schema draft specifications, so it's interesting learning what the AJV engineers have to reconcile when things change from the draft to draft. I appreciate that changing specifications must be very awkward to code against.

I’d like to see it stabilising - I think that the change for items in 2020 is quite unintuitive and hopefully will be reverted by the time it gets to RFC.

Yeah, this is quite interesting. I'm curious, is there a mailing list or community were one can get up to speed on possible reverts to the drafts? I'm not familiar with the 2020 change to items but will try do some reading up on that (I'm surprised something as fundamental as items could break). Historically, it's been quite difficult to find specific information and reasoning on each new schema draft (particularly for the intended downstream use-cases). I will say tho, the potential for items to be reverted (in whatever form it currently is in) does certainly raise some uncertainly with respect to adopting new functionality in these drafts.

The reason draft-07 is the default is that draft-2019/2020 compilation needs to add extra code even if it’s new features are not used - so it will remain opt-in rather than default, as many users don’t need these features.

Mostly I'm just interested in the 2019-09 spec for unevaluatedProperties in tandem with allOf, mostly to facilitate composition of intersection types for this project. The main motivation is for the library to produce idealized schemas to match the TypeScript type system, of which, Type.Intersect(...) does see quite a bit of usage (as users are approaching type composition from TS perspective and expecting an appropriate JSON schema representation to be created for them).
Currently the library is fudging intersections by mashing two schemas together manually (and is currently locked at draft 6), but the preference would be to leverage draft-2019-09 to take advantage of unevaluatedProperties and get better compositional usage from JSON schema. The uncertainty however arises around if it's reasonable for this library to generate 2019-09 schemas if the 2019-09 draft is still up in the air. I've held back implementing unevaluatedProperties as a result.
In your opinion, how stable do you feel unevaluatedProperties is on the 2019-09 draft? Is there a potential for this to change also? (From what I understand, there was a lot of discussion around unevaluatedProperties, but I'm unfamiliar with any contention there, or potential for this to be reverted also).
Sure would be good if JSON schema finally settled on a final specification everyone could work against. But thank you for your excellent work on AJV, it's an excellent library.
Regards
S


Benchmark

Some significant speed improvements by processing many rows per warp. Added benchmarking scripts and updated readme with result.

rerun checks


Migration Engine: Reenable NOT NULL constraints for required relation fields

We used this as a temporary workaround while the query engine was not able to perform write flipping yet.

Will fix https://github.com/prisma/lift/issues/98

Closed with https://github.com/prisma/prisma-engine/pull/134


Library works from Python 2.7+ (Compatible with all 3.x versions)

Hi,
Thanks for your contribution!
Let us test your suggested changes and verify them and we'll update you as soon as we can continue.


fix(cli): Skip tracing-chrome for platforms without 64bit atomics

See rust-lang/rust#122054
I also created thoren-d/tracing-chrome#27

Well, we might want to add some comments for this?
Anyway, let's merge this for now.
@bors r+

:pushpin: Commit 307ad0c4966dcde99535d0d029e5ed674d43b637 has been approved by weihanglo
It is now in the queue for this repository.

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing a4c63fe5388beaa09e5f91196c86addab0a03580 to master...


Modify docs for 22.02 to address issue-4319[skip ci]

Modify docs for 22.02 to address issues in 4319. contributes to #4319
Signed-off-by: Hao Zhu<EMAIL_ADDRESS>
remove not-released RapidsShuffleManager manager.
Change some “GPU Architecture” to "GPU Models"

build


Title: Redirect to ontributer accout

Initiative (Required)
GSSoC (Girl Script Summer of Code) 🌸
Is your feature request related to a problem? Please describe.
There is Contributors section in that when we click on some contributer it must be redirect to that contributer's Github profie.. . that is not available in current system..
Describe the solution you'd like.
it must be redirect to that contributer's Github profie.. . that is not available in current system..
Add any other context or screenshots about the feature request here.
No response

/assign

@Kushal997-das Can i work on it ??


Handle Connection Errors for Bad Twitter Streaming Request 406

If there is a problem with the credentials or query parameters provided by the user the node falls over and the user needs to manually edit the flow.json to enable the node to start. This needs to be addressed through validations on the Node-Input fields and/or exception handling.

Added validations if any coordinates provided:

Are all four coordinates provided?
Do coordinates fall within expected ranges? (N: 90 / S: -90 / E: 180 / W: -180)
Are the South and West coordinate values less than the North and East coordinates?


Any react version template update ?

I would love to know as well.
I tired using this with plugin-react but failed to do so.
The react plugin is a 1-page application that seems to have it's index.html file to be in the main folder (outside of the src folder).
I either can't compile it because of that clashing with the manifest file or I am able to build but then the react app doesn't show after loading the extension to chrome with the following error:
Error: Minified React error #31; visit https://reactjs.org/docs/error-decoder.html?invariant=31&args[]=%5Bobject%20Promise%5D for the full message or use the non-minified dev environment for full errors and additional helpful warnings.


For search sub-command, don't print files that do NOT have the search term(s).

Currently, it still prints them, but with a matching line count of 0. Probably, use awk after grep to filter out lines that end in :0.

Done as of commit df54b6e2c2ed2b6ab0226449f4d2658d51c13820.


Porting to ESP8266 Arduino

Hi,
I'm porting my_basic to ESP8266 2.3.0 and Arduino 1.6.12. I found that there is an alignment error that causes system to hang. I guess pointer variables in structures must be aligned to dword. For example, the following structure, "bool_t valid;" is one byte so the following variables would be un-aligned and causes hang.
typedef struct mb_interpreter_t {
/** Fundamental /
bool_t valid;
void userdata;
_ls_node_t* ast;
So I added three dummy "bool_t"s to align variables. Then it worked fine.
typedef struct mb_interpreter_t {
/** Fundamental /
bool_t valid;
bool_t dummy1;
bool_t dummy2;
bool_t dummy3;
void userdata;
_ls_node_t* ast;
I think that it can be fixed by adding some compile switches to force align variables but I'm not familiar with those compiler switches. If you can address this issue and fix it for future release, that would be great.
Thanks!

Hi,
Thank you for posting. Looks like an alignment error indeed. Please try comment the line #	define MB_COMPACT_MODE in my_basic.h, thus the compiler should decide the alignment by itself. Hope this helps. BTW. where can I get a full specification of ESP8266?
Sincerely

You can find info about esp8266 from http://esp8266.net. I will try MB_COMPAT_MODE and let you know see if it works.

Hi,
I recompiled with MB_COMPAT_MODE commented out and it works fine now. Thanks a lot!


Setup proguard for the Godot Android Editor build

This reduces the generated apk size by ~1MB.
Based off https://github.com/godotengine/godot/pull/31509
Related to https://github.com/godotengine/godot-proposals/issues/3931

Can you clarify the reason for abandoning this one? I see it was still a draft, are there issues with enabling Proguard that outweigh the benefits?

Can you clarify the reason for abandoning this one? I see it was still a draft, are there issues with enabling Proguard that outweigh the benefits?

Mostly due to the need for this being low to inexistant. The PR was attempting to set up proguard for the Android Editor, but from a quick test it only saves about ~1MB which based off the latest 4.3-dev3 build is only about a ~0.6% saving.
There is still a use-case for setting up proguard for the template release builds, but that is addressed by https://github.com/godotengine/godot/pull/31509.


Issues when mixing @Arg with and without name

i was using simple @Arg(column, type). Tried to add name=... to some args that had the same type, to make things more resilient. this broke the mapper.

having name's on just some args of a resultMap doesn't seem supported (would be nice)
since it isn't, can an additional check be added for such situations that throws something better worded about this not being supported?
a broken mapper may actually be created if another constructor matches the args with name. see test case below, that should throw a different exception right now

MyBatis version
4.5.13, current master
Test case or example project
public class PartialArgsTest {

  record Post(String section, Timestamp createdOn, String subject) {
    public Post(String section, Timestamp subject) {
      this(null, null, null);
    }
  }

  interface Mapper {
    @Select("SELECT * FROM post")
    @Arg(column = "SECTION", name = "section", javaType = String.class)
    @Arg(column = "CREATED_ON", javaType = Timestamp.class)
    @Arg(column = "SUBJECT", name = "subject", javaType = String.class)
    List<Post> getPosts();
  }

  @Test()
  void shouldGetData() throws Exception {
    final Environment environment = new Environment("test", new JdbcTransactionFactory(),
      BaseDataTest.createBlogDataSource());
    final Configuration config = new Configuration(environment);

    assertThrows(BuilderException.class, () -> {
      config.addMapper(Mapper.class);
    });

    /* how to continue if partial names would be supported (but actually throws right now):
    var sqlSessionFactory = new SqlSessionFactoryBuilder().build(config);
    try (SqlSession session = sqlSessionFactory.openSession()) {
      Mapper mapper = session.getMapper(Mapper.class);
      mapper.getPosts();
    }
    */
  }
}

record Post(String section, Timestamp createdOn, String subject) {
public Post(String section, Timestamp subject) {
this(null, null, null);
}
}
Something is wrong here

Something is wrong here

This minimalist example is absurd, yes, since it is stripped down to only the parts necessary to highlight the bug.

Doesn't look like there is any interest, so i'll just close this issue


inherent gpio methods

See https://github.com/esp-rs/esp-hal/pull/1273#issuecomment-1995219928

Thanks for the PR.
We're still discussing what we're going to do regarding the various embedded-hal traits, so I'm hesitant to start refactoring our drivers specifically to accommodate them. Assuming that embedded-hal-compat gets updated, I'm leaning towards dropping the<EMAIL_ADDRESS>trait implementations entirely, though there still needs to be some discussion surrounding this.
I think given our current implementations that this PR is completely reasonable, however I think I would prefer to come to a decision regarding embedded-hal before committing to refactoring a bunch of drivers.

Maybe we could split this PR into two bits, the inherent infallible methods on the GPIO structs and the eh trait refactoring? Imo the inherent infallible methods we can accept now, before figuring out what to do with the traits.

I like the idea of putting the hal implementations into modules

Rebased.

I like the idea of putting the hal implementations into modules

I very much don't, but guess I won't be too stubborn about it. I'd like some guarantee that all of the other modules implementing these traits will be updated, because otherwise I have a feeling I will have to do this myself.

I like the idea of putting the hal implementations into modules

I personally like to have it in modules - I don't like to have it in different files t.b.h.

Is problem in mod's or different files?

At the end of the day it's largely just a matter of consistency, I guess my personal preferences don't matter as much (I seem to be in the minority as is often the case, anyway).
I've been putting a lot of work into trying to make our code base more consistent (this is still ongoing), and this feels like a step backwards unless these changes are made for all applicable modules. I think it's reasonable for contributors to expect our drivers to be structured in similar ways, and I can see having only one or two driver like this causing confusion (or, we'll have to explain to contributors constantly what is expected in this regard).
Given the above, it follows that we should also split out modules for all other third-party trait packages, and this seems tedious and like a lot of work for essentially zero tangible gain.
But, I won't argue any more about this I suppose. Just my $0.02

Is now better?


Potential Enhancements

First off great work! I really like this, and it really makes my workflow faster testing and diagnosing issues.
I have two potential enhancements that I would like to propose (I am happy too do them). In order of what I think is important to me (and maybe others)

Is there to add a header or commented title saying that this is a modified by hostess, that way you can kind of seperate manual entries (obviously this could be via a external script)

An Enhancements, being a way to remove host entries via regex, so a *.google.com or *.github.com would be really good feature to have. For, now I can work around this with a wrapper script but  its bit clunky.

What do you think?

Thanks for the feedback!

Is there to add a header or commented title saying that this is a modified by hostess, that way you can kind of seperate manual entries (obviously this could be via a external script)

What are you trying to do with this? This is the kind of feature that I could add but I don't have a reason to, so I'm curious what you're trying to accomplish.

An Enhancements, being a way to remove host entries via regex, so a *.google.com or *.github.com would be really good feature to have. For, now I can work around this with a wrapper script but its bit clunky.

Your example uses glob-like syntax rather than regexp. I think this actually makes more sense for hostnames because escaping . for regexp would be a bit tedious. I'd be happy to add this for on/off/rm and other commands that make sense to use with multiple hostnames.


Slow react tests

Describe your problem and how to reproduce it:
Several React challenges have asynchronous tests that include numerous timeouts.  This can cause npm run test to fail randomly causing ci tests to, mistakenly, flag a commit as failing when it should not.  Most recently curriculum/challenges/english/03-front-end-libraries/react/add-event-listeners.english.md failed, but it may not be the only one.
I don't think there is a need to wait, since the testing framework is synchronous. So, they should be re-written as synchronous tests.
Reproduction is difficult, but it should be fixed if the tests run quickly (i.e under a second).

@ojeytonwilliams , is this still something worth working on?

@Sky020 Sure thing.
It won't be necessary to change all challenges with redundant timeouts. If you time them and fix any of the worst offenders that would be great.

I have been unable to even get the tests to finish with npm run test:curriculum
I get this error:
  8387 passing (6m)
  568 pending
  2 failing

  1) Check challenges
       Check challenges (english)
         Access the JSON Data from an API
           Test suite must fail on the initial contents:
     Error: Timeout of 6000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (C:\Users\shauh\Documents\freeCodeCamp\freeCodeCamp\curriculum\test\test-challenges.js)
      at listOnTimeout (internal/timers.js:531:17)
      at processTimers (internal/timers.js:475:7)

  2) Check challenges
       "after all" hook:
     Uncaught Error: unhandledRejection: Error, Protocol error (Runtime.callFunctionOn): Target closed.
      at process.<anonymous> (test\test-challenges.js:94:11)
      at processPromiseRejections (internal/process/promises.js:165:18)
      at processTicksAndRejections (internal/process/task_queues.js:90:32)

I have tried changing the flags in the package.json in curriculum. I have removed --bailout, and cannot find any useful flags for purposes of timing in the Mocha documentation.
Also, what has happened to the functionality of this:
npm run test:curriculum --block='React'

Or:
npm run test -- -g 'Add Event Listeners'

Neither work. The whole test suite is run.
@ojeytonwilliams , could you help by pointing in the correct direction?

@Sky020 I've sent you a message on Gitter about the failing tests.
To get timing info from Mocha, you can use
 "test": "mocha --delay --reporter spec --bail"

in scripts and then search the output for any tests with 4 digit times.  When I did that I found:

Use Array.filter() to Dynamically Filter an Array
Use Advanced JavaScript in React Render Method
Use a Ternary Expression for Conditional Rendering
Render Conditionally from Props
Optimize Re-Renders with shouldComponentUpdate
Create a Controlled Form

Any of those would be worth investigating.

 Slow React Tests


GO:1905224 clathrin-coated pit assembly

Is described as a "membrane assembly", that doesn't seem right? it happens to a membrane but the membrane is already there?

Thats why curators use the "Quick fix label" its a "hey look I'm quick to fix" , we just use it as a way of shouting....So you can stop us by removing it, and we don't need to preserve any historical usage.... it has no real  administrative use.

The problem seems to be this:

But probably 'membrane region' shoud be 'part of' membrane', not 'is a membrane'???
@ukemi

membrane region is a membrane AND a membrane part

Is this OK ?

If I make 'clathrin-caoted pit'
is_a membrane part, rather than is_a membrane region, then we loose the incorrect inference:


Fix Appveyor fails at 7.4.926

https://groups.google.com/d/msg/vim_dev/IeXBr0P7k7M/xs-rgbAbBwAJ

Sorry for noise.


removing maven-source-plugin execution during verify phase.

This caused Maven releases to deploy source artifacts twice which will be rejected by Nexus if redeploy is disabled and fail the build.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


PolyLine.getLocation(..) not intuitive

The PolyLine2d.getLocation(double) method returns a Ray2d, where the word 'location' suggests the return of a Point2d or an extension of a Point2d such as an OrientedPoint2d. Same for 3d. Sometimes a Ray is useful, sometimes a Point is useful. Both methods should be present, with clear names so users know what to expect. E,g., Polyline2d.getOrentedPointAt(double) and Polyline2d.getRayAt(double) or even Polyline2d.getOrentedPointAtFraction(double) and Polyline2d.getRayAtFraction(double).

Things are quite confusing when the 3D version is concerned.
We may need to create a class DirectedPoint3d, extending Point3d (as does OrientedPoint3d). DirectedPoint3d adds phi and theta, while OrientedPoint3d adds dirX, dirY and dirZ. A Ray3d would extend a DirectedPoint3d. The main difference between a DirectedPoint3d and a Ray3d is the Bounds property.
In 2D, there is less need for a DirectedPoint2d class as there would be no essential difference between a DirectedPoint2d and an OrientedPoint2d (although we could name that added field dirZ in OrientedPoint2d and phi in DirectedPoint2d). The main reason to introduce DirectedPoint2d is naming consistency.
What shall we do?

A DirectedPoint3d is a point in a 3d space with a direction vector. The direction vector is in essence providing a rotation around the Y-axis and around Z-axis to provide a unique direction vector from (0, 0, 0), after which the point is translated to its (x, y, z) position. In essence, all points on a unit sphere around (0, 0, 0) can be reached when one of the two rotations is between 0 and two pi, and the other rotation is between 0 and pi (spherical coordinates). Note that a DirectedPoint3d is a directed vector from a point, not a spherical coordinate itself (a vector (r, dirY, dirZ) from the origin to a point)
A OrientedPoint3d is a point that has a 3-dimensional orientation, This orientation is indicated by three rotation degrees of freedom, sometimes denoted as 'yaw, pitch and roll'. Think about a plane at location (x, y, z), where the plane can point more to the left or right from a top view (rotZ, or yaw), where the nose can be more up or down (e.g., rotY, or pitch), and where the plane can roll along its longitudinal axis (e.g., rotX, or roll). This is one degree of freedom more than the DirectedPoint3d, where the difference of 'roll', or rotX would not be visible; the vector would rotate along its axis, which would not make any difference.

A Ray is different from a DirectedPoint or an OrientedPoint. A Ray is, in a sense, a directed LineSegment and not a directed Point (!). That is also why the Bounds if a Ray return a half-space and not a point (a degenerate bounds where minX = maxX, minY = maxY, and minZ = maxZ).
Since the coordinates of a Ray go to infinity, we cannot store the start point and end point, but have to store it as a start point and a direction. This looks the same as a DirectedPoint, but it is a truly different concept.

If the above descriptions make sense, we might add some of them to the Javadoc of the respective interfaces and classes to clarify our interpretation of the concepts in djutils-draw.

I think it (mostly) makes sense.
GetLocation & friends should return a DirectedPoint.
If we really need something that creates a Ray at a location, we can name that method getRayAt, or something similar.
For now, I would like to change the object returned by getLocation methods to a DirectedPoint.

For me, that makes perfect sense!

Makes sense to me. Alternatively there could be Ray2d = DirectedPoint2d.toRay() and DirectedPoint2d Ray2d.toDirectedPoint() methods. They can even share the same information if one is implemented based on the other, i.e. something like:
public class DirectedPoint2d implements Point<DirectedPoint2d>
{
    final double x;

    final double y;

    final double rotZ;

    private Ray2d ray = null;

    public DirectedPoint2d(final double x, final double y, final double rotZ)
    {
        this.x = x;
        this.y = y;
        this.rotZ = rotZ;
    }

    public Ray2d asRay()
    {
        if (this.ray == null)
        {
            this.ray = new Ray2d(this);
        }
        return this.ray;
    }

    public Bounds2d getBounds()
    {
        return new Bounds2d(this.x, this.x, this.y, this.y);
    }
}

And:
public static class Ray2d implements Ray<Ray2d, DirectedPoint2d>
{
    private final DirectedPoint2d point;

    Ray2d(final DirectedPoint2d point)
    {
        this.point = point;
    }

    public Ray2d(final double x, final double y, final double rotZ)
    {
        this.point = new DirectedPoint2d(x, y, rotZ);
    }

    public DirectedPoint2d asOrientedPoint()
    {
        return this.point;
    }

    public Bounds2d getBounds()
    {
        if (this.point.rotZ) > 0.5 * Math.PI)
        {
            return new Bounds2d(Double.NEGATIVE_INFINITY, this.point.x, this.point.y, Double.POSITIVE_INFINITY);
        }
        if (this.point.rotZ > 0.0)
        {
            return new Bounds2d(this.point.x, Double.POSITIVE_INFINITY, this.point.y, Double.POSITIVE_INFINITY);
        }
        if (this.point.rotZ < -0.5 * Math.PI)
        {
            return new Bounds2d(Double.NEGATIVE_INFINITY, this.point.x, Double.NEGATIVE_INFINITY, this.point.y);
        }
        return new Bounds2d(this.point.x, Double.POSITIVE_INFINITY, Double.NEGATIVE_INFINITY, this.point.y);
    }
}


Add categories and phrasebooks endpoints

Definition of Done

[ ] Reviewer can follow the flow of the code
[ ] Variables, methods are named properly and clearly
[ ] Methods are documented using comments (where not self-explanatory)
[ ] Any suggestions for refactoring have been implemented
[ ] Tests are created and cover at least 85% of the functionality
[ ] Code is unlikely to introduce new regressions
[ ] Acceptance criteria has been met

Looks good @plasticviking but a few changes/additions:

You can just have one version of categories (the new one), so please make v2 the only version
I noticed that the entry count for categories doesn't include subcategories, so you need an IN query that includes both the parent and children (fv-word:categories/* IN ('UID', 'UID')). Phrase books are flat (no children), but categories can have children one level deep. This is done btw in EnricherUtils -> expandCategoriesToChildren as well.
Also consider that for this to work with sections the FIND_WORDS_WITH_CATEGORY_PP and FIND_PHRASES_WITH_PHRASEBOOK_PP should be looking at fvproxy:proxied_categories when the dialect is a proxy/in sections
One good addition to have is a parentId for child categories, which can be null (or missing) if the category is a parent itself.

Thanks!

I've updated the code to match your suggestions. Should be ready for a final review and merge now.


Can't expand object in debugger variable list

VSCode Version: 1.6.1
OS Version: Windows 7

Steps to Reproduce:

Stop at any breakpoint, debugging javascript
Cannot expand any objects in watch/global list but can watch each variable individually http://i.imgur.com/bLtgZoR.jpg Arrays can be expanded just fine

@Krimik you are using VS Code Insiders and not v1.6.1, correct?

This was 1.6.1, I checked "About", but now this issue fixed itself, I guess restart helped...
Could it have been that I am opening folders on Google Drive ?


ChatterBot Django-training

Hello,
i’m developing a ML Arabic Chatbot using the Chatterbot in a Django application.
So, i set the setting file as follow:
CHATTERBOT = {
    'name': 'Female_bot',
    'storage_adapter' : {'import_path': 'chatterbot.storage.SQLStorageAdapter','database': 'Female'},
    'logic_adapters':[
        {"import_path": "chatterbot.logic.BestMatch",},
        {'import_path': 'chatterbot.logic.LowConfidenceAdapter','threshold': 0.5,'default_response': 'UNK'},],
    'trainer': 'chatterbot.trainers.ChatterBotCorpusTrainer',
    'training_data': ['chatterbot.corpus.Arabic.Fcon'],
}

CHATTERBOT = {
    'name': 'Male_bot',
    'storage_adapter' : {'import_path': 'chatterbot.storage.SQLStorageAdapter','database': ‘Male'},
    'logic_adapters':[
        {"import_path": "chatterbot.logic.BestMatch",},
        {'import_path': 'chatterbot.logic.LowConfidenceAdapter','threshold': 0.5,'default_response': 'UNK'},],
    'trainer': 'chatterbot.trainers.ChatterBotCorpusTrainer',
    'training_data': ['chatterbot.corpus.Arabic.Mcon'],
}

and added the app 'chatterbot.ext.django_chatterbot’, to INSTALLED_APP list. after that i want to train it but i got this:
[mansard@web569 src]$ python3 manage.py train
Mcon.yml Training: [####################] 100%
ChatterBot trained using “ChatterBotCorpusTrainer

The Female chatbot is not trained.
After the training the two bot the result was (  Male.db with the the Mcon crops data in it - Female.db with not data)

@EmanSaad11 I think you are using same setting file for your two objects, But chatterbot is considering only one configuration dict at a time, see here
https://github.com/gunthercox/ChatterBot/blob/c3163c84e0c18dc712ea0a449175b5eff4ccd0e6/chatterbot/ext/django_chatterbot/views.py#L13
Currently chatterbot supports only one database at time perform different operations.

@vkosuri so there is no way to create two chatterbot in Django? because i need two chat bots with two different DB

Yes, this is possible with different ports.


Reverse screen

When the car is in reverse gear, the reverse screen does not align, its missing most of it.

Fix in the latest update


Adding a new rebus - pencil box

Associated Issue: #
Summary of Changes

change 1
change 2

Pull Request Test Coverage Report for Build 957

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 87.143%

Totals

Change from base Build 937:
0.0%

Covered Lines:
158

Relevant Lines:
180

💛  - Coveralls


enchantment bug

when i create any tool it comes with unbreaking 3 and fortune 3 im new to modding and cannot find a the culprit

If you could please share your logs or if using curseforge an export of your pack tutorial here

Apotheosis does not contain any functionality to modify freshly crafted items in that manner.


Potential IIS code injection

Fixes #
Proposed Changes

I noticed there is a reference to the REDMOND domain in the query is that something that we want to leave in there?


Issues/fixture

v10.5.4 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


Folders with spaces not working

I just downloaded and gave this a try, as I was browsing a structure that I have backed up onto my server (thus why the folders sometimes have spaces) I discovered that I cannot expand and collapse the folders when there are any spaces in the folder names.

Hi @trickjarrett
Latest mainline version seems ok. Please use latest pheditor.php from main branch:
https://raw.githubusercontent.com/pheditor/pheditor/refs/heads/main/pheditor.php
Please give me more details about your OS, php version if was not ok.