Rounding causes total consumption to never be greater than 0.00 kWH

The fix merged for #5 and #6 seems to have caused a new issue- total consumption now always shows as 0.00 kWh, even if the UPS is reporting usage. This also affects the Eve-computed Total Cost value.

I think (but haven't totally proven it) that it is related to the rounding done in these two places:

https://github.com/ebaauw/homebridge-lib/blob/c4fa195194d03bca86bb6595b699c1c0573e7c5d/lib/ServiceDelegate/History/Power.js#L81
https://github.com/ebaauw/homebridge-lib/blob/c4fa195194d03bca86bb6595b699c1c0573e7c5d/lib/ServiceDelegate/History/Power.js#L114

Since this value is published as a FLOAT characteristic, I think it could either omit rounding completely, or replace:
this._totalConsumption += Math.round(delta / 3600000.0) // kWh

with
this._totalConsumption += Math.round(delta / 3600.0) / 1000.0 // kWh

To round to three decimal places (e.g. Wh, but expressed as kWh).

I think you're right.    Normally, smart plugs report Total Consumption and I simply expose that.  This is the first time I actually try and compute it from Current Consumption.
Double checking my Eve Energy smart plugs, Eve seems to show Total Consumption with a  0.01 kWh resolution, and Current Consumption with a 1W resolution.  The history seems to have entries with a 0.01Wh resolution, but that's deceiving.  It shows values in Wh, but the values themselves are integer, in 0.1 W * 10 min.  So it divides those by 6 (10 min/h) to get 0.1 Wh.   I see I round those values to W, and then multiply by 10.
I think, it makes sense only to round values when sending these to HomeKit and keep the internal accumulation in full precision.  Let me see if I can get it right this time...

Ran the changes for a day in test; it looks to be correct now.  Published v1.0.5.

I've been running 1.0.5 for about 24 hours now, and I am also seeing total consumption data that looks good. Thanks for fixing!


This example 404s on a call to OPTIONS https://cds.us1.twilio.com/v1/entities

This example 404s on a call to OPTIONS https://cds.us1.twilio.com/v1/entities

This may be due to it not being immediately clear what the appSid needs to be in the credentials file. How is this different from the instanceSid? Where is the appSid obtained?

Believe the problem is that the Twilio server is not set up to handle CORS preflight requests (using OPTIONS). None of the ip-messaging example code works anymore, not just this app.

This was due to a required SDK update (0.7.4 works fine).


Improvements to example project

Wow! Thanks for all of that, Matthew.

Glad to help @markfinger... I'll keep them coming :)


Hash: use integer division instead of float division

Fixes a couple of warnings in src/hash.cr:
$ bin/crystal spec/std/hash_spec.cr --warnings=all
In src/hash.cr:240:54

 240 | @entries = malloc_entries(initial_indices_size / 2)
                                                      ^
Warning: Deprecated Int32#/. `Int#/` will return a `Float` in 0.29.0. Use `Int#//` for integer division.

In src/hash.cr:887:18

 887 | indices_size / 2
                    ^
Warning: Deprecated Int32#/. `Int#/` will return a `Float` in 0.29.0. Use `Int#//` for integer division.

A total of 2 warnings were found.

Thanks @Blacksmoke16 for finding this (though next time please report it as an issue, I might forget what I read in gitter 😊)

Did we forget to make the Int#/ change for 0.29.0 and 0.30.0?

No, but the llvm migration took more time than expected. So it didn’t fit in my plate at least.

IMO we shouldn't put out such message with a precise schedule like "will return a Float in 0.29.0". There can always be delays and cause that we can't fulfill the announced plan. For example "will return a Float after 0.28.0" is almost equally expressive but doesn't claim to happen in a specific release.


XF.4.5 with AndroidX Librarys crash in Release-Mode (ZXingScannerViewRenderer)

Hi guys,
I have a project with your barcode scanner.
It works fine so far, but as soon as I change the release settings to "User+SDK assemblys",
I can no longer build the app in the release configuration.
The build process is aborted very quickly with the following exception.
System.IO.FileNotFoundException: Could not load assembly 'zxing.portable, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=830ae994e36ac27d'. Perhaps it doesn't exist in the Mono for Android profile?
Filename: "zxing.portable.dll"
   bei Java.Interop.Tools.Cecil.DirectoryAssemblyResolver.Resolve(AssemblyNameReference reference, ReaderParameters parameters) in /Users/runner/runners/2.165.0/work/1/s/xamarin-android/external/Java.Interop/src/Java.Interop.Tools.Cecil/Java.Interop.Tools.Cecil/DirectoryAssemblyResolver.cs:Zeile 241.
   bei Java.Interop.Tools.Cecil.DirectoryAssemblyResolver.Resolve(AssemblyNameReference reference) in /Users/runner/runners/2.165.0/work/1/s/xamarin-android/external/Java.Interop/src/Java.Interop.Tools.Cecil/Java.Interop.Tools.Cecil/DirectoryAssemblyResolver.cs:Zeile 191.
   bei Mono.Cecil.MetadataResolver.Resolve(TypeReference type) in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/external/cecil/Mono.Cecil/MetadataResolver.cs:Zeile 110.
   bei Mono.Cecil.TypeReference.Resolve() in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/external/cecil/Mono.Cecil/TypeReference.cs:Zeile 276.
   bei Mono.Linker.TypeReferenceExtensions.<GetMethods>d__4.MoveNext()
   bei Mono.Linker.Steps.TypeMapStep.TryMatchMethod(TypeReference type, MethodReference method)
   bei Mono.Linker.Steps.TypeMapStep.<GetBaseMethodsInInterfaceHierarchy>d__16.MoveNext()
   bei Mono.Linker.Steps.TypeMapStep.MapVirtualInterfaceMethod(MethodDefinition method)
   bei Mono.Linker.Steps.TypeMapStep.MapVirtualMethods(TypeDefinition type)
   bei Mono.Linker.Steps.TypeMapStep.MapType(TypeDefinition type)
   bei Mono.Linker.Steps.TypeMapStep.ProcessAssembly(AssemblyDefinition assembly)
   bei Mono.Linker.Steps.BaseStep.Process(LinkContext context)
   bei Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step)
   bei Mono.Linker.Pipeline.Process(LinkContext context)
   bei MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context)
   bei Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res)
   bei Xamarin.Android.Tasks.LinkAssemblies.RunTask()
   bei Xamarin.Android.Tasks.AndroidTask.Execute()

I'm using nuget version 3.0.0-beta5 of ZXing.Net.Mobile and <IP_ADDRESS>0 of XF. The workaround for now is to switch Linking to "None" in Android Options in Properties of Xamarin.Android project. With this option the building and archiving to apk/aab is succeeded.

try something like this, create a static class and static method which you're gonna call in OnCreate ..
public static class LinkerExceptions
  {
    public static void PleaseKeepThese()
    {
      var zxing= typeof(ZXing.Net.Mobile.Forms.Android.ZXingBarcodeImageViewRenderer).FullName;
    }
  }

You probably don't want to switch to None linking since it will make the final package too large. With this workaround you should be able to keep this settings on Sdk Assemblies Only

I can build with success on Release with this solution.
@standamikes I tried build Xamarin.Android project in Release and Linking Sdk Assemblies Only using your workaround but with no success.
But:

I cloned this repo (git clone https://github.com/Redth/ZXing.Net.Mobile --recurse-submodules),
updated XF in it,
removed ValidateOnly = "$(_XFXamlCValidateOnly)" from Xamarin.Forms.targed in 120 line (somehow this repo could not build with this line),
uninstalled all ZXing nugets from NetStandard and X.Android and referenced this local repo (I added it to my main solution as projects),
referenced zxing.dll to NetStandard and X.Android projects (this dll is located in ZXing.Net.Mobile folder)
my OnCreate has (propably) all ZXing initialization references:

base.OnCreate(savedInstanceState);
...
Xamarin.Essentials.Platform.Init(Application);
ZXing.Net.Mobile.Forms.Android.Platform.Init();
MobileBarcodeScanner.Initialize(Application); //deprecated
LinkerExceptions.PleaseKeepThese();
...
Forms.Init(this, savedInstanceState);
LoadApplication(new App());

And now i can build X.Android in Release with linking Sdk Assemblies Only, which results in much smaller apk and bundle files.

@MickLesk what version of ZXing.Net.Mobile were you using?


Filters tasks functions

Function that filter all relevant tasks according to given key.
The key can be one of:  [created_date, assignee, priority, status]

Im on it


Fixes !seen wording.

Previously, if a command was done it would say
"I last saw USER#DISCRIM an hour (2017-09-17 08:26:44.853000)"
this small change means that it will say
"I last saw USER#DISCRIM an hour ago (2017-09-17 08:26:44.853000)"

I currently have a PR open for something like this, as can be seen here, https://github.com/b1naryth1ef/rowboat/pull/23. Would you mind if I added this to my PR to simplify it?

Do it 👍 @OGNova

I'll have to do it when I'm home, since mobile GitHub doesn't want to show my forked repo


feat(scrolling-regions): use terminal scrolling regions to stop Terminal::insert_before from flickering

The current implementation of Terminal::insert_before causes the viewport to flicker. This is described in #584 .
This PR removes that flickering by using terminal scrolling regions (sometimes called "scroll regions"). A terminal can have its scrolling region set to something other than the whole screen. When a scroll ANSI sequence is sent to the terminal and it has a non-default scrolling region, the terminal will scroll just inside of that region.
We use scrolling regions to implement insert_before. We create a region on the screen above the viewport, scroll that up to make room for the newly inserted lines, and then draw the new lines. We may need to repeat this process depending on how much space there is and how many lines we need to draw.
When the viewport takes up the entire screen, we take a modified approach. We create a scrolling region of just the top line (could be more) of the viewport, then use that to draw the lines we want to output. When we're done, we scroll it up by one line, into the scrollback history, and then redraw the top line from the viewport.
A final edge case is when the viewport hasn't yet reached the bottom of the screen. This case, we set up a different scrolling region, where the top is the top of the viewport, and the bottom is the viewport's bottom plus the number of lines we want to scroll by. We then scroll this region down to open up space above the viewport for drawing the inserted lines.
Regardless of what we do, we need to reset the scrolling region. This PR takes the approach of always resetting the scrolling region after every operation. So the Backend gets new scroll_region_up and scroll_region_down methods instead of set_scrolling_region, scroll_up, scroll_down, and reset_scrolling_region methods. We chose that approach for two reasons. First, we don't want Ratatui to have to remember that state and then reset the scrolling region when tearing down. Second, the pre-Windows-10 console code doesn't support scrolling regio
This PR:

Adds a new scrolling-regions feature.
Adds two new Backend methods: scroll_region_up and scroll_region_down.
Implements those Backend methods on all backends in the codebase.
The crossterm and termion implementations use raw ANSI escape sequences. I'm trying to merge changes into those two projects separately to support these functions.
Adds code to Terminal::insert_before to choose between insert_before_scrolling_regions and insert_before_no_scrolling_regions. The latter is the old implementation.
Adds lots of tests to the TestBackend to for the scrolling-region-related Backend methods.
Adds versions of terminal tests that show that insert_before doesn't clobber the viewport. This is a change in behavior from before.

The major concern I had with these changes was whether or not scrolling regions would be supported by all terminals, and if not, what the best way was to address #584 while not breaking Terminal::insert_after for those terminals that don't support scrolling regions.
My first attempt at that was to create a scrolling-regions feature, so that the feature could be enabled by applications that could guarantee they would only be run on appropriate terminals. I don't imagine this is a long-term solution.
From my research, it seems like anything that is vt100-related supports scrolling regions. Window's implementation of ANSI escape sequences supports them, and all Linux and Mac terminal emulators I've tried do support them. The big issue is pre-windows-10 windows support within crossterm.
As a intermediate solution, we could have both implementations compiled in. We'd start with the scrolling-regions one and fall back to the existing implementation. Thus, the but would be fixed on everything but old windows code. The only risk here is that some terminals may not support these ANSI escape sequences. As I said above, I think that's very unlikely: everything I can find that supports ANSI escape sequences supports scrolling regions.
As a long-term solution, we could implement the appropriate behavior in crossterm for windows, and then always rely on scrolling regions. This should be possible, looking at the windows documentation, but I would need to do some work to get it tested and integrated.
One advantage of the intermediate solution is that it wouldn't break external implementations of Backend. I don't know how important it is to avoid this type of breaking change. The long-term solution would require that all Backends support scrolling a region of the screen somehow, since the old code would be removed.

I should also note that building maelstrom with this feature enabled results in a much improved TUI. The flickering that was pretty bad before is completely eliminated.

I think I have addressed all of the comments.
I'm not sure what to do about the failing coverage check. It's not running coverage checks with scrolling-regions enabled.

I have created two separate, mutually exclusive, PRs for crossterm:

https://github.com/crossterm-rs/crossterm/pull/918
https://github.com/crossterm-rs/crossterm/pull/923
I have also created a merge request for termion:
https://gitlab.redox-os.org/redox-os/termion/-/merge_requests/196

If/when these get merged, the appropriate backends should be updated.

What can we do to get this across the line?

Hi! Test drove this PR, the flickering is gone :)
That being said, there doesn't seem to be a way with the new insert_before to insert a line longer than the terminal width. This is useful to emulate println!() above a powerline. Lines shorter will get clipped, and while you can wrap them yourself, that's not exactly the same as the line truly being longer than the terminal width (as is common with log lines such that the emulator can wrap them).
I'm not sure if there's anything that can be done in this PR to enable that, but it's worth calling out.
Even an insert_lines_before would be nice such that each line is unbounded in length.
I've implemented a workaround using crossterm directly, but it might be a worthwhile addition to this PR to have this be a supported directly.

I've implemented a workaround using crossterm directly, but it might be a worthwhile addition to this PR to have this be a supported directly.

I don't think it would be part of this PR (mainly because if we tried to solve all the problems all at once we'd be here until the world ends reviewing things). But the idea is worth investigating more certainly. What I'd suggest is cutting another issue to list out the problems you're seeing and the specific functionality that you're trying to achieve. Include the workaround that you're using and how it acts under various circumstances.

That being said, there doesn't seem to be a way with the new insert_before to insert a line longer than the terminal width. This is useful to emulate println!() above a powerline. Lines shorter will get clipped, and while you can wrap them yourself, that's not exactly the same as the line truly being longer than the terminal width (as is common with log lines such that the emulator can wrap them).
I'm not sure if there's anything that can be done in this PR to enable that, but it's worth calling out.

Yeah, that's an interesting issue with the current API. What would your ideal API look like?
I'm curious how the scrolling would interact with the terminal's line wrapping. You might be better off emulating the wrapping yourself so you know how much to scroll by.

I've implemented a workaround using crossterm directly, but it might be a worthwhile addition to this PR to have this be a supported directly.

Can you share how your workaround works? I'm curious.

I addressed all of @joshka 's comments, I think. Please let me know what's next.
I'm not sure why the test backend::test::tests::buffer_view_with_overwrites is failing in CI. I can't reproduce it on my end and none of the changes in my PR should affect that functionality.

Yeah, that's an interesting issue with the current API. What would your ideal API look like?

Ideally I'd be able to widgets/lines into a buffer with an unbounded (or just really large) width and then let the emulator handle the wrapping of the individual lines.
If you try this today with the current API ratatui simply panics. Ideally we could just use today's API but maybe resize the viewport before we push the widget into it, and insert_before would calculate the number of lines it needs to scroll up before inserting the line.

I'm curious how the scrolling would interact with the terminal's line wrapping. You might be better off emulating the wrapping yourself so you know how much to scroll by.

As far as I can tell, you need to scroll the scroll region up to make enough room for the wrapped line (which could wrap to multiple lines) and then call println!() at the top line. The emulator apparently will wrap this properly but then also treat the line as a true line (collapsing the line breaks when the viewport is resized).

Can you share how your workaround works? I'm curious.

The gist of it is that you call insert_before with the number of lines the widget will be after it's wrapped, and then you manually call println!() at the top of that free space.
This works with really-long lines and multilines:

I do have a bug where the grapheme calculation is slightly off when the incoming ansi sequences seem to cause the line wrapping calculation to be slightly off.
    fn drain_logs(
        &mut self,
        terminal: &mut Terminal<CrosstermBackend<io::Stdout>>,
    ) -> io::Result<()> {
        use unicode_segmentation::UnicodeSegmentation;

        let Some(log) = self.pending_logs.pop() else {
            return Ok(());
        };

        // Grab out the size and location of the terminal and its viewport
        let frame_rect = terminal.get_frame().area();
        let term_size = terminal.size().unwrap();

        // Create a paragraph by escaping the contents of the log, which is already ansi escaped
        let mut overflowed_lines = 0;
        for line in log.content.lines() {
            let grapheme_count = line.graphemes(true).count() as u16;
            if grapheme_count > term_size.width {
                // Subtract 1 since we already know this line will count as at least one line
                overflowed_lines += grapheme_count.div_ceil(term_size.width) - 1;
            }
        }

        let byte_count = log.content.len() as u16;
        let paragraph = Paragraph::new(log.content.into_text().unwrap());
        let line_count = paragraph.line_count(term_size.width) as u16;

        // We want to get the escaped ansii string and then by dumping the paragraph as ascii codes (again)
        // This is important because the line_count method on paragraph takes into account the width of these codes
        let mut raw_ansi_buf = AnsiStringBuffer::new(3000.max(byte_count), line_count);
        raw_ansi_buf.render_ref(&paragraph, raw_ansi_buf.buf.area);

        // Calculate how many lines we need to draw by adding the real lines to the wrapped lines
        let lines_to_draw = line_count + overflowed_lines;

        let space_available = term_size.height - self.viewport_current_height() - 1;

        // Rendering this line will eat the frame, so just shortcut a more reliable path
        // Render the new line at the top of the viewport, and then some spaces so that when we call "clear"
        // The lines will have been scrolled up
        if space_available < lines_to_draw {
            crossterm::queue!(
                std::io::stdout(),
                crossterm::cursor::MoveTo(0, frame_rect.y),
                crossterm::style::Print(raw_ansi_buf.to_string().trim_end()),
                crossterm::style::Print("\n"),
                crossterm::style::Print(
                    (0..self.viewport_current_height() - 1)
                        .map(|_| "\n")
                        .collect::<String>()
                ),
            )?;
            terminal.clear()?;
            return Ok(());
        }

        // In the case where the log will fit on the screen, we want to make some room for it
        // by adding some lines above the viewport. `insert_before` will eventually use scroll regions
        // in ratatui, so we're just going to use that, even if it has extra flickering in the interim.
        terminal.insert_before(lines_to_draw, |_| {})?;

        // If the viewport is at the bottom of the screen, our new log will be inserted right above
        // the viewport. If not, the viewport will shift down by lines_to_draw *or* the space available
        let y_offset = match frame_rect.y - 1 < space_available {
            true => 0,
            false => lines_to_draw,
        };

        // Finally, print the log to the terminal using crossterm, not ratatui
        // We are careful to handle the case where the log won't fit on the screen, since that will
        // cause this code to be called with the wrong viewport and cause tearing.
        raw_ansi_buf.trim_end();
        let buf = raw_ansi_buf.to_string();

        let mut max_idx = 0_u16;
        for (idx, line) in buf.lines().enumerate() {
            if line.is_empty() {
                continue;
            }
            let start = frame_rect.y.saturating_sub(y_offset) + idx as u16;
            crossterm::queue!(
                std::io::stdout(),
                crossterm::cursor::MoveTo(0, start),
                crossterm::style::Print(line),
                crossterm::style::Print("\n"),
            )?;
            max_idx = idx as _;
        }

        // Just sanity check that our math works out
        assert_eq!(max_idx - line_count, 0);

        Ok(())
    }

Ah, I see what you're doing. Thanks for sharing.
I think you're right about doing this with scrolling regions. Assuming the viewport doesn't take up the whole screen, you'd just set the scrolling region, append a lot of lines at the bottom of the region, then reset the scrolling region. Right?
When the viewport takes up the whole screen, I think the top-line trick would work as well, wouldn't it? The terminal emulator would scroll up the top line when doing wrapping. It seems like something to play with.

To implement your function, I think we'd want to split up the backend functions into four, instead of two:

Set scrolling region.
Reset scrolling region (to whole screen).
Scroll up.
Scroll down.
I think that's do-able for all backends except for crossterm for old windows terminals (ones that don't support ANSI sequences). Currently, this crossterm implementation doesn't support old windows terminals either, but it could in theory.

I addressed all of @joshka 's comments, I think. Please let me know what's next.
I'm not sure why the test backend::test::tests::buffer_view_with_overwrites is failing in CI. I can't reproduce it on my end and none of the changes in my PR should affect that functionality.

I also can't repro the test failures locally.  I'll rerun them to see if it was some weird intermittent failure. https://github.com/ratatui/ratatui/actions/runs/10964957433?pr=1341

I don't have permission to edit the PR, but here's the patch to fix this:
diff --git a/Cargo.toml b/Cargo.toml
index 4a8bdac9c..7e4597202 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -38,7 +38,7 @@ termwiz = { version = "0.22.0", optional = true }
 time = { version = "0.3.11", optional = true, features = ["local-offset"] }
 unicode-segmentation = "1.10"
 unicode-truncate = "1"
-unicode-width = "0.1.13"
+unicode-width = "=0.1.13"

 [target.'cfg(not(windows))'.dependencies]
 # termion is not supported on Windows

I merged in @joshka's fix from main and that seems to fix it.

Ok, then we're just working out release timing on this one. I'm not sure whether the next release will be 0.28.2 (without this) or 0.29.0 (with this).

Yeah, that's an interesting issue with the current API. What would your ideal API look like?

Ideally I'd be able to widgets/lines into a buffer with an unbounded (or just really large) width and then let the emulator handle the wrapping of the individual lines.
If you try this today with the current API ratatui simply panics. Ideally we could just use today's API but maybe resize the viewport before we push the widget into it, and insert_before would calculate the number of lines it needs to scroll up before inserting the line.

I'm curious how the scrolling would interact with the terminal's line wrapping. You might be better off emulating the wrapping yourself so you know how much to scroll by.

As far as I can tell, you need to scroll the scroll region up to make enough room for the wrapped line (which could wrap to multiple lines) and then call println!() at the top line. The emulator apparently will wrap this properly but then also treat the line as a true line (collapsing the line breaks when the viewport is resized).
I think with scroll regions you can just simply println!() at the bottom of the region and the region will scroll up, so you wouldn't need to implement the wrapping math yourself, hence why I jumped into this PR.

Can you share how your workaround works? I'm curious.

The gist of it is that you call insert_before with the number of lines the widget will be after it's wrapped, and then you manually call println!() at the top of that free space.
This works with long lines and multilines (ignore the panic I inserted...):

I opened #1426.


Adds syslog endpoint

Issues:
Fixes #770
Problem:
The syslog remote logging API was not supported
Analysis:
This patch provides support for the syslog api
Tests:
unit and functional

@zancas @wojtek0806 @jasonrahm

this look good to merge


feat(.iopipe folder): use .iopipe folder for wrapped handler files

By generating *-iopipe.js files inside a .iopipe folder, users can add .iopipe to gitignore easier
and the service directory is not cluttered with extra files.

Streamline tests that rely on unzipping of serverless packages.
Adds iopipeHandlerDir option for folder destination (useful due to offline not allowing leading-dot folders) https://github.com/dherault/serverless-offline/pull/346

fix #72

@coreylight This is labeled "Work In Process", am I still supposed to review?

@kolanos ready for review. Thanks!


SQL Server Availability Group Wording Fixes

Within this Workflow section, the following bolded words and phrases are kinda/sorta not accurate and may confuse readers:

The database tier can be configured to use Always On availability groups. With this SQL Server configuration, one primary database within a cluster is configured with up to eight secondary databases. If an issue occurs with the primary database, the cluster fails over to one of the secondary databases, allowing the application to remain available. For more information, see Overview of Always On availability groups for SQL Server.

I would suggest the following edits to reflect the concept of primary and secondary 'replicas' within an Availability Group, removing the reference to a cluster failing over given Availability Groups are not true Failover Cluster Deployments of SQL Server, and minor other edits to ensure clarity. For reference, the official listing of Availability Group terms and conditions can be found here
Proposed edits are bold and italic:

The database tier can be configured to use Always On availability groups. With this SQL Server configuration, one primary read/write replica within an availability group is configured with up to eight secondary read-only replicas. If an issue occurs with the primary replica, the availability group fails over primary read/write activity to one of the secondary replicas, allowing the application to remain available. For more information, see Overview of Always On availability groups for SQL Server.

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

ID: 5e6bcac8-81a4-74ef-8287-6a185c564e84
Version Independent ID: 5e6bcac8-81a4-74ef-8287-6a185c564e84
Content: Multi-tier web application built for HA/DR - Azure Example Scenarios
Content Source: docs/example-scenario/infrastructure/multi-tier-app-disaster-recovery-experiment.yml
Service: architecture-center
Sub-service: example-scenario
GitHub Login: @sujayt
Microsoft Alias: sutalasi

@kenjmartinii
Thanks for your feedback! We will investigate and update as appropriate.

@kenjmartinii - our apologies for the long delay, and thanks very much for your contribution.
Your suggestions have been incorporated. The article will republish by around 10am Pacific on 11/21.
#please-close


feat(layers): deploy Lambda layers in ap-south-2 and me-central-1

Summary
Changes

Please provide a summary of what's being changed

This PR adds the necessary config to the CI workflows to deploy our public Lambda layers to two new commercial regions: ap-south-2 and me-central-1.
Additionally, the PR also includes changes to the docs, so that these two new regions show up in the table that lists all the layer ARNs.

Please add the issue number below, if no issue is present the PR might get blocked and not be reviewed

Issue number: #2674

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

@am29d - I have already backfilled the versions from 1 through 8 of the v2 layer in these two regions in the production account.


feat: add autonomys testnet 1.3.0 assets info

Add new chain

Template to provide information about the new chain. Only add extra information in the bottom section. Ensure that the contracts are deployed on the chain, if not deploy with safe-contracts. Only one chain ID, one Safe version and one deployment type per PR. This entire paragraph should be deleted.

Please fill the following form:
Provide the Chain ID (Only 1 chain id per PR).

Chain_ID: 490000(0x77a10)

Provide RPC URL for the chain (should be able to query atleast 10 requests per minute for automatic PR check).

RPC_URL: https://nova-0.gemini-3h.subspace.network/ws

Relevant information:
https://nova.subspace.network/

Could you please pull from main so the review script is up to date?

@mmv08 branch updated.

@mmv08 branch updated.

I think you merged the wrong main branch (from your fork)

@mmv08 branch updated.

I think you merged the wrong main branch (from your fork)

Never mind, we found a bug with the script and are working on fixing it.

Apologies for the back and forth, could you please merge the main branch again? 😰

@remedcu @mmv08 Updated. Sorry for long response.


support for disabling metrics endpoint from outside of pod

description
support for disabling metrics endpoint from outside of pod. Currently we can't have encrypted metrics from sidecar and istiod, we are trying to have one solution using collector sidecar which can fetch metrics and encrypt them before exporting outside of the pod. For this solution we are adding a way to disable plain text access from outside for proxy and control plane.

@hemendrateli: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test release-notes

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test release-notes

lint_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test lint

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test release-notes

lint_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test lint

unit-tests-arm64_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test release-notes

lint_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test lint

unit-tests-arm64_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test unit-tests-arm64

unit-tests_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test unit-tests-arm64

unit-tests_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test unit-tests

gencheck_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test gencheck

lint_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test lint

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
9ca68c519f4cae4a3f9c48e8c049abf702bf1f76
link
true
/test unit-tests

gencheck_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test gencheck

lint_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test lint

unit-tests-arm64_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Did you consider using K8S NetworkPolicy to block the metrics ports?

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test lint

unit-tests-arm64_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test unit-tests-arm64

gencheck_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test gencheck

unit-tests_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Did you consider using K8S NetworkPolicy to block the metrics ports?

This won’t work for our use case(and anyone else having similar use case) because there are allow-all base network policies for clusters. Since NetworkPolicies are additive, it isn’t possible to deny access to a specific port.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test lint

unit-tests-arm64_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test unit-tests-arm64

gencheck_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test gencheck

unit-tests_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test unit-tests

integ-cni_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test integ-cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Yeah you can allow to the other ports only though:
https://github.com/ahmetb/kubernetes-network-policy-recipes/blob/master/09-allow-traffic-only-to-a-port.md
On Mon, Apr 29, 2024, 6:49 AM Hemendra Teli @.***>
wrote:

Did you consider using K8S NetworkPolicy to block the metrics ports?
This won’t work for our use case(and anyone else having similar use case)
because there are allow-all base network policies for clusters. Since
NetworkPolicies are additive, it isn’t possible to deny access to a
specific port.
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/50728#issuecomment-2082807143, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXOQ63V77X2UMSFPIFDY7ZFVJAVCNFSM6AAAAABG6KSKESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBSHAYDOMJUGM
.
You are receiving this because your review was requested.Message ID:
@.***>

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test lint

unit-tests-arm64_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test unit-tests-arm64

gencheck_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test gencheck

unit-tests_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test unit-tests

integ-cni_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test integ-cni

integ-pilot_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test integ-pilot

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test unit-tests-arm64

gencheck_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test gencheck

integ-cni_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test integ-cni

integ-pilot_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test integ-pilot

unit-tests_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-cni_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test integ-cni

integ-pilot_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test integ-pilot

unit-tests_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test unit-tests

unit-tests-arm64_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-cni_istio
ab418c09c4044c6768e945e52aaa7ef80c53addc
link
true
/test integ-cni

unit-tests_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test unit-tests

unit-tests-arm64_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test unit-tests-arm64

integ-pilot_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test integ-pilot

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test unit-tests

unit-tests-arm64_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test unit-tests-arm64

integ-pilot_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test integ-pilot

integ-cni_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test integ-cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hemendrateli: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test unit-tests

unit-tests-arm64_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test unit-tests-arm64

integ-pilot_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test integ-pilot

integ-cni_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test integ-cni

release-test_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test release-test

integ-security-istiodremote_istio
dcc32d55137c35af3f8288aa2dc402530491973c
link
true
/test integ-security-istiodremote

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Yes, please update the envoy bootstrap in tools/packaging/common/envoy_bootstrap.json for the listener on the Prometheus port as well. It might be listening on all interfaces as well.
NetPol was considered but rejected because it is not expressive enough. STRICT would be required already because of that, so this is to complete STRICT for Istio traffic as well.

Aside from the netpol comments, this seems incomplete. There are other endpoints used from metrics expose by envoy. Envoy is on localhost so these are exposed by that

I have updated the PR and also tested that we are blocking endpoint exposed by envoy also (:15090/stats/prometheus).

@hemendrateli: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

gencheck_istio
c55c9913a04ac5721854749cddeb839b8d3eac17
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

ty @hemendrateli !

ty @hemendrateli !

Thank you @bleggett @howardjohn and @kyessenov for the review.

In response to a cherrypick label: #50728 failed to apply on top of branch "release-1.21":
Applying: support for disabling metrics endpoint from outside of pod
Using index info to reconstruct a base tree...
M	pilot/cmd/pilot-agent/status/server.go
M	pilot/pkg/features/pilot.go
Falling back to patching base and 3-way merge...
Auto-merging pilot/pkg/features/pilot.go
CONFLICT (content): Merge conflict in pilot/pkg/features/pilot.go
Auto-merging pilot/cmd/pilot-agent/status/server.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 support for disabling metrics endpoint from outside of pod
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to a cherrypick label: new issue created for failed cherrypick: #50809

In response to a cherrypick label: new pull request created: #50812


[Bug Report]: Gui Is Larger Than Physical Screen When DataFrames Are Loaded

Describe the bug
When at least one dataframe is loaded, the minimum size of PandasGui is larger than my physical screen (width). I'm unable to shrink it even when not putting it into fullscreen
Environment
OS: Linux laptop 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 (2022-03-07) x86_64 GNU/Linux
Python: Python 3.9.2
IDE: vs-code
Package versions
TO GET ALL RELEVANT PACKAGE VERSIONS, RUN THIS COMMAND IN BASH AND PASTE THE OUTPUT
pip freeze | grep -i "pyqt|pandasgui|plotly|ipython|jupyter|notebook"
EXAMPLE OUTPUT
ipython==8.12.0
pandasgui @ git+https://github.com/adamerose/pandasgui.git@e71a97c5809b4e31d878ae08f06cc0a1ea6dc88f
plotly==5.14.1
PyQt5==5.15.9
PyQt5-Qt5==5.15.2
PyQt5-sip==12.12.0
PyQtWebEngine==5.15.6
PyQtWebEngine-Qt5==5.15.2

Here's a screenshot to show what it looks like.

The code to load the dataframes looks like:
import pandasgui
# ...
dataframes: dict = get_dataframes(...)
pandasgui.show(**dataframes)

The dictionary is structured as:
{
  "dataframe_one": pd.DataFrame,
  "dataframe_two": pd.DataFrame,
  "dataframe_three": pd.DataFrame,
  # ...
}

#226 could be related issue fixing this


RFC: Situation with tests in Tesseract

Hello.
I have some questions about situation with tests in Tesseract repo.

I think we have lack of unit-tests in Tesseract repo. Here I see some tests, but it is too few, I think. Should we add more unit-tests? Should we write more unit-tests for old engine? Or just write unit-tests for newer LSTM engine? Also I think we can move unit-tests also to CMake. And we can intgrate running unit-tests to TravisCI/Appveyor.
I am a little bit confused about testing recognition quality. How do we do it? I found this, but this seems out-dated stuff. Can we collect different images (of course, only images with good license for us), prepare ground-truth and check Tesseract on our set for regressions? I think it's very important for OCR-engine. Also we can integrate regression tests to TravisCI/Appveyor.
We must test Tesseract with Google sanitizers. For this we must have some tests, compile Tesseract with sanitizers and run tests. I think we can find some errors. Also this way will prevent from some possible mistakes in future.
(Hint) I suggest collect all images from issues and add it to our test set.
I try to understand, can I work on this way for Tesseract? Will this work be welcomed?
As mentioned in #1351, we should try to use OSS-FUZZ with Tesseract. At my last work we found a lot of problems with different Tesseract options (some of them led to crash)

I suggest discuss here about testing stuff.

Google has a bunch of tests that we should add to the repo. Here's an example of one of them. I can help with this.
#include "tesseract/ccstruct/statistc.h"
#include "tesseract/ccutil/genericvector.h"
#include "tesseract/ccutil/kdpair.h"

namespace {

const int kTestData[] = { 2, 0, 12, 1, 1, 2, 10, 1, 0, 0, 0, 2, 0, 4, 1, 1 };

class STATSTest : public testing::Test {
 public:
  void SetUp() {
    stats_.set_range(0, 16);
    for (int i = 0; i < ABSL_ARRAYSIZE(kTestData); ++i)
      stats_.add(i, kTestData[i]);
  }

  void TearDown() {
  }

  STATS stats_;
};

// Tests some basic numbers from the stats_.
TEST_F(STATSTest, BasicStats) {
  EXPECT_EQ(37, stats_.get_total());
  EXPECT_EQ(2, stats_.mode());
  EXPECT_EQ(12, stats_.pile_count(2));
}

// Tests the top_n_modes function.
TEST_F(STATSTest, TopNModes) {
  GenericVector<tesseract::KDPairInc<float, int> > modes;
  int num_modes = stats_.top_n_modes(3, &modes);
  EXPECT_EQ(3, num_modes);
  // Mode0 is 12 1 1 = 14 total count with a mean of 2 3/14.
  EXPECT_FLOAT_EQ(2.0f + 3.0f / 14, modes[0].key);
  EXPECT_EQ(14, modes[0].data);
  // Mode 1 is 2 10 1 = 13 total count with a mean of 5 12/13.
  EXPECT_FLOAT_EQ(5.0f + 12.0f / 13, modes[1].key);
  EXPECT_EQ(13, modes[1].data);
  // Mode 2 is 4 1 1 = 6 total count with a mean of 13.5.
  EXPECT_FLOAT_EQ(13.5f, modes[2].key);
  EXPECT_EQ(6, modes[2].data);
}

}  // namespace

Jeff,
Ray had started transferring some tests but hit a road block with one which
included some file io. We couldn't get it to build as tesseract repo is
missing some libraries used at Google.
The source is there in unittests folder but it is not included in makefile.
On Mon 4 Jun, 2018, 8:03 AM jbreiden<EMAIL_ADDRESS>wrote:

Google has a bunch of tests that we should add to the repo. Here's an
example of one of them. I can help with this.
#include "tesseract/ccstruct/statistc.h"
#include "tesseract/ccutil/genericvector.h"
#include "tesseract/ccutil/kdpair.h"
namespace {
const int kTestData[] = { 2, 0, 12, 1, 1, 2, 10, 1, 0, 0, 0, 2, 0, 4, 1, 1 };
class STATSTest : public testing::Test {
public:
void SetUp() {
stats_.set_range(0, 16);
for (int i = 0; i < ABSL_ARRAYSIZE(kTestData); ++i)
stats_.add(i, kTestData[i]);
}
void TearDown() {
}
STATS stats_;
};
// Tests some basic numbers from the stats_.
TEST_F(STATSTest, BasicStats) {
EXPECT_EQ(37, stats_.get_total());
EXPECT_EQ(2, stats_.mode());
EXPECT_EQ(12, stats_.pile_count(2));
}
// Tests the top_n_modes function.
TEST_F(STATSTest, TopNModes) {
GenericVector<tesseract::KDPairInc<float, int> > modes;
int num_modes = stats_.top_n_modes(3, &modes);
EXPECT_EQ(3, num_modes);
// Mode0 is 12 1 1 = 14 total count with a mean of 2 3/14.
EXPECT_FLOAT_EQ(2.0f + 3.0f / 14, modes[0].key);
EXPECT_EQ(14, modes[0].data);
// Mode 1 is 2 10 1 = 13 total count with a mean of 5 12/13.
EXPECT_FLOAT_EQ(5.0f + 12.0f / 13, modes[1].key);
EXPECT_EQ(13, modes[1].data);
// Mode 2 is 4 1 1 = 6 total count with a mean of 13.5.
EXPECT_FLOAT_EQ(13.5f, modes[2].key);
EXPECT_EQ(6, modes[2].data);
}
}  // namespace
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tesseract-ocr/tesseract/issues/1627#issuecomment-394218649,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE2_o4fW7j4uPre6P7gRXa4C9cNneRKiks5t5JxtgaJpZM4UYRTW
.

Google has 56 files of tests for Tesseract. None of them will work as-is with the GitHub repo, but at least some could be adapted without too much effort.  Might be a good starting point, especially for someone like @ZaMaZaN4iK  who sounds excited about writing or improving test.

@jbreiden It will be great if you can add them to GitHub for @ZaMaZaN4iK to update. Thanks!

@ZaMaZaN4iK, could you please add "RFC:" to the title of this issue ("RFC: Situation with tests in Tesseract")? That makes it clear that it is not a bug report.
@jbreiden, I also think that the available test code should be added to git, even if it is currently not integrated in the build process. Please add only text files (test code) to tesseract git. If there are also binaries (images, tessdata), they can be added to https://github.com/tesseract-ocr/test.

@jbreiden Thank you for the information. Seems like Google has unit-tests. Okay, we can wait for them. But what about regression tests? Has Google anything for this? Or we should prepare images and ground truth?

@stweil If I have some images with/without ground truth for them, should I add them to  https://github.com/tesseract-ocr/test? Are there any special requirements for test data?

And I want to clarify situation with unit-tests. Do we want to wait for unit-tests from Google or start implement our own unit-tests?

If you have any specific unitest in mind, please go ahead and implement it.
We can add the ones from Google as and when they are added to the repo and modified to work with the code in GitHub.
There was discussion in another thread, regarding putting all binaries related to testing in a separate repo (test) which can be invoked as a submodule so that the tesseract repo does not become very large.
@zdenop  has already created a new repo and the images used by current unittests should also be moved there.
Additionally, it might be possible to reduce some test file sizes for image files.

@Shreeshrii Was any discussion about measuring recognition quality between different Tesseract runs?

I don't remember such discussions, but I think that measuring the quality (not only for text recognition, but also for layout recognition) should be part of the regression tests.

No, that was not covered. Google may have these internal tests, since Ray puts statistics in his presentations, but nothing was mentioned in context of the open source code.
However, I think it is important to check for regression, at least with some sample images to begin with.
The UNLV datasets are only for limited set of languages. I would like us to be able to test each language and script, even if is a with a single one page image.
That dataset might take some time to build, but if a framework for that can be setup new language tests can be added as and when the image and matching ground truth becomes available.

That dataset might take some time to build,

Synthetic test data using a single font such as Noto Sans can be built using a single page of training text for all languages. Since all languages will not have high accuracy, we can have a cutoff for accuracy or have a parameter whose value can be set based on language.
@stweil had also suggested at one point,  to load all languages to make sure traineddata files are valid and dont's crash.

we could also start a Wiki page https://github.com/tesseract-ocr/tesseract/wiki/Ground-Truth

That is a very good idea.

I am not sure that we can find easily good source of images and ground truth for Tesseract. But I can prepare manually some of them and publish it under appropriate license.
Also there is large image collection here: https://github.com/renard314/textfairy/tree/master/test-images
But I am not sure can we use it or not for Tesseract

Also see https://github.com/tesseract-ocr/tessdata_best/pull/27#issuecomment-394228199

Also TextFairy's author allowed use image from TextFairy for Tesseract testing: https://github.com/renard314/textfairy/tree/master/test-images

Storing binaries in Git results in very large repositories, so there are good reasons to keep the source repository small for builds without tests. Repositories with test data can be included as Git submodules, then there won't be problems with broken links. The tests only have to check whether the needed submodules are available and only run if they do.

@stweil Of course. There is no reason to store test scripts and test data in one repo. You are right

I have uploaded the test binaries to tesseract-ocr/test and have created a
PR
https://github.com/tesseract-ocr/tesseract/pull/1632
to add it as submodule in tesseract.
@stweil what will be best method for updating the submodule in tesseract as
more test images are added to test repo?
ShreeDevi

भजन - कीर्तन - आरती @ http://bhajans.ramparivar.com
On Tue, Jun 5, 2018 at 2:09 AM, Alexander<EMAIL_ADDRESS>wrote:

@stweil https://github.com/stweil Of course. There is no reason to
store test scripts and test data in one repo. You are right
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tesseract-ocr/tesseract/issues/1627#issuecomment-394491328,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE2_o12V_zYHz0g520_2A1coYJoete1oks5t5ZrygaJpZM4UYRTW
.

As good start point we can upload to our test data repository these files: https://code.google.com/archive/p/isri-ocr-evaluation-tools/downloads
Inside we have a lot already binarized images with ground truth for every image. After that we can run Tesseract for every file (we can parallelize it with GNU\Parallel) for speedup.

Please see https://github.com/tesseract-ocr/tesseract/tree/master/testing
The scripts there need to be updated to use this newer location.
@zdenop also has a copy of the files on sourceforge.
https://sourceforge.net/projects/isri-ocr-evaluation-tools-alt/
ShreeDevi

भजन - कीर्तन - आरती @ http://bhajans.ramparivar.com
On Tue, Jun 5, 2018 at 10:59 AM, Alexander<EMAIL_ADDRESS>wrote:

As good start point we can upload to our test data repository these files:
https://code.google.com/archive/p/isri-ocr-evaluation-tools/downloads
Inside we have a lot already binarized images with ground truth for every
image. After that we can run Tesseract for every file (we can parallelize
it with GNU\Parallel) for speedup.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tesseract-ocr/tesseract/issues/1627#issuecomment-394586284,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE2_o2vqKPUJnjcV7cCUCDCfJ9VzNsTZks5t5hdBgaJpZM4UYRTW
.

Also see https://github.com/tesseract-ocr/tesseract/wiki/UNLV-Testing-of-Tesseract#example-results
for comparison of results up to 3.04.01

FYI, so that there is no duplication of efforts.
I am changing the current unittests to use the test submodule. Also updating the instructions and scripts for the UNLV tests.

@stweil @zdenop Have you run the UNLV testsuite recently?

I did not.

Nor did I.

@stweil I am running into an error with the unlvtests. Need your help to fix.
The batch file at the end calls these two c programs. The batch is passing a list of space separated filenames in $accfiles and $wafiles.
  unlvtests/ocreval/bin/accsum "$accfiles >unlvtests/reports/$setname.characc"
  unlvtests/ocreval/bin/wordaccsum "$wafiles" >"unlvtests/reports/$setname.wordacc"

The programs check for the following:
   initialize(&argc, argv, usage, NULL);
    if (argc < 2)
	error("not enough input files", Exit);

I am getting the error 'not enough input files' even though a long list is given. Here is the output from a test sample.
+ unlvtests/ocreval/bin/ocrevalutf8 unlvtests/ocreval/bin/accuracy /home/ubuntu/ISRI-OCRtk/bus.3B/0/8520_001.3B.txt unlvtests/results/bus.3B/8520_001.3B.unlv
+ accfiles=' unlvtests/results/bus.3B/8500_001.3B.acc unlvtests/results/bus.3B/8510_001.3B.acc unlvtests/results/bus.3B/8520_001.3B.acc'
+ unlvtests/ocreval/bin/ocrevalutf8 unlvtests/ocreval/bin/wordacc /home/ubuntu/ISRI-OCRtk/bus.3B/0/8520_001.3B.txt unlvtests/results/bus.3B/8520_001.3B.unlv
+ wafiles=' unlvtests/results/bus.3B/8500_001.3B.wa unlvtests/results/bus.3B/8510_001.3B.wa unlvtests/results/bus.3B/8520_001.3B.wa'
+ read page dir
+ unlvtests/ocreval/bin/accsum ' unlvtests/results/bus.3B/8500_001.3B.acc unlvtests/results/bus.3B/8510_001.3B.acc unlvtests/results/bus.3B/8520_001.3B.acc >unlvtests/reports/bus.3B.characc'
accsum: not enough input files
+ unlvtests/ocreval/bin/wordaccsum ' unlvtests/results/bus.3B/8500_001.3B.wa unlvtests/results/bus.3B/8510_001.3B.wa unlvtests/results/bus.3B/8520_001.3B.wa'
wordaccsum: not enough input files

I removed the quote marks from the following and it seems to be working.
unlvtests/ocreval/bin/accsum "$accfiles >unlvtests/reports/$setname.characc"
unlvtests/ocreval/bin/wordaccsum "$wafiles" >"unlvtests/reports/$setname.wordacc"

Does pull request #1640 fix the problem with the UNLV tests?

Thanks @stweil. I had removed all quotes from those two lines and the script was working. I will test test with PR #1640 later today.
I am wondering though whether the problem is related to using a different version of bash, since the quotes were there in original script too - I was mostly making changes for new path for the files.
Here are the results:
Testid  	Testset Character               Word                    Non-stopword
					Errors  Acc     Change  Errors  Acc     Change  Errors  Acc     Change

1995		bus.3B	5959	98.14%	0.00%	1631	96.83%	0.00%	1293	95.73%	0.00%
1995		doe3.3B	36349	97.52%	0.00%	7826	96.34%	0.00%	7042	94.87%	0.00%
1995		mag.3B	15043	97.74%	0.00%	4566	96.01%	0.00%	3379	94.99%	0.00%
1995		news.3B	6432	98.69%	0.00%	1946	97.68%	0.00%	1502	96.94%	0.00%

4.0.0-beta	bus.3B	6158	98.10%	 3.34%	1136	97.88%	-30.35%	961		97.06	-25.68%	 4500.68s
4.0.0-beta	doe3.3B	29914	97.97%	-17.70%	13716	94.48%	 75.26%	13113	92.42	 86.21%	19882.96s
4.0.0-beta	mag.3B	10946	98.37%	-27.24%	3337	97.16%	-26.92%	2807	96.07	-16.93%	 7322.79s
4.0.0-beta	news.3B	5678	98.85%	-11.72%	1308	98.46%	-32.79%	1033	97.96	-31.23%	 5651.85s
4.0.0-beta	Total	52696	-		-17.38%	19497	-		 22.09%	17914		-	 35.55%

3.02.02		bus.3B	6039	98.11%	 1.34%	1541	97.01%	- 5.52%	1240	95.90	 -4.10%
3.02.02		doe3.3B	35988	97.54%	-0.99%	8482	96.03%	  8.38%	7640	94.43	  8.49%
3.02.02		mag.3B	14367	97.84%	-4.49%	3891	96.60%	-14.78%	3024	95.52	-10.51%
3.02.02		news.3B	7148	98.55%	11.13%	1484	98.23%	-23.74%	1152	97.65	-23.30%
3.02.02		Total	63542	-		-0.38%	15398	-		 -3.58%	13056		-	 -1.21%

I also included 3.02.02 results from https://github.com/tesseract-ocr/tesseract/wiki/UNLV-Testing-of-Tesseract - these were originally reported in the tesseract-ocr forum.

The original post by Tom Morris was in tesseract-dev group. Here is the link to the discussion thread which has info regarding other ground truth datasets.

Which traineddata did you used?

I used tessdata_fast.
The scripts will need further modifications to take training directory as parameter.
The power8 VM that I used has 4 cores. Cpu usage was 300% or so and if any other process was running then recognition time shot up. I had left the script running overnight.
The timing results will certainly be different on different machines. I don't know whether accuracy will also change.

I re-ran the tests for English with tessdata_fast and the numbers are slightly different. The only difference in scripts is conversion of the files to UTF-8 to allow for accented letters. For English, it is é.

1995    bus.3B  5959    98.14%  0.00%   1631    96.83%  0.00%   1293    95.73%  0.00%
1995    doe3.3B 36349   97.52%  0.00%   7826    96.34%  0.00%   7042    94.87%  0.00%
1995    mag.3B  15043   97.74%  0.00%   4566    96.01%  0.00%   3379    94.99%  0.00%
1995    news.3B 6432    98.69%  0.00%   1946    97.68%  0.00%   1502    96.94%  0.00%
4_fast_eng      bus.3B  6124    98.11%  2.77%   1138    97.88%  -30.23% 963     97.05   -25.52% 3935.26s
4_fast_eng      doe3.3B 30029   97.96%  -17.39% 13781   94.45%  76.09%  13178   92.38   87.13%  18847.36s
4_fast_eng      mag.3B  10934   98.37%  -27.32% 3343    97.15%  -26.78% 2813    96.06   -16.75% 6867.14s
4_fast_eng      news.3B 5734    98.84%  -10.85% 1322    98.45%  -32.07% 1040    97.94   -30.76% 5527.38s
4_fast_eng      Total   52821   -       -17.19% 19584   -       22.64%  17994   -       36.15%

Anything else should be done here?
Test image data are at https://github.com/tesseract-ocr/test
unittest are in https://github.com/tesseract-ocr/tesseract/tree/master/unittest

Anything else should be done here?

There remain some tests to be fixed:
baseapi_test
baseapi_thread_test
dawg_test
equationdetect_test
fileio_test
imagedata_test
lang_model_test
layout_test
ligature_table_test
lstm_recode_test
lstm_squashed_test
lstm_test
lstmtrainer_test
mastertrainer_test
networkio_test
normstrngs_test
pagesegmode_test
pango_font_info_test
paragraphs_test
params_model_test
qrsequence_test
recodebeam_test
resultiterator_test
scanutils_test
shapetable_test
stridemap_test
stringrenderer_test
tatweel_test
textlineprojection_test
unicharcompress_test
unicharset_test
unichar_test
validate_grapheme_test
validate_indic_test
validate_khmer_test
validate_myanmar_test

OSS Fuzz is now supported.

After going through the experience of undertaking the unit tests for a single contribution (#2294), I have a few suggestions here.
Foremost, I believe that the implicit dependency on the data repos should be made explicit (while still being optional): Currently make check relies on the assumption that data files were put in upward directories, which is some surprise and cannot be changed. Since submodules are already used here, why not just make tessdata, tessdata_best, tessdata_fast, and langdata_lstm submodules of the test submodule?
Also, why not simply skip all tests that cannot be satisfied due to missing data repos (instead of failing with crash reports)?
Moreover, I suggest including make check and all it entails (deps and data repos) into the Travis CI configuration.
Lastly, IMHO the tesstutorial on training should be fully scripted, with explicit dependencies, incremental stages and automated result verification. The individual commands would have to be split up into recipes of makefile targets I guess.

In the meantime we have more than 50 working unit tests. These tests are still missing:
pagesegmode_test – needs missing TIFF files
tatweel_test – needs files ara.* (from ara.traineddata?)

I have fixed the code for both, but they fail because of the missing files.

Thanks @stweil.
Do you think that tatweel_test will work if we extract the files from tessdata_fast/ara.traineddata?

The last subtest requires an old ara.unicharset to test backwards compatibility. I did not find one for that test, not even in the Git history of tessdata.

tatweel_test is now in Git master and automatically skips the subtests with missing files. Maybe @jbreiden can provide ara.wordlist and ara.unicharset which are missing here.

Maybe @jbreiden can provide ara.wordlist and ara.unicharset which are
missing here.

I think I can help.

@jbreiden provided the ara.* files, and tatweel_test is fine now. With a little help from Jeff, I also managed to make pagesegmode_test work.
So there are now 60 working unit tests with more than 300 working subtests for Tesseract.

@stweil and @jbreiden  Thank you for getting the unit tests working for tesseract.
@jbredien Are there any regression tests that can be open sourced?
Also, the LSTM langdata for Arabic is is the same as 3.0x langdata - only 80 lines of training_text. Is training data from Ray's last traaining run available?
@stweil It will be good to split the tests into legacy/LSTM. Then --disable-legacy could be used for testing only the LSTM tests.

pango_font_info_test now no longer depends on TensorFlow, see PR #3189.

@stweil Do you have a test suite for comparing performance + accuracy? It would be good to check the effect of recent changes.

@stweil Do you have a test suite for comparing performance + accuracy? It would be good to check the effect of recent changes.

No, I don't, but would like to have one, too. I recently started comparing the time for lstm_testwhich should be a good indicator for the training performance, but also for recognition performance with tessdata_best models.

No, I don't, but would like to have one, too. I recently started comparing the time for lstm_testwhich should be a good indicator for the training performance, but also for recognition performance with tessdata_best models.

maybe good start point regarding performance measurement is https://github.com/tesseract-ocr/tesseract/issues/263

maybe good start point regarding performance measurement is https://github.com/tesseract-ocr/tesseract/issues/263


Added proposal for power shelf management

Proposal spec and profile for management of a power shelf.
Currently version 0.9.0 to indicate this is a WIP for review and feedback.

I am not sure it matters but the LED’s are in the power supplies and not in the shelf.  We would want to take that into account, and probably have. [From Kevin Gero on the OCP Rack & Power mail-list, 2023.11.13]

The Fans are usually also within the PSUs, currently they seem to be listed as part of the thermal subsystem, which appears to be an external device to PSUs. Also thermal sensors are currently within the PSU, there are no thermal sensors defined within the power shelf itself. In addition i am wondering if this group also will define this for BBU (Battery Backup Shelf) ?

I am not sure it matters but the LED’s are in the power supplies and not in the shelf. We would want to take that into account, and probably have. [From Kevin Gero on the OCP Rack & Power mail-list, 2023.11.13]

We should be covered with this; I followed up offline and showed the spec puts the LEDs in the power supplies and not the shelf.

The Fans are usually also within the PSUs, currently they seem to be listed as part of the thermal subsystem, which appears to be an external device to PSUs.

The profile has two "IfImplemented" requirements around fans: 1) the "Fan" resource, which is used for fans in the shelf that are external to the power supplies, and 2) the "PowerSupplyMetrics" resource with the "FanSpeedsPercent" property for fans that are within the power supplies. The intent here with the usage of "IfImplemented" is to show that it's only a requirement to support if the power shelf design has those types of fans. Is it safe to say a power shelf will never be designed with fans outside of the power supply? If so, I can remove this from the spec and profile.

Also thermal sensors are currently within the PSU, there are no thermal sensors defined within the power shelf itself.

The power supply temperature sensors are covered with the requirement in PowerSupplyMetrics (with the TemperatureCelsius property). I was unaware the overall shelf did not have an overall temperature sensor. I'll remove that requirement from EnvironmentMetrics and ThermalMetrics to not require an "Internal" temperature sensor.

In addition i am wondering if this group also will define this for BBU (Battery Backup Shelf) ?

It's certainly something that has been brought up. However, the Redfish model itself doesn't have support for this type of design, so changes in the standard would need to be made first. Once that's done, we should make a separate profile/spec for that class of product. But right now this profile/spec is limited to power shelves.

Approved on March 5.  Need to bump to 1.0.


How can I batch updates to the created object before returning it?

Imagine this factory:
FactoryBot.define do
  factory :main_model

  trait :with_a do
    after(:create) do |main_model|
      # Both sides refer to each other, so this must be done in after(:create).
      main_model.update(a_id: create(:a, main_model_id: main_model.id).id)
    end
  end

  trait :with_b do
    after(:create) do |main_model|
      # Both sides refer to each other, so this must be done in after(:create).
      main_model.update(b_id: create(:b, main_model_id: main_model.id).id)
    end
  end
end

Note that we are not using ActiveRecord so we can't use any of the normal association support.  We must do this manually.  But, the associations are effectively has_one and belongs_to so that the association is recorded on both sides.  This means that we cannot create the associated objects (A and B) until the MainModel is created and we have the main models's instance ID, and we then need to update the MainModel after creating each of the associations.
The result of a call to create(:main_model, :with_a, :with_b), then, is the following:

create the main model
create the A class
update the main model
create the B class
update the main model

What I would like to do is combine steps 3 and 5 into a single update that runs right before the main model that was created in step 1 is finally returned to the caller.  In this example, it only saves one write, but some specs use many more traits, and we have dozens of thousands of specs, so the savings would not be meaningless.
I cannot figure out how to achieve this.  Any suggestions?
(I first asked on StackOverflow but wasn't able to get a working solution).

You might be able to get something working with transients:
require 'factory_bot'

class Thing
  attr_accessor :a, :b
end

FactoryBot.define do
  factory :thing do
    transient do
      should_build_a {false}
      should_build_b {false}
    end

    trait :with_a do
      transient do
        should_build_a {true}
      end
    end

    trait :with_b do
      transient do
        should_build_b {true}
      end
    end

    after(:build) do |thing, evaluator|
      thing.a = "A" if evaluator.should_build_a
      thing.b = "B" if evaluator.should_build_b
    end
  end
end

Ah, I see now it looks like people mentioned transients on Stack Overflow as well.
Another option might be to write some helper methods that create the objects with factory_bot, but then do the updating as a separate step outside of factory bot:
def main_with_a_and_b
  main = create(:main)
  a = create(:a, main: main)
  b = create(:b, main: main)
  main.update!(a: a, b: b)
end

I tend to prefer this second approach where possible, since it keeps the factories simpler.

I'd trade a complex factory for simpler specs any day.  😄
Basically I think what I'm looking for is a before(:return) callback that is invoked right before the factory returns the final object.  Just a way to do last-minute "stuff".  I can think of any number of ways to track that "stuff" needs to be done, there's just no hook point to do it in.

I'd trade a complex factory for simpler specs any day. 😄

The approach with a helper method could still keeps your specs simple. The helper method might live somewhere in spec/support, and the the spec itself would have something like main = main_with_a_and_b (rather than main = create(:main, :with_a, :with_b)).

callback that is invoked right before the factory returns the final object.

That is what the create callback already does. Triggering that callback is last thing that happens when using the create strategy.

The helper method might live somewhere in spec/support, and the the spec itself would have something like main = main_with_a_and_b (rather than main = create(:main, :with_a, :with_b)).

That would certainly work, but I don't want to have to create cover methods for each combination of main object and association that I might want.  I'd much prefer this to be something that "just works" in the factory so that I don't have to write the factories and associations and then go back and write the extra methods that people need to call when they need some arbitrary combination.

That is what the create callback already does. Triggering that callback is last thing that happens when using the create strategy.

... on a per-factory/trait case.  The after(:create) callback for the main factory runs before the after(:create) for each trait.  I can't write the association ids into the main model in the main factory's after(:create) because they haven't been created yet.  I can't use after(:build) for any of this to change the order because the point is to have IDs.
There is no single point at the very end of the factory run that could do anything with the object that is about to be returned.  It's exactly that that I think I need.


Fix Documentation Misalignments for Android Users

Note that this issue is only for testing purposes and I'll close it once GFI-Bot stabilizes. Sorry for spamming the collaborators!
google
chrome
echo "This is ONLY A TEST"

[GFI-Bot] Predicted as Good First Issue with probability 0.18%.

[GFI-Bot] Predicted as Good First Issue with probability 0.18%.

[GFI-Bot] Predicted as Good First Issue with probability 0.16%.

[GFI-Bot] Predicted as Good First Issue with probability 0.16%.

[GFI-Bot] Predicted as Good First Issue with probability 0.15%.


Modified the dark mode and toggler button

Modified the dark more toggler button and the dark theme.

resolve conflicts

done :)

please do again

done again :)

Thank you :)

dard mode is not working , can you please solve the bug

Ok i am looking after the issue

I have checked the website in 3 other devices and different browser and it is working fine. I think you have some problem.

it's working fine , thank you !


Can we run this project on ubuntu?

Hello! Thank you for your excellent work. Can I run this project on Ubuntu system?

Probably not, UE is not compatible with Ubuntu.


Add tests for cells sub-module

Description
What is this PR

[ ] Bug fix
[ ] Addition of a new feature
[X] Other

Why is this PR needed?
The coverage of the cells sub-module is currently only 70%, and there are very few docstrings explaining its functionality.
What does this PR do?
This PR expands the tests and docstrings, bringing the cells sub-module coverage up to 90%.
References
Closes https://github.com/brainglobe/brainglobe-utils/issues/57
Adds docstrings for https://github.com/brainglobe/brainglobe-utils/issues/19
How has this PR been tested?
Tests have been updated, and all pass locally.
Is this a breaking change?
No
Does this PR require an update to the documentation?
No
Checklist:

[X] The code has been tested locally
[X] Tests have been added to cover all new functionality (unit & integration)
[X] The documentation has been updated to reflect any changes
[X] The code has been formatted with pre-commit

Thanks @alessandrofelder ! I've added all of your suggestions now - feel free to merge if you're happy with it.


Abstract checkboxes into a common component that can be mapped.

Started in #144 will iterate to CheckboxComponent and LabelComponent


JQuery Autocomplete

Cannot get autocomplete to work with an input text box. When the suggested text is rendered it does not show up below the input text box. The open event is being called but nothing is shown to the user.

Hey @timi2shoes happy to help. Can you please provide some example code and/or a link to a page where we can observe this errant behavior? Thanks for using Vex!

Hey Adam,
The code I am using:
function edit_value_modal(value_id) {
vex.dialog.open({
message: 'Edit Value:',
input: '' +
'' +
'' +
'',
buttons: [
$.extend({}, vex.dialog.buttons.YES, { text: 'Add' }),
$.extend({}, vex.dialog.buttons.NO, { text: 'Back' })
],
callback: function (data) {
if (data !== false) {
        }
    }
});

}
I can get autocomplete to work on the same page on non vex items and it
works great.
Jquery I am using:
ajax.googleapis.com/ajax/libs/jqueryui/1.10.4/themes/smoothness/jquery-ui.min.css
ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js
ajax.googleapis.com/ajax/libs/jqueryui/1.10.4/jquery-ui.min.js
Hope that helps
-Tim
On Tue, Apr 21, 2015 at 3:46 PM, Adam Schwartz<EMAIL_ADDRESS>wrote:

Hey @timi2shoes https://github.com/timi2shoes happy to help. Can you
please provide some example code and/or a link to a page where we can
observe this errant behavior? Thanks for using Vex!
—
Reply to this email directly or view it on GitHub
https://github.com/HubSpot/vex/issues/119#issuecomment-94935438.

I also noticed that when the  is generated if I change the zindex to a
higher number than what vex has it will show up.
On Wed, Apr 22, 2015 at 3:14 PM, Shpetim<EMAIL_ADDRESS>wrote:

Hey Adam,
The code I am using:
function edit_value_modal(value_id) {
vex.dialog.open({
message: 'Edit Value:',
input: '' +
'' +
'' +
'',
buttons: [
$.extend({}, vex.dialog.buttons.YES, { text: 'Add' }),
$.extend({}, vex.dialog.buttons.NO, { text: 'Back' })
],
callback: function (data) {
if (data !== false) {
        }
    }
});

}
I can get autocomplete to work on the same page on non vex items and it
works great.
Jquery I am using:
ajax.googleapis.com/ajax/libs/jqueryui/1.10.4/themes/smoothness/jquery-ui.min.css
ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js
ajax.googleapis.com/ajax/libs/jqueryui/1.10.4/jquery-ui.min.js
Hope that helps
-Tim
On Tue, Apr 21, 2015 at 3:46 PM, Adam Schwartz<EMAIL_ADDRESS>wrote:

Hey @timi2shoes https://github.com/timi2shoes happy to help. Can you
please provide some example code and/or a link to a page where we can
observe this errant behavior? Thanks for using Vex!
—
Reply to this email directly or view it on GitHub
https://github.com/HubSpot/vex/issues/119#issuecomment-94935438.

Closing to clean up a little.