text:
feat: the Fourier transform of a Schwartz function is differentiable

maintainer merge

bors merge

authors: mcdoll ocfnash sgouezel


text:
chore(RingTheory.Binomial): add nsmul_right_inj to simplify some proofs

Nice clean-up, thanks!
maintainer merge

Thanks :tada:
bors merge

source: gharchive/pull-request

authors: Ruben-VandeVelde grunweg jcommelin

license_type: permissive

license_source: github-api


text:
feat: Decidability of curry/uncurry

Match https://github.com/leanprover-community/mathlib/pull/18366

Closing, see comment on the mathlib3 PR.

authors: YaelDillies semorrison


text:
feat: port CategoryTheory.Category.Bipointed

bors merge

authors: Parcly-Taxel semorrison


text:
feat: port FieldTheory.Finiteness

bors merge

I guess the conflict would be with #3372.

bors merge

bors merge


text:
feat: restore positivity extension for ℝ≥0∞

bors merge

authors: semorrison urkud


text:
refactor: generalize PiLp to WithLp

The motivation is to be able to reuse this for ProdLp in #6136.
This matches the pattern of how the Lex type synonym is used.

I think this is a nice refactor, but it would be good if someone else had eyes on it too. Zulip thread

bors d+
Thanks!

bors merge

authors: eric-wieser j-loreaux sgouezel


text:
chore: bump dependencies

Ugh. Closing and trying again later.


text:
feat(data/polynomial): polynomial.comp

Also move degree_pos_of_root from integral_domain section to comm_ring.
TO CONTRIBUTORS:
Make sure you have:

[x] reviewed and applied the coding style: coding, naming
[x] make sure definitions and lemmas are put in the right files
[x] make sure definitions and lemmas are not redundant

For reviewers: code review check list

@digama0 Looks good to me.

repo: leanprover/mathlib


text:
Note to self 1: Need to add pictures of speakers, panelists, and organizers

Hi

Added. :)

source: gharchive/issue


text:
invalid banner check

Hi,
I'm scanning a version of libssh which is known as vulnerable and I get the following output:
[*] 127.0.0.1:22 is not vulnerable to authentication bypass (SSH-2.0-libssh_0.7.5)
Strangely, the banner does not match because of the _ instead of -.
From what I see in libssh code (libssh/include/libssh/priv.h), the banner is "SSH-2.0-libssh_" SSH_STRINGIFY(LIBSSH_VERSION), so I suppose the scanner should be updated to match an underscore instead of the dash.
After doing the modification, the scanner properly detects the server as "likely VULNERABLE".
By the way, in aggressive mode, the server is seen as not vulnerable, can it be because of the server configuration?

Should be fixed in the latest version, libssh-scanner 1.0.3. Try again and let me know.

Hi,
The banner with underscores is properly detected now, thanks.

Awesome thanks!

repo: leapsecurity/libssh-scanner

license: MIT


text:
Kubernautic is no longer there

I wanted to check out Kubernautic, i see their socials but i dont think this is still operational.
See https://downforeveryoneorjustme.com/kubernautic.com?proto=https

removed

authors: bizmate salaboy


text:
[iOS] the picture empty issue

[iOS]
"react-native": "0.41.2",
"react-native-swiper": "^1.5.4"

Hi, everyone. There are some issues when I use this Component.
I use this component to create a picture carousel, this carousel was infinite scroll, and this picture was able to click to a new page.
When I click to a new page by this picture , wait for some seconds and go back. The picture might be empty.
So have anybody know how to resolve this issue?

adding the removeClippedSubviews={false} prop to Swiper resolve this issue.

repo: leecade/react-native-swiper

license: mit

license_source: bigquery


text:
GUI 수정 및 개선

기존 계산기의 GUI를 수정 및 개선한다.

[ ] 숫자 입력/표시 부분 통합
[ ] 새 버튼 추가
[ ] 전체적인 로직 변경  (GLineEdit이용)


text:
HTML is not working in forwarded email

Hi, I'm loving this project. But I encountered an issue when I forwarded the email. HTML is not working as expected. Anyone faced this issue? Do you have any workaround to this? Appreciate your response. Thanks!

You don't forward newsletter. Because, depending on the client you use, it may crop important part of the mail. Outlook typically erase the css/responsive part, also adding custom formatting to the text that may alter the graphic you intended.

Yeh I'm afraid there's nothing can be done about this AFAIK. Forwarding HTML breaks depending on the client.

authors: akosijiji leemunroe logovitta


text:
test

prova per isr!

prova chiusura

repo: leerob/on-demand-isr


text:
Data not being updated frequently

Hi,
I've just installed your alfen_wallbox integration with HACS, I'm able to create the initial connection to my Eve Single Pro-line with firmware 6.4.0-4210, Entities will get the actual values.
Home Assistant version: 2024.9.1
HACS version: 2.0.1
After adding a bunch of entities to my dashboard, it looks like the data is not being updated. this is confirmed by looking at a random entity made by this integration, the 'last update' timer just keeps running up.
I can see an error in the logs:
Updating alfen_wallbox sensor took longer than the scheduled update interval 0:00:05
Looks like its running to fast,
strange thing is, I changed the update interval to a value of 30 seconds as a test. error log still says it's configured as 5 seconds.

nevermind, same as
https://github.com/leeyuentuen/alfen_wallbox/issues/124


text:
C++'s First New Floating Point Types in 40 years!

https://en.wikipedia.org/wiki/Half-precision_floating-point_format
https://en.wikipedia.org/wiki/Bfloat16_floating-point_format
https://en.wikipedia.org/wiki/IEEE_754
https://en.cppreference.com/w/cpp/types/floating-point
https://en.cppreference.com/w/cpp/header/stdfloat
https://compiler-explorer.com/z/oasbMxnYh

C++ is the only language people can complain about how it evolves very fast and very slow /hj

Coming in Episode 433

authors: fcolecumberri lefticus

license: Unlicense


text:
client.getDiscoItems is not a function

Hi, I have included stanza.bundle.js as it is , in my Index.html file. And using it in my Angularjs Controller as follows..
I m able to create client and send message. But unable to access functions like getDiscoItems , searchHistory etc...
<body ng-app="app">
<div ui-view></div>
</body>
<script type="text/javascript" src="./js/app.min.js"></script>
<script type="text/javascript" src="./js/stanza.bundle.js"></script>

and Controller is:
angular.module('login', []).config(function($stateProvider) {

    $stateProvider.state('login', {
        url: '/login',
        templateUrl: 'login/login.tpl',
        controller: 'LoginCtrl'
    });
}).controller('LoginCtrl', function($scope, Constants) {
    console.log("inside LoginCtrl");
    console.log("Constants", Constants.APP_URL);

    var client = XMPP.createClient({
        jid: 'sandy@localhost',
        password: 'password',

        // If you have a .well-known/host-meta.json file for your
        // domain, the connection transport config can be skipped.

        transport: 'websocket',
        wsURL: 'ws://localhost:5280/ws-xmpp/'
            // (or `boshURL` if using 'bosh' as the transport)
    });

    client.on('session:started', function() {
        console.log("In session started");
        client.getRoster();
        client.sendPresence();

    });

    client.on('chat', function(msg) {
        console.log("Received Message",msg);
        alert(msg.body);
    });

    client.connect();

    $scope.sendMessage = function(message) {
        console.log("inside send message", $scope.message);
        var message = $scope.message;
        client.sendMessage({
            to: 'himanshu@localhost',
            body: message
        });
    }

client.getDiscoItems('muc@localhost','', (err, data) => {

    })();

    console.log("inside XMPP", client);
});

You are trying to use getDiscoItems before you are connected

Sandeep,
How did you managed to build stanza.io

authors: abador nitinmukesh sandeepgujela


text:
🛑 VePhim API hf is down

In a8d5563, VePhim API hf (https://api.vephim.online/api/ping) was down:

HTTP code: 0
Response time: 0 ms

Resolved: VePhim API hf is back up in 7ee12b1 after 9 minutes.


text:
[request] ipad portrait support

love the app, would love ipad portrait support :smile:

thx!

repo: leichunfeng/MVVMReactiveCocoa


text:
wazero: updates to latest with a little polish

Sorry not entirely sure about the index out of bounds thing on make run, but hope this helps!

ps on the error:
Wasm File: basic.wasm
Func: view
Params: [u32(6)]
Error: wasm runtime error: runtime error: index out of range [4294967295] with length 0
wasm backtrace:
	0: vec_get
	1: unknown

So, there are two problems at that call site:
		"vec_get": func(v val.Val, i val.Val) val.Val {
			vec := h.Objects.GetVec(v) // << this is nil
			idx, err := val.ToU32(i) // << this returned 2^32-1
			if err != nil {
				panic(err)
			}
			return vec[idx] <-- so this panics because the nil vectoris being asked for element 4294967295

Hope this helps!

ps latest wazero is a looot smaller on amd64
before:
8504	build/sjc

after:
6488	build/sjc

See https://github.com/tetratelabs/wazero/pull/427 for API changes

Hi @codefromthecrypt! Thank for the help fixing these issues and love the development of wazero, especially the broad compatibility with the interpreter. I'm rewriting this tool to run on Deno to get at some other dependencies I want to include that exist in the NPM ecosystem, so won't need to merge this.

authors: codefromthecrypt leighmcculloch

repo: leighmcculloch/sjc


text:
npm repo is outdated

version 0.4.2  is the latest on npm, can we get an update?

Sorry probably won't be updated for a few weeks. Best way would be to use the sha you want in package.json:  git://github.com/lelandrichardson/react-native-maps#faa19067fd59169b1dcd3eea43f3051a6edbee1c

npm install lelandrichardson/react-native-maps works as well :)
I just wanted to report incase you guys weren't aware!

authors: allthetime jrichardlai

repo: lelandrichardson/react-native-maps


text:
possible bug in is_valid_false_atom

The is_valid_false_atom assigns the result of the check to a 32 bit value and cheks if it's 0;
false has 5 characters so the check only covers if it's a valid fals atom, for example falsy would also pass the check in question.

Thanks. I will work on this.

FWIW: I found that using a 64 bit error value instead of a 32 bit one solves the issue. but I'm not sure about the negative impact on the performance of that.

I'm not sure about the negative impact on the performance of that

I have not measured it, because I expect that there won't be any impact. It is going to be the same number of instructions (I expect).
Anyhow, if you have a document where parsing "false" atoms is the bottleneck... it is going to be a fun document.

Let us close this.

The new code might actually be faster...
https://godbolt.org/z/ORcNo5
I'll do a performance comparison later but I am confident that there won't be a regression and there might be a small gain. In any case, it is bug fix so it is not like we can have a choice. We can't leave the old code.

authors: Licenser lemire

repo: lemire/simdjson


text:
feat: Add useCreateMirror hook (T-1339)

Adds a new useCreateMirror hook to the @lens-protocol/react package
Adds an example of mirroring a publication to the web-wagmi example
Introduces a PublicationCacheManager to abstract from responders the exact way to update Publication cache
Adds documentation for useCreateMirror https://dash.readme.com/project/lensprotocol/v1.1/docs/use-create-mirror

link T-1339

Link T-1339

Link T-1339

repo: lens-protocol/lens-sdk


text:
Pod status is wrong when pod is being terminated

Describe the bug
Pod shows "Container creating" status when pod is being terminated.
To Reproduce
Scale down deployment via terminal and watch pod list view/status column.

I've noticed this as well during a release deployment today.

I've noticed this as well during a release deployment today.

I can verify this is true.
Cluster
v1.19.10+k3s1
Lens
Lens: 4.2.2
Electron: 9.4.0
Chrome: 83.0.4103.122
Node: 12.14.1

@cristianorvf Are you able to provide an screenshot, we don't (or no longer) have the text "Container creating" in our repo and I cannot seem to reproduce this.

@cristianorvf Are you able to provide an screenshot, we don't (or no longer) have the text "Container creating" in our repo and I cannot seem to reproduce this.

Hi @Nokel81, of course.
Cluster software: v1.19.10+k3s1 installed via k3sup with no options (vanilla)
Video os lens:
Video of command line:

MD5 (Lens-4.2.2.dmg) = 805fa36e14f91f761519a2d152953e22

Almost certainly a UI thing, since we generate those strings. Thanks for the reproduction steps.

authors: Nokel81 cristianorvf jakolehm jgrasett

repo: lensapp/lens


text:
Add the ability to track any qualities, not just favours

I like your favour tracker feature, and I want to extend that to track anything. This can be useful in carousels (in Port Carnelian, tracking Striped Delights, Silver Horseheads, Imperial Legitimacy, and Time Passing in Office), and in longer term grinds (tracking Estimable Trophies when going for Defender of Public Safety).
I've made this change myself, and I've been using it for a few months, it's been really helpful for me. I'll add it as a pull request. I'm not very familiar with github and contributing to open source software, so hopefully this is the way you'd like me to do this.

I'll list all the shortcomings I can think of with my current solution, so you can say if you want me to fix it, if you can fix it, or if it's fine and not worth fixing. I've been using it myself for months, though, so I think it's good enough to be useful.

You can't start tracking anything you currently have 0 of. The only ways around this would be for small mercies to maintain a list of every item and quality in the game (yuck), or have the user type it in. Typing it in might work, but the user would need to know the quality's category (eg Silver Horseheads are 'Story', Antique Mysteries are 'Elder').
The user input boxes are ugly. I'm no good at making UIs look nice.
It would be nice to be able to reorder the values without having to remove them all and readd them in the new order.
It can't track CP. I use it to track Making Waves, but knowing I'm at 16 and my target is 17 is less useful than knowing I'm at 16 and 10 CP. I don't see anywhere that CP is visible to Small Mercies, so I don't know if there's any way to improve on this.

Awesome! I knew that procrastinating enough on that feature would force someone to start implementing it 🤣 On a more serious note, I will take a look at your PR as soon as possible and will provide feedback.
Concerning the points that you've raised:

Having a hardcoded list of every quality is not as yucky as it may seem, as beggars can't be choosers. We can certainly use Fallen London Wiki API to extract and compile said list, especially since its admins are quite open to helping fan projects. But let's file it under the "nice to have" category for now. "Good enough" at the current moment would be something like a placeholder with a "question" image, which would anyway be replaced the moment we get information about that quality from the backend. Knowing a specific category is not really that useful, as collisions between quality names are very rare (maybe even non-existent?).
Do not concern yourself with the UI intricacies, this we can easily polish later. For the moment my main concern with your approach is that it clashes with the already-established convention that all configuration happens on the "Settings" page. Seeing as the name remains the primary way to describe some quality, I believe that we can replace those input boxes with a single text area on the said screen.
Each line would describe a single quality, allowing the user to easily rearrange them and/or share them with their friends as a single block of text.
While there is indeed no way to obtain a specific number of CP points for a current quality level, we can use progressAsPercentage attribute which is served by the backend as a stand-in, if only for displaying the appropriate progress bar state. The current version does not support accessing that value, but adding support for it is trivial (maybe I will do it myself so you can rebase the code and use it).

I will leave further comments on the PR itself, but I am grateful already for the work that you've done!

One other concern that I have is that it does not play well with the current Favour Tracker, in the sense that it replaces it completely with no option to switch to it. Either this feature should be its replacement (with a Favours being a default pre-set of tracked qualities), or a way to switch between different tracker panes should be established.

Does it not work with Favours for you? I haven't seen a problem, what happens when you try?

Hey everyone,
I really like the idea, in fact I already worked on something similar where the qualities are shown below the main text body but above the storylets / branches. My intention was to hardcode a few wheel-tracking qualities and add more later on this way. I'll share screenshots once I'm back from vacation. Excited to see you working on this!

@AnteIndustrial You misunderstood, I was talking about how this feature will conflict with the existing Favour Tracker. It is not removed in your PR, so I assumed that was intentional. In its current form, both features will add their tracker panels in the same space and it does not make sense since your tracker technically supersedes mine.
I would suggest you remove the existing FavourTrackerMixin and set the Favour list as the default one. In this way people will still get the experience they are used to, but with an option to customize it.

@fynngodau While I like the idea itself, moving trackers on top of branches eats up a lot of useful space IMO. Moving them into the right sidebar like the Favours will make more sense, as they fulfill the same function.
Would you mind if I implement this feature in the form mentioned above? With full attribution to you as the author of the idea, of course.

That is cool, and it's the sort of thing I was thinking of doing. However, it seems like the devs may be adding that sort of thing to the game officially. They've added a tracker for zeefaring, lab research, Naga advertising, and a couple of other areas.

@AnteIndustrial I think that is not actually the same and may have advantages over the native solution:

Devs seem to be intent on working with what they have, namely the left sidebar which is already quite overloaded (especially for the endgame players).  Displaying those qualities more prominently on the right should offer more ease for an at-a-glance appraisal of your current situation.
Not all qualities relevant to the situation are being displayed due to the aforementioned cramped circumstances. E.g. at the Zee it would be also nice to have "Troubled Waters" and your current Pursuit status displayed (when you have Corsair colors).

Time will tell if they will extend first-class support for things such as Moulin expeditions and Hearts' Game, but adding support for them here would be easy enough once the initial framework is laid in place.
@AnteIndustrial I will probably create the necessary scaffolding for a more streamlined usage of the right sidebar in the coming days, so you are free to play with it. Or I can take this over and credit you as the author of the initial version. Your call :)

Typescript, UI, and Chrome extensions are all outside my usual comfort zone, so if you want to take over that's fine with me. I've been having some headaches moving the setup into the settings menu.

@lensvol I agree that the official implementation on the left sidebar increases the clutter there. It's not a place to keep an eye on constantly due to the many qualities that tend to stay the same most of the time. Let me share some more thoughts regarding the right sidebar:

I personally have the snippets enabled, so the qualities on the right sidebar are very much on the bottom and I wouldn't be able to keep an eye on them. For this reason, I don't use them much. We could consider moving the right sidebar qualities above the snippet.
My idea for reducing space usage with the layout I proposed would be to place multiple fitting qualities next to each other, like so:Elaboration    |     Backstory
Nuance | Witness | Credentials

However I do get that this still uses up space, and especially on mobile it would mean that one has to scroll up and down even more.
The right sidebar is, however, not available on mobile.
My personal reason why I chose the spot at the top was that I also intended to add some more "texture" to the different in-game locations so that it feels more unique to be in a certain place.

…but if it's not viable to have it at the top, we can of course put all this on the sidebar as well. Naturally, you are free to use the above suggestions and the code I linked (it contains some extensions to matchers.ts that may be of interest to you, as well), though I would be happy to hear your thoughts and further collaborate with you as well.

Or I can take this over and credit you as the author of the initial version. Your call :)

So, I said you could take over... but I've been working on a different change, and it required me to go into settings, and after mucking around with that for a day or two I felt confident enough to move this lot into settings too. I've updated my pull request with that commit. I should be clear: it's a bit messy, and there's a good chunk of code duplication, because now misc_tracker.ts and settings.ts have to do similar things, but it's just slightly different enough that I couldn't easily remove all duplication. Also, if I removed duplication and just had one, eg, private createTracker(title: string): HTMLElement, I'm not sure whether that should go in misc_tracker or settings, and I thought I'd leave that decision up to you.
I dunno, let me know what you think about the current state. I think it's all working, I tried to break it a few ways, but it seems functionally good, it's just messy and duplicated.

@AnteIndustrial Cool! I've been away on vacation without my laptop for a week, so no work got lost on my end. :)
I will take a look a bit later and see how it looks.

authors: AnteIndustrial fynngodau lensvol

repo: lensvol/fl-small-mercies


text:
ETIMEDOUT вне России.

При попытке использования API на сервере Heroku выдаёт ошибку ETIMEDOUT. Из России всё работает, на Heroku ни США, ни Европа не срабатывают. user.diary() зависает до момента краша с вышеуказанной причиной.
OS: Linux 64bit
Node.js version: 18.1.0.
VPN, антивирусов, прокси и прочих источников gayтовских зараз нет.

Свежий лог:
2022-05-25T19:14:57.416838+00:00 app[web.1]:  ERROR  Ошибка в коде привела к закрытию сессии.
2022-05-25T19:14:57.419141+00:00 app[web.1]: FetchError: request to https://giseo.rkomi.ru/webApi/addresses/schools failed, reason: connect ETIMEDOUT 91.227.95.98:443
2022-05-25T19:14:57.419142+00:00 app[web.1]:     at ClientRequest.<anonymous> (/app/node_modules/node-fetch/lib/index.js:1491:11)
2022-05-25T19:14:57.419143+00:00 app[web.1]:     at ClientRequest.emit (node:events:527:28)
2022-05-25T19:14:57.419144+00:00 app[web.1]:     at TLSSocket.socketErrorListener (node:_http_client:454:9)
2022-05-25T19:14:57.419144+00:00 app[web.1]:     at TLSSocket.emit (node:events:527:28)
2022-05-25T19:14:57.419145+00:00 app[web.1]:     at emitErrorNT (node:internal/streams/destroy:157:8)
2022-05-25T19:14:57.419145+00:00 app[web.1]:     at emitErrorCloseNT (node:internal/streams/destroy:122:3)
2022-05-25T19:14:57.419146+00:00 app[web.1]:     at processTicksAndRejections (node:internal/process/task_queues:83:21) {
2022-05-25T19:14:57.419148+00:00 app[web.1]:   type: 'system',
2022-05-25T19:14:57.419148+00:00 app[web.1]:   errno: 'ETIMEDOUT',
2022-05-25T19:14:57.419148+00:00 app[web.1]:   code: 'ETIMEDOUT'
2022-05-25T19:14:57.419149+00:00 app[web.1]: }

Это нормально, дело в том что сервера сго локально расположены и до них пинг большой

А такая ошибка происходит постоянно?

Постоянно.

Это нормально, дело в том что сервера сго локально расположены и до них пинг большой

40 секунд - это нормально?

Постоянно.

Понятно, сейчас посмотрю, что с этим можно будет сделать.

Администраторы твоего  сайта - молодцы.
Твой код не работает на хероку из-за проверки ip.
Я попробовал использовать прокси русских  серверов и на страницах апи выдается это

Если интересно, то вот полный список реплик
"То, что вы хотите, нету.",
"URL неправильный.",
"Я даже попробовал поглядеть рядом.",
"Нет ничего похожего.",
"А случайно не перепутали с http://www.elemanrf.ru",
"Как жаль, что нет ...",
"Послушайте, я всего лишь скромный веб-сервер.",
"Я ничего не знаю. Я никого не видел.",
"У меня даже нет ушей, чтобы слышать.",
"Я в глубокой депрессии.",
"Ну откуда я знаю, что вы хотите от меня?",
"Вы что, действительно считаете, что я могу догадаться?",
"Ну когда вы уйдете?",
"Тут ничего нет.",
"Честно.",
"Я сейчас заплачу ...",
"Не издевайтесь над бедным веб-сервером!",
"Ну не виноват я, что странички нет.",
"Ой, как мне плохо ...",
"Ну что, вы все еще тут?",
"О, а у меня идея!",
"Попробуйте вместо http: указать https:",
"Здорово, да?",
"Да, наверное было бы здорово, если у меня был бы SSL.",
"Смешная шутка, да?",
"Ну и ладно.",
"Я тут у соседних серверов поспрашивал.",
"Такого URL у них тоже нет.",
"Поверьте мне!",
"Мне очень жаль.",
"Я знаю, это моя работа - отдавать вам запрашиваемые страницы.",
"И я по мере сил стараюсь выполнять свою работу хорошо.",
"У меня хорошие администраторы.",
"Поверьте мне!",
"Послушайте, а у меня тут есть другие страницы.",
"Хорошие... с аниме...",
"Не интересуетесь?",
"Жаль.",
"Может быть, картинки?",
"Жаль. Очень жаль.",
"Ой, подождите, а я такой анекдот знаю!",
"В Интернет-клуб врывается взерошенный парень с пистолетом:", "- Это ограбление! 10 часов Интернета, быстро!","Понравилось?",
"Ой, ко мне кто-то еще пришел.",
"Извините, я вас оставлю на секундочку...",
"Но на последок скажу вам одну мудрую вещь:",
"Смеётся тот, кто смеётся без последствий.",
"Прощайте!"

Хе-хе. Не ожидал от сомнительного сайта на aspx такой защиты. Спасибо, буду искать VPN.

Закрывать?

repo: lentryd/NetSchoolApi


text:
Deprecate pkg_resource.read_text

========================================================================================================== warnings summary ==========================================================================================================
tests/download/test_list_names.py::test_list_names[case0]
  /Users/leonlan/Dropbox/cvrplib/vrplib/download/list_names.py:52: DeprecationWarning: read_text is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy for migration advice.
    fi = pkg_resource.read_text(__package__, "instance_data.csv")

tests/download/test_list_names.py::test_list_names[case0]
  /opt/homebrew/Cellar/python@3.11/3.11.3/Frameworks/Python.framework/Versions/3.11/lib/python3.11/importlib/resources/_legacy.py:80: DeprecationWarning: open_text is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy for migration advice.
    with open_text(package, resource, encoding, errors) as fp:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html

---------- coverage: platform darwin, python 3.11.3-final-0 ----------
Coverage XML written to file coverage.xml

=================================================================================================== 86 passed, 2 warnings in 3.39s ===================================================================================================
leonlan@Leons-Air cvrplib %

I don't have this warning anymore.

repo: leonlan/VRPLIB


text:
chore(setup): update python version range limitation, update install script with quote to fit zsh env

update python version range
update install script with quote to fit zsh shell

Thanks! Giving the fact that pytorch doesn't support 3.12 yet I think this makes sense.

authors: Yangqing sjy

repo: leptonai/leptonai


text:
Can't watch or serve new project after running cargo update

Expected Behavior
Expected to be able to run cargo leptos watch in a new project
Actual Behavior
Getting a thread panicked error
Steps to Reproduce the Problem

cargo install cargo-leptos
cargo leptos new --git https://github.com/leptos-rs/start
cd [your project name]
cargo update
cargo leptos watch

Specifications

Version: 0.1.0
Platform: Linux
Subsystem: Arch
Stack trace:

  RUST_BACKTRACE=1 cargo leptos watch
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
       Cargo finished cargo build --package=leptos_start --lib --target-dir=target/front --target=wasm32-unknown-unknown --no-default-features --features=hydrate
thread 'tokio-runtime-worker' panicked at 'index out of bounds: the len is 0 but the index is 0', /home/eran/.cargo/registry/src/github.com-1ecc6299db9ec823/wasm-bindgen-cli-support-0.2.83/src/descriptor.rs:208:15
stack backtrace:
   0: rust_begin_unwind
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/core/src/panicking.rs:64:14
   2: core::panicking::panic_bounds_check
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/core/src/panicking.rs:147:5
   3: wasm_bindgen_cli_support::descriptor::Descriptor::_decode
   4: wasm_bindgen_cli_support::descriptor::Function::decode
   5: wasm_bindgen_cli_support::descriptor::Descriptor::_decode
   6: wasm_bindgen_cli_support::descriptors::execute
   7: wasm_bindgen_cli_support::Bindgen::generate_output
   8: cargo_leptos::compile::front::front::{{closure}}::{{closure}}
   9: tokio::runtime::task::core::Core<T,S>::poll
  10: tokio::runtime::task::harness::Harness<T,S>::poll
  11: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
  12: tokio::runtime::scheduler::multi_thread::worker::Context::run
  13: tokio::macros::scoped_tls::ScopedKey<T>::set
  14: tokio::runtime::scheduler::multi_thread::worker::run
  15: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
  16: tokio::runtime::task::core::Core<T,S>::poll
  17: tokio::runtime::task::harness::Harness<T,S>::poll
  18: tokio::runtime::blocking::pool::Inner::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Error: task 17 panicked

I found the output of cargo update
 ╰─λ cargo update
    Updating crates.io index
    Updating git repository `https://github.com/leptos-rs/leptos`
    Removing bincode v1.3.3
    Removing doc-comment v0.3.3
    Updating encoding_rs v0.8.31 -> v0.8.32
    Updating js-sys v0.3.60 -> v0.3.61
    Updating leptos v0.1.3 (https://github.com/leptos-rs/leptos#e2b1365e) -> #e380097a
    Updating leptos_actix v0.1.3 (https://github.com/leptos-rs/leptos#e2b1365e) -> #e380097a
    Updating leptos_config v0.1.3 (https://github.com/leptos-rs/leptos#e2b1365e) -> #e380097a
    Updating leptos_dom v0.1.3 (https://github.com/leptos-rs/leptos#e2b1365e) -> #e380097a
    Updating leptos_macro v0.1.3 (https://github.com/leptos-rs/leptos#e2b1365e) -> #e380097a
    Updating leptos_meta v0.1.3 (https://github.com/leptos-rs/leptos#e2b1365e) -> #e380097a
    Updating leptos_reactive v0.1.3 (https://github.com/leptos-rs/leptos#e2b1365e) -> #e380097a
    Updating leptos_router v0.1.3 (https://github.com/leptos-rs/leptos#e2b1365e) -> #e380097a
    Updating leptos_server v0.1.3 (https://github.com/leptos-rs/leptos#e2b1365e) -> #e380097a
    Updating parking_lot_core v0.9.6 -> v0.9.7
    Updating proc-macro2 v1.0.50 -> v1.0.51
    Removing rmp v0.8.11
    Removing rmp-serde v1.1.1
    Updating serde_json v1.0.91 -> v1.0.92
    Updating tinyvec_macros v0.1.0 -> v0.1.1
    Removing uuid v1.2.2
    Updating wasm-bindgen v0.2.83 -> v0.2.84
    Updating wasm-bindgen-backend v0.2.83 -> v0.2.84
    Updating wasm-bindgen-futures v0.4.33 -> v0.4.34
    Updating wasm-bindgen-macro v0.2.83 -> v0.2.84
    Updating wasm-bindgen-macro-support v0.2.83 -> v0.2.84
    Updating wasm-bindgen-shared v0.2.83 -> v0.2.84
    Updating web-sys v0.3.60 -> v0.3.61
      Adding windows-sys v0.45.0
      Adding windows-targets v0.42.1

Closing as a duplicate of https://github.com/leptos-rs/leptos/issues/479

authors: eboody gbj

repo: leptos-rs/start


text:
🛑 Mini (A literal Mac Mini) is down

In 2141faa, Mini (A literal Mac Mini) ($MINISERVER_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mini (A literal Mac Mini) is back up in 2f1fa11 after 32 minutes.

repo: lerndmina/uptime


text:
Abandoned?

We wanted to use this library, but it feels like this library is abandoned? Is there an alternative?

What specifically? You mean the plugin?

yes i mean this plugin. :)

What specifically? You mean the plugin?

Is there a way to update the dependecies and create a new release? This would be create, because this plugin includes clean-css which has the CWE-1333 and this could have been fixed with a new release and updated libraries or? All version of clean-css < 4.1.11 are affected.

Go ahead and create a PR if you wish!

here you go #37 :)

repo: less/less-plugin-clean-css


text:
Does not work on dotfiles starting with .git

Describe the bug
Opening any file starting with .git  prevents this plugin from loading because of the following matching:
https://github.com/lewis6991/gitsigns.nvim/blob/eac60ec72d1f9222ba978754da65dfd2901441f1/teal/gitsigns.tl#L190-L193
This should probably be a bit stricter considering git services uses this for prefix for configurations.
To Reproduce
init.vim:
let $PLUGIN_DIRECTORY = '~/.config/nvim/bundle'
set runtimepath^=$PLUGIN_DIRECTORY/plenary.nvim
set runtimepath^=$PLUGIN_DIRECTORY/gitsigns.nvim

lua << EOF
require('gitsigns').setup {
  debug_mode = true, -- You must add this to enable debug messages
  -- config
}
EOF

Steps to reproduce the behavior:

Create a new file with the name of ex .gitlab-ci.yaml with some basic content (below)
Commit
Open
Nothing happens

faefea:
  FOO=bar

Observed output
run_job: git --no-pager --version
attach(1): Attaching
run_job: git --no-pager config user.name
run_job: git --no-pager rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --git-dir=/tmp/foo/.git ls-files --stage --others --exclude-standard /tmp/foo/.gitlab-ci.yaml
attach(1): In non-standard git dir
attach(3): Attaching
attach(3): Non-normal buffer

Additional context
System: Linux
Neovim version: compiled freshly before posting this issues

Thanks!


text:
Scroll or jump into hunk preview window

Sometimes I have quite big diffs that span more than the height of the current window. It would be great if there was either a way to jump into the floating preview window, or scroll through it with some key mapping.
Jumping into the window could be done if preview_hunk is called a second time with the window still being visible, that would also allow copying some code etc.
Scrolling would need either a conditional remap of default key mappings like <c-u> and <c-d> that otherwise just propagates to the default action.

Use <C-w>W to focus onto the window.

Oh wow, I didn't know about that. Thanks!


text:
_Cache.values returns insertion order, not time order.

import heavylight
class Non_T_Model(heavylight.Model):
    def get_a(self, a):
        return a * 10

ntm = Non_T_Model(proj_len=10):
ntm.get_a(5)
ntm.get_a(10)
ntm.get_a(7)

After this, ntm.get_a.values will return [50, 100, 70].
I don't think this is a big issue, as it is unlikely that non t functions are likely to have an order, however it might cause issues.
Aside: I've added a keys property, e.g. ntm.get_a.keys which is aligned to the values.

Also added _Cache.df which returns a dataframe.
Changes are on https://github.com/lewisfogden/heavylight/tree/dev_core as they are breaking.

I'm happy with this, but need to document before closing.

repo: lewisfogden/heavylight


text:
WIP: Find correspondences across several datasets

This is a work in progress, do not merge.
Things to do:

[ ] The code currently relies on a hard coded list of datasets, and fakes the lexicore interface. This is a temporary way to not be dependent on the timeline for lexicore. Instead, replace by actual lexicore.
[ ] Implement alternatives to genera to find sub-groups in each family
[ ] Use a better cognate detection method
[ ] Maybe implement something to have a coarser sound classification than BIPA

How do I call the code, can you give an example?

Sure, it is pretty similar to what you originally wrote:
cldfbench lexitools.correspondences --model asjp --cutoff 2 --threshold 1 --concepts Holman-2008-40

--model can be "asjp" or "bipa" (this is used to downscale phonemes)
--concepts limits to a list of concepts. Here using Holman-2008-40
--cutoff lets you pick how many times a correspondence must appear to be kept
--threshold is the similarity threshold between pairs of words

This will run on several datasets. To run on a single dataset:
cldfbench lexitools.correspondences --model asjp --cutoff 2 --threshold 1 --concepts Holman-2008-40 --dataset asjp

I think "asjp" is the only case where we may want to run it on a single dataset.

Okay, now the question: "several datasets": what are these datasets, all
those that are installed? or how do you determine them?

As I said above, this is what simulates "lexicore" (the --dataset argument defaults to "lexicore"). I implemented this before lexicore was ready, and needed something which would more or less run on the same set of datasets, and be easily swappable with the real lexicore interface once lexicore is ready. This is not code that is intended to stay, it is merely a work around to make sure the sound correspondence work can go forward as much as possible without waiting for the technical details of lexicore. As soon as lexicore is ready I can very easily swap it in.
The list I have currently is the below, which I got from the google sheet. Some datasets do not install/read properly.
["aaleykusunda", "abrahammonpa", "allenbai",
                        "backstromnorthernpakistan", "bdpa", "beidasinitic",
                        "birchallchapacuran", "bodtkhobwa", "bowernpny", "cals",
                        "castrosui", "castroyi", "chaconarawakan",
                        "chaconbaniwa", "chaconcolumbian", "chenhmongmien",
                        "chindialectsurvey", "clarkkimmun", "dravlex",
                        "dunnaslian", "galuciotupi", "halenepal",
                        "hantganbangime", "housinitic", "hsiuhmongmien",
                        "hubercolumbian", "ivanisuansu", "joophonosemantic",
                        "lieberherrkhobwa", "listcognatebenchmark",
                        "liusinitic", "marrisonnaga", "mcelhanonhuon",
                        "mitterhoferbena", "mortensentangkhulic",
                        "naganorgyalrongic", "northeuralex", "robinsonap",
                        "sagartst", "savelyevturkic", "sohartmannchin", "suntb",
                        "tppsr", "transnewguineaorg", "tryonsolomon",
                        "vanbikkukichin", "walworthpolynesian", "wangbai",
                        "wichmannmixezoquean", "wold", "yanglalo",
                        "zgraggenmadang", "gerarditupi", "polyglottaafricana",
                        "peirosaustroasiatic", "deepadungpalaung", "zhaobai"]

I think, @XachaB, you can also just merge this for now, I'd then later check quietly and provide updates and other suggestions. The current solution you propose for cloning is okay, I'd say.

authors: LinguList XachaB

repo: lexibank/lexitools


text:
bob74_ipl help

-- Meth lab: 1009.5, -3196.6, -38.99682
exports('GetBikerMethLabObject', function()
    return BikerMethLab
end)

BikerMethLab = {
    interiorId = 247041,

    Ipl = {
        Interior = {
            ipl = "bkr_biker_interior_placement_interior_2_biker_dlc_int_ware01_milo",

            Load = function()
                EnableIpl(BikerMethLab.Ipl.Interior.ipl, true)
            end,
            Remove = function()
                EnableIpl(BikerMethLab.Ipl.Interior.ipl, false)
            end
        }
    },
    Style = {
        none = "",
        empty = "meth_lab_empty",
        basic = {
            "meth_lab_basic",
            "meth_lab_setup"
        },
        upgrade = {
            "meth_lab_upgrade",
            "meth_lab_setup"
        },

        Set = function(style, refresh)
            BikerMethLab.Style.Clear(false)

            if style ~= "" then
                SetIplPropState(BikerMethLab.interiorId, style, true, refresh)
            else
                if refresh then
                    RefreshInterior(BikerMethLab.interiorId)
                end
            end
        end,
        Clear = function(refresh)
            SetIplPropState(BikerMethLab.interiorId, {
                BikerMethLab.Style.empty,
                BikerMethLab.Style.basic,
                BikerMethLab.Style.upgrade
            }, false, refresh)
        end
    },
    Security = {
        none = "",
        upgrade = "meth_lab_security_high",

        Set = function(security, refresh)
            BikerMethLab.Security.Clear(false)

            if security ~= "" then
                SetIplPropState(BikerMethLab.interiorId, security, true, refresh)
            else
                if refresh then
                    RefreshInterior(BikerMethLab.interiorId)
                end
            end
        end,
        Clear = function(refresh)
            SetIplPropState(BikerMethLab.interiorId, BikerMethLab.Security.upgrade, false, refresh)
        end
    },
    Details = {
        production = "meth_lab_production", -- Products

        Enable = function(details, state, refresh)
            SetIplPropState(BikerMethLab.interiorId, details, state, refresh)
        end
    },

    LoadDefault = function()
        BikerMethLab.Ipl.Interior.Load()
        BikerMethLab.Style.Set(BikerMethLab.Style.upgrade)
        BikerMethLab.Security.Set(BikerMethLab.Security.upgrade)
        BikerMethLab.Details.Enable(BikerMethLab.Details.production, false)

        RefreshInterior(BikerMethLab.interiorId)
    end
}

would this be correct if i want the lab to be filled with all the props?

Hi,
I have deleted your paste in the other issue to prevent cluttering, hope that's okay.
The relevant part of the file is the LoadDefault function at the end, I think you also need to set the value for BikerMethLab.Details.production to true to enable some more features. Otherwise it looks good to me.


text:
Promise.fulfill and Promise.reject shorthands

For now the readme says:
Promise.new
  .tap(&:fulfill)
  .then { Promise.new.tap(&:fulfill) }
  .then { Promise.new.tap(&:reject) }
  .then(nil, proc { |reason| p reason })

Last two PRs I've made introduced a change so following is possible:
Promise.new.fulfill
  .then { Promise.new.fulfill }
  .then { Promise.new.reject }
  .then(nil, proc { |reason| p reason })

What about an extra Promise.reject and Promise.fulfill, so following is possible?
Promise.fulfill
  .then { Promise.fulfill }
  .then { Promise.reject }
  .then(nil, proc { |reason| p reason })

Is it ok?

btw. it's also because I often return fulfilled promises like so: Promise.new.fulfill("value")

There is already a Promise.resolve method that works similar to your proposed Promise.fulfill.  The naming is for consistency with javascript's Promise.resolve function
Javascript does have a Promise.reject function, so having one in this library would be appropriate.

authors: dylanahsmith sheerun

license: unlicense


text:
Allow replacing the host url

Feature request.
I am crawling localhost:3000
I want to replace localhost:3000 with the real domain when writing the file.

That sounds useful. Anyone willing to submit a PR for this?

I can take a stab at this next week.

Awesome! 😊

This could be useful. I would want this too.

authors: GerkinDev RayLuxembourg ianwalter lgraubner

repo: lgraubner/sitemap-generator


text:
Allow wizards-0.6

Apparently builds fine: https://bugzilla.redhat.com/show_bug.cgi?id=1195553#c3

Whoops, I see master now.

repo: liamoc/wizards


text:
iOS black frames after launch screen

Issue details
I'm using a storyboard launch screen in my app that then should transition into a Scene2D launch screen which looks the same but with animation. There is almost a second of black screen after the storyboard launch screen disappears and my Scene2D launch screen appears, which is not acceptable (Apple review does reject such glitches).
By using static images for the iOS launch screen the issue goes away with the RoboVM backend.

Static images, robovm backend: seamless transition
Static images, metalangle backend: 1 frame of half rendered half black screen on simulator
Storyboard, robovm backend: several black frames
Storyboard, metalangle backend: about 1 second of black screen on simulator

Probable cause
By design the iOS splash screen fades out once the method didFinishLaunching() of the app delegate returned. At this time the next view controller needs to be setup already.
With libGDX this means that the OpenGL/Metal view needs to have started drawing its content before didFinishLaunching is complete.
Currently the way the iOS backend is setup makes this impossible. The ApplicationListener.create() method as well as the completion of the OpenGL setup are called after didFinishLaunching().
Version of libGDX and/or relevant dependencies
1.11.1-SNAPSHOT
Please select the affected platforms

[ ] Android
[X] iOS
[ ] HTML/GWT
[ ] Windows
[ ] Linux
[ ] macOS

I can't really reproduce the error, for me it opens without any really noticable delay with MetalANGLE + launch storyboard. Maybe my mac is faster? I have a Mac mini M1 2020. Do you maybe have any minimal reproducer project?

At this time the next view controller needs to be setup already.
Is this documented somewhere? Haven't found anything in the apple docs.

Anyhow, by looking through the docs it seems like there would be nothing speaking against hooking up the controller initialization in the willFinishLaunching event (https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623032-application?language=objc). Would you be able to test, whether this fixes the issue for you?

The ApplicationListener.create() method as well as the completion of the OpenGL setup are called after didFinishLaunching().

As far as I understand it, not precisly. They are called during the "didFinishLaunching" callback. Also, according to the docs, "This method is called after state restoration has occurred but before your app’s window and other UI have been presented. At some point after this method returns, the system calls another of your app delegate’s methods to move the app to the active (foreground) state or the background state."
https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622921-application?language=objc
So the app seems to be not expected to have something already drawn, at this point.
But interesting in the code is also this:
	public void viewWillAppear (boolean arg0) {
		super.viewWillAppear(arg0);
		// start GLKViewController even though we may only draw a single frame
		// (we may be in non-continuous mode)
		setPaused(false);
	}

So maybe "setPaused" was working different in GLKit than in MGLKit? But thats also just a random idea, can't test around without being able to reproduce it.

The ApplicationListener.create() method is called during the first draw call of the view controller:
IOSGraphics.java
	public void draw (GLKView view, CGRect rect) {
		...
		if (!created) {
			// OpenGL glViewport() function expects backbuffer coordinates instead of logical coordinates
			gl20.glViewport(0, 0, screenBounds.backBufferWidth, screenBounds.backBufferHeight);

			String versionString = gl20.glGetString(GL20.GL_VERSION);
			String vendorString = gl20.glGetString(GL20.GL_VENDOR);
			String rendererString = gl20.glGetString(GL20.GL_RENDERER);
			glVersion = new GLVersion(Application.ApplicationType.iOS, versionString, vendorString, rendererString);

			updateSafeInsets();
			app.listener.create();
			app.listener.resize(getWidth(), getHeight());
			created = true;
		}
		...

I managed to move all that stuff into the didFinishLaunching method in a local fork to make:
IOSApplication.java
	final boolean didFinishLaunching (UIApplication uiApp, UIApplicationLaunchOptions options) {
		...
		this.uiWindow.setRootViewController(this.graphics.viewController);
		this.graphics.updateSafeInsets();

		Gdx.app.debug("IOSApplication", "created");

		// make sure the OpenGL view has contents before displaying it
		this.graphics.view.display();

		return true;
	}

This entirely removes the black/empty frames after the launch screen. The bigger the app is the longer this "blackout" was, in my case over 500ms. However it is still noticeable in the default libGDX app.
I'm providing a PR with this fix.

Maybe it is cleaner to move the view initialization code into a callback like view[Will/Did]Appear, if this works too?
Those callbacks are called too late. We need to have it within the constructor so everything is setup once ApplicationListener.create() is called.

authors: Berstanio CoderBaron

repo: libgdx/libgdx


text:
chore: release main

:robot: I have created a release beep boop
autonat: 2.0.5
2.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

bootstrap: 11.0.5
11.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

circuit-relay-v2: 2.1.0
2.1.0 (2024-09-25)
Features

add relay server reservation store metrics (#2722) (60f6aa9)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/peer-collections bumped from ^6.0.4 to ^6.0.5
@libp2p/peer-record bumped from ^8.0.4 to ^8.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

dcutr: 2.0.5
2.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devtools-metrics: 1.1.3
1.1.3 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/logger bumped from ^5.0.4 to ^5.1.0
@libp2p/simple-metrics bumped from ^1.2.2 to ^1.2.3

echo: 2.0.5
2.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

fetch: 2.0.5
2.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

floodsub: 10.1.3
10.1.3 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/pubsub bumped from ^10.0.4 to ^10.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0
@libp2p/peer-collections bumped from ^6.0.4 to ^6.0.5

identify: 3.0.5
3.0.5 (2024-09-25)
Bug Fixes

switch informational logging to trace logging (#2727) (442a835)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/peer-record bumped from ^8.0.4 to ^8.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

interface-compliance-tests: 6.1.3
6.1.3 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/logger bumped from ^5.0.4 to ^5.1.0
@libp2p/multistream-select bumped from ^6.0.4 to ^6.0.5
@libp2p/peer-collections bumped from ^6.0.4 to ^6.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

interface-internal: 2.0.5
2.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/peer-collections bumped from ^6.0.4 to ^6.0.5

kad-dht: 13.1.0
13.1.0 (2024-09-25)
Features

add inbound rpc request metrics (#2721) (fa83ee1)

Bug Fixes

reduce dht logging and update metrics (#2725) (80fb47f)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/peer-collections bumped from ^6.0.4 to ^6.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0
@libp2p/peer-store bumped from ^11.0.4 to ^11.0.5

keychain: 5.0.6
5.0.6 (2024-09-25)
Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

logger: 5.1.0
5.1.0 (2024-09-25)
Features

add %e error formatter (#2726) (c5988cc)

mdns: 11.0.5
11.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

mplex: 11.0.5
11.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

multistream-select: 6.0.5
6.0.5 (2024-09-25)
Bug Fixes

switch informational logging to trace logging (#2727) (442a835)

Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

peer-collections: 6.0.5
6.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/utils bumped from ^6.0.4 to ^6.0.5

peer-record: 8.0.5
8.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/utils bumped from ^6.0.4 to ^6.0.5

peer-store: 11.0.5
11.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/peer-collections bumped from ^6.0.4 to ^6.0.5
@libp2p/peer-record bumped from ^8.0.4 to ^8.0.5

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

perf: 4.0.5
4.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

ping: 2.0.5
2.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

plaintext: 2.0.5
2.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

pnet: 2.0.5
2.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

prometheus-metrics: 4.1.3
4.1.3 (2024-09-25)
Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

pubsub: 10.0.5
10.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/peer-collections bumped from ^6.0.4 to ^6.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

simple-metrics: 1.2.3
1.2.3 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

tcp: 10.0.5
10.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

tls: 2.0.5
2.0.5 (2024-09-25)
Bug Fixes

close tls socket on encryption failure (#2724) (9800384)

Dependencies

The following workspace dependencies were updated

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

upnp-nat: 2.0.5
2.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

utils: 6.0.5
6.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0

webrtc: 5.0.7
5.0.7 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/circuit-relay-v2 bumped from ^2.0.4 to ^2.1.0
@libp2p/identify bumped from ^3.0.4 to ^3.0.5
@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0
@libp2p/websockets bumped from ^9.0.4 to ^9.0.5
libp2p bumped from ^2.1.2 to ^2.1.3

websockets: 9.0.5
9.0.5 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/logger bumped from ^5.0.4 to ^5.1.0

webtransport: 5.0.7
5.0.7 (2024-09-25)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/logger bumped from ^5.0.4 to ^5.1.0
@libp2p/ping bumped from ^2.0.4 to ^2.0.5
libp2p bumped from ^2.1.2 to ^2.1.3

libp2p: 2.1.3
2.1.3 (2024-09-25)
Bug Fixes

split error/operation metrics (#2728) (0c59578)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface-internal bumped from ^2.0.4 to ^2.0.5
@libp2p/logger bumped from ^5.0.4 to ^5.1.0
@libp2p/multistream-select bumped from ^6.0.4 to ^6.0.5
@libp2p/peer-collections bumped from ^6.0.4 to ^6.0.5
@libp2p/peer-store bumped from ^11.0.4 to ^11.0.5
@libp2p/utils bumped from ^6.0.4 to ^6.0.5

devDependencies

@libp2p/circuit-relay-v2 bumped from ^2.0.4 to ^2.1.0
@libp2p/identify bumped from ^3.0.4 to ^3.0.5
@libp2p/interface-compliance-tests bumped from ^6.1.2 to ^6.1.3
@libp2p/mplex bumped from ^11.0.4 to ^11.0.5
@libp2p/plaintext bumped from ^2.0.4 to ^2.0.5
@libp2p/tcp bumped from ^10.0.4 to ^10.0.5
@libp2p/websockets bumped from ^9.0.4 to ^9.0.5

This PR was generated with Release Please. See documentation.

:robot: Created releases:

plaintext-v2.0.5
tls-v2.0.5
interface-compliance-tests-v6.1.3
interface-internal-v2.0.5
kad-dht-v13.1.0
keychain-v5.0.6
libp2p-v2.1.3
logger-v5.1.0
devtools-metrics-v1.1.3
prometheus-metrics-v4.1.3
simple-metrics-v1.2.3
multistream-select-v6.0.5
peer-collections-v6.0.5
bootstrap-v11.0.5
mdns-v11.0.5
peer-record-v8.0.5
peer-store-v11.0.5
pnet-v2.0.5
autonat-v2.0.5
dcutr-v2.0.5
echo-v2.0.5
fetch-v2.0.5
identify-v3.0.5
perf-v4.0.5
ping-v2.0.5
pubsub-v10.0.5
floodsub-v10.1.3
mplex-v11.0.5
circuit-relay-v2-v2.1.0
tcp-v10.0.5
webrtc-v5.0.7
websockets-v9.0.5
webtransport-v5.0.7
upnp-nat-v2.0.5
utils-v6.0.5
:sunflower:


text:
Should we return or give a warning when providing bounds/constraints to a problem that cannot handle them?

We discussed this in https://github.com/libprima/prima/pull/134/ but I'd like to raise the discussion again. In the current code, if someone is merely curious as to how UOBYQA performs on their objective function, even if it ignores their constraints, they will be blocked from doing so until they modify their code to stop providing constraints. Once their curiosity is satisfied, they will need to both change the algorithm back to their original one and uncomment their constraints. This seems rather unfriendly to the user. It might even be difficult for them to comment out all of the constraints - maybe they call prima_minimize in many places with many different objective functions, and it could be very tedious and time consuming to comment out the constraints in all those places.
I see no harm in running one of these algorithms even if constraints are provided that it cannot handle. I do think we should issue a warning, because it's strange to call an unconstrained algorithm and provide constraints, but I don't think it makes sense to refuse to continue until the user does some extra actions. In real life if somebody came to me with a problem they wanted me to solve, and they provided some extraneous information, I certainly wouldn't refuse to solve the problem until they told me again but without the extraneous information, although I might inform them that some of the information they provided is unlikely to impact the solution.
In addition to the above, I was also thinking about what we should do in the event that someone calls an algorithm with accepts constraints, but doesn't provide any. I think this might also be a good case to issue a warning. If we refuse to run the algorithm, the user can always override this by providing a constraint function which does nothing, but again this is very unfriendly to the user.
We've talked about how objective and constraint functions can be expensive, so we do not want to run them unnecessarily, but if a user starts a program and sees a warning about constraints not being used or not being provided, they can always act on the warning and press Ctrl+C and investigate.
The main changes this would lead to in the code would be in prima_check_problem in prima.c, which currently returns an error code if an algorithm that doesn't take constraints is provided along with constraints. We would need to modify it to produce a warning and continue. We may also need to modify it depending on the answer to the question about running algorithms which take constraints but are not provided with any, I would propose we add a warning in these cases as well.
Edit: After writing this I went back to https://github.com/libprima/prima/pull/134/ and reviewed your comments there. I think that if the user does not specify an algorithm, we should refine the problem as we see fit and select the appropriate algorithm, and we'll never have the issue of calling an algorithm with extra information or with not enough constraints. However if the user explicitly asks us to use a particular method by overriding the method argument in Python, then it would be appropriate to issue a warning if we cannot refine the problem to the point that the bounds/constraints are appropraite for the method, but I do not see why we should refuse to run, especially when the user can modify their code and sidestep our restriction.

Thank you @nbelakovski for raising this.
However, I think the following is crystal clear and commonly accepted.

If an unconstrained solver is called to solve a contained problem, something is wrong.
A constrained solver should be capable of solving unconstrained problems.

You are right that a warning (a message) should be printed if the user invokes a solver on a problem it cannot handle, so that the user knows what goes wrong. But the solver should exit with an error code afterward.
Thanks.

Commonly accepted by whom?

If an unconstrained solver is called to solve a contained problem, something is wrong.

Maybe, but maybe not. The only way an unconstrained solver can be called to solve a constrained problem is if the user explicitly asks for that solver. I'm ignoring any possibility of errors in any sort of preprocessing/problem relaxation routines because I hope we would test them well, and in any case we're not talking about bugs in this conversation we're talking about intended behavior.
If a user has explicitly asked for a particular solver, then may not be aware that this solver cannot handle constrained problems, but then again it's possible they are aware of this fact. In some cases running an unconstrained solver on a problem might help to gain insight on a problem. It might help the user figure out where to place x0. Or maybe the user is just curious about where the optimal point would be if constraints were removed.
In that case, why should we refuse to run the algorithm? They've explicitly asked for it. We should warn them, in case they are uninformed or made a typo/mistake, but why should we also refuse to honor their request? What is the harm in continuing? Surely the users who are uninformed or who made a mistake can kill the program upon seeing the warning and re-evaluate their code before trying again.

The following code produces the following output:
Code:
from scipy.optimize import minimize, NonlinearConstraint as NLC
nlc = NLC(lambda x: x**2, lb=25, ub=100)
minimize(lambda x: x**2, 7, method='bfgs', constraints=nlc)

Output:
/Users/nickolai/Library/Python/3.11/lib/python/site-packages/scipy/optimize/_minimize.py:576: RuntimeWarning: Method bfgs cannot handle constraints.
  warn('Method %s cannot handle constraints.' % method,
  message: Optimization terminated successfully.
  success: True
   status: 0
      fun: 7.451631553407712e-17
        x: [-8.632e-09]
      nit: 3
      jac: [-2.363e-09]
 hess_inv: [[ 5.000e-01]]
     nfev: 8
     njev: 4

The same warning occurs with other unconstrained algorithms. Naturally asking for COBYLA produces no warning message. But the point is that it produces a warning and still runs the algorithm.
One more thing that I think i worth pointing out: in the past software was often written to produce an error message in case anything was wrong and leave it up to the user to figure out what's wrong how to fix it. The modern trend is towards helpful error messages (see here and here and here). In that spirit, an error message in this situation should give the user a hint as to what to do. Since we don't know whether the user wants to see the unconstrained solution to their problem or whether they selected the wrong algorithm we could give them a rather long error message suggesting both options. It seems more straightforward to simply issue a warning and continue, don't you think?

The correct behavior is to print a warning and select a correct solver. This is the behavior of PDFO and the MATLAB interface of PRIMA.
However, do you really want to jump into this rabbit hole when talking about the C interface? Recall that different solvers have different requirements on the parameters. I suggest you have a look at https://github.com/libprima/prima/blob/main/matlab/interfaces/private/preprima.m. Let us keep the C interface simple and do the sophisticated things in the Python/MATLAB/Julia/R interfaces.
thanks.

The correct behavior is to print a warning and select a correct solver. This is the behavior of PDFO and the MATLAB interface of PRIMA.

Even if the user has explicitly selected a solver? I don't understand, why is an option to select a solver provided if the software is going to pick its own solver anyway? If the only way for a user to invoke a different solver is to change their problem, then does it even make sense to offer them a way to override the method*? To me, the whole point of a manual override is for the user to say "I know this is wrong, but I want you to do it anyway," and of course we should issue a warning if it's inappropriate, but to offer the user the ability to override without actually overriding seems disingenuous.
* - The only exception would be NEWUOA/UOBYQA since they can both be applied to the same type of problem.
It doesn't matter too much to me where this logic goes, probably Python is best because I imagine SciPy may want to configure this logic to be closer to what I'm suggesting (since that's their current logic as evidenced by the above example).

Even if the user has explicitly selected a solver? I don't understand, why is an option to select a solver provided if the software is going to pick its own solver anyway?

If the user specifies a wrong option, the we raise a warning and use the default. This has been always the way that PRIMA handles all wrongly specified options.
There may be other ways to hand wrongly specified options, but the above-mentioned way has been adopted (together with Tom @nbelakovski ) since 2019 when we were working on PDFO, and it has been working well. I do not see any reason to change it. I do not want to make an exception here.
Thank you for this discussion, but I do not really think this particular topic is an urgent issue.

authors: nbelakovski zaikunzhang

repo: libprima/prima


text:
Stdlib feature: counter for # of VASP child addresses

Needed to support proof of solvency + limit number of child accounts (https://github.com/libra/libra/issues/3949).

Thanks!

authors: kchalkias sblackshear

repo: libra/libra


text:
Support delete operation in jellyfish-merkle

Motivation
To make the jellyfish merkle library more feature complete, can potentially used for other purposes, like UTxO set.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Unit tests are not done yet, if you like this, I'll add the tests.

Is this a feature we want in our storage?

I'll take a look this week.
@davidiw Currently not a high-pri thing since we don't have a use case in our case, maybe for general purpose it is more useful as it is a good-to-have feature. But I think even we approve this from contributors, it has to be merged after code freeze to avoid any risks.

We are currently not accepting new features into the code base at this point in time. Given @lightmark's feedback, we'll re-open this and explore again in the future. Thanks for your contribution!

authors: davidiw lightmark yihuang


text:
Unknown bootloader CRC - 0x0939FCDA - please report this on GitHub issues

This is a Tongou TO-Q-SY1-JWT DIN rail power switch/meter: https://www.elektroda.com/rtvforum/topic3990985.html
It had already stopped working, so I got brave and opened it up. Appear to flash firmware just fine (ESPHome, then OpenBK7231N_QIO_1.17.654.bin
|-- Unknown bootloader CRC - 0x0939FCDA - please report this on GitHub issues!
|   |-- Success! Chip info: BK7231N
|-- Writing '/home/dwmw/Downloads/OpenBK7231N_QIO_1.17.654.bin'
|   |-- Start offset: 0x11000 (auto-detected)
|   |-- Write length: 1.1 MiB (auto-detected)
|   |-- Skipped data: 68 KiB (auto-detected)
  [################################################################]  100%          |-- The current command timeout of 1.0 second(s) is too low for reading 1150976 bytes CRC. Increasing to 3 second(s).

|   |-- Finished in 61.297 s

Still doesn't work afterwards. The LEDs come on but there's no apparent WiFi activity, nothing on the serial port if I configure ESPHome to use UART1. But it was like that before with the Tuya firmware (although it was only the status LED that came on, IIRC, while now both do).
Will order a new one to sacrifice and see if that one works.

Your device most likely needs different encryption keys. OpenBeken currently doesn't have means to change encryption keys, LibreTiny/ESPHome does.
But in order to find the encryption keys for your device, you will need to post a stock firmware dump here.

Thanks. What would the failure mode be in that case? It seemed to flash successfully but then just doesn't boot; is that what we'd expect?
New unit will be here tomorrow.

Yes, flashing a firmware with different keys will make it unable to boot.
Depending on whether you've flashed OpenBeken using their official tool (which overwrites the bootloader) you might be able to still retrieve the stock bootloader firmware dump. That could be enough to uncover the encryption keys.

I only flashed with ltchiptool, so should a 'flash read' give us the bootloader?

Yes. With no parameters it should give a full 2 MiB firmware dump, which will most likely include the stock bootloader and your firmware flashing attempts.

http://david.woodhou.se/frombk.bin
SHA256 f414981edc35e348524ae21a73295ac4522191f38d83f1bce5c0104cf4b391ca

This device uses default encryption keys - it's a Tuya device, they all use the same keys.
Flashing ESPHome should work with no issues, using the default config. Make sure you're checking the right UART port.
The bootloader might be corrupted - the binary differs from a known-good BK7231N bootloader by one byte. Try flashing just the bootloader from the OpenBeken's firmware image:
ltchiptool flash write -s 0x0 -l 0x11000 OpenBK7231N_QIO_1.17.654.bin

Then flash the firmware of choice without passing -s and -l.

I had originally flashed with esphome run....
Will try the above.

Aug 11 13:52:41 lantiq.infradead.org dnsmasq-dhcp[24570]: DHCPACK(tag.2) 172.31.31.176 a0:92:08:23:d8:00 upk2esphome-bk7231n

Just flashing the bootloader worked. Thanks!

Depending on whether you've flashed OpenBeken using their official tool (which overwrites the bootloader)

this is no longer the case. This can be checked if bootloader overwrite is desired

OpenBeken currently doesn't have means to change encryption keys, LibreTiny/ESPHome does.

It's a lot easier with LT/ESPhome but OpenBeken can tried by changing key in https://github.com/openshwprojects/OpenBK7231N/blob/master/platforms/bk7231n/bk7231n_os/build.sh

repo: libretiny-eu/ltchiptool


text:
Release proposal: v1.43.0

We're coming up on six months since the last release. I'd like to release v1.43.0.
Notable changes:

uv_ip_name() has been added.
On Windows, uv_fs_read() and uv_fs_write() now return UV_EBADF instead of UV_EPERM when the file descriptor was opened with incorrect flags. This matches the behavior on other platforms.
Streams can be reset and attempted to read from after EOF is read.
The main thread now has a valid ID instead of NULL.
uv_cpu_info() now supports aarch64.
Several minor issues related to mingw32 have been fixed.

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/2211/. The only failure is in the ipc_closed_handle test, which I believe has been flaky for a while now.
Node.js + libuv integration CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/192/ and https://ci.nodejs.org/view/libuv/job/libuv-in-node/195/. test-performance-eventloopdelay failed, but has failed in Node recently as well. test-fs-writefile-with-fd and test-fs-write-file both failed because the Windows error code returned by libuv changed in 9604b61db679be2697132891f22509f88ebcc416.

#3383 might be nice to have and should (I think) be risk free. I'd have merged it but I didn't want to get in your way.

I'm going to pass on #3383 for now. It would be good to get some eyes on that PR from the Windows team.

I'm kicking off the release now. The libuv CI is still good after the changes that landed yesterday.

It might be nice to land https://github.com/libuv/libuv-release-tool/pull/13 first?

Sorry @vtjnash I missed your comment while I was cutting the release. I did notice a few things were off with the release this time - I think I fixed everything by hand. We should land that release tool PR before the next release.

I notice you did not sign the tag (though did sign the commit). Could you push a modified tag with your gpg signature:

Sure, I'll look into this.

I pushed a corrected tag (the release tool did not really want to make a new release without it fixed first)

checking if anything is broken today unexpectedly:
https://ci.nodejs.org/view/libuv/job/libuv-test-commit/2233/
https://ci.nodejs.org/view/libuv/job/libuv-in-node/209/

authors: bnoordhuis cjihrig vtjnash

repo: libuv/libuv


text:
upgrade to python 3

Output from caniusepython3 (pre dependency upgrade):
You need 1 project to transition to Python 3.
Of that 1 project, 1 has no direct dependencies blocking its transition:

  django-rest-auth

Resources: https://docs.python.org/3/howto/pyporting.html

Looks like we'd need to modify the /auth/token endpoint to do token generation manually: http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication

Done:
369aec744bc5cd34f154cea582d7ac8cb1bc5db0
959f75f103820c08100ea8d0c06db78562444372
a94b61b7d06733d649abd360d195f7e682a65ac1

repo: liddiard/skry


text:
Consider adding Spring Boot 2 support

Relates to https://github.com/spring-projects/spring-boot/issues/13510
We are reviewing our community starters list and a quick look here suggests that this starter doesn’t yet support Spring Boot 2.
Can you please let us know if/when you plan to support Spring Boot 2?
Thanks!

Hi Stephane,
The update has been completed, version 2.0.0 has been released with Spring Boot 2 support.

Sweet, thanks!

authors: lievendoclo snicoll

repo: lievendoclo/hajdbc-spring-boot


text:
Support node 12

This arised from support ticket :point_right: https://issues.liferay.com/browse/LPP-36579

Apparently this won't be possible unless we upgrade gulp.

So, this turned out to be a duplicate of #148, so I'm closing it.

repo: liferay/liferay-js-themes-toolkit


text:
I got an error with "null, shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[kafka-lag-exporter]".

Hi,
I got an error with "null, shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[kafka-lag-exporter]".
Then, docker container was shutdown.
The error log is as below.
2019-11-29 12:56:24,281 INFO  c.l.k.ConsumerGroupCollector$ akka://kafka-lag-exporter/user/consumer-group-collector-kafka_stream - Reporting offsets
Uncaught error from thread [kafka-lag-exporter-akka.actor.default-dispatcher-76]: null, shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[kafka-lag-exporter]
java.lang.StackOverflowError
at scala.collection.Iterator.foreach(Iterator.scala:941)
at scala.collection.Iterator.foreach$(Iterator.scala:941)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1429)
at scala.collection.IterableLike.foreach(IterableLike.scala:74)
at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
at scala.collection.MapLike$FilteredKeys.foreach(MapLike.scala:238)
at scala.collection.MapLike$FilteredKeys.foreach(MapLike.scala:238)
at scala.collection.MapLike$FilteredKeys.foreach(MapLike.scala:238)
at scala.collection.MapLike$FilteredKeys.foreach(MapLike.scala:238)
....
2019-11-29 12:56:24,295 ERROR akka.actor.ActorSystemImpl akka.actor.ActorSystemImpl(kafka-lag-exporter) - Uncaught error from thread [kafka-lag-exporter-akka.actor.default-dispatcher-76]: null, shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[kafka-lag-exporter] java.lang.StackOverflowError: null
at scala.collection.Iterator.foreach(Iterator.scala:941)
at scala.collection.Iterator.foreach$(Iterator.scala:941)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1429)
at scala.collection.IterableLike.foreach(IterableLike.scala:74)
at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
at scala.collection.MapLike$FilteredKeys.foreach(MapLike.scala:238)
at scala.collection.MapLike$FilteredKeys.foreach(MapLike.scala:238)
at scala.collection.MapLike$FilteredKeys.foreach(MapLike.scala:238)
....
2019-11-29 12:56:24,297 INFO  c.l.k.KafkaClusterManager$ akka://kafka-lag-exporter/user - Attempting graceful shutdown
2019-11-29 12:56:24,305 INFO  c.l.k.MetricsReporter$ akka://kafka-lag-exporter/user/lag-reporter - Gracefully stopped Prometheus metrics endpoint HTTP server
2019-11-29 12:56:24,312 INFO  c.l.k.ConsumerGroupCollector$ akka://kafka-lag-exporter/user/consumer-group-collector-kafka_stream - Gracefully stopped polling and Kafka client for cluster: kafka_stream
2019-11-29 12:56:24,313 INFO  c.l.k.ConsumerGroupCollector$ akka://kafka-lag-exporter/user/consumer-group-collector-kafka_lake - Gracefully stopped polling and Kafka client for cluster: kafka_lake
2019-11-29 12:56:24,313 WARN  o.a.k.c.s.kerberos.KerberosLogin  - [Principal=plugin@xxxxx.COM]: TGT renewal thread has been interrupted and will exit.
2019-11-29 12:56:24,313 INFO  c.l.k.ConsumerGroupCollector$ akka://kafka-lag-exporter/user/consumer-group-collector-kafka_iot - Gracefully stopped polling and Kafka client for cluster: kafka_iot
What can I do?

Is there any more to the log?  I don't see the Kafka Lag Exporter call site in the error stack traces.

Please include the complete stack trace if you still observe this error with the latest version.  Consult Troubleshooting for more information.

authors: helloyeops seglo

repo: lightbend/kafka-lag-exporter


text:
Allow for deployment in subdirectory

Is your feature request related to a problem? Please describe.
Currently the app assumes to be deployed on a separate (sub)domain. For the BTCPay Server integration I'd like to use our existing FE proxy (nginx) and certificates to provide an easier setup for the user. I imaging deploying the LiT app in a subdirectory of the existing BTCPay domain, like mybtcpay.com/lit/.
Right now the asset and API requests target the root /, whereas we would need to have them prefixed with /lit/.
Describe the solution you'd like
I started looking into this a bit and found the option of setting the homepage option for create-react-app. By using "homepage": "." as a setting the build uses a relative URL for the asset references, which would solve that part. I'm unsure though whether or not this also works for the API calls. Before proceeding on that front I wanted to inquire if this feature would be wanted.
Describe alternatives you've considered
I've started using nginx sub_filter directives in our setup to rewrite certain URLs, but this is error prone and brittle.

I'm unsure though whether or not this also works for the API calls.

The urls for the API calls will remain https://x.x.x.x/lnrpc.Lightning/GetInfo when you modify the homepage option. I do not believe there will be any issues with this.

Before proceeding on that front I wanted to inquire if this feature would be wanted.

Exactly what feature are you proposing? modifying the homepage field in this repo?
An alternative option to customize the url path is the PUBLIC_URL environment variable when running yarn build. Unfortunately, this is also something that cannot be specified at runtime, so you wouldn't be able to use the lightninglabs/lightning-terminal docker image as is. You'd need to create a new docker image that uses the one of these methods.

The general request would be to allow for the app to be run/deployed in a subdirectory. I think the homepage setting would make it work more universally and solve my current issue with the asset paths not working with a subdir deployment.
As for the API calls I think the config would need to be adapted to not only use the host, but also a potential path (as in our case).
I'd like to avoid shipping a separate docker image and think we can achieve this via the homepage setting and determining the API base URL at runtime.

How do you proposed we make the homepage option customizable at runtime? create-react-app uses this field at build time to set the css/js paths in the html.

I think it can be set on build time without having a negative effect on how the app works currently. From what I see it should just make it work for non-root directory deployments.

Ok, if you'd like to submit a PR with these changes, then i'll review it.

What's the best way to get the app and dependencies running locally for development? I tried connecting the dev Docker images and Polar, but am struggling with that because of certificate issues.

The best way to get it running locally is using testnet. You should be able to follow the compile from source doc for more details. What certificate  issue are you running into?

An alternative option to customize the url path is the PUBLIC_URL environment variable when running yarn build. Unfortunately, this is also something that cannot be specified at runtime, so you wouldn't be able to use the lightninglabs/lightning-terminal docker image as is. You'd need to create a new docker image that uses one of these methods.

I discussed this offline with @dennisreimann and I think it is reasonable to just offer two "official" images under different tags. One that serves the UI from the root path and one that serves it from a specific sub path (for example /lit).
One thing that doesn't work correctly when using PUBLIC_URL is the browser history rewrite mechanism (not sure what the correct term is, the mechanism that is responsible for the virtual pages like /pool). That also needs to take the public URL into account. I think that's probably not a big issue to solve, @jamaljsr ?
The problem with the API calls remains, but I'm sure that can be solved somehow. I'm going to think on this a bit more.

I think I found a possible solution how an nginx can rewrite incoming grpc-web requests to be forwarded to LiT based on the Content-Type. This worked for me (in combination with building the static resources using PUBLIC_URL=/lit/:
http {
    map $content_type $lnd_backend {
      "application/grpc-web+proto" "172.17.0.1:8443"; # This is the host:port of the LiT container (in this example the docker host).
      default "localhost:10009"; # This is the host:port of the lnd host where all normal gRPC (non-grpc-web) calls are sent to.
    }

    server {
        listen 80;
        server_name localhost;

        location /lit {
            # This needs a slash at the end!
            proxy_pass https://172.17.0.1:8443/;
        }

        location ~* ^/lnrpc.Lightning/ {
            # This cannot have a slash at the end!
            proxy_pass https://$lnd_backend;
        }

        location ~* ^/looprpc.SwapClient/ {
            # This cannot have a slash at the end!
            proxy_pass https://$lnd_backend;
        }

        location ~* ^/poolrpc.Trader/ {
            # This cannot have a slash at the end!
            proxy_pass https://$lnd_backend;
        }
    }
}

@guggero I think we should not go down the latter route, because it is a combination of having the path set on the one side, while still circumventing the path not being set for the API requests. For BTCPay this also might not work, as there are other apps using the gRPC API as well, which this might interfere with.
I think the best way to handle this would be that the app is agnostic to its root (or picking it up on startup/runtime). The asset paths can be changed to work that way via the homepage option (see above). The API requests should also use relative paths or the base path of the app should be set on startup/runtime -- this way we wouldn't need different Docker builds and no workarounds in the deployment (i.e. nginx).

there are other apps using the gRPC API as well, which this might interfere with.

No, that's what the map at the beginning is for. Only LiT makes calls with Content-Type: application/grpc-web+proto while any other, normal, gRPC traffic will have Content-Type: application/grpc. So the requests will be forwarded either to LiT or to lnd depending on whether they come from LiT or not.

The API requests should also use relative paths or the base path of the app should be set on startup/runtime

gRPC doesn't support relative paths for RPC requests. So this might not even be possible with the library we use.

Alright, added a draft PR for the integration, which thanks to @guggero's snippet almost works.
With the current state there are only the path issues left to resolve.
For the asset paths I've found nginx sub_filters as a workaround, though these might be rather easy to eliminate via the homepage option. From what I've seen this option would not have a negative side effect for the app.
Frontend-wise the paths switch to the root paths (e.g. /loop/ instead of /lit/loop/) on navigation. This might be solvable by setting the PUBLIC_URL as Oliver suggested.
@jamaljsr What are your thoughts on this?

For the asset paths I've found nginx sub_filters as a workaround, though these might be rather easy to eliminate via the homepage option. From what I've seen this option would not have a negative side effect for the app.
Frontend-wise the paths switch to the root paths (e.g. /loop/ instead of /lit/loop/) on navigation. This might be solvable by setting the PUBLIC_URL as Oliver suggested.

I believe that setting PUBLIC_URL would help solve both of these issues, but you'd also need a code change for the second one. The magic-string paths specified in the Routes.tsx and appView.ts would also need to be updated to include the PUBLIC_URL env value. I haven't tested myself but this seems doable.

authors: dennisreimann guggero jamaljsr

repo: lightninglabs/lightning-terminal