Will not save unworking connection

Connections
Add Connections
Pick any driver. Fill any text in all the fields.
Click Save - save is successful.
Now it is impossible to edit this connection (possibly the only way would be to overwrite all fields until you get a working connection). It seems sqlpad will let you create a non-working connection, but not update it. Furthermore, when you click "Save" the window just disappears, without notification that things were not saved.

I'll look into this. I'm guessing this is related to a lot of the restructuring/data migrations done moving to SQLite


Apply default aggregateWindow in data explorer

Currently, we do not set a default aggregateWindow for queries built using the query builder. This frequently results in query responses that are > 10MB. This causes a poor user experience.
WHEN I build a query with the query builder
THEN the mean aggregate is automatically selected

cc @ssoroka

@desa - This came up in some user research and I spoke with @pauldix about it and tried to represent the desired point-of-view here.
GIVEN the user is in the Data Explorer working with data-filled Bucket
WHEN the user queries too much data that it will return a size related error
THEN the query is automatically downsampled
AND there's a persistent NotificationDialog message that says "You're original query was too big. It was downsampled for better viewing."
AND there's an [Undo] button
WHEN I hit [Undo]
THEN the query is re-run without downsampling

I would say that ideally it never submits the query that pulls back too much data. Ideally it would modify the query to apply downsampling automatically. That way the query engine/storage engine can provide an answer quickly and everything in the UI feels snappy.

How would we know that a query is likely to return a large result set (without executing the query) or are you suggesting that we always downsample by default, even for small queries?

I think downsampling by default, but it could be based on time range. If we assume a sampling interval of 10s then we can extrapolate when to downsample based on the number of horizontal pixels they have available. 1h = 360 raw samples, 2h = 720. So if you have anywhere from 500 - 700 pixels, you could probably query without downsampling for anything showing less than 2h of data. But if you go larger, add downsampling. So for 8h you'd aggregate by 1m buckets of time or for 72h you'd aggregate by 10m buckets of time.
Now the question is what happens if their sampling interval is something greater like 1m? I think if you pick a selector instead like first or last in those time intervals without filling missing intervals, you'll just get the raw samples, until it gets to the point where if filters them out.
It would be interesting to give them an option in the prompt that tells them it was downsampled. You can have the time window and the function used be dropdowns. So the user could then easily specify a different period or different summary function.
If I'm looking only at a single series, I find it useful to show min, max, mean when downsampling over larger periods of time.

Automatic downsampling based on pixels available sounds perfect, and what I would expect as a user.

@desa @russorat @alexpaxton here's the latest iteration of this Issue
User Problem:
The user can create queries that return too much data that can’t be displayed and crashes the UI
Solution:
Auto downsample queries to return results that can be contained by the number of display pixels.
Design Notes
Prototype
https://www.figma.com/proto/naxHHmkcY0Tc6pfbgzdq9T/Auto-Downsampling?node-id=77%3A3&viewport=-49%2C352%2C0.5&scaling=min-zoom
Working file (has CSS)
https://www.figma.com/file/naxHHmkcY0Tc6pfbgzdq9T/Auto-Downsampling?node-id=77%3A3

other tools limit the points per series to ~350. The number of series is sometimes limited as well, at least while exploring.
IMO, an aggregate can always be applied though. if there are fewer points or a single point in the aggregate, it would be the same as full fidelity.
The UI is blind though, so we might have to rethink the experience if there's no way for the UI to know if the data is full fidelity or not.

This will break Single Stat, as currently Single Stat cannot render with Aggregate Functions applied.

This will break Single Stat, as currently Single Stat cannot render with Aggregate Functions applied.

How?

Refactor Aggregate Function Panel to have two modes Auto and Custom
Given: I'm in the Data Explorer
Mode 1: Auto
When: the Auto mode is enabled (via the AutoInput - https://influxdata.github.io/clockface/?path=/story/components-inputs-composed--autoinput)
Then: MEAN is selected by default
Or a user could select MEDIAN
Mode 2: Custom
When: the Custom mode is enabled
Then: I can select any of the aggregate functions
But: One must be selected at all times (like a radio button)
Design:
https://www.figma.com/file/naxHHmkcY0Tc6pfbgzdq9T/Auto-Aggregation?node-id=250%3A110

In custom mode, I think we should default to one of the aggregate functions, but I think there should be an option to not aggregate.  Otherwise, once a user has looked at their data and realizes that it would fit without being aggregated they have no way to turn off the aggregation, without going into the script editor.

Could this be changed to a setting that could be turned off? I've lost countless hours when testing because I don't realize that default aggregation is on and I think my data/times are writing incorrectly.

It can be.  You can go into 'custom' and uncheck the aggregate method selected.

That doesn't save though. Every time I go back into the data explorer it defaults back to auto mean aggregation.


README Update

Please confirm the README is updated and accurate for this repository.

When we work on this, we should be sure to document the current behavior of deletate's selectors with regard to exclusion of the delegation root, as discussed in #25.

I made a couple some changes in https://github.com/baw/dojo-dom/tree/update-readme
I was also looking into ways to have runnable examples of the modules/functions.


Failed to build antd?bundle&dev on test page

Failing module
I figured I didn't need all the stuff as this is related to running the server locally, and it continuing to fail on this one from the test page:
http://localhost:7101/antd?bundle&dev
Error message
/* esm.sh - error */
throw new Error("[esm.sh] " + "esbuild: Could not resolve \"./_freeGlobal\"");
export default null;

Additional info
This is the latest master.

OK, for some reason it works in my deployed environment, but not locally 🤔

i have no idea, i will try it in my local laptop

works in latest v53:
import { Tree, Upload } from "http://esm.sh/antd?bundle&dev"


Ancillary data: fix infinite loop

Fix for https://sourceforge.net/p/mediainfo/bugs/1082/

Thanks for the quick turnaround.


Failed to install hlint. Possible Error?

Just downloaded Haskell via:
brew cask install haskell-platform

Followed by:
cabal install happy
cabal install hlint

I get the following error:

Resolving dependencies...
Configuring hlint-1.9.37...
Building hlint-1.9.37...
Failed to install hlint-1.9.37
Build log ( /Users/roman/.cabal/logs/hlint-1.9.37.log ):
cabal: Entering directory '/var/folders/p8/41kg47m97xdcvft_zqxhfry00000gn/T/cabal-tmp-20731/hlint-1.9.37'
Configuring hlint-1.9.37...
Building hlint-1.9.37...
Preprocessing library hlint-1.9.37...
[ 1 of 46] Compiling Test.Util        ( src/Test/Util.hs, dist/build/Test/Util.o )
[ 2 of 46] Compiling Test.InputOutput ( src/Test/InputOutput.hs, dist/build/Test/InputOutput.o )
[ 3 of 46] Compiling HSE.Type         ( src/HSE/Type.hs, dist/build/HSE/Type.o )
[ 4 of 46] Compiling HSE.FreeVars     ( src/HSE/FreeVars.hs, dist/build/HSE/FreeVars.o )
[ 5 of 46] Compiling HSE.Util         ( src/HSE/Util.hs, dist/build/HSE/Util.o )
[ 6 of 46] Compiling HSE.Match        ( src/HSE/Match.hs, dist/build/HSE/Match.o )
[ 7 of 46] Compiling HSE.Scope        ( src/HSE/Scope.hs, dist/build/HSE/Scope.o )
[ 8 of 46] Compiling HsColour         ( src/HsColour.hs, dist/build/HsColour.o )
[ 9 of 46] Compiling Parallel         ( src/Parallel.hs, dist/build/Parallel.o )
[10 of 46] Compiling Paths_hlint      ( dist/build/autogen/Paths_hlint.hs, dist/build/Paths_hlint.o )
[11 of 46] Compiling Util             ( src/Util.hs, dist/build/Util.o )
[12 of 46] Compiling CmdLine          ( src/CmdLine.hs, dist/build/CmdLine.o )
[13 of 46] Compiling HSE.Bracket      ( src/HSE/Bracket.hs, dist/build/HSE/Bracket.o )
[14 of 46] Compiling HSE.Evaluate     ( src/HSE/Evaluate.hs, dist/build/HSE/Evaluate.o )
[15 of 46] Compiling HSE.All          ( src/HSE/All.hs, dist/build/HSE/All.o )
[16 of 46] Compiling Settings         ( src/Settings.hs, dist/build/Settings.o )
[17 of 46] Compiling Idea             ( src/Idea.hs, dist/build/Idea.o )
[18 of 46] Compiling Report           ( src/Report.hs, dist/build/Report.o )
[19 of 46] Compiling Test.Proof       ( src/Test/Proof.hs, dist/build/Test/Proof.o )
[20 of 46] Compiling Refact           ( src/Refact.hs, dist/build/Refact.o )
[21 of 46] Compiling Hint.Type        ( src/Hint/Type.hs, dist/build/Hint/Type.o )
[22 of 46] Compiling Hint.List        ( src/Hint/List.hs, dist/build/Hint/List.o )
[23 of 46] Compiling Hint.Monad       ( src/Hint/Monad.hs, dist/build/Hint/Monad.o )
[24 of 46] Compiling Hint.Bracket     ( src/Hint/Bracket.hs, dist/build/Hint/Bracket.o )
[25 of 46] Compiling Hint.Naming      ( src/Hint/Naming.hs, dist/build/Hint/Naming.o )
[26 of 46] Compiling Hint.Pattern     ( src/Hint/Pattern.hs, dist/build/Hint/Pattern.o )
[27 of 46] Compiling Hint.Import      ( src/Hint/Import.hs, dist/build/Hint/Import.o )
[28 of 46] Compiling Hint.Pragma      ( src/Hint/Pragma.hs, dist/build/Hint/Pragma.o )
[29 of 46] Compiling Hint.Extensions  ( src/Hint/Extensions.hs, dist/build/Hint/Extensions.o )
[30 of 46] Compiling Hint.Duplicate   ( src/Hint/Duplicate.hs, dist/build/Hint/Duplicate.o )
[31 of 46] Compiling Hint.Comment     ( src/Hint/Comment.hs, dist/build/Hint/Comment.o )
[32 of 46] Compiling Hint.Unsafe      ( src/Hint/Unsafe.hs, dist/build/Hint/Unsafe.o )
[33 of 46] Compiling Hint.Util        ( src/Hint/Util.hs, dist/build/Hint/Util.o )
[34 of 46] Compiling Hint.ListRec     ( src/Hint/ListRec.hs, dist/build/Hint/ListRec.o )
[35 of 46] Compiling Test.Translate   ( src/Test/Translate.hs, dist/build/Test/Translate.o )
[36 of 46] Compiling Hint.Match       ( src/Hint/Match.hs, dist/build/Hint/Match.o )
[37 of 46] Compiling Hint.Lambda      ( src/Hint/Lambda.hs, dist/build/Hint/Lambda.o )
[38 of 46] Compiling Hint.All         ( src/Hint/All.hs, dist/build/Hint/All.o )
[39 of 46] Compiling Apply            ( src/Apply.hs, dist/build/Apply.o )
[40 of 46] Compiling Language.Haskell.HLint2 ( src/Language/Haskell/HLint2.hs, dist/build/Language/Haskell/HLint2.o )
[41 of 46] Compiling Grep             ( src/Grep.hs, dist/build/Grep.o )
[42 of 46] Compiling Test.Annotations ( src/Test/Annotations.hs, dist/build/Test/Annotations.o )
[43 of 46] Compiling Test.All         ( src/Test/All.hs, dist/build/Test/All.o )
: can't load .so/.DLL for: /Users/roman/.cabal/lib/x86_64-osx-ghc-8.0.1/text-<IP_ADDRESS>-9Yh8rJoh8fO2JMLWffT3Qs/libHStext-<IP_ADDRESS>-9Yh8rJoh8fO2JMLWffT3Qs-ghc8.0.1.dylib (dlopen(/Users/roman/.cabal/lib/x86_64-osx-ghc-8.0.1/text-<IP_ADDRESS>-9Yh8rJoh8fO2JMLWffT3Qs/libHStext-<IP_ADDRESS>-9Yh8rJoh8fO2JMLWffT3Qs-ghc8.0.1.dylib, 5): Library not loaded: /usr/local/opt/ghc/lib/ghc-8.0.1/binary-<IP_ADDRESS>/libHSbinary-<IP_ADDRESS>-ghc8.0.1.dylib
Referenced from: /Users/roman/.cabal/lib/x86_64-osx-ghc-8.0.1/text-<IP_ADDRESS>-9Yh8rJoh8fO2JMLWffT3Qs/libHStext-<IP_ADDRESS>-9Yh8rJoh8fO2JMLWffT3Qs-ghc8.0.1.dylib
Reason: image not found)
cabal: Leaving directory '/var/folders/p8/41kg47m97xdcvft_zqxhfry00000gn/T/cabal-tmp-20731/hlint-1.9.37'
cabal: Error: some packages failed to install:
hlint-1.9.37 failed during the building phase. The exception was:
ExitFailure 1

ghc --version

The Glorious Glasgow Haskell Compilation System, version 8.0.1

cabal --version

cabal-install version <IP_ADDRESS>
compiled using version <IP_ADDRESS> of the Cabal library

What does ghc-pkg check say? It looks like your text install is borked by a broken binary install.

I'm assuming its a general setup issue, not HLint specific, because HLint doesn't really have control over how it is linked itself.


Windows adaptation: Fixed some error points in Windows systems

Oh gosh. I guess I merged these issues (after a lengthy Christmas break)  in the wrong order and this now causes a merge conflict. Can you check again? 🙏 This is super important because I cannot debug Windows issues personally!

I've tried to setup Windows CI, here is an WIP preview !
Before git cherry-pick this PR: https://github.com/fritx/nue/actions/runs/7399718947/job/20131776062
After git-cherrypick: https://github.com/fritx/nue/actions/runs/7399792114/job/20132011501
Seems the YAML parse error in site.yaml error gone with this fix.
However, the Windows CI test still got a lot to fix, seems like most of them are just path issues like:

See: https://github.com/fritx/nue/actions/runs/7399792114/job/20132011501  @tipiirai

Thank you, guys!


FIM implementation question

Hello, maintainers and contributors,
I hope you are all doing well. I am writing this issue to inquire about the FIM implementation in this repository. I noticed that the implementation differs from the one described in the original paper.
The FIM paper mentioned that the joint 50-50 SPM+PSM mixture may be the most efficient and flexible than the solely SPM mode. However, this FIM-clean branch only implemented the SPM mode, with
<SUF> ◦ Enc(suffix) ◦ <PRE> ◦ Enc(prefix) ◦ <MID> ◦ Enc(middle) ◦ <EOT>
instead of
<PRE> ◦ <SUF> ◦ Enc(suffix) ◦ <MID> ◦ Enc(prefix) ◦ Enc(middle) ◦ <EOT>
Is there a specific reason for these changes, such as improvements in performance or stability?
I appreciate your time and work on this project, and I'm looking forward to understanding the rationale behind the differences in the implementation.
Thank you in advance for your help and support.
Best regards,

Hi! Sorry for the delay on this.
At the time I did not thoroughly compare the different variants implemented in the paper. My rationale for not implementing joint PSM-SPM was that at inference time, one's interface to infilling (if e.g. serving a model that has FIM capabilities) can be controlled behind the scenes--there's no reason that pops out to me that explains why one would want to sometimes do PSM mode, sometimes SPM mode, at inference time. I suppose it might be the case that one mode allows more attention to the prefix vs. suffix compared to the other, but I am not certain this is likely or desirable. Does this make sense to you?
Some other information that may interest you:

I helped Bigcode expand my implementation a bit and it was used to train Santacoder (paper: https://arxiv.org/abs/2301.03988, code: https://github.com/bigcode-project/Megatron-LM/blob/multi-query-attention/megatron/data/gpt_dataset.py). This code should implement joint SPM + PSM as done in the paper because Bigcode's intent was to maximally derisk FIM training and confirm that the minor performance hit was the same for identical settings to the FIM paper's recommendation.
FIM still caused a minor performance hit as seen on HumanEval left-to-right performance in Santacoder, about the same size drop as I observed in my own SPM experiments.
I don't know how thoroughly UL2-style FIM training, or head-to-head between InCoder's Causal Masking vs. FIM training have been compared. it may be the case that one of these styles is better downstream or causes less of a performance drop, but I'm not aware of work that fairly compares these, though UL2 was used in the new CodeGen2.

Thank you very much for your detailed and informative response! It has greatly helped me in understanding the issue and resolving my problem.


Clear touch handler states when gesture recognizer ended.

In RCTTouchHandler, touch states are removed in -[RCTTouchHandler _recordRemovedTouches:], which is called in -[RCTTouchHandler mouseUp:]. The problem is -[RCTTouchHandler mouseUp:] is not guaranteed to be called, and when it's not, the touch states would be wrong.
So, correct me if I was wrong, I think touch states need to be cleared some where, and I think -[NSGestureRecognizer reset] might be the right place.

Looks good to me, let's test in the wild in 0.11 rc3. Sorry for failed test, too many Flow errors.

Thanks!


Speed up the LazyAggregatorTest

It sleeps 7 seconds, we can make the 1 second transaction submission window configurable, reduce it, and remove the delays

Closed by https://github.com/rollkit/rollkit/pull/807


feat: time-based disabling of multicall-prevention

In the contracts, we prevent multicall-buy to avoid bots taking a good part of the supply at launch.
However, this creates an overhead cost as we store inside a storage var commited to L1 the last tx_hash of the interaction from the sender of the transaction.
To prevent this, we can disable this security feature a certain amount of time after launch. I propose to keep it for 30 minutes, and disable it after.

Depends on #81

In the contracts, we prevent multicall-buy to avoid bots taking a good part of the supply at launch.
However, this creates an overhead cost as we store inside a storage var commited to L1 the last tx_hash of the interaction from the sender of the transaction.
To prevent this, we can disable this security feature a certain amount of time after launch. I propose to keep it for 30 minutes, and disable it after.

Agreed, good idea


RepositoryFile.setContent seems to truncate the last eol

When I use createFile() the file that arrives in GitLab is missing any/all blank lines at the end of the file, blank lines throughout the file are not effected.
Thus the file I get when checked out in Linux reports noeol, in for example vim.
I tried adding \n to the String object as its passed to setContent() but it was stripped off as well.
If I write the same String to File on disk the blank lines are at the bottom as expected.
Here's the way I have the code...
someTextString = new String(Files.readAllBytes(Paths.get("thePathToSomeFile"))); RepositoryFileApi repositoryFileApi = new RepositoryFileApi(gitLabApi); RepositoryFile repositoryFile = new RepositoryFile(); repositoryFile.setFilePath("somePath"); repositoryFile.setContent(someTextString); repositoryFileApi.createFile(repositoryFile, 123456, "master", "Initial Commit");
I don't know if I'm doing something wrong, if this is expected, or what. I seems pretty straight forward.
Thanks

This has been fixed and released in version 4.8.1
One quick comment, There are convenience methods for creating singletons of the sub APIs, so instead of creating a new instance of RepositoryFileApi, you can do this:
RepositoryFileApi repositoryFileApi = gitLabApi.getRepositoryFileApi();


Adding example projects to help users get started

See the conversation in #83

Adding examples folder with easy to start projects (see README in that folder)
Example 1: hello world
Example 2: handle the user prompt by sending it to the Copilot API and returning the result

early feedback, I haven't looked at the handle prompt example yet.
I would suggest we remove 1- prefixes, the names should stay on their own

I was aiming for having a very logical way of knowing where to start and gradually add more complex examples. Numbering them helps so that you do not need to search in the README.

@gr2m , I've addressed most of the feedback but moving the body parsing logic out of the on_end event. Please go over the comments and close them if the feedback has been handled adequately 😄.

We have a live stream today that I think might draw some interest, I think it would be great to finish this up by then:
https://nickyt.live/#2024-09-17-gregor-martynus%2C staff software engineer at github
I'll address my remarks to get the PR merged, we can do follow up PRs aftewards


When validation fails you should have the option to not perform binding

There seems to be no way to detect a validation failure and therefor not bind. Take justify-examples-binding as the example. When the json is invalid the Person object should not be created. Maybe fromJson should return an Optional?
If the json is invalid, yet the object is still created, then how is user to know? Maybe if you don't provide a ProblemHandler then justify defaults to returning an empty Optional?
I realize I can add functionality to my ProblemHandler Object but that isn't exactly convenient. I would think the normal use-case would be validating incoming requests so that bad ones are disguarded or possibly fixed, but in that order.

@hambone01
The specification of JSON-B API is originally defined by Oracle and now maintained by Eclipse Jakarta EE Team. So I cannot modify the API.
Please see https://github.com/eclipse-ee4j/jsonb-api
You can throw an unchecked exception from your ProblemHandler in order to stop binding immediately after the input document turned out to be invalid.


MathCAT ignores preferences in a Tauri app on Android

I'm using Tauri to compile an app For Windows and Android both. On Windows, MathCAT works like a charm. But on Android, I had problems:

Although MathCAT initially read the prefs.yaml correctly, it later failed to open it.

This lead me to assume that Tauri commands may run in separate threads from the app setup, at least on Android.
I therefore specify the rules directory at the start of each function where I call MathCAT. This fixed the initial issue.

Unfortunately, I run into a separate issue where changing the BrailleCode preferences doesn't work. They're always Nemeth, even if I change them to LaTeX or UEB.
Since I always call the preference change right after specifying the rules directory and before setting the MathML and retrieving the braille output, I'm at a loss as to why this happens. No errors get reported, MathCAt just stubbornly sticks with UEB.

I've verified the file structure is correct and it all works fine on Windows. I'd appreciate any pointers to further debug this problem.

MathCAT reads preferences from two locations:

System preferences: Rules/prefs.yaml
User-specific settings: dirs::config_dir()/MathCAT/prefs.yaml

User settings take precedence over system settings. The Rust documentation mentions where dirs::config_dir() is located for Windows, MacOS, and Linux. It is silent for Android (same as Linux???). That might be one of the problems. However, if you never try to write the user file, that isn't the issue.
If you specifically set a preference, that should override any user or system setting. That might trigger rule files to be re-read though (see below for when that happens).
MathCAT has a preference that controls when the rules files are checked for changes (and potentially re-read): CheckRuleFiles. The possible values are:

All: always check the pref and rule files to see if they have changed (has the time-stamp changed)
Prefs: only check the pref files for changes
None:  don't ever check for updates

I suggest trying to set the value to None and see if that helps. If that fails, try changing the value in src/prefs.rs (line 103). With value None, once the rule files are read, they won't be re-read unless you change the language, speech style, or braille code.
MathCAT is single-threaded, so there shouldn't be an issue with other threads doing the reading, but with the None setting, it cuts down on when files are read. Reading a file might allow another thread or process to run (but it won't be a MathCAT thread).
Let me know if that helps.

I got it to work with your tip about the preference. There's a lot I don't understand yet:

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_log::Builder::new().build())
        .plugin(tauri_plugin_dialog::init())
        .plugin(tauri_plugin_shell::init())
        .invoke_handler(tauri::generate_handler![preview, export_html, export_epub])
        .setup(|app| {
            let setup_result = app_setup(app);
            match &setup_result {
                Ok(()) => log::info!("Completed app setup"),
                Err(e) => log::error!("Error during setup: {}", e.to_string()),
            }
            setup_result
        })
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

fn app_setup(app: &mut App) -> Result<(), Box<dyn std::error::Error>> {
    let mathcat_rules_zip = Asset::get("MathCAT_Rules.zip").unwrap();
    let target_dir = app
        .path()
        .resolve("MathCAT_Rules", tauri::path::BaseDirectory::AppConfig)?
        .canonicalize()?;
    if target_dir.exists() && target_dir.is_dir() {
        fs::remove_dir_all(&target_dir)?;
    }
    extract(
        target_dir.parent().unwrap(),
        Cursor::new(mathcat_rules_zip.data),
    )?;
    // Originally, I configured MathCAT here, thinking the
    // configuration would be the same during the app cycle.
    // Sadly, the configuration doesn't persist to the Tauri commands (on Android, anyway).
    // Maybe because those run on a different thread?
    Ok(())
}

/// Renders a preview version of the HTML document.
///
/// Mathematical equations get converted to MathML using KaTeX and then
/// get converted into a more accessible format using MathCAT.
#[tauri::command]
fn preview(app: AppHandle, content: &str) -> String {
    // SNIP
    let root = match create_ast(&app, content, &arena, &options, &katex_options) {
        Ok(root) => root,
        Err(e) => return e,
    };
    generate_html(root, &options)
}

fn create_ast<'a>(
    app: &AppHandle,
    content: &str,
    arena: &'a Arena<AstNode<'a>>,
    options: &Options,
    katex_options: &Opts,
) -> Result<&'a AstNode<'a>, String> {
    let root = parse_document(arena, content, options);
    let target_dir = app
        .path()
        .resolve("MathCAT_Rules", tauri::path::BaseDirectory::AppConfig)
        .unwrap()
        .canonicalize()
        .unwrap();
    // If the configuration happens **here**, it works.
    libmathcat::set_rules_dir(target_dir.to_str().unwrap().into()).unwrap();
    if libmathcat::get_preference("CheckRuleFiles".into()).unwrap() != *"None" {
        libmathcat::set_preference("CheckRuleFiles".into(), "None".into()).unwrap();
    }
    if libmathcat::get_preference("BrailleCode".into()).unwrap() != *"LaTeX" {
        libmathcat::set_preference("BrailleCode".into(), "LaTeX".into()).unwrap();
    }
    // We can't modify the document tree while traversing it, so we need to save
    // math nodes for later modification.
    let mut math_nodes = Vec::new();
    for node in root.descendants() {
        if let NodeValue::Math(_) = node.data.borrow().value {
            math_nodes.push(node);
        }
        if let NodeValue::CodeBlock(ref code) = node.data.borrow().value {
            if code.info == *"math" {
                math_nodes.push(node);
            }
        }
    }
    for node in math_nodes {
        // If, on the other hand, the setup for MathCAT happens here,
        // it doesn't work - there's an error reading files.
        if let NodeValue::Math(ref math) = node.data.borrow().value {
            if math.display_math {
                // If KaTeX doesn't parse this, just leave it unaltered.
                if let Ok(html) = katex::render_with_opts(&math.literal, katex_options) {
                    // Since we know for a fact KaTeX parsed this fine,
                    // the MathML should be valid, but it never hurts to be cautious.
                    let node_id = match libmathcat::set_mathml(extract_mathml(&html)) {
                        Ok(id) => id,
                        Err(e) => {
                            log::error!("MathCAT error: {}", libmathcat::errors_to_string(&e));
                            return Err(libmathcat::errors_to_string(&e));
                        }
                    };
                    let node_value = match libmathcat::get_braille(node_id) {
                        Ok(braille) => NodeValue::Text(braille),
                        Err(e) => {
                            log::error!("Braille error: {}", e);
                            return Err(libmathcat::errors_to_string(&e));
                        }
                    };
                    let katex_node = AstNode::from(node_value);
                    let arena_ref = arena.alloc(katex_node);
                    let para_node = AstNode::from(NodeValue::Paragraph);
                    let para_ref = arena.alloc(para_node);
                    node.insert_before(para_ref);
                    para_ref.append(arena_ref);
                    node.detach();
                }
            } else if let Ok(html) = katex::render(&math.literal) {
                let node_id = match libmathcat::set_mathml(extract_mathml(&html)) {
                    Ok(id) => id,
                    Err(e) => return Err(libmathcat::errors_to_string(&e)),
                };
                let node_value = match libmathcat::get_braille(node_id) {
                    Ok(braille) => NodeValue::Text(braille),
                    Err(e) => return Err(libmathcat::errors_to_string(&e)),
                };
                let katex_node = AstNode::from(node_value);
                let arena_ref = arena.alloc(katex_node);
                node.insert_before(arena_ref);
                node.detach();
            }
        } else if let NodeValue::CodeBlock(ref math) = node.data.borrow().value {
            if let Ok(html) = katex::render_with_opts(&math.literal, katex_options) {
                let node_id = match libmathcat::set_mathml(extract_mathml(&html)) {
                    Ok(id) => id,
                    Err(e) => return Err(libmathcat::errors_to_string(&e)),
                };
                let node_value = match libmathcat::get_braille(node_id) {
                    Ok(braille) => NodeValue::Text(braille),
                    Err(e) => return Err(libmathcat::errors_to_string(&e)),
                };
                let katex_node = AstNode::from(node_value);
                let arena_ref = arena.alloc(katex_node);
                let para_node = AstNode::from(NodeValue::Paragraph);
                let para_ref = arena.alloc(para_node);
                node.insert_before(para_ref);
                para_ref.append(arena_ref);
                node.detach();
            }
        }
    }
    Ok(root)
}

It's hard to figure out what's happening, exactly, especially because logs returned from Android are very noisy and don't include Debug messages (maybe I'll figure out sometime how I can change this). Too many moving parts at play, too: Is this a MathCAT issue, a Tauri one or an Android quirk?
Either way, it works now, so while understanding why this works but other almost identical versions don't isn't too urgent.
As a legally deafblind programmer, I owe you huge thanks for creating MathCAT. If I do manage to finish my bachelor's degree as planned, it is in part because of MathCAT - because it (finally!) made exercises and literature more accessible and (particularly) more readable to me.
Closing this as resolved, even if I don't fully understand why. :D

I'm really happy to hear you managed to get the Android version to work and that MathCAT is helping you get through school. I have only met one other deafblind person. That was John Boyer, the main author for liblious. Years (decades?) ago, I did some work on braille generation for math in liblouis and it was months of corresponding with him before I found out that he was deafblind. When I finally met him in person, it was a bit surreal for me because communication still needed to take place via computer. The ability of computers to not only allow him to communicate, but to be very productive, was eye opening and remains a constant reminder to me that computers can drastically improve the lives of people with disabilities. That you managed to get MathCAT to run on Android is a testament to your abilities!
For debugging MathCAT, you need to set an environment variable when running it. I use
env RUST_LOG=DEBUG cargo run

You can set it to a few different values, but MathCAT mainly uses "debug".  I'm not sure what the equivalent would be on Android (sorry, I've never done Android programming). To set it programmatically, I think you can use
env_logger::Builder::from_env(Env::default().default_filter_or("debug")).init();

Another option I found on the web (but haven't tested):
if env::var("RUST_LOG").is_err() {
    env::set_var("RUST_LOG", "debug")
}
env_logger::init();

I still don't understand why you need to set the RulesDir every time, but if things are working for you and speed is not a problem, I guess it doesn't matter.
Good luck getting your bachelor's degree!

Thank you!
There's actually nothing about MathCAT that makes compiling it to the linux-aarch64 target difficult. Granted, incorporating it into an Android app written in Kotlin could be tricky, but I let Tauri do all the heavy lifting.
You said MathCAT is single-threaded. So unless I'm misinterpreting things, my problems were partly caused by multiple threads or possibly async tasks. I.e., MathCAT gets initialized on one thread, but the subsequent call to set_mathml happens on a different thread due to how Tauri apps run. That's my only explanation for the behaviour I see, honestly; can't reproduce it on Windows. Would there be a way to share a MathCAT instance between threads? Tauri has shared state, but I honestly don't know how I'd go about putting a MathCAT instance in such a shared state...
One optimization I can make is to check if there are any MathNodes in the AST at all - if not, MathCAT won't get needed so I don't need to call initialization again. Overall, though, the performance seems to be good, plus there's already a debouncing mechanism in place to keep preview rerendering to an acceptable level.
There's a lot more I'd like to know and share, but I don't want to spam your GitHub issues and it's not technically an issue with MathCAT. So if you'd like, you can reach me at contact[at]tim-boettcher.email.

MathCAT has state (bad for multi-threading), but I'm pretty sure that by being single-threaded (only one thread/instance of MathCAT can exist), any calls to MathCAT will be shared, one at a time.
My hypothesis is that you are actually starting a new MathCAT each call and that is why the Rules directory needs to be set each time. One possible way to detect this is to do a time measurement. MathCAT on my 7 year old Windows machine takes about 50ms to read in all the rules and produce speech and braille the first time, but after that, it only takes 4ms or less. So if you time the calls and don't see it taking substantially less on a subsequent call, that is a strong sign that in fact you are not reusing the MathCAT instance.
I'll contact you at your email addr so I can answer other technical issues you have.


Schematics not rotating or flipping

I have the latest version and when i click the rotate or flip buttons nothing happens

Latest version tells me nothing. You could be on the "latest" 1.12, 1.8 or 1.0.

Closing due to lack of feedback.


Research seems to not be working anymore.

The automation passes on the research tab, but no research is activated, even though I have the resources. I made sure that researches are enabled in the option, that the researches have a valid priority (non-disabled).

I concur: Research doesn't work at all, which completely prevent automation of small runs, which is what I mainly use automation for.


improve: Standard Practice Questions on Recursion

⭐ Summary
Hi @Utkarsh1504
I would like to work on Standard Practice Questions on Recursion section. Here I will take popular question on recursion and explain that with codes.
Please assign it to me.
Thanks
💻 Location
title: Standard Practice Questions
section: Recursion
order: 8G
filename: recursion-practise.md
❌ Additional Info
#hacktoberfest2021

@sujoy-coder absolutely go ahead. Just share the question you want to add.


Extra benchmark tests for order type

I want to merge this change because it adds a few benchmarks to order type:

giftCards
invoices
payments
which apparently were missing dataloaders.

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

Task linked: SALEOR-6812 Optimize order type resolvers


[LLVMCPU] Set encoding on batch_matmul ops

Set data-tiling encoding on batch_matmul ops when --iree-flow-enable-data-tiling flag is provided.
Currently we are seeing slight regressions (max at +8%) on BertLargeTF and T5LargeTF models. The detailed analysis and next steps are post here: https://github.com/openxla/iree/issues/14431#issuecomment-1699685372.
I had an offline discussion with @hanhanW and we think it's fine to enable current batch_matmul data-tiling under --iree-flow-enable-data-tiling. This will make it easier to work on the further improvements. Alternatively, we can have another flag to guard this feature.

This looks fine. I am fine with landing these with the slight regressions as well. I'd like some info on the regressed dispatch count, just to get an idea of whats happening there.

Checked both dispatch counts and it matched the extra pack/unpack dispatches created for batch_matmul

The regression looks like noise and that benchmark should be unaffected

@RoboTux fyi, the batch_matmul data-tiling + ukernel in CPU backend should now be enabled with --iree-flow-enable-data-tiling --iree-llvmcpu-enable-microkernels flags

Sorry for the late comment. FYI in my initial testing on AWS graviton 3 we got a speedup of over 2x for both BERT Large batch 1 and BERT Large batch 32. I think there is still room for improvement and I'm testing a solution for that.


[FEAT] Option to show CPU and GPU temps in fahrenheit

in the cpu and gpu modules allow choosing the unit the temperature is displayed in

display.temp.unit: F
See fastfetch -h temp-unit

display.temp.unit: F
See fastfetch -h temp-unit

i get an Error: unknown option: --temp-unit when trying to use it

Use display.temp.unit in config.json

ah ok i figured it out, but that unknown option bug needs fixing


Tweak Colors to Match IQX Light Theme

Summary
Changed Background Colors of Gates to Match IQX Light Theme.
Made changes to dictionaries so font color is different like in IQX.
Details and comments
Fixes #5032
@1ucian0

 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.

The following PR will close due to some errors and messed up commits. I will move it to a new PR soon

#5066


Updated Bad diagnostic errors

Fixes #64903
I have updated the error messages which were not very clear to the user.
Environment
Swift version 5.9-dev (LLVM 6a04c4848990c70, Swift f2bac1a22939a4d)
This is my first pull request on this project. Please scold me if I have made any mistake.

Hey @LucianoPAlmeida I have committed the new changes you suggested, please have a look

Sorry, been a bit busy lately with work so I just glanced on the basics when commenting.
Now was trying to get more context I see that the exercise here is to try to make the wording of diagnostic to be clear on what the language rule is and tell that to the user.
Here are a few things to think about:
struct SS<T> : T { } // expected-error{{cannot inherit from non-protocol type 'T'}}

It is still not clear what cannot inherit from not protocol types. So you can start thinking about the rules about inheritance for struct types and how to describe that in a succinct, but clear way.
Same applies to other cases, so you can start with questions such as:
What is the language rules for inheritance of each construct class, struct, enum and extensions of each of those?
And how improve the current diagnostics to express that in a more clear way?


You can have infinite charges for the freedom/emp implanter using a implanter from med techfab

Description
You can basically recharge your implants for emp/freedom by just taking the implant out and putting it back in, giving you 3 charges again.
Reproduction
Use a freedom/emp implant
Use all the charges
Take an implanter and just take it out and put it back in
Have 3 charges again
Screenshots
Additional context
I feel like a simple fix would be to just delete the implant after the 3 charges are used up, like the dna implanter

wont fully fix it if it still works when partially used, but is a good thing anyways

I couldn't replicate this! Both partly and fully used implants remember the amount of charges they had before being removed.
I think its fixed but I couldn't find any PRs that mention it so 🤷


TP not showing pitch or yaw

Can you fix the thirdperson not showing any angles please.

u can do that yourself but also needs to make animfix


Not able to import using line 'from azure.storage.blob import BlockBlobService '

[I'm not able to import BlockBlobService using 'from azure.storage.blob import BlockBlobService'. I get the following error
Traceback (most recent call last):
File "", line 1, in
from azure.storage.blob import BlockBlobService
ImportError: cannot import name 'BlockBlobService' from 'azure.storage.blob' (C:\Users\abo4jk\AppData\Local\Continuum\anaconda3\envs\spyder-4.1.3\lib\site-packages\azure\storage\blob_init_.py)
]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 2f45a6b5-0fea-7fbb-5d4d-37e0e2583fd7
Version Independent ID: 7be6f792-09f8-c22f-86b6-d0f690e9b3a4
Content: Explore data in Azure blob storage with pandas - Team Data Science Process
Content Source: articles/machine-learning/team-data-science-process/explore-data-blob.md
Service: machine-learning
Sub-service: team-data-science-process
GitHub Login: @marktab
Microsoft Alias: tdsp

@segun030 Thanks for the question. We are investigating the issue and will update you shortly.

@segun030  Thanks for the feedback. You can manage the blobs with Python v12 SDK instead of using the legacy version of the Azure Blob storage client library.
Here is the doc for the same: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-quickstart-blobs-python

@segun030 We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Export: Create new glyphs entries when export range is outside of contained glyphs.

This is usable for example when you want to add new characters to a font only containing standard ascii characters.
I used this for a font exporting from 0x20 to 0x7E, when I wanted to add the ° symbol. First I imported the existing font, then I exported with "Last glyph to export" == "0xFF". Then I took the result and imported again, so I could edit the newly added symbols.

Hi @charno and thanks for that,
I'm just wondering if this wouldn't be easier and more user-friendly to add a button that can add directly a new "blank" glyph at the end of the range ? It would avoid the useless export/reimport step I guess
What do you think ?

Hi @tchapi
I don't know about easier (I'm by no means experienced in JS).
From a users perspective I can see that this would make more sense. Then I would suggest to allow to add a number of items at a time (since when the button only adds one blank glyph I woud have to click about 100 times to go from 0x7E to °).
This was just the implementation that I as a JS noob could come up with in a reasonable time, and I thought that it could be useful for other people as well.

Hi @charno
Would you mind testing https://github.com/tchapi/Adafruit-GFX-Font-Customiser/pull/17 and tell me if that suits your needs ? You can add a character (directly in a modal), and it will automatically add the interval characters needed for the output file, disabling them so they don't take that much space.
It should work properly but I'm not sure I have covered all edge cases.
Thanks in advance !
Cyril

Superseeded by #17 / #18


RHOAIENG-16076: tests(gha): mount the lvm volume with performance flags

https://issues.redhat.com/browse/RHOAIENG-16076
Another chunk of the

https://github.com/opendatahub-io/notebooks/pull/775

changes to be reviewed and merged.
Description
I did not actually benchmark this, and the speed of the disk does not matter much, but since I found a guide and the suggested options look reasonable, and they don't break anything functionally, then, why not?
How Has This Been Tested?
GHA
Merge criteria:

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work

/lgtm

lol, it's the most useless pr from the series, but it's true that it's also the easiest to review, so I'm not wondering it got a lgrm first
with the other PRs I'd like to see the two lgtm rule, just so that it is impactful, but this one is really trivial, so
/approve

/override ci/prow/images


When user touches screen during fling the state transitions to end state than scrolls back a little

Google Maps behavior is such that a touch after a fling (while fling is in progress) is ignored. Current lib behavior is such that when user touches screen during fling, the state transitions to the end state, then scrolls back a little towards the touch.
I will try looking into this issue, but help is appreciated as well.

it's what you were talking in #15 right?

No this is a different issue. I'll post a video.


Unnecessary check for 'iOS'; minimum deployment target ensures guard will always be true

Hi,
Is it possible to fix this compile warning when targeting iOS9.0+ ?
(Alamofire/Source/ParameterEncoding.swift:230:12)
Thanks

I'm going to assume you are using CocoaPods. The issue has been fixed by the CocoaPods team, but the fix has not yet been released. Please see https://github.com/Alamofire/Alamofire/issues/871 for more info.


Strange Crash when Idling during Install?

Hi! I was installing a large game on my USA N3DS non-XL system using FBI.cia on 10.7 sysnand running AuReiNand (pre-Luma3DS)+A9LH, and I decided to let the game install while I ate dinner with my family.
 I tried pressing Home but it didn't do anything (I didn't hear anything either.) So I force-shut off my system. When it reboot, it turned out that the game had completely finished installing before the system crashed, so it must have crashed at some point while idling on the "Install Completed" screen.

Is this with the latest version? (2.1.1)

Whoa, sorry. I thought I updated: I just checked in the app itself, and it says the version is "2.0.5".

Depends... did you build it yourself or do you always download? If you build yourself, take a look at #79

I actually had a crash with 2.1.1, installing a 2GB+ CIA yesterday. It just hung at ~850MB for an eternity, so I was forced to shutdown. I guess this might be a completely different issue though. Worked fine when I used FBI 1.4.17 afterwards, btw.

I used the release. I think I installed it just before installing the .cia and reported it right when I got back, so whichever version was released 16 hours ago (at the time of this posting)

the same i install 2 cias
ther first ok
the second freeze but i restart and game is install ok

Can you test if this happens in this build?
https://www.dropbox.com/s/866yhujdg859mor/FBI.zip?dl=0

the last version no problems. it ok

Closing, then. Feel free to reply further if new information comes up.


Upgraded to node-sass 3.0.0-beta.7 and related doc changes.

Removed imagePath from options documentation. Support for this was removed from libsass
Added functions to options documentation. See https://github.com/sass/node-sass#functions--v300---experimental

My ultimate goal here is to allow ember-cli-sass to support custom functions.

Great, thanks Luke! Any reason why you've pinned to version beta.7 in the package.json? FYI I'll be removing the peerDependency when this goes out of beta. This is because peerDeps are being removed, and I a better solution is to simply provide an option that allows you to pass in a specific version of node-sass.

Sure thing, Simon. The pin was an oversight. I just updated his PR with the caret restored.

BTW, I'm using my works in our projects to implement image-url and font-url and it's working well. Example:
var types = require('node-sass').types;
var app = new EmberAddon({
  sassOptions: {
    functions: {
      'image-url($path)': function(pathString) {
        var str = 'url("/assets/images/' + pathString.getValue() +'")';
        return new types.String(str);
      },
      'font-url($path)': function(pathString) {
        var str = 'url("/assets/fonts/' + pathString.getValue() +'")';
        return new types.String(str);
      }
    }
  }
});

That's awesome, what a cool feature. Hey while I've got you, props for your contributions to Ember :+1:

Published v1.0.0-beta.8

Thanks, Simon. I love seeing the community move forward together!
Thanks for releasing a new version with this change. Can you do one of ember-cli-sass that incorporates this version of broccoli-sass-source-maps too?

Can do, published<EMAIL_ADDRESS>


Deprecate EnvironmentalMaterialTerm, FunctionalAnnotationTerm + children

See https://github.com/microbiomedata/nmdc-schema/issues/1881
This PR is the first step in deprecating EnvironmentalMaterialTerm, FunctionalAnnotationTerm + children. It adds a deprecated string to each class definition. This PR will need to be reviewed to see if/when it can be merged in during the Berkeley schema rollout, or if we need to wait.

this was supposed to be created in berkeley schema fork, whoops


Simulating Errors for Testing

Hi,
I've just added NVIDIA DCGM to our compute cluster to monitor our GPU health. So far everything is working well, and I am able to query GPU health regularly from our management nodes.
However, I haven't been able to thoroughly test this as I haven't had a hardware failure yet. Is there an easy way to simulate a hardware error for DCGM? I want to test my scripts to see if the appropriate actions are taken on our Slurm cluster.
Sorry if this is off-topic or within the docs somewhere, my google-fu is failing me.

DCGM Error Injection is probably what you're looking for: https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-error-injection.html

This looks like exactly what I want. Not sure how I missed this, thank you!


Regex.match raises exception when certain pattern applied to long subject

The pattern in question has to involve a repeated group that contains |, and the subject needs to be long enough that the group matches 1024 or more times.
regex = /^(_|X)+/
# regex = /^(_)+/

(1020..1027).each do |i|
    subject = "_" * i
    match_result = regex.match(subject)
    puts "#{i}: #{match_result ? "matches" : "NOMATCH"}"
end

I get:
1020: matches
1021: matches
1022: matches
1023: matches
Unhandled exception: Regex match error: JIT_STACKLIMIT (Regex::Error)
  from /snap/crystal/2018/share/crystal/src/regex/pcre.cr:197:7 in 'internal_matches?'
  from /snap/crystal/2018/share/crystal/src/regex/pcre.cr:174:8 in 'match_impl'
  from /snap/crystal/2018/share/crystal/src/regex.cr:614:12 in 'match_at_byte_index'
  from /snap/crystal/2018/share/crystal/src/regex.cr:563:12 in 'match'
  from bug_report.cr:7:20 in '__crystal_main'
  from /snap/crystal/2018/share/crystal/src/crystal/main.cr:129:5 in 'main_user_code'
  from /snap/crystal/2018/share/crystal/src/crystal/main.cr:115:7 in 'main'
  from /snap/crystal/2018/share/crystal/src/crystal/main.cr:141:3 in 'main'
  from /lib/x86_64-linux-gnu/libc.so.6 in '??'
  from /lib/x86_64-linux-gnu/libc.so.6 in '__libc_start_main'
  from /home/michael/snap/crystal/common/.cache/crystal/crystal-run-bug_report.tmp in '_start'
  from ???

(Note that if I change the regex to /^(_)+/, I get "matches" for all lengths.)
crystal -v:
Crystal 1.12.1 [4cea10199] (2024-04-11)

LLVM: 15.0.7
Default target: x86_64-unknown-linux-gnu

OS is Ubuntu 22.04.4

Try upgrading to PCRE2, based on the trace you're still on PCRE1. I'm unable to reproduce this myself, so was like fixed or is just no longer a problem on the newer version.

Try upgrading to PCRE2, based on the trace you're still on PCRE1.

E.g., invoke crystal build -Duse_pcre2 bug.cr ? That gives me an ld error (which I'm trying to figure out).
I thought PCRE2 was the default since crystal 1.8.

No, I mean actually install PCRE2 via sudo apt-get install libpcre2-dev. You currently do not have it installed, hence the ld error.
AFAIK PCRE2 is the default if it is available, whereas in your case, it is not, so it falls back on PCRE1. Of which, it's been quite a while since 1.8. Wonder if its time to drop this fallback behavior...

No, I mean actually install PCRE2 via sudo apt-get install libpcre2-dev. You currently do not have it installed, hence the ld error.

Ah, okay. Seems like that should have been mentioned in the migration steps.
Anyway, that fixes this bug for me.


Dockerfile improvements

*Compiles binaries in a separate container
*Saves around 300mb on the docker image

Great stuff!  Really appreciate the slimming of the image.


"My name is heymycroft"

Right now, this skill's response to "Who are you" is along the lines of "My name is heymycroft and I'm an intelligent personal assistant." This is a little jarring - the prefix "hey" should probably be stripped out.

fixed by #14


[#9177] add metrics server to go function

Fixes #9177
Motivation
go function added metrics collector by #6105, but havnt pass metricsPort to go function, also not init & start prometheus http server. As the result, function worker will keep trying to access to the metrics port to collect data, which will cause massive log errors in log history.
Modifications

expose metricsPort to go function
add prometheus http server to go function

Verifying this change

[ ] Make sure that the change passes the CI checks.

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

Hello @freeznet Thanks you work on this, I agree with @zymap's point of view, it seems that it is more reasonable for us to use metricsPort as a field of InstanceConfig. Of course, there is no problem with your current implementation.

Hello @freeznet Thanks you work on this, I agree with @zymap's point of view, it seems that it is more reasonable for us to use metricsPort as a field of InstanceConfig. Of course, there is no problem with your current implementation.

@wolfstudy thanks for review. I will go for @zymap and your advice. But this will affect java and python's code, should I put metricsPort into InstanceConfig in an individual pull-request?

@wolfstudy thanks for review. I will go for @zymap and your advice. But this will affect java and python's code, should I put metricsPort into InstanceConfig in an individual pull-request?

Yes, make sense to me. Let's get merge this PR.

Yes, make sense to me. Let's get merge this PR.

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

@freeznet Thank you for fixing this issue!


Rekha: Movies-List

[x] repo
[x] demo

Hi @Rekhasriraman , you need to change your url on gitHub


Returned Policies and Exploitability

Can I get some clarity on the input assumptions when calculating exploitability? See the following simple example:
from open_spiel.python.algorithms import sequence_form_lp, exploitability
import pyspiel

game = pyspiel.load_game('kuhn_poker')
(v1, v2, pi1, pi2) = sequence_form_lp.solve_zero_sum_game(game)
exploitability.exploitability(game, pi1)

The exploitability here is nonzero even though the utilities match the expected values (-1/18, 1/18). This does not happen when I used the closed form expression for the kuhn nash equilibrium:
from open_spiel.python.algorithms import exploitability
from open_spiel.python.games import data
import pyspiel

game = pyspiel.load_game('kuhn_poker')

pi_kuhn = data.kuhn_nash_equilibrium(0.219434553)
exploitability.exploitability(game, pi_kuhn)

This exploitability is zero. However, when I manually compare [pi_1, pi_2] and pi_kuhn, they look almost identical. What am I missing?

Wow, that is quite the gotcha.... I'm surprised the first one even works!
The problem is that you're trying to compute exploitability for just a single policy. But exploitability is a function of the entire strategy profile (both policies) or "joint policy", not just the one player's policy. The sequence form LP code gives you them back separately rather than contained in a single object (like e.g. the CFR code does).
The fix is to just merge them into a single joint policy:
from open_spiel.python.algorithms import sequence_form_lp, exploitability
from open_spiel.python import policy
import pyspiel

game = pyspiel.load_game('kuhn_poker')
(v1, v2, pi1, pi2) = sequence_form_lp.solve_zero_sum_game(game)
merged_policy = policy.merge_tabular_policies([pi1, pi2], game)
exploitability.exploitability(game, merged_policy)

We should totally have this in a test. I was surprised not to see it in the sequence_form_lp_test, so please leave this open as a reminder to add a test that does the above so there's a reference to it in the code somewhere.

Oh that makes sense! I was curious why there were two returned policies, but each policy itself was still defined over the joint action space (with uniform random values in the other player's states). Thanks!!


Add smoke tests for AdoptOpenJDK

In https://github.com/adoptopenjdk/openjdk-build, we configure a lot of things without actually testing/ensuring that they have the desired effect. Examples:

Vendor names in version string
Special build configuration (JFR, Shenandoah, ...)
Custom CA certificates
Metadata

To make things worse, some of these things are version/platform dependant (for example, Shenandoah).
This needs to be covered by tests to reduce breakages and to ensure the long-term maintainability of the project.

First PR (check TLS/SSL stack) has landed: #2049.

I believe many of these can be added into functional/packaging or functional/build directories.
Created JDK_VENDOR (https://github.com/AdoptOpenJDK/TKG/issues/115) and JDK_VERSION enhancment (https://github.com/AdoptOpenJDK/TKG/issues/116) issues so that we can come back and update playlists appropriately (does not block us from adding tests that temporarily do their own checking of vendor and update versions in the interim).

Something to cover with tests: https://github.com/AdoptOpenJDK/openjdk-build/issues/2229

https://github.com/AdoptOpenJDK/openjdk-build/issues/2236

https://github.com/AdoptOpenJDK/openjdk-tests/issues/2024

After virtual deskside review of https://github.com/AdoptOpenJDK/openjdk-tests/pull/2140 with @adamfarley and also considering https://github.com/AdoptOpenJDK/openjdk-tests/pull/2067, felt it would be useful to create a table of the known specific tests, and noting how one may verify it, in order to see the common patterns we can implement to cover all the known cases and better prepare for new unknown cases.
Note: This table is incomplete and will undergo several revisions (need to verify which vendors each test case is applicable to), and add new known/needed test cases to the list, even if they are not implemented or are in a PR at present.

Test for
How to verify
Impls
Vendors
Version(s)
Platform(s)

testIfCudaIsEnabled
find file + find string in file
openj9
openj9,ibm
all
win/linux

FreetypeAbsenceTest.testTemplateExample
find file
all
all?
all
linux

freetypeOnlyBundledOnWindowsAndMacOS
find file
all
all?
all
on Win/MacOS, not on Linux/AIX

testShenandoahAvailable
cmdLineTest
hotspot
adopt,upstream/RH
15+,11.0.9+
all aarch64, x86

testZGCAvailable
cmdLineTest
hotspot
adopt
15+
aarch64 linux, x64 win/macos/linux

testJFRAvailable
cmdLineTest
hotspot
adopt
11+, 8u262
---

javaVersionPrintsVendor
cmdLineTest
all
---
---
---

vmPropertiesPointToVendor
cmdLineTest
all
---
---
---

testDefaultTls
ability to connect to servers
all
all?
all
all

testTls13
ability to connect to servers
all
all?
11+
all

Given this, we see we need generic methods, findFile, findStringInFile, checkCommandLine via ProcessBuilder or cmdLineTester, connectToServer via HttpsURLConnection.  All utility methods to find version info, or build info can be moved to a common area for use by all tests (we have many implementations of similar type utility methods scattered around, and an effort should be made to consolidate some of them).

After virtual deskside review of https://github.com/AdoptOpenJDK/openjdk-tests/pull/2140 with @adamfarley and also considering https://github.com/AdoptOpenJDK/openjdk-tests/pull/2067, felt it would be useful to create a table of the known specific tests, and noting how one may verify it, in order to see the common patterns we can implement to cover all the known cases and better prepare for new unknown cases.
Note: This table is incomplete and will undergo several revisions (need to verify which vendors each test case is applicable to), and add new known/needed test cases to the list, even if they are not implemented or are in a PR at present.

Test for
How to verify
Impls
Vendors
Version(s)
Platform(s)

testIfCudaIsEnabled
find file + find string in file
openj9
openj9,ibm
all
win/linux

FreetypeAbsenceTest.testTemplateExample
find file
all
all?
all
linux

freetypeOnlyBundledOnWindowsAndMacOS
find file
all
all?
all
on Win/MacOS, not on Linux/AIX

testShenandoahAvailable
cmdLineTest
hotspot
adopt,upstream/RH
15+,11.0.9+
all aarch64, x86

testZGCAvailable
cmdLineTest
hotspot
adopt
15+
aarch64 linux, x64 win/macos/linux

testJFRAvailable
cmdLineTest
hotspot
adopt
11+, 8u262
---

javaVersionPrintsVendor
cmdLineTest
all
---
---
---

vmPropertiesPointToVendor
cmdLineTest
all
---
---
---

testDefaultTls
ability to connect to servers
all
all?
all
all

testTls13
ability to connect to servers
all
all?
11+
all

Given this, we see we need generic methods, findFile, findStringInFile, checkCommandLine via ProcessBuilder or cmdLineTester, connectToServer via HttpsURLConnection.  All utility methods to find version info, or build info can be moved to a common area for use by all tests (we have many implementations of similar type utility methods scattered around, and an effort should be made to consolidate some of them).

@aahlenst - Based on our respective PRs (#2140 and #2067), Shelley's comments above, and your comment in #2140, I'd say we've got several items to complete here. Since much of the work is already done, here's my draft of a todo list.
Please review and let me know your thoughts.

To complete #2140 (including the addition of the "comprehensive" change) and merge, forming the basis for the underlying framework for the build tests. (Adam)
Reasoning: The vendor-agnostic framework documentation, and test template allows folks like dragonwell to use it. Also, the shared functionality in "BuildIs" would lend well to Shelley's plan for more shared functionality later.
To adapt #2067's test suite to fit into the vendor-agnostic framework, using shared functionality where possible. (Andreas, with Adam willing to help).
Reasoning: As above. Also, using shared functionality for vendor-determination makes it trivial to find later if we remove it as part of the TestNg paramaterization stuff (where a test is only compiled and run if it is tagged with a specific vendor. Discussed with Shelley, details tbd.)
To decide on a final home for the shared functionality (build version string parsing, findFile, findStringInFile, etc) and to move the shared code there (perhaps TKG?). Also includes the work adapting the tests if needed, and also any documentation. (All)
Reasoning: We already have a copy of stuff like the "build version string parsing" elsewhere, and we should make this as widely available as possible to avoid folks having to duplicate work implimenting it, and also copying fixes if they change the version string upstream. Also mentioned in Shelley's comment.
To adapt the framework to pass the vendor name in via TestNG parametric functionality. (owner tbd)
Reasoning: This, to prevent tests even being considered for compilation if it's not being run on a build by a suitable vendor. (To be discussed in more detail once the vendor parameter reaches us from upstream).

@aahlenst - Based on our respective PRs (#2140 and #2067), Shelley's comments above, and your comment in #2140, I'd say we've got several items to complete here. Since much of the work is already done, here's my draft of a todo list.
Please review and let me know your thoughts.

To complete #2140 (including the addition of the "comprehensive" change) and merge, forming the basis for the underlying framework for the build tests. (Adam)
Reasoning: The vendor-agnostic framework documentation, and test template allows folks like dragonwell to use it. Also, the shared functionality in "BuildIs" would lend well to Shelley's plan for more shared functionality later.
To adapt #2067's test suite to fit into the vendor-agnostic framework, using shared functionality where possible. (Andreas, with Adam willing to help).
Reasoning: As above. Also, using shared functionality for vendor-determination makes it trivial to find later if we remove it as part of the TestNg paramaterization stuff (where a test is only compiled and run if it is tagged with a specific vendor. Discussed with Shelley, details tbd.)
To decide on a final home for the shared functionality (build version string parsing, findFile, findStringInFile, etc) and to move the shared code there (perhaps TKG?). Also includes the work adapting the tests if needed, and also any documentation. (All)
Reasoning: We already have a copy of stuff like the "build version string parsing" elsewhere, and we should make this as widely available as possible to avoid folks having to duplicate work implimenting it, and also copying fixes if they change the version string upstream. Also mentioned in Shelley's comment.
To adapt the framework to pass the vendor name in via TestNG parametric functionality. (owner tbd)
Reasoning: This, to prevent tests even being considered for compilation if it's not being run on a build by a suitable vendor. (To be discussed in more detail once the vendor parameter reaches us from upstream).

Both PRs are stuck because we haven't yet decided how to organize the tests and how to select the tests. Shelley said a while ago that she made some experiments but I do not know what the outcome was.
From my POV, there are multiple ways to tackle this. What we have seen so far:

The current capabilities to filter tests in the XML are insufficient because we cannot express ranges down to the x.y.z level or say "Apply to 11, 15 and newer" or do that on a per-test basis. There are also cases where the test needs to be altered depending on the version (different VM args, for example).
Auto detection of VM vendor based on VM properties is risky because VM properties are sometimes wrong.
Differences between vendors are large. Take TLS 1.3 support in JDK 8: Azul introduced it a long time before everyone else, around 8u222 or so. Then came Oracle and half a year later OpenJDK. Red Hat does still not enable JRF for their builds, Oracle ignores Shenandoah and Red Hat even includes it in 8.

Because of that, I think the approach we both took (determining in the test whether something is supported) is wrong and will lead to unmaintainable and very complicated tests. But the question is: What's the alternative?
First aspect, versions a.k.a time: Usually, test material is saved alongside the code to be tested. So if you change the code, you run the tests that you find in an adjacent directory and they all must pass. There's no "Uhm, take the test suite from a year ago and it should be green for the current code" or "What about using today's test suite for a one year old release. Sure they'll pass." But by using version numbers as some sort of feature flags ("must be present in 8u272 or newer but absent before"), we try exactly that. This is madness and we should stop. Even though our test material is separate, who in their right mind would run today's test suite against a build of 8u192? So we go back to "That's a test for 11, that's for 8" and call it a day. After a test has been added, it is expected that all newer builds pass. If there are material changes required while one version is in rampdown (e.g. 8u282) and the other one is in development (e.g. 8u292), we're screwed. But that's never going to happen 🤞And if it does, there's still ProblemList.txt or a human that can ignore the failure.
Vendors: We have seen that VM props can be unreliable. Therefore, I'd argue that the vendor selection needs to be an argument set by a human. We usually know what we're building anyway. This cuts down on potential problems. Now that we know what the vendor is, how do we know what tests to run? Having a single test for everyone and letting it figure out what values to expect puts a big burden on the author (you need to check dozens of builds even if you have zero interest in a subset of products) and the tests become very complex. Just look at the number of conditions required for Shenandoah. This again is madness and we need to stop. Alternatives:

Supplying a file per vendor that specifies which tests to run.
Having dedicated folders per vendors, each with a full copy of "their" tests.

Option 1 is sufficient for tests like TLS 1.3 or Shenandoah because those boil down to "Run test: yes/no". However, it does not work for tests of VM properties or the list of jmods which vary per vendor/platform. So we're back at having long if-elseif-else blocks or would require something like Cucumber specs.
Option 2 would do away with the if-elseif-else blocks (simple tests, yay) but comes at the expense of having duplicated or triplicated tests that vary slightly. Is it so bad? Upside: Maintenance of vendor specific folders could be outsourced to the respective teams.
Last aspect, how do we combine vendor and version? Having a folder per version in a vendor's directory (like dragonwell/11) looks attractive at first (we know exactly which tests apply) but isn't: A test introduced with 11 would have to be copied into every future version's folder. Using the XML that we have now would solve this problem by being able to express ranges, but is only slightly better because a single XML applies to all tests in a suite. But as we have seen, each test can apply to  a different set of versions. This would result in a large number of suites, most containing only a single test. So we need some mechanism that works on a per-file basis like the annotations in jtreg tests.
To sum up, I'd end up with folders per vendors and simple version range expressions per test. But maybe I missed some aspects or it doesn't fit with what we have at all. What I've completely ignored are platform differences, but maybe that's something we have to ultimately solve within each test or could be done in a similar way as the version ranges, for example through some sort of annotation per file.
As soon as we have decided what we want, we can make the necessary changes to TKG/... Factoring out common functionality (as well as using a better assertion library) can come afterwards and does not look like such a big deal to me.

Both PRs are stuck because we haven't yet decided how to organize the tests and how to select the tests. Shelley said a while ago that she made some experiments but I do not know what the outcome was.
From my POV, there are multiple ways to tackle this. What we have seen so far:

The current capabilities to filter tests in the XML are insufficient because we cannot express ranges down to the x.y.z level or say "Apply to 11, 15 and newer" or do that on a per-test basis. There are also cases where the test needs to be altered depending on the version (different VM args, for example).
Auto detection of VM vendor based on VM properties is risky because VM properties are sometimes wrong.
Differences between vendors are large. Take TLS 1.3 support in JDK 8: Azul introduced it a long time before everyone else, around 8u222 or so. Then came Oracle and half a year later OpenJDK. Red Hat does still not enable JRF for their builds, Oracle ignores Shenandoah and Red Hat even includes it in 8.

Because of that, I think the approach we both took (determining in the test whether something is supported) is wrong and will lead to unmaintainable and very complicated tests. But the question is: What's the alternative?
First aspect, versions a.k.a time: Usually, test material is saved alongside the code to be tested. So if you change the code, you run the tests that you find in an adjacent directory and they all must pass. There's no "Uhm, take the test suite from a year ago and it should be green for the current code" or "What about using today's test suite for a one year old release. Sure they'll pass." But by using version numbers as some sort of feature flags ("must be present in 8u272 or newer but absent before"), we try exactly that. This is madness and we should stop. Even though our test material is separate, who in their right mind would run today's test suite against a build of 8u192? So we go back to "That's a test for 11, that's for 8" and call it a day. After a test has been added, it is expected that all newer builds pass. If there are material changes required while one version is in rampdown (e.g. 8u282) and the other one is in development (e.g. 8u292), we're screwed. But that's never going to happen 🤞And if it does, there's still ProblemList.txt or a human that can ignore the failure.
Vendors: We have seen that VM props can be unreliable. Therefore, I'd argue that the vendor selection needs to be an argument set by a human. We usually know what we're building anyway. This cuts down on potential problems. Now that we know what the vendor is, how do we know what tests to run? Having a single test for everyone and letting it figure out what values to expect puts a big burden on the author (you need to check dozens of builds even if you have zero interest in a subset of products) and the tests become very complex. Just look at the number of conditions required for Shenandoah. This again is madness and we need to stop. Alternatives:

Supplying a file per vendor that specifies which tests to run.
Having dedicated folders per vendors, each with a full copy of "their" tests.

Option 1 is sufficient for tests like TLS 1.3 or Shenandoah because those boil down to "Run test: yes/no". However, it does not work for tests of VM properties or the list of jmods which vary per vendor/platform. So we're back at having long if-elseif-else blocks or would require something like Cucumber specs.
Option 2 would do away with the if-elseif-else blocks (simple tests, yay) but comes at the expense of having duplicated or triplicated tests that vary slightly. Is it so bad? Upside: Maintenance of vendor specific folders could be outsourced to the respective teams.
Last aspect, how do we combine vendor and version? Having a folder per version in a vendor's directory (like dragonwell/11) looks attractive at first (we know exactly which tests apply) but isn't: A test introduced with 11 would have to be copied into every future version's folder. Using the XML that we have now would solve this problem by being able to express ranges, but is only slightly better because a single XML applies to all tests in a suite. But as we have seen, each test can apply to  a different set of versions. This would result in a large number of suites, most containing only a single test. So we need some mechanism that works on a per-file basis like the annotations in jtreg tests.
To sum up, I'd end up with folders per vendors and simple version range expressions per test. But maybe I missed some aspects or it doesn't fit with what we have at all. What I've completely ignored are platform differences, but maybe that's something we have to ultimately solve within each test or could be done in a similar way as the version ranges, for example through some sort of annotation per file.
As soon as we have decided what we want, we can make the necessary changes to TKG/... Factoring out common functionality (as well as using a better assertion library) can come afterwards and does not look like such a big deal to me.

This code has been delivered into openjdk-build repo via https://github.com/AdoptOpenJDK/openjdk-build/pull/2397

re: https://github.com/AdoptOpenJDK/openjdk-tests/issues/2024#issuecomment-756717796 JDK_VENDOR support is now in TKG and soon we will look at adding minor version support also, in the meanwhile the code that handles minor version support stays in the test code, but when it sits at that level, it has to be repeated in each group of test code, and results in a lot of needless duplication.

java.vendor.version change merged: https://github.com/AdoptOpenJDK/openjdk-build/pull/2544


Fixing compilation in Debug mode.

This fixes the unit quaternion check when building in Debug, however it breaks the unit test at
/home/peter/catkin_ws/src/curves/curves/test/CubicHermiteSE3CurveTest.cpp:261:

Couldn't figure out what goes wrong here, any ideas?

Can one of the admins verify this patch?

retest this please

@pfankhauser isn't Jenkins setup to verify PRs? I'll try on my machine.

@pfankhauser I get the same issue, with the rotational part failing. Which part of the modif did solve the building in debug? The new construction of the w1_dbeta1 ... objects or the construction of qDiff with normalization? Are you sure that both modifs are needed and maybe we can use this to isolate? Also which constructor of https://github.com/ethz-asl/kindr/blob/9a0d954636278e79b62e21a2ea4d7d664265f5be/include/kindr/rotations/RotationQuaternion.hpp#L55 is used? I could not find one taking a 3x1 eigen matrix.

@dbellicoso what's the state of this with your latest fixes?

add to whitelist

I've killed the curves_tests on ibex-trusty after it had consumed > 700 minutes of CPU time...


TELEWORK: Restrict email addresses allowed to gov.bc.ca and other OCIO accepted domains

User Story
As the product owner, I want the employee to only be able to change the supervisor email field to a BC Government domain. This is for security and process reasons (clarity of who is signing off).
Tasks

[ ] Collect the range of domains we wish this to be restricted to. It will naturally include gov.bc.ca but there are other government domains such as crtbc.ca (the Civil Resolution Tribunal).
[ ] Apply this filter to the "Manager/Employer Email" field (variable name = managerEmail.
[ ]  Create text next to the field saying that it is restricted to government email addresses.
[ ] Give the range of accepted domains in the supporting documentation.

Acceptance Criteria

[ ] This filter should not exclude any potential users of this form
[ ] The filter must function

I can assist in collecting the domain addresses.

This is a duplication of #215.

I asked for a list of domains today on Yammer on in the Digital Government group.

I asked Colin Newell today and he referred me to Danton Remacle. I am awaiting a response. Alex also asked Steven Jones.

-We have collected a list of possible domains from the Messaging and Communications group.

We have also collected a list of applicable organizations from Policy.
The next step is to match the two.

@DonMoffatt @MeghanStothers @Stella-Archer @Abuchana
I added an example on what this could look like on the telework form in dev. The List of domains / messaging can be updated in the Validation Tab of the field (custom validation section).
![image.png](https://images.zenhubusercontent.com/61df28f84562db4e4d8e63d1/2436177d-5b
43-4666-b595-4c7c5369df79)

Thanks - yes,  this looks simple.

yes this looks great thansk!

I've had a reply from Igor and OCIO that they have received our request for the latest list. I have asked for a deadline of tomorrow at the latest as we'll need Simen's time to add the domains. @simensma-fresh can you let us know if getting the list on Tuesday will give you enough time?
Also, we'll want to adjust the message to show "BC" in caps but that is low-priority item. I will share this informati
on with the client/Sean/PIE at our meeting this afternoon.

Action: I have been given a contact name Aaron Leskiw, ED Network, to help us with this request. I will loop in Stella and Igor to the thread.

I can add the domains, @MeghanStothers. Simen has already added the code and it is very simple.

I added the following approved domains to both the employee and manager email validation. Employee is also necessary as copies of confidential information could otherwise be sent there if it was changed from the default.
"inbcinvestment.ca",
"bcassessment.ca",
"bc-ebc.ca",
"bcehs.ca",
"bcest.bc.ca",
"bcfarmreviewboard.ca",
"BCFerryCommission.ca",
"bchumanrights.ca",
"bciif.ca",
"bcldb.com",
"bcliquorstores.com",
"bcrcf.ca",
"bcspp.org",
"bcucipp.org",
"crtbc.ca",
"cullencommission.ca",
"cupsa-aspc.ca",
"destinationbc.ca",
"destinationbc.travel",
"eaat.ca",
"elections.bc.ca",
"healthlinkbc.ca",
"iiobc.ca",
"justicebc.ca",
"lrb.bc.ca",
"obcctc.ca",
"paab.bc.ca",
"patientcarequalityreviewboard.ca",
"ptboard.bc.ca",
"robsonsquare.ca",
"seniorsadvocatebc.ca",
"surfacerightsboard.bc.ca",
"tourismbc.com",
"ticorp.ca",
"workbc.ca",
"royalbcmuseum.bc.ca",
"rcybc.ca",
"lngbuybc.ca",
"eabtribunals.ca"

Tested successfully in DEV!
Ready to be pushed to TEST and PROD!

Tested successfully in PROD!
Ready to be closed


Allow to pass custom parameters to Busboy

It'd be nice to allow passing custom parameters to Busboy (like, to define file size limit).
And, a HUGE THANKS for this library. This was the solution after almost 3 hours of search and struggle.

Thanks for the thanks, not entirely my solution though, just followed an answer on StackOverflow.
Also, just added the requested options, see the new README for more information.