Optimize fontconfig fallback

There's some ideas in #456 which are worth pursuing to improve fallback performance. Specifically, it added caching for results of various fontconfig operations like font_sort. Additionally, it might be a huge win to store a custom FontSet which is the set of all fonts which have so far been used for fallback.

IMHO I don't think fontconfig is a very good piece of software for a number of reasons. One purely practical reason to observe fontconfig font substitutions would be that they are so prevalent on Linux and 'somewhat work'; everything else that I know about fontconfig makes me want to rip it out of my system rather sooner than later. It's altogether a trainwreck built on wrong assumptions using a hellishly convoluted and poorly documented XML configuration that wants to cover everything but achieves very little. I'm not qualified to post a full-fledged rant here, but let me just point out that

you cannot target single codepoints or ranges of codepoints in fontconfig, meaning that wherever you insert a given font into the the font stack, all of its glyphs will share the same priority. This feature—named font selection by codepoint, for which see below—which is absolutely essential to build virtual fonts, has been requested by users for years but never got implemented.

fontconfig is wrongly assuming that configured language is the primary point to decide about displaying a given codepoint using the one or the other set of rules. While this makes sane font selections ridiculously complicated, it can never work from the get-go in most cases because most environments lack that piece of data. Sure, you have your system configured to use the de_DE or the en_US locale, but what happens when you write an email in French? In practice, this assumption often leads to a jarring jumble of different fonts in different styles on Chinese and Japanese web pages, depending on what parts of what rules happened to be triggered by a given codepoint.

As a side effect of the above, writing your own fontconfig rules is extremely error prone, and even when you achieve what you wanted in some programs, you will likely mess up font display in other software.
Most terminal emulators that I have tested so far offer two choices for display: Use the system monospaced font, or select one from the dropdown. Disclosure: I managed to get like 85% what I wanted (each of 85.000 CJK codepoints in a font of my choice) using the system font choice and writing my own fonts.conf, but I also messed up the display of quite a few webpages and less-important applications.
The alternative I see to using fontconfig is a font selection mechanism that is patterned on CSS3 @font-face and unicode-range. In fact, https://github.com/kovidgoyal/kitty#font-control promises to deliver exactly this (I'm installing dependencies as I'm writing, so I can't yet say whether it works).
In fact, I think font selection should be done by a separate piece of software that offers the potential to be re-used across applications. A minimal viable solution could have the capability to identify fonts (optionally via filepaths to circumvent fontconfig interventions and the many, many vagaries that have been constructed around font-selection-by-name, what with true vs simulated italics and bold faces etc), link (ranges of) Unicode codepoints with fonts, and offer a way to stipulate whether a codepoint should be rendered as normal (aka 'half') or double (aka 'full') width.

Interesting! Thanks for the detailed feedback about fontconfig. It seems that supporting something like unicode-range would actually be really straight-forward and could be added as part of the upcoming Alacritty font configuration changes: #957.

 I'm ready to think more about this subject, as I have to do anyhow for my work where I'm faced with having to select the right font for the right codepoint in various applications, one of them being a MarkDown -> (Xe)(La)TeX -> PDF typesetting workflow, the other being text editors, web browsers and the command line.
One of the most valuable tools that I've been using over the years is BabelMap, a Windows Unicode viewer that runs fine on Linux under Wine. For years this was virtually the only convenient tool I had to look up how exactly a given codepoint renders in a given font without being mislead by font substitions, and also vice versa to see what codepoints were supported by a given font. This unassuming free tool does it better than many fat and costly applications manage to, and it does so in very simple ways. I just opened it to have another look at its Composite Font Configuration dialog, where you can select Unicode block by block and assign a different font to each one from a selection list that has a figure for % coverage and a preview. If that wasn't enough, you can ex- and import your settings; turns out the author uses a simple XML format:
<?xml version="1.0" encoding="UTF-8" ?>
<CompositeFont unicode="10.0" lang="en">
	<Block start="0000" end="007F" name="Basic Latin">Sun-ExtA</Block>
	<Block start="0080" end="00FF" name="Latin-1 Supplement">Sun-ExtA</Block>
	<Block start="0100" end="017F" name="Latin Extended-A">Sun-ExtA</Block>
	<Block start="0180" end="024F" name="Latin Extended-B">Sun-ExtA</Block>
	<Block start="0250" end="02AF" name="IPA Extensions">Sun-ExtA</Block>
	<Block start="02B0" end="02FF" name="Spacing Modifier Letters">Sun-ExtA</Block>
	<Block start="0300" end="036F" name="Combining Diacritical Marks">Sun-ExtA</Block>
...
	<Block start="F0000" end="FFFFF" name="Supplementary Private Use Area-A">Aegyptus</Block>
	<Block start="100000" end="10FFFF" name="Supplementary Private Use Area-B">Samyak Devanagari</Block>
</CompositeFont>

I'm not into XML but I can totally live with this level of complexity. This is like 80 or 90 percent of what fontconfig should have ever been about.
Basically what is needed in my opinion is the ability to name a 'display flavor' and then add physical fonts in a ranked listing where later mentions overrides earlier mentions (fontconfig got this one wrong which is why you always have to explicitly prepend your own rules to the set of existing rules; CSS got it right). The ranked listing should provide a way to specify single codepoints or ranges of codepoints; probably there should be an option to specify what to do with 'holes' in the font (i.e. with codepoints that provide no glyph; most of the time, but not always, you'll want missing glyphs to be filled in from fonts lower in the ranking).
BTW over the years I've come to reject the whole idea of having one font with several 'styles' such as italic, bold or bold-italic. These terms largely only apply to Western typography anyway; what you really want is a sound collection of typefaces that go together well in the same document. Think of it like an oldskool typesetter: Whatever is put together in one case is a font; when you want to emphasize a word, set a quoted passage, or add a headline, you have to break out another case (another font, i.e. another file). One huge advantage of digital type, at least vector type, is that one 'master' may be used for any number of sizes; but, as in lead type, if you typeset in LucidFooRoman and there's no italics coming with that typeface, just go and grab another typeface that harmonizes.
As far as terminal emulators are concerned, I think if you want styled type at all, then what you really want is configurable, named 'flavors' of type. In this thinking a whole layer of complexity that has never really worked satisfactorily is summarily done away with.


Register 1 initialization nibbles are flipped

should be:
_register[0] = 0x00;
_register[1] = 0x04;
not
_register[0] = 0x00;
_register[1] = 0x40;

Thanks for reporting
Will look into datasheet tomorrow to verify.

From datasheet:

The value should indeed be 0x04 to set BUFFER_SELECT to 1.
I will prepare a PR asap.

PR made, build is running.

@sjthomsen
Build is successful, does the library work as expected after your fix?
Or are there things missing (that could easily be included) ?
Thanks again for finding the bug!

Works great.  Sorry for the delayed response.  Busy weekend and wasn't able to check it until today.

No problem, I rechecked changes after a good nights rest and it still made sense soI merged it.
Thanks again for reporting the bug!


Removed the "Delete" action in item details #189

Did you intend to delete the home.vue file?

I did it by accident and I am trying to recover it. Sorry about that.

Not a problem, just wanted to check on things because that looked a bit unusual.
You can look into reverting the commit, e.g. this link, or probably better, you could reset your branch head to the previous commit and then force push (and you could look into the --force-with-lease option). You should expect to run into some more tricky parts of git if you have never done any of these before, so don't be surprised if it takes a while to sort out your confusion.
It isn't always a good idea to force push on a branch that you have already pushed to a remote repo, but in this case it should be ok because no one is likely to have based further work off of this branch.

Thank you for the tips.

Was this PR approved before it got merged? Looks like there might have been some review from Daniel, perhaps an out of band approval?
I want to make sure we are waiting for approval from another developer before merging.

Sorry, my bad. I saw Daniel reviewed it so I merged. I will wait for approval before merging next time.
Should I revert and restore the branch?

I think this one is fine to leave merged, thanks. Yes, let's wait for a more explicit approval, through the GitHub approval.


AppExit should return from App::run without quitting the process

It seems a bit counter intuitive that when default plugins are added, App::run() is effectively a diverging function that never returns. This means that any code after the call to App::run() is silently ignored.
With add_default_plugins
use bevy::prelude::*;

fn main() {
    println!("Before");
    App::build()
        .add_default_plugins()
        .add_startup_system(setup.system())
        .run();
    println!("After");
}

prints:
Before

When the window is closed, the process exits and App::run() never returns.
Without add_default_plugins
In the hellow_world.rs example that doesn't add default plugins this behaves more as I would expect:
    println!("Before");
    App::build().add_system(hello_world_system.system()).run();
    println!("After");

prints:
Before
hello world
After

Conclusion
In my opinion the most intuitive behavior would be if the AppExit event just caused the App::run() function call happening on the main thread to return control (as it does in the hello_world example).

This might be unresolvable, due to how winit works - it has to take over your main thread forever; one of the default resources, as far as I know, is that.

In that case it might make sense to have run always diverge ( -> !) so that the compile can tell you that code after it is unreachable.

This is a tough one. On the one hand, I like knowing when code is unreachable. On the other hand, for apps that dont need winit, I'm not sure I want to prevent them from being used within a larger context.
Ideally we can find a way to make winit return. If not I'm inclined to leave the current behavior the way it is, despite the slightly confusing divergent behavior. I'm happy to discuss this more though.

Ex: allowing Apps to return makes it much easier to write unit tests

For what it's worth, it's possible to have it return on desktop targets (where most unit testing should/will happen, I think), but there are caveats, as outlined in the link. Perhaps a variant of the plugin, for testing and that one inevitable odd setup that cannot live without it?

@Ratysz Thank you for that link. I was digging in the winnit code a bit trying to see if it was configurable but that was the piece I was missing.
I took a look at the macos implementation of run to understand the difference between run and run_return and learned that besides the closure type that they take (as mentioned in the documentation linked), run really does just call run_return followed by process.exit(0). So at least there aren't a lot of implementation details that might complicate the our options.

Here's a similar bug a similar bug winit that goes into some detail about the design decision there. One caveat that I think we should be aware of as consumers of winit is that if there is anything in scope that is not captured by the closure passed in to run no destructors for items will be called. As long as everything is moved into the closure, it will be destructed between the run_return and exit calls.

So I've given this a bit of thought and I think it'd be great to add an extension on to App supporting the same configurations supported by EventLoopExtDesktop which would allow us to configure App to return from run.
This would let us use it in tests as well as let clients of Bevy make an informed decision for their projects. I'd write similar caveats into the documentation for the new API linking to the caveats in the dependency.
@Ratysz, @cart what do you think?  If that sounds good I'd be happy to take the issue.

I think that shouldn't be tacked on to App, but rather passed into winit via a configuration Resource of some kind (ex: WinitConfig { run_return: bool })
I'm cool with giving people choices. It seems pretty clear (given the winit docs) that the default should remain as it is though.
So yeah that sounds good to me!

Yes it is necessary


Uploading folders using File Management converts them to text

I know you can use SFTP for this stuff, but as I've begun hosting more and more servers for people, they continue to want to use the file manager. Since it's built in, it really should support the addition of folders. Presently, if someone clicks and drags a folder into the file manager, it uploads that folder as a text file. None of the contents within are brought over.

At this point it should just toss a warning that you can't upload folders. I do not believe it will ever do that since there would be a significant amount of logic required to pull that off, and it was never designed to replace SFTP for complex actions such as uploading an entire folder and its subfolders.


chrome: bump OTLP version

This PR proposes to bump OTLP version [1]. The generated code does not have changes.
[1] https://github.com/open-telemetry/opentelemetry-proto/releases/tag/v1.0.0

Looks good.


docs: fixed typos in tipsi-stripe migration guide

 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.


Fixed #22125 - Don't create extraneous index on autocreated through models

This patch is based on all the suggestions in https://code.djangoproject.com/ticket/22125.

Check the test failures and a new test is required.

Do you plan to pursue this further, Phil?

Closing due to inactivity.


chore: bump baseline version requirement of sub crates

What does this PR try to resolve?
Closes https://github.com/rust-lang/cargo/issues/13493
While we can just bump to the latest versions, this time we do a conservative one for some crates.

cargo-util --- 0.2.10 to 0.2.11 contain only comment changes.
cargo-platform --- 0.1.6 to 0.1.8 contain only lint and metadata changes.
rustfix and cargo-util-schemas contain actual behavior changes.

How should we test and review this PR?
Currently, there is no Cargo-native way to dry-run cargo publish.
Cargo itself can benefit from https://github.com/rust-lang/cargo/issues/1169 to avoid issues like https://github.com/rust-lang/cargo/issues/13493 from happening.
Additional information

@bors r+

:pushpin: Commit edd2821f4637b806f5114904266fa89a0328d1fd has been approved by epage
It is now in the queue for this repository.

:hourglass: Testing commit edd2821f4637b806f5114904266fa89a0328d1fd with merge bf5acf8e58303f120e500f6645360fecf73f237f...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing bf5acf8e58303f120e500f6645360fecf73f237f to master...


Move exampleData.js into auxiliary

... thereby allowing us to get rid of its dummy test.

I'm glad we found a good place to put this! It wasn't always known (https://github.com/zulip/zulip-mobile/pull/3727#issuecomment-566719420) that we could have Jest ignore certain files so they aren't required to have dummy tests.
I bet there are other places we can take advantage of this, but I don't think they should block merging this — in fact, due to the (fortunately) somewhat increasing activity in exampleData, it would probably be good to get this merged as quickly as possible, or this PR will gather some rather annoying merge conflicts.
Looks good to me.

Maybe, including something like

__tests__/auxiliary is skipped by Jest (see jest.config.js)

also in the first commit might be useful, since this I think the first commit is a little more visible to people wondering why the move was done.

Thanks @ray-kraesig for this cleanup!
I like the idea of putting this file along with lolex.js in a subdirectory. Looking at this diff is kind of making me regret the name auxiliary, though -- it's a bit of a mouthful to type, and I don't want these test helpers to feel like a pain to go reach for.
How about lib? That's short and feels quite conventional -- and in Zulip in particular it's already what we have for tools/lib/ and the server/webapp repo's tools/lib/ and scripts/lib/.
I'll push a revision of this branch with a quick rename added in front. Please take a look.

I bet there are other places we can take advantage of this, but I don't think they should block merging this — in fact, due to the (fortunately) somewhat increasing activity in exampleData, it would probably be good to get this merged as quickly as possible, or this PR will gather some rather annoying merge conflicts.

Indeed. I've got at least one other PR that's been waiting on this one, specifically to avoid those merge conflicts. :disappointed:
Amended my commit messages per your suggestion, above, and merged (including Greg's rename).


IN queries

Most Firestore clients now support this, but I see no progress made on the Java side. Is this coming soon?

The IN & ARRAY_CONTAINS_ANY query filters were released in version 1.29.0 back at the end of October.
Code samples can be found published in the official docs here: https://cloud.google.com/firestore/docs/query-data/queries#in_and_array-contains-any
Javadocs can be found published here: whereIn whereArrayContainsAny

My mistake! I need to bug the firebase-admin-java guys to update their dependency version.


Should CRD's auto upgrade on installation of new version?

Question: on installing of a new release, does the controller (or anything else) upgrade the crds?
Thanks

Yes it does if you're using HelmRelease to manage it.

We are, but the upgrade to the most recent rc release didn't update the crd in the cluster.
Could you confirm the latest helm release version? (Or point me to the place I can find it?)
Cheers

I was being stupid, upgraded the image tag and not the helm version. Thanks for the quick reply @chanwit


RT-5.1 - Add Tolerance for ipv6 control packets and traffic fix

Following Changes done to singleton_test

Tolerance for ipv6 control packets

Skip traffic check for packets larger than MTU

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1462

Relevant Lines:
2012

💛  - Coveralls

Xiao, Yan, can you please have a look?
The changes, in short:

adding 6 packets as a margin for ipv6 traffic (multicast based neighbor discovery. Might be observed up to two times due to test length, with three packets needed in each run)
Not checking drops for MTU+ sized packets (they are dropped).

LGTM from my side

cc: @jjing1122


custom op 'linalg.pad_tensor' is unknown

Describe the bug
I've compiled a tensorflow saved_model using 'iree-import-tf'.
The generated MLIR contains the "linalg.pad_tensor" operation.
When I compile using 'iree-compile', it shows that "custom op 'linalg.pad_tensor' is unknown"
I find there is a patch that moving this operation to 'tensor' dialet.
https://reviews.llvm.org/D117892
Is there a consistency issue between the front end and the MLIR?
BTW, the tool 'iree-import-tf' is installed by python pip.
How can I build 'iree-import-tf' from the source?

It's been moved for a while. The latest release/tag should contain the change. You won't hit the issue if you update the package.
For building it from source, please see https://google.github.io/iree/building-from-source/python-bindings-and-importers/#python-bindings-and-importers

I'm using the latest tag 'candidate-20220413.106'
It has the same issue.


make sure it is defined

assign empty string instead of undefined variable to get rid of the Undefined index notice

Thanks for the request. Unfortunately this module version isn't the latest. I have done various changes already but need to commit it at some point. This line of code isn't in there anymore anyway.

OK, Thanks for the module anyway. I keep using it in this version until the update. For now it suffices.


Remove gofileutils?

github.com\cloudfoundry\gofileutils also appears to perform the same glob function as github.com\bmatcuk\doublestar, although it appears to only work with Unix and doesn't appear to be used anywhere in the code.

Removed:
https://github.com/cloudfoundry/bosh-utils/commit/6593370c83ab0f0dba0965c2563a44c78b42a104
https://github.com/cloudfoundry/bosh-cli/commit/a1f37f620ab02833ccfcd117bc605d11b0be3b19
I verified github.com/cloudfoundry/gofileutils was not used in github.com/cloudfoundry/bosh-agent, so the removal should be safe.


wlan-ap-consumer

Access point implementation using cfg80211 platform and standard OpenSync services.

Hi
kindly consider to rework the patch annotation of all 3 patches
"wlan-ap-consumer: $subject
$description
Signed-off-by: Name "
Thanks !

@lkristan-plume Hi
static code analyses spotted various errors, including null pointer derefs
https://github.com/Telecominfraproject/wlan-ap/pull/152/checks?check_run_id=1927307209

static code analyses spotted various errors, including null pointer derefs
@blogic, AFAICS the failures are in parts of code not touched by our commits. I presume the static analysis checks were introduced recently, and the offending parts of code were not fixed yet on trunk.

@blogic any update on static resolution ... we would like to get this patch approved asap since we have Adtran waithing with BCM and MTK contributions

@blogic, PR has been rebased and updated

Hi @cbuschfb Please note that 'consumer' product and its services are implemented as a separate feed and do not modify any of the code used for 'enterprise' mainstream products. The main change regarding the use of OVS is in this commit: https://github.com/Telecominfraproject/wlan-ap/pull/152/commits/0ca28d37a1a999a9bffb934e8586c697f479f062. The change is not affecting API therefore it should be agnostic also to the cloud, but at this point in time several of 'consumer' advanced services rely on OVS and use standard OpenSync managers OM, FSM, FCM which was the reason for adding it on-top.
At the moment 'consumer' and 'enterprise' products (feeds) differ only on some "service" needed code where majority is the same and as we agreed we shall work towards merging common and OpenSync code as we should also work towards adding CI sanity testing.


Fix #13518

Fix #13518
use per-dataset settings instead of default colors to prevent the responsive behaviour change the chart color

Description
To the chart initialization for stats widget the responsive option of chartjs override the defaults color settings randomly according to the amount of chart instances, to prevent it, this require set the colors using per-dataset settings.

Visual changes

after

Functional changes

[x] Code style has been fixed by running the composer cs command.
[x] Changes have been tested to not break existing functionality.
[x] Documentation is up-to-date.

Thanks! Is it also worth doing this for the normal chart widget too in components/chart.js?

Not really, the normal chart widget only has one instance of chartjs, there is no conflict there.

Can you make it consistent though please? :) You can also use more than one chart widget on a page, not sure if that affects it

In the normal chart widget the instance can receive an array with multiple datasets so we can't use the per dataset configuration, the current definition is the best option or do you want to read all the data and set the required properties? but I have found many options set by default attribute.
In the stats chart we can define multiple instances of chartjs from a single filament widget and all of them are defined using the same value of refs “canvas”. so the same refs name creates a conflict with the chartjs resize function but in the normal widget there is only one instance of chartjs so there is no conflict here, even when you have many widgets per page.

Thanks for the explanation!


Users have the option to sign up for the AppMap Analysis beta

The AppMap Analysis beta will be available to users who contact us through the website at appland.com/appmap-analysis-beta.
Message the user via Visual Studio Code notifications  as well as in the empty 'Findings' pane. Users will only be notified if they are "eligible", which means:

Ruby project
Ruby agent is installed
They have already recorded AppMaps in that project

Proposed wording for the VS Code notification:

Proposed wording for the sidebar CTA:

:tada: This issue has been resolved in version 0.33.0 :tada:
The release is available on:

v0.33.0
GitHub release

Your semantic-release bot :package::rocket:

Are we calling it Beta?
Technical preview?
Early access?
On Wed, Jun 22, 2022 at 5:54 PM Daniel Warner @.***>
wrote:

The AppMap Analysis beta will be available to users who contact us through
the website at appland.com/appmap-analysis-beta.
Message the user via Visual Studio Code notifications
https://code.visualstudio.com/api/ux-guidelines/notifications as well
as in the empty 'Findings' pane.
—
Reply to this email directly, view it on GitHub
https://github.com/applandinc/vscode-appland/issues/408, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAVC64EVADLJZ6A2HS4VILVQODPTANCNFSM5ZR4SEGA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


(PUP-7330) Add gen_hosts dependency for quick target

Add the gen_hosts task as a dependency of ci:test:quick so that the
beaker-hostgenerator file is created before calling beaker.
/cc @puppetlabs/agent-team
This needs to be merged up to 4.10.x and master

Successfully creates host files and executes quick suite.
SHA=1.9.3 TEST_TARGET=debian8-64a bundle exec  rake ci:test:quick
...
              - Test Case Summary for suite 'pre_suite' -
       Total Suite Time: 102.86 seconds
      Average Test Time: 14.69 seconds
              Attempted: 7
                 Passed: 5
                 Failed: 0
                Errored: 0
                Skipped: 2
                Pending: 0
                  Total: 7

...
              - Test Case Summary for suite 'tests' -
       Total Suite Time: 572.53 seconds
      Average Test Time: 35.78 seconds
              Attempted: 16
                 Passed: 16
                 Failed: 0
                Errored: 0
                Skipped: 0
                Pending: 0
                  Total: 16

merged to 4.10.x at e6fa8bdf72a366c5f5893ed2e2c6b98e5f4380a2
merged to master at 2cae7c1508495e72bcfa859067609b3b787c065e


fix(meta): device yaml marshal to Json  error

when add some complex vaules to the attributes of deviceResources in the device profile, error happens. use gopkg.in/yaml.v3 instead of gopkg.in/yaml.v2
Fixes: #3682
Signed-off-by: wangshihui<EMAIL_ADDRESS>PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/master/.github/Contributing.md.
What is the current behavior?

Issue Number:
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

New Imports

[x] Yes
[ ] No

Specific Instructions
Are there any specific instructions or things that should be known prior to reviewing?
Other information

once you remove gopkg.in/yaml.v2, please also remove it from Attribution.txt

Codecov Report

Merging #3683 (99d79da) into main (e58d3ad) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #3683   +/-   ##
=======================================
  Coverage   47.27%   47.27%
=======================================
  Files         112      112
  Lines        9180     9180
=======================================
  Hits         4340     4340
  Misses       4466     4466
  Partials      374      374

Impacted Files
Coverage Δ

internal/io/reader.go
74.07% <ø> (ø)

Continue to review full report at Codecov.

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


feat: gics_classification has both 4-digit and 6-digit codes

Currently, gics_classification has both 4-digit and 6-digit codes.
Since 6-digit is required to map to most PACTA sectors, I would suggest we only support that level of granularity (it seems disingenuous to offer 4-digit codes when we know they won't be sufficient for analysis in the end).
(See how "construction materials" gets mapped to "cement")
Thoughts @jacobvjk ?
r2dii.data::gics_classification |>
  dplyr::filter(nchar(code) == "6")
#> # A tibble: 68 × 4
#>    description                 code   sector       borderline
#>    <chr>                       <chr>  <chr>        <lgl>
#>  1 energy equipment & services 101010 oil and gas  TRUE
#>  2 oil, gas & consumable fuels 101020 oil and gas  FALSE
#>  3 chemicals                   151010 not in scope FALSE
#>  4 construction materials      151020 cement       TRUE
#>  5 containers & packaging      151030 not in scope FALSE
#>  6 metals & mining             151040 steel        TRUE
#>  7 paper & forest products     151050 not in scope FALSE
#>  8 aerospace & defense         201010 not in scope FALSE
#>  9 building products           201020 cement       TRUE
#> 10 construction & engineering  201030 not in scope FALSE
#> # ℹ 58 more rows

Created on 2024-03-19 with reprex v2.1.0

based on what I have seen, GICS has 8-digit codes for sub-industries. I would suggest including 6 and 8 digit codes. Even at 8 digits, GICS does not map neatly to PACTA sectors. We will have to live whit that.
https://www.msci.com/our-solutions/indexes/gics
https://www.spglobal.com/marketintelligence/en/documents/112727-gics-mapbook_2018_v3_letter_digitalspreads.pdf


DTArray fix only partially applied

see https://github.com/jsm174/vpx-standalone-scripts/issues/132
That table seems to not have the part where it inserts the DropTarget class so it's only applying a partial fix.
We should probably make sure we put the class somewhere else then. Or detect this and fail the patch. Or let the user know the patch was only partially applied.

Another issue where this time the setup lines are not handled
https://vpuniverse.com/files/file/8357-fog-the-gottlieb-1979-complete-package/

same with https://virtual-pinball-spreadsheet.web.app/game/UQ6dnKLa/

And another one
https://vpuniverse.com/files/file/7492-space-shuttle-williams-1984/

Looks like all bord tables are affected? https://vpuniverse.com/files/file/11451-batman-the-dark-knight-stern-2008-bord-mod/

https://github.com/jsm174/vpx-standalone-scripts/pull/150


Support regex image tag filtering

At the moment Flux only offers support for wildcard filtering (e.g. prod-*, v1.8.*, etc).
This works perfectly fine if you are in control of how the images are getting tagged, however, if you are using images from an external vendor you will run in to problems pretty fast.
It is a common pattern to build additional images on top of a base image and tag them with a suffix describing the addition (e.g. 1.0 and 1.0-jmx, see for an example https://hub.docker.com/r/datadog/agent/tags/). These images will get rolled out last so Flux will detect them as the eligible new image (as it looks for the last published images that matches the filter requirements).
I briefly discussed this issue some weeks ago with @squaremo on Slack who proposed a semver:^1.8 solution (as an addition to glob:1.8.*). I do however think this solution would be insufficient as semver tagging is as common as using the latest commit hash.
Instead I would like to propose a regex filter option that looks for pattern matches, this is highly configurable and can get as complex (and nasty) as required. Eliminating issues with whatever weird tag the user wants to keep track of.

semver tagging is #706. Would you mind explaining in more detail why what is proposed there is insufficient?
One of the advantages of semver is that it provides an order, i.e. you can always determine which is the "best" version. That is not the case for a regexp match.

Would you mind explaining in more detail why what is proposed there is insufficient?

Edge cases where images are not published using semver. The Docker ecosystem is already huge - and growing every day. One of the ideas behind Docker images it that they should be reusable. With this comes the problem that everyone has their own tagging strategy and semver is not as common as one may think.
I think this addition would make Flux 'feature complete' for 99% of the edge case scenarios as it allows complex filtering.

One of the advantages of semver is that it provides an order, i.e. you can always determine which is the "best" version. That is not the case for a regexp match.

This is true, but this is also not the case for the current glob filter.
Imagine the following scenario: you have a glob:v1.8.* filter on one of your deployment manifests, the vendor of the image you are using publishes a new v1.8.1 image and shortly after that a v1.8.1-foo image with some additions you are not interested in. Flux will now detect the v1.8.1-foo image as the latest image and deploy it in the cluster.
With a regex you could filter out this -foo addition and tell Flux you are only interested in the newest image that matches your pattern.
As an addition @squaremo provides an additional issue that semver would have with this pattern:

mbridgen [4:20 PM]
And the reason semver won't cover that is that it treats -foo as a prerelease, so if you do want the foo variation, you can't express that
(though if that's the only reason, a tweakable semver would be better)

Taking all this in consideration: I think #706 should have a higher priority as it is easier for a user to configure and will also solve the scenario described above.
However, for edge cases that require complex filtering - because someone has other ideas or you really enjoy doing exotic stuff - this should be added to Flux when there is time.

Imagine the following scenario: you have a glob:v1.8.* filter on one of your deployment manifests, the vendor of the image you are using publishes a new v1.8.1 image and shortly after that a v1.8.1-foo image with some additions you are not interested in. Flux will now detect the v1.8.1-foo image as the latest image and deploy it to the cluster.

With regard to exactly this scenario, semver filtering with semver:~1.8 would do what you wanted: the non-pre-release version (v1.8.1) has precedence over the pre-release version (v1.8.1-foo).


Yc wk7

update PPP file name and its link in AboutUs.md

Codecov Report
Base: 70.62% // Head: 70.62% // No change to project coverage :thumbsup:

Coverage data is based on head (7acb764) compared to base (b6eb31c).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master      #30   +/-   ##
=========================================
  Coverage     70.62%   70.62%
  Complexity      404      404
=========================================
  Files            73       73
  Lines          1280     1280
  Branches        131      131
=========================================
  Hits            904      904
  Misses          335      335
  Partials         41       41

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Extend dockerfile part

More exercises on writing dockerfiles, e.g.:

COPY
ADD
ARG
ENV
WORKDIR
ENTRYPOINT
USER

Difference between ADD and COPY: https://stackoverflow.com/questions/24958140/what-is-the-difference-between-the-copy-and-add-commands-in-a-dockerfile

Difference ENTRYPOINT and CMD:

ENTRYPOINT makes container behave as executable (can not be overridden by positional arguments)
CMD: more flexible. Can be also be used to provide default arguments to ENTRYPOINT

Image annotation here: https://github.com/opencontainers/image-spec/blob/v1.0.1/annotations.md


Additional annotation for 2,6-diaminopurine (CHEBI:38001)

It would be useful if the below details could be added to the 2,6-diaminopurine (CHEBI:38001) entry.
Synonym: 2-aminoadenine
A  has functional parent relationship with adenine (CHEBI:16708) should be added.
Chemical details, including SMILES can be imported from its PubChem entry: https://pubchem.ncbi.nlm.nih.gov/compound/30976
The below references could be added:

Kirnos, M., Khudyakov, I., Alexandrushkina, N., & Vanyushin, B. (1977). 2-Aminoadenine is an adenine substituting for a base in S-2L cyanophage DNA. Nature, 270(5635), 369-370.
Khudyakov, I., Kirnos, M., Alexandrushkina, N., & Vanyushin, B. (1978). Cyanophage S-2L contains DNA with 2,6-diaminopurine substituted for adenine. Virology, 88(1), 8-18.

Hi Coby,
CHEBI:38001 is actually a class name rather than an individual compound - I have added an 's' to the end of the name to make it clearer. It doesn't have a structure as the term can include various tautomers (double bond/position of the N-H, etc.) as well as substituents at any position, so there is no InCHI, SMILES, etc.
The entry you probably want is 9H-purine-2,6-diamine (CHEBI:40235), which I have now updated to include the references and functional parent relationship you mention.
Best regards,
Gareth

Great; thank you! I appreciate the explanation.


Updated to the helm v3

There are some changes about compatible the helm version 3.
Also did some changes in the k8s manifests. The old manifest didn't pass the validation of the k8s version 21 rules.

Thank you for making this work with helm 3, I checkout out your PR and I can confirm that it now works on my localhost.


Move big number calculator interactive

Move interactive from Complexity and Tractability chapter

Click to load
big number calculator

outdated - content moved already


[W-11170848/W-11164006/W-11147296/W-11148437/W-11374554]  Elevate Experience Sites

Technical Design Review
[Technical Design Review] W-11170848/W-11164006/W-11147296/W-11148437/W-11374554 - NPSP
Changes
As part of this task, we first fixed the Elevate component currently used in the CRM to work with Elevate fields so that it can also work from the Digital Experience Site. Then part of the existing logic was reused to edit the Elevate Recurring Donation data and have it reflected in Elevate. It was updated the Elevate fields widget to be able to use different style when it is used from the Digital Experience Sites. Added Amount validation only for Experience Sites. Removed Elevate message from the spinner component only for Experience Sites.
Work Closed
W-11170848
W-11164006
W-11147296
W-11148437
W-11374554

@andrewyu-salesforce and @npsp-reedestockton There are good number of RD entry form changes in this PR.  The one that catches my eye is that there's a lot of dynamic CSS injection code in the JS. That may be ok, but it did stand out to me.

@alvaroolivenciasf Looking at the technical design doc, the testing plan is focused only on the donor's experience. Because this PR makes significant changes to the functionality that is used in both single RD entry and I believe shared by Batch Gift RD entry, there will need to be much more testing and validation. There's a decent sized test suite for RD's you can use as a start. @npsp-reedestockton and @andrewyu-salesforce may have more to add to this as well.
Also bringing @voduyemi into the conversation because this may have an impact on the gift entry UI work in 240.

@alvaroolivenciasf Looking at the technical design doc, the testing plan is focused only on the donor's experience. Because this PR makes significant changes to the functionality that is used in both single RD entry and I believe shared by Batch Gift RD entry, there will need to be much more testing and validation. There's a decent sized test suite for RD's you can use as a start. @npsp-reedestockton and @andrewyu-salesforce may have more to add to this as well.
Also bringing @voduyemi into the conversation because this may have an impact on the gift entry UI work in 240.

You are right @force2b. We informed about the CRM testing back on June 8th: https://salesforce-internal.slack.com/archives/C02MMGUPBSB/p1654700569241029. In that thread we stressed out the importance of your testing.
As part of the donor's experience testing, @nadiasanchez is also testing the CRM side, but as you said, her testing is much more focused on the donor's experience rather than CRM experience (and as you already know, she found a couple of possible bugs in the CRM side we shared with you in slack).


Using SAX instead of DOM for type inference and Row conversion

Building a full DOM tree for each XML record is very expensive and unnecessary, since we only need to traverse the contents once for either type inference or Row conversion. Using SAX can probably win much better performance.
Link from https://github.com/HyukjinKwon/spark-xml/issues/8

For this issue, I got a reason to use DOM. Mostly the main reason is to infer ArrayType. In order to infer ArrayType, it needs to check all the child keys (child elements) in each record in a XML and decide it is a StructType when it has a single key or ArrayType when it has duplicated multiple keys.
(I also manually gave a precedence for ArrayType higher than StructType at InferSchema in case that some records have a single key (field) A, namely inferred as StructType, while others can have duplicated multiple keys (fields) A, namely inferred as ArrayType, where key (field) A should be inferred as ArrayType)
At the first I used StAX, but I realised that the implementation actually works almost like DOM (It just read all the elements for a record first and then started to process). So I changed it to DOM #2.
Maybe there is another clever way but I could not come up with one. It would be great if there is a good way to resolve the problem with SAX.
I think anyway it can use SAX for constructing Rows as the problem is only about type inference.
Link from https://github.com/HyukjinKwon/spark-xml/issues/8#issuecomment-159764517

Ah. Actually I think I can do this reducing ObjectType having the smae fields to ArrayType after inferring types for each. I will try.

Fixed in https://github.com/databricks/spark-xml/pull/43.

I used StAX parser instead of SAX because I can easily resample JSON datasource in Spark which uses Jackson parser (pull model). Since the issue was not to build a full DOM tree but to traverse the contents once, I anyway closed this issue.


dev-util/phpstorm: add USE=server for keeping plugins/remote-dev-server/selfcontained out of remove_me array?

I run a dev box that uses remote-dev-server feature, it works very well.

PS I'm testing 2024 b1 for New Terminal feature https://blog.jetbrains.com/idea/2024/02/the-new-terminal-beta-is-now-in-jetbrains-ides/ and it seems they've cleaned up their packaging: remove_me array can now be completely empty, our file list isn't there anymore. (Other than remote-dev-server)


B1.5

Build against Scala 2.11 finished with success

Build against Scala 2.11 finished with failure

Build against Scala 2.10 finished with success

Build against Scala 2.10 finished with failure

Build against Scala 2.11 finished with success


Post-LayerNorm support

Hi, thanks for the great work. I applied smooth quant to post-layernorm models, but with significant performance downgrade since I have to introduce an elementwise-div or elementwise-mul operation in the skip path. Illustrated below:

Do you have any other suggestions to boost the performance? Thank you!
Minghao

I met a similar problem like this, how did you solve it?


feat: support override platform in diff command

🤖 Generated by Copilot at ba571ed
Add platform support to buildah commands and functions. This allows users to compare, build and copy images across different OS, architecture and variant combinations.

/cherry-pick release-v4.2


Project website

https://reposilite.com

Project website should be located in reposilite-site module

Content:

Index
Download & Installation
Docs

@dzikoysk currently https://reposilite.com it redrecting here
is it ok ?

Yeah, reposilite does not have a dedicated website at this moment and it is why this issue is still open. I'm a little busy in recent weeks, but it is a next goal for this project.


Update es_ES and minified

Capitalized translations and added minified files for pickadate.js and default themes.

Ok, sorry for that and thanks for accept it :-)


F&F screen getting stuck on refresh

Friends and Family screen getting stuck on auto refresh.

F&F screen is getting stuck on auto refresh which takes place when user goes to F&F screen.
When refreshing the screen should show a disabled greyed out state.

-Verified this issue on staging app v1.4.4.(223)


NuGet package versioning is hidden from sample users

Never, ever, not in a million years, would I have thought to look for an inherited package manager versioning specifier document somewhere above the otherwise complete sample solution folder I care about.
Please don't do "clever" things like this in sample repos.
Users, like me, are going to attempt to build their first Aspire project by copying one of the sample solutions out of this repo and pasting it into their own repo to start messing with it.
The copied sample won't work.
None of the samples will work.
Hours will be wasted, and the devs will either give up or come close to it.

cc @DamianEdwards

Yep agreed. We discussed this when first creating this repo but the decision was made to use central package management (CPM). Now that we're getting Dependabot configured I'll remove CPM from this repo for the reasons you cite.


Using pls.json to define dependencies and extra flags.

Hi @amdrozdov,
We can now use pls.json properly!
And pls see the PR into https://github.com/current-deps/websockets where it is used -- with this new version of pls it should work like a charm.
Thx,
Dima

LGTM, need to publish it in pypi and test with web-sockets build

TY! Will not forget to publish the new pls ... right after completing the changes I'm working on now!


[DROOLS-1384] Objects in a List is not correctly unmarshalled by JSON…

incorporated in https://github.com/droolsjbpm/droolsjbpm-integration/pull/765
@tkobayas if you find some time please give it a try, I do believe it should now work with both versions - where all custom types are wrapped or only the top level. Though priority for this to work is work where all types are wrapped.


TST: Fixed RE conftest parametrization for call_returns_plan_result

Description

conftest.py now correctly produces RE fixtures with call_returns_plan_result = True and False. Before, it was always essentially true. Also fixes one test that failed with correct parameterization

Ah, did not realize it's that test 😆. Thanks, @cjtitus!

Added a public property call_returns_result and changed all the existing tests that were calling the "private" underlying RE._call_returns_result flag to call RE.call_returns_result. This was maybe the first time that I have ever used sed and had it save me time.

Thank you @cjtitus !


Axis label position: Allow customizing vertical position of axis label for Y axis

The distance between the axis label and the chart is customizable in one direction. It'd be great to be able to expose a setting for the other direction (or for styling it in general) to allow more flexibility.
.attr("dy", labelAnchor === "center"
               ? axis === "right"
                   ? "-0.32em"
                   : "0.75em"
               : labelAnchor === "bottom"
                   ? "1.4em"
                   : "-1em")

The last condition ("-1em") seems too tight for my chart:

Can you share your chart?

Sure:
Plot.plot({
    width,
    y: {
      grid: true,
      zero: true,
      label: 'Cumulative spending',
      tickFormat: (d: number) => `${formatCurrencySimple(d)}`,
      nice: true,
    },
    x: { tickRotate: -45, type: 'utc' },
    marks: [
      Plot.lineY(
        budget,
        Plot.map(
          { y: 'cumsum' },
          {
            x: xProp,
            y: yProp,
            sort: xProp,
            curve: 'step',
            stroke: 'gray',
          }
        )
      ),
    ],
    marginTop: 40,
    marginBottom: 60,
    marginLeft: 80,
  });

I'd also like this; here's a chart I generated where the X axis label is unpleasantely close to the right margin:

(Probably axis titles should respect the graph margin? But I could also fix it manually if I could tweak its horizontal offset)

Related #375.


fix, log error

'success' is global variable.
So if one package is fail then others will not display although success.

display grouping success/fail

Hi @prugel. I don't understand the problem, could you provide a specific example? Also, any changes need to pass the unit tests. Changing the output format would surely break a lot of them so I'm not sure I want to change that unless there is a very important reason.
In non-verbose mode all you get are error & log arrays, you can log it in whichever way you want.

// bower.json
"dependencies": {
"iCheck": "~1.0.2",
"ngDialog": "~0.4.0",
"ngpager": "~1.1.0",
"slimScroll": "~1.3.6",
"sweetalert": "~1.1.0",
"angular": "~1.4.3"
}
if  ngpager and angular is fail. then it will be display
expected
iCheck: installed: 1.0.2, expected: ~1.0.2
ngDialog: installed: 0.4.0, expected: ~0.4.0
ngpager: installed: 0.9.0, expected: ~1.1.0     // fail
slimScroll: installed: 1.3.6, expected: ~1.3.6
sweetalert: installed: 1.1.0, expected: ~1.1.0
angular: installed: 1.4.3, expected: ~1.4.3      // fail

but
iCheck: installed: 1.0.2, expected: ~1.0.2
ngDialog: installed: 0.4.0, expected: ~0.4.0
ngpager: installed: 0.9.0, expected: ~1.1.0     // fail
angular: installed: 1.4.3, expected: ~1.4.3      // fail

slimScroll, sweetalert message do not display

Thanks, I understand now. I'd prefer to separate any styling changes and actual bug fixes. Could you just fix the bug (I assume one if (success) check was wrong when logging) and add a test to test/spec.js and remove other changes from the PR?
Note that there already is an output object, no need to duplicate it in logs.

Sorry, I don't know how to remove other changes.

You can just modify the code back to the way it was, add a new commit with the changes and push to the same branch. GitHub will pick it up automatically, no need to create a new PR.


added animated glowing cursor

I have added animated glowing cursor to project.

closes #460

Please provide a preview of the site.

https://github.com/user-attachments/assets/89c3de23-fd09-41f2-850d-a75fc21c2fe5


fix: user profile image focus v11

Contributes to #2839
improves the focus state of the user profile image. visual change approved by shaun and marwa

@lee-chase thanks for the suggestion. fixt


COM-67: Adapt Redirects-DataGrid-Column Sizes

It seems to me that this column widths are too big. What would happen on a screen that only has ~1000px width?

Why do you need minWidth at all? Shouldn't flex be enough? The min widths still add up to 800 pixels, which is definitely larger than a mobile device. But perhaps we should focus on mobile in a follow-up PR.

We probably need a condensed view for mobile. I would do that in a follow-up PR.


issue adding dataset

HI ml-jku
I am trying to run hopular on my own data sets.  It looks like there are two formats for doing this

one, used for blastchar, just involves adding a csv file and describing it in auxiliary/data.py. I have done this for the "adult census" data and it all seems to work (ie. no errors)

the other seems to involve the use of about 4 files i.e for  statlog_heart it is

folds_py.dat
labels_py.dat
statlog_heart_py.dat
validation_folds_py.dat

I can't make any sense of this. The heart data should have 6 numeric and 7 discrete features, according to both data.py and the UCI website. however. it seems to have 13 numeric features

> head -2  resources/statlog_heart/statlog_heart_py.dat
1.70892,0.688222,0.869313,-0.0752701,1.39961,-0.416256,0.979844,-1.75595,-0.699923,1.17882,0.675165,2.4681,-0.874083
1.37958,-1.44764,-0.183219,-0.91506,6.08171,-0.416256,0.979844,0.445582,-0.699923,0.480261,0.675165,-0.710216,1.18707

also I cant figure out what  folds_py.dat   and validation_folds_py.dat are doing.
> head -2  resources/statlog_heart/folds_py.dat
0,1,0,0
1,0,0,0

> head -2  resources/statlog_heart/validation_folds_py.dat
1,0,1,0
0,0,0,0

I am not so interested in the heart data as in understanding how to add my own data,  use a test set or cross-validation and then
test on a independent  data set.
Bye

just part of the same question. For the same data set, what does the output mean? And how can I the predicted values
>hopular optim --dataset "StatlogHeartDataset"  --num_workers 20

  accuracy_target/test       0.746268630027771
        loss/test           0.5171667337417603
    loss_target/test        0.5171667337417603


Parameter/attribute type encoding in protobuf backend

Consider:
(* blackbox *)
module submod(output q);
parameter [7:0] a = 0;
parameter [7:0] b = 0;
parameter [71:0] c = 0;
parameter [72*8-1:0] d = 0;
endmodule

module top(output q);
	submod #(
		.a(8'b11110000),
		.b(8'b1111xxxx),
		.c(72'h1),
		.d("000000000000000000000000000000000000000000000000000000000000000000000001")
	) submod_i(
		.q(q)
	);
endmodule

running yosys -p "proc; hierarchy; write_protobuf -text" ptypes.v gives (abridged):
        parameter {
          key: "a"
          value {
            int: 240
          }
        }
        parameter {
          key: "b"
          value {
            int: 240
          }
        }
        parameter {
          key: "c"
          value {
            str: "000000000000000000000000000000000000000000000000000000000000000000000001"
          }
        }
        parameter {
          key: "d"
          value {
            str: "000000000000000000000000000000000000000000000000000000000000000000000001"
          }
        }

Clearly a and b; and c and d; should not be encoded identically.
As I am interested in protobuf or equivalent being a JSON replacement for nextpnr; at least for more advanced flows with hierarchy; it would be good to sort this out properly and avoid the pain we had fixing this in the JSON flow.
A proposal would be to add an explicit type message that stores width, signedness and stringness; and also ensure that any value with 'x' bits is not converted to an integer.
Any other thoughts before I implement something like this?

This is only somewhat related, but have you looked at flatbuffers?

It would certainly be an option. But I'm not sure if we should be maintaining both flatbuffer and protobuf front/backends for Yosys, so it would be good to decide one way or another.

AFAIK it is technically superior to protobuf in essentially every way, so it is a matter of there being enough desire to switch.

I would certainly be keen to see this decided before I work on the nextpnr side. I have no objections to switching - and making the change on the Yosys side - but I've never used either option "in anger". Any comments @q3k, given you implemented the protobuf backend in the first place?

I would recommend Cap'n'Proto over flatbuffers. After doing an assessment of ProtoBuf, FlatBuffers and Cap'n'Proto we decided to use Cap'n'Proto in VtR.
FYI - Support both Protobuf and Cap'n'Proto could make sense, they have reasonably different use cases. Protobuf is more efficient in the data transmission side (for things like RPCs), while Cap'n'Proto (and flatbuffers) can be memory mapped directly without any decoding overhead.

AFAIK it is technically superior to protobuf in essentially every way, so it is a matter of there being enough desire to switch.

Not really, but that's outside the scope for this discussion.
However, I do agree for some usecases (like having zero copy) Cap'n'Proto/Flatbuffers are a better choice than Protobufs. I don't have a strong personal preference regarding changing to or adding a different proto-style format. I also don't think there are any large consumers of the current Protobuf format, so it's probably okay to break backwards compatibility in a sane way (eg. by changing tag numbers so existing consumers don't mis-decode data, and instead find the design empty).
The reason the current protobuf backend type system is dodgy is that I couldn't come up with a universal way to pack arbitrary width integers, and kept the same mindset as the JSON backend did - deciding on the emitted type based on the bit width of the incoming number. An alternative would be to always ship these as a message Value { int32 nbits; bytes packed; } with a well defined endianness and padding scheme, but that would make writing consumer code somewhat annoying. And still wouldn't solve the problem of extra states like 'X', 'Z' or others.
I'm not sure any alternative has a better type for this. This isn't a typical problem that users of these exchange formats face. But I'd like to hear your ideas.

I don't actually think zero copy is that much of an issue here; as any consumer is likely to be building its own structures (e.g. hash tables of objects, etc) that will be much more expensive than the parse. But it's a nice to have.
The number one requirement is good cross platform support, if this is to become the recommended interchange format for nextpnr in the long term it needs to cause no issues for Windows or macOS.
As for parameters; I think one-byte-per-bit is reasonable as throwing away 'x's is not correct - particularly for memory initialisation these can have significance as parameters. Likewise it is important to disambiguate strings that look like bit vectors, and large bit vectors.

Comparison of language support between cap'n'proto and protobuf:
https://github.com/protocolbuffers/protobuf/blob/master/docs/third_party.md
https://capnproto.org/otherlang.html
Flatbuffers has probably the smallest language support base of the three.


run on machine with single GPU

can I use the code to train in single GPU machine rtx5000?if yes, how to do it ?

Hello, have you resolved this issue?

Hi,do you have ckpt and train logs , can you share  with me ?  I got an error ,when I download them.


License Finder Frontend does not use cookies

Session cookies are disabled in License Finder, so there is no need for this rule to not strip cookies.

Ah, although when I browse /apply-for-a-licence there are no cookies set, and looking through the code in Licensify /frontend confirms this.
On this basis can the PR be merged?, or should I update the comment to make it clearer that it refers to Licensify.

Licensify has this though which looks to me like a session cookie in the frontend: https://github.com/alphagov/licensify/blob/7826858e8bb655c901f15e55579b878b5d305fee/frontend/conf/application.conf#L62

Yep, and I see the session cookie are used for the payment flow https://github.com/alphagov/licensify/blob/master/frontend/app/uk/gov/gds/licensing/frontend/controllers/GenericPaymentController.scala#L37


Character display error

You need to select a font that supports more of unicode -- click on the gogi preferences and then on the font selector to see which ones render properly.

Not working for □ ■  〄 ♂ ♀ ♫ ♪ ♩ ❤ ♥ ღ ❥ ✧ ★ ☆ ✰ ✪ ✡
by Noto Sans Traditional Chinese

It will potentially work better now with the latest 1.3.17 release -- update here if you get a chance.

1.3.17 batter but not good enough in terms of Unicode support.

see #486 for a potential solution. If you have access to a Mac, you might give a try there -- should be better.  In any case, if you happen to know about standard unicode fonts on linux or windows, please update that issue.

Closing in favor of the more general #568.


Accessing remotely

Describe your problem
If I want to run on my server and access remotely, which changes and where should I make? Thank you

Put it behind a reverse-proxy, like caddy and forward port 80 and 443 from your router to the computer where caddy is running.

What you need is only a accessible IP.


Add Polars Dataframe output cache type

I added "polars_dataframe" as an option for the _Cacher arguments. I also improved the type hint for the cache arguments.

If you assign an issue a milestone make sure to merge into that branch instead of main.


Upload integrity and retries for dropbox

This is a placeholder epic for industrial strength upload issues once the basic functionality is available.

Removed from upload epic. Closing per January 5th refinement.

Removed from upload epic. Closing per January 5th refinement.


diff reports in generated

for issue #413
requires csvdiff from https://aswinkarthik.github.io/csvdiff/
makefile rule alldiffs puts reports in directory generated/

@turbomam I just resolved a bunch of conflicts when I merged PR #412. Most of them were updating dependency versions, but there were a few other small changes. I'm not sure, but it looks like the conflicts in this branch might revert some of the ones I just change. Can you please confirm that if I resolve these current conflicts to what is in this branch that those are the changes you want?

OK, I will merge main back into whatever I'm working on and get back to you.
Regarding poetry.lock, we can just run poetry update before each commit.
I'll have to check @sujaypatil96's most recent RP  regarding pyproject.toml
A lot of my work is taking place in the Makefile, we should be sure not to nuke any of that unless it's intentional

removing the following from pyproject.toml. I thought about using them for some text mining but that's experimental and probably shouldn't go in main yet.

textmining = "^1.0"
scikit-learn = "^1.0.2"

We should be sure that none of the old gen-markdown stuff gets added back to @sujaypatil96's latest gen-docs commits
Also, we should still run the gen-docs creation and publish it to GH pages

no more merge conflicts


bump scaffold for ctlog 0.2.24

bump scaffold for ctlog 0.2.24
Description of the change
bump scaffold for ctlog 0.2.24
Existing or Associated Issue(s)
#211 #210
Additional Information
None
Checklist

[x] Chart version bumped in Chart.yaml according to semver. Where applicable, update and bump the versions in any associated umbrella chart
[ ] Variables are documented in the values.yaml and added to the README.md. THe helm-docs utility can be used to generate the necessary content. Use helm-docs --dry-run to preview the content
[ ] JSON Schema generated
[ ] List tests pass for Chart using the Chart Testing tool and the ct lint command

@cpanato new version of ctlog will be available once #210 is integrated


get_cli_args is not defined

For https://github.com/codecov/feedback/issues/369, I have considered a slightly different approach: on a merge event to main, fetch the coverage report from the latest commit of the PR that was merged and re-upload it to Codecov for the newly created commit on main. For this, I am trying to use the codecov-cli since that is used anyway by the codecov-action (on GitHub Actions). Unfortunately, the command get-report-results fails with the following error:
> codecovcli get-report-results
info - 2024-10-22 11:15:34,874 -- ci service found: local
Traceback (most recent call last):
  File "/home/fridolin/.virtualenvs/codecovcli/bin/codecovcli", line 8, in <module>
    sys.exit(run())
             ^^^^^
  File "/home/fridolin/.virtualenvs/codecovcli/lib/python3.12/site-packages/codecov_cli/main.py", line 83, in run
    cli(obj={})
  File "/home/fridolin/.virtualenvs/codecovcli/lib/python3.12/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/fridolin/.virtualenvs/codecovcli/lib/python3.12/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/home/fridolin/.virtualenvs/codecovcli/lib/python3.12/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/fridolin/.virtualenvs/codecovcli/lib/python3.12/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/fridolin/.virtualenvs/codecovcli/lib/python3.12/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/fridolin/.virtualenvs/codecovcli/lib/python3.12/site-packages/click/decorators.py", line 33, in new_func
    return f(get_current_context(), *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/fridolin/.virtualenvs/codecovcli/lib/python3.12/site-packages/codecov_cli/commands/get_report_results.py", line 31, in get_report_results
    args = get_cli_args(ctx)
           ^^^^^^^^^^^^
NameError: name 'get_cli_args' is not defined

And indeed, I can't find an import for get_cli_args in the file.
To reproduce: create a new venv, then
pip install codecov-cli
codecovcli get-report-results

@glatterf42, I pushed up a new version of the CLI 9.1.0, are you able to try and see if you are getting this error still?

Sure, thanks for picking this up :)
In yet another new venv, attempting to get the report of the latest commit from this repo, I now see:
> codecovcli get-report-results -C 5c0b44f0118c3fcd361d1345d6a7cf1bd61658a0
info - 2024-12-05 12:46:17,032 -- ci service found: local
info - 2024-12-05 12:46:17,204 -- Process Getting report results complete
error - 2024-12-05 12:46:17,204 -- Getting report results failed: {"error":"Not found"}

Which makes me think that a --verbose option or more detailed error message might be nice, but that's besides the point of this issue. The code seems fine, likely my local settings are not correct to access the codecov repo where the report is stored. As in: the code definitely doesn't fail on finding get_cli_args, so this issue can be closed :)

@glatterf42 woof ok, I'll close this for now, but if you're struggling to get that to work, please open a new issue and feel free to tag me.


Update pstn-usage-report.md

Adding one sentence to specify that data can be exported up to 1 year from the current date

@nenonix @JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@tonysmit PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


This package needs a release to be usable by SPM

No version tag found in<EMAIL_ADDRESS>package. Add a version tag with "git tag" command. Example: "git tag 0.1.0"

Done. Thank you.


Compilation errors

Hi all,
I am trying to build your reconstruction software on a fresh Ubuntu 22 LTS system on Linode.
First, I had to additionally install the package 'python-is-python3'.
sudo apt install python-is-python3
Secondly, I run into the following error:
[ 34%] Building CXX object Modules/Image/src/CMakeFiles/LibImage.dir/VelocityToDisplacementFieldSS.cc.o
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make[2]: *** [Modules/Image/src/CMakeFiles/LibImage.dir/build.make:538: Modules/Image/src/CMakeFiles/LibImage.dir/InterpolateImageFunction.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make[2]: *** [Modules/Image/src/CMakeFiles/LibImage.dir/build.make:608: Modules/Image/src/CMakeFiles/LibImage.dir/ScalingAndSquaring.cc.o] Error 1
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make[2]: *** [Modules/Image/src/CMakeFiles/LibImage.dir/build.make:118: Modules/Image/src/CMakeFiles/LibImage.dir/DifferenceOfCompositionLieBracketImageFilter3D.cc.o] Error 1
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make[2]: *** [Modules/Image/src/CMakeFiles/LibImage.dir/build.make:146: Modules/Image/src/CMakeFiles/LibImage.dir/DisplacementToVelocityFieldBCH.cc.o] Error 1
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make[2]: *** [Modules/Image/src/CMakeFiles/LibImage.dir/build.make:636: Modules/Image/src/CMakeFiles/LibImage.dir/ShapeBasedInterpolateImageFunction.cc.o] Error 1
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make[2]: *** [Modules/Image/src/CMakeFiles/LibImage.dir/build.make:454: Modules/Image/src/CMakeFiles/LibImage.dir/ImageGradientFunction.cc.o] Error 1
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make[2]: *** [Modules/Image/src/CMakeFiles/LibImage.dir/build.make:216: Modules/Image/src/CMakeFiles/LibImage.dir/Erosion.cc.o] Error 1
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make[2]: *** [Modules/Image/src/CMakeFiles/LibImage.dir/build.make:398: Modules/Image/src/CMakeFiles/LibImage.dir/Histogram2D.cc.o] Error 1

What can I do to fix this errors?
Kind regards,
Kai

hi Kai,
It looks like it is cause by python 2 / python 3 issue and python-is-python3 ...
MIRTK version that we use requires python 2
What was the error before you installed python-is-python3?
Thank you,
Alena

The error was "command python not found". I will try it again with the package "python-is-python2".

hi Kai,
Could you please uninstall python-is-python2 and install simple python2 instead (sudo apt-get install python)?
It looks like the error is caused by the fact that you don't have python2 installed but this package is trying to interpret python2 command using python3. ..
Let me know how it goes.
Best wishes,
Alena

There was not enough RAM for my virtual environment. The compilation was killed by the virtual hosting provider.


criterion-<IP_ADDRESS> on Hackage fails to build with optparse-applicative-<IP_ADDRESS>

The HEAD version of criterion does not suffer from this issue.
Building criterion-<IP_ADDRESS>...
Preprocessing library criterion-<IP_ADDRESS>...
[ 1 of 13] Compiling Paths_criterion  ( dist/build/autogen/Paths_criterion.hs, dist/build/Paths_criterion.o )
[ 2 of 13] Compiling Criterion.Types  ( Criterion/Types.hs, dist/build/Criterion/Types.o )
[ 3 of 13] Compiling Criterion.Monad.Internal ( Criterion/Monad/Internal.hs, dist/build/Criterion/Monad/Internal.o )
[ 4 of 13] Compiling Criterion.Measurement ( Criterion/Measurement.hs, dist/build/Criterion/Measurement.o )
[ 5 of 13] Compiling Criterion.Monad  ( Criterion/Monad.hs, dist/build/Criterion/Monad.o )
[ 6 of 13] Compiling Criterion.Report ( Criterion/Report.hs, dist/build/Criterion/Report.o )

Criterion/Report.hs:35:1: warning: [-Wdeprecations]
    Module ‘Data.Aeson.Encode’ is deprecated:
      Use Data.Aeson or Data.Aeson.Text instead

Criterion/Report.hs:94:34: warning: [-Wdeprecations]
    In the use of ‘encodeToTextBuilder’
    (imported from Data.Aeson.Encode):
    Deprecated: "Use Data.Aeson or Data.Aeson.Text instead"
[ 7 of 13] Compiling Criterion.IO.Printf ( Criterion/IO/Printf.hs, dist/build/Criterion/IO/Printf.o )
[ 8 of 13] Compiling Criterion.Analysis ( Criterion/Analysis.hs, dist/build/Criterion/Analysis.o )
[ 9 of 13] Compiling Criterion.Main.Options ( Criterion/Main/Options.hs, dist/build/Criterion/Main/Options.o )

Criterion/Main/Options.hs:88:34: error:
    • Variable not in scope: (<>) :: Mod f50 a43 -> Mod f51 a44 -> t23
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:88:47: error:
    • Variable not in scope:
        (<>) :: t23 -> Mod f52 a45 -> Mod FlagFields Bool
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:89:40: error:
    • Variable not in scope:
        (<>) :: Mod f53 a46 -> Mod f54 a47 -> Mod FlagFields Bool
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:93:33: error:
    • Variable not in scope: (<>) :: Mod f46 a39 -> Mod f47 a40 -> t22
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:93:46: error:
    • Variable not in scope: (<>) :: t22 -> Mod f48 a41 -> t21
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:93:65: error:
    • Variable not in scope:
        (<>) :: t21 -> Mod f49 a42 -> Mod OptionFields Int64
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:97:25: error:
    • Variable not in scope: (<>) :: Mod f41 a35 -> Mod f42 a36 -> t20
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:97:38: error:
    • Variable not in scope: (<>) :: t20 -> Mod f43 a37 -> t19
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:97:57: error:
    • Variable not in scope: (<>) :: t19 -> Mod f44 MatchType -> t18
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:97:73: error:
    • Variable not in scope:
        (<>) :: t18 -> Mod f45 a38 -> Mod OptionFields MatchType
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:104:18: error:
    • Variable not in scope: (<>) :: Mod f2 a1 -> Mod f3 a2 -> t3
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:104:31: error:
    • Variable not in scope: (<>) :: t3 -> Mod f4 a3 -> t2
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:104:47: error:
    • Variable not in scope: (<>) :: t2 -> Mod f5 Double -> t1
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:104:69: error:
    • Variable not in scope:
        (<>) :: t1 -> Mod f6 a4 -> Mod OptionFields Double
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:106:37: error:
    • Variable not in scope: (<>) :: Mod f7 a5 -> Mod f8 a6 -> t4
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:106:50: error:
    • Variable not in scope:
        (<>) :: t4 -> Mod f9 a7 -> Mod FlagFields Bool
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:109:26: error:
    • Variable not in scope: (<>) :: Mod f10 a8 -> Mod f11 a9 -> t7
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:109:39: error:
    • Variable not in scope: (<>) :: t7 -> Mod f12 a10 -> t6
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:109:57: error:
    • Variable not in scope: (<>) :: t6 -> Mod f13 Double -> t5
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:109:76: error:
    • Variable not in scope:
        (<>) :: t5 -> Mod f14 a11 -> Mod OptionFields Double
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:112:25: error:
    • Variable not in scope: (<>) :: Mod f15 a12 -> Mod f16 a13 -> t9
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:112:44: error:
    • Variable not in scope: (<>) :: t9 -> Mod f17 Int -> t8
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:112:63: error:
    • Variable not in scope:
        (<>) :: t8 -> Mod f18 a14 -> Mod OptionFields Int
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:115:29: error:
    • Variable not in scope: (<>) :: Mod f19 a15 -> Mod f20 a16 -> t10
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:115:54: error:
    • Variable not in scope:
        (<>) :: t10 -> Mod f21 a17 -> Mod OptionFields ([String], String)
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:117:44: error:
    • Variable not in scope:
        (<>) :: Mod f22 a18 -> Mod f23 a19 -> Mod OptionFields String
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:119:46: error:
    • Variable not in scope: (<>) :: Mod f24 a20 -> Mod f25 a21 -> t11
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:119:59: error:
    • Variable not in scope:
        (<>) :: t11 -> Mod f26 a22 -> Mod OptionFields String
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:121:40: error:
    • Variable not in scope:
        (<>) :: Mod f27 a23 -> Mod f28 a24 -> Mod OptionFields String
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:123:44: error:
    • Variable not in scope:
        (<>) :: Mod f29 a25 -> Mod f30 a26 -> Mod OptionFields String
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:126:37: error:
    • Variable not in scope: (<>) :: Mod f31 a27 -> Mod f32 a28 -> t14
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:126:50: error:
    • Variable not in scope: (<>) :: t14 -> Mod f33 a29 -> t13
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:126:69: error:
    • Variable not in scope: (<>) :: t13 -> Mod f34 Int -> t12
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:127:47: error:
    • Variable not in scope:
        (<>) :: t12 -> Mod f35 a30 -> Mod OptionFields Int
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:129:34: error:
    • Variable not in scope: (<>) :: Mod f36 a31 -> Mod f37 a32 -> t17
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:129:47: error:
    • Variable not in scope: (<>) :: t17 -> Mod f38 a33 -> t16
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:129:65: error:
    • Variable not in scope: (<>) :: t16 -> Mod f39 FilePath -> t15
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:130:33: error:
    • Variable not in scope:
        (<>) :: t15 -> Mod f40 a34 -> Mod OptionFields String
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:135:26: error:
    • Variable not in scope:
        (<>) :: Mod OptionFields String -> Mod f0 a0 -> t0
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:135:44: error:
    • Variable not in scope:
        (<>) :: t0 -> Mod f1 String -> Mod OptionFields String
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:175:39: error:
    • Variable not in scope: (<>) :: [Char] -> String -> String
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:175:55: error:
    • Variable not in scope:
        (<>) :: ParserInfo Mode -> InfoMod a48 -> t24
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:176:14: error:
    • Variable not in scope:
        (<>) :: t24 -> InfoMod a49 -> ParserInfo Mode
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

Criterion/Main/Options.hs:182:39: error:
    • Variable not in scope: (<>) :: [Char] -> String -> String
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Options.Applicative),
        ‘<*>’ (imported from Options.Applicative),
        ‘*>’ (imported from Options.Applicative)
      Perhaps you want to add ‘<>’ to one of these import lists:
        ‘Text.PrettyPrint.ANSI.Leijen’ (Criterion/Main/Options.hs:40:1-47)
        ‘Data.Monoid’ (Criterion/Main/Options.hs:32:1-27)

As @phadej notes in https://github.com/bos/criterion/pull/116#issuecomment-240148935, we really should add an explicit < 0.14 upper bound for optparse-applicative, since not adhering to the PVP for that dependency has bitten criterion (possibly multiple times).

Ok, at least that upper bound can be patched in post facto on Hackage.
On Tue, Aug 16, 2016 at 12:02 PM Ryan Scott<EMAIL_ADDRESS>wrote:

As @phadej https://github.com/phadej notes in #116 (comment)
https://github.com/bos/criterion/pull/116#issuecomment-240148935, we
really should add an explicit < 0.14 upper bound for optparse-applicative,
since not adhering to the PVP for that dependency has bitten criterion
(possibly multiple times).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bos/criterion/issues/113#issuecomment-240149694, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAQwlp_c7OrGDX4DRW23ODyQE4OqGTS0ks5qgd8rgaJpZM4JlZmF
.

--
Sent from my mobile device. Please excuse brevity and odd autocompletes.

@rrnewton: We should retroactively upper-bound these versions:

<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>

Bump. Can you publish a new version of criterion to hackage that builds against optparse-applicative-<IP_ADDRESS>?

@DanBurton - I'm paged out here, but if someone can point to exactly which branch/commit to release, I'll push it out.

@rrnewton: In my criterion fork, I've created a branch with the bugfixes that I think should make it into the next minor release of criterion. They include the following cherry-picked commits:

https://github.com/bos/criterion/commit/bcd57f04a7217a496dedefb07025dace9e1506b8
https://github.com/bos/criterion/commit/fb794484bcf7c88b1b3d5f7fb33c356742f4d31f
https://github.com/bos/criterion/commit/0b71b0efd22849bb949e8a671a02d5777a9f34cc

As well as an additional commit that fixes the build with optparse-applicative-0.13. (You happened to fix it indirectly in https://github.com/bos/criterion/commit/32afe61935e55662425d535df2edbfd30bb79afd, but cherry-picking that was non-trivial, so I backed off.)
An unresolved question: what version number do we give to this minor release? The current version in HEAD is <IP_ADDRESS>, but the one on Hackage is <IP_ADDRESS>.

Bump again. We've been holding back optparse-applicative on stackage for 2.5 months. Would love to lift that constriant. https://github.com/fpco/stackage/issues/1784

@DanBurton: after talking with @rrnewton, it doesn't sound like he'll get a chance to work on this until after the PLDI deadline (November 15).

I just pushed out a <IP_ADDRESS> release that addresses this.


New logo svg files in Logo folder and Updated the Readme file

Thanks so much Sir! I appreciate your acceptance to my proposal. Best regards to all!

Thank you so much @Tobaloidee - these are fantastic