text:
test: fix deadlocks in uv_cond_wait

Calling uv_cond_wait without uv_cond_signal/uv_cond_broadcast may
cause deadlock. This commit avoids this situation as well as tests
these functions.
Fixes: #712

Smoketest CI: https://ci.nodejs.org/job/libuv+any-pr+multi/257/

PR updated addressing @bnoordhuis comments. Thank you for the review.

@hrektts can you fix this one too?

Minor style issue: in libuv, each struct member is put on its own line.

Updated to fix style. Thanks!

LGTM. One more CI run just in case: https://ci.nodejs.org/job/libuv+any-pr+multi/260/

Sorry for the delay, landed in ca0b657, thanks!

authors: hrektts saghul


text:
Alpinelinux 029 test fails

Trying to upgrade to latest version I faced with failed test https://github.com/alpinelinux/aports/pull/11938
used to add debug information
--- 029.phpt.1	2019-11-26 18:06:12.979624226 +0200
+++ 029.phpt	2019-11-26 18:09:12.768886144 +0200
@@ -13,6 +13,7 @@
   $err = vips_call("add", $image, $rg);
   $msg = vips_error_buffer();

+var_dump($msg);
   if ($err == -1 &&
     $msg == "add: not one band or 3 bands\n") {
     echo "pass";

Not I see there's more then one message
$ cat 029.log

---- EXPECTED OUTPUT
pass
---- ACTUAL OUTPUT
string(106) "vips_realpath: unable to form filename
unix error: No such file or directory
add: not one band or 3 bands
"
---- FAILED

Cant fine where vips_realpath defined to catch error

That's curious, it works for me in Ubuntu. I'll try in an Alpine docker image.

@jcupitt thank you, please use alpine:edge image because it is where I faced with issue and new release (3.1) in progress of build

Hi again Andy,
It looks like it could be a problem with grsec:
https://www.openwall.com/lists/musl/2015/02/07/2
libvips is trying to canonicalise filenames with realpath(), realpath works by opening /proc/self/fd, and grsec will block that. This generates an error message which stops 029.php producing the expected output.
As a workaround, I agree, just delete this test.
Longer term, I've removed realpath from libvips:
https://github.com/libvips/libvips/commit/0bc49a485efd060b09bfd35d6f3da5a676efe894
So the test should start working again in 8.8.4 or later.
Thanks for reporting this!

@jcupitt Thank you a lot!

I did rebuild with 8.9.2 and now test passes!
Closing it, @jcupitt thanks again)

source: gharchive/issue

authors: andypost jcupitt

repo: libvips/php-vips-ext

license: MIT

license_type: permissive

license_source: github-api


text:
mean and std Norm ?

hi,dear 大佬
对于得到的视频帧数据为何进行固定mean和std参数的Norm处理啊？
codes is here
transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225])
这个有什么参考或者说依据吗？
多谢

@ucas010 这个就是预训练图像分类模型里做的预处理操作。
我直接用的预训练好的模型，所以follow这个预训练好的模型需要的预处理操作。
当然在i/vqa问题中，不做预处理操作也许更合适，但是这样需要自己预训练一个不需要预处理操作的图像分类模型。

@lidq92
多谢。
我对torch不太熟，但我发现tf训练的模型似乎都没有这个操作啊

@ucas010
早期的Caffe有减均值图像的做法，PyTorch的torchvision里提供的图像分类模型是有我代码里那个预处理操作的，可以看torchvision/models.html#classification。
至于TensorFlow，你可以自己再好好看看相关资料，以实际训练的时候的操作为准。比如我粗略搜了一下，你可以看看这两个文件preprocessing.py和imagenet_preprocessing.py。
我不使用TensorFlow，所以关于TensorFlow的具体细节你可以自己再深入看看。
祝好。


text:
Panic due to funding transaction rejected with "non-BIP68-final"

> openchannel 0227d8e3f25e4d991cc51a19782c0277904f1590db7da27b33bf96cca181022bd8@127.0.0.1:9737 1000000
EVENT: initiated channel with peer 0227d8e3f25e4d991cc51a19782c0277904f1590db7da27b33bf96cca181022bd8.
thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "Errored with status: 500 and contents: {\"result\":null,\"error\":{\"code\":-26,\"message\":\"non-BIP68-final\"},\"id\":\"129\"}\n" }', src/bitcoind_client.rs:241:88

Then on restart:
thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "Errored with status: 500 and contents: {\"result\":null,\"error\":{\"code\":-27,\"message\":\"Transaction already in block chain\"},\"id\":\"5\"}\n" }', src/bitcoind_client.rs:241:88

Matt's explanation: "yes, we currently are quite lazy and send transactions which conflict with ones we see on the chain (this addresses some super-theoretical basically nonsense cases around eclipse-style attacks) as well as ones which are not yet broadcastable as they are time-locked. in the second case, the docs currently say its the users' responsibility to rebroadcast the transactions until the timelock is reached (hence the "non-BIP68-final" error you see above), but I'd realllllyyyy like to change that requirement."
Before addressing this known issue, we'll want to get https://github.com/rust-bitcoin/rust-lightning/pull/642 merged, as the solution will heavily conflict.

This should be resolved now.

authors: TheBlueMatt valentinewallace

repo: lightningdevkit/ldk-sample


text:
Crash: FetchChanUpdates

After runnign lnd for quite a long time (more than month I think):
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0xc8f959]

goroutine 577 [running]:
main.(*chanSeries).FetchChanUpdates(0xc42021c160, 0x72b3f1b60a8ce26f, 0x4ff763ae46a2a6c1, 0x9c085ae165831e93, 0x19d668, 0x44400086506, 0x1790001, 0x1, 0xc4322d1700, 0x405d2b, ...)
        /home/lightning/go/src/github.com/lightningnetwork/lnd/chan_series.go:300 +0x459
github.com/lightningnetwork/lnd/discovery.(*gossipSyncer).FilterGossipMsgs(0xc42014c2d0, 0xc42049f680, 0x19, 0x19)
        /home/lightning/go/src/github.com/lightningnetwork/lnd/discovery/syncer.go:865 +0x88a
github.com/lightningnetwork/lnd/discovery.(*AuthenticatedGossiper).networkHandler(0xc420226300)
        /home/lightning/go/src/github.com/lightningnetwork/lnd/discovery/gossiper.go:1185 +0x12c3
created by github.com/lightningnetwork/lnd/discovery.(*AuthenticatedGossiper).Start
        /home/lightning/go/src/github.com/lightningnetwork/lnd/discovery/gossiper.go:444 +0x19c

Your environment

version of lnd: 0.5.0-beta commit=fb95858afce6d7129758e7677bcb1552c5be2c51
operating system: Debian stable Linux <hostname censored> 3.16.0-4-amd64 #1 SMP Debian 3.16.51-2 (2017-12-03) x86_64 GNU/Linux
bitcoind -version: v0.16.3
lnd runs under a different user than bitcoind

Steps to reproduce
Unknown, just ran the node
Expected behaviour
Not crashing
Actual behaviour
Crash
Sorry if this was filed somewhere already, I didn't find anything similar.

This is fixed in the latest release.

authors: Kixunil wpaulino

repo: lightningnetwork/lnd


text:
fuzz: upgrade to testing.F

The fuzz tests we have don't run on my machine anymore with go1.18. dvyukov/go-fuzz is basically deprecated at this point. We should upgrade to language-native testing.F even if it's not that great yet.
Basically the fuzz tests should stay the same, but the build step is changed:

remove make-level fuzz references
fuzz tests that don't need to import from other packages can live in the same package they test (lnwire)
fuzz tests that require testing more complex state will likely need to live in a top-level fuzz package
these should probably be behind build flags since we still support 1.17

It might be better to move a package at a time to ease review

Hello, new here. Thought this would be a good first issue for me. Just made a commit migrating lnwire: https://github.com/babinchak/lnd/commit/1c7cd98f40a6bda99adb2b00c58ba66a1ec8c4ff
Working on migrating brontide, wtwire, and zpay32 to make my first pull request.
For now, I put all the tests from fuzz/lnwire/*.go to a single lnwire/fuzz_test.go file, preserving order.
Let me know if you think I should organize/write the tests different.

Migrated wtwire, similar to lnwire: https://github.com/babinchak/lnd/commit/520afde240b8ec77f131698cad52aaacb39065a0

Migrated zpay32
Fuzzed encode and decode for 30s each successfully. Want to know good seed corpus values.

Migrated brontide: https://github.com/babinchak/lnd/commit/27591d07a9d15659837d35dda5ce4b3ea6874440

diff that might help visualize brontide migration: https://github.com/babinchak/lnd/compare/f3a67bd..33dc5e5
Just using github as a diff tool, the commits in diff_demo branch aren't actual changes

Might need help writing function comments for fuzz tests in lnwire, wtwire, and zpay32. Brontide's fuzz test comments were detailed so I copied them but the other packages were not.

authors: Crypt-iQ babinchak


text:
[lncli] rpc error: code = Unknown desc = edge not found

Background
On a daily bases i check my node on amboss and spotted nicehash channel have the status  stated that my node have disable the channel.

but on my end( in my node ) the status was online

Your environment

Lightning node : 0.15.0-beta
OS : Umbrel
BTC node : 22.0-build-2

Steps to reproduce
i try running the below command
lncli updatechanstatus d5cde60872614da1062643c1b9de5339f2e9855e6071c7bce58ec1bffa0b53bb --action enable
and got the error : [lncli] rpc error: code = Unknown desc = edge not found
so i am wondering is it my node issue or something?

if you use lncli listchannels does it show the channel as active?
worth noting that enabling/disabling is directional. So perhaps they just disabled the direction from them to you. But that would not explain why you get the edge not found error

in the command you have above, you aren't passing the vout (output_index).

Closing as per the comment above, thanks for noticing, @SachinMeier.
You can also use the --chan_point flag which takes the format txid:output_index.

authors: LStratos SachinMeier ellemouton guggero


text:
mod: bump tor submodule to v1.1.1

Depends on https://github.com/lightningnetwork/lnd/pull/7782.
Fixes https://github.com/lightningnetwork/lnd/issues/6493.

Needs a rebase then g2g!

source: gharchive/pull-request

authors: Roasbeef guggero


text:
Unexpected result when parsing of too big integer or floating point numbers without dot as numeric primitives

scala> upickle.default.read[Byte]("999")
res0: Int = -25

scala> upickle.default.read[Byte]("0e0")
res1: Int = 18

scala> upickle.default.read[Short]("99999")
res2: Short = -31073

scala> upickle.default.read[Short]("0e0")
res3: Short = 530

scala> upickle.default.read[Char]("99999")
res4: Char = 蚟

scala> upickle.default.read[Char]("0e0")
res5: Char = Ȓ

scala> upickle.default.read[Int]("9999999999")
res6: Int = 1410065407

scala> upickle.default.read[Int]("0e0")
res7: Int = 530

scala> upickle.default.read[Long]("0e0")
res8: Long = 530

Handling of exponents is fixed by https://github.com/lihaoyi/upickle/commit/1d4ae8e066292a14e4f958953228ef1ba31bd097, going to call integer overflow and wrap-around a wontfix since it matches what most bespoke handling of integer parsing is going to do anyway

authors: lihaoyi plokhotnyuk

repo: lihaoyi/upickle


text:
Replace timeouts with ctx

https://pkg.go.dev/context
Functions should use ctx as argument. Context should be passed around (using DialContext ¶ instead of Dial), or checked with ctx.Done.

Hello @jtagcat
Thanks for your feedback, I will do it.

If you think this repository is helpful, please share it with friends, thanks.

Thanks for your feedback @likexian (and for this great lib)!
Having context support is important for us.
Is there anything we can do to help this be implemented?

authors: gnuletik jtagcat likexian

repo: likexian/whois


text:
Add the aarch64 cloud image for tumbleweed

Don't need to use the old "JeOS" anymore.
And remove the references to closed issues.
Issue #2611

And remove the references to closed issues.

I wonder if Tumbleweed should be moved from experimental to the regular directory?

authors: afbjorklund jandubois

repo: lima-vm/lima


text:
Code re-org: data loading

The data loading should be generalized more to deal with different datasets.  Changes can go under /src/deepdisc/data_format/. The way data is loaded in the detectron2 framework is described here [https://detectron2.readthedocs.io/en/latest/tutorials/data_loading.html]

A function is built to read in all the metadata from memory and is passed to the DatasetCatalog.register() method to register it.  This function should return a list[dict] Right now this function is get_data_from_json. It assumes the metadata is saved as a json list of dicts, formatted in the COCO format (see https://detectron2.readthedocs.io/en/latest/tutorials/datasets.html).  Images are not stored in the dictionaries, only filepaths to the images.
The train_mapper_cls class will take as input a single item from the list[dict].  It will use the image filepath to read in the image using some function, apply augmentations, store it in the dictionary and slightly change the format of the dictionary metadata.  This new dictionary that contains the image and reformatted metadata is what is fed into the model.  Right now the function to read in images in the train_mapper_cls is the read_image_hsc function inside astrodet/astrodet.

Both functions in step 1 and 2 should be easily customizable to deal with different dataset formats.  I think having some general base class for step 1 for reading in data and returning a list[dict] would be useful.  Also a base class for reading in image data would also be useful.  This would address much of issue #30.

[ ] Generalize get_data_from_json to class that has a method to read in all metadata and output it in coco dict format
[ ] Generalize the read_image methods to a class that will take a user specified function, apply some scaling, and return an image based on a key found in the dictionary output from step 1.

@grantmerz, what are some of the other dataset formats we want to support beyond the json/COCO format?

For the most part, code should stick with list[dict] COCO format. For example, if you look at demo_decam.ipynb, there is a get_astro_dicts function that outputs a list[dict] after manually reading in files and formatting everything to COCO format.  Below it, there is a get_data_from_json function that reads in a COCO pre-formatted json file and returns a list[dict]. Since these output the same thing, my vision was to have a common class for them. The user would still have to write the code in get_astro_dicts since image files may be formatted differently.  But it would be useful to have the option to customize this portion and output a list[dict] that doesn't adhere to COCO format.

The utility is that if we want to generalize this for other models, we can still use the data loading tools that assume list[dict] but the dict can contain whatever data those other models need

As a small status update. I've been working on this here: https://github.com/lincc-frameworks/deepdisc/blob/data_loader/src/deepdisc/data_format/file_io.py#L12
The main idea being that the DataLoader class has a generate_filedict function which reads in filenames from a given directory. It's generalizable to the extent of being able to handle DECAM and HSC data within the same API. The output is standardized and then can be fed into generate_dataset_dict to pass the image and mask files along to user-defined functions. The result is a list of whatever output is produced by the UDF at the moment. I also plan on potentially adding the canned get_astro_dict() functions from the DECAM and HSC notebooks as available on-hand functions here, modified to work with the format being passed along to the UDFs.
The list[dict] format can also be gotten directly from a file, like get_data_to_json if it's available.
Plan to keep working on this tomorrow, and actually trying this code will almost certainly not work as I've yet to start using it in any capacity. Let me know if this looks totally off-base from what is being requested.

I like the way this is structured.  It would be nice to change the self.dataset_dicts to a self.dataset property.  This is to indicate that the class should be able to output data that might not be in dictionary format, for instance a loaded numpy array of all images+metadata.  This output is reformatted in the DataMapper class which feeds directly into the model, so it's ok if the output data from DataLoader isn't necessarily a dictionary (it just needs to be indexable for pytorch backend). Then, have a general method that users can provide a custom function to for loading the dataset.  This way, the user could insert a loading function (like np.load/get_data_from_json).  Maybe the generate_dataset_dict function could be part of a ScarletDataLoader subclass

authors: dougbrn grantmerz

repo: lincc-frameworks/deepdisc


text:
Crash in libamplituda-native-lib.so

/lib/arm64/libamplituda-native-lib.so (Java_linc_com_amplituda_Amplituda_amplitudesFromAudioJNI+868) (BuildId: 72a4899b05ffbd6f588f1c352f33364c6ef73a9d)
When attempting to load an amplitude of corrupted file AFTER successful processing another non-corrupted one I get uncatchable crash

Similar to #68

authors: karlovm thedroiddiv

repo: lincollincol/Amplituda


text:
Intermittent test failure in ZooKeeperRegistrationTest

com.linecorp.armeria.server.zookeeper.ZooKeeperRegistrationTest > testServerNodeCreateAndDelete FAILED
    java.util.concurrent.CompletionException: io.netty.channel.unix.Errors$NativeIoException: bind(..) failed: Address already in use
        at java.base/java.util.concurrent.CompletableFuture.reportJoin(Unknown Source)
        at java.base/java.util.concurrent.CompletableFuture.join(Unknown Source)
        at com.linecorp.armeria.common.util.EventLoopCheckingFuture.join(EventLoopCheckingFuture.java:70)
        at com.linecorp.armeria.server.zookeeper.ZooKeeperRegistrationTest.startServers(ZooKeeperRegistrationTest.java:67)
        Caused by:
        io.netty.channel.unix.Errors$NativeIoException: bind(..) failed: Address already in use

ZooKeeperRegistrationTest > legacyZooKeeperRegistrationSpec() FAILED
    org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a com.linecorp.armeria.server.zookeeper.ZooKeeperRegistrationTest null within 10 seconds.
        at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
        at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
        at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
        at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
        at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
        at com.linecorp.armeria.server.zookeeper.ZooKeeperRegistrationTest.legacyZooKeeperRegistrationSpec(ZooKeeperRegistrationTest.java:79)

        Caused by:
        java.util.concurrent.TimeoutException
            at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
            at org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
            at org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
            at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:102)
            ... 5 more

repo: line/armeria


text:
Use prettier-java or google-java-format for formatting code

We currently use our own IntelliJ code style which is largely based on my personal taste. The resulting code looks fine, but it requires a contributor to configure the IDE properly first, because otherwise he or she will get a Checkstyle violation, which can be very annoying until getting used to our code style.
It's probably time to look for a solution to lower the contribution barrier and prevent the annoyances we have when we encounter a build failure because of extra (or missing) spaces.

prettier-java - https://github.com/jhipster/prettier-java

Pros:

Based on Prettier
Customizable

Cons:

Based on Prettier - need to configure Node.js
No IntelliJ IDEA support
No Gradle plugin

google-java-format - https://github.com/google/google-java-format

Pros:

More users, well-known
IntelliJ IDEA support
Gradle plugin

Cons:

Not very customizable

spring-javaformat - https://github.com/spring-io/spring-javaformat

Pros:

Spring means bigger community
IntelliJ IDEA support
Gradle plugin

Cons:

Relatively new
Not very customizable

Doesn't #2247 come before this? ;)

Haha yeah, we need to take care of that as well!

authors: anuraaga trustin


text:
Log socket traffic at TRACE level

Motivation:
It is sometimes necessary to investigate protocol-level traffic to
figure out the root cause of the problem.
Modifications:

Add a Netty handler 'TrafficLoggingHandler` which logs the traffic at
TRACE level

Server-side traffic is logged at
'com.linecorp.armeria.traffic.server'.
Client-side traffic is logged at
'com.linecorp.armeria.traffic.client'.
Note that the TrafficLoggingHandler is always added to
ChannelPipeline so that a user can turn the logging on or off at
runtime.

Result:
A user can look into the socket traffic easily without modifying Armeria
source code and inserting Netty LoggingHandler. In Logback, a user can
add the following configuration to enable traffic logging:
<logger name="com.linecorp.armeria.traffic" level="TRACE" />

To enable traffic logging for server or client side only:
<logger name="com.linecorp.armeria.traffic.client" level="TRACE" />
<!-- or -->
<logger name="com.linecorp.armeria.traffic.server" level="TRACE" />

Example log:
15:20:10.094 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] ACTIVE
15:20:10.094 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] RECEIVED: 201B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 48 45 41 44 20 2f 20 48 54 54 50 2f 31 2e 31 0d |HEAD / HTTP/1.1.|
|00000010| 0a 68 6f 73 74 3a 20 31 32 37 2e 30 2e 30 2e 31 |.host: 127.0.0.1|
|00000020| 3a 36 34 36 33 33 0d 0a 75 73 65 72 2d 61 67 65 |:64633..user-age|
|00000030| 6e 74 3a 20 61 72 6d 65 72 69 61 2f 30 2e 32 36 |nt: armeria/0.26|
|00000040| 2e 32 2e 46 69 6e 61 6c 2d 53 4e 41 50 53 48 4f |.2.Final-SNAPSHO|
|00000050| 54 0d 0a 75 70 67 72 61 64 65 3a 20 68 32 63 0d |T..upgrade: h2c.|
|00000060| 0a 48 54 54 50 32 2d 53 65 74 74 69 6e 67 73 3a |.HTTP2-Settings:|
|00000070| 20 41 41 45 41 41 42 41 41 41 41 49 41 41 41 41 | AAEAABAAAAIAAAA|
|00000080| 42 41 41 4e 5f 5f 5f 5f 5f 41 41 51 41 41 50 5f |BAAN_____AAQAAP_|
|00000090| 5f 41 41 55 41 41 45 41 41 41 41 5a 5f 5f 5f 5f |_AAUAAEAAAAZ____|
|000000a0| 5f 0d 0a 63 6f 6e 6e 65 63 74 69 6f 6e 3a 20 48 |_..connection: H|
|000000b0| 54 54 50 32 2d 53 65 74 74 69 6e 67 73 2c 55 70 |TTP2-Settings,Up|
|000000c0| 67 72 61 64 65 0d 0a 0d 0a                      |grade....       |
+--------+-------------------------------------------------+----------------+
15:20:10.110 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 90B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 48 54 54 50 2f 31 2e 31 20 31 30 31 20 53 77 69 |HTTP/1.1 101 Swi|
|00000010| 74 63 68 69 6e 67 20 50 72 6f 74 6f 63 6f 6c 73 |tching Protocols|
|00000020| 0d 0a 63 6f 6e 6e 65 63 74 69 6f 6e 3a 20 75 70 |..connection: up|
|00000030| 67 72 61 64 65 0d 0a 75 70 67 72 61 64 65 3a 20 |grade..upgrade: |
|00000040| 68 32 63 0d 0a 63 6f 6e 74 65 6e 74 2d 6c 65 6e |h2c..content-len|
|00000050| 67 74 68 3a 20 30 0d 0a 0d 0a                   |gth: 0....      |
+--------+-------------------------------------------------+----------------+
15:20:10.112 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 9B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 04 00 00 00 00 00                      |.........       |
+--------+-------------------------------------------------+----------------+
15:20:10.113 [armeria-server-nio-4-1] DEBUG c.l.a.s.http.Http1RequestDecoder - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] Handling the pre-upgrade request (h2c): HEAD / HTTP/1.1 (0B)
15:20:10.146 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 14B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 22 01 25 00 00 00 01 00 00 00 00 0f       |..".%.........  |
+--------+-------------------------------------------------+----------------+
15:20:10.147 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 29B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 48 03 34 30 35 5f 92 49 7c a5 8a e8 19 aa fb 50 |H.405_.I|......P|
|00000010| 93 8e c4 15 30 5a 99 56 7b 5c 02 32 32          |....0Z.V{\.22   |
+--------+-------------------------------------------------+----------------+
15:20:10.151 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] RECEIVED: 42B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 50 52 49 20 2a 20 48 54 54 50 2f 32 2e 30 0d 0a |PRI * HTTP/2.0..|
|00000010| 0d 0a 53 4d 0d 0a 0d 0a 00 00 00 04 00 00 00 00 |..SM............|
|00000020| 00 00 00 00 04 01 00 00 00 00                   |..........      |
+--------+-------------------------------------------------+----------------+
15:20:10.151 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 9B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 04 01 00 00 00 00                      |.........       |
+--------+-------------------------------------------------+----------------+
15:20:10.162 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] RECEIVED: 84B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 4b 01 24 00 00 00 03 00 00 00 00 0f 83 84 |..K.$...........|
|00000010| 41 8b 08 9d 5c 0b 81 70 dc 71 a7 19 67 86 5f 9c |A...\..p.q..g._.|
|00000020| 1d 75 d0 62 0d 26 3d 4c 79 59 33 d8 69 53 f6 a5 |.u.b.&=LyY3.iS..|
|00000030| 76 1d 27 21 e8 83 7d dc 9a 61 db cf 7a 96 1d 94 |v.'!..}..a..z...|
|00000040| 96 c3 0d 80 2e 27 17 12 f8 4d 50 e8 5b 76 98 75 |.....'...MP.[v.u|
|00000050| ee c7 ab 7f                                     |....            |
+--------+-------------------------------------------------+----------------+
15:20:10.166 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] RECEIVED: 35B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 1a 00 00 00 00 00 03 80 01 00 01 00 00 00 |................|
|00000010| 05 68 65 6c 6c 6f 00 00 00 00 0b 00 01 00 00 00 |.hello..........|
|00000020| 01 61 00                                        |.a.             |
+--------+-------------------------------------------------+----------------+
15:20:10.167 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] RECEIVED: 9B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 00 01 00 00 00 03                      |.........       |
+--------+-------------------------------------------------+----------------+
15:20:10.177 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 14B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 28 01 24 00 00 00 03 00 00 00 00 0f       |..(.$.........  |
+--------+-------------------------------------------------+----------------+
15:20:10.177 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 35B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 88 5f 9c 1d 75 d0 62 0d 26 3d 4c 79 59 33 d8 69 |._..u.b.&=LyY3.i|
|00000010| 53 f6 a5 76 1d 27 21 e8 83 7d dc 9a 61 db cf 5c |S..v.'!..}..a..\|
|00000020| 02 33 31                                        |.31             |
+--------+-------------------------------------------------+----------------+
15:20:10.178 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 9B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 1f 00 00 00 00 00 03                      |.........       |
+--------+-------------------------------------------------+----------------+
15:20:10.178 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 31B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 80 01 00 02 00 00 00 05 68 65 6c 6c 6f 00 00 00 |........hello...|
|00000010| 00 0b 00 00 00 00 00 06 6e 6f 6e 65 3a 61 00    |........none:a. |
+--------+-------------------------------------------------+----------------+
15:20:10.178 [armeria-server-nio-4-1] TRACE com.linecorp.armeria.traffic.server - [id: 0x79dc575e, L:/127.0.0.1:64633 - R:/127.0.0.1:64651] WRITE: 9B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 00 01 00 00 00 03                      |.........       |
+--------+-------------------------------------------------+----------------+

Current coverage is 65.42% (diff: 94.44%)

Merging #292 into master will increase coverage by 0.05%

@@             master       #292   diff @@
==========================================
  Files           306        307     +1
  Lines         12079      12097    +18
  Methods           0          0
  Messages          0          0
  Branches       1776       1778     +2
==========================================
+ Hits           7897       7915    +18
+ Misses         3345       3343     -2
- Partials        837        839     +2

Powered by Codecov. Last update 618d5f3...03e8b17

authors: codecov-io trustin


text:
Add JDK21 to CI build target

JDK21 is now GA https://jdk.java.net/21/release-notes

Hi @ocadaruma, can I work on this?

@thachlp Sorry for the late reply.
Thank you for your interest!
However this issue may likely be solved by https://github.com/line/decaton/pull/224

Thanks for your information 😀

authors: ocadaruma thachlp

repo: line/decaton


text:
Add FromStr for DynamicColor and static colors

This makes it easier to parse them from a string with more concise code and not requiring a separate import of parse_color.

If we like this idea, then I'd add tests to the PR.

This would improve code in Vello's pico_svg as well as my current patches to svgtypes.

repo: linebender/color


text:
mess when run example

command:
cargo run --example widget_gallery --features="svg im image png"
os:
windows 10

command:
cargo run --example text

That doesn't look great :grimacing: It seems like an issue with incorrect invalidation/repainting.
Are you able to bisect to figure out the problematic commit? I can't reproduce this on linux.

authors: jneem skydig

repo: linebender/druid


text:
Add type_name to panic error messages in WidgetPod

Hey, just started tinkering with Druid and think that it could work well for my current project. Even though it's "discontinued", I'd like to start contributing to soften some of the rough edges while Xilem gets off the ground.
This PR introduces a super small change, adding the typename to the panic messages. I ran into this while running down a another bug in my app. I couldn't make heads or tails about which component was causing issues because WidgetPod is used under the hood in so many places. I think adding information. about which type is experiencing the panic will be helpful to others, too.

I haven't tested this, but this looks valuable to me.

Thanks for the PR! It looks like some auto-formatter got run on the changelog, right? Seems harmless, though...
Edit: it looks like we'll have to figure out the CI failures, though... my initial guess is that some mac dependency broke semver...

thanks, I removed the unnecessary formatting. I'll merge when CI is green.

authors: jaredoconnell matthewgapp


text:
Add Wayland dev package dependency info to README.md.

I just did a fresh Ubuntu 23.04 install and was greeted with the following error when attempting to build with the wayland feature:
error: failed to run custom build command for `wayland-sys v0.30.1`

Caused by:
  process didn't exit successfully: `/home/strom/Rust/glazier/target/debug/build/wayland-sys-23ce904e0e81cf94/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=WAYLAND_CLIENT_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=WAYLAND_CLIENT_STATIC
  cargo:rerun-if-env-changed=WAYLAND_CLIENT_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: `PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" PKG_CONFIG_ALLOW_SYSTEM_LIBS="1" "pkg-config" "--libs" "--cflags" "wayland-client"` did not exit successfully: exit status: 1
  error: could not find system library 'wayland-client' required by the 'wayland-sys' crate

  --- stderr
  Package wayland-client was not found in the pkg-config search path.
  Perhaps you should add the directory containing `wayland-client.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'wayland-client', required by 'virtual:world', not found
  ', /home/strom/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wayland-sys-0.30.1/build.rs:10:47
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed

Doing apt install libwayland-dev solved the issue and so this PR adds that info to the readme here. I didn't test Fedora, I just looked up the package name.

Thanks! Seems an obvious thing to miss. For reference, this is a consequence of adopting raw-window-handle (and more generally, being able to use Vulkan to render to surfaces). Ideally, the Vulkan spec would support this in a different way, but that seems very unlikely
I haven't checked this on Fedora out due to being on mobile.

authors: DJMcNab xStrom

repo: linebender/glazier


text:
Don't encode empty glyph

This fixes artifacts we are seeing in porting the "shello" demo to glazier, which was caused by appending glyphs with empty paths to the scene fragment. It's not obvious to me this is the best fix, as it could be done higher up by special casing glyphs with empty outlines, or lower down by allowing correct encoding of empty paths.
So partly it's a discussion of how to best fix the problem. I think a case can be made we shouldn't include empty paths in the encoding (though they can be made valid and evaluated correctly). It's likely that similar problems remain with empty paths made through the path building mechanism.

Closing this because #200 does it better.

repo: linebender/piet-gpu


text:
The preprocess code is duplicated

The same code is used twice:

In crates/shaders/src/compile/preprocess.rs
In src/shaders/preprocess.rs

According to Raph, this is because the vello_shaders is meant for Skia integration, and currently isn't used by Vello.
We should fix that and remove the duplication.

We always intended for the main Vello crate to use vello_shaders but never got around to it. The crate supports generating native shaders (such as MSL) from the WGSL which allows external engines to target Metal, Vulkan, etc directly. This code path isn't exercised in the Vello repository but we have wanted to have native runners (i.e. alternative engines alongside wgpu) eventually but decided to put that in the backburner due to other priorities.
I think this issue can be repurposed as "Move to shader management via crates/shaders".

authors: PoignardAzur armansito

repo: linebender/vello


text:
[test_scenes] Port longpathdash test case from Skia

This is a single very long path that results in a large number of line segments when dashing is applied. This demonstrates rendering artifacts.

I've not had a chance to run this yet - can you include a screenshot?

Yes of course!
This is the expected shape with butt caps:

This is the same butt cap render showing artifacts when it's zoomed out:

This is the same shape with round caps (which increases the line segment count) showing artifacts at a moderate zoom level:

The latter can be fixed by increasing the bump buffer sizes. I'm treating this as a pathological case with a very high memory requirement. The zoomed out case appears regardless of the size of the bump buffers so that's probably a separate issue.


text:
Release ci

copilot:all

🤖 Generated by lychee action
Summary

Status
Count

🔍 Total
981

✅ Successful
378

⏳ Timeouts
0

🔀 Redirected
0

👻 Excluded
601

❓ Unknown
0

🚫 Errors
1

Errors per input
Errors in README.md

[404] https://sealos.io/zh-Hans/pricing | Failed: Network error: Not Found

Full action output
Full Github Actions output

repo: lingdie/sealos


text:
add name to contributors.html and add small style to index.html

Hi, would you add small changes? :)

Yes for sure :)

authors: BennyCarlsson vamisola

repo: lingonsaft/hacktoberfest


text:
fix: fix build definition of DatasetFieldUrn

Checklist

[x] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable)

You don't need changes in DatasetFieldUrnTest.java ?

They still pass, no

repo: linkedin/datahub


text:
Initial commit for ETL-3803: remove topic conception from compaction

@zliu41 Can you review?

Updated with some fix. Tested in Azkaban with regular compaction, late data movement, and recompaction.

Please resolve conflicts.

@zliu41 Updated.

@zliu41 Updated.

@zliu41 Updated.

@zliu41 Updated.

@ydai1124 can you please describe the high-level design in the PR description?

@chavdar Changed both title and description.

@chavdar @zliu41 Moved dataset and datasetFinder to gobblin-api. @ibuenros Can you also take a look on the last commit?

LGTM

repo: linkedin/gobblin


text:
KAFKA-8583: Optimization for SslTransportLayer#write(ByteBuffer)

Warp data as many as possible in SslTransportLayer#write(ByteBuffer)
The change comes from Ambry, whose TransportLayer code is same with Kafka.
https://github.com/linkedin/ambry/pull/1105
More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Can you provide a more readable explanation of your change?  What do you mean by "warp"?

Also if this is not a hot fix (i.e. we don't need it to fix something immediately)  then why not just submit this to upstream Kafka and go though their process.  We will cherry pick it or rebase on changes on top of this.

authors: smccauliff zzmao

repo: linkedin/kafka


text:
[Clean up] Enhance TableSizeReader to reduce the logs

In MultiGetRequest, log a warning for failed GET request (there is no way to get the failed url info from the caller side because we don't keep the order of URLS in CompletionService)
In TableSizeReader, if there are missing segments from all servers, log only one lines with all missing segments
Also fixed the issue where getResponseBodyAsStream should be used instead of getResponseBodyAsString for large size response

Codecov Report

Merging #3328 into master will increase coverage by 0.01%.
The diff coverage is 88.88%.

@@             Coverage Diff              @@
##             master    #3328      +/-   ##
============================================
+ Coverage     70.79%   70.81%   +0.01%
  Complexity        4        4
============================================
  Files           984      984
  Lines         45369    45344      -25
  Branches       6092     6086       -6
============================================
- Hits          32121    32110      -11
+ Misses        11135    11124      -11
+ Partials       2113     2110       -3

Impacted Files
Coverage Δ
Complexity Δ

...ntroller/helix/core/PinotHelixResourceManager.java
59.83% <0%> (+0.24%)
0 <0> (ø)
:arrow_down:

...ler/api/resources/PinotSegmentRestletResource.java
29.41% <0%> (ø)
0 <0> (ø)
:arrow_down:

...inkedin/pinot/controller/util/TableSizeReader.java
96.07% <100%> (+1.96%)
0 <0> (ø)
:arrow_down:

...om/linkedin/pinot/common/http/MultiGetRequest.java
100% <100%> (+5%)
0 <0> (ø)
:arrow_down:

...ontroller/api/resources/ServerTableSizeReader.java
97.22% <100%> (+19.72%)
0 <0> (ø)
:arrow_down:

...ot/core/realtime/stream/PartitionCountFetcher.java
54.16% <0%> (-20.84%)
0% <0%> (ø)

...e/operator/dociditerators/SortedDocIdIterator.java
54.05% <0%> (-10.82%)
0% <0%> (ø)

...kedin/pinot/core/util/SortedRangeIntersection.java
83.82% <0%> (-7.36%)
0% <0%> (ø)

...e/impl/dictionary/LongOnHeapMutableDictionary.java
82.22% <0%> (-6.67%)
0% <0%> (ø)

...impl/dictionary/DoubleOnHeapMutableDictionary.java
68.88% <0%> (-6.67%)
0% <0%> (ø)

... and 27 more

Continue to review full report at Codecov.

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

authors: Jackie-Jiang codecov-io

repo: linkedin/pinot

license_source: bigquery


text:
Add singlefile archive docs

Documentation for linkwarden/linkwarden#525

Umm, it looks a bit messy. How come that the main has commits that dev doesn't?

We went for Monolith for archiving the webpages since it was easier to implement, and that doesn't need any docs since Docker is already handling it, manual installers can also just install Monolith separately.
But thanks for the work @rutkai!
I'll be releasing everything soon.

repo: linkwarden/docs


text:
How do you import this in React?

I use ES6 import import { BackgroundVideo } from "background-video";, it shows error TypeError: Cannot call a class as a function. How can we import this?

Anyone ever figure this out?

Did you try import BackgroundVideo from "background-video"; ?

Yes, I get the same error as above.

Did you try import BackgroundVideo from "background-video"; ?

Of course.
To be he honest I need to spend a bit of time re-factoring this as it's very old and unmaintained currently.
For now I'd recommend importing the dist (import my/path/to/backgroundVideo/dist/backgroundVideo.js). I've never tested it with React as this was a pure JS solution when I made it.
I'll try and find some time if someone wants to make a PR I'd be happy to review.

Unfortunately that yeilds the same result. I guess it has to do with how the module is created; I'd love to make a PR but this is honestly not in my wheelhouse. Any work on this would be super appreciated!

I know how to fix but it's time. I'll do my best to find some
On Tue, 19 Feb 2019, 22:22 23twenty <notifications@github.com wrote:

Unfortunately that yeilds the same result. I guess it has to do with how
the module is created; I'd love to make a PR but this is honestly not in my
wheelhouse. Any work on this would be super appreciated!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/linnett/backgroundVideo/issues/40#issuecomment-465335267,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACI_wefcQ2sv0_3jKq0VOMG3e9LsSCRoks5vPHkbgaJpZM4ZjYyS
.

Same in VueJS

repo: linnett/backgroundVideo

license: mit


text:
page.keyboard.press("Tab") input "Tab" as text

Steps to reproduce
import { launch } from "https://deno.land/x/astral@0.3.5/mod.ts";
const browser = await launch();
const page = await browser.newPage('https://google.com');
await page.keyboard.type("Tab");

Expected behavior
Press tab key
Actual behavior
Type "Tab"

Does await page.keyboard.type("\t"); work?

import { launch } from "https://deno.land/x/astral@0.3.5/mod.ts";
const browser = await launch();
const page = await browser.newPage(
  "https://news.ycombinator.com/login?goto=news",
);
await page.keyboard.type("a\tb\tc\td");

Hm, appears to work?

Expected behavior in that case is focus movement, so
a
b
c
d

Is the expected behavior consistent with the behavior of other tools (e.g. puppeteer, playwright, etc)? Perhaps we could have something like page.accessibility.tabNext()?

I don't know about puppeteer or playwright behavior, so I simply used "Tab" because it was type hinted.
However, I have noticed other constants present there. If you decide to add tabNext, you should first remove that hint.

authors: jeiea lino-levan

repo: lino-levan/astral


text:
Implement components for common information

We need something for loading:

[ ] Plan names
[ ] Datacenters
[ ] Backups
[ ] Sources
[ ] Warning button /!\

We definitely don't want to call a plan Linode 1024 in one place and Linode 1GB in another.

@caker we need a call on the distinction between "Linode 1024" and "Linode 1G" (or 2G I guess :wink:)

My vote is for 1G. It makes it much easier for all plans - big and small.

authors: SirCmpwn eatonphil na3d

repo: linode/manager


text:
Update PAT edit test

Missed this in @martinmckenna's PR, updating the test to account for the new action menu name

yarn && yarn start
yarn selenium
yarn e2e:modified --browser=headlessChrome # run headless if you want it to be non-intrusive

Coverage remained the same at 26.475% when pulling 24e42b15a210a019b204acac257f64533330e0c6 on patthiel:tokens-test-fix into f564c86312afff91cb545044125405e8730d9559 on linode:develop.

authors: coveralls patthiel


text:
Add timeout setting for Slacker

There are serveral parameters for slacker:
slacker.Slacker(token,
                incoming_webhook_url=None,
                timeout=DEFAULT_TIMEOUT,
                http_proxy=None,
                https_proxy=None,
                session=None,
                rate_limit_retries=DEFAULT_RETRIES)

However, in the previous code, only token is passed to slacker, and
timeout could not be set. It uses DEFAULT_TIMEOUT in slacker, which
is 10 seconds, not enough for slackbot to upload large file (20MB
video for example).
In this commit, timeout could be set in settings as token. Bot()
would pass it to SlackClient and to Slacker if TIMEOUT exists in
settings.

👍

This could use a test...
def test_init_with_timeout():
    client = SlackClient(None, connect=False)
    assert client.webapi.api.timeout == 10  # seconds default timeout

    expected_timeout = 42  # seconds
    client = SlackClient(None, connect=False, timeout=expected_timeout)
    assert client.webapi.api.timeout == expected_timeout

add to tests/unit/test_slackclient.py

@townie Thanks, I added the test and rebase it on the latest develop.

authors: amjltc295 matthewshirley townie


text:
meta-amlogic compile issue

when compile Yocoto with meta-amlogic machine, I met the following compile error
ERROR: Unable to install packages. Command '/home/floragui/code/Yocto/meta-amlogic/build/tmp/sysroots/x86_64-linux/usr/bin/smart --quiet --data-dir=/home/floragui/code/Yocto/meta-amlogic/build/tmp/work/odroidc1-poky-linux-gnueabi/core-image-base/1.0-r0/rootfs/var/lib/smart install -y psplash@cortexa5hf_vfp_neon packagegroup-base-extended@odroidc1 run-postinsts@all packagegroup-core-boot@odroidc1 locale-base-en-us@cortexa5hf_vfp_neon locale-base-en-gb@cortexa5hf_vfp_neon' returned 1:
error: Can't install libamcodec-v2014.05.27+git0+143e73d6d7-r3@odroidc1: no package provides libstdc++.so

ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/floragui/code/Yocto/meta-amlogic/build/tmp/work/odroidc1-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_rootfs.21775
ERROR: Task 7 (/home/floragui/code/Yocto/meta-amlogic/poky/meta/recipes-core/images/core-image-base.bb, do_rootfs) failed with exit code '1'

First time i also see WARNING like this:
WARNING: QA Issue: libamcodec requires libm.so, libstdc++.so, libc.so, but no providers in its RDEPENDS [file-rdeps]
does anyone meet this before? how to solve the issue?

Can you please provide the info screen which is shown after recipe parsing which contains machine and and distro information + used layers and git SHA1s?
Yes, the QA Warnings are on the TODO list. see #1
It looks like you are using PACKAGE_CLASSES ?="package_rpm" in conf/local.conf isn't it?
I am using ipk in most cases. Can you please retry with ipk please?
PACKAGE_CLASSES ?= "package_ipk"

Thanks, it works, didn't report "no package provides libstdc++.so" again.

I've observed this on poky dizzy while building recipes-core/images/wetek-image-minimal.bb on odroidc1

authors: floragui graugans rzr

repo: linux-meson/meta-amlogic


text:
[Feature] Simplify the resource naming of Liqo resources

So far, Liqo resources were named after the remote cluster id. To simplify the interaction with those resources, we would like to have pretty names for resources, which are easier to understand for users. This problem is particularly true when Liqo manages a lot of clusters, and it is hard to understand which cluster is involved.
Strategy: Liqo should use a unique local name to access resources locally; Liqo will use a hash of the UUID (max six characters) for remote disambiguation.
Tasks:
Rename LOCAL resources according to the new strategy starting from:

[ ] ForeignClusters
[ ] Nodes
[ ] NetworkConfig (from GenerateName)
[ ] TunnelEndpoint (from GenerateName)
[ ] Tenant
[ ] Tenant Namespaces
[ ] ResourceOffers (named after the cluster that created it)
[ ] ResourceRequests (named after the cluster that created it)

Rename REMOTE resources according to the new strategy starting from:

[ ] Application Namespaces

/test

I can't remember if this was discussed in the relevant call, but what happens if two discovered clusters share the same cluster name (and would therefore create eg. the same tenant namespaces)? I think this situation should be avoided by assigning discovered clusters a new name if a conflict occurs, but let's discuss this in tomorrow's standup.

authors: CapacitorSet palexster

repo: liqotech/liqo


text:
Fix: Freeing a reserved subnet equal to a network pool

Description
This PR fixes a bug that arises when freeing a reserved network equal to a network pool. Currently the Ipam removes completely the network pool and no cluster can ask/be mapped to that pool.
This PR also improves Ipam behavior if a cluster asks for an entire network pool. Currently it just looks for a mapping. If none is found, then returns an error. Thanks to this correction, if a mapping has not been found, the entire network pool is assigned to the cluster.

/ok-to-test

/rebase


text:
PeeringPhase-Based Replication

Description
This pr introduces a logic to start the replication of different CRDs in different peering phases.
For example, the replication of ResourceRequests has to be always enabled when a ForeignCluster CR is present, while the replication of NetworkConfigs has to be enabled only if the peering is enabled.
Ref. #573
How Has This Been Tested?

[x] locally on KinD
[x] add unit test

/merge

authors: aleoli palexster


text:
Fixes #3625 JAVA_HOME Path when parenthesis are present

Impact

[X] Bug fix (non-breaking change which fixes expected existing functionality)
[ ] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
Fixes #3625 JAVA_HOME Path when parenthesis are present
Inside the liquibase.bat file the JAVA_HOME could not be processed due to parenthesis. The issue is fixed when the path is wrapped by quotes.
Users can now start liquibase also from directories which includes parenthesis in their path.
Things to be aware of
Things to worry about
Additional Context

@filipelautert This change was made to the Windows batch file. In addition to this change, could you check and see if a similar change needs to be made to the Linux script file? Are there any other places in the code where this change makes sense?

@kevin-atx all fine, Linux version already has the double quotes .
@JulienMa94 - thanks for the PR! With this fix, am I right to say that we should do the same around line 31 too?
if NOT "%JAVA_HOME%" == "" set JAVA_PATH=%JAVA_HOME%\bin\java

@JulienMa94 - thanks for the PR! With this fix, am I right to say that we should do the same around line 31 too?
if NOT "%JAVA_HOME%" == "" set JAVA_PATH=%JAVA_HOME%\bin\java

@filipelautert Makes sense to me too. I will do the change the coming days and test it.

@filipelautert After testing my changes I think that line 31 > if NOT "%JAVA_HOME%" == "" set JAVA_PATH=%JAVA_HOME%\bin\java should not be changed.
I tryed starting the liquibase cli from a path with containing parenthesis & also changed my JAVA_HOME systemvariable to a path with parenthesis and could start liquibase / see the banner with options.
Inside the screenshot you can see the LIQUIBASE_HOME, JAVA_HOME, JAVA_PATH variables printed to the powershell before the liquibase banner appears.

So I assume that the JAVA_PATH is set correctly and that line 33 already uses the correct qoutes > "%JAVA_PATH%" %JAVA_OPTS% -jar "%LIQUIBASE_HOME%\internal\lib\liquibase-core.jar" %*.

This pull request addresses an issue where parentheses in the file path prevent the Liquibase CLI from running on Windows. I have verified that the fix works on Windows.
Thank you @JulienMa94!
Approved.

Hello @JulienMa94 - we had to revert this PR as it caused https://github.com/liquibase/liquibase/issues/4695 . I tried a fix but it didn't work. Do you have any ideas around that?

Hi @filipelautert just read your message and looked into the releated pull requests / work. At the moment I don't have any ideas what could cause / fix these issue.

Hi @filipelautert,
maybe found a fix for the parenthese issue. In the following Stackoverflow thread it is suggested to encapsulate the whole set command with double quoutes to allow special characters inside a variable like so:
@echo off set a=some value with (parentheses) inside if 1 == 1 (     set "PATH=%a%" )
So we could try
set "JAVA_HOME=%LIQUIBASE_HOME%\jre"
instead of
set JAVA_HOME="%LIQUIBASE_HOME%\jre"
Maybe this could be a possible fix and also does not create other issues.
Greetings
Julien

Thanks for the research @JulienMa94 ! We could create a new PR with this change and then test team can help us to test it on various windows environments.

Hi @filipelautert,
I can submit a PR in roughly 2 weeks I am not able to work until the end of September. If this fix can wait I am happy to contribute.
Greetings
Julien

@JulienMa94 -> https://github.com/liquibase/liquibase/pull/4985

authors: JulienMa94 filipelautert kevin-atx rberezen

repo: liquibase/liquibase


text:
Update cats-effect to 3.1.1

Updates org.typelevel:cats-effect from 2.5.1 to 3.1.1.
GitHub Release Notes - Version Diff
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 me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Applied Migrations

github:typelevel/cats-effect/v3_0_0?sha=series/3.x

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

labels: library-update, semver-major, scalafix-migrations

Superseded by #74.


text:
Downloading chunks is very unreliable

It seems like I failed at my task of making the chunk downloading system more robust, and for some reason, sometimes, chunks are just not sent out to other clients.
I'm still yet to investigate the root cause behind this.

I think I found the crux of the issue. The new master-sub chunk system is flaky and causes problems when drawing lines very fast at large scales (low zoom %). This causes some sub-chunks to not be marked as present, which means that the PaintCanvas::chunk_positions() iterator does not yield them, so the clients never receive chunk positions that actually exist on the host's canvas.
I think the only reasonable solution here would be to get rid of the master-sub chunk system entirely, and instead operate on normal 256x256-sized chunks. The problem here is that Skia is not very fast at rendering a lot of things at once, so doing that causes low FPS. In fact, this current system was introduced as a side effect of this problem, but as demonstrated by this issue, it's not problem-free. It also leads to much more convoluted code, and prevents some optimizations.
Thus, this issue is blocked by #29. At first the app should be made render-agnostic; later we can switch out to an OpenGL/WebGPU backend, both of which can render these large amounts of chunks very easily.

There seem to be more issues than just the lime drawing thing; it appears that sometimes the host has to move its cursor before it starts sending out packets. This sounds like a buffering problem.
Unfortunately this is really hard to debug, as I have not found a reliable way to reproduce this yet, so until that, this issue will have to wait.

Both of these issues are fixed with 0.5.0 – the way the brush creates new chunks has been changed to use a simple rectangle covering the whole stroke, instead of a chain of smaller rectangles. This does make chunk allocation a little less efficient, but it does improve reliability by large.
The second buffering issue did in fact turn out to be a buffering issue, and 0.5.0 removes read buffering completely, too – both from the matchmaker side and the client side. Write buffering is still performed, as some performance boost is better than none.

repo: liquidev/netcanv


text:
Install pyahocorasick to allow the use of --word-list flag

The Yelp's detect-secrets tool allow the use of --word-list  flag to pass a file with words to be ignored, but this flag requires the installation of pyahocorasick, which could be done by:
pip install detect-secrets[word_list]

My suggestion is to replace the current pip install  with the one above, allowing people to use the --word-list flag.

@lirantal if you agree with this I have made a PR, but as pyahocorasick is implemented in C, I needed to install build-essential too, what caused the image to increase in size by 161MB (the first one is the new image):

Yep, that sounds a great enhancement.

authors: belaaiza lirantal

repo: lirantal/docker-detect-secrets


text:
最新版编译之后，首页的登录之类链接没变

我编译之后搭建起来，发现首页无法正确显示链接，包括 登录、注册、应用等。我通过手动修改浏览器链接可以访问登录页（后面手动+  /login），但是点击登录无响应。这个是还未开发完整吗？

我回退到0.2.0版本的时候，就可以了。0.3.0版本我配置有问题？

console 输出日志：

warning.js:36 Warning: Portal: React.createClass is deprecated and will be removed in version 16. Use plain JavaScript classes instead. If you're not yet ready to migrate, create-react-class is available on npm as a drop-in replacement.
printWarning @ warning.js:36
warning @ warning.js:60
createClass @ ReactClass.js:628
Object.defineProperty.value @ Portal.js:34
__webpack_require__ @ bootstrap 2e06878…:54
Object.defineProperty.value @ Modal.js:26
__webpack_require__ @ bootstrap 2e06878…:54
(anonymous) @ Modal.js:1
__webpack_require__ @ bootstrap 2e06878…:54
(anonymous) @ index.js:1
__webpack_require__ @ bootstrap 2e06878…:54
484 @ Footer.js:21
__webpack_require__ @ bootstrap 2e06878…:54
142 @ Layout.js:28
__webpack_require__ @ bootstrap 2e06878…:54
509 @ index.js:5
__webpack_require__ @ bootstrap 2e06878…:54
510 @ index.js:18
__webpack_require__ @ bootstrap 2e06878…:54
479 @ client.js:93
__webpack_require__ @ bootstrap 2e06878…:54
1230 @ client.js:7
__webpack_require__ @ bootstrap 2e06878…:54
webpackJsonpCallback @ bootstrap 2e06878…:25
(anonymous) @ client.js:1
index.js:19 OPTIONS http://127.0.0.1:3000/README.md net::ERR_CONNECTION_REFUSED
_callee$ @ index.js:19
tryCatch @ runtime.js:65
invoke @ runtime.js:303
prototype.(anonymous function) @ runtime.js:117
step @ index.js:5
(anonymous) @ index.js:5
(anonymous) @ index.js:5
action @ index.js:19
_callee$ @ browser.js:185
tryCatch @ runtime.js:65
invoke @ runtime.js:303
prototype.(anonymous function) @ runtime.js:117
step @ asyncToGenerator.js:17
(anonymous) @ asyncToGenerator.js:35
F @ _export.js:35
(anonymous) @ asyncToGenerator.js:14
next @ browser.js:206
_callee$ @ index.js:33
tryCatch @ runtime.js:65
invoke @ runtime.js:303
prototype.(anonymous function) @ runtime.js:117
step @ index.js:15
(anonymous) @ index.js:15
(anonymous) @ index.js:15
action @ index.js:33
_callee$ @ browser.js:185
tryCatch @ runtime.js:65
invoke @ runtime.js:303
prototype.(anonymous function) @ runtime.js:117
step @ asyncToGenerator.js:17
(anonymous) @ asyncToGenerator.js:35
F @ _export.js:35
(anonymous) @ asyncToGenerator.js:14
next @ browser.js:206
_callee2$ @ browser.js:226
tryCatch @ runtime.js:65
invoke @ runtime.js:303
prototype.(anonymous function) @ runtime.js:117
step @ asyncToGenerator.js:17
(anonymous) @ asyncToGenerator.js:35
F @ _export.js:35
(anonymous) @ asyncToGenerator.js:14
resolve @ browser.js:251
_callee$ @ client.js:96
tryCatch @ runtime.js:65
invoke @ runtime.js:303
prototype.(anonymous function) @ runtime.js:117
step @ client.js:154
(anonymous) @ client.js:154
(anonymous) @ client.js:154
onLocationChange @ client.js:96
479 @ client.js:154
__webpack_require__ @ bootstrap 2e06878…:54
1230 @ client.js:7
__webpack_require__ @ bootstrap 2e06878…:54
webpackJsonpCallback @ bootstrap 2e06878…:25
(anonymous) @ client.js:1
warning.js:36 Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:
 (client) <!-- react-empty: 1 -
 (server) <div data-reactroot="
printWarning @ warning.js:36
warning @ warning.js:60
_mountImageIntoNode @ ReactMount.js:507
mountComponentIntoNode @ ReactMount.js:112
perform @ Transaction.js:140
batchedMountComponentIntoNode @ ReactMount.js:126
perform @ Transaction.js:140
batchedUpdates @ ReactDefaultBatchingStrategy.js:62
batchedUpdates @ ReactUpdates.js:97
_renderNewRootComponent @ ReactMount.js:320
_renderSubtreeIntoContainer @ ReactMount.js:401
render @ ReactMount.js:422
_callee$ @ client.js:138
tryCatch @ runtime.js:65
invoke @ runtime.js:303
prototype.(anonymous function) @ runtime.js:117
step @ client.js:154
(anonymous) @ client.js:154
client.js:154 Uncaught (in promise) TypeError: Failed to fetch

server 的nginx配置：
server
{
    listen 80;
    server_name api.codepush;
    location / {
        #proxy_http_version 1.1;
        #proxy_set_header Upgrade $http_upgrade;
        #proxy_set_header Connection "upgrade";

        add_header Access-Control-Allow-Origin http://127.0.0.1:3001|codepush.cc|www.codepush.cc always;
        # add_header Access-Control-Allow-Origin * always;
        add_header Access-Control-Allow-Credentials true always;
       if ($request_method = "OPTIONS") {
            add_header 'Access-Control-Allow-Origin' 'http://127.0.0.1:3001|codepush.cc|www.codepush.cc' always;
            # add_header 'Access-Control-Allow-Origin' '*' always;
            add_header 'Access-Control-Allow-Origin'  always;
            add_header 'Access-Control-Allow-Credentials' true always;
            add_header 'Access-Control-Max-Age' 86400 always;
            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PATCH' always;
            add_header 'Access-Control-Allow-Headers' 'reqid, nid, host, x-real-ip, x-forwarded-ip, event-type, event-id, accept, content-type, x-requested-with, origin, authorization' always;
            add_header 'Content-Length' 0 always;
            add_header 'Content-Type' 'text/plain, charset=utf-8' always;
            return 204;
        }

        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://127.0.0.1:3000;
    }

    access_log /srv/www/codepush/nginx/access_codepush_api.log;
}

code-push-server是否开启，日志显示无法连接到127.0.0.1:3000，确保code-push-server已经开启

已经开启了，我直接访问IP的3000端口，是ok的。页面也显示正常。

另外，为啥首页的链接，全部都是链接到首页？  不是对应的页面？

我也遇到了一样的问题  顶部那里的“我的应用”、“注册”等等点了后，地址栏显示的链接都是http://127.0.0.1:3001/#

连接是这样的没有问题，项目用的react写的，跳转用的history.push，主要是防止刷新dom，master上是好的么？

是跨域问题，还有就是注意在填写api的url时候，不能填写localhost/127.0.0.1，填写真实的地址就好了。

authors: hwangjr ismjt lisong

repo: lisong/code-push-web


text:
Set up pallet action logger

Approaching new pallets is a challenge because the information is quite hard to pin down, meaning the research phase is way longer than the development phase.
The plan is to build a test processor. The requirements are:

only runs actions involving a specified account
logs all events/extrinsics for a pallet (to a JSON file)
has a configurable chain -> run against small chain at first, then against a bigger chain (e.g. polkadot/kusama) when we are the confirmation stage

@markdavison feel free to add/edit details

It might be helpful to be able to set a block range that you want to be fetched?

It might be helpful to be able to set a block range that you want to be fetched?

added, it's an easy param to set

authors: bdmason markdavison

repo: litentry/squid


text:
Notification callback on CONNECTION_CLOSE frame

Support new lsquic_stream_if callback on_conncloseframe_received() to notify application of CONNECTION_CLOSE frame

Thanks for the PR -- it looks good.
The only part I hesitate to take is the #define -- we don't have this mechanism for other members of the API struct.  Perhaps you could use LSQUIC_*_VERSION at compile-time?  We rarely (ever?) remove the callbacks.

Feel free to remove this line. Or if you like I will update the pull request.
The #define is there because multiple developers are working on our application and some may not yet have this commit. I didn’t want to break the build for anyone.
Paul
From: Dmitri Tikhonov notifications@github.com
Sent: Friday, December 18, 2020 12:44 PM
To: litespeedtech/lsquic lsquic@noreply.github.com
Cc: Sheer, Paul Paul.Sheer@spirent.com; Author author@noreply.github.com
Subject: Re: [litespeedtech/lsquic] Notification callback on CONNECTION_CLOSE frame (#205)
[Warning] This email comes from an external source. Be careful of any embedded links and attachments.
Thanks for the PR -- it looks good.
The only part I hesitate to take is the #definehttps://github.com/litespeedtech/lsquic/pull/205/files#diff-192594105d74d1d93080aafe6efc7a01c9ddf04b0b9e552d30de64038e1c091bR230 -- we don't have this mechanism for other members of the API struct. Perhaps you could use LSQUIC_*_VERSION at compile-time? We rarely (ever?) remove the callbacks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/litespeedtech/lsquic/pull/205#issuecomment-748253261, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKAGOJQCDPJH3JKUVTNHJJLSVOPH5ANCNFSM4VBQGHZQ.

We'll remove it after merging, then.

authors: dtikhonov psheer-spirent

repo: litespeedtech/lsquic


text:
Freeing quickjs.Runtime after creating a new function causes a segmentation fault.

The suspicion is of possible misuse of JS_NewCFunctionData, which is used over JS_NewCFunction to provide an opaque pointer to proxy() in Go to dispatch Go functions in C.
It may be that this is not the intended use of JS_NewCFunctionData, and that calling JS_FreeRuntime frees unintended memory as a result.
func main() {
	runtime := quickjs.NewRuntime()
	defer runtime.Free()

	ctx := runtime.NewContext()
	defer ctx.Free()

	globals := ctx.Globals()
	defer globals.Free()

	httpFunc := ctx.Function(func(ctx quickjs.Context, this quickjs.Value, args []quickjs.Value) quickjs.Value {
		if len(args) != 1 || !args[0].IsString() {
			return ctx.ThrowTypeError("http(request: string)")
		}

		request := args[0]
		fmt.Println(request.String())

		return request
	})
	defer httpFunc.Free()

	globals.Set("http", httpFunc)

	result, err := ctx.Eval(`http('test')`)
	check(err)
	defer result.Free()

	fmt.Println(result)
}

$ CGO_CFLAGS="-DDUMP_LEAKS" go run main.go
# command-line-arguments
/tmp/go-link-072279044/000024.o: In function `_cgo_26061493d47f_C2func_getaddrinfo':
cgo_unix.cgo2.c:(.text+0x81): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
test
test
main: quickjs.c:5625: gc_decref_child: Assertion `p->ref_count > 0' failed.
SIGABRT: abort
PC=0x782978 m=0 sigcode=18446744073709551610

goroutine 0 [idle]:
runtime: unknown pc 0x782978
stack: frame={sp:0x7ffd922906b8, fp:0x0} stack=[0x7ffd91a91ae8,0x7ffd92290b10)
00007ffd922905b8:  000000000092db5c  0000000000000000
00007ffd922905c8:  0000000000798780  00000000fbad8000
00007ffd922905d8:  00000000022c1a00  00000000022c1a00
00007ffd922905e8:  00000000022c1a00  00000000022c1a00
00007ffd922905f8:  00000000022c1a4c  00000000022c1a64
00007ffd92290608:  00000000022c1a00  00000000022c1a64
00007ffd92290618:  0000000000000000  0000000000000000
00007ffd92290628:  0000000000000000  0000000000000000
00007ffd92290638:  0000000000000000  0000000092290660
00007ffd92290648:  0000000000688a26  00000000022c0000
00007ffd92290658:  0000000000000000  00007ffd92290690
00007ffd92290668:  0000000000688aae  ffffffffffffffff
00007ffd92290678:  0000000000000000  00000000022b70c8
00007ffd92290688:  00007f356e578000  00000000009b2420
00007ffd92290698:  000000000092d5c4  00000000000015f9
00007ffd922906a8:  000000000092db5c  0000000000000000
00007ffd922906b8: <0000000000782d0a  0000000000000020
00007ffd922906c8:  0000000000000000  0000000000000000
00007ffd922906d8:  0000000000000000  0000000000000000
00007ffd922906e8:  0000000000000000  0000000000000000
00007ffd922906f8:  0000000000000000  0000000000000000
00007ffd92290708:  0000000000000000  0000000000000000
00007ffd92290718:  0000000000000000  0000000000000000
00007ffd92290728:  0000000000000000  0000000000000000
00007ffd92290738:  0000000000000000  0000000000000004
00007ffd92290748:  00000000022b7ab0  00007ffd92290720
00007ffd92290758:  00000016022c9230  0000000000000000
00007ffd92290768:  00007f356e578000  00000000009b2420
00007ffd92290778:  000000000092d5c4  00000000000015f9
00007ffd92290788:  000000000092db5c  0000000000000000
00007ffd92290798:  00000000007a5377  00000000022c3bf0
00007ffd922907a8:  fffffffffffffff9  00000000009c9e9c
runtime: unknown pc 0x782978
stack: frame={sp:0x7ffd922906b8, fp:0x0} stack=[0x7ffd91a91ae8,0x7ffd92290b10)
00007ffd922905b8:  000000000092db5c  0000000000000000
00007ffd922905c8:  0000000000798780  00000000fbad8000
00007ffd922905d8:  00000000022c1a00  00000000022c1a00
00007ffd922905e8:  00000000022c1a00  00000000022c1a00
00007ffd922905f8:  00000000022c1a4c  00000000022c1a64
00007ffd92290608:  00000000022c1a00  00000000022c1a64
00007ffd92290618:  0000000000000000  0000000000000000
00007ffd92290628:  0000000000000000  0000000000000000
00007ffd92290638:  0000000000000000  0000000092290660
00007ffd92290648:  0000000000688a26  00000000022c0000
00007ffd92290658:  0000000000000000  00007ffd92290690
00007ffd92290668:  0000000000688aae  ffffffffffffffff
00007ffd92290678:  0000000000000000  00000000022b70c8
00007ffd92290688:  00007f356e578000  00000000009b2420
00007ffd92290698:  000000000092d5c4  00000000000015f9
00007ffd922906a8:  000000000092db5c  0000000000000000
00007ffd922906b8: <0000000000782d0a  0000000000000020
00007ffd922906c8:  0000000000000000  0000000000000000
00007ffd922906d8:  0000000000000000  0000000000000000
00007ffd922906e8:  0000000000000000  0000000000000000
00007ffd922906f8:  0000000000000000  0000000000000000
00007ffd92290708:  0000000000000000  0000000000000000
00007ffd92290718:  0000000000000000  0000000000000000
00007ffd92290728:  0000000000000000  0000000000000000
00007ffd92290738:  0000000000000000  0000000000000004
00007ffd92290748:  00000000022b7ab0  00007ffd92290720
00007ffd92290758:  00000016022c9230  0000000000000000
00007ffd92290768:  00007f356e578000  00000000009b2420
00007ffd92290778:  000000000092d5c4  00000000000015f9
00007ffd92290788:  000000000092db5c  0000000000000000
00007ffd92290798:  00000000007a5377  00000000022c3bf0
00007ffd922907a8:  fffffffffffffff9  00000000009c9e9c

goroutine 1 [syscall]:
runtime.cgocall(0x6578e2, 0xc000059db0, 0x1f9)
        /snap/go/current/src/runtime/cgocall.go:133 +0x5b fp=0xc000059d80 sp=0xc000059d48 pc=0x403fab
github.com/lithdew/quickjs._Cfunc_JS_FreeRuntime(0x22b7030)
        _cgo_gotypes.go:260 +0x41 fp=0xc000059db0 sp=0xc000059d80 pc=0x504551
github.com/lithdew/quickjs.Runtime.Free.func1(0x22b7030)
        /home/kenta/lithdew/quickjs/quickjs.go:33 +0x4d fp=0xc000059de0 sp=0xc000059db0 pc=0x50691d
github.com/lithdew/quickjs.Runtime.Free(0x22b7030)
        /home/kenta/lithdew/quickjs/quickjs.go:33 +0x2b fp=0xc000059df8 sp=0xc000059de0 pc=0x50556b
main.main()
        /home/kenta/lithdew/ghost/main.go:109 +0x40e fp=0xc000059f88 sp=0xc000059df8 pc=0x656d2e
runtime.main()
        /snap/go/current/src/runtime/proc.go:203 +0x1fa fp=0xc000059fe0 sp=0xc000059f88 pc=0x4359fa
runtime.goexit()
        /snap/go/current/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc000059fe8 sp=0xc000059fe0 pc=0x4620d1

rax    0x0
rbx    0x7f356e578000
rcx    0x782978
rdx    0x6
rdi    0x6960
rsi    0x6960
rbp    0x9b2420
rsp    0x7ffd922906b8
r8     0x22c1a00
r9     0x0
r10    0x8
r11    0x206
r12    0x92d5c4
r13    0x15f9
r14    0x92db5c
r15    0x0
rip    0x782978
rflags 0x206
cs     0x33
fs     0x0
gs     0x0
exit status 2

func main() {
	runtime := quickjs.NewRuntime()
	defer runtime.Free()

	ctx := runtime.NewContext()
	defer ctx.Free()

	globals := ctx.Globals()
	defer globals.Free()

	httpFunc := ctx.Function(func(ctx quickjs.Context, this quickjs.Value, args []quickjs.Value) quickjs.Value {
		if len(args) != 1 || !args[0].IsString() {
			return ctx.ThrowTypeError("http(request: string)")
		}

		request := args[0]
		fmt.Println(request.String())

		return request
	})
	//defer httpFunc.Free()

	globals.Set("http", httpFunc)

	result, err := ctx.Eval(`http('test')`)
	check(err)
	//defer result.Free()

	fmt.Println(result)
}

$ CGO_CFLAGS="-DDUMP_LEAKS" go run main.go
# command-line-arguments
/tmp/go-link-896294616/000024.o: In function `_cgo_26061493d47f_C2func_getaddrinfo':
cgo_unix.cgo2.c:(.text+0x81): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
test
test
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x2 addr=0x1e4c030 pc=0x1e4c030]

runtime stack:
runtime.throw(0x8bd124, 0x2a)
        /snap/go/current/src/runtime/panic.go:1116 +0x72
runtime.sigpanic()
        /snap/go/current/src/runtime/signal_unix.go:679 +0x46a

goroutine 1 [syscall]:
runtime.cgocall(0x6577e2, 0xc000059e08, 0x1f9)
        /snap/go/current/src/runtime/cgocall.go:133 +0x5b fp=0xc000059dd8 sp=0xc000059da0 pc=0x403fab
github.com/lithdew/quickjs._Cfunc_JS_FreeRuntime(0x1e38010)
        _cgo_gotypes.go:260 +0x41 fp=0xc000059e08 sp=0xc000059dd8 pc=0x504551
github.com/lithdew/quickjs.Runtime.Free.func1(0x1e38010)
        /home/kenta/lithdew/quickjs/quickjs.go:33 +0x4d fp=0xc000059e38 sp=0xc000059e08 pc=0x50691d
github.com/lithdew/quickjs.Runtime.Free(0x1e38010)
        /home/kenta/lithdew/quickjs/quickjs.go:33 +0x2b fp=0xc000059e50 sp=0xc000059e38 pc=0x50556b
main.main()
        /home/kenta/lithdew/ghost/main.go:109 +0x329 fp=0xc000059f88 sp=0xc000059e50 pc=0x656c49
runtime.main()
        /snap/go/current/src/runtime/proc.go:203 +0x1fa fp=0xc000059fe0 sp=0xc000059f88 pc=0x4359fa
runtime.goexit()
        /snap/go/current/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc000059fe8 sp=0xc000059fe0 pc=0x4620d1
exit status 2

Here is another similar case:
main.go
package main

import (
	"github.com/lithdew/quickjs"
)

func check(err error) {
	if err != nil {
		panic(err)
	}
}

func main() {
	rt := quickjs.NewRuntime()

	for i := 0; i < 10000; i++ {

		ctx := rt.NewContext()

		globals := ctx.Globals()

		globals.Set("B", ctx.Function(SetRedisObject))

		ctx.Eval(`B('test',{a:'c'});`)

		defer ctx.Free()
	}
}

fn.go
package main

import (
	"github.com/go-redis/redis"
	"github.com/lithdew/quickjs"
)

var rdb = redis.NewClusterClient(&redis.ClusterOptions{
	Addrs: []string{"localhost:7000"},
})

func ValueToMap(v *quickjs.Value) map[string]interface{} {
	if v.IsObject() == false {
		panic("not an object")
	}
	names, err := v.PropertyNames()
	check(err)

	result := map[string]interface{}{}
	for _, name := range names {
		result[name.String()] = v.GetByAtom(name.Atom).String()
	}
	return result
}

func SetRedisObject(ctx quickjs.Context, this quickjs.Value, args []quickjs.Value) quickjs.Value {
	err := rdb.HMSet(args[0].String(), ValueToMap(&args[1])).Err()
	if err != nil {
		panic(err)
	}
	return ctx.Null()
}

produces:
Exception 0xc0000005 0x0 0xffffffffffffffff 0x632bee
PC=0x632bee

runtime: unknown pc 0x632bee
stack: frame={sp:0x101f7f0, fp:0x0} stack=[0x0,0x101fdc0)
000000000101f6f0:  0000000000190000  00007ff8b22bba17
000000000101f700:  0000000028bfaf30  ffffffffffffffff
000000000101f710:  0000000000000068  0000000028bfaf30
000000000101f720:  0000000028c32980  0000000028bfaf30
000000000101f730:  000000000101f7e0  00000000006d3e79
000000000101f740:  0000000028bfb420  0000000000000025
000000000101f750:  0000000000196028  0000000028bf3830
000000000101f760:  0000000028bfaf30  ffffffffffffffff
000000000101f770:  0000000028bfaf30  ffffffffffffffff
000000000101f780:  000000000101f7b0  0000000000626a2a
000000000101f790:  0000000028bf6cb0  0000001300000000
000000000101f7a0:  0000000000196028  0000000028bfaf30
000000000101f7b0:  ffffffffffffffff  000000c000149de0
000000000101f7c0:  00000000007d8105  0000000000000000
000000000101f7d0:  0000000000000000  0000000002030000
000000000101f7e0:  000000000101f890  0000000000632bf1
000000000101f7f0: <0000000000197b70  0000000000197b70
000000000101f800:  0000000000632df5  000000000062832a
000000000101f810:  0000000028bfacf0  ffffffffffffffff
000000000101f820:  000000000101f830  00000000001975c0
000000000101f830:  0000000028bf6c10  00000000006283c3
000000000101f840:  0000000028c39390  0000000000976c00
000000000101f850:  0001010000000001  0000000028bf5760
000000000101f860:  0000000000197b70  0000000028bfacf0
000000000101f870:  0000000028bfaf40  0000000000197bb8
000000000101f880:  000000000101fa40  0000000000976c00
000000000101f890:  000000000101f8e0  0000000000632f07
000000000101f8a0:  0000000000195f80  0000000028bfacf0
000000000101f8b0:  0000000000632df5  000000000062f130
000000000101f8c0:  00000000edb13dc1  0000000028bfacf0
000000000101f8d0:  0000000028bfae20  0000000028bfad00
000000000101f8e0:  000000000101f910  0000000000633244
runtime: unknown pc 0x632bee
stack: frame={sp:0x101f7f0, fp:0x0} stack=[0x0,0x101fdc0)
000000000101f6f0:  0000000000190000  00007ff8b22bba17
000000000101f700:  0000000028bfaf30  ffffffffffffffff
000000000101f710:  0000000000000068  0000000028bfaf30
000000000101f720:  0000000028c32980  0000000028bfaf30
000000000101f730:  000000000101f7e0  00000000006d3e79
000000000101f740:  0000000028bfb420  0000000000000025
000000000101f750:  0000000000196028  0000000028bf3830
000000000101f760:  0000000028bfaf30  ffffffffffffffff
000000000101f770:  0000000028bfaf30  ffffffffffffffff
000000000101f780:  000000000101f7b0  0000000000626a2a
000000000101f790:  0000000028bf6cb0  0000001300000000
000000000101f7a0:  0000000000196028  0000000028bfaf30
000000000101f7b0:  ffffffffffffffff  000000c000149de0
000000000101f7c0:  00000000007d8105  0000000000000000
000000000101f7d0:  0000000000000000  0000000002030000
000000000101f7e0:  000000000101f890  0000000000632bf1
000000000101f7f0: <0000000000197b70  0000000000197b70
000000000101f800:  0000000000632df5  000000000062832a
000000000101f810:  0000000028bfacf0  ffffffffffffffff
000000000101f820:  000000000101f830  00000000001975c0
000000000101f830:  0000000028bf6c10  00000000006283c3
000000000101f840:  0000000028c39390  0000000000976c00
000000000101f850:  0001010000000001  0000000028bf5760
000000000101f860:  0000000000197b70  0000000028bfacf0
000000000101f870:  0000000028bfaf40  0000000000197bb8
000000000101f880:  000000000101fa40  0000000000976c00
000000000101f890:  000000000101f8e0  0000000000632f07
000000000101f8a0:  0000000000195f80  0000000028bfacf0
000000000101f8b0:  0000000000632df5  000000000062f130
000000000101f8c0:  00000000edb13dc1  0000000028bfacf0
000000000101f8d0:  0000000028bfae20  0000000028bfad00
000000000101f8e0:  000000000101f910  0000000000633244

goroutine 1 [syscall]:
github.com/lithdew/quickjs._Cfunc_JS_NewContext(0x195f80, 0x0)
        _cgo_gotypes.go:688 +0x51
github.com/lithdew/quickjs.Runtime.NewContext.func1(0x195f80, 0x28bfa5a0)
        C:/Users/cemre.mengu/go/pkg/mod/github.com/lithdew/quickjs@v0.0.0-20200709202529-fb8d8987e9de/quickjs.go:36 +0x54
github.com/lithdew/quickjs.Runtime.NewContext(0x195f80, 0x0, 0x0, 0x0, 0x0)
        C:/Users/cemre.mengu/go/pkg/mod/github.com/lithdew/quickjs@v0.0.0-20200709202529-fb8d8987e9de/quickjs.go:36 +0x43
main.main()
        C:/Users/cemre.mengu/Desktop/quick/main.go:18 +0x74
rax     0x101f810
rbx     0x28bfacf0
rcx     0x195f80
rdi     0xc000149de0
rsi     0xffffffffffffffff
rbp     0x101f890
rsp     0x101f7f0
r8      0x632df5
r9      0x1010000000001
r10     0x0
r11     0x101f7e0
r12     0x7d8105
r13     0x0
r14     0x0
r15     0x2030000
rip     0x632bee
rflags  0x10202
cs      0x33
fs      0x53
gs      0x2b

Fixed by https://github.com/lithdew/quickjs/commit/ee6f6e9628f0ae350513081bf1a685ab0017674b.

authors: cemremengu lithdew

repo: lithdew/quickjs


text:
Per-experiment annotations to allow for opt-in to unique experiments

Currently, to opt into Litmus experiments, one must use this command:
kubectl annotate deploy/hello-world litmuschaos.io/chaos="true"
and similarly false or delete the annotation to "opt-out"
However, this doesn't allow for the selection of WHICH experiment you want to opt into. If various deployments only want certain experiments at a given time, that's not possible right now. You can't have the beer-brewing deployment in the namespace "alcohol" run pod-delete, and have the cider-brewing deployment, also in the namespace "alcohol" run node-cpu-hog, but
Furthermore: If, in conjunction with 1219 if the Kubernetes cluster has several experiments installed into an administrator/litmus namespace, it's important for each deployment to opt-in to individual experiments rather than chaos as a whole, as long-term one can envision many different experiments on a cluster but each deployment only wants one at a time (or many at a time, depending on the business context).

The latest versions of litmus no longer supports the litmuschaos.io/chaos annotation for apps to opt-in or out of experiments. Also, the mode of experimentation is via a consciously constructed workflow which allows the user to do what is described in the issue, i.e., as long-term one can envision many different experiments on a cluster but each deployment only wants one at a time (or many at a time, depending on the business context)

authors: cpitstick-argo ksatchit

repo: litmuschaos/litmus


text:
update dependencies + add clippy to CI

[X] update dependencies. One nice thing is that with recent serde_json versions, we can use the json! marco instead of builders
[x] fix all the clippy warnings
[ ] run clippy in CI for nightly builds

I remove the allow[dead_code] that I added. I agree it's better to try getting rid of the warnings than hide them. I also tried to remove it in src/core.rs but it becomes very noisy and it gets hard to see the other warnings, so I left it.

lol fair enough. i'll open an issue for it :)

I'm assuming I should wait for you to get clippy working in CI before approving? (I see that box is still unchecked all the way at the top)

Yes, I'm on it right now  actually :)

repo: little-dude/xi-tui


text:
🛑 USTC Mirrors (IPv4) is down

In 6e13ea4, USTC Mirrors (IPv4) (https://ipv4.mirrors.ustc.edu.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: USTC Mirrors (IPv4) is back up in ab62a9e.

repo: littlekud/sites-status


text:
🛑 USTC is down

In e3d820a, USTC (https://www.ustc.edu.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: USTC is back up in 6f8c8a8.


text:
大神，在使用您的扩展时遇到了几个问题，求助！！！

1.FFLabel长文本，用约束布局不能准确计算高度。
2.FFLabel偶尔会出现文字字体变小的情况。
3.FFLabel因为拦截了触摸事件，如果点击到不是高亮文字的区域，无法响应父控件的事件。

文字变小，需要在外部统一设置一下属性文本，这个不是FFLabel的问题，是传递的属性文本有问题，你可以试试看啊，这也应该是不能计算高的原因
关于高亮文本点击问题，我这两天看看，能不能处理一下哈

您好，大神：
我设置的字体是直接获取的label本身的font，字体变小是一个列表偶尔会出现一次，设置字体都是在懒加载里写死的。刚开始以为是转换表情字符的问题，我不转换表情了，还是一样的效果。这是效果图和代码：https://blog.6ag.cn/demo/1.jpg

截图访问 403 了，你在程序中没有使用 attributeString 吗？

截图403刷新一下页面就好了。程序中有使用属性字符串的，并且我用系统的Label显示正常。

把属性字符串的字体从头到位统一设置一下，然后再传递给 label 就好了
示例代码大概是这个样子的：
NSDictionary *attrDict = @{NSFontAttributeName: [UIFont systemFontOfSize:15]};
[attrStr setAttributes:attrDict range:NSMakeRange(0, attrStr.length)];

P.S. 截图还是没有刷出来啊

谢谢！
我刚又检查了一下。发现布局计算高度不准和字体大小改变是由于表情属性文本造成的，不是FFLabel造成的。。。
就差响应除高亮区域外的父控件交互了

找到问题就好，:D

大神，还有个问题。就是当遇到空字符串时，会越界崩溃的。
/// add line break mode
    private func addLineBreak(attrString: NSAttributedString) -> NSMutableAttributedString {
        let attrStringM = NSMutableAttributedString(attributedString: attrString)

        var range = NSRange(location: 0, length: 0)

        // 崩溃代码
        var attributes = attrStringM.attributesAtIndex(0, effectiveRange: &range)
        var paragraphStyle = attributes[NSParagraphStyleAttributeName] as? NSMutableParagraphStyle

        if paragraphStyle != nil {
            paragraphStyle!.lineBreakMode = NSLineBreakMode.ByWordWrapping
        } else {
            // iOS 8.0 can not get the paragraphStyle directly
            paragraphStyle = NSMutableParagraphStyle()
            paragraphStyle!.lineBreakMode = NSLineBreakMode.ByWordWrapping
            attributes[NSParagraphStyleAttributeName] = paragraphStyle

            attrStringM.setAttributes(attributes, range: range)
        }

        return attrStringM
    }

额，这个我记住了，不过我现在机器的环境都是测试版，暂时没法提交修改后的 Swift 框架，过几天我改了提交一下哈，麻烦你现在外面自己判断一下


text:
Vue.prototype.init = function(){this?}

1. prototype的方法里面的this指的是Vue的实例吗？

需要再看一下prototype

回答是的, 这个相当与给所有的实例增加方法或者属性

2.this.constructor.options 中的this.constructor 需要再看一下高程

initData
proxy

initData

把options.data返回一个object对象作为vm._data;
如果options.data是function则执行, 并返回; 否则直接返回

repo: liuyanshi/gesang-fe-blog


text:
"Add secret" form improvements

Add label for "name" and "value" inputs
Display validation error when secret already exists in a hub
Change hub select to a list of radio buttons

Please rebase after #1687 is merged. :)

yup, I know!

authors: josevalim wojtekmach

repo: livebook-dev/livebook


text:
Fix inserting new cells on Safari

Fixes #2003
Creating this PR as draft because I'm not sure if this should rather be addressed in Monaco itself.

Thanks, see https://github.com/livebook-dev/livebook/issues/2003#issuecomment-1607913389 :)

authors: awerment jonatanklosko


text:
Intermittent Error When Interrupting Assistant in LiveKit with OpenAI Assistant

Hello,
I have been working with the LiveKit project, using the integrated OpenAI Assistant, and I have encountered an intermittent problem that occurs when interrupting the assistant while it is responding. Despite having implemented several suggested solutions to properly handle task cancellation and avoid concurrent executions, the error still persists occasionally.
Problem:
When I interrupt the assistant by speaking while it is generating a response, sometimes an error occurs that prevents the assistant from responding to new inputs until I repeat my message. The error that appears in the logs is as follows:
openai.BadRequestError: Error code: 400 - {'error': {'message': 'Thread thread_xxx already has an active run run_xxx.', 'type': 'invalid_request_error', 'param': None, 'code': None}}
This indicates that an attempt is being made to start a new run on a thread that already has an active run, which is not allowed by the OpenAI API.
What I Have Tried to Solve the Problem:

Handling Task Cancellation: I implemented the aclose method in the AssistantLLMStream class to properly cancel the _create_stream_task when the assistant is interrupted.

async def aclose(self):
    if not self._create_stream_task.done():
        self._create_stream_task.cancel()
        try:
            await self._create_stream_task
        except asyncio.CancelledError:
            pass

Exception Handling in _main_task: I modified the _main_task method to handle asyncio.CancelledError and properly close the OpenAI stream.

async def _main_task(self) -> None:
    try:
        # Existing code...
        async with self._client.beta.threads.runs.stream(**kwargs) as stream:
            try:
                await stream.until_done()
            except asyncio.CancelledError:
                await stream.aclose()
                raise
        # Existing code...
    except asyncio.CancelledError:
        logger.debug("AssistantLLMStream _main_task was cancelled")
        pass
    finally:
        if not self._done_future.done():
            self._done_future.set_result(None)

Avoiding Concurrent Executions: I used an asyncio.Lock to ensure that new executions are not started while one is already active.

# In AssistantLLM.__init__()
self._lock = asyncio.Lock()
# When creating an instance of AssistantLLMStream
return AssistantLLMStream(
    # ...
    lock=self._lock,
)
# In AssistantLLMStream._main_task()
async with self._lock:
    # Existing code...
Despite these modifications, the error still occurs intermittently. The assistant sometimes correctly handles the interruption and responds to the new input, but other times it does not, and the error appears in the logs.
Relevant Logs:
Here are excerpts from the logs showing the error:
2024-11-21 12:06:03,705 - DEBUG livekit.plugins.openai - AssistantLLMStream _main_task was cancelled
openai.BadRequestError: Error code: 400 - {'error': {'message': 'Thread thread_xxx already has an active run run_xxx.', 'type': 'invalid_request_error', 'param': None, 'code': None}}
Additional Information:

The error does not occur every time, suggesting that there may be a race condition or a case where the previous execution is not completely cancelled before starting a new one.

I have noticed that the problem occurs more frequently when the interruptions are very quick or consecutive.

The "channel closed" messages are now logged as DEBUG and do not seem to be directly related to this issue.

I Request Help To:

Identify the root cause of this intermittent error.

Get suggestions on how to ensure that previous executions are completely cancelled before starting new ones.

Understand if there is any additional configuration or state management that should be implemented to avoid this conflict with the OpenAI API.

Any guidance or code examples that you can provide would be greatly appreciated. Thank you in advance for your time and assistance!
I appreciate any help you can provide to resolve this issue.

I often receive this error as well

authors: JeisonNovoa RenegadeMaster

repo: livekit/agents


text:
AttributeError: module 'livekit.plugins.openai' has no attribute 'LLMStream'

I am trying to get all the messages in the Chat Context for the Voice Assistant once the room is disconnected.
I came across the AssistantContext which takes in the assistant and llm _stream as input.
However, when trying to get the llm_stream using the openai.LLMStream method, this is the error I am getting
   llm_stream = oai.LLMStream()                  ^^^^^^^^^^^^^ AttributeError: module 'livekit.plugins.openai' has no attribute 'LLMStream'
This is how I have initialised the assistant and its components
from livekit.agents.voice_assistant import VoiceAssistant, AssistantContext from livekit.plugins import deepgram, elevenlabs, openai, silero
stt = deepgram.STT()     tts = elevenlabs.TTS(model_id='eleven_multilingual_v2', voice=VOICE)     oai = openai     llm=oai.LLM()     llm_stream = oai.LLMStream()
`
assistant = VoiceAssistant(         vad=silero.VAD(), # Voice Activity Detection         stt=stt, # Speech-to-Text         llm=llm, # Language Model         tts=tts, # Text-to-Speech         chat_ctx=initial_ctx, # Chat history context     )
then this is how I will be getting the context, and hope to get the messages
assistant_ctx = AssistantContext(assistant, llm_stream)     assistant.start(ctx.room)
assistant_ctx.get_metadata(assisstant, llm_stream)
Also, is there a better way to get all the messages in the ChatContext from the llm? Or, wondering even if this the right way?

I have recently installed all the new packages from livekit.
livekit                   0.11.1                   pypi_0    pypi livekit-agents            0.7.2                    pypi_0    pypi livekit-api               0.5.0                    pypi_0    pypi livekit-plugins-deepgram  0.5.1                    pypi_0    pypi livekit-plugins-elevenlabs 0.6.0                    pypi_0    pypi livekit-plugins-openai    0.6.0                    pypi_0    pypi livekit-plugins-silero    0.5.1                    pypi_0    pypi

Hey, this is correct the type should be exposed. Otherwise you don't have to  create a LLMStream manually. Use oai.LLM().chat function

authors: naman-scogo theomonnom


text:
Custom Video Source using AVFoundation

I'm looking for a way to add a custom video source like providing the video frames by AVCapturesession with a custom captureOutput implementation. Is that possible using LiveKit?

I want to implement the custom CameraCapturer too.
But looks like it was using RTCCameraVideoCapturer from webrtc and also cannot extends VideoCapturer outside the module.

From my point of view, it would be enough to know how to feed the frames to webrtc manually. So I could retrieve the frames via captureOutput and hand them over to WebRTC videoCapturer?

@andreasteich then I think maybe you want something like this LocalVideoTrack.createBufferTrack().

Okay thank you very much! Do you have some more informarion about that? Can't find documentation for that...

You're amazing thank you very much!

You're amazing thank you very much!
So if I understand it correctly, when I'm receiving CMSampleBuffers inside captureOutput of AVCaptureSession, I can pass those buffers on to the capturer.capture(...) with proper configuration provided for BufferCapturer and LocalVideoTrack on setup?
Can you confirm @ming-chu ?

I think so, but honestly I didn't tested it out. I would like to hear from you about the results 😃

So I keep this issue until implementation done. Thank you very much!

@Negi-Rohit yes, was able to do so by following @ming-chu instructions. Just Create the BufferTrack and pass it some CMSampleBuffer or CVPixelBuffer objects.
Works incredibly well!

authors: andreasteich ming-chu

repo: livekit/client-sdk-swift


text:
Can only claim one round of earnings at a time

Describe the bug (required)
A clear and concise description of what the bug is.
Expected behavior (required)
A clear and concise description of what you expected to happen.
To Reproduce (required)
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Device (required):

Device: [e.g. MacBook Pro, iPhone6]
OS: [e.g. iOS, Linux]
Browser [e.g. Chrome, Safari]
Version [e.g. 22]

Screenshots (optional)
If applicable, add screenshots to help explain your problem.
Console logs (optional)
Paste related logs and/or error messages from the console here.
Network issues, such as the cURL output from failing requests, can also be pasted here.

Additional context (optional)
Add any other context about the problem here.

This has been fixed. This was an issue on the classic explorer which was moved into a separate repo here.

repo: livepeer/livepeerjs