Global Litellm Config

Issue
My company requires that all LLM traffic goes through a proxy to remove any potential customer data leakage.  In order to comply I need to add some additional headers to be sent with every request.  Currently I'm having to create a model settings file for each model I want to use, copy out all the current default values for that model, and then add an extra_params section to add the headers.  This is cumbersome, and has to be updated any time there's a new model to use.   It also risks not keeping model settings up to date with latest greatest in aider.
What I would love is a way to provide a global default model (name == "*") with a partial list of settings that can serve as a default for all other models.  I'd want it to be additive so I can just add the extra_params section and not need anything else.
Example .aider.model.settings.yml:
- name: *
  extra_params:
    extra_headers:
      x-userid: mbradshaw
      x-appid: aider.chat
- name: other-model
  use_repo_map: true
  send_undo_reply: false,
  examples_as_sys_msg: true

Alternately just some way to set global litellm settings.
Version and model info
Aider v0.59.1

Thank you for filing this issue.
In doubt create/use a proxy for your proxy that adds the necessary fields. E.g LiteLLM proxy.

Yeah, that's an option we're kicking around, but we're trying to roll out aider internally to our devs (large company) and we want to make setup as simple as possible.  Setting up and running a litellm proxy just adds friction.

Since this is not easily testable from outside and only benefits a subset of users, I think this falls in the category "patch welcome" if you want/need this functionality inside aider. IMHO.

Well, here's a stab at it.

@fry69 @paul-gauthier Just a reminder that I have an updated PR that was adjusted after Paul's comments.  Can you take a look?

I'm labeling this issue as stale because it has been open for 2 weeks with no activity. If there are no additional comments, it will be closed in 7 days.

Hey Paul.  As you can see above in the last comment I've been trying to navigate a PR through to merging.  I made some adjustments as you requested in a previous PR, and I just need you to review it.

@paul-gauthier Here's the updated PR with the simplified approach: https://github.com/Aider-AI/aider/pull/2242

And I see it needs to get rebased.  I'll try to take care of that tonight.

@paul-gauthier That PR is rebased and ready to go.

Thanks for the effort here. I was struggling with the use of a semicolon-separated list of key-values, as it has limitations on what you can express. I just merged a different approach:
https://aider.chat/docs/config/adv-model-settings.html#global-extra-params

Thanks Paul.  I think that'll work.  :)

I'm going to close this issue for now, but feel free to add a comment here and I will re-open. Or feel free to file a new issue any time.


Bump grunt-contrib-qunit to ^0.7.0

Coverage remained the same at 100.0% when pulling 9be797cc20615038bb28901d795ecbe9d77ff377 on bump-qunit into 3eb0a3c4ddb524b50cbfafdeaf93211e9db04931 on master.


refactor: Remove Cypress cy.visitWithLogin() account mocking, improve DBaaS mocks

Description 📝
This is related to PR #9715 from yesterday -- we got the tests passing by mocking the databases feature flag to true, when the root cause of the failures was actually that the API /account request was getting mocked, and the mocked response did not include "Managed Databases" in the list of capabilities.
This PR makes a handful of changes to address this and restore the DBaaS tests to a state that's more useful for their team.
Major Changes 🔄

Adds Cloud Firewall, Vlans, Machine Images, and Managed Databases to the Account factory's capabilities property
Removes implicit account mocking behavior from cy.visitWithLogin() -- this was added a while ago to get around performance issues with the API /account endpoint. I think the performance issues with that endpoint have been improved if not resolved, and opted to remove this behavior altogether due to the confusion caused
Explicitly mock the account request in the DBaaS tests to ensure that the tests are running with the Managed Databases capability available, regardless of the state of the test accounts
Remove the mocks related to the databases feature flag so that the DBaaS team can run the tests against environments where the flag is and is not enabled

How to test 🧪
We can rely on automated tests to ensure that everything continues running and passing as expected. I want to pay particular attention to the performance of these test runs to ensure that removing the implicit account mocking didn't impact performance in a significant way.

Hi @jdamore-linode Can you please add Surbhi to these PRs going forward if they affect databases?

Hi @jdamore-linode Can you please add Surbhi to these PRs going forward if they affect databases?

Hey @rvenugopal11. I'm not able to add Surbhi as a reviewer, I believe because she's not a member of the organization in GitHub. I sent her a link to the PR in Slack when I opened the PR and requested her review there instead.

@jdamore-linode Should I assume the /linode-storage.spec.ts failure is unrelated?

@jdamore-linode Should I assume the /linode-storage.spec.ts failure is unrelated?

Yeah, I believe that's the case. I'm going to try rerunning this until I can get a green check, but I'm trying to get a handle on all of these flaky tests too.

Pushed a quick addition that should get the tests passing again in light of the LD feature/API changes made today


docs: remove demo manifests required by website

Description:
Removes the demo manifests required by the docs
website as these have been moved to the osm-docs
repo.

Affected area:

Functional Area

Other
[X]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? no

Did you notify the maintainers and provide attribution?

Is this a breaking change? no

Codecov Report

Merging #4455 (824a6bf) into main (bfc256d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #4455   +/-   ##
=======================================
  Coverage   69.21%   69.21%
=======================================
  Files         212      212
  Lines       14580    14580
=======================================
  Hits        10091    10091
  Misses       4437     4437
  Partials       52       52

Flag
Coverage Δ

unittests
69.21% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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 bfc256d...824a6bf. Read the comment docs.

In release_pull_request_template.md can the check "Updated the image tags used in the demo manifests" be removed?

In release_pull_request_template.md can the check "Updated the image tags used in the demo manifests" be removed?

The words demo manifests here can be a bit misleading, where it could be referring to the automated demo manifests inlined in the bash scripts. I rephrased this.


element-{web,desktop}: 1.11.15 -> 1.11.16

Description of changes
ChangeLog web: https://github.com/vector-im/element-web/releases/tag/v1.11.16
ChangeLog desktop: https://github.com/vector-im/element-desktop/releases/tag/v1.11.16

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 205752 run on x86_64-linux 1

3 packages built:

element-desktop
element-desktop-wayland
element-web


Remove attachments from disk on end of bust

Implements #52
A copy of list of attachments is generated when running !list. This list is held until the current bust ends, in which the list is enumerated and each attachment is removed from disk. This list is overwritten if !list is called multiple times before !bust.

I'm very bad at github,  I submitted the same review 4x because it kept telling me it had a server error when I tried to submit it


UART unfixed-length data receiving based on IDLE interrupt and DMA

I'm trying to implement unfixed-length data receiving based on IDLE interrupt and DMA, and here is my code. But there are still some problems and I think it's not convenient enough. Is there a better way?
#![no_std]
#![no_main]

use core::fmt::Write;

use cortex_m::singleton;
use panic_halt as _;
use rtic::app;
use stm32f1xx_hal::{
    dma::CircBuffer,
    pac::{self, Interrupt},
    prelude::*,
    serial::{self, Serial},
};

#[app(device = stm32f1xx_hal::pac, peripherals = true)]
const APP: () = {
    struct Resources {
        rx_transfer: Option<CircBuffer<[u8; 8], serial::RxDma1>>,
        usart1_tx: serial::Tx<pac::USART1>,
    }

    #[init]
    fn init(cx: init::Context) -> init::LateResources {
        // Cortex-M peripherals
        let _cp: cortex_m::Peripherals = cx.core;
        // Device specific peripherals
        let dp: pac::Peripherals = cx.device;

        let mut flash = dp.FLASH.constrain();
        let rcc = dp.RCC.constrain();

        let clocks = rcc.cfgr
            .use_hse(8.mhz())
            .sysclk(72.mhz())
            .pclk1(36.mhz())
            .pclk2(72.mhz())
            .freeze(&mut flash.acr);

        let mut afio = dp.AFIO.constrain();
        let dma_channels = dp.DMA1.split();

        let mut gpioa = dp.GPIOA.split();
        let pa9 = gpioa.pa9.into_alternate_push_pull(&mut gpioa.crh);
        let pa10 = gpioa.pa10.into_floating_input(&mut gpioa.crh);

        let mut usart1 = Serial::usart1(
            dp.USART1,
            (pa9, pa10),
            &mut afio.mapr,
            serial::Config::default().baudrate(115200.bps()),
            clocks,
        );
        rtic::pend(Interrupt::USART1);
        usart1.listen(serial::Event::Idle);

        let (mut tx, rx) = usart1.split();
        let rx = rx.with_dma(dma_channels.5);
        let buf = singleton!(: [[u8; 8]; 2] = [[0; 8]; 2]).unwrap();
        let rx_transfer = rx.circ_read(buf);

        write!(tx, "Init.\r\n").unwrap();

        init::LateResources {
            rx_transfer: Some(rx_transfer),
            usart1_tx: tx,
        }
    }

    #[idle]
    fn idle(_: idle::Context) -> ! {
        loop {}
    }

    #[task(binds = USART1, resources = [rx_transfer, usart1_tx])]
    fn usart1_isr(cx: usart1_isr::Context) {
        let rx: CircBuffer<[u8; 8], serial::RxDma1> = cx.resources.rx_transfer.take().unwrap();
        let tx: &mut serial::Tx<pac::USART1> = cx.resources.usart1_tx;

        let (buf, mut rx) = rx.stop();
        let len = (buf[0].len() as u32 * 2) - rx.channel.ch().ndtr.read().bits();
        write!(tx, "len: {} data: {}\r\n", len, core::str::from_utf8(&buf[0][..]).unwrap()).unwrap();

        // Clear SR IDLE bit
        let usart1 = unsafe { &*pac::USART1::ptr() };
        usart1.sr.read();
        usart1.dr.read();

        cx.resources.rx_transfer.replace(rx.circ_read(buf));
    }
};

Can you test https://github.com/stm32-rs/stm32f1xx-hal/tree/serial2 branch, please?
Some methods for serial interrupts are added here.

Good, it works, here's the current code:
#[task(binds = USART1, resources = [rx_transfer, usart1_tx])]
fn usart1_isr(cx: usart1_isr::Context) {
    let rx: CircBuffer<[u8; 8], serial::RxDma1> = cx.resources.rx_transfer.take().unwrap();
    let tx: &mut serial::Tx<pac::USART1> = cx.resources.usart1_tx;

    let (buf, mut rx) = rx.stop();
    let len = (buf[0].len() as u32 * 2) - rx.channel.ch().ndtr.read().bits();
    write!(tx, "len: {} data: {}\r\n", len, core::str::from_utf8(&buf[0][..]).unwrap()).unwrap();

    let (rx, channel) = rx.release();
    rx.clear_idle_interrupt();
    let rx = rx.with_dma(channel);

    cx.resources.rx_transfer.replace(rx.circ_read(buf));
}

And I have another question, because Transfer<MODE, BUFFER, PAYLOAD> not implement method like stop(), I cannot stop the DMA transfer (to restart the transfer) until the transfer is finished, I have to use circ_read() to get CircBuffer<B, Self> which has stop() method. Can we add a stop() method to Transfer<MODE, BUFFER, PAYLOAD>?

Looks weird, you are right. I need time to investigate this.

Looks like if we implement preliminary stop for Transfer<W, ..> you could use peek for your needs.
cc @TheZoq2 @thalesfragoso


Jekyll-style includes completely broken

Describe the bug
As far as I can tell, Jekyll includes ({% include foo %}) aren't tested and don't work actually work. transferReferences work, but the content isn't actually moved over.

[ ] Parser
[ ] HtmlRenderer
[ ] Formatter
[ ] FlexmarkHtmlParser
[ ] DocxRenderer
[ ] PdfConverterExtension
[x] extension(s)

To Reproduce
The provided sample file here reproduces the issue.

Options used to configure the parser, renderer, formatter, etc. Please provide concise code when you can.

Per the example, this configuration should be sufficient:
options.set(Parser.EXTENSIONS, Arrays.asList(JekyllTagExtension.create()));

Expected behavior
When I {%include%} another file, I expect all the content from that file to be inlined into the include site in the output.
In the case of the example, the word "Included" should show up somewhere in the output.
Resulting Output

http://github.com/vsch/flexmark-java

ref

Additional context
I saw this issue originally in my own code using "com.vladsch.flexmark:flexmark-all:0.61.16", and also the latest in the repo, by downloading the entire thing as a zip, at https://github.com/vsch/flexmark-java/commit/bdf33bb8570e08b9a014184ebdfc00058dfe093c.

@nanodeath, I forgot to update the JekyllIncludeFileSample.java to reflect the new implementation of Jekyll include tag processing.
Now embedding of content is done during parsing by IncludeNodePostProcessor.java. This means that include content map must be available before the document is parsed.
Effectively, if the embedding is done via a map which is computed from the document AST then the document needs to be parsed twice. Once to compute the map, then again with the defined map to embed the content.
If the include processing is done via a LinkResolver(s) which map include paths to absolute file://... URLs then the file content will be embedded from the file system, without the need to parse twice.
As an alternative, content embedding can be done without the double parsing by duplicating the processing in the IncludeNodePostProcessor.java which appends new child nodes to the JekyllTagBlock to hold the embedded content.
The change in processing was done to allow other (non-HTML) renderers to easily handle embedded content, since the original mechanism only supported embedding HTML.

This means that include content map must be available before the document is parsed.

I actually saw this and was poking through the source code trying to get this approach to work, but ended up giving up -- I could see the IncludeNodePostProcessor was getting picked up, but then never actually invoked.
Can you give me a simple example that should work?

@nanodeath, JekyllIncludeFileSample.java above is an updated working example which uses html content map.

@nanodeath, I am considering adding another extension point API: UriContentProvider to provide content for URLs. At the moment file:// URI is handled by code which needs content.
DocxRenderer uses image content for embedding and conversion, JekyllTagExtension uses it for embedding.
This is not reusable and hard-coded. Having this extension point will make it easy to handle any type of content including dynamic.

Sorry, commented from my work account, so I deleted that. I'll repeat my reply to your original comment here for some semblance of continuity:

This means that include content map must be available before the document is parsed.

I actually saw this and was poking through the source code trying to get this approach to work, but ended up giving up -- I could see the IncludeNodePostProcessor was getting picked up, but then never actually invoked.
Can you give me a simple example that should work?

The end goal here is to replicate Jekyll-style "layouts" where there's a common header/footer used across all pages that include in different content depending on the article being rendered, if that helps any :)

@nanodeath, If you create an HTML content map without examining what files the document actually includes then you can create the content map and set the options before creating the parser.
In your case, all included files are located in the _includes directory.
Since the include tag does not use a path, references from all markdown documents do not depend on the relative path of the document.
Compute the map of file name to rendered file content in for all files in the _includes directory. You might have to create aliases with and without an extension (not sure since I do not work with Jekyll and my knowledge is based on what I read in the documentation).
Then set options used to create the parser, includeHtmlMap is Map<String, String> from file name in the include tag to the HTML content of the file:
 options.set(JekyllTagExtension.INCLUDED_HTML, includeHtmlMap);
 options.set(JekyllTagExtension.EMBED_INCLUDED_CONTENT, true);

@nanodeath, I added a modified JekyllIncludeFileSample2.java which computes the html content map in advance and only parses the document once.

Thanks @vsch, I'll give it a try. I think in my most recent experimenting I missed the EMBED_INCLUDED_CONTENT option.

Eyyy, I finally got it working. Your JekyllIncludeFileSample2 example worked fine for me, and eventually I got my code working too.
Besides EMBED_INCLUDED_CONTENT, I was also missing extra newlines around the include -- looks like it requires at least two newlines before and after. I'm guessing this is necessary for it to be parsed as a JekyllTagBlock/JekyllTag? It's a bit surprising behavior that without the newlines, the include is silently omitted from the output -- no error, no {%include%}, no included content.
Anyway, thanks for your help and quick turnaround.

@nanodeath, I will take a look at why inline include tags are silently ignored. They should either be left as text or handled as includes. Could be a bug.

@nanodeath, can confirm that inline include tag implementation was broken. Now fixed.
For inline include tags, If included file contains a single paragraph then the paragraph is unwrapped so only the text is included. Otherwise, the included file AST is included as is, which may result in invalid HTML if included file has block elements since these will be included in the p tag of including element.
:information_source: when include tag embedding is enabled, the included file elements will be added as child nodes of the JekyllTag node, not JekyllTagBlock node as was done in previous versions.
Fix for this is available. Repo updated, maven updated but may take a while to show up in maven central.


Missing dist folder

Hi,
I'm trying to test your library that seems promising on CodeSandbox (https://codesandbox.io/s/vqvk0z0jl5).
The package.json contains references to files that doesn't exist.
  "module": "dist/vue-cast-props.es.js",
  "unpkg": "dist/vue-cast-props.js",
  "browser": "dist/vue-cast-props.es.js",

So I get the following error: ENOENT: no such file or directory, scandir '/tmp/1980110140/node_modules/vue-cast-props/dist'.
Would it be possible for you to fix the missing files?
Cheers.

It is probably because of the git ignore that ignores dist folder. It is quite common to commit them when the project is a library (e.g. https://github.com/vuejs/vue/tree/dev/dist)


[BUG] minor: ansi codes in daphene output

I use Rich as my Django logger, as described here: https://www.willmcgugan.com/blog/tech/post/richer-django-logging/
Everything worked fine with runserver, however once I started using Daphene there were ansi codes in the output.

Platform

Click to expand
Mac, rich==11.2.0

Thank you for the incredible piece of software!

This is probably because Daphne itself is writing ansi codes via logging. I would consider this an abuse of logging personally. There's not a great deal Rich can do about that.

Thanks, I'll open an issue there!


Adds engine hint to package.json

This module includes native ES2015 code since v3.0.0. In older node versions that do not implement the spread operator, the process crashes. This PR sets the engine property in the package.json to >=5.0.0 let users know about the compatibility issue during the install and prevent installing newer versions if the users choose to configure the engine-strict flag of npm.
In addition, the PR should be ported to v3.0.0 too (branch from that version, apply the change, create v3.0.1 and publish).

There are 2 versions here now. one the ES6 and one the ES5. I think this pull will make it so those who want the new ES5 version will not be able to get it.
What do you think?

The engines property is just a hint, so anyone using older node versions will be able to install the package anyway and require the ES5 file. Just a warning will be thrown by npm but not an error.
Having said that, my own preference to maximize both development productivity and compatibility is to code using the newest ES features and publish in ES5 using babel. That is briefly explained in http://jamesknelson.com/writing-npm-packages-with-es6-using-the-babel-6-cli/ and applied in some of my own packages as gabmontes/tiny-once. Hope that helps!!

Hey thanks!  It is the right tool for a lot of other stuff though! I just released a version that does node version detection and includes the event-pubsub es5 version when necessary.
I think this will fix the issue for those who have engine-strict set as well, and then everyone can get the latest updates.
:tada:
Thanks for helping out with this!

FYI, this was the fix :

let Events = require('event-pubsub/es5');
if(process.version[1]>4){
    Events = require('event-pubsub');
}


redis-filter: Support hash slot based routing

Commit Message: redis-filter: Support hash slot based routing
Additional Description: Adding a hash slot based routing for redis filter, see https://github.com/envoyproxy/envoy/issues/26511
Risk Level: low
Testing: Unit test/integration test
Docs Changes: TBD
Release Notes: TBD
Fixes #Issue: https://github.com/envoyproxy/envoy/issues/26511

Hi @mattklein123 , bumping this up ^ , thanks!


[wxwidgets] Add feature webview2

Fix https://github.com/microsoft/vcpkg/issues/26013
Add feature fonts.
All features tested on the following triplets:
x64-windows
x86-windows
x64-windows-static

Thank you!


LICENSE file missing

I can't find if the source is released under a license. Is there a license?

This software is free to use
I added a license file


MethodDataSource Matching Arguments Analyzer

I assume this issue is here because TUnit0010 is being triggered (now invalidly) for methods that have parameters?

Yep I will fix it at some point don't worry 😅 Might just have to suppress it in the mean time

No worries! Thanks! Just wanted to make sure I didn't open another issue for it. :)


Add IST

Why would BLD be verified and IST not be verified?

That's our way of marking incentivized/strategic assets to be included in the main app vs frontier.

Changed
Are we good to merge?
the Decentralized Cooperation Foundation is planning incentivize the IST pools asap.


feat: terraform contribution guide

Overview/Summary
This PR changes

Terraform contribution guide

If you want to view the compiled version of the current page clone/check this and run hugo serve.
As part of this Pull Request I have

[x] Read the Contribution Guide and ensured this PR is compliant with the guide
[x] Checked for duplicate Pull Requests
[ ] Associated it with relevant GitHub Issues or ADO Work Items (Internal Only)
[x] Ensured my code/branch is up-to-date with the latest changes in the main branch
[x] Ensured PR tests are passing
[x] Updated relevant and associated documentation (e.g. Contribution Guide, Docs etc.)

Some changes..
We should allow contributors to work from a branch in the main repo as they have write access. Using a fork is more complex and unnecessary.

As outside collaborator then, fine with that. Another option was to have dev branches in the source repo and letting contributors raise PRs against it, once their fork e2e test are green we merge their fork branch into dev and then raise an obligatory PR with e2e which should go green as well. But yeah granting them access as outside collaborator is a simpler solution.

Some changes..
We should allow contributors to work from a branch in the main repo as they have write access. Using a fork is more complex and unnecessary.

As outside collaborator then, fine with that although I thought the secret access will be fixed the need of secret access eliminated with the transition to self-hosted runners? Another option was to have dev branches in the source repo and letting contributors raise PRs against it, once their fork e2e test are green we merge their fork branch into dev and then raise an obligatory PR with e2e which should go green as well. But yeah granting them access as outside collaborator is a simpler solution.
Regarding your comments about the doco, I'm going to use our Thursday session to run us through the details and incorporate all your comments, thanks.

All questions were clarified.

Some changes..
We should allow contributors to work from a branch in the main repo as they have write access. Using a fork is more complex and unnecessary.

Added as per our conversation 3 weeks ago see https://github.com/segraef/Azure-Verified-Modules/blob/cd02c4c73fc42b89420ed6e407b5cabe6538c6d8/docs/content/contributing/terraform/terraform-contribution-flow/_index.md?plain=1#L110

Just one change on UMIs for contributors no longer bring requried

leftover comments, removed


Broken link in External Resources

There is a link in the page, which is broken:
The Definitive Guide to the JavaScript Generators by Gajus Kuizinas
I could find another source to the content, it could be helpful to insert a link from Web Archive.

@gajus is the article available somewhere on the web? :)

https://github.com/gajus/gajus.com-blog/blob/master/posts/the-definitive-guide-to-the-javascript-generators/index.md ?

https://github.com/gajus/gajus.com-blog/blob/master/posts/the-definitive-guide-to-the-javascript-generators/index.md ?

Thats correct. Sorry, didn't see the original notifications.

Fixed, thank you guys :)

Thanks everyone for your time and effort!


MINOR: Fixed misleading reference to HTTPS instead of SSL support in the doc

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/5896/
Test PASSed (JDK 7 and Scala 2.11).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/5881/
Test PASSed (JDK 8 and Scala 2.12).


samples: hello: increase TX buffer size for nrf52840dk_nrf52840

So far using cert-based authentication was not successful with
nrf52840dk_nrf52840 platform.
Seems that the main reason why handshake never succeeds is lack of network
TX buffers. Increasing them from default 16 to 32 solves the problem. There
are still allocation failures on the RX path (when receiving data from
offloaded WiFi chip and putting them on the networking RX queue), but in
the end DTLS handshake still completes.
Increase TX buffer to 32 for nrf52840dk_nrf52840 platform. Do this for
both PSK-based and cert-based authentication, as there is no easy mechanism
to apply those settings (apart from using default Kconfig values per
platform, which is kind of hacky) only for one platform and one
configuration variant.
Same issue does not reproduce with esp32 platform, probably due to mix of
following reasons:

240MHz vs 64MHz clock (ESP32 does the handshake in ~1.5s instead of ~12s
in case of nRF52840),
nRF52 + ESP-AT WiFi is suboptimal in UART (which is used as a
communication interface between the two) interrupt handling, where each
received byte from network is generating single interrupt, further
lowering processing power for general use like processing TLS handshake,
more time spent on processing handshake results in more retransmissions,
which results in more processing power needed for handling interrupts,
which once again results in more incoming data, ...,
TX/RX packets are not completely drained for ESP32 platform due to high
network traffic and processing time spent on handshake and interrupt
handling.

There are commit message compliance issues due to long line lengths. All those lines are because of log messages attached. Breaking those would decrease readability, so those checks were ignored on purpose in that case.


create(undefined) example is valid

Hey folks, first time TypeScript-er here! Loving the guide so far.
I think I found a small discrepancy in one of your examples. On line 290-291 of this guide, you say:

By default null and undefined are subtypes of all other types.
That means you can assign null and undefined to something like number.

This leads me to believe that you can also assign the value undefined to a variable with a type of null.
You then introduce the --strictNullChecks flag in line 293, which prevents null and undefined from being assigned to anything other than unknown, any, or their respective types. With this flag enabled, I believe you can no longer assign undefined to something with a type of null.
Amazing! I'll definitely want to use this in my code. However, you say that:

As a note: we encourage the use of --strictNullChecks when possible, but for the purposes of this handbook, we will assume it is turned off.

Here's the discrepancy I notice. In the Object section, you declare a function create:
declare function create(o: object | null): void;

You indicate that invoking the function with undefined would cause the compiler to error. It seems like this is only true with --strictNullChecks, which you said you assume is turned off for this handbook.
I've confirmed locally that create(undefined) does not produce an error when --strictNullChecks is not passed to the compiler. For this guide, I've moved create(undefined) into the "Ok" section, and I've added a comment clarifying that undefined is a subtype of null.
Does this change make sense to you?

Great point, yeah - this is right. Thanks for the comprehensive PR description, I agree!

Great point, yeah - this is right. Thanks for the comprehensive PR description, I agree!


Add documentation for dataframe reshape methods

Adds some documentation for the DataFrame reshape methods.
Do not have examples for pivot_table and melt, unless we want to borrow the ones from Pandas.
Reference issue: #4825

Thank you for taking the time to do this @tpanza
Two requests:

It looks like there is a small linting failure
dask/dataframe/reshape.py:249:121: E501 line too long (124 > 120 characters)

You can check this locally by running flake8 dask from the root directory of this repository

Can you also add an autosummary section for these functions?  This is what generates these nice summary sections for easier discovery:

This looks great.  Thanks for making the changes @tpanza .  Merging!
Also, I notice that this is your first code contribution to this repository.  Welcome!

Thank you, glad to help, and it was a good learning process.


[beta] Console output formatting of % character

Challenge make-circular-images-with-a-border-radius has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
The console output displays characters &#37 instead of % character. Not a biggie but still.

<link href="https://fonts.googleapis.com/css?family=Lobster" rel="stylesheet" type="text/css">

CatPhotoApp

Click here to view more cat photos.

Things cats love:

cat nip

laser pointers

lasagna

Top 3 things cats hate:

flea treatment

thunder

other cats

  <form action="/submit-cat-photo">
    <input type="radio" name="indoor-outdoor" checked> Indoor
    <input type="radio" name="indoor-outdoor"> Outdoor

    <input type="checkbox" name="personality" checked> Loving
    <input type="checkbox" name="personality"> Lazy
    <input type="checkbox" name="personality"> Energetic

    <input type="text" placeholder="cat photo URL" required>
    <button type="submit">Submit</button>
  </form>

Looking into this, I can confirm that I get the same error as @onpikono with the provided code.  I am using the same version of chrome on Mac and can reproduce on a current local build of freecodecamp.
It looks as though the console prints out the literal characters and not the ascii code equivalent.

Okay.  So, from what I found at Stackoverflow: Displaying unicode characters in codemirror and it's linked threads, Codemirror will display litteral html-code characters unless you specifically set up for decoding them.  It doesn't look as though there are many instances of them, if more than this test at this moment.
I tested using just literal '%' and ',' characters, since that is what the html-codes represent for and they render correctly.
To the more experienced Contributors:  Is there a problem that I am unaware of using these characters or should we work out the function to decode the characters before inserting the string into codemirror?


Issues setting up beaker dev env

Operation System: macOS
Beaker Version: master branch
I have a fresh clone of this repo. I ran npm install && npm start and saw this:

So I ran npm run build, then saw this:

Then I ran cd app && npm install && cd .. Same errors from start and build scripts.
Then npm run rebuild && npm run start and now I'm good.
So... let's document the right incantation in CONTRIBUTING.md. Does the following represent the current reality?
git clone https://github.com/beakerbrowser/beaker
cd beaker
npm install
npm run build
npm run rebuild
npm start

we have a “building from source” section in the readme

Ah oops I jumped straight to the existing CONTRIBUTING.md and didn't bother looking in the README.
I see a few paths forward:

Move the dev setup instrucutions from README to CONTRIBUTING, and add a link to the README

or

Leave instructions where they are, and link to them from CONTRIBUTING

Ok should be much clearer now. Thanks!

Bravo! Grazie!


README: Include '-m' in the ilab data generate --model command

In the README, at theilab data generate --model add -m to be consistent with other ilab commands

Related to #1871


Don't favor beginning of line

The current behavior is biased towards the beginning of the line. In other words, if you’re midway between two vertices on the line, the returned index always corresponds to the earlier vertex, even if the point is closer to the later vertex. (The distance is consistent with this bias.) It’s as if the function “rounds down”.
Moreover with this change, the "closest point" now has a distance which is less than what is currently in the test fixtures.
We discovered this bug while porting this library to swift and started to see some interesting edge cases when using this lib to draw maneuver arrows:

My worry with this change is that are other turf libraries which use this library and also assume it will round down.
/cc @tmcw @morganherlocker @1ec5

Heh, didn't see there was already another PR for this https://github.com/turf-junkyard/turf-point-on-line/pull/6/files. I'll keep this one open as it also updates the test fixtures.

Closing and opening in https://github.com/Turfjs/turf


Uniform distribution edges are faulty in multimodals

I think I understand why now. We don't actually render uniform distributions with 0s, just with the point single state value. I'll make a new issue for this.


Syntax highlighting with multiline REPL input

Source code:
```>
function fact(n)
    p = 1
    for i in 1:n
        p *= i
    end
    return p
end
```

```>
fact(30)
```

Keywords are not highlighted beyond line 1

the funny thing is that I do see issues here but not the one you mentioned

the Main.__FRANKLIN__ should be scrubbed, there's logic to do this that doesn't get applied here, that's not good
integer overflow or something 🤔
keyword stuff

note that the highlighting is not handled by [XF]ranklin, so here it's a matter of figuring out why highlight.js doesn't like what it sees. I'll investigate (should also do #262 while I'm at it...)

Integer overflow is the thing I want to demonstrate here :rofl:

Possibly related to https://github.com/JuliaEditorSupport/atom-language-julia/issues/282?

A lot of julia-repl code highlighter fall back to this regex, which appears to be broken.
Maybe this isn't too surprising given the comment on line 3.


Add support for legacy parsing of main.tf

Is your feature request related to a problem? Please describe.
We'd like to use the main.tf/main.tofu file to pin the opentofu version, just like the terraform plugin does (i.e. https://github.com/asdf-community/asdf-hashicorp/blob/master/bin/parse-legacy-file).
See also the legacy version files documentaion
Describe the solution you'd like
We'd like the plugin to be able to

parse main.tf for an opentofu version contraint
parse .opentofu-version for an  opentofu version contraint (although not that important to us, but this would make it feature-complete to asdf-hashicorp

Describe alternatives you've considered

Pinning the opentofu version in .mise.toml is an option, although this leads to 2 places where the tofu version is pinned (.mise.toml and main.tofu)

Additional context
None

Hi @hinricht :wave: many thanks for opening this feature request.
I'm happy to accept a PR if you and others are willing to resolve any bugs that may appear after the feature is released.
Currently, I do not use mise or legacy_version_file, and I do not have time to maintain it after the release.
wdyt?

@virtualroot Nice, I'll see when I can work on this, and will create a PR.

Here it is, hope it works!

Btw, I'm using mise and noticed that with this change, mise is able to set the tofu version from a main.tofu. but not from a file with a different name (even when I export the ASDF_OPENTOFU_VERSION_FILE env var to this file name).
I checked with the asdf-terradform plugin and it's the same.
Therefore I created a mise issue to track this error: jdx/mise#2602
Just fyi.

Thanks for the heads-up!


Improve error behavior

Currently if the proxy runs into an internal error the connection is just closed without any reply. While with #25 we now have logging for these, this behavior is still far from ideal. In addition the snafu dependency is a bit redundant atm. At the very least we should be giving at least some error and not a connection reset. as this can lead to very unexpected behavior in libraries
We have several options here:

Return an 400 bad request, this has the clear disadvantage that downstream consumers might try to parse the body as a discord error and fail very badly, potentially crashing them
return a generic 500 server error
return a 503 service unavailable

of these option 2 and 3 would probably be the best options

My suggestion based on skimming through RFC 2616:
https://github.com/twilight-rs/http-proxy/blob/trunk/src/main.rs#L271 should be 501
https://github.com/twilight-rs/http-proxy/blob/trunk/src/main.rs#L285 should be 501/500
https://github.com/twilight-rs/http-proxy/blob/trunk/src/main.rs#L298 should be 500
https://github.com/twilight-rs/http-proxy/blob/trunk/src/main.rs#L330 should be 500
https://github.com/twilight-rs/http-proxy/blob/trunk/src/main.rs#L342 should be 502


Coalesce multiple reads together and don't block on io if there's values available

Seems like ci hits a deadlock

I must have introduced deadlock in https://github.com/spiraldb/vortex/pull/1466/commits/4ffd42bbcd049af04175208c4b285efc83be2584 since everything was running before that commit. I will figure it out tonight

I merged the renames. I think there's still something funky with Unpin but I will fix it in a followup


[BUG] Possible bug in validation perplexity metric for DPO?

🐛 Bug
I'm not quite sure this is a bug, but after calibrating my hyperparameters for DPO (after running SFT on the model)  to get where validation loss falls through the training process, I am seeing validation perplexity increase, which I didn't think was possible (i.e validation loss and perplexity should be closely linked).
Relevant hyperparameters are Lora R: 64, Lora Alpha 256, Lora Dropout 0.05, Learning rate 0.00001, batch size 1, epochs 1, Gradient Clip 2, Beta 0.05. The dataset is composed of 620 SQL pairs that the model got wrong after SFT, with the corrected output.
Attaching a screenshot so you can see what I mean. Is this expected?

Thanks a lot for posting, interesting findings!
I've checked Perplexity implementation, code-wise I haven't found any issues.
For Dpo, validation loss and perplexity may exhibit different behavior, as dpo calculation is using
policy_chosen_logps - policy_rejected_logps - (reference_chosen_logps - reference_rejected_logps)
whereas Perplexity is using chosen_logits, only.
It is probably a good idea to add additional train/validation metrics (that will be logged to neptune) such as CE loss to better track the experiment.
I've created this branch where SampleAveragedCrossEntropyLoss is used as a validation loss and ran some experiments on it. So far, val loss is in sync with Perplexity.

I digged a bit deeper into the loss curves in this branch; cross entropy is logged for both accepted as well as rejected samples; alongside with the corresponding perplexity.
Regarding the different behavior of loss vs. perplexity, my explanation for this is that evaluation samples the model struggles to predict can disproportionately impact the overall perplexity.
As an example, suppose we have a dataset with 4 samples where the third sample is out-of-distribution of the SFT model.

After epoch 1, suppose the model has the following cross entropy loss for each sample: (1, 1, 9, 1) (third answer is hard to predict).
Mean cross-entropy (cross-entropy per sample / num_samples) will be 12/4 = 3
Mean perplexity  (perplexity per sample / num_samples) will be mean([exp(1), exp(1), exp(9), exp(1)]) ~ 2027.8.
After epoch 2, suppose the model has the following cross entropy loss for each sample: (4, 4, 4, 4) (model adapts to third sample at the cost of predicting the other samples worse)
Mean cross-entropy will be 16/4 = 4
Mean perplexity will be exp(4) / 4 ~ 13.6

My assumption is that this explains the behavior observed (and it is not caused by a bug).


flutter web 报错

我将fish-redux 2.2 集成进工程，在dart2js的时候报错，我怎样修改不会影响fish-redux正常运行？感谢！
bogon:caricature_app cibn$ webdev serve --hostname <IP_ADDRESS>
[INFO] Reading cached asset graph completed, took 573ms
[INFO] Checking for updates since last build completed, took 1.6s
[INFO] Serving web on http://<IP_ADDRESS>:8080
[SEVERE]build_web_compilers:ddc on lib/external/fish_redux/src/redux_connector/generator.dartdevc.module: Error compiling dartdevc module:caricature_app|lib/external/fish_redux/src/redux_connector/generator.ddc.js
[error] The integer literal '0x3FFFFFFFFFFFFFFF' can't be represented exactly in JavaScript. The nearest value that can be represented exactly is '0x4000000000000000'. (package:caricature_app/external/fish_redux/src/redux_connector/generator.dart, line 5, col 21)
Please fix all errors before compiling (warnings are okay).
}

代码：
String Function() generator() {
int nextId = 0;
String prefix = '';
return () {
if (++nextId >= 0x3FFFFFFFFFFF) {
nextId = 0;
prefix = '$' + prefix;
}
return prefix + nextId.toString();
};
}

flutter_web不支持插件
Plugins
Plugins are not currently supported in flutter web.
https://github.com/flutter/flutter/wiki/Building-a-web-application-with-Flutter


15 improve task weaver module

Updated versions of gpt-3.5-turbo to -1106-preview
added gpt4 as well
Added more detail on installations


set minimum word len for typos

this PR allows the configuration on the minimum word length for typos.
The default values are the same as previously.
steps

[x] introduce settings for the minimum word length for 1 and 2 typos
[x] update the settings update flow to set this setting
[x] create a structure TypoConfig to configure typo tolerance in the query builder
[x] in typo, use the configuration to create the appropriate query tree node.
[x] extend Context to return the setting for minimum word length for typos
[x] return correct error message for wrong settings.
[ ] merge #469

waiting on #469, but rfr

Could you also add one more integration test where you try to find a word by doing one/two typos on a short word and find your document, please? Or do we prefer it on the Meilisearch side?

I assumed that this was already covered by the typo tests on milli's side, but I can't seem to find the test. Can you confirm that it doesn't already exist?

@Kerollmops actually, after investigating more I couldn't find any test for typos, and even found a bug in the 2 typos codepath. I am writing more tests and fixing that.

@Kerollmops, we should merge https://github.com/meilisearch/milli/pull/485 before

Thanks!
bors merge


Add missing include files

[hip] - cstring for std::memcpy and cstddef for size_t
[serial] - cstddef for size_t

FYI, to build with ROCm 5.0 I need to patch one file in the Eigen external:
diff --git a/Eigen/src/Core/products/GeneralBlockPanelKernel.h b/Eigen/src/Core/products/GeneralBlockPanelKernel.h
index 40171eb83..b073ecf7a 100644
--- a/Eigen/src/Core/products/GeneralBlockPanelKernel.h
+++ b/Eigen/src/Core/products/GeneralBlockPanelKernel.h
@@ -73,13 +73,7 @@ struct CacheSizes {
   CacheSizes(): m_l1(-1),m_l2(-1),m_l3(-1) {
     int l1CacheSize, l2CacheSize, l3CacheSize;

-#if !defined(EIGEN_CUDA_ARCH)
     queryCacheSizes(l1CacheSize, l2CacheSize, l3CacheSize);
-#else
-    l1CacheSize = defaultL1CacheSize;
-    l2CacheSize = 1572864;
-    l3CacheSize = defaultL3CacheSize;
-#endif
     m_l1 = manage_caching_sizes_helper(l1CacheSize, defaultL1CacheSize);
     m_l2 = manage_caching_sizes_helper(l2CacheSize, defaultL2CacheSize);
     m_l3 = manage_caching_sizes_helper(l3CacheSize, defaultL3CacheSize);
@@ -117,7 +111,19 @@ inline void manage_caching_sizes(Action action, std::ptrdiff_t* l1, std::ptrdiff
   {
     eigen_internal_assert(false);
   }
-  #else // EIGEN_CUDA_ARCH
+  #elif defined(EIGEN_HIP_DEVICE_COMPILE)
+  if (action==GetAction)
+  {
+    // GCN 5.0 / Radeon Pro WX 9100
+    *l1 =         16 * 1024;  // 16 KB per CU
+    *l2 =   4 * 1024 * 1024;  // 4 MB
+    *l3 =                 0;
+  }
+  else
+  {
+    eigen_internal_assert(false);
+  }
+  #else
   static CacheSizes m_cacheSizes;

   if(action==SetAction)

I wonder if that patch would work with earlier ROCm versions (say down to 4.3)? Also, if we should look into applying this patch locally (as we did earlier), propagating it to CMS' eigen mirror, or trying to get it into upstream?

The patch is on top of the other CMS / Patatrack changes, so it'll take some effort to upstream everything.

I've pushed it to the CMS repository and update the pixeltrack-standalone Makefile (via https://github.com/cms-patatrack/pixeltrack-standalone/pull/319)

And the update for CMSSW_12_3_X is in https://github.com/cms-sw/cmsdist/pull/7649 .


Rename components folders

Related to #1158

There is going to be a massive refactor with the POC of agnostic components so I'm better closing. Thanks for the PR anyway! :)


Move ZMQ native libs and native loading logic into 3rdParty/libnzmq

Notice
It is not allowed to submit your PR to the master branch directly, please submit your PR to the master-pre-merge branch.
Description
Please include a brief summary of the change that this pull request proposes. Include any relevant motivation and context. List any dependencies required for this change.

Move ZMQ native libs and native loading logic into 3rdParty/libnzmq

put the .so files in libnzmq (when it builds, its .jar will have the .so files)
libnzmq seemed to have some native library loading code ... I don't think it was used and wasn't implemented correctly though, so I replaced it with a simpler implementation
update Gradle
removed the library loading code from rest of kernel

removed some modules' Gradle dependency on aion_api (they weren't actually needed)
aion_api needs an update for this to work -- https://github.com/aionnetwork/aion_api/pull/57

Fixes Issue # .
Type of change
Insert x into the following checkboxes to confirm (eg. [x]):

[ ] Bug fix.
[ ] New feature.
[ ] Enhancement.
[ ] Unit test.
[ ] Breaking change (a fix or feature that causes existing functionality to not work as expected).
[ ] Requires documentation update.

Testing
Please describe the tests you used to validate this pull request. Provide any relevant details for test configurations as well as any instructions to reproduce these results.

Manual testing only

compiled and ran kernel with Api Server and connected Desktop Wallet to it
./gradlew pack succeeds

Verification
Insert x into the following checkboxes to confirm (eg. [x]):

[ ] I have self-reviewed my own code and conformed to the style guidelines of this project.
[ ] New and existing tests pass locally with my changes.
[ ] I have added tests for my fix or feature.
[ ] I have made appropriate changes to the corresponding documentation.
[ ] My code generates no new warnings.
[ ] Any dependent changes have been made.

discussed with @aion-kelvin , the client api will merge first then put the cross-platform support in the following PR,

@AionJayT -- heard back from Centrys; they said:

as long as the communication protocol between the java api and the kernel is not affected, we can live with an older version of the api.

So, I think we are good from their side!


[e2e]: nodejs push main custom_publish slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/10484405961
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.nodejs.push.main.custom_publish.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.nodejs.push.main.custom_publish.slsa3.yml
Trigger: push
Branch: main
Date: Wed Aug 21 06:07:12 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/10502715022
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.nodejs.push.main.custom_publish.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.nodejs.push.main.custom_publish.slsa3.yml
Trigger: push
Branch: main
Date: Thu Aug 22 06:09:29 UTC 2024
Tests are passing now. Closing this issue.


Spanner: support stored procedures in the form of Java bytecode

Yes I know this is a long shot, just throwing it out there...
Is your feature request related to a problem? Please describe.
The problem is this: like many folks we use Java and persist state using ORM solutions like Hibernate. Because Java is object oriented and inter-object references are everywhere, it's easy for a single transaction to end up requiring lots of query-response round trips to the database, due to the Java code traversing a bunch of collections and object references.
This happens because with SQL it's just not always feasible to JOIN together everything you need to look at in one query (e.g., you can't just set FetchMode.EAGER on all your collections or else you get a combinatorial explosion). The only alternative is for collections and referenced objects to be loaded at least somewhat lazily, i.e., on demand. And the more complex your Java transaction, the more complex your data access pattern.
This round-tripping is OK except in scenarios where there is an appreciable round trip time to your database. But this is exactly the situation if someone is using Spanner from the "outside world", i.e., their application is not hosted within Google's cloud infrastructure. We would like to use Spanner from the "outside world".
Of course, the long RTT will not only make transactions slower, but also make them more likely to have a retry failure due to a conflict: typically a transaction will do more reading at the beginning of the transaction, and then do its writing at the end; the more time separation between the reads & writes, the wider the race window.
The obvious way to fix this problem is to move the code to the data instead of what we end up doing today, which is moving a lot of the data to the code.
Some database support SQL stored procedures but trying to write elegant code in that language, and implement and debug it inside a Java application, is a nightmare.
Describe the solution you'd like
I'd like Spanner to have first-class support for moving the code to the data, and I'd like Java classfiles to be one supported code type.
Presumably, Spanner would define some SpannerQuery interface that my code could implement. I'd send my code to Spanner and tell it to invoke my code and return the result. The entire execution would be performed within the context of the containing transaction, on the Spanner node where it can access whatever data it decides it needs to access with minimal latency. One round trip and the whole transaction is done!
There are lots of ways this could be configured. For Java, you could designate a table having a className and bytecode columns to contain your code. Or, call it Java stored procedures and mimic the SQL stored procedure syntax (of course, adding the bytecode part).
Note that VoltDB supports Java stored procedures, so the idea is not crazy.
Describe alternatives you've considered
Not using Spanner?

Hi @archiecobbs
Thank you for your extensive feature request. This is however not a feature that we could logically add to the client libraries. Instead, this would be something that would have to be added to the backend. This GitHub repository is only used for the client libraries. The issue tracker for the backend can be found here: https://issuetracker.google.com/issues?q=componentid:190851%2B status:open
Would you mind open a feature request there instead?
I'll leave it to the backend team to discuss whether this has any chance of this being added in the foreseeable future.
Alternative Solution
If I understand you correctly, your main problem is the high round-trip time to the database as you are executing your application outside the Google infrastructure. At the same time, it would be possible for you to extract the database transaction logic into separable blocks of code that you would like to add to the database, and let the database server execute for you. Could it also be a possibility to place these transaction blocks in a separate container and execute these on Google Compute or Google App Engine?
That would enable you to keep most of your application logic where it currently is, while moving the database transaction logic into the Google infrastructure.

@olavloite , sorry for the misdirected issue report and thank you for the redirect and the suggestion. Closing this issue.

New issue created: https://issuetracker.google.com/issues/144183725


Constant upgrade 10 always acts as if it's level 1.

Constant upgrade 10 always acts as if it's level 1.
The code specifically does Math.min(1, player.constantUpgrades[10])
This slows the game down by like 10 to 100 times where I'm up to.

Constant upgrade 9 also appears to do this.


Isolate os in the db module

I ran into this issue playing around with coverage 5 and my diff_cover project
I fixed the issue in diff cover (https://github.com/Bachmann1234/diff_cover/pull/118) but it would have been a very difficult issue to diagnose had I not already been working from the coverage source.
I noticed this isolate_module pattern in other places and it seemed to fix this problem as well. I tested it by running a report on a version of diff-cover without my fix

the steps to trigger the bug btw
checkout diff_cover at commit 242a4de016c1c21ac5f25ab5a00df60a896a7a46
checkout coveragepy at commit 9bc6b93805a5f20a87211a315d00503eddab66dc
on my mac 10.14.5
git clone git@github.com:Bachmann1234/diff_cover.git
git clone git@github.com:nedbat/coveragepy.git
virtualenv -p python3 venv
source venv/bin/activate
cd diff_cover
git checkout 242a4de016c1c21ac5f25ab5a00df60a896a7a46
pip install -r requirements/test-requirements.txt
pip uninstall coverage
cd ../coveragepy
pip install -e .
cd ../diff_cover
coverage run -m pytest

Test suite should run and end with
Data file '/Users/bachmann/Desktop/diff_cover/.coverage' doesn't seem to be a coverage data file: Couldn't use data file '/Users/bachmann/Desktop/diff_cover/.coverage': no such table: coverage_schema

This is because of a sloppy mock on my part causing coverage to think the db already exist. It then fails to open said db.

Codecov Report

Merging #821 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #821      +/-   ##
==========================================
+ Coverage   90.09%   90.09%   +<.01%
==========================================
  Files          81       81
  Lines       11333    11334       +1
  Branches     1197     1197
==========================================
+ Hits        10210    10211       +1
  Misses        985      985
  Partials      138      138

Impacted Files
Coverage Δ

coverage/sqldata.py
92.91% <100%> (+0.01%)
:arrow_up:

Continue to review full report at Codecov.

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


Build failure: tailwindcss

Hi all!
It seems like I can't build tailwindcss with an extra plugin.
The issue seem to be node-package wide.
Here it is:
Steps To Reproduce
shell.nix
let pkgs = import <nixos-unstable> {};
in pkgs.mkShell {
  name = "tailwind";
  buildInputs = [
    (pkgs.pkgs.tailwindcss.overrideAttrs (old: {
      plugins = [ pkgs.pkgs.nodePackages."@tailwindcss/typography" ];
    }))
  ];
  src = null;
  shellHook = "";
}

Build log
error:
       … while calling the 'derivationStrict' builtin

         at /builtin/derivation.nix:9:12: (source not available)

       … while evaluating derivation 'tailwind'
         whose name attribute is located at /nix/store/zlb6mx5dc6qsb66397k0szgb34lzq5x5-nixos-unstable/nixos-unstable/pkgs/stdenv/generic/make-derivation.nix:336:7

       … while evaluating attribute 'buildInputs' of derivation 'tailwind'

         at /nix/store/zlb6mx5dc6qsb66397k0szgb34lzq5x5-nixos-unstable/nixos-unstable/pkgs/stdenv/generic/make-derivation.nix:383:7:

          382|       depsHostHost                = elemAt (elemAt dependencies 1) 0;
          383|       buildInputs                 = elemAt (elemAt dependencies 1) 1;
             |       ^
          384|       depsTargetTarget            = elemAt (elemAt dependencies 2) 0;

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: 'utillinux' has been renamed to/replaced by 'util-linux'

Additional context
I think it's related to this line, which was for 20.09. Maybe useless now?
https://github.com/NixOS/nixpkgs/blob/e0464e4/pkgs/development/node-packages/node-env.nix#L7
Maybe related issue: https://github.com/NixOS/nixpkgs/issues/350738
Notify maintainers
because it's node-packages wide: @Luflosi
because it targets tailwindcss: @adamcstephens

Probably also fixed by #350815

If there's a node issue, it's unrelated to tailwindcss. https://github.com/NixOS/nixpkgs/blob/7eabf557d4fd5e7195cb3e372304ffdeb04170a9/pkgs/development/tools/tailwindcss/default.nix

Oh, that's right. I thought I was adding the typography myself, but it's actually already integrated in the bundle. Thanks!


Add a scraper for the EPA-EIA Crosswalk

This is a draft PR so folks can follow along on my progress towards adding a EPA-EIA Crosswalk scraper. Note that there are several line changes because of the black formatter--not trying to be gnit-picky!
The scraper successfully downloads two files from the CAMD github page:

epa_eia_crosswalk.csv
field_descriptions.csv

Questions:
Right now the scraper uses a direct link to download each of the files. I.e.:

"https://github.com/USEPA/camd-eia-crosswalk/raw/master/epa_eia_crosswalk.csv"
"https://github.com/USEPA/camd-eia-crosswalk/raw/master/field_descriptions.csv"

Would it be more robust to start with the link to the main github page "https://github.com/USEPA/camd-eia-crosswalk" and work from there using xpaths to find the links to each of the files?

I decided against downloading the entire repo and then extracting the files I wanted, do you agree with this method?

It might be worth doing a single bulk reformatting of everything with black in an isolated commit that we can add to the git-blame-ignore list. More generally we could bring over the pre-commit hooks from the cheshire repo. Let me know if you want help setting that stuff up.

, so I think I'd lean toward grabbing the entire repo

Ok that makes sense

@zaneselvans @cmgosnell
Do you think I need to write a test for this? It's so strait forward I feel like it doesn't even need one.

Regarding a test: You could also just run the scraper. The runner is on github and the data is on github and it's only 1MB so it will be super fast, and it'll catch when they (say) rename the master branch to main or change the repo in some other way.

Regarding a test: You could also just run the scraper. The runner is on github and the data is on github and it's only 1MB so it will be super fast, and it'll catch when they (say) rename the master branch to main or change the repo in some other way.

Do you mean that I should write a test that runs the scraper or just run the scraper as a test any time I want to see if it still works?

Oh also all of the tests in this module have the word test as a prefix rather than a suffix. EX: test_eia860.py vs. eia860_test.py. Should I change these? I'm shocked this hasn't been addressed unless it's some weird scrapy specification I'm not aware of.

Though maybe I should get the CI in here soon since pre-commit-ci is trying to run an failing because it's not configured! 😆

Maybe it makes sense to make this another PR and close this one out.


Update README.md

Some additions to the explanation - hope you like them!

Good stuff, very helpful!


AccessKit updates: macOS text editing, critical fixes for Windows 11 with Narrator

We just need to bump egui-winit's dependency on accesskit_winit to 0.7.2. What's the standard procedure for such a dependency update?

@emilk I mean, should I just open a PR with the dependency bump and the updated Cargo.lock, or would you rather batch this update with others, as you have before? I'd personally prefer to do this one right away, because AccessKit has momentum and I want to keep it going, with egui reflecting the latest improvements. But of course, this is your project.

Given that the accesskit_winit semver spec is 0.7.1 with no other qualifiers, Cargo treats it as a range. There is technically no need to do anything more. Dependents will naturally pull in 0.7.2 for their first build (without a lockfile) or after running cargo update.
But IMHO, a PR just to bump a dependency is a reasonable thing to do.


Simplify the encoded_value type

We have found that it is a bit too cumbersome to use the encoded_value<T> struct. It has several limitations in some of our common uses cases:

It is often not very interesting to know how the data is stored in the value
When the caller wants a std::string it can just call json::encoded instead of json::encoded_value
Creating an encoded_value with the intention of writing to another JSON string requires an extra copy of the encoded JSON (encode_context → std::string → encode_context)
json::encode_value is unsafe when used incorrectly (json::encode<json::ref>(...))
It is difficult to write an function that takes an encoded value, since the value has the storage type in a template parameter (encoded_value<std::string>, encoded_value<ref> or encoded_value<whatever>?)

We would like the API to have the following characteristics:

Safe
Simple
As fast as possible but not faster

I feel that the current variant of encoded_value<T> fails all three of those. 😢
I propose that we simplify the encoded_value<T> to just encoded_value (no <T>). The new version will always own the JSON data, but we don't allow the caller to std::move the storage out from it. The most common use case for this was to steal the underlying std::string value, but the caller can do that with json::encode anyway. The new type would allow the json::encode_value function to move the encode_buffer into the returned value, avoiding the extra copy mentioned above.
This would make the API safe and simple and in many cases fast. We should also let advanced users of the API avoid the copy completely when there is an opportunity for that. I propose that we introduce a new type json_value_ref that is similar to the json_value (the any_value_t codec should work with both types), but does not have its own storage of the JSON, just referring to another JSON buffer. The caller is then responsible for keeping the JSON buffer alive for as long as they need to use the encoded values.
By letting the encoded_value and encoded_value_ref types implicitly convert, the usage stays simple:
...
json::encoded_value save_some_state() const;
void restore_some_state(const json::encoded_value_ref &saved_state);
...
const auto saved_state = save_some_state();
restore_some_state(saved_state);

Compare this to today's situation:
...
json::encoded_value<> save_some_state() const;  // T is std::string
void restore_some_state(const json::encoded_value<> &saved_state);
...
const auto saved_state = save_some_state();  // Copying the JSON into a std::string
restore_some_state(saved_state);

or:
...
json::encoded_value<> save_some_state() const;  // T is std::string
void restore_some_state(const json::encoded_value<json::ref> &saved_state);
...
const auto saved_state = save_some_state();  // Copying the JSON into a std::string
restore_some_state(saved_state);  // Mismatching storage types

Summary
json::encoded_value<T>
json::encoded_value and json::encoded_value_ref

lgtm. How far away do you think we are from 1.0 after this?

Also seems sensible to me.


Don't get the pretty stack trace, only the basic one

Hi, i followed the Readme but i don't get to the pretty stacktrace, only the simple one:
i=0
i=1
i=2
i=3
i=4
i=5
i=6
i=7
i=8
i=9
i=10
i=11
i=12
i=13
i=14
i=15
i=16
i=17
i=18
i=19
i=20
i=21
i=22
i=23
i=24
i=25
i=26
i=27
i=28
i=29
i=30
i=31
i=32
i=33
i=34
i=35
i=36
i=37
i=38
i=39
i=40
i=41
#0 at unsigned long backward::details::unwind<backward::StackTraceImpl<backward::system_tag::linux_tag>::callback>(backward::StackTraceImpl<backward::system_tag::linux_tag>::callback, unsigned long)
#1 at backward::StackTraceImpl<backward::system_tag::linux_tag>::load_here(unsigned long)
#2 at TracedException::_get_trace[abi:cxx11]()
#3 at TracedException::TracedException()
#4 at f(int)
#5 at f(int)
#6 at f(int)
#7 at f(int)
#8 at f(int)
#9 at f(int)
#10 at f(int)
#11 at f(int)
#12 at f(int)
#13 at f(int)
#14 at f(int)
#15 at f(int)
#16 at f(int)
#17 at f(int)
#18 at f(int)
#19 at f(int)
#20 at f(int)
#21 at f(int)
#22 at f(int)
#23 at f(int)
#24 at f(int)
#25 at f(int)
#26 at f(int)
#27 at f(int)
#28 at f(int)
#29 at f(int)
#30 at f(int)
#31 at f(int)
Stack trace (most recent call last):

I copied the source from the _test_main.cpp file to my project
#include "backward.hpp"

using namespace backward;

class TracedException : public std::runtime_error
{
public:
	TracedException() :
		std::runtime_error(_get_trace())
	{}

private:
	std::string _get_trace()
	{
		std::ostringstream ss;

		StackTrace stackTrace;
		TraceResolver resolver;
		stackTrace.load_here();
		resolver.load_stacktrace(stackTrace);

		for (std::size_t i = 0; i < stackTrace.size(); ++i)
		{
			const ResolvedTrace trace = resolver.resolve(stackTrace[i]);

			ss << "#" << i << " at " << trace.object_function << "\n";
		}

		return ss.str();
	}
};

void f(int i)
{
	if (i >= 42)
	{
		throw TracedException();
	}
	else
	{
		std::cout << "i=" << i << "\n";
		f(i + 1);
	}
}

namespace {

	TEST(pfFiles, TestStackError)
	{
		backward::StackTrace st;
		try
		{
			f(0);
		}
		catch (const TracedException& ex)
		{
			std::cout << ex.what();
		}

		backward::Printer printer;
		//    printer.address = true;
		printer.object = true;
		printer.print(st, stdout);
	}
}

I use the following CMAKE settings.
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -Werror -Wno-long-long -Wpedantic -std=c++14 -g")
  set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lbfd")

I have installed backward-cpp as subdirectory in my cmake script.
I installed the gnu binutils package under ubuntu 16.04LTS with gcc 5.4.
I neither set the define (-DBACKWARD_HAS_...=1) flag nor used #define BACKWARD_HAS_BFD 1 because it seems that your cmake script automaticly detects the library:
Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
-- Could NOT find libdw (missing:  LIBDW_LIBRARY LIBDW_INCLUDE_DIR)
-- Found libbfd: /usr/lib/x86_64-linux-gnu/libbfd.so
-- BACKWARD_HAS_UNWIND=1
-- BACKWARD_HAS_BACKTRACE=0
-- BACKWARD_HAS_BACKTRACE_SYMBOL=0
-- BACKWARD_HAS_DW=0
-- BACKWARD_HAS_BFD=1
-- Found Backward: /home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/3rdparty/backward-cpp

i compile with:
add_executable(PfTEngineTest ${SOURCES} ${BACKWARD_ENABLE})
add_backward(PfTEngineTest)

So my question is: What do i have to do to get the full pretty code style?
Have i installed all dependencys correclty ?
Have i forgot something ?
The README doesn't specify what needs to be in code for pretty code ? is it enough just to compile backward.cpp with my target ?
Or do i have to create some classes ?
Do i need to throw special Exceptions or is everything catched ?
Do i need a TRY/CATCH block in main which covers everything ?
Thanks for any help :)
PS: I used the changed code from #51

It looks like you are not collecting all the trace details in your _get_trace method. Try calling abort() with backward-cpp signal handler installed for comparison.

The README doesn't specify what needs to be in code for pretty code ?

It does, read again :) And as far as I can tell, your defines are correct in your cmake output. (But I am not experienced with CMake, so take my affirmation with a grain of salt). You have unwind and BFD.

Do i need to throw special Exceptions or is everything catched ?
Do i need a TRY/CATCH block in main which covers everything ?

backward-cpp doesn't offer any function to attach stacktrace onto Exceptions (I had a work in progress branch at some point, but never took the time to finish the work).
If you never catch an exception, eventually your program will call abort(). This will effectively get you a stacktrace from backward-cpp assuming signal handlers are registered. But this stackstrace will start from the abort() call not were the exception was raised.
So your idea of storing a stacktrace alongside the Exception is perfectly good, but make sure to collection all the details :) I would advise you to collection stacktrace only in the exception, and use the stacktrace printer whenever you want to print details about the stacktrace.
Best,

I was not sure if
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lbfd")

is the correct way to link against the library, so i added:
target_link_libraries(PfTEngineTest "libbfd.so")

now when calling abort in f() i get a pretty nice stacktrace.
`i=0
i=1
i=2
i=3
i=4
i=5
i=6
i=7
i=8
i=9
i=10
i=11
i=12
i=13
i=14
i=15
i=16
i=17
i=18
i=19
i=20
i=21
i=22
i=23
i=24
i=25
i=26
i=27
i=28
i=29
i=30
i=31
i=32
i=33
i=34
i=35
i=36
i=37
i=38
i=39
i=40
i=41
Stack trace (most recent call last):
#31   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#30   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#29   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#28   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#27   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#26   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#25   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#24   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#23   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#22   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#21   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#20   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#19   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#18   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#17   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#16   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#15   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#14   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#13   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#12   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#11   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#10   Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#9    Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#8    Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#7    Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#6    Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#5    Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#4    Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#3    Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 50, in f(int) [0x4be574]
         47: 	else
         48: 	{
         49: 		std::cout << "i=" << i << "\n";
      >  50: 		f(i + 1);
         51: 	}
         52: }
#2    Source "/home/gitlab-runner/builds/0c2717af/0/PfTTech/PfTEngine/src/test/pfthread.cpp", line 44, in f(int) [0x4be53b]
         41: {
         42: 	if (i >= 42)
         43: 	{
      >  44: 		abort();
         45: 		throw TracedException();
         46: 	}
         47: 	else
#1    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7faf86b13029, in abort
#0    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7faf86b11428, in gsignal
Aborted (Signal sent by tkill() 19122 999)
Aborted

I am glad that it works now :)

So the pretty output only shows up if you link against the right libraries? I think there's a bug in the conan recipe then :(

Only if you link to one of the two lib and of course you  set the right
defines for it so that backward-cpp can include the headers and make use of
them.
I have no clue how Conan works. It was a contribution. Maybe there is way
to setup optional dependencies in Conan? Or maybe what you did was the
right way as the Conan recipie did setup the right defines automatically
perhaps?
On Fri, Jan 13, 2017, 04:47 Manu Sánchez<EMAIL_ADDRESS>wrote:

So the pretty output only shows up if you link against the right
libraries? I think there's a bug in the conan recipe then :(
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/bombela/backward-cpp/issues/52#issuecomment-272435586,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANMjCfDclFL3JvNTlzP5X97A1YsAJceks5rR3JfgaJpZM4LeXau
.

From the package recipe perspective, conan is just a python script that tells how to get your project sources, build them, and what build artifacts must be packaged (In this way works very similar to some system package managers). The only thing that makes it special is that conan is specifically designed for C++, so it keeps track of compiler versioning, abi, platform, etc when building and resolving the dependencies.
With this in mind, if there's a bug in the way optional libraries are handled is because I didn't take this right into account when writing the recipe. Specifically, I put one conan option (A package can define multiple options that result in different "variants" of the same package, for example "MyFooLib" Debug vs Release) for each backward-cpp option. Then conan build() method just invokes your CMakeLists.txt with those options. What I forgot is to tell the library (Maybe by modifying how the cmake library target is handled in the CMakeLists.txt) to link against different optional libraries depending on the options.

cannot print pretty stack backtrace either.
os: centos6.2
0、uncomment #define BACKWARD_HAS_DW 1 in backward.cpp  1、cmake . 2、make
3、g++ -o t t.cc -g -I/home/txy/learn/backward-cpp/ /home/txy/learn/backward-cpp/libbackward.a -ldw
4、./t  output Segmentation fault (core dumped) no pretty trace.


Can't export data.

Using Safari and clicking export data doesn't do anything. Any suggestions as to what might be going wrong?

Do you have any logs ?
Works fine on chrome :(


Badge freezes on Basic serial loading: 'sload'

In Basic interpreter type "sload". Badge cannot receive information and BRK has not effect.

I can't reproduce the issue. Both receiving from serial line and BRK abort does work as expected.
Please, try the 1.06 binary I just pushed to repository, it doesn't exhibit the problem. If the problem still persists, please paste build output here.

Tested and working in v1.07


ISSUE: UI is not mobile friendly

Hy, I was trying to run it on my Samsung Galaxy 21 and it didnt work well. I would like to help to make it more responsive.

will fix soon

Merged to develop


Simplify package.json

There's a shorter repository property for GitHub repositories, according to npm docs.
normalize-package-data says bugs are needless if you're specified the repository.

Thanks. Will check it later today


Added user command to set multiple entities

Signed-off-by: ahcorde<EMAIL_ADDRESS>🎉 New feature
Summary
In ign-omni we need to set up multiple entity poses. This PR adds a new user command service called set_pose_vector that allows to set up multiple entity poses
Test it
Checklist

[x] Signed all commits for DCO
[x] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[x] codecheck passed (See contributing)
[x] All tests passed (See test coverage)
[x] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

This pull request has been mentioned on Gazebo Community. There might be relevant details there:
https://community.gazebosim.org/t/new-ignition-releases-2022-04-13-fortress-edifice/1367/1


Cannot read properties of null (reading 'props')

Installed the package and setup and also looked on the examples after running vite page go blank and a console error message.
app.ts:131 Uncaught TypeError: Cannot read properties of null (reading 'props')
    at ReactiveEffect.fn (app.ts:131:38)
    at ReactiveEffect.run (reactivity.esm-bundler.js:190:25)
    at get value [as value] (reactivity.esm-bundler.js:1171:39)
    at Object.get2 [as get] (reactivity.esm-bundler.js:504:67)
    at ReactiveEffect.fn (momentum-modal.js:15:46)
    at ReactiveEffect.run (reactivity.esm-bundler.js:190:25)
    at get value [as value] (reactivity.esm-bundler.js:1171:39)
    at w (momentum-modal.js:44:26)
    at momentum-modal.js:51:1

PHP: 8.1.
Laravel: 10x
Vite: 4.2.2
Vue: 3.2.47
@inertiajs/vue3: 1.0.4
momentum-modal: 0.2.1
based/momentum-modal: v0.2.0

After hours debugging the issue was on my packages (npm).
I just ran npm update and after that everything works!
I used laravel/breeze for initializing my project. Just added here if someone rans into it.
Thanks for this wonderful & helpful package!


Supports "SAMPLE BY"  statement

What problem does the new feature solve?
SAMPLE BY in questdb is a really useful statement for summarising large datasets into aggregates of homogeneous time chunks.
SELECT time, avg(price) FROM trades SAMPLE BY 30m

We already implement PromQL plans such as SeriesNormalize, InstantManipulate etc. in our pure rust PromQL implementation. I think it's easy to support this statement by adding those plans into SQL planners to enhance the SQL too.
What does the feature do?
Described above.
Implementation challenges
No response

Will this also introduce the support of time literal outside of SAMPLE BY statement? For example, Influxdb's influxql supports syntax like WHERE time >= now - 12h

Will this also introduce the support of time literal outside SAMPLE BY statement? For example, Influxdb's influxql supports syntax like WHERE time >= now() - 12h

The syntax sugar for timestamp such as 12h or 5metc.  is an important part of TSDB, and we want to support them too.
I think we can create an independent issue to track it.

Will this also introduce the support of time literal outside SAMPLE BY statement? For example, Influxdb's influxql supports syntax like WHERE time >= now() - 12h

The syntax sugar for timestamp such as 12h or 5metc. is an important part of TSDB query language, and we want to support them too. I think we can create an independent issue to track it.

We can derive this duration parsing functionality from promql-parser here, which is in PromQL's format like 5m, 4d3h.

Duplicated with #1662


[DO NOT MERGE] [KeyVault] Common public source code unified through a private, bundled package.

(this PR is supposed to be a draft PR, my bad)
This PR is part of a set of PRs made to explore together what are the possibilities of having, and managing, common code dependencies.
In this specific PR, we'll be exploring how it would be to move the common code out of KeyVault-Keys into a separate private project, published through bundledDependencies.
Things to consider:

I haven't dug through the setting files to make sure they're as clean as they can possibly be.
I haven't moved out the same common test code from KeyVault-Secrets and KeyVault-Certificates to avoid having to have so many changes in one single PR.
CI might not pass right away, but I'm confident I can get it to work once we pick an approach.

To do:

Come up with a list of pros and cons.
Fix CI.

Your review is appreciated.
Please also check the other PRs:

[KeyVault] Test utilities in a separate, private package #7611
[KeyVault] Test utilities in a separate folder, through symbolic links and scripts #7612

Closing on favor of: https://github.com/Azure/azure-sdk-for-js/pull/7612


[silx view] Support title in NXdata views

See the expected behavior in:
https://github.com/nexusformat/definitions/issues/760

It was already supported! I was expecting an NXdata attribute but it is a dataset inside the NXdata group.

@PiRK Good job


Load new images to demo, run data update utility and test.

Once the data model changes (to support the proxy submitter use case) have been implemented in all components of the system. New images (fcrepo, ember etc.) will need to be deployed to demo, and the update utility run against the database.

@htpvu I think this is a duplicate of #70 and can be closed.


Forcing function symbols

It seems that whenever a symbol that does not appear elsewhere in a specific model is defined using a forcing function, it is not added to the parameters list of the instantiated model. This is contrary to the behaviour for conventionally defined symbols. So in the following case:
Y = 1
!F X = 2

For a model "mod", mod.parameters will only contain X if it is in a rate equation (if it is a substrate/product it will appear in mod.species), while Y will appear in the parameter list.
Is this the intended behaviour? A workaround for this issue is to add X=0 to the model file before using X in the forcing function, but I'm not sure if this could have unintended side effects.

Hi, your workaround is the proper way to do it.
Forcing functions are assignments that use/assign to model variables/parameters so if you want to use stuff in a forcing function it should be declared as such, somewhere in the model.
For one thing it is slightly more complicated to parse and extract the parameters in an arbitrary expression, compared to a kinetic equation (where the reagents/variables are specified).
So, in short, consider forcing functions to be rules you apply to existing model (global) elements. Make sense?


python3 GroundSystem.py depends on PyQt5 and PyQt5 won't install in linux 20.04.06

I've followed every possible hint on substack I could find and could not install PyQt5, the last
thing I tried the installer started kicking out  a stream of "y" characters.
$  pip install PyQt5 --verbose
yes
y
y
y
...
Is it possible to update to PyQt6?
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

nevermind, exited and reentered my user account and problem went away


WSL does not install. But comes with useless error messsag.

Windows Version
Microsoft Windows [Version 10.0.19045.4894]
WSL Version
Unknown
Are you using WSL 1 or WSL 2?

[ ] WSL 2
[X] WSL 1

Kernel Version
unknown
Distro Version
Ubuntu
Other Software
It does not install.
Repro Steps
I have tried to install WSL on well patched Windows 10 and Windows 11 machines.
Both via command line and through menues. It fails to complete install.
Expected Behavior
WSL is installed.
Actual Behavior
WSL is only half way installed.
It does not show up in Programs and features, but WSL detects that WSL is installed when I try again.
Alvorlig feil = Serious Error.
Error level = -1

Diagnostic Logs
WslLogs-2024-09-18_11-42-12.zip

I installed the update according to https://learn.microsoft.com/en-us/windows/wsl/install-manual#installing-your-distro
That ensured that I got an error message  that could be googled.
An error occurred during installation. Distribution Name: 'Ubuntu' Error Code: 0x8000ffff

I read here in a case with the same error  that installing Ubuntu as a normal user without elevation worked.
I would never have guessed and I'm disappointed that the WSL program does not point out that fact. I'm also disapointed that the WSL was not update through the normal patching process.