text:
Fixed CLion sdkcompat

Checklist

[ ] I have filed an issue about this change and discussed potential changes with the maintainers.
[ ] I have received the approval from the maintainers to make this change.
[ ] This is not a stylistic, refactoring, or cleanup change.

Please note that the maintainers will not be reviewing this change until all checkboxes are ticked. See
the Contributions section in the README for more
details.
Discussion thread for this change
Issue number: <please reference the issue number or url here>
Description of this change

I tried to fix all the build errors for CLion 242. Since the CMakeNotificationProvider was removed I had to move the deregistration also to the sdkcompat.

Just noticed this exception:
com.intellij.diagnostic.PluginException: Cannot create extension (class=com.google.idea.blaze.plugin.CMakeNotificationFilter) [Plugin: com.google.idea.bazel.clwb]
	at com.intellij.serviceContainer.ComponentManagerImpl.createError(ComponentManagerImpl.kt:977)
	at com.intellij.openapi.extensions.impl.XmlExtensionAdapter.doCreateInstance(XmlExtensionAdapter.kt:73)
	at com.intellij.openapi.extensions.impl.XmlExtensionAdapter.createInstance(XmlExtensionAdapter.kt:33)
	at com.intellij.ui.EditorNotificationsImpl$updateEditors$job$1.invokeSuspend(EditorNotificationsImpl.kt:233)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:585)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:802)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:706)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:693)

Will look at this Thursday.

Update this line to enable CI https://github.com/tpasternak/bazel-intellij/blob/c40b7f5170efa07fd6aeb764af13a074b017bd29/intellij_platform_sdk/build_defs.bzl#L40

Addressed your comments in new PR here: https://github.com/bazelbuild/intellij/pull/6469

authors: LeFrosch tpasternak

repo: tpasternak/bazel-intellij


text:
Get rid of Config requirement (at least on testnet)

In spite of the issue #180 I just made, a super smooth testnet experience is really important (and if you make smooth enough, maybe you can discount the argument I made in #180 ). To that end, I think you should try to get instructions like "Create accounts with these providers and add their API keys to this JSON file". You want the user to go as long as possible before editing config files (compare VS Code to Emacs).
What about this as a solution: Launch the UI before originating, and then use the users wallet to originate. Same thing with Pinata - launch the UI before you have the keys, and then have a textbox where people can paste their pinata keys in to activate the minter. Of course people who know what they're doing will want a config file by which they can automate this process, but GUI's are really, really nice to have when you're trying something new (compare AWS to provisioning a VM yourself).
The otehr way to do it is "convention over configuration" - let people drop ready-made config files into obvious locations as I did in #178 . At least then I don't have to worry about the contents of the file, just its acquisition and placement, but it's still inferior to a wizard that guides me through the process.

Hey @d4hines, thanks for the feedback! With the release of v0.4.1 we have streamlined the whole onboarding experience. Getting running on testnet is now a very simple process and requires no custom config.

source: gharchive/issue

repo: tqtezos/minter

license: MIT

license_type: permissive

license_source: github-api


text:
Map bug

When having a map in hands
https://imgur.com/a/5EUB3pu

Fixed with the next release since maps won't be rendered as a minimap at all.

Fixed with the next release since maps won't be rendered as a minimap at all.


text:
对java程序进行故障注入卡住

chaosmeta版本为0.6.1。
1，chaosmeta执行实验显示成功。
2，jvm修改返回值或延时都未实际生效。
3，看起来在java -cp .:tools.jar 的命令执行的时候卡住了，并未往后进行实验。
卡在了ChaosMetaJVMAttacher中第21行，vm.loadAgent(agentPath, configPath);
我使用的是amazoncorretto的jdk8镜像，普通的spring demo程序。

repo: traas-stack/chaosmeta


text:
Theme not opening when --open (-o) flag is passed to the serve executor

Current Behavior

When a theme is served using the --open flag the local server starts but the theme is not automatically opened in the browser.
Expected Behavior

Whenever the --open or -o flags are passed to the serve executor the theme should be opened in the browser with the local server address (BrowserSync).
Steps to Reproduce

$ npx create-nx-workspace myorg --preset=empty --nxCloud=false
$ cd myorg
$ npm i -D @trafilea/nx-shopify@alpha
$ nx g @trafilea/nx-shopify:theme my-shop
$ nx serve my-shop --open

Environment

>  NX  Report complete - copy this into the issue template

  Node : 12.18.4
  OS   : linux x64
  npm  : 7.5.6

  nx : Not Found
  @nrwl/angular : Not Found
  @nrwl/cli : 11.3.2
  @nrwl/cypress : Not Found
  @nrwl/devkit : 11.3.2
  @nrwl/eslint-plugin-nx : Not Found
  @nrwl/express : Not Found
  @nrwl/jest : 11.3.2
  @nrwl/linter : 11.3.2
  @nrwl/nest : Not Found
  @nrwl/next : Not Found
  @nrwl/node : Not Found
  @nrwl/react : Not Found
  @nrwl/schematics : Not Found
  @nrwl/tao : 11.3.2
  @nrwl/web : Not Found
  @nrwl/workspace : 11.3.2
  typescript : 4.0.7

:tada: This issue has been resolved in version 1.0.0-alpha.6 :tada:
The release is available on:

GitHub release
npm package (@alpha dist-tag)

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.0.0-beta.1 :tada:
The release is available on:

GitHub release
npm package (@beta dist-tag)

Your semantic-release bot :package::rocket:

repo: trafilea/nx-shopify


text:
bitcode dis ERROR

Hello, I want to use llvm-dis hello.bc to get readable .ll file. But there was an error:
LLVM ERROR: getPointer in streaming memory objects not allowed
how can i fix this problem?

Are you using the correct version of llvm-dis? You may have more than one version of LLVM installed.
Bitcode formats across LLVM versions are not compatible. If you use something like mcsema-lift-5.0 <args> to lift, you'd want to use llvm-dis-5.0 hello.bc to disassemble the file.

repo: trailofbits/mcsema

license_source: bigquery


text:
🛑 Optoingen-Web is down

In ab4de05, Optoingen-Web (https://$DOMAIN4) was down:

HTTP code: 404
Response time: 629 ms

Resolved: Optoingen-Web is back up in 66e3ca1 after 8 minutes.

repo: traktuner/status


text:
🛑 TechinAsia_WordPress_API is down

In 3df525d, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 228 ms

Resolved: TechinAsia_WordPress_API is back up in 3369326 after 9 minutes.

repo: traqy/upptime


text:
🛑 TechinAsia_WordPress_API is down

In 7f4b2b6, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 172 ms

Resolved: TechinAsia_WordPress_API is back up in 8294f45 after 7 minutes.


text:
🛑 TechinAsia is down

In 8bbb370, TechinAsia (https://www.techinasia.com) was down:

HTTP code: 403
Response time: 766 ms

Resolved: TechinAsia is back up in 8b9eda7 after 7 minutes.


text:
🛑 TechinAsia_WordPress_API is down

In fb5124f, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 174 ms

Resolved: TechinAsia_WordPress_API is back up in 0957e25 after 9 minutes.


text:
🛑 TechinAsia_WordPress_API is down

In 9f0889e, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 231 ms

Resolved: TechinAsia_WordPress_API is back up in 7f31cf8 after 7 minutes.


text:
🛑 TechinAsia is down

In ae79386, TechinAsia (https://www.techinasia.com) was down:

HTTP code: 403
Response time: 720 ms

Resolved: TechinAsia is back up in 697d611 after 7 minutes.


text:
🛑 TechinAsia_WordPress_API is down

In 8732520, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 171 ms

Resolved: TechinAsia_WordPress_API is back up in a470ba5 after 7 minutes.


text:
🛑 TechinAsia is down

In 3332d74, TechinAsia (https://www.techinasia.com) was down:

HTTP code: 403
Response time: 976 ms

Resolved: TechinAsia is back up in 0b787f8 after 10 minutes.


text:
🛑 TechinAsia_WordPress_API is down

In 584381d, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 231 ms

Resolved: TechinAsia_WordPress_API is back up in e937d4f after 7 minutes.


text:
Ping

Create IMAP folder.

Again!

repo: trasherdk/svelte-stripe-js


text:
amqp-job: implement state message counter

This counter helps Hub reorder the messages if they arrive in a different order than Worker sent them in, which sometimes causes a "requeue" immediately after "received" to be interpreted as "requeue" and then "receive", causing the job to get stuck.
/cc @svenfuchs, is this roughly what you thought in terms of JSON payloads? I.e. state_update_count in the top-level of both the payload from Scheduler and the payload to Hub?
/cc @solarce

@henrikhodne super, so glad to see this happening! ❤
I have just recently started including a "meta" hash into messages to Hub, e.g. [here] (https://github.com/travis-ci/travis-gatekeeper/blob/92b0f18ce72c621ff56464a2737d51305483b25c/lib/travis/gatekeeper/service/build/cancel.rb#L34).
Would that be a too annoying in Go to do in this case as well?

@svenfuchs So, something like this?
err := j.sendStateUpdate("job:test:reset", map[string]interface{}{
    "id":    j.Payload().Job.ID,
    "state": "reset",
    "meta": map[string]interface{}{
        "state_update_count": j.stateCount,
    },
})

I.e. the following JSON:
{
    "id": 1234,
    "state": "reset",
    "meta": {
        "state_update_count": 1
    }
}

@henrikhodne looks good to me! wdyt?

Updated to pass the counter inside a meta block. Should test this out in staging first to make sure hub ignores the value for now, then I think this is good to merge.

@henrikhodne is the input format the same? i.e. is Scheduler supposed to include the same meta hash?

is the input format the same? i.e. is Scheduler supposed to include the same meta hash?

Ah, no, right now it just expects state_update_count at the top level of the object, I'll push it into a meta object.

Tested this on MacStadium staging and hub seemed to deal with the new fields just fine without any errors.

source: gharchive/pull-request

authors: henrikhodne svenfuchs

repo: travis-ci/worker

license: mit


text:
Add a cron job to hourly check the status of docker and travis-worker

What is the problem that this PR is trying to fix?
docker and travis-worker services sometimes get into a weird state on worker instances, and need to be start or restarted.
What approach did you choose and why?
This PR adds two hourly cron jobs as part of the worker install step to check the status of these services and restart them if necessary.
How can you test this?
We'll see on staging?
What feedback would you like, if any?
Is there a better way?
Addresses https://github.com/travis-pro/team-blue/issues/704

Closing in favor of https://github.com/travis-infrastructure/terraform-config/pull/251


text:
Update cats-effect, cats-effect-laws to 1.3.1

Updates

org.typelevel:cats-effect
org.typelevel:cats-effect-laws

from 1.3.0 to 1.3.1.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a nice day!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [{ groupId = "org.typelevel" }]

labels: semver-patch

Codecov Report

Merging #119 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #119   +/-   ##
=====================================
  Coverage      52%    52%
=====================================
  Files           9      9
  Lines         200    200
  Branches        3      3
=====================================
  Hits          104    104
  Misses         96     96

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 d32e47c...977afeb. Read the comment docs.

authors: codecov-io scala-steward

repo: travisbrown/catbird


text:
npm  install错误

travis CI 的状态是成功的，你的安装失败应该是国内网络环境导致

repo: trazyn/weweChat


text:
must_be/2 is slow

Hi, I just tried:
% numbervars2(+Term, +Integer, -Integer)
numbervars2(T, N, M) :-
   term_variables(T, L),
   numbervars_list(L, N, M).

% numbervars_list(+List, +Integer, -Integer)
numbervars_list(['$VAR'(N)|L], N, M) :-
   H is N+1,
   numbervars_list(L, H, M).
numbervars_list([], N, N).

?- time((between(1,1000000,_), numbervars(f(X,g(Y,X),Y), 0, M), fail; true)).
Time elapsed 8.92 secs
   true.
?- time((between(1,1000000,_), numbervars2(f(X,g(Y,X),Y), 0, M), fail; true)).
Time elapsed 1.39 secs
   true.

It seems that the must_be/2 eats a lot of time, its even not the catch/3
inside the numbervars/3 implementation. One can try:
?- time((between(1,1000000,_), numbervars_(f(X,g(Y,X),Y), 0, M), fail; true)).
Time elapsed 7.76 secs
   true.

Somehow I have the feeling must_be/2 is even not necessary,
since numbervars_list/3 calls H is N+1 which would anyway catch
a non-number, but it would also allow a float, so there is a little dilemma.

Yes, must_be/2 & can_be/2 from error.pl are slow. I will change to use my
own implementations in the builtins.
On Sun, Jun 5, 2022 at 9:38 PM Jean-Luc-Picard-2021 <
@.***> wrote:

He I just tried:
% numbervars2(+Term, +Integer, -Integer)
numbervars2(T, N, M) :-
term_variables(T, L),
numbervars_list(L, N, M).
% numbervars_list(+List, +Integer, -Integer)
numbervars_list(['$VAR'(N)|L], N, M) :-
H is N+1,
numbervars_list(L, H, M).
numbervars_list([], N, N).
?- time((between(1,1000000,), numbervars(f(X,g(Y,X),Y), 0, M), fail; true)).
Time elapsed 8.92 secs
true.
?- time((between(1,1000000,), numbervars2(f(X,g(Y,X),Y), 0, M), fail; true)).
Time elapsed 1.39 secs
true.
It seems that the must_be/2 eats a lot of time, its even not the catch/3
inside the numbervars/3 implementation. One can try:
?- time((between(1,1000000,), numbervars(f(X,g(Y,X),Y), 0, M), fail; true)).
Time elapsed 7.76 secs
true.
—
Reply to this email directly, view it on GitHub
https://github.com/trealla-prolog/trealla/issues/584, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNKSESVSBADBZB6JSSQFJTVNSGTFANCNFSM5X45VVIA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I think must_be/2 can be made faster, it has must_be_(type, Type),
but the type is known. Wouldn't it be valid to call must_be_/2 directly
in trusted code?
Not sure what the way out is...

repo: trealla-prolog/trealla


text:
[WIP] GraalJS follow up (re-implement)

Follow up #1256

Fix conflict and reimplement #1266 (3a43d66836fc94)
Fix shadowJar issue (a78aa0fba94aeab0b50dd9b20)
Fix runtime error by upgrade graaljs (f9c49b0b2d40204e394b60362b882a)
Implement #1266 in GraalJS to fix degrade performance (62126f72937bae65d7fed22dcdcef226e0e5af9c)
Handle exception in CheckingJsEvaluator.evaluate() and add error message (216796636d103da84a858232e8d5ba4ac9795218)

@ritta Could you review the PR ?
This include #1256 and I reviewed it.
So I ask you to the additional commits which I list up in the PR message.

repo: treasure-data/digdag


text:
Depreciated Aspects

Since FusedLocationAPI has been depreciated, what do you recommend using in its place?

Sorry for my delayed reply! There's a good thread about this on StackOverflow, though I haven't tried updating it myself as I'm no longer actively writing code. https://stackoverflow.com/a/46482065/475217

authors: JoshuaFry benjakuben

repo: treehouse/android-location-example


text:
Add lakefs cmd local config flag

Closes #4186

@nopcoder Not such an elegant solution - feel free to suggest/push improvements

repo: treeverse/lakeFS


text:
Fix lakectl table write to non tty non string column

Fix #5433

(Not sure this is specifically related to tty output.)
Thanks!

The non-tty is related to the fact that we use this code while render the table when we identify that the output is not the terminal.


text:
Pub/Sub modification for message ordering

Signed-off-by: Jigyasa jigyasakhaneja05@gmail.com
Pull request
Description
Adding support for creating subscription with the option to enable/disable message ordering
Related
https://github.com/tremor-rs/tremor-runtime/issues/724
Checklist

[x] The RFC, if required, has been submitted and approved
[ ] Any user-facing impact of the changes is reflected in docs.tremor.rs
[x] The code is tested
[x] Use of unsafe code is reasoned about in a comment
[x] Update CHANGELOG.md appropriately, recording any changes, bug fixes, or other observable changes in behavior
[x] The performance impact of the change is measured (see below)

Performance

Coverage increased (+0.01%) to 83.925% when pulling 86b3ef2c2bef2fa7cefbb8726b8c7dea2c945051 on jigyasak05:pubsub-connector into 650bc0e7b58cc48bcc903bf4b103594334b0140b on tremor-rs:main.

Woop woop!

authors: coveralls darach jigyasak05

repo: tremor-rs/tremor-runtime


text:
EINVAL and EHOSTDOWN

Hi,
I've created a simple server, but if I make requests from the local machine (OS X El Capitan, dig command) always is ok, if I make requests from another computer in the same LAN (Windows 10, Chrome) always I get EHOSTDOWN or EINVAL errors.
The code I used is this.
var named = require('node-named')
var dns = require('dns')

var dnsServer = named.createServer()

dnsServer.on('query', (query) => {

  switch(query.type()) {

    case 'A':
      dns.resolve(query.name(), 'A', (err, addresses) => {

        if(err)
          return

        for(var i = 0; i < addresses.length; i++)
          query.addAnswer(query.name(), new named.ARecord(addresses[i]), 0)

        dnsServer.send(query)
      })

      break

  }
})

dnsServer.on('uncaughtException', (e) => console.log('LOG0'))
dnsServer.on('after', (e) => console.log('LOG1'))
dnsServer.on('clientError', (e) => console.log('LOG2'));

dnsServer.listen(process.env.DNS_PORT || 53, () => {
  console.log('DNS server started.')
})

Console output is this
imac-di-edoardo:ad Edoardo$ sudo npm start

> ad@0.0.0 start /Users/Edoardo/Desktop/FLRAuth/ad
> node server.js

DNS server started.
{ Error: send EHOSTDOWN ::ffff:192.168.1.4:61551
    at Object.exports._errnoException (util.js:1018:11)
    at exports._exceptionWithHostPort (util.js:1041:20)
    at SendWrap.afterSend [as oncomplete] (dgram.js:406:11)
  code: 'EHOSTDOWN',
  errno: 'EHOSTDOWN',
  syscall: 'send',
  address: '::ffff:192.168.1.4',
  port: 61551 }
{"name":"named","hostname":"imac-di-edoardo.local","pid":1081,"component":"agent","level":40,"adddress":"::ffff:192.168.1.4","port":61551,"err":{"message":"send EHOSTDOWN ::ffff:192.168.1.4:61551","name":"Error","stack":"Error: send EHOSTDOWN ::ffff:192.168.1.4:61551\n    at Object.exports._errnoException (util.js:1018:11)\n    at exports._exceptionWithHostPort (util.js:1041:20)\n    at SendWrap.afterSend [as oncomplete] (dgram.js:406:11)","code":"EHOSTDOWN","errno":"EHOSTDOWN","syscall":"send","address":"::ffff:192.168.1.4","port":61551},"msg":"send: unable to send response","time":"2017-04-18T16:45:12.387Z","v":0}

events.js:160
      throw er; // Unhandled 'error' event
      ^
ExceptionError: function () {
                return msg || name;
        }
    at SendWrap.callback (/Users/Edoardo/Desktop/FLRAuth/ad/node_modules/node-named/lib/server.js:137:44)
    at SendWrap.afterSend [as oncomplete] (dgram.js:411:8)

npm ERR! Darwin 15.6.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "start"
npm ERR! node v6.10.1
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! ad@0.0.0 start: `node server.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the ad@0.0.0 start script 'node server.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the ad package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node server.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs ad
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls ad
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/Edoardo/Desktop/FLRAuth/ad/npm-debug.log

My node version is 6.10.1.
Thank you in advance.

Ah you are indeed correct.
This is a pretty old issue, actually as it appears to have been introduced when there was a change to the way that node address binding worked.
I'll submit a patch shortly.

@tsndr there you go https://github.com/trevoro/node-named/pull/33
Thanks @trevoro for this project, helped me a lot! 😉

Do we get a fix ?

repo: trevoro/node-named


text:
build and release linux/amd64 images

use beefier 8-core runners for building linux/amd64, linux/arm64 and linux/ppc64le images
Closes #1341

ready to go!

repo: triggermesh/triggermesh


text:
Use Qt SDK from qt.io for macOS CI

brew has Qt5.13 (but we use 5.12.x) and qtifw fails (#270). Shift to official Qt 5.12.4 & QtIFw from SDK can help to solve these issues

Done #486

repo: trikset/trik-studio


text:
Loss of object restangle when loading virtual model.

Пропадает объект прямоугольник при загрузки виртуальной модели мира.
model.xml.txt

При загрузке не правильно координаты пересчитывает.
Если прямоугольник был задан как <rectangle begin="50:50" end="10:10"> -- все отлично
Если  <rectangle begin="50:50" end="100:100"> -- сворачивается в точку.

Не воспроизводится на Линуксе.

Первое. Проблема в нецелочисленных значениях begin и end. Нецелочисленные сворачиваются в 0.

authors: anastasiia-kornilova ilyashir


text:
Provide Xcode project instead of !NO_SWIFTPM

The !NO_SWIFTPM flag was really difficult to get working correctly, and was not sustainable for someone with an existing Xcode project who wants to use LLVMSwift.

Really?  I've had quite a lot of success with flags like this in TypeLift projects.  I think Xcode projects are a liability in most projects because they introduce organizational issues and potential points for merge conflicts.

I've finally gotten around to playing with the Kaleidoscope sample repo recently and I was struggling with the !NO_SWIFTPM flag. Then I stumbled upon the swift package generate-xcodeproj command and it seems to work really well so far. So I don't think this is really necessary.

Agreed. It's going away.

authors: CodaFi TristanBurnside harlanhaskins

repo: trill-lang/LLVMSwift


text:
Zip function is not working if destination will be outside(downloads) folders instead of inapp protected folders

Hey @triniwiz,
I have tried to zip the folder with NS Cli v4 and Zip plugin v3.0.0 in Nativescript angular application.
Platform - android
I cannot able to zip the folder in downloads folder, as mentioned in plugin docs (https://www.npmjs.com/package/nativescript-zip#zip)  if the folder is in inapp protected folders then its returning promise with unzipped successfully console. but i cannot able to see/copy the generated zip file.
regarding this issue i have created a topic here in nativescript forum.
.Thanks

fixed: https://github.com/triniwiz/nativescript-zip/commit/c109fc3c295f9ad2460b5259b652340b7a90ce47

authors: kumarandena triniwiz

repo: triniwiz/nativescript-zip


text:
helm deployment - invalid choice: '/etc/gateway/config.yaml' (choose from 'server', 'check')

Error starting pod after deployment using current main branch. Same error using 10 tag. Posted on slack twice last week. No response. Cannot find any other issues related to this error in open/closed issues.
2024-08-13T20:24:33.031Z	INFO	main	io.airlift.log.Logging	Logging to stderr
2024-08-13T20:24:33.139Z	INFO	main	stderr	SLF4J(W): Class path contains multiple SLF4J providers.
2024-08-13T20:24:33.139Z	INFO	main	stderr	SLF4J(W): Found provider [org.slf4j.jul.JULServiceProvider@57829d67]
2024-08-13T20:24:33.139Z	INFO	main	stderr	SLF4J(W): Found provider [ch.qos.logback.classic.spi.LogbackServiceProvider@19dfb72a]
2024-08-13T20:24:33.139Z	INFO	main	stderr	SLF4J(W): See https://www.slf4j.org/codes.html#multiple_bindings for an explanation.
2024-08-13T20:24:33.140Z	INFO	main	stderr	SLF4J(I): Actual provider is of type [org.slf4j.jul.JULServiceProvider@57829d67]
2024-08-13T20:24:33.149Z	INFO	main	org.hibernate.validator.internal.util.Version	HV000001: Hibernate Validator 8
2024-08-13T20:24:33.947Z	INFO	main	stderr	invalid choice: '/etc/gateway/config.yaml' (choose from 'server', 'check')
2024-08-13T20:24:33.948Z	INFO	main	stderr	usage: java -jar gateway-ha-jar-with-dependencies.jar
2024-08-13T20:24:33.948Z	INFO	main	stderr	       [-h] [-v] {server,check} ...
2024-08-13T20:24:33.948Z	INFO	main	stderr	positional arguments:
2024-08-13T20:24:33.954Z	INFO	main	stderr	  {server,check}         available commands
2024-08-13T20:24:33.955Z	INFO	main	stderr	named arguments:
2024-08-13T20:24:33.955Z	INFO	main	stderr	  -h, --help             show this help message and exit
2024-08-13T20:24:33.955Z	INFO	main	stderr	  -v, --version          show the application version and exit

my override.yaml
config:
    dataStore:
        jdbcUrl: jdbc:postgresql://trinogw-ds.trinogw.svc.cluster:5432/gateway
        user: postgres
        password: ***
        driver: org.postgresql.Driver
ingress:
    enabled: true
    className: "nginx"
    hosts:
        - host: trinogw.192.168.212.42.nip.io
          paths:
            - path: /
              pathType: ImplementationSpecific
    tls:
        - hosts:
            - trinogw.192.168.212.42.nip.io
service:
    port: 443

invalid choice: '/etc/gateway/config.yaml' (choose from 'server', 'check')
This message comes from Dropwizard and we removed it since 10.
Looks like you are using an image before 10.
Please make sure you're using the correct image / deployment config.

I'm using the files from main and the latest image which is also tagged as 10, based on dockerhub. https://hub.docker.com/r/trinodb/trino-gateway/tags

https://github.com/trinodb/trino-gateway/blob/112c500321805de962f6d9874ec5145c70dc8631/helm/trino-gateway/Chart.yaml#L24
https://github.com/trinodb/trino-gateway/blob/112c500321805de962f6d9874ec5145c70dc8631/helm/trino-gateway/values.yaml#L6-L7
Looks like the default tag in main is 8.

Ah....I did not know the Chart appVersion was used by the deployment to choose the image. I always look at the values for the tag and it was not applied, and failed to read those 2 lines.... My apologies. Shouldn't the Chart.yaml be updated with each release?

authors: oneonestar wccropper

repo: trinodb/trino-gateway


text:
[Frontend][Backend] Add device-side tma descriptor update API

This adds several new operators to the nvidia gpu IR which expose

loading a descriptor into shared memory
updating different fields on the descriptor
copying the descriptor back to global memory
fencing operations on the descriptor

I then use these to expose 3 new functions in tl.extra.cuda.

experimental_device_tensormap_create1d
experimental_device_tensormap_create2d
experimental_tensormap_fenceproxy_acquire

which allows for new tensormap descriptor creation based on a template, and gives the fence operation needed to use the updated descriptor. We also have the tools needed to implement partial updates if they end up being needed for performance reasons.

@ThomasRaoux as discussed, I've:

Changed TTIR to only have a single tt.experimental_tensormap_create op that doesn't expose shared memory.
Moved fine grained tensormap ops to the nvidia IR
Updated LocalAllocOp to take an alignment attribute and removed TensormapAlloc

@ThomasRaoux as discussed, I've:

Changed TTIR to only have a single tt.experimental_tensormap_create op that doesn't expose shared memory.
Moved fine grained tensormap ops to the nvidia IR
Updated LocalAllocOp to take an alignment attribute and removed TensormapAlloc

Thanks!

Moved fine grained tensormap ops to the nvidia IR

do we even need those ops. What if we were lowering tt.experimental_tensormap_create directly to llvm?

@ThomasRaoux PTAL, removed nvidia ops and now lower directly to LLVM. Also removed the read of the template and now just zero-fill the smem descriptor.

repo: triton-lang/triton


text:
Rename hooks

It is necessary to include the Apollo word in function names? I think it would be much cleaner without it
useQuery
useMutation
We could have both and deprecate the old names with a message.

Hi. @nicolaslopezj Yes, I think it's a good idea. I'm going to implement it (or accept a PR).

authors: nicolaslopezj trojanowski

repo: trojanowski/react-apollo-hooks


text:
🛑 Radarr Anime is down

In 6b6ba39, Radarr Anime (https://tronflix.app/radarr-anime/activity/queue/) was down:

HTTP code: 520
Response time: 116 ms

Resolved: Radarr Anime is back up in e29805f.

repo: tronyx/upptime


text:
🛑 Radarr Anime is down

In 5431b82, Radarr Anime (https://tronflix.app/radarr-anime/activity/queue/) was down:

HTTP code: 520
Response time: 118 ms

Resolved: Radarr Anime is back up in 3219630.


text:
🛑 Plex is down

In 33ef1b0, Plex (https://tronflix.app/plex/web/index.html) was down:

HTTP code: 520
Response time: 164 ms

Resolved: Plex is back up in a338f3e.


text:
🛑 Radarr is down

In 8a97b2c, Radarr (https://tronflix.app/radarr/activity/queue/) was down:

HTTP code: 302
Response time: 124 ms

Resolved: Radarr is back up in 3d837d2 after 6 minutes.


text:
🛑 Bitwarden is down

In 01e4e67, Bitwarden (https://bitwarden.tronflix.app) was down:

HTTP code: 403
Response time: 78 ms

Resolved: Bitwarden is back up in b38b2db.


text:
🛑 Gitea is down

In 76fd9f4, Gitea (https://gitea.tronflix.app) was down:

HTTP code: 521
Response time: 110 ms

Resolved: Gitea is back up in 3431912.


text:
Possible to add more than 1 breakpoint?

Gridstack is great and is a valuable library first off...
That said would love to know if there is a way to recalculate the grid to break at specific (bootstrap) breakpoints, but maintain order.  Currently at 768+ I have a 3 column grid, but would ideally like to have a  2 column grid from 768 to 992, then at 992, it breaks to 3 columns.
Is there an API method, or hack that I can do to achieve this functionality?

@troolee correct me if I'm wrong but this is something planned in the upcoming release?
@JohnBlazek for now I think the only way is to edit generated css file so you can define your own breakpoint (well single one that says when it's time to go single column mode)

Great, thanks for the info @pySilver. Any insight into the next release date, love to recommend this library for future use...

It would be also great to be able to specify the order of widgets in 1-column view.

+1

I don't believe there are plans for this to be part of gridstack's core, but as @pySilver mentioned (thanks!), it's perfectly acceptable to modify the CSS to attain this result.

authors: JohnBlazek palpatine1991 pepf pySilver radiolips


text:
"rm -rf node_modules" to "rimraf node_modules"

looks like this may be a leftover from before rimraf started being used?

@joshburgess well spotted! thank you.

authors: joshburgess trueadm

repo: trueadm/inferno


text:
beechdrops, frails

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[b,f]

/trunk merge

repo: trunk-io/mergequeue-staging


text:
gramashes, antiantienzyme

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,g]

/trunk merge


text:
excoriates, dorser (logical-conflict)

This pull request was generated by the 'mq' tool

/trunk merge


text:
estraying, geodetical

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[e,g]

/trunk merge


text:
asphalts, flutey

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,f]

/trunk merge


text:
diureses, etymography

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[d,e]

/trunk merge


text:
eightieth, almeh

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,e]

/trunk merge


text:
desklike, estafa

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[d,e]

/trunk merge


text:
concussively, diaconicum

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[c,d]

/trunk merge


text:
entamoebiasis, gingerwork

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[e,g]

/trunk merge


text:
extravagate, dowcote

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[d,e]

/trunk merge


text:
factorially, diachylum

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[d,f]

/trunk merge

repo: trunk-io/mergequeue


text:
fringillidae, bacchanalias

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b,f]

/trunk merge


text:
aficionados, boschvark

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,b]

/trunk merge


text:
educatory, burrs

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b,e]

/trunk merge


text:
cosharer, attainder

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,c]

/trunk merge


text:
garnice

This pull request was generated by the 'mq' tool

/trunk merge


text:
buying, contractible

This pull request was generated by the 'mq' tool

/trunk merge


text:
aerographic, dataria

This pull request was generated by the 'mq' tool

/trunk merge


text:
chem, engineery

This pull request was generated by the 'mq' tool

/trunk merge


text:
beylical, carabid

This pull request was generated by the 'mq' tool

/trunk merge


text:
fidiculae, conchological

This pull request was generated by the 'mq' tool

/trunk merge


text:
dyophysitic, bacchanalianism

This pull request was generated by the 'mq' tool

/trunk merge


text:
depopulate, bumpoff

This pull request was generated by the 'mq' tool

/trunk merge


text:
amphibryous, buddha

This pull request was generated by the 'mq' tool

/trunk merge


text:
dineros, fetcher

This pull request was generated by the 'mq' tool

/trunk merge


text:
beefcakes, chloroleucite

This pull request was generated by the 'mq' tool

/trunk merge


text:
diamondbacks

This pull request was generated by the 'mq' tool

/trunk merge


text:
dominantly, animator

This pull request was generated by the 'mq' tool

/trunk merge


text:
corneum, gathering

This pull request was generated by the 'mq' tool

/trunk merge


text:
branchiosaurus, glaucochroite

This pull request was generated by the 'mq' tool

/trunk merge


text:
funambulant, cent

This pull request was generated by the 'mq' tool

/trunk merge


text:
endures, confuter

This pull request was generated by the 'mq' tool

/trunk merge


text:
gramercy

This pull request was generated by the 'mq' tool

/trunk merge


text:
augustinianism, gynecotelic

This pull request was generated by the 'mq' tool

/trunk merge


text:
autophyllogeny, demiseason

This pull request was generated by the 'mq' tool

/trunk merge


text:
electiveness

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[e]

/trunk merge


text:
fowling

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[f]

/trunk merge


text:
boutel, cuscuses

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[b,c]

/trunk merge


text:
convenably, ganoidean

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[c,g]

/trunk merge


text:
gumptious, fetted

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[f,g]

/trunk merge


text:
bubonalgia, feckly

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[b,f]

/trunk merge


text:
enfork, gladii

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[e,g]

/trunk merge


text:
exegetes, counteractor

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[c,e]

/trunk merge


text:
canaster, gerhardtite

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[c,g]

/trunk merge


text:
gazer, comicodidactic

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[c,g]

/trunk merge


text:
famble, balancer

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[b,f]

/trunk merge


text:
antilens, fluochloride

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[a,f]

/trunk merge


text:
aposiopestic, formfeed

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,f]

/trunk merge


text:
gasterosteoid, champagnes

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[c,g]

/trunk merge


text:
descendence, carats

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[c,d]

/trunk merge


text:
famine, divulging

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[d,f]

/trunk merge


text:
colluder, amphoras

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,c]

/trunk merge


text:
creepers, dilatable

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[c,d]

/trunk merge


text:
Fix typo in filename

Summary
changes Tooltop.stories.tsx to Tooltip.stories.tsx

I may use this PR to test out some things to fix the happo failings we see from time to time

repo: trussworks/react-uswds


text:
ci: fix storybook deploy

Note: This branch is just for testing. Let's make updates and merge @jpandersen87's PR (https://github.com/trussworks/react-uswds/pull/2843) instead so they get the credit.

This works. Will recommend to @jpandersen87 to update on the original branch.


text:
Key rotation support for did:web

The public part of Orb server signing key should be exposed using did:web

we should also discuss key rotation implications for prod.

It looks like there will be no additional work required in Orb, that KMS will handle rotate keys functionality. We may have to add test for this.

We have to look into this further.

authors: sandrask troyronda

repo: trustbloc/orb


text:
fix: Notification opening app for Android 12

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Some stuff are weird in plugin.xml, this files dont exist.

Some stuff are weird in plugin.xml, this files dont exist.

Hi Harold,
I can't find that in the plugin.xml  in this plugin, not in any branch?
This is the file from the branch android-native-caller: https://github.com/trusted-care/phonegap-plugin-push/blob/android-native-caller/plugin.xml ?

You are right, I confused, let me add the new .Java file in it.
Also careful it is not tested. I will provide tricks to install from branch
in next PR with xml fix.
Le mer. 8 nov. 2023, 09:36, Daniel Dornhardt @.***> a
écrit :

Some stuff are weird in plugin.xml, this files dont exist. [image:
Screenshot 2023-11-06 at 16 26 25]
https://user-images.githubusercontent.com/8635/280760256-239c9a6f-bcd7-4107-849d-da736d1c38fa.png
Hi Harold,
I can't find that in the plugin.xml in this plugin, not in any branch?
This is the file from the branch android-native-caller:
https://github.com/trusted-care/phonegap-plugin-push/blob/android-native-caller/plugin.xml
?
—
Reply to this email directly, view it on GitHub
https://github.com/trusted-care/phonegap-plugin-push/pull/3#issuecomment-1801323143,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAACDO2B2A5QFJ3V4MWNIATYDNACNAVCNFSM6AAAAAA67VR6VKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBRGMZDGMJUGM
.
You are receiving this because you authored the thread.Message ID:
@.***>

authors: DanielDornhardt hthetiot

repo: trusted-care/phonegap-plugin-push


text:
1.10.* compatibility

You should check compatibility with other versions

@startupz thank you for contribution

authors: ishakuta startupz

repo: trustify/oroplatform-mass-update-bundle


text:
@ts-rest/fastify pathPrefixes not working with nested contracts/routers

Describe the bug
only pathPrefixes set on the deepest level of a contract are used, upper level pathPrefixes are ignored, see reproduction script.
My ts-rest version is 3.45.2 and the fastify version is 4.28.0.
Also I get a type error on test: r1 but don^t have any clue why:
Type 'InitialisedRouter<RecursivelyApplyOptions<{ all: { method: "GET"; path: "/"; responses: { 200: ZodObject<{ data: ZodArray<ZodString, "many">; }, "strip", ZodTypeAny, { data: string[]; }, { data: string[]; }>; }; }; }, { ...; }>>' is not assignable to type 'InitialisedRouter<RecursivelyApplyOptions<RecursivelyApplyOptions<{ all: { method: "GET"; path: "/"; responses: { 200: ZodObject<{ data: ZodArray<ZodString, "many">; }, "strip", ZodTypeAny, { data: string[]; }, { data: string[]; }>; }; }; }, { ...; }>, { ...; }>> | RecursiveRouterObj<...>'.
  Type 'InitialisedRouter<RecursivelyApplyOptions<{ all: { method: "GET"; path: "/"; responses: { 200: ZodObject<{ data: ZodArray<ZodString, "many">; }, "strip", ZodTypeAny, { data: string[]; }, { data: string[]; }>; }; }; }, { ...; }>>' is not assignable to type 'InitialisedRouter<RecursivelyApplyOptions<RecursivelyApplyOptions<{ all: { method: "GET"; path: "/"; responses: { 200: ZodObject<{ data: ZodArray<ZodString, "many">; }, "strip", ZodTypeAny, { data: string[]; }, { data: string[]; }>; }; }; }, { ...; }>, { ...; }>>'.
    Types of property 'contract' are incompatible.
      Type 'RecursivelyApplyOptions<{ all: { method: "GET"; path: "/"; responses: { 200: ZodObject<{ data: ZodArray<ZodString, "many">; }, "strip", ZodTypeAny, { data: string[]; }, { data: string[]; }>; }; }; }, { ...; }>' is not assignable to type 'RecursivelyApplyOptions<RecursivelyApplyOptions<{ all: { method: "GET"; path: "/"; responses: { 200: ZodObject<{ data: ZodArray<ZodString, "many">; }, "strip", ZodTypeAny, { data: string[]; }, { data: string[]; }>; }; }; }, { ...; }>, { ...; }>'.ts(2322)
server.data.ts(399, 7): The expected type comes from property 'test' which is declared here on type 'RecursiveRouterObj<RecursivelyApplyOptions<{ test: RecursivelyApplyOptions<{ all: ...; }, { pathPrefix: "/test"; }>; }, { pathPrefix: "/first"; }>>'

How to reproduce
start a ts-rest-fastify server according to the reproduction script:
Log output: [ts-rest] Initialized GET /test/
Expected behavior
Log output should be [ts-rest] Initialized GET /first/test/ and the route should listen to this.
Code reproduction
const server = Fastify();

  const c = initContract();
  const s = initServer();

  const c1 = c.router(
    {
      all: {
        method: 'GET',
        path: '/',
        responses: {
          200: z.object({
            data: z.array(z.string())
          })
        }
      }
    },
    { pathPrefix: '/test' }
  );

  const c2 = c.router(
    {
      test: c1
    },
    { pathPrefix: '/first' }
  );

  const r1 = s.router(c1, {
    all: async () => {
      return {
        status: 200,
        body: { data: ['test1', 'test2'] }
      };
    }
  });

  const r2 = s.router(c2, {
    test: r1
  });

  s.registerRouter(c2, r2, server, {
    logInitialization: true,
    responseValidation: true
  });

  const start = async () => {
    try {
      await server.listen({ port: Number.parseInt(process.env.PORT || '9900') });
    } catch (err) {
      server.log.error(err);
      process.exit(1);
    }
  };

  start();

ts-rest version
3.45.2

@rkreienbuehl If you make this change it should fix both the incorrectly initialized route and the type error.
// before
const r1 = s.router(c1, {

// after
const r1 = s.router(c2.test, {

The problem is that when you pass c1 directly, the router does not see the path prefix defined in c2. This is also the cause for the type error.
Technically this should not happen because you pass c2 to  s.registerRouter, but this is just a peculiarity with just the fastify library due to how we construct the routers internally. I'd be fine with this if the type error was easy to understand, but at the moment it's not super intuitive so I will keep this issue open and try to find a way to fix this from the library's end.

@rkreienbuehl If you make this change it should fix both the incorrectly initialized route and the type error.
// before
const r1 = s.router(c1, {

// after
const r1 = s.router(c2.test, {

The problem is that when you pass c1 directly, the router does not see the path prefix defined in c2.
Technically this should not happen because you pass c2 to  s.registerRouter, but this is just a peculiarity with just the fastify library due to how we construct the routers internally. I'd be fine with this if the type error was easy to understand, but at the moment it's not super intuitive so I will keep this issue open and try to find a way to fix this from the library's end.

@rkreienbuehl If you make this change it should fix both the incorrectly initialized route and the type error.
// before
const r1 = s.router(c1, {

// after
const r1 = s.router(c2.test, {

The problem is that when you pass c1 directly, the router does not see the path prefix defined in c2.
Technically this should not happen because you pass c2 to s.registerRouter, but this is a peculiarity with just the fastify library due to how we construct the routers internally. I'd be fine with this if the type error was easy to understand, but at the moment it's not super intuitive so I will keep this issue open and try to find a way to fix this from the library's end.

A colleague of mine did a quick investigation into the code and found a solution for the pathPrefix problem. He made a pull-request #619 that fixes this. With the fix, you don't have to do this const r1 = s.router(c2.test, {.
The issue with the typings also is present in ts-rest/express.

@rkreienbuehl do you mean that your fix would fix the following?
I'm trying to split contracts and routers as well, using path prefixes
import { initContract } from "@ts-rest/core"
import { initServer } from "@ts-rest/express"
import { z } from "zod"

export const authContract = initContract().router(
  {
    login: {
      method: "POST",
      path: `/login`,
      body: z.object({
        email: z.string(),
        password: z.string(),
      }),
      responses: {
        200: z.object({
          token: z.string(),
        }),
      },
    },
  },
  {
    pathPrefix: "/auth",
  },
)

export const authServer = initServer().router(authContract, {
  login: async () => {
    return {
      status: 200,
      body: {
        token: "secret token",
      },
    }
  },
})

export const contract = initContract().router(
  {
    auth: authContract,
  },
  {
    pathPrefix: "/api",
  },
)

export const router = initServer().router(contract, {
  // Error TS2322
  // Types of property login are incompatible.
  // The types of tsRestRoute.path are incompatible between these types.
  // Type "/api/auth/login" is not assignable to type "/auth/login"
  auth: authServer,
})

I looked at the fix, it's a 1-liner in ts-rest/fastify, so most likely not fixing express.
I created another issue here: https://github.com/ts-rest/ts-rest/issues/626

@rkreienbuehl @guillaume-docquier-vention see https://github.com/ts-rest/ts-rest/issues/626#issuecomment-2241319140

repo: ts-rest/ts-rest


text:
fix(terminology tab): Hide title of ontology info widget for the tab.

The pull request hides the title Ontology Information from the ontology info widget. I think this would be confusing for the user. The title is in the tab title e.g. about {NCIT}.
before change

after change

:tada: This PR is included in version 2.11.1 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


text:
[Q] SPTS from a MPTS with constant packet size

Hello,
I have tried to extract one channel from a MPTS transport stream. It works, but the new transport stram has a dynamic packet size with small Packages. (e. g. 188 instead von 1316). With the option --stuffing I get the original packet size of the MPTS, because the SPTS transport stream is filled with 0 bits and the original bitrate of the MPTS.
Is it possible with ts duck to get a SPTS with no 0 bits and a constant packet size of e. g. 1316?

the new transport stram has a dynamic packet size with small Packages. (e. g. 188 instead von 1316)

By specification, all transport streams have and have always had a fixed packet size : 188 bytes.
You probably refer to UDP transport where the convention (not a requirement) is to group 7 TS packets (7x188=1316) per UDP datagram because this is the highest number of TS packets for which a UDP datagram remains below the old Ethernet MTU, 1500 bytes. Other forms of TS transports use other forms of TS packet clustering, or no clustering at all (files, broadcast).
So, I assume that you use ip both as input and output plugin.
With the zap plugin, as well as any other plugin which removes TS packets, the output plugin typically receives smaller chunks of TS packets. By default, the ip output plugin sends TS packets as soon as it receives them. Therefore, when some plugin removed packets, the UDP datagrams can be sent with less than 7 TS packets. This is legal and it should work with any valid receiver. However, this is not optimal. If you want to enforce 7 packets per output UDP datagram (and consequently force the output plugin to wait for that number of outgoing packets), use option --enforce-burst (RTFM for more details).

With the option --stuffing I get the original packet size of the MPTS, because the SPTS transport stream is filled with 0 bits and the original bitrate of the MPTS.

With option --stuffing, the TS packets to remove are kept in the TS but replaced with so-called "null packets". Thus, the output plugin receives the same number of TS packets as input is producing, at the same rate, and the outgoing UDP datagrams are usually full (7 TS packets). However, this is very inefficient in terms of network bandwidth.
Also note that the stuffing packets are NOT filled with 0 bits. Null packets are sent on reserved PID 0x1FFF and their payload is filled with 0xFF bytes.

repo: tsduck/tsduck


text:
Firefox support

I can confirm that using react-chrome-redux in a Firefox extension works on FF 57.0 (Quantum) straight out of the box (at least my usage of it). I ported over an extension I had written for Chrome.
I did need to remove the background: { persistent: "true"} from my manifest.json

Woooooooo! That's awesome news @missioeric! :D

authors: missioeric vhmth

repo: tshaddix/react-chrome-redux


text:
Errore zone 27/02/2021

Ciao!
Segnalo che nel dataset, oggi, le Regioni Molise e Basilicata vengono segnate in rosso, ma in realtà dovrebbero entrare in zona rossa Lunedì 1 Marzo.
Se possibile, correggete questa cosa. Grazie!

Ciao!
Segnalo che nel dataset, oggi, le Regioni Molise e Basilicata vengono segnate in rosso, ma in realtà dovrebbero entrare in zona rossa Lunedì 1 Marzo.
Se possibile, correggete questa cosa. Grazie!

Sistemato grazie!

Ciao @tsiotas,
bene, figurati! Però, in questo modo, la data è al futuro. Non è possibile inserire nel dataset le informazioni in tempo reale, sulla base della data odierna? Quindi, il record relativo al 1 Marzo, farlo apparire effettivamente il 1° Marzo e non prima?
Grazie!

Ciao @tsiotas,
bene, figurati! Però, in questo modo, la data è al futuro. Non è possibile inserire nel dataset le informazioni in tempo reale, sulla base della data odierna? Quindi, il record relativo al 1 Marzo, farlo apparire effettivamente il 1° Marzo e non prima?
Grazie!

E' un problema che si è risolto da solo aspettando ;)
Comunque dipende tutto da come decidi di elaborare i dati e da quello che devi farci (l'uso per cui l'abbiamo concepito è quello di elaborazione dati sullo storico, se devi farci una dashboard che visualizza solo l'ultimo giorno è inefficiente tirare giù tutto per poi prendere solo un valore e come hai notato possono esserci errori che vengono corretti in un secondo momento. Nessuno ti vieta di farlo, ma fallo con le dovute considerazioni), banalmente, anziché elaborare brutalmente tutto, basterebbe fare una query del tipo:
SELECT * FROM dataset WHERE Giorno < CURRENT_DATE
(O equivalente nel framework che usi).

Ciao @tsiotas,
bene, figurati! Però, in questo modo, la data è al futuro. Non è possibile inserire nel dataset le informazioni in tempo reale, sulla base della data odierna? Quindi, il record relativo al 1 Marzo, farlo apparire effettivamente il 1° Marzo e non prima?
Grazie!

E' un problema che si è risolto da solo aspettando ;)
Comunque dipende tutto da come decidi di elaborare i dati e da quello che devi farci (l'uso per cui l'abbiamo concepito è quello di elaborazione dati sullo storico, se devi farci una dashboard che visualizza solo l'ultimo giorno è inefficiente tirare giù tutto per poi prendere solo un valore e come hai notato possono esserci errori che vengono corretti in un secondo momento. Nessuno ti vieta di farlo, ma fallo con le dovute considerazioni), banalmente, anziché elaborare brutalmente tutto, basterebbe fare una query del tipo:
SELECT * FROM dataset WHERE Giorno < CURRENT_DATE
(O equivalente nel framework che usi).

Sì certo, ma infatti il "problema" era nei giorni precedenti. In quanto la mappa mi segnava come zone rosse delle Regioni che non erano ancora in zona rossa, con (ieri) la data dell'ultimo aggiornamento visualizzata al futuro (ovvero 01/03/2021).
Comunque sì, certo, si può gestire in fase di elaborazione. Chiedevo solo per capire se fosse possibile avere già il dataset aggiornato con la data corrente. In questo caso ok, allora farò un controllo nella query per ottenere solo il dato della data corrente (o dell'ultima disponibile, prima della data corrente).
Grazie!

Aggiungo un'altra cosa: la Sardegna non dovrebbe essere in zona bianca da oggi? Il dataset verrà aggiornato in giornata? Da dove vengono presi i dati?

Aggiungo un'altra cosa: la Sardegna non dovrebbe essere in zona bianca da oggi? Il dataset verrà aggiornato in giornata?
Abbiamo sistemato ma facendolo abbiamo dovuto aggiungere una colonna per la zona "Bianca" che non era prevista prima

Aggiungo un'altra cosa: la Sardegna non dovrebbe essere in zona bianca da oggi? Il dataset verrà aggiornato in giornata?

Abbiamo sistemato ma facendolo abbiamo dovuto aggiungere una colonna per la zona "Bianca" che non era prevista prima

Ok perfetto! Grazie! I dati vengono presi dal sito del Governo?

authors: HashakGik RiccardoBorchi tsiotas


text:
Add null model rationale

Suggested by Per.

Yep - not yet addressed here, as the wikipedia page for Null Models is not very helpful here. Other suggestions welcome.

Having a bit of a tidy-up - is this still something you'd like to get in @hyanwong?

Peter's suggestion SGTM. Shall I implement?

Change made, should be OK to merge.

LGTM. But, what the heck, CI?

authors: benjeffery hyanwong petrelharp

repo: tskit-dev/tutorials


text:
Filtering SQL after sort causes crash

After sorting the SQL statements by clicking on a header column, if you then try to filter the SQL by From/Where/Error Trace Wizard crashes.

This issue has been resolved.


text:
Doesn't build on a (my) mac

In CMakeLists.txt
${SDL2_INCLUDE_DIR} => /usr/local/include/SDL2/
(SDL2 installed via homebrew)
#include <SDL2/SDL.h> fails as the directory "SDL2" is not in any of the include directories.
changing
- include_directories(${SDL2_INCLUDE_DIR})
+ include_directories(${SDL2_INCLUDE_DIR}/..)

Temporarily fixes it, we need a long term fix.

You can overwrite the directory CMake looks in when initially building makefiles with CMake.

@TheKnarf iirc you also have mac. Do you have the same problem when you try to build the project on your side?

@rexim I do have the same problem building on my Mac, and I solved it by adding the -DSDL2_INCLUDE_DIR=/usr/local/include paramater when running cmake (Overwriting where CMake finds SDL2).

@voldyman we can try to incorporate your workaround into CMakeLists.txt like that: 611fda140bd4817d473a76918b933cb07fc73bb7
Please pull the latest changes when you get a chance and let me know if it works for you.

authors: TheKnarf rexim voldyman

repo: tsoding/nothing


text:
Few minor color changes

Maybe make the these, highlighted by red, to white? Minor stuff but would help. thanks

also on moments tab
PS: I'm using Firefox

Closing as per PR #70

I should probably keep this open until the updated packages go out for the chrome and firefox stores.

@arnofirdaus This library is no longer in use as Twitter has implemented dark mode on their own. I'm going to close this now.

authors: Nickkaczmarek arnoanfield daftxcunt nickkaczmarek

repo: tsriram/twitter-web-night-mode


text:
[FR] iOS support...

...would be great.
... Actually, I managed to run it in Obsidian iOS for one session (by modifying the manifest file) but the next time it did not allow me to enable it again. It was working flawlessly for that one session, though.
I wonder what allows a non-mobile app to be installed/enabled for one session and not for a second time? It happened with another plugin (Surfing; it didn't access the internet as per required though) before.
Cheers

I'm sorry, but I do not plan on supporting mobile and especially not iOS, because I don't own a device which runs iOS. I also don't know why editing the manifest file doesn't work, but I'd guess there's some code which causes errors when launching Obsidian and therefore Obsidian automatically disables the plugin.


text:
Login failed - Password Incorrect

I Installed this today on a fresh FreeBSD 10.2. Everything seems to be installed, but I can't login to webmin.
It always returns an error that the password is incorrect. I'm using the root user to login.
But I can login just fine via ssh.
How to fix this?

I don't believe Webmin is using PAM for authentication in FreeBSD.   It's using a non-integrated account.  You should be able to sign on using the 'admin' username and the root password.

Not working.
With user admin and root password:
"Login failed. Please try again."
It's possible to change the password for webmin admin user via command line in FreeBSD?

Try
/usr/local/libexec/webmin/changepass.pl /usr/local/etc/webmin admin <newpass>

/usr/local/libexec/webmin/changepass.pl: Command not found.

But with the help of find command:
find / -name "changepass.pl"
/usr/local/lib/webmin/changepass.pl

So the command that worked was:
/usr/local/lib/webmin/changepass.pl /usr/local/etc/webmin admin <newpass>

I've now managed to login, and the post configuration started, but an error occurred, staging that MySQL is not installed:
MySQL cannot be enabled, as it is not installed on your system

I haven't gotten to setting up MySQL in the install scripts, but it should be in the package repositories.  If you want to try and see if it works manually:
pkg install -y mysql56-server

That should work.  If not, maybe I'll re-visit this and do some additional work on it today.

I tried to reproduce your password issue without any luck.  Was the username of an initial user you setup during FreeBSD's install 'admin'? If so, was admin placed into the 'wheel' secondary group?

No. Only user configured in FreeBSD install was root. Not a single user was created.
Also, on virtualmin post setup, it complained about the mysql password. I fixed it manually running webmin mysql module to enter the password, and after running the post setup again, this error occured:

So, as suggestions, after the finish of setup script, add an option for the user to set the admin password for webmin/virtualmin. And, add MySQL to the setup script so it can be used and the post config can be completed. At least MySQL shoud be installed. Postgree is not important, but MySQL is.

Thanks, I will  try and debug.
A known issue: MySQL setup throws an error when you select anything other than "Leave Default Settings".

I skipped the MySQL part at least to finish the post configuration. And it seems to be everything working. Thank you for all your work!!
But without MySQL this virtual setup is almost non functional. We need to get MySQL to setup with the system automatically like all the other packages.
Now, I will test this on a remote system with real valid IPs, and test the following:
Server 1: main web server and primary DNS server
Server 2: Secondary DNS server (controlled by server 1)
Thank you!!

MySQL has been added to the install script:19e16cb5eb819d6d50ad8e08051d9c8be4a71a8f
Still deciding what to do about the password issue.

Why not ask at the end of the install script to create the admin user?

authors: christianrj tuaris

repo: tuaris/freebsd-virtualmin


text:
Feature/odf tests

ObservationCollectionParser feature, as well as filtering and splitting capabilities.
Still to be done:

[ ] Observation dependent variables refactoring, incl. dependent variable-based filter and splitter
[x] Check handling of residuals inside OrbitDeterminationManager (during the estimation)
[x] Reintroduce some functions (e.g. weights setting) for backward compatibility
[x] Remove deprecated functions (e.g., createResidualObservationSet, splitObservationSetsIntoArcs)
[x] Option to remove single observation sets based on parser condition, or if empty (ObservationCollection level)

This should now be ready for merge right? Should it be compatible with the latest version of tudatpy, or will this require a separate pull request (I understand the new functionality will require a new PR, but I'm wondering if merging this now will break tudat-tudatpy compatibility)

I am not sure, but just to be on the safe side I just opened the corresponding tudatpy PR. Has feature/odf_merge also been recently merged to develop for the tudatpy repo?

authors: DominicDirkx SamFayolle

repo: tudat-team/tudat


text:
Make Constraint::Length requirement STRONG so that it always gets satisfied

Upstream: #527

Description
While trying to create an element one row tall at the bottom of my screen using Layout, I noticed that it kept being shrunk to 0. You can observe this behaviour with a program like:
use tui::layout::{Constraint, Direction, Layout, Rect};

fn main() {
    let area = Rect::new(0, 0, 100, 75);

    let chunks = Layout::default()
        .direction(Direction::Vertical)
        .margin(0)
        .constraints(
            [
                Constraint::Length(1),
                Constraint::Ratio(1, 9),
                Constraint::Ratio(9, 10),
            ]
            .as_ref(),
        )
        .split(area);

    println!("When Length is first, chunks = {:?}", chunks);

    let chunks = Layout::default()
        .direction(Direction::Vertical)
        .margin(0)
        .constraints(
            [
                Constraint::Ratio(1, 10),
                Constraint::Ratio(9, 10),
                Constraint::Length(1),
            ]
            .as_ref(),
        )
        .split(area);

    println!("When Length is last, chunks = {:?}", chunks);
}

Before my changes, running this produces:
% cargo run -q --example length-last
When Length is first, chunks = [Rect { x: 0, y: 0, width: 100, height: 1 }, Rect { x: 0, y: 1, width: 100, height: 8 }, Rect { x: 0, y: 9, width: 100, height: 66 }]
When Length is last, chunks = [Rect { x: 0, y: 0, width: 100, height: 7 }, Rect { x: 0, y: 7, width: 100, height: 67 }, Rect { x: 0, y: 75, width: 100, height: 0 }]

This is a result of all of the constraints having WEAK strength, and the final Constraint::Length getting solved after the Constraint::Ratio has already been satisfied to take up the whole screen. You can also see that the heights don't add up to 75 here. This is because cassowary is producing fractional values that do sum to 75, but then get truncated when converted from f64 to u16.
It seems like specifying a precise number of columns or rows via Length should take precedence over the more flexible Ratio, so I have modiffied the constraint generation to use STRONG. I have also changed the constraint for Ratio to calculate the goal value using integer arithmetic first and then convert to a float, so that the target value is non-fractional. This seems to be enough to prevent fractional results.
Running the above program now produces:
% cargo run -q --example length-last
When Length is first, chunks = [Rect { x: 0, y: 0, width: 100, height: 1 }, Rect { x: 0, y: 1, width: 100, height: 8 }, Rect { x: 0, y: 9, width: 100, height: 66 }]
When Length is last, chunks = [Rect { x: 0, y: 0, width: 100, height: 7 }, Rect { x: 0, y: 7, width: 100, height: 67 }, Rect { x: 0, y: 74, width: 100, height: 1 }]

Testing guidelines
I have added two new tests to src/layout.rs that check splitting Vertical and Horizontal layouts where the Length constraint comes last after two Ratio constraints. Running cargo make ci results in all tests passing.
Checklist

[X] I have read the contributing guidelines.
[X] I have added relevant tests.
[ ] I have documented all new additions.

Since I haven't added any new APIs, I didn't change any of the docs. (I did update CONTRIBUTING.md to link to cargo-make, though, to help other future contributors figure out what to do to get it.) Let me know if there's anything you think I should document or otherwise change, and I can do so.

Duplicate of https://github.com/tui-rs-revival/ratatui/pull/31, so closing this.

authors: orhun sayanarijit

repo: tui-rs-revival/ratatui


text:
KafkaJS has UnhandledPromiseRejection somewhere in the code

Was running stress tests on the kafkajs and picked up this issue (error does not matter most important part is UnhandledPromiseRejectionWarning):
(node:78646) UnhandledPromiseRejectionWarning: KafkaJSProtocolError: The coordinator is not aware of this member
    at createErrorFromCode (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/protocol/error.js:537:10)
    at Object.parse (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/protocol/requests/heartbeat/v0/response.js:20:11)
    at Connection.send (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/network/connection.js:317:35)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:78646) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2017)

Looks like heartbeat has unhandled promise or throwing inside async function somewhere
Was running latest BETA version  ( "kafkajs": "1.13.0-beta.15")

You should be able to easily reproduce that by changing heartbeat/v0/response.json to always throw and run consumer.
const parse = async data => {
  // if (failure(data.errorCode)) {
  throw createErrorFromCode()
  // }
  return data
}

Looks like it may be related to reties:
Passed here
debug: Suppressed error:  {"timestamp":"2020-04-19T21:17:58.870Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":5,"size":10}
debug: {"timestamp":"2020-04-19T21:17:58.870Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":5,"payload":{"type":"Buffer","data":"[filtered]"}}
Passed here
debug: Suppressed error:  {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":6,"size":10}
debug: {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":6,"payload":{"type":"Buffer","data":"[filtered]"}}
Passed here
debug: Suppressed error:  {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":7,"size":10}
debug: {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":7,"payload":{"type":"Buffer","data":"[filtered]"}}
Passed here
debug: Suppressed error:  {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":8,"size":10}
debug: {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":8,"payload":{"type":"Buffer","data":"[filtered]"}}
Passed here
debug: Suppressed error:  {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":9,"size":10}
debug: {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":9,"payload":{"type":"Buffer","data":"[filtered]"}}
Passed here
debug: Suppressed error:  {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":10,"size":10}
debug: {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":10,"payload":{"type":"Buffer","data":"[filtered]"}}
Passed here
debug: Suppressed error:  {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":11,"size":10}
debug: {"timestamp":"2020-04-19T21:17:58.871Z","logger":"kafkajs","message":"Response Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","error":"Unknown error code undefined","correlationId":11,"payload":{"type":"Buffer","data":"[filtered]"}}
Passed here
debug: {"timestamp":"2020-04-19T21:17:58.873Z","logger":"kafkajs","message":"Request Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","correlationId":16,"expectResponse":true,"size":121}
debug: {"timestamp":"2020-04-19T21:17:58.873Z","logger":"kafkajs","message":"Request Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","correlationId":17,"expectResponse":true,"size":121}
debug: {"timestamp":"2020-04-19T21:17:58.873Z","logger":"kafkajs","message":"Request Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","correlationId":18,"expectResponse":true,"size":121}
debug: {"timestamp":"2020-04-19T21:17:58.874Z","logger":"kafkajs","message":"Request Heartbeat(key: 12, version: 1)","broker":"xyz:9092","clientId":"kafkajs-87503","correlationId":19,"expectResponse":true,"size":121}
(node:87503) UnhandledPromiseRejectionWarning: KafkaJSProtocolError: Unknown error code undefined
    at createErrorFromCode (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/protocol/error.js:537:10)
    at Object.parse (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/protocol/requests/heartbeat/v0/response.js:20:9)
    at Connection.send (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/network/connection.js:317:35)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:87503) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 17)
(node:87503) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I cannot seem to reproduce this. See https://github.com/tulios/kafkajs/tree/repro-702.
I get into the regular crash handling:
$ node examples/consumer.js
{"level":"ERROR","timestamp":"2020-04-20T06:33:09.366Z","logger":"kafkajs","message":"[Connection] Response Metadata(key: 3, version: 5)","broker":"192.168.0.17:9100","clientId":"example-consumer","error":"There is no leader for this topic-partition as we are in the middle of a leadership election","correlationId":3,"size":126}
Attempt to reproduce #702
{"level":"INFO","timestamp":"2020-04-20T06:33:09.692Z","logger":"kafkajs","message":"[Consumer] Starting","groupId":"test-group"}
{"level":"ERROR","timestamp":"2020-04-20T06:33:09.789Z","logger":"kafkajs","message":"[Connection] Response GroupCoordinator(key: 10, version: 1)","broker":"localhost:9100","clientId":"example-consumer","error":"The group coordinator is not available","correlationId":2,"size":55}
{"level":"ERROR","timestamp":"2020-04-20T06:33:10.140Z","logger":"kafkajs","message":"[Connection] Response GroupCoordinator(key: 10, version: 1)","broker":"localhost:9100","clientId":"example-consumer","error":"The group coordinator is not available","correlationId":3,"size":55}
{"level":"ERROR","timestamp":"2020-04-20T06:33:10.967Z","logger":"kafkajs","message":"[Connection] Response GroupCoordinator(key: 10, version: 1)","broker":"localhost:9100","clientId":"example-consumer","error":"The group coordinator is not available","correlationId":4,"size":55}
{"level":"INFO","timestamp":"2020-04-20T06:33:12.761Z","logger":"kafkajs","message":"[Runner] Consumer has joined the group","groupId":"test-group","memberId":"example-consumer-2a9eaf3e-97cc-4cbc-839c-47550bc88f97","leaderId":"example-consumer-2a9eaf3e-97cc-4cbc-839c-47550bc88f97","isLeader":true,"memberAssignment":{"topic-test":[0]},"groupProtocol":"RoundRobinAssigner","duration":3067}
{"level":"ERROR","timestamp":"2020-04-20T06:33:17.851Z","logger":"kafkajs","message":"[Connection] Response Heartbeat(key: 12, version: 1)","broker":"localhost:9094","clientId":"example-consumer","error":"Unknown error code 0","correlationId":5,"size":10}
{"level":"ERROR","timestamp":"2020-04-20T06:33:17.852Z","logger":"kafkajs","message":"[Consumer] Crash: KafkaJSNumberOfRetriesExceeded: Unknown error code 0","groupId":"test-group","retryCount":0,"stack":"KafkaJSNonRetriableError\n  Caused by: KafkaJSProtocolError: Unknown error code 0\n    at createErrorFromCode (/Users/tommybrunn/workspace/kafkajs/src/protocol/error.js:537:10)\n    at Object.parse (/Users/tommybrunn/workspace/kafkajs/src/protocol/requests/heartbeat/v0/response.js:20:9)\n    at Connection.send (/Users/tommybrunn/workspace/kafkajs/src/network/connection.js:317:35)\n    at processTicksAndRejections (internal/process/task_queues.js:97:5)\n    at async Broker.heartbeat (/Users/tommybrunn/workspace/kafkajs/src/broker/index.js:314:12)\n    at async ConsumerGroup.heartbeat (/Users/tommybrunn/workspace/kafkajs/src/consumer/consumerGroup.js:317:7)\n    at async Runner.fetch (/Users/tommybrunn/workspace/kafkajs/src/consumer/runner.js:369:5)\n    at async /Users/tommybrunn/workspace/kafkajs/src/consumer/runner.js:384:9"}
{"level":"INFO","timestamp":"2020-04-20T06:33:17.908Z","logger":"kafkajs","message":"[Consumer] Stopped","groupId":"test-group"}
{"level":"ERROR","timestamp":"2020-04-20T06:33:17.909Z","logger":"kafkajs","message":"[Consumer] Restarting the consumer in 297ms","retryCount":0,"retryTime":297,"groupId":"test-group"}

We have seen the same once as well, didn't get around yet to filing this :(
(node:17) UnhandledPromiseRejectionWarning: KafkaJSProtocolError: The group is rebalancing, so a rejoin is needed
     at createErrorFromCode (/app/node_modules/kafkajs/src/protocol/error.js:537:10)
     at Object.parse (/app/node_modules/kafkajs/src/protocol/requests/heartbeat/v0/response.js:20:11)
     at Connection.send (/app/node_modules/kafkajs/src/network/connection.js:317:35)
     at runMicrotasks (<anonymous>)
     at processTicksAndRejections (internal/process/task_queues.js:97:5)
     at Broker.heartbeat (/app/node_modules/kafkajs/src/broker/index.js:314:12)
     at ConsumerGroup.heartbeat (/app/node_modules/kafkajs/src/consumer/consumerGroup.js:317:7)
     at /app/node_modules/kafkajs/src/consumer/runner.js:346:15
 (node:17) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 529519)
 (node:17) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

@Nevon just tried running from your commit. Looks like there is one more condition which is necessary to reproduce the bug. It should constantly consume messages from the topic.
So i have tweaked producer and started publishing messages to the topic:
const { Kafka, logLevel } = require('../index')

const kafka = new Kafka({
  logLevel: logLevel.DEBUG,
  brokers: [`xyz:9092`],
  clientId: 'example-producer',
})

const topic = 'topic-test'
const producer = kafka.producer()

const getRandomNumber = () => Math.round(Math.random(10) * 1000)
const createMessage = num => ({
  key: `key-${num}`,
  value: `value-${num}-${new Date().toISOString()}`,
})

const sendMessage = () => {
  return producer
    .send({
      topic,
      messages: Array(getRandomNumber())
        .fill()
        .map(_ => createMessage(getRandomNumber())),
    })
    .then(console.log)
    .catch(e => console.error(`[example/producer] ${e.message}`, e))
}

const run = async () => {
  await producer.connect()
  setInterval(sendMessage, 100)
}

run().catch(e => console.error(`[example/producer] ${e.message}`, e))

const errorTypes = ['unhandledRejection', 'uncaughtException']
const signalTraps = ['SIGTERM', 'SIGINT', 'SIGUSR2']

errorTypes.map(type => {
  process.on(type, async () => {
    try {
      console.log(`process.on ${type}`)
      await producer.disconnect()
      process.exit(0)
    } catch (_) {
      process.exit(1)
    }
  })
})

signalTraps.map(type => {
  process.once(type, async () => {
    try {
      await producer.disconnect()
    } finally {
      process.kill(process.pid, type)
    }
  })
})

Then run consumer and in some time it crashed with unhandled rejection...

Again, I'm not getting an unhandled promise rejection. The error is caught and handled by the crash handler:
- topic-test[0 | 72119] / 1587378593021 key-84#value-84-2020-04-20T10:29:53.018Z
{"level":"ERROR","timestamp":"2020-04-20T10:29:53.037Z","logger":"kafkajs","message":"[Connection] Response Heartbeat(key: 12, version: 1)","broker":"localhost:9097","clientId":"example-consumer","error":"Unknown error code 0","correlationId":62,"size":10}
{"level":"ERROR","timestamp":"2020-04-20T10:29:53.037Z","logger":"kafkajs","message":"[Consumer] Crash: KafkaJSNumberOfRetriesExceeded: Unknown error code 0","groupId":"test-group","retryCount":0,"stack":"KafkaJSNonRetriableError\n  Caused by: KafkaJSProtocolError: Unknown error code 0\n    at createErrorFromCode (/Users/tommybrunn/workspace/kafkajs/src/protocol/error.js:537:10)\n    at Object.parse (/Users/tommybrunn/workspace/kafkajs/src/protocol/requests/heartbeat/v0/response.js:20:9)\n    at Connection.send (/Users/tommybrunn/workspace/kafkajs/src/network/connection.js:317:35)\n    at processTicksAndRejections (internal/process/task_queues.js:97:5)\n    at async Broker.heartbeat (/Users/tommybrunn/workspace/kafkajs/src/broker/index.js:314:12)\n    at async ConsumerGroup.heartbeat (/Users/tommybrunn/workspace/kafkajs/src/consumer/consumerGroup.js:317:7)\n    at async Runner.processEachMessage (/Users/tommybrunn/workspace/kafkajs/src/consumer/runner.js:181:7)\n    at async onBatch (/Users/tommybrunn/workspace/kafkajs/src/consumer/runner.js:298:9)\n    at async /Users/tommybrunn/workspace/kafkajs/src/consumer/runner.js:345:15"}
{"level":"INFO","timestamp":"2020-04-20T10:29:53.049Z","logger":"kafkajs","message":"[Consumer] Stopped","groupId":"test-group"}
{"level":"ERROR","timestamp":"2020-04-20T10:29:53.049Z","logger":"kafkajs","message":"[Consumer] Restarting the consumer in 303ms","retryCount":0,"retryTime":303,"groupId":"test-group"}

@Nevon Looks like unhandled rejection is not triggered on every run i think it is due to heartbeatInterval so i have change heartbeatInterval to 0 it also is important to have messages in the topic (probably good to have them on different partitions) after running few times looks like error appears more often than not (sometimes need to wait abit on each run). Also i have gone in to runner and on each place where we call await heartbeat() did a fake await new Promise((resolve, reject) => reject(new Error('Did not work'))) and looks like in some of the places it fails with unhandled rejection...

During my chaos testing was able to pull another unhanded rejection
(node:17090) UnhandledPromiseRejectionWarning: KafkaJSConnectionError: Not connected
    at Connection.failIfNotConnected (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/network/connection.js:352:13)
    at Connection.send (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/network/connection.js:275:10)
    at Broker.heartbeat (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/broker/index.js:314:34)
    at ConsumerGroup.heartbeat (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/consumer/consumerGroup.js:317:30)
    at concurrently (/Users/dmitrii/Desktop/Projects/at_connector_common/node_modules/kafkajs/src/consumer/runner.js:346:40)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:17090) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 169)

Just run version 1.12 and it works properly... Looks like it was introduced in some latest things...

@Nevon after debuging abit more have found out that this like causes some issues
https://github.com/tulios/kafkajs/blob/2faef0719eeba50759eccc2b7d8800dbe63803f3/src/consumer/runner.js#L348
Looks like it is throwing in to this lock which has not yet been awaited which means it will throw unhandled
https://github.com/goriunov/kafkajs/blob/c76c34663fbb53f8df419e925c901d98d6a6ff4e/src/consumer/runner.js#L318

@Nevon @tulios  found simpler way to reproduce issue. Change consumer to be something like that:
const run = async () => {
  await consumer.connect()
  await consumer.subscribe({ topic, fromBeginning: true })
  await consumer.run({
    partitionsConsumedConcurrently: 2,
    eachMessage: async ({ topic, partition, message }) => {
      throw new Error('Did not work')
    },
  })
}

Before running consumer it is important to have messages in multiple partitions and probably good to have quite abit of messages so pre publish some 😄
After running consumer it may work correctly for abit and than will fail with Unhandled promise rejection (due to parallel processing and not handling lock properly)
Please let me know if you can observe the issue now...

With the last example, for me, it reaches KafkaJSNumberOfRetriesExceeded and then restarts.

The code in question has seen quite some changes in the current unreleased version, so that would somewhat be expected I'd say.

@WaleedAshraf yeah i could not see that in 1.12 only on latest master can you try running on master and see if you can hit that bug.... With above example and few thousands messages in the topic and partitions i can reproduce every single time

Tested "kafkajs": "1.13.0-beta.15" but was not able to reproduce the issue.
I tested with some already published messages, by just consuming the topic like above. Also, I have a lot of partitions for one topic, maybe that makes some difference.

@WaleedAshraf interesting my one is always crashing may be i have different setup.....

@WaleedAshraf this logs is just a fork of master (latest) with only change in consumer example:
-> kafkajs dmitrii$ node examples/consumer.js
{"level":"INFO","timestamp":"2020-04-22T21:42:13.784Z","logger":"kafkajs","message":"[Consumer] Starting","groupId":"test-group"}
{"level":"INFO","timestamp":"2020-04-22T21:42:14.262Z","logger":"kafkajs","message":"[Runner] Consumer has joined the group","groupId":"test-group","memberId":"example-consumer-e8df5ed4-cd1b-47d4-9859-d1d3c9efc4e6","leaderId":"example-consumer-e8df5ed4-cd1b-47d4-9859-d1d3c9efc4e6","isLeader":true,"memberAssignment":{"xyz":[0,1,10,11,2,3,4,5,6,7,8,9]},"groupProtocol":"RoundRobinAssigner","duration":475}
{"level":"ERROR","timestamp":"2020-04-22T21:42:17.877Z","logger":"kafkajs","message":"[Runner] Error when calling eachMessage","topic":"xyz","partition":1,"offset":"155857815","stack":"Error: Did not work\n    at Runner.eachMessage (/Users/dmitrii/Desktop/github/kafkajs/examples/consumer.js:20:13)\n    at Runner.processEachMessage (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:164:20)\n    at onBatch (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:298:20)\n    at concurrently (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:345:21)\n    at invoke (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:38:5)\n    at push (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:51:7)\n    at Promise (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:60:53)\n    at new Promise (<anonymous>)\n    at action (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:60:20)\n    at batches.map.batch (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:335:11)"}
{"level":"ERROR","timestamp":"2020-04-22T21:42:17.878Z","logger":"kafkajs","message":"[Runner] Error when calling eachMessage","topic":"xyz","partition":10,"offset":"197257578","stack":"Error: Did not work\n    at Runner.eachMessage (/Users/dmitrii/Desktop/github/kafkajs/examples/consumer.js:20:13)\n    at Runner.processEachMessage (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:164:20)\n    at onBatch (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:298:20)\n    at concurrently (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:345:21)\n    at invoke (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:38:5)\n    at push (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:51:7)\n    at Promise (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:60:53)\n    at new Promise (<anonymous>)\n    at action (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:60:20)\n    at batches.map.batch (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:335:11)"}
{"level":"ERROR","timestamp":"2020-04-22T21:42:17.879Z","logger":"kafkajs","message":"[Runner] Error when calling eachMessage","topic":"xyz","partition":4,"offset":"177473653","stack":"Error: Did not work\n    at Runner.eachMessage (/Users/dmitrii/Desktop/github/kafkajs/examples/consumer.js:20:13)\n    at Runner.processEachMessage (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:164:20)\n    at onBatch (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:298:20)\n    at concurrently (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:345:21)\n    at invoke (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:38:5)\n    at waiting.push.override (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:55:9)\n    at next (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:30:7)\n    at action.then.result (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:41:9)\n    at process._tickCallback (internal/process/next_tick.js:68:7)"}
{"level":"ERROR","timestamp":"2020-04-22T21:42:17.879Z","logger":"kafkajs","message":"[Runner] Error when calling eachMessage","topic":"xyz","partition":7,"offset":"177816988","stack":"Error: Did not work\n    at Runner.eachMessage (/Users/dmitrii/Desktop/github/kafkajs/examples/consumer.js:20:13)\n    at Runner.processEachMessage (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:164:20)\n    at onBatch (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:298:20)\n    at concurrently (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:345:21)\n    at invoke (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:38:5)\n    at waiting.push.override (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:55:9)\n    at next (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:30:7)\n    at action.then.result (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:41:9)\n    at process._tickCallback (internal/process/next_tick.js:68:7)"}
process.on unhandledRejection
Unhandled promise rejection { error: 'Did not work',
  stack:
   'Error: Did not work\n    at Runner.eachMessage (/Users/dmitrii/Desktop/github/kafkajs/examples/consumer.js:20:13)\n    at Runner.processEachMessage (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:164:20)\n    at onBatch (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:298:20)\n    at concurrently (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:345:21)\n    at invoke (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:38:5)\n    at push (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:51:7)\n    at Promise (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:60:53)\n    at new Promise (<anonymous>)\n    at action (/Users/dmitrii/Desktop/github/kafkajs/src/utils/concurrency.js:60:20)\n    at batches.map.batch (/Users/dmitrii/Desktop/github/kafkajs/src/consumer/runner.js:335:11)' }
(node:99878) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 7)
{"level":"INFO","timestamp":"2020-04-22T21:42:19.940Z","logger":"kafkajs","message":"[Consumer] Stopped","groupId":"test-group"}

Yes, I might be a bug. Maybe I missed something when trying to reproduce. I Will ping here if I catch this error.

This is fixed #714

authors: Nevon WaleedAshraf ankon goriunov

repo: tulios/kafkajs


text:
Installation failed when there is a space in username of Windows

cp: cannot stat ‘/mnt/c/Users/Luo’: No such file or directory
cp: cannot stat ‘Yan/Desktop/alwsl.sfs’: No such file or directory

See https://github.com/turbo/alwsl/issues/10#issuecomment-247329795.

authors: huiyiqun minxomat

repo: turbo/alwsl


text:
[BUG] Speculative decoding regresses performance on 7900 xtx under ROCM

OS
Linux
GPU Library
AMD ROCm
Python version
3.12
Pytorch version
Pulled from https://download.pytorch.org/whl/rocm6.2 yesterday
Model
Qwen2.5-Coder-32B + Qwen2.5-Coder-1.5B as draft model
Describe the bug
When loading the Qwen2.5-Coder-32B model through Exui, I am getting around 20 tokens/s with a 4_25 bpw quant (unrelated, but this is also lacking compared to the 25+ I am seeing with llamacpp). However, when loading the 1.5B version of the model as a draft model, performance drops down to below 16 tokens/sec instead of experiencing a speedup. I do experience a speedup with llamacpp speculative decoding (a little over 2x).
Reproduction steps

Load the 32B model through exui
Ask for a story in a chat
See around 20 tokens/second
Unload the 32B model
Load the 32B model + 1.5B draft model
Ask for another story in a new chat

Expected behavior
A speed boost is obtained.
Actual outcome: The performance regresses.
Logs
No response
Additional context
No response
Acknowledgements

[X] I have looked for similar issues before submitting this one.
[X] I understand that the developers have lives and my issue will be answered when possible.
[X] I understand the developers of this program are human, and I will ask my questions politely.

Set lower max seq len, recommend 16k.

authors: Mushoz Originalimoc


text:
Exception trace

Show Exception Trace if debug = true

SQL Message, class and method removed.

repo: turbopixel/PHPDO-Database


text:
Create CHANGELOG.md

Checklist

[ ] Issue(s) linked

Added in https://github.com/turbot/flowpipe-mod-reallyfreegeoip/pull/8

repo: turbot/flowpipe-mod-reallyfreegeoip