adds contact us section and newsletter subscribe

Ok updated per notes - Thanks @IamManchanda and @canterberrie !
Good to merge? @canterberrie

Looks good to me too!


CONTRIBUTING.md file link broken.

At the end of the README.md, where it says to read the CONTRIBUTING.md file, the link is broken as it says CONTRIBUTING.md instead of CONTRIBUTION.md. Thank you.

Hey @CodingSpecies ,
Thanks for raising the issue, actually the CONTRIBUTION.md file isn't also updated, It would be great if you would like to work on that and contribute to this repository and help me in making it big.
Happy Open-Sourcing!!!

@Subhampreet thank you I will work on it.

I have assigned you the issue, work on it, and also link it to the PR you send so that the issue gets closed too when I merge your PR.

Sure thanks

#29


MockClient verifyMembership error

The proof commitment for MsgRecvPacket  uses sha256 + sha256 .
https://github.com/hyperledger-labs/yui-ibc-solidity/blob/64b95470cabe3b660c6e8d36ea58bf85b5e23dfa/pkg/relay/ethereum/chain.go#L229
https://github.com/cosmos/ibc-go/blob/12c00ec85c1238a0b9075a14593485c60f0da729/modules/core/04-channel/types/packet.go#L19
On the other hand, IBCPacket uses sha256 + sha256 and  MockClient verifyMembership further performs sha256, which always seems to cause an error. In fact, it failed in my environment.
https://github.com/hyperledger-labs/yui-ibc-solidity/blob/64b95470cabe3b660c6e8d36ea58bf85b5e23dfa/contracts/core/04-channel/IBCPacket.sol#L113-L120
https://github.com/hyperledger-labs/yui-ibc-solidity/blob/64b95470cabe3b660c6e8d36ea58bf85b5e23dfa/contracts/clients/MockClient.sol#L149
It looks like we should'n use sha256 for verifyMembership in MockClient, but it is still an error because sha256 is used in yui-relayer for connection and channel.
https://github.com/hyperledger-labs/yui-relayer/blob/d4cc52059626e9dd86433dbd78de0c40fba87f5b/provers/mock/prover.go#L159
As a tentative response, I was able to prevent the error by modifying MockClient's verifyMembership as follows.
//before
return sha256(value) == proof.toBytes32(0);

//after
bytes32 v = value.toBytes32(0); // for packet
bytes32 s = sha256(value); // for connection and channel
bytes32 p = proof.toBytes32(0);
return s == p; || v == p;

We are closing this issue because we have found that this is a problem with older versions and that the latest version behaves differently.

This is

I think the problem is that the mock-client does not support the generic verification function.
https://github.com/datachainlab/ibc-mock-client/blob/main/modules/light-clients/xx-mock/types/client_state.go#L225
The property of being able to verify commtiment in the same method, independent of the commitment path, would be important to support some applications (e.g. https://github.com/cosmos/ibc/tree/main/spec/app/ics-031-crosschain-queries)

I close this issue since already opened the issue in ibc-mock-client: https://github.com/datachainlab/ibc-mock-client/issues/7


Think about saving/restoring machine in (JSON) for example

When you get around to taking a look at this, I have some code that could be useful https://github.com/erdo/persista, it will store/read any class that has a kotlin serializer (stored as a JSON text fille). If you think it might be useful, feel free to copy-paste the class / maybe remove its external dependencies, whatever suits you. kstatemachine looks very nice 👍

@erdo Hi! Thank you, I really appreciate your help. I will take a look at your code.
Do you need this feature in a kstatemachine?

No not urgently. I have just been thinking about using a state machine to implement navigation on android apps since forever - I think kstatemachine could probably drive something like that

Ok. In case of UI navigation, to support "navigateUp()" actions, some kind of memory for state machine must be implemented. Currently kstatemachine lacks such functionality.

currently there is no builtin solution in the library. But you should be able to serrialize your states using kotlinx-serialization if you provide seriazilers for  them. I suppose it can be implemented like a new kind of visitor to walk through kstatemachine state/transition hierarchy.

Event recording implemented in https://github.com/KStateMachine/kstatemachine/releases/tag/v0.30.0 version


No Access to DropDownMenu or AlertDialog in common source set

We currently can't access the DropDownMenu or AlertDialog from the common source set for compose. Someone mentioned this was because of PopupProperties.

For DropDownMenu we can create a common function in commonMain:
fun DropdownMenu(
    expanded: Boolean,
    onDismissRequest: () -> Unit,
    modifier: Modifier = Modifier,
    offset: DpOffset = DpOffset(0.dp, 0.dp),
    content: @Composable ColumnScope.() -> Unit
)

@igordmn I did it and here is the result
https://github.com/JetBrains/compose-jb/issues/758

What is blocking you from adding DropdownMenu as an expected declaration?

Is there some milestone for this issue??
Access AlertDialog and DropDownMenu from common sources set sounds great.
compose-android // compose-ios // compose-desktop // compose-web

It was released in 1.5.0

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Add choco package files and readme

It adds the needed files to setup the choco package, taking inspiration from GhcChoco and CabalChoco
Not sure if the powershell code will be too advanced for some windows versions

@Mistuke could you take a look if you get a chance? many thanks in advance

It adds the needed files to setup the choco package, taking inspiration from GhcChoco and CabalChoco
Not sure if the powershell code will be too advanced for some windows versions

The chocolatey verifier service will check this on upload. It always checks against the least common denominator.

@Mistuke could you take a look if you get a chance? many thanks in advance

Awesome! This looks good to me, the only comment I have is that I've recently moved to using the tools install location https://github.com/Mistuke/GhcChoco/commit/93676e55aca7629de5b244393117b9decb503ba1 which is a bit faster as it doesn't force the hashing requirements of any files you download and also removes the need for admin rights and allows people to change it by setting environment variables.


scala-runners: init at 0c0b369

This is a script to run multiple versions of scala either by version number or build hash.

Motivation for this change
It's a good script and useful for testing with pre-release and non-current versions of Scala.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS <-- don't have one!
[ ] other Linux distributions <-- don't have any but can if you like

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests) <-- manually tested this; coursier and jdk are the only upstreams
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after) <-- Total closure size is 390.4Mb but almost all of that is openjdk and coursier
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

?

#128060 to replace this because apparently force-push then reopen doesn't work. yay, github.


DRILL-8088: Improve expression evaluation performance

DRILL-8088: Improve expression evaluation performance
Description
Remove unnessesery map copy each time when enter new scope.
Documentation
No need
Testing
Will be tested in many existed UT which query with "case when", e.g. ifExpression in TestLimit0VsRegularQueriesMetadata

Hi @luocooong, looks like you're looking at the expression and operator code. I wonder, is there anything you're trying to improve? Execution performance, maybe?
As you know, Drill is very complicated. Drill uses code generation for expression evaluation. The code generation goes though a path that made sense for Java 5 (when Drill was written), but is now a bit awkward. We do have a way to use the native Java tools, which worked faster several years ago; that path is probably even faster now.
Operator setup (another of your PRs) is impacted by code gen cost. Drill generates code for each fragment. If your query has 20 fragments, we generate code 20 times. The reason we must do that is that, in theory, every fragment can see a different schema, so the generated code could differ. By comparison, Spark generates code once, then pushes that code to all its executors.
The generated code itself can be rather awkward for large queries: the code tries to inline everything which is great for small functions, but causes optimization problems as code blocks get larger.
The mechanism to generate code, especially in the PROJECT operator, is vastly overly complex and could use a good re-think. It is so complex that it is hard to optimize because of the many assumptions and other issues embedded in the code.
The generated code is meant to be small. But, over time, some operators added lots of "standard" code to the code generation path. The work is more work for the compiler and "byte code optimizer" that adds no per-query value. We've taken several passes at refactoring to pull that code of the code gen path, but there is more to do.
Drill was designed to allow vector operations (hence Value Vectors), but the code was never written. In part because there are no CPU vector instructions that work with SQL nullable data. Arrow is supposed to have figured out solutions (Gandiva, is it?) which, perhaps we could consider (but probably only for non-nullable data.)
Anyway, there are many areas we can improve. I can give you more details if I know what you're trying to accomplish.

Drill was designed to allow vector operations (hence Value Vectors), but the code was never written. In part because there are no CPU vector instructions that work with SQL nullable data. Arrow is supposed to have figured out solutions (Gandiva, is it?) which, perhaps we could consider (but probably only for non-nullable data.)

Hi @paul-rogers, I think that what Arrow does for computations over nullable data is store an external null mask and compute results for every record, including the null ones where the value vector contains either rubbish or some sentinel value.  In a second pass, a null mask is computed for the result.  This results in wasted arithmetic operations for null values, but in practice that's better than a branch for every value.  Quite possibly even for pretty sparse vectors.

Drill was designed to allow vector operations (hence Value Vectors), but the code was never written. In part because there are no CPU vector instructions that work with SQL nullable data. Arrow is supposed to have figured out solutions (Gandiva, is it?) which, perhaps we could consider (but probably only for non-nullable data.)

Hi @paul-rogers, I think that what Arrow does for computations over nullable data is store an external null mask and compute results for every record, including the null ones where the value vector contains either rubbish or some sentinel value. In a second pass, a null mask is computed for the result. This results in wasted arithmetic operations for null values, but in practice that's better than a branch for every value. Quite possibly even for pretty sparse vectors.

i'm sure you have already discussed this, but i would like to know why we are not migrating to arrow and cannot find any information about this decision. As far as i know, arrow was inspired by drill and on the arrow homepage they have still the picture with drill on it but drill does not use arrow. https://arrow.apache.org/overview/
Is there any official statement from the project for the arrow support/migration?

i'm sure you have already discussed this, but i would like to know why we are not migrating to arrow and cannot find any information about this decision. As far as i know, arrow was inspired by drill and on the arrow homepage they have still the picture with drill on it but drill does not use arrow. https://arrow.apache.org/overview/
Is there any official statement from the project for the arrow support/migration?

@Z0ltrix there isn't an official statement that I know of.  It's too big a question for a comment thread answer and a good topic for a community meetup with some senior devs present.  I believe that to some extent Drill's vector engine has developed in its own direction since Arrow arrived and the best route forward for Drill is now not entirely obvious, and needs some thought.  Significant pros for Arrow are that it is maintained externally and I believe its performance is very good.

@paul-rogers Hello, thanks for the information. I just have a few questions I'd like to know..

 If we are going to use the native java tools, is there anything we can do for this?
Use provided-schema : If we provide the schema at query time, does it mean that we can also generate code once like Spark?
Refactors and changes : Is there any reference old tickets were used to rewrite and improve the CG path?
Vectorization : As I understand, Drill only implements vector storage, but had not implemented the vectorization base on these vector value, is that correct?

@luocooong @paul-rogers I've always thought of Drill's code gen as being an effort to present a good target for the JVM's auto-vectorisation.  Not that this is likely to get the same results as the new SIMD intrinsics in the JVM, or a nice way to code.  Is this on the mark?  A reference:
https://cr.openjdk.java.net/~vlivanov/talks/2019_CodeOne_MTE_Vectors.pdf

@luocooong, here are answers to your questions:
Code gen: Drill already supports "plain Java" code gen and use of the standard compiler without byte code fixup. It is what is used when you set the magic flag in each operator, then ask to save code for debugging. In the tests I did way back when, he "plain Java" path performed at least as well as the Janino/byte-code-fixup path.
If you are not familiar with the "save code for debugging" mechanism, you should be if you want to look at optimization. I'd by happy to describe it (or hunt down to see if it is already described in the Wiki.)
Provided schema: There are three cases to consider.

Explicit SELECT: SELECT a, b, c FROM .... In this case, if we have a schema, then all operators will use exactly the same code and we can generate once.
"Lenient" wildcard: SELECT * FROM ..., where the file (such as JSON or CSV) may have more columns than described by the "provided schema". In this case, each reader is free to add the extra columns. Since each file may be different, each reader will produce a different schema, and downstream operators must deal with schema-on-read; the code cannot be shared.
"Strict" wildcard: readers include only those columns defined in the schema. For this option, we can also generate code once.

Refactors: there are probably some random assortment of tickets filed as various people looked into this area. However, this is more than a "change this, improve that" kind of thing, it probably needs someone to spend time to fully understand what we have today and to do some research to see if there are ways to improve the execution model. Hence, this discussion.
Vectorization: that is a complex discussion. I'll tackle that in another note.

All: so I've kicked the hornet's nest with the mention of value vectors and Arrow. I'm going to put on my flame-proof suit and debunk some myths.
The columnar format is great for storage, for all the usual reasons. This is why Parquet uses it, Druid uses it for segment files, and various DBs use it for storage. The question we want to ask is, do those benefits apply to the format within the Drill execution engine? I'm here to suggest that columnar has no advantage, and many disadvantages, when used as the internal format of an execution engine. "Thems is fighting words", so let's bring it on.
I've had the pleasure of working with several query engines: Drill (columnar) and Impala (row-based) are two well-known examples. This has given me a unique opportunity to see if all the marketing claims for columnar (which still appear in the videos on Drill's website) actually hold up in practice. Spoiler: they don't.
This is a PR about optimization. A good rule in optimization is to start with the biggest issues, then work toward the details. So, rather than tinker with the details of vector execution, let's look at the fundamental issues.
Myth: Vectorized execution: The biggest myth is around vectorized execution. Of course, a minor myth is that Drill uses such execution (it doesn't.) The bigger myth is that, if we invested enough, it could.
Vectorized execution is great when we have a simple operation we apply to a large amount of data. Think the dot-product operation for neural networks, or data compression, or image transforms, or graphics. In all cases, we apply a simple operation (rescale, say) to a large amount of homogeneous data (the pixels in an image.)
So, the question is, does typical, real-world SQL fit this pattern? I've now seen enough crufty, complex, messy real-world queries to suggest that, no, SQL is not a good candidate for vectorization. SELECT and WHERE clauses embed business logic, and that logic is based on messy human rules, not crisp, clean mathematics. The resulting SQL tends to have conditionals (WHEN or IF(), etc.), lots of function calls (all those cool UDFs which @cgivre has written), and so on. Plus, as noted above, SQL deals with NULL values, which must short-circuit entire execution paths.
Hence, even if we could vectorize simple operations, we'd find that, in most queries, we could not actually use that code.
Myth: Vectors are CPU Cache Friendly: The second big myth is that vectors are somehow more "friendly" to the CPU L1 cache than a row format. The idea is that one can load a vector into the L1 cache, then zip through many values in one go. This myth is related to the above one.
First, SQL expressions are not based on columns, they are based on rows. Each calculation tends to involve multiple columns: net_receipts = sales + taxes - returns. Here each calculation touches four vectors, so we need all four to be in the CPU cache to benefit.
Second, SQL is row based: that above calculation is just one of perhaps many that occur on each row. In the ideal case, the calculations for independent groups: SELECT a + b AS x, c - d + e AS y, f / g AS z, .... In this case, we could load vectors ``a, b, x into the L1 cache, do the calcs, then load c, d, e and y in the cache and so on. Of course, Drill doesn't work this way (it does all the calculations for a single row before moving to the next), but it could, and it would have to to benefit from vectorization.
A more typical case is that the same column is used in multiple expressions: SELECT a + b AS x, a / c AS y, (a - d) * e AS z, ... In this case, we must load the a vector into the L1 cache multiple times. (Or, more properly, its values would continually be bumped out of the cache, then reloaded.)
Myth: Bigger Vectors are Better: Drill went though a phase when everyone bought into the "L1 cache" myth. To get better performance everyone wanted ever larger vectors. In the code, you'll see that we started with 1K-row batches, then it grew to 4K, then other code would create 64K row batches. It got so bad we'd allocate vectors larger than 16MB, which caused memory fragmentation and OOM errors. (This is the original reason for what evolved to be "EVF": to control vector sizes to prevent memory fragmentation - very basic DB stuff.)
Remember, the CPU L1 cache is only about 256K in size. A 4MB vector is already 16x the L1 cache size. Combine that with real-world expressions and we end up with a "working set" of 10s of MB in size: 20x or more the L1 cache size. The result is lots of cache misses. (This stuff is really hard to measure, would be great for someone to do the experiments to show this happening in practice.)
Myth: Vectors are Efficient: A related, minor myth is that writing to vectors is more efficient than writing to rows. This is not true in general. In Drill, it is especially false. Originally, vectors were allocated at some small initial size (256K? Something like that.) Vectors grow as we add data. (That's one of the things that make working with them difficult.) Fill the 256K vector? We double it to 512K and copy across the data. We do again at 1MB, 2MB, 4MB, ... In the end, to grow to 4MB, copy about 4MB of data. That is 4MB of reads, 4MB of writes, in addition to the 4MB of writes needed to create the data.
Later, a bunch of ad-hoc "batch sizing" code was added to try to guess a good initial size for vectors. Not too hard or fixed-width vectors (INT, say), but rather tricky for variable-width vectors (VARCHAR).
Remember that each vector is sized and grows independently. So, to create a batch, we have to track the size of every vector, grow those that need growing, but not over-allocate all the vectors because the space is not fungible: vector a can't "borrow" unused space from vector b.
The point is, Drill needs a large amount of complex, add-on code just to work around the fact that every vector will grow, and copy data, if not sized correctly, and, in general, we don't know ahead of time what the size should be. The result is inefficiency.
Single Data Format for In-Memory and Over-the-Wire: One of Drills' claims to fame is that value vectors (and, later Arrow vectors) use the same layout in memory as over the wire, leading to efficient exchanges via RPC. This myth is true, as far as it goes. But, if you look at the code, the truth is much more complex. On the sender side, vectors are independent buffers (as explained above.) On the receiver side, the whole message comes in as one big buffer. Special code slices up that buffer to recover vectors. A vast amount of complex code is needed to handle the accounting. (Thanks to Chris, a one-time Drill contributor who wrote all that code well enough that it "just works". It would be hell to fix otherwise.)

The last topic is so complex that no myth has grown up around it, and the issue is not at all well understood.  This gets pretty techie, so hang on.
Vectors are Hell for Exchanges:  This comes from a real-world case in which a large cluster worked no faster than a single thread of execution. We've discussed how Drill wants to create large batches (per the myth) to benefit from vectorization (which we don't have) and to optimize L1 cache usage (which, as we've seen, we don't actually do.) Let's assume "small" batches of 1K rows.
Drill also wants the single format for in-memory and over-the-wire usage. This means we want to transfer 1K record batches so that the receiver gets batches of the optimal in-memory size.
Now, what happens in a distributed system? Assume you have 100 fragments running. (Maybe 10 machines with 10 cores each.) Let's think about one fragment, call it "f0.0". Let's assume f.0.0 runs a scan and a network sender. The scan builds up its 1K batches, because those are "efficient" (according to the myths we've discussed.)
What does f0.0's network sender do? Let's assume the target is a hash join. So, the sender hashes the keys into 100 buckets. Now, the sender follows Drill's rule: send 1K record batches. Since there are 100 targets, the sender has to create 100 buffered batches, fill them each to 1K records, then send them. To visualize:
f0.0 (reader --> sender) - - > f1.x (receiver --> hash-join --> ...) ...
There are 100 f0 fragments: f0.0, ... f0.99, we're looking just at one of them: f0.0. The f0 "slice" sends to the "f1" slice that consists of 100 additional fragments: f1.0, ... f1.99.
So, what happens in our sender? Assuming even hash distribution, we have to fill all our 100 outgoing batches before we can send them. This means we have to read 100 * 1K = 100K input records before we send the first outgoing batch. The result is a huge memory usage (those 100 batches), plus all the vector resizes and copies we discussed (as we grow those batches.)
If that we not bad enough, this occurs in all our other 99 f0 fragments: we've got 100 * 100 = 10K buffered batches waiting to send. Yikes!
Now, what happens in f1? It is sitting around waiting for data. No f0 will send until if fills its first outgoing batch for that receiver. If we assume an even distribution of data, then the outgoing batches fill at about the same rate. None can be sent until one of them reaches the target, at which point most of them are near-full. Once the first hits the 1K mark, off it goes to f1 who can filly start processing. This is bad because Drill claims to be highly distributed, but we just described is a serial way of working.
But, it gets worse! Now, assume we're deeper in the DAG, at a sort:
f4: (receiver --> sort --> sender) - - > f4: (receiver --> merge --> ...)
The sort sorts its slice of records, and sends it to the merge fragment which merges all the partial sorts. Classic distributed systems stuff. Again, the f4 (sort) sender waits to fill its outgoing batches, then it sends. The merge can't start until it sees batches from all 100 inputs. So, it proceeds at the rate of the slowest sort.
Now what happens? The merge uses up one of the 100 input batches, and needs another before it can proceed. But, here things get really nasty.
On the f4 side, f4.0, say, sent the first batch to get full. It then sent the others as they filled. Meanwhile, the first batch started refilling and eventually will need to be sent again. Since the merges can't read a new batch until its used up the previous one, it blocks the f4 sender. As a result, f4 can't send to any other merge.
The downstream fragment throttles the upstream, and visa versa. Not quite deadlock, but the entire system becomes serialized: the sort can't ship batches until the slowest merge can receive them. The merge can't make progress until the slowest sort provides the next batch. Every fragment depends on every other. Disaster!
Again, we spent hours trying to figure this out on a customer cluster. We could see the effect, but we could not get in to work out the details. Would be great for someone to do the experiments.
Summary: The above has debunked the major myths around columnar storage within a query engine. Note that none of the above changes if we use Arrow. We'd do a huge amount of work to switch, and be stuck with the same fundamental problems.
Hence, we have to think deeply about this issue, not just by the snake oil that "vectors are good for an execution engine." Good old solid engineering and experimentation will tell us what's what.

OK, so the above raise the issues we have to consider when thinking about vectors (Drill's or Arrow's.) What is the alternative?
Here, I think Impala got it right. Impala uses Parquet (columnar) for storage, but rows for internal processing. Impala is like an Italian sports car of old: spends lots of time in the shop, but when it works, it is very fast.
One of the reasons that Impala is fast is because of the row format.  First, let's describe what "row-based" means. It means that columns appear together, as in a C struct, with rows packed one after another as in an array of structs. This means that the data for a given row is contiguous. There is only one buffer to size. Classic DB stuff that seems unusual only because we're all used to Drill's vector format.
Let's look at the same issues above, but from a row-based perspective.
Expression Execution: With a row-based model, the CPU can easily load a single row into the L1 cache. All our crufty-real-world expression logic works on that single row. So, no matter how messy the expressions, from the CPU's perspective, all the data is in that single row, which fits nicely into the cache.
Rows can be small (a few dozen bytes) or large (maybe a 10s of K for long VARCHARs). In either case, they are far smaller than the L1 cache. The row is loaded. Once we move onto the next row, we'll never visit the previous one, so we don't care if the CPU flushes it from the cache.
Memory Allocation: Rows reside in buffers (AKA "pages"), typically of a fixed size. A reader "pours" data into a row. When the page is full, that last record is copied to the next page. Only that one row is copied, not all the existing data. So, we eliminate the 1X copy + 1X load problem in Drill. Since there is only one page to allocate, memory is simpler. Since pages are of fixed size, memory management is simpler as well.
Exchanges: Network exchanges are row-based. Rows are self-contained. A network sender can send single rows, if that is efficient, or batches of rows. In our 100-senders-100-receiver example, we could send rows as soon as they are available. The receiver starts working as soon as the first row is available. There is no near-deadlock from excessive buffering.
Yes, we would want to buffer rows (into pages) for efficiency. But, in extreme cases, we can send small numbers of rows to keep the DAG flowing.
Clients: As noted above, row-based clients are the classic solution and are simple to write. We could easily support proper clients in Python, Go, Rust and anything else if we used a row-based format.
Conclusion: We tend to focus on the "value vector vs. Arrow" discussion. I'm here to say that that is the wrong question: it buys into myths which have hurt Drill for years. The correct question is: what is the most efficient format for the use cases where Drill wants to excel? The above suggests that, rather than Arrow, a better solution is to adopt a row-based internal format.

One last note. Let's assume we wanted to adopt the row-based format (or, the myths being strong, we want to adopt Arrow.) How would we go about it?
The "brute force" approach is to rewrite all the operators. Must deal with low-level vector code, so we'd rewrite that with low-level row (or Arrow) code. Since we can't really test until all operators are converted, we'd have to do the entire conversion in one huge effort. Then, we get to debug. I hope this approach is setting off alarm bells: it is high cost and high risk. This is why Drill never seriously entertained the change.
But, there is another solution. The scan readers all used to work directly with vectors. (Parquet still does.) Because of the memory reasons explained above, we converted most of them to use EVF. As a result, we could swap vectors for row pages (or Arrow) by changing the low-level code. Readers would be blissfully ignorant of such changes because the higher-level abstractions would be unchanged.
So, a more sane way to approach a change of in-memory representations is to first convert the other operators to use an EVF-like approach. (EVF for writing new batches, a "Result Set Loader" for reading exiting batches.) Such a change can be done gradually, operator-by-operator, and is fully compatible with other, non-converted operators. No big bang.
Once everything is upgraded to EVF, then we can swap out the in-memory format. Maybe try Arrow. Try a row-based format. Run tests. Pick the winner.
This is not a trivial exercise, but it is doable over time, if we see value and can muster the resources.

@paul-rogers Thanks for your knowledge base. For the vectorization and Arrow, I may need to keep pouring cold water for everyone. I think we need to figure out what we need here is, not just see it as powerful, then say it's really powerful.
SQL, NoSQL and NewSQL
In my work, I went through these three databases architecture. Initially, we had performance bottlenecks, so choose the NoSQL database, eg : mongo, es and redis. After entering the production environment, most developers were not good at using the API(clients) designed for these databases. The key is that developers do not have the patience to learn the advanced syntax of each database(NoSQL). So we come back to use the SQL-style database : NewSQL. But, we found that NewSQL also has many bottlenecks(once you don't think need any optimization), especially once you comes to deploy a private cluster, you'll get complex operation and maintenance conditions and user complaints.
Here, the lesson is that choosing the right one is better than choosing it blindly.
OLTP, OLAP and HTAP
The row format is good for OLTP, because need to insert / update / delete and batch fetch entire rows as soon as possible. The columnar format is good for OLAP, because need to analyze large amounts of data. To keep low latency, need to filter data size from the disk and reduce network IO bottlenecks. What does HTAP look like? let's see that Internal implementation of TiDB :

TiFlash provides the columnar storage, it conducts real-time replication of data in the TiKV nodes
at a low cost that does not block writes in TiKV. Meanwhile, it provides the same read consistency
as in TiKV and ensures that the latest data is read.

As is well known, database vendors prefer to use row format to apply in OLTP and columnar format to support OLAP. However, they are well aware that there is no perfect data format. So that, I agree with Paul that the row format is better for Drill.
CPU Cache miss

N-ary Storage Model

Cache miss

The figure shows the processing of CPU caches, and we can see that a lot of invalid data is being filled into the cache, crowding out data that would otherwise have been reusable.

Decomposition Storage Mode

Reduce cache-miss is one of the advantages of the columnar format, but note that Paul has explained that there will also be cache-miss(calculation based in SQL syntax) in the columnar format. So that, we cannot expect the maximum performance with Arrow.
Write amplification
Avoid becoming a database system, but Drill has several key points on the read-write path.

Drill support split vector value to disk.
Drill is an engine, isn't a database, unable to unify the initial source format(made in the database vendor).
Complex read-write path :

(1) Read from a variety of data sources.
(2) Write to vector value or split to disk.
(3) Combined to row sets.
(4) Client side.

As noted above, Impossible to avoid read and write multiple times in a query, and the write amplification will increase latency. So that, there's a lot to optimize, not only the columnar format.


ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py

when I try to open turtlebot3_model = waffle the robot not shown in gazebo world but the scan is visible .

launch.log

It resolved after reboot but still wonder why it happened.

ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py
[INFO] [launch]: All log files can be found below /home/hasan/.ros/log/2023-10-03-13-25-00-843416-hasan-TULPAR-T7-V20-2-21387
[INFO] [launch]: Default logging verbosity is set to INFO
urdf_file_name : turtlebot3_waffle.urdf
urdf_file_name : turtlebot3_waffle.urdf
[INFO] [gzserver-1]: process started with pid [21391]
[INFO] [gzclient-2]: process started with pid [21393]
[INFO] [robot_state_publisher-3]: process started with pid [21395]
[INFO] [spawn_entity.py-4]: process started with pid [21397]
[robot_state_publisher-3] [INFO] [1696328702.095739897] [robot_state_publisher]: got segment base_footprint
[robot_state_publisher-3] [INFO] [1696328702.095856757] [robot_state_publisher]: got segment base_link
[robot_state_publisher-3] [INFO] [1696328702.095866587] [robot_state_publisher]: got segment base_scan
[robot_state_publisher-3] [INFO] [1696328702.095871929] [robot_state_publisher]: got segment camera_depth_frame
[robot_state_publisher-3] [INFO] [1696328702.095876800] [robot_state_publisher]: got segment camera_depth_optical_frame
[robot_state_publisher-3] [INFO] [1696328702.095881920] [robot_state_publisher]: got segment camera_link
[robot_state_publisher-3] [INFO] [1696328702.095886540] [robot_state_publisher]: got segment camera_rgb_frame
[robot_state_publisher-3] [INFO] [1696328702.095891173] [robot_state_publisher]: got segment camera_rgb_optical_frame
[robot_state_publisher-3] [INFO] [1696328702.095910251] [robot_state_publisher]: got segment caster_back_left_link
[robot_state_publisher-3] [INFO] [1696328702.095914766] [robot_state_publisher]: got segment caster_back_right_link
[robot_state_publisher-3] [INFO] [1696328702.095919118] [robot_state_publisher]: got segment imu_link
[robot_state_publisher-3] [INFO] [1696328702.095923376] [robot_state_publisher]: got segment wheel_left_link
[robot_state_publisher-3] [INFO] [1696328702.095927925] [robot_state_publisher]: got segment wheel_right_link
[spawn_entity.py-4] [INFO] [1696328702.483233629] [spawn_entity]: Spawn Entity started
[spawn_entity.py-4] [INFO] [1696328702.483520489] [spawn_entity]: Loading entity XML from file /home/hasan/pcl_ws/install/turtlebot3_gazebo/share/turtlebot3_gazebo/models/turtlebot3_waffle/model.sdf
[spawn_entity.py-4] [INFO] [1696328702.484128413] [spawn_entity]: Waiting for service /spawn_entity, timeout = 30
[spawn_entity.py-4] [INFO] [1696328702.484388842] [spawn_entity]: Waiting for service /spawn_entity
[spawn_entity.py-4] [INFO] [1696328702.987694323] [spawn_entity]: Calling service /spawn_entity
[gzserver-1] [INFO] [1696328703.243750808] [turtlebot3_imu]: <initial_orientation_as_reference> is unset, using default value of false to comply with REP 145 (world as orientation reference)
[spawn_entity.py-4] [INFO] [1696328703.332019477] [spawn_entity]: Spawn status: SpawnEntity: Successfully spawned entity [waffle]
[INFO] [spawn_entity.py-4]: process has finished cleanly [pid 21397]
[gzserver-1] [INFO] [1696328704.055513828] [camera_driver]: Publishing camera info to [/camera/camera_info]
[gzserver-1] [INFO] [1696328704.056688060] [camera_driver]: Publishing depth camera info to [/camera/depth/camera_info]
[gzserver-1] [INFO] [1696328704.056896104] [camera_driver]: Publishing pointcloud to [/camera/points]
[gzserver-1] [INFO] [1696328704.147841488] [turtlebot3_diff_drive]: Wheel pair 1 separation set to [0.287000m]
[gzserver-1] [INFO] [1696328704.147879273] [turtlebot3_diff_drive]: Wheel pair 1 diameter set to [0.066000m]
[gzserver-1] [INFO] [1696328704.148557932] [turtlebot3_diff_drive]: Subscribed to [/cmd_vel]
[gzserver-1] [INFO] [1696328704.149637805] [turtlebot3_diff_drive]: Advertise odometry on [/odom]
[gzserver-1] [INFO] [1696328704.150997393] [turtlebot3_diff_drive]: Publishing odom transforms between [odom] and [base_footprint]
[gzserver-1] [INFO] [1696328704.158385674] [turtlebot3_joint_state]: Going to publish joint [wheel_left_joint]
[gzserver-1] [INFO] [1696328704.158412400] [turtlebot3_joint_state]: Going to publish joint [wheel_right_joint]


eth_mcux: ipv6 works on both interfaces only when promiscuous mode is enabled.

When both interfaces are enabled. I can only ping a single interface unless promiscuous mode is enabled.

@danieldegrasse any comment on this one?

@danieldegrasse any comment on this one?

Unfortunately I don't have a good way to reproduce this, as none of the NXP EVKs I'm aware of have multiple ENET interfaces enabled in Zephyr. @jameswalmsley-cpi, if you can provide more details on where you see the error I can attempt to help narrow this down, but unfortunately I don't have hardware I can reproduce it with.

This bug report is unclear and seems to be raised against the reporter's own PR that was never merged https://github.com/zephyrproject-rtos/zephyr/pull/60073, so closing this for now, reopen if necessary


ERROR in ENOENT: no such file or directory, lstat '/node_modules/graphql/index'

Intended outcome:
Serve angular app with Ivy enabled
Actual outcome:
When ivy enabled with the latest .next version of Angular, an error is thrown
ERROR in ENOENT: no such file or directory, lstat '/node_modules/graphql/index'

How to reproduce the issue:
I'm not quite sure if this is related to apollo, but I've tracked the issue and it only occurse when I import something from Apollo.
for example
import { Apollo } from 'apollo-angular';

or
import { QueryRef } from 'apollo-angular';

Versions
From my package.json
     "apollo-angular": "^1.6.0",
    "apollo-angular-link-http": "^1.8.0",
    "apollo-cache-inmemory": "^1.6.2",
    "apollo-client": "^2.6.3",
    "apollo-link": "^1.2.12",
    "apollo-link-context": "^1.0.18",
    "graphql": "^14.4.2",
    "graphql-tag": "^2.10.1",

To get the latest versions from Angular
ng update @angular/cli @angular/core --next

To get Iy enabled add this to your tsconfig.sjon
"angularCompilerOptions": {
    "fullTemplateTypeCheck": true,
    "strictInjectionParameters": true,
    "enableIvy": true
  }

in the mean time, I managed to bypass this error by deleting the .js extension of the graphql npm module

I tried with 9.0.0-next.7 and 1.7.0 of apollo-angular + latest graphql and it seems to work fine. Could you guys create a reproduction?


[FIX] Midweek meeting schedule has extra day on it

Describe the bug:
In midweek meeting scheduling there is an extra day that is placed before actual starting week of the month.
February is for example - how it looks in the app and how it looks when I saved a pdf.
Steps to reproduce the issue:

Select midweek meeting
Select year - 2025
Select month - February

Expected behavior:
Expected is not to have this extra day in the list of weeks
Screenshots

Which platform can you reproduce the bug on?
All platforms
Your operating system:
Windows
App version:
3.4.1
Additional information
No response

@wikmanipoiss: Thanks for this report! Can you please verify if you still see the odd week after updating to the latest version (3.4.2)?

@rhahao I can verify that this odd week is no more there. Thank you :)


docker部署的，添加钉钉，测试发送报错 tls: failed to verify certificate: x509: certificate signed by unknown authority

？？

感谢反馈，已经修复
请拉取最新镜像
docker pull engigu/message-nest:latest

欧了，辛苦了


Getting "premature close" errors with npm install

Using node version 0.9.3 and npm version 6.4.1 I'm getting errors like this when running make pre-run or make pre-build or just npm install.
Unhandled rejection Error: premature closell extract<EMAIL_ADDRESS>    at PassThrough.onclose (/Users/bigmac/.nvm/versions/node/v11.3.0/lib/node_modules/npm/node_modules/end-of-stream/index.js:47:67)
    at PassThrough.emit (events.js:187:15)
    at emitCloseNT (internal/streams/destroy.js:59:8)
    at process.internalTickCallback (internal/process/next_tick.js:72:19)

The package name doesn't really matter.
I end up retrying again and again until I get that "lucky" run when all node packages are downloaded and extracted and I can proceed to next step.
Is there something wrong on my end?
I tried to connect via fastest network connection I have and there's no proxy in between.

So it looks like node version has to be 9.3.0.
npm version has to be 6.4.1 (I'm not sure what's the lowest version that can be used, but I know that default 5.x.x will not work).
Running npm install or npm ci commands directly did not work for me.
I had to use make pre-run instead 🤷♂

Running fresh npm ci command on 9.3.0/6.4.1 node/npm I occassionally get this:
npm WARN prepare removing existing node_modules/ before installation
npm ERR! path /Users/bigmac/dev/cba/mattermost-mobile/node_modules/mattermost-redux/package.json
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall open
npm ERR! enoent ENOENT: no such file or directory, open '/Users/bigmac/dev/cba/mattermost-mobile/node_modules/mattermost-redux/package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR!      /Users/bigmac/.npm/_logs/2018-11-30T01_50_41_935Z-debug.log

And mattermost-redux is exactly the package that's causing issues while running the app: https://github.com/mattermost/mattermost-mobile/issues/2407

Same premature close when using node 10.11.0 and npm 6.4.1
Also, make pre-run fails with same error too, so it looks like I got one-off successful run :/

So it looks like using yarn to install packages may be the workaround.
Still both with npm and with yarn I end up having this issue: https://github.com/mattermost/mattermost-mobile/issues/2407

Hi @mgrebenets, was this issue resolved earlier? If not, I encourage joining our Mobile apps channel on our community server and our devs or other community members will be able to help.


Create swift.yml

Add an initial GitHub workflow to enable a swift-format linting action.

I'll update this once we figure out what to do with the swift-format issues


Support deprecated

[ ] Add field to schema and validator
[ ] Populate
[ ] Remove from titles

These can instead be in the yaml. Preferably not a deprecated: true because that name would be set in the "negative" instead of "positive"

# simple enabled/disabled, if disabled, assume deprecated
enabled: false
# if this key is set, assume deprecated
deprecated_date: 2025-12-31

A separate file for deprecated entries is also an option


feat/ Create Login View Controller 🎃

Any update? 🤺
@oradwanomar @claramounir

We need to review and merge it before tomorrow's meeting

We need to review and merge it before tomorrow's meeting

Sorry, I was in the bed last 3 days and forgot to push it 🤧🤒

@motoon-eg/ios Can someone help here?


GFF generation for the integration with mgnify

Is this still valid and needed @mberacochea ? I think back then we discussed this feature to basically show annotated ORFs in a contig browser? For me, this still sounds like a good feature to provide a final GFF-styled output for all contigs and their ORF annotations.

I need to improve my github notifications filter on my email :facepalm: .
Yes, having the results as a gff is something we should provide.. I've had some requests for this already.
I'm closing this in favour of a new feature ticket.


Make DOWNLOAD_ASSEMBLIES store data more effeciently

Currently, the DOWNLOAD_ASSEMBLIES function downloads a zipped archive, unzips it, and renames some files in the unzipped archive that are used for the process' output. Both the zipped and unzipped versions are retained, so this uses more than twice the storage it could use. We only need to store some of the files in the archive and those can be compressed again once they have been removed from the unzipped archive. All the other files can be deleted by the process.
Things to do:

Instead of renaming files in place, move them to the root of the process work directory while renaming them
Compress all the required files that were moved from the zipped archive
Delete the original zipped archive and the unzipped version

done


Safe UpdateMeshBuffer Util Method

The UpdateMeshBuffer Method is important for updating GPU mesh data repeatedly in a performant manner.
This pull request intends to add a safe utility version of this method by accepting a span wrapper of the data rather than a pointer.
This method (including the interop version) requires an index to whichever buffer the user wishes to update—for example vertices, texture coordinates, colors etcetera. This is why I added VboIdIndex constants to the mesh class to help users access the right vertex buffer object (VBO) ID for the UpdateMeshBuffer Method.
For whatever reason raysan5/raylib does not include an enum or definitions for these VBO indexes. The closest thing I could find to these indexes being defined anywhere was in the raylib source code in UploadMesh.
I also added an example showing a good use case for the safe UpdateMeshBuffer Method and the VBO definitions.
Here is what you should expect from the example program:

Thanks, merged!


[BUG] Inconsistent result type using upsert()

Describe the bug
Based on the documentation, this code can be used to insert a document in database, or update it if it exist.
await Product.find_one(Product.name == "Tony's").upsert(
    Set({Product.price: 3.33}),
    on_insert=Product(name="Tony's", price=3.33, category=chocolate)
)

The "bug" if i may say is:

if the document is inserted, it will return a Product document
if the document is updated, it will return a UpdateResult

What is the correct approach to always have a document as a result ?
Should we check for UpdateResult, and act accordingly ?
Expected behavior
I expected to have a Product document.

Hi. Sorry for the delay.
I have to update the doc. The behavior you are talking about is possible now.
from beanie.odm.queries.update import UpdateResponse

await Product.find_one(Product.name == "Tony's").upsert(
    Set({Product.price: 3.33}),
    on_insert=Product(name="Tony's", price=3.33, category=chocolate),
    response_type=UpdateResponse.NEW_DOCUMENT
)

I'll update the doc and probably will make this behavior default in a few version with respective warnings.


feat(ui): add Arabic localization support

Description
Replace this paragraph with a description of what this PR is doing. If you're modifying existing behavior, describe the existing behavior, how this PR is changing it, and what motivated the change.
Related Issues
Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR. Note that you'll have to prefix the issue numbers with flutter/flutter#.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[ ] All existing and new tests are passing.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] The analyzer (melos run analyze) does not report any problems on my PR.
[ ] I read and followed the Flutter Style Guide.
[ ] I signed the CLA.
[ ] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change.
[x] No, this is not a breaking change.

@maxzod I'm not sure how to translate map tbh, I know it literally  means خريطة, so I don't know if this is the common translation in CS Arabic books.
Personally I would prefer it to stay English.

@pr-Mais
we could use  "كائن"  since map in JS is just a Object


Update d2sqlite3 and make it easier to access the DB

One issue I've seen in the live system is that it's hard to debug anything because the DB is unreadable.
Having binary data in the sqlite kind of defeat a great benefit of having sqlite in the first place, hence this change.
Open for debate.

It makes sense to me

There seems to be some flaky test triggering on mac + ldc. But it's not related to your PR.


Tree view is empty

Describe the bug
The dendron tree view displays no items, although there are plenty of notes.
To Reproduce

Open Dendron workspace.

Restarting VS Code and dis- and reenabling the Dendron extension didn't help.
Expected behavior
The tree view displayes the note hierarchy.
Screenshots

Desktop (please complete the following information):

OS: Windows 10
VS Code 1.50
Version: 0.12.6

Dendron Log file
{"level":30,"time":1602402995665,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"_activate","stage":"dev","isDebug":false,"logPath":"b:\\AppData\\Roaming\\Code\\logs\\20201011T095444\\exthost1\\dendron.dendron","extensionPath":"c:\\Users\\User\\.vscode\\extensions\\dendron.dendron-0.12.6","extensionUri":{"$mid":1,"fsPath":"c:\\Users\\User\\.vscode\\extensions\\dendron.dendron-0.12.6","_sep":1,"path":"/c:/Users/User/.vscode/extensions/dendron.dendron-0.12.6","scheme":"file"},"storagePath":"b:\\AppData\\Roaming\\Code\\User\\workspaceStorage\\0d7fa9d2843e7172eb2840b215215ea2\\dendron.dendron"}
{"level":30,"time":1602402995666,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"DendronWorkspace","msg":"initialized"}
{"level":30,"time":1602402995667,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"_activate","installedGlobalVersion":"0.12.6","migratedGlobalVersion":"0.12.4","previousGlobalVersion":"0.12.3","previousWsVersion":"0.12.4","platform":"win32","extensions":[{"id":"dendron.dendron-paste-image","version":"1.0.4","active":false},{"id":"equinusocio.vsc-material-theme","version":"33.0.0","active":false},{"id":"dendron.dendron-markdown-shortcuts","version":"0.12.1","active":false},{"id":"dendron.dendron-markdown-preview-enhanced","version":"0.10.1","active":false},{"id":"dendron.dendron-markdown-links","version":"0.6.8","active":false},{"id":"dendron.dendron-markdown-notes","version":"0.0.17","active":false},{"id":"github.github-vscode-theme","version":"1.1.5","active":false}],"workspace":"a:\\Dokumente\\Notes\\vault"}
{"level":30,"time":1602402995667,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"_activate","msg":"wsActive","lspSupport":false}
{"level":30,"time":1602402995667,"pid":984,"hostname":"User-PC","name":"dendron","msg":"initialized"}
{"level":30,"time":1602402995668,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"getOrCreateEngine","msg":"create new engine"}
{"level":30,"time":1602402995669,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"activateWorkspace","stage":"dev","msg":"enter"}
{"level":30,"time":1602402995669,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"createWorkspaceWatcher"}
{"level":30,"time":1602402995670,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"createServerWatcher","portFile":"a:\\Dokumente\\Notes\\.dendron.port"}
{"level":30,"time":1602402995671,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"createSchemaWatcher","msg":"enter"}
{"level":30,"time":1602402995684,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"ReloadIndex.execute","msg":"enter"}
{"level":30,"time":1602402997804,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"ReloadIndex.execute","msg":"exit"}
{"level":30,"time":1602402997921,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"reloadWorkspace","msg":"post-reload-ws"}
{"level":30,"time":1602402997921,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"reloadWorkspace","msg":"exit"}
{"level":30,"time":1602402997922,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"postReloadWorkspace","msg":"preUpgrade: new wsVersion"}
{"level":30,"time":1602402997922,"pid":984,"hostname":"User-PC","name":"UpgradeSettingsCommand","ctx":"Upgrade:execute","opts":{"settingOpts":{"force":true}}}
{"level":30,"time":1602402998429,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"reloadWorkspace","msg":"gotConfig","config":{"folders":[{"path":"vault"}],"settings":{"editor.fontFamily":"'Cascadia Code SemiLight', 'Fira Code', Consolas, 'Courier New', monospace","editor.fontSize":16,"dendron.rootDir":".","editor.minimap.enabled":false,"files.autoSave":"onFocusChange","workbench.colorTheme":"Quiet Light","pasteImage.path":"${currentFileDir}/assets/images","pasteImage.prefix":"/","markdown-preview-enhanced.enableWikiLinkSyntax":true,"markdown-preview-enhanced.wikiLinkFileExtension":".md","vscodeMarkdownNotes.noteCompletionConvention":"noExtension","vscodeMarkdownNotes.slugifyCharacter":"NONE","editor.snippetSuggestions":"inline","editor.suggest.snippetsPreventQuickSuggestions":false,"editor.suggest.showSnippets":true,"editor.tabCompletion":"on","[markdown]":{"editor.quickSuggestions":true,"editor.wordBasedSuggestions":false,"editor.tabSize":2,"editor.suggest.showSnippets":true}},"extensions":{"recommendations":["dendron.dendron-paste-image","equinusocio.vsc-material-theme","dendron.dendron-markdown-shortcuts","dendron.dendron-markdown-preview-enhanced","dendron.dendron-markdown-links","dendron.dendron-markdown-notes","github.github-vscode-theme"],"unwantedRecommendations":["shd101wyy.markdown-preview-enhanced","kortina.vscode-markdown-notes","mushan.vscode-paste-image"]}}}
{"level":30,"time":1602407537348,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"show"}
{"level":30,"time":1602407537350,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"updatePickerBehavior","resp":[{"iconPathNormal":{"id":"find-selection"},"iconPathPressed":{"id":"menu-selection"},"type":"selectionExtract","pressed":true,"title":"Selection Extract"}]}
{"level":30,"time":1602407537350,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"updatePickerItems","querystring":"","opts":{"flavor":"schema"},"msg":"no qs"}
{"level":30,"time":1602407537351,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"updatePickerItems","querystring":"","opts":{"flavor":"schema"},"msg":"exit","profile":0}
{"level":30,"time":1602407537351,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"updatePickerItems","querystring":"","opts":{"flavor":"schema"},"msg":"no qs"}
{"level":30,"time":1602407537351,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"updatePickerItems","querystring":"","opts":{"flavor":"schema"},"msg":"exit","profile":0}
{"level":30,"time":1602407540085,"pid":984,"hostname":"User-PC","name":"dendron","ctx":"execute","opts":{}}

Running into the same issue on macOS. I’ll do some testing with removing some thing of the files from the vault later today.

this should now be fixed with 0.12.7. thanks for reporting!


vscode dies when input search pattern in debug console

Type: Bug
During debug of a flutter project, there are already many logs in debug console and new logs are keep coming, try to input a pattern to search, it stop responding and after a while, a warn dialog appear to ask if I want keep waitting or reopen, most time keep waitting is useless. this happened many times.
Another issue is, filter out all logs that not cotain search pattern is not good, highlight the search pattern is what user need, at least there should be an option for this.

For the "find" request, see #4338.

it's not a pattern issue, it might die after input 1 to 3 letters

I think it's an arithmetic issue, there can be times of 10000 logs, though most of which are same and are displayed in 1 line with a highlighted times at the begining of the line.
Filter out all logs that not cotain search pattern is not good, since user would probably need to see context.
By the way, I checked https://github.com/microsoft/vscode/issues/4338., seems not helpful for this.

@gjsjohnmurray

@zzzh I am not a member of the core team. Pinging @roblourens

@gjsjohnmurray
Ok, thank you.

@roblourens

I tried some different cases with a script that logs a lot, and filtering it in different ways. VS Code stayed fast and responsive. Could you share something more specific like what the output looks like? A simple script that 'prints' to repro the issue would help a lot

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Test will try to use docker, even when told not to....

I created a local database that can be approached with ident authentication.
Then in .env specified:
DB_CONNECTION=postgresql+psycopg2:///real_world_application
In an ipython shell I verified that I can use this string to the database.
Still $ USE_LOCAL_DB_FOR_TEST=True pytest results in:

During handling of the above exception, another exception occurred:
../../../.cache/pypoetry/virtualenvs/fastapi-realworld-example-app-qr8Xy3u9-py3.8/lib/python3.8/site-packages/docker/api/client.py:214: in _retrieve_server_version
    return self.version(api_version=False)["ApiVersion"]
../../../.cache/pypoetry/virtualenvs/fastapi-realworld-example-app-qr8Xy3u9-py3.8/lib/python3.8/site-packages/docker/api/daemon.py:181: in version
    return self._result(self._get(url), json=True)
../../../.cache/pypoetry/virtualenvs/fastapi-realworld-example-app-qr8Xy3u9-py3.8/lib/python3.8/site-packages/docker/utils/decorators.py:46: in inner
    return f(self, *args, **kwargs)
../../../.cache/pypoetry/virtualenvs/fastapi-realworld-example-app-qr8Xy3u9-py3.8/lib/python3.8/site-packages/docker/api/client.py:237: in _get
    return self.get(url, **self._set_request_timeout(kwargs))
../../../.cache/pypoetry/virtualenvs/fastapi-realworld-example-app-qr8Xy3u9-py3.8/lib/python3.8/site-packages/requests/sessions.py:555: in get
    return self.request('GET', url, **kwargs)
../../../.cache/pypoetry/virtualenvs/fastapi-realworld-example-app-qr8Xy3u9-py3.8/lib/python3.8/site-packages/requests/sessions.py:542: in request
    resp = self.send(prep, **send_kwargs)
../../../.cache/pypoetry/virtualenvs/fastapi-realworld-example-app-qr8Xy3u9-py3.8/lib/python3.8/site-packages/requests/sessions.py:655: in send
    r = adapter.send(request, **kwargs)
../../../.cache/pypoetry/virtualenvs/fastapi-realworld-example-app-qr8Xy3u9-py3.8/lib/python3.8/site-packages/requests/adapters.py:498: in send
    raise ConnectionError(err, request=request)
E   requests.exceptions.ConnectionError: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))

(Lots of the above...)

@nsidnev Thanks a lot. I already got everything running with this in my .env:
DB_CONNECTION=postgresql:///real_world_application.
But tests where still failing. Later today I will run the new code to see how that turns out.

@nsidnev I can confirm that tests are running well now!

Awesome! Then I'll close this issue. Thanks for the confirmation!


Number input min-max limits not working as expected

Current Behavior
I can put values in number input out of bounds of min max setting.

Expected Behavior
I expect it to limit input value if input is out of bounds. At least not output  out of bounds value.
Steps To Reproduce
No response
Environment

Dashboard version: 1.15.0
Node-RED version: 4.0.2
Node.js version: 20
npm version:
Platform/OS: RT linux arm32
Browser: Chrome

Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate

Download
https://www.mediafire.com/file/jc5ws0hujgycrp5/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Warning!!!. Do not download kehkou link. Virus

Warning!!! Do not download kehkou link. Virus. Github need to fix this
Edit: Github removed it, be careful for later with comments asking you to download malware

The reason I found this place is because I also just received a link from kehkou, and you were the only one who mentioned this problem.
He cleverly provided an executable file related to gcc (which is also the hardest hit by false positives) Only after I ran it and nothing happened did I realize something was wrong, luckily the antivirus saved me in the end...

Also the step control is not working, it always increments in 1 steps

@mountain181, thank you for reporting this bug with the number input node.
Could you please provide the version of Safari and the OS platform you're using?

Please note that if you're using Safari for Windows, it may cause issues as it was discontinued in 2010
We're continuing to investigate these issues further

@gayanSandamal
It works for me now as well. I think i had a issue with browser cache. No problems with safari.

@gayanSandamal It works for me now as well. I think i had a issue with browser cache. No problems with safari.

Thanks for the confirmation @mountain181


📝 Consistently use ln.Annotate for any anndata- and df-like artifact

We have several examples that rely on the lower-level API that's now private:
https://github.com/laminlabs/lamin-usecases/pull/129

@sunnyosun - does this make sense to bump up the prio list?

https://github.com/laminlabs/lamin-usecases/commit/862b690d7a7a3113ea1d8db9f6ae336091811eac

Thank you! 🙏


Update readme

Ah great I'll review shortly. Can you git commit --amend --signoff --no-edit to meet the DCO check.

done


chore: update uni-registrar version to 0.5-SNAPSHOT

Signed-off-by: Firas Qutishat<EMAIL_ADDRESS>

@fqutishat Let's wait for @cihanss to merge this, then we should be able to trigger a redeployment of the latest version at https://uniregistrar.io/

@peacekeeper thank you.

@peacekeeper can you trigger a redeployment of the latest version at https://uniregistrar.io/


In README of "monitoring-models-with-openscale-gui", missing pictures

In README of "monitoring-models-with-openscale-gui", missing pictures,
In the Payload logging section, select the type of input. In our case, choose Categorical:
Choose model input type
In the Model details sections, select Manually configure monitors:
Choose model details
==> missing picture
In the Quality alert section, set the alert threshold to 70% and the sample size to 100:
==> missing picture
Set alert threshold and sample size
==> missing picture

Re-Open Notebook
From your project page, go to Notebooks:
==> missing picture

Thanks for the issue. Sorry, this module is a Work in Progress, and should not have been exposed. Parts of this are not fully tested, since it was ported from a workshop @jrtorres created using OpenScale on the IBM Cloud. Also, there are missing screen shots because of this.
We'll be taking on the work of updating this the week of April 20-24, and I hope to have these updates in by 4/24/20. Thanks again.

Closing this for now as we are developing this manual monitor configuration module in upstream.


Frontend: add information about how to contribute to footers

Details
We should include a small notice saying something like "Want to contribute? Check this out." in our footer, linking to SleepAPI Github page.
EDIT: This is about the footers in the simplistic frontend. You can find this under backend/src/assets as a bunch of simple html files. Unfortunately the footers are duplicated currently across the html files and would all need to be updated unless you go for a refactor.
The footers currently mention our contact info on Discord like:
Sleep API authors on Discord for questions
We should expand this with information on how to contribute to the project.

Hi, can I work on this issue?

Hi, can I work on this issue?

Absolutely, I've assigned it to you and marked it as In Progress in the board.
Let me know if you have any questions 👍

Okay, Thanks for the update, what I am adding to the footer is just the link to the project GitHub page

Okay, Thanks for the update, what I am adding to the footer is just the link to the project's GitHub page. You can correct me if I am wrong

Thanks for your follow-up question, that is correct. Just a simple text with a href to SleepAPI's Github landing page.
We want to keep the current link to contact the Sleep API authors on Discord, but we also want to add information on how to contribute. Please consider making sure these two texts don't stick together completely, they should be somewhat separated by space, or a divider or whatever you suggest.
Just so the text doesn't completely stick together like:
Sleep API authors on Discord for questions Want to contribute? Check this out
If you want to keep it simple you can probably just add a pipe or something like:
Sleep API authors on Discord for questions   |   Want to contribute? Check out Sleep API on Github

Ok thanks a lot

You can checkout the pull request

You can checkout the pull request

Thank you! Left a few comments 😃

I have fixed the issues, can you take a look at it?

I have fixed the issues, can you take a look at it?

Two small comments, please have a look 😃


Using TranscriptLoggerMiddleware breaks Bot on Azure Infrastructure

The TranscriptLoggerMiddleware works on the Emulator, but fails when run
on Azure Infrastructure. This is caused by the invalid modification of
the incoming Activity. While outgoing activities are cloned before they
are modified, the incoming activity is modified in place.
The modifications then create invalid data leading to this JSON fragment
for reply activities:
{
    // ...
    "recipient":{
        "properties":{
            "role":{}
        },
        "id":"8d51e790-8bd3-4450-af3d-1741838d1354",
        "role":{}
    },
    // ...
}

The role key in the properties subobject should not be there and while
the second role entry should indeed be set, it should be set to a
string, not an object. This results in a http 400 status from the bot
framework:
{
  "error": {
    "code": "BadSyntax",
    "message": "Invalid or missing Activity in request"
  }
}

While adding the role information to the from property of the activity
is convenient, it should not modify the incoming activity.
To fix this, the incoming activity is cloned before it is modified, as
the outgoing activity also lacks the role information, the update of the
role attribute is applied to both types. In addition the correct
atttribute is updated for the role information.

@matthiasblaesing Thanks Matthias.  I'll need to research this a bit before I can merge.  Since it was ported from one of our other Bot SDK's, we need to verify if it was an error in the port, or something deeper.  Clearly something is broken.  An object instead of a string appears to be a port error.

@tracyboehrer you mean this should be the reference?
https://github.com/microsoft/botbuilder-dotnet/blob/master/libraries/Microsoft.Bot.Builder/TranscriptLoggerMiddleware.cs
Yeah the C# implementation looks saner than the java version - the transliteration should be straight forward. If you prefer to keep the two implementation feature/bug equals, I can live with it.


Add the ability to set imagePullSecrets

... for pulling from a private Docker repository.
Addresses issue:
#280
Tests run:

values.yaml input

imagePullSecrets: {}
# - name: regcred

output:
spec:
  serviceAccountName: RELEASE-NAME-vernemq

values.yaml input

# imagePullsSecrets:

output:
spec:
  serviceAccountName: RELEASE-NAME-vernemq

values.yaml input

imagePullSecrets:
- name: regcred

output:
spec:
  imagePullSecrets:
    - name: regcred
  serviceAccountName: RELEASE-NAME-vernemq

@ioolkos - I filled out the contact form on octavolabs.com and referenced this PR/issue

@alan-copeland-keysight thanks, seems I can't find the ticket. "contact at octavolabs com" e-mail address.

Hi there! @ioolkos  So this is not merged at all, if I understand this correctly?
It would be needed for images that are not coming from docker hub.

@phlegx yeah, I know, I hope it's not perceived as lock-in. But the packages (and subscriptions) are what keeps this project maintained.
(you can always clone this repo, and and adapt and add functions, of course)

Yes this is understand this of course.


[MINOR][DOCS] Remove the duplicated word/ typo in Streaming Docs

What changes were proposed in this pull request?
In the section Handling Late Data and Watermarking in Structured Streaming Programming Guide, the word received occurs twice in row. Fixed this typo.
How was this patch tested?
N/A

Can one of the admins verify this patch?

@tdas could you accept this small PR?

Better idea: grep for all instances of repeated words and fix more than just this in one go. I actually see quite a few. This is a quick and dirty grep that shows most of them grep -rE "[^m] ([a-zA-Z]+) \1 " * | grep -E "\.(md|scala|java):"

@srowen -- indeed, better; thanks for the suggestion. I also ran this command: grep -rE "[^m] \b(\w+)\s+\1\b" * | grep -E "\.(md|scala|java|py):" and removed some duplicates not caught by your regex search.

whoa. LGTM.

Test build #3519 has started for PR 16455 at commit add7a50.

Merged to master


Fix regex for Rfc3339 validation

This is fixing a date-time validation problem where an invalid datetime string is still considered valid if it starts or ends with invalid chars (see the tests for a more clear example).

+1


Add docstrings to healpy interface functions

This PR adds minimal docstrings to the functions in healpix.healpy, linking to the equivalent function in healpy. I think this is very useful, for quick checking if the functions really are equivalent in signature or not. Plus they have good docstrings, so no need to duplicate those in our docs.
I also added a Migrate section to the healpy docs page, that mentions that one can do the one-line import change to from healpix import healpy to hp.
@astrofrog - Please review.

Should be OK to merge now.

Coverage remained the same at 98.305% when pulling 121a7accf80e702e6ae36bfec325b6e45f557a9f on healpy-docstrings into a3cfdef81ee9d82c650ca9982cfd60897f2c12b7 on master.

Coverage remained the same at 98.305% when pulling 4fec1067d2e5a933766ab84c72412fc9fe68d727 on healpy-docstrings into a3cfdef81ee9d82c650ca9982cfd60897f2c12b7 on master.


How to zoom page ??

i want to know how to enable zoom page rather to double click or tap ??

basically, you should implement this yourself, cause PdfRender translates the pdf page into bitmap, so, if you wanna use pinch zoom, simplest way is to implement gesture for image view.

use this library
https://github.com/chrisbanes/PhotoView

I am closing this issue/PR, as it has been migrated to the new repo linked above in the comments. Thank you!


pythonPackages.cvxpy: init at 1.0.25

Motivation for this change
Add dependency for upcoming qiskit package #78772 @jonringer
Depends on #78897
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

please fix eval

@GrahamcOfBorg eval

please rebase

Rebased, but still waiting on #78897

merged, sorry about that

@GrahamcOfBorg eval

@GrahamcOfBorg build python37Packages.cvxpy python38Packages.cvxpy

bot builds fail b/c scs package uses mkl (non-free).


Update how_to_integrate_payment.rst

Added example how to integrate 'cash-on-delivery'

see #4060


forge script and forge snapshot aliases are the same

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (dd7c88f 2022-07-08T00:23:23.289481Z)
What command(s) is the bug in?
forge
Operating System
macOS (Intel)
Describe the bug
If you type forge to get the help menu, you'll see
[...]
script              Run a smart contract as a script, building transactions that can be sent onchain. [aliases: s]
snapshot            Create a snapshot of each test's gas usage. [aliases: s]
[...]

Running forge s it will try to run forge script as far as I see.

since script came after snapshot, should we remove the script's alias @onbjerg ?
put perhaps script is used more widely?

Hi 👋
I created a patch PR for this:  https://github.com/foundry-rs/foundry/pull/2269

since script came after snapshot, should we remove the script's alias
put perhaps script is used more widely?

Agree with this. I made a PR to follow the above suggestion for now, but if there is any other better solution I would fix the PR.


Fix small race in DefaultChannelPipeline introduced by a729e0fcd94009…

…905d219665bdd069eb31433b7c
Motivation:
There is a small race while adding handlers to the pipeline because callHandlerAddedForAllHandlers() may not be run when the user calls add* but the Channel is already registered.
Modifications:
Ensure we always delay handlerAdded(..) / handlerRemoved(...) until callHandlerAddedForAllHandlers() was called.
Result:
No more race on pipeline modifications possible.

Cherry-picked into 4.1 (339b512e70caa562dc36aae769ac720c22d91699) and 4.0 (fd1fa42a7ddb10e232acc1d0366ec2406f7b7657)


Support placement when starting new instances

Thanks for this module, finding it very useful!
Boto/AWS lets you specify the availability zone when starting new instances

Great, thanks!


Fix github actions for forked PRs

Hopefully this fixes the forked PR failing checks

@ghost91- I think this fixes the forked PRs failing checks.


Allow adding custom entries to pages

Sometimes I want to add custom entries to pages that already contain 8 entries. The tldr guidelines only allow up to 8 entries per page.
Maybe we could set up a way to register "patchfiles" with tealdeer (e.g. by placing them somewhere in the .config/tealdeer/ directory). Those patchfiles would be appended to the corresponding pages when updating the cache.

Adding custom pages would also be nice

Implementing this in #142


Show lens for unreachable code

If it takes time lets do only Java for now and open additional tasks for the others
The lens name is 'Never Reached'

This should only be displayed on functions we know we can get data from (e.g there is a span/endpoint definition).
For example, in this case we don't really know if it wasn't reached or not since we don't have instrumentation:

@borisermakof , @MykolaYaremchuk  in my opinion we better wait for issue #280 to be resolved - that way we could use the new model - insights PER method


isURL allow_protocol_relative_urls intended behavior?

What is the intended effect of allow_protocol_relative_urls? It seems to me that there might be a bug, but I'm also not clear on the flag's intended effects. For example:
> isURL('//google.com/login', {require_host: false}) // default allow_protocol_relative_urls: false
true

The source just seems to offset the rest of the parsing by the protocol, and there doesn't seem to be any way that explicitly fails when protocol-relative URLs are used.
https://github.com/chriso/validator.js/blob/master/lib/isURL.js#L86

Thanks, that is indeed a bug.


Loading the saved learner as .from_pretrained

Hi,
I have a ktrain learner that is made of a tokenizer and transformer from HuggingFace.
The use case I would want to have is:

Train a classification with this learner.
Save the learner in disk.
Load the updated model  using transformers library classes using:

AutoModel.from_pretrained(model_name_or_path, config=config, cache_dir=cache_dir)
AutoTokenizer.from_pretrained(model_name_or_path, cache_dir=cache_dir)

By this way, you can update the transformer downloaded from huggingface using ktrain, and yet can save it and keep using it from other libraries in the ecosystem (like sentence-transformers, for example).
Is there any way of saving the models trained with ktrain so the pretrained  format files are in the same format than hugginface transformers and tokenizers standard?
Kind regards.

Yes, you can do this easily, as ktrain is just a lightweight wrapper.  So, once you train the model, you can manage it directly using transformers, tensorflow, or use it with other libraries like sentence-transformers. There are several ways to do this.
After you train the model using the Learner object, you can save it with:
learner.save_model('/tmp/some_path')

If the model you're saving is a Hugging Face transformers model, then the above command will simply save the model using save_pretrained, so it will be in the format expected by transformers.  This will create the folder 'tmp/some_path' if it doesn't already exist.
Alternatively, you can access the underlying transormers model directly and invoke save_pretrained explicitly with learner.save_pretrained('/tmp/some_path').   See here for an example of this.  The underlying TensorFlow model is always directly accessible with learner.model.
Note that the above will save a transformers model in TF2 format.  If you need, you can convert it to a PyTorch model using the transformers library.

Two additional comments:
ktrain does not save  tokenizers for transformers models, as they are not modified as part of training.  So, if you need them, you can load them directly using the transformers library in which case the tokenizer will be loaded from cache (and downloaded if necessary).
Also, when saving a Predictor instance for a transformers model, the model is also saved in the correct/expected format and can be re-loaded and used with other libraries:
p = ktrain.get_predictor(learner.model, t)
p.save('/tmp/mypred')  # folder will contain the transformers model as tf_model.h5 (same as save_pretrained)

Great! Thank you very much @amaiya


[bug]Switching mobile network will disconnect

Switching from wifi to mobile phone 4g or switching from 4g to wifi calls are directly interrupted and cannot be reconnected，
In the new version of sdk, the reconnection method is gone.
在通话的时候切换手机网络，从wifi到4g或从4g到wifi都会中断且直接丢失房间的连接，在1.2.0的sdk里重连方法不见了。
flutter 3.7.3
livekit_client 1.2.0
redmi note5 4g
android 8.1.0

We may need to monitor current network type, and automatically trigger the re-connection when it changes

We may need to monitor the current network type, and automatically trigger the re-connection when it changes

The reconnection method is gone in the new sdk

Harmonys os 4g  screen freezes
print log :org.webrtc.Logging(19744): HardwareVideoEncoder: Dropped frame, encoder queue full

Some mobile phones will automatically reconnect when switching networks in debug mode, but they are directly disconnected in release mode
在debug模式下切换网络会自动重连，但是在release模式下直接断开了

The reconnection method is gone in the new sdk

What is the reconnection method?

The reconnection method is gone in the new sdk

What is the reconnection method?

 void _onTapReconnect() async {
    try {
      await room?.reconnect();
    } catch (error) {}
  }

okay, I made it an internal method in the last PR, but I think we need to reconnect by monitoring network changes instead of manually reconnecting?
https://github.com/livekit/client-sdk-flutter/pull/238/files

@hrxiang When calling you to switch networks, can you observe that the signaling ws connection is disconnected? or nothing will happen

@hrxiang When you switch networks, can you observe that the signaling ws connection is disconnected? or nothing will happen

There will be reconnection in debug mode, and the release mode will be disconnected directly.
I used the 1.1.4 version to build the release package and it can be reconnected, but I used the 1.2.0 version to build the release package and disconnected directly.
I used the 1.2.0 version to build the debug package can be reconnected

okay, let me test it

Just tested, 1.2.0 uses the release mode, it can be reconnected after switching from WIFI to 5G, but the publisher successfully reconnects first, while the subscriber will lag behind for 3 to 5 seconds but will eventually reconnect, and the two-way video will return to normal.

Just tested, 1.2.0 uses the release mode, it can be reconnected after switching from WIFI to 5G, but the publisher successfully reconnects first, while the subscriber will lag behind for 3 to 5 seconds but will eventually reconnect, and the two-way video will return to normal.

4g phone.

same result on 4g network

But I observed an interesting phenomenon, the disconnection/new connection of ws signaling seen on the livekit-server has the same delay of 3-5 seconds, so this should be related to the delay of iOS sending WS socket disconnection event.

But I observed an interesting phenomenon, the disconnection/new connection of ws signaling seen on the livekit-server has the same delay of 3-5 seconds, so this should be related to the delay of iOS sending WS socket disconnection event.

Nova5 pro (Harmonys os 4g) mobile phone has this problem, but gt neo5 5g does not have this problem.
nova5 pro only supports 4G but not 5G

The current version depends on the disconnection of the WSS signaling to trigger the RESTARTCONNECT/ResumConnect, This method relies on the system to report the timeout of the Socket disconnect.
maybe we can adopt a more positive way as the preferred network changes, and actively re-connect,

Nova5 pro (Harmonys os 4g) mobile phone on the 1.2.0 version, the screen will freeze, but it is normal on <=1.1.4

Since I do not have a device that can reproduce the Issue,
Can you help REVERT the code in 1.2.0 SDK to test it?
https://github.com/livekit/client-sdk-flutter/commit/5c4761bc7ca2ec28269a49eca2dbe8f129dc4ab0#diff-3a92e05d440158fbb2bd9af33b72cc5aba22adf50ca82f4e824477109fc58f95L309-L313

So sorry! Our server code here has not been upgraded, we are still using a version from long ago. After updating the servers, we occasionally lose connection when switching networks, most of the time this is normal.
Now there is a problem that the Huawei 4G mobile phone will be stuck after a while, but the sound can be heard
Repeated console output：
org.webrtc.Logging(19744): HardwareVideoEncoder: Dropped frame, encoder queue full
org.webrtc.Logging(19744): HardwareVideoEncoder: Dropped frame, encoder queue full
org.webrtc.Logging(19744): HardwareVideoEncoder: Dropped frame, encoder queue full
org.webrtc.Logging(19744): HardwareVideoEncoder: Dropped frame, encoder queue full
org.webrtc.Logging(19744): HardwareVideoEncoder: Dropped frame, encoder queue full
org.webrtc.Logging(19744): HardwareVideoEncoder: Dropped frame, encoder queue full
org.webrtc.Logging(19744): HardwareVideoEncoder: Dropped frame, encoder queue full
org.webrtc.Logging(19744): HardwareVideoEncoder: Dropped frame, encoder queue full

Is it the same issue as this one? https://github.com/open-webrtc-toolkit/owt-deps-webrtc/issues/117

This may be a bug on a specific device, if this issue recurs frequently, please reopen this issue


Fix for the crash due to missing environment Keyboard Observer object

Keyboard Observer environment object is provided for the ChatDetailView - the only view which need it. Another solution is to provide it to the root view in the SceneDelegate.

Good catch! Thanks for the help.
I would rather inject the KeyboardObserver in the SceneDelegate, since it might be useful for further screens as well (which are not built yet, obviously, but might be added in the future). Do you mind adapting the MR accordingly?

Sure, it does make a good sense - done.

Great, thanks!


Feature/addaptivecpp 24.06.0

Adds AdaptiveCpp 24.06.0.

Happy to approve this, but longer-term I wonder if it would be possible to hack the build or run environment of dependents of AdaptiveCpp to prevent the problems you've encountered. I'll try to find some time to play around with it.


added django course

added django persian taught course to free-courses-fa_IR

i fixed things that you mentioned. e.g adding more course to django section and blank lines number between sections.


No visible @interface for 'RCTTextField' declares the selector 'setInputAccessoryView:'

I updated to RN 0.46 and got this error
No visible @interface for 'RCTTextField' declares the selector 'setInputAccessoryView:'

Looks like https://github.com/bky/react-native-keyboard-tracking-view/commit/3f07ab8cca87f6f16b210040bfeba1795378dabc fixes it

Any chance of this fix getting merged?

I really want to use this plugin. It's the only one that I've found to make something like this really work. Please fix this bug.

I tried that commit and the code did not work either...

Now it says "No visible @interface for 'RCTTextField' declares the selector 'textField'"

same issue here: No visible @interface for 'RCTTextField' declares the selector 'textField'

I used the latest commit by bky and was able to get it working - https://github.com/bky/react-native-keyboard-tracking-view/commits/master


Make dockerhost overridable.

This has gotten me more than once. If you are NOT developing on a local machine and plan to browse to your VM over the web, then the URL determined by the manage script here is not useful to you.

👍🏻


SystemStackError in Grape/Hashie when POSTing GeoJSON file

I've been experiencing SystemStackErrors in Hashie's mash.rb, when POSTing somewhat large GeoJSON files to a Grape endpoint. I'm using Grape 0.7.0.
To replicate the bug, do the following:

Clone/copy files from gist,
open two terminals, run rackup in one,
and ./bug.sh in the other.

The Grape/Rack terminal will output:
[2014-06-17 11:18:37] ERROR SystemStackError: stack level too deep
    /Users/bert/.rvm/gems/ruby-2.1.1/gems/hashie-3.0.0/lib/hashie/mash.rb:242

I tried your example on the master branch.
rack raises a range error before Hashie converts the params.

RangeError: RangeError
/home/dmitry/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/utils.rb:135:in `normalize_params'

The main problem that you didn't specify content type for your large GeoJSON.
curl uses  application/x-www-form-urlencoded type by default for the --data params so this GeoJSON is parsed as usual query params(whole content is one BIG KEY with a complex structure but without a value).
After adding "Content-type: application/json" header all works well.
Anyway thanks for the reporting this issue, seems like the parsing of HTTP "key-value" pairs is interesting thing(I can't find any RFC at the moment).
I'll close, it's not related directly to grape.


Nuth & Kaab coregistration spreads NaNs

The Nuth & Kaab coregistration (and I assume other types of coregistration as well) spread NaNs because of the resampling.
An easy way to see it is to run the Nuth & Kaab example and to add some random gaps in the DEM. See attached script (rrnamed to txt so that GitHub does not complain) and figure below.

plot_nuth_kaab.txt

A simple solution is to replace the whole _apply_matrix method by something like this:
dem_to_be_aligned_copy = dem_to_be_aligned.copy()
dem_to_be_aligned_copy.shift(-nuth_kaab._meta['offset_east_px']*nuth_kaab._meta['resolution'], -nuth_kaab._meta['offset_north_px']*nuth_kaab._meta['resolution'])
aligned_dem = dem_to_be_aligned_copy.reproject(reference_dem)

Actually, cubic interpolation spreads the NaNs even more, so bilinear is preferable, see below.
With bilinear interpolation

With cubic interpolation

This is most likely due to the dilate_mask argument, which we deemed was a preferable behavior over potentially introducing weird artefacts. I'm not saying this isn't an issue, just that the effect is an intentional "better of two evils"!
https://github.com/GlacioHack/xdem/pull/87#discussion_r618416956

The NaN spread is even worth with two coregistrations in a row, like coreg = xdem.coreg.ICP() + xdem.coreg.NuthKaab() (see attached script and figure).
Turning off the 'dilate_mask' option reduces the gaps, but it is not perfect yet, because currently the apply method is run twice with two items in the CoregPipeline.

test_coreg.txt


favicon

I tried using the podcast icon for this but it's too many words. Will need to do this in figma with just "FC"

Got this working on all pages that end in .html but still need to figure out how to get it working on .md pages


Don't make a PR to packages that use an equality specifier

I have a request based on a PR I just closed this morning:

This pull request changes the compat entry for the FFTW package from =1.2.2 to =1.2.2, 1.2.

We have an equality specifier on FFTW because there are bugs in later versions that prevent us from using them; we must use precisely FFTW = "=1.2.2". It doesn't make sense to me why CompatHelper should change the compat entry in this case, since I have explicitly declared that I want one exact version of the package. My request is that CompatHelper does not make a PR changing the compat entry for this package because I used an equality specifier. Does this make sense to anyone else? Am I missing a use case that this was designed for?

Happy to support this feature. We wouldn't make it the default behavior, but we could have a keyword argument that you could set.
(To elaborate, the default behavior of CompatHelper is designed to meet the following goal: make sure that package X is compatible with the latest version of all of its dependencies.)
But yes, we'd be happy to accept a PR to add this feature as an opt-in.


[Send Notification] Passenger received incorrect Notification about Ride cancellation

Environment: Xiaomi Mi 9 Lite, Android 10, MIUI 12 <IP_ADDRESS>
Reproducible: always
Build found: v1.0.238.apk
Preconditions
Car app is opened
Ride is created
Passenger is added into the Ride
Steps to reproduce

Log in as a Driver
Go to created Ride
Tap on ellipsis menu-> 'More Optionts' pop-up is opened
Tap on 'Edit ride details'->Departure time->Change date->Apply changes->Apply->Ok
Repeat step 3
Tap on 'Edit ride details'->'Cancel ride'->Yes, cancel it->Ok
Log in as a Passenger
Go to 'Notification' tab
Observe the result

Actual result

Notification "Ride details have been updated" was received
Click "Ride details have been updated"->View->App is not responding (screen becomes white)

https://user-images.githubusercontent.com/84583510/124571438-7238b100-de50-11eb-8c9f-4d21ac01b438.mp4
Expected result

Notification "Ride is canceled" was received
Tap notification "Ride is canceled"-> pop-up window 'Ride is canceled' appears

User story and test case links
User Story #265
Labels to be added
"Bug", Priority ("pri:").

Now this bug fixed but the screen is opened instead of white screen is  wrong. Another bug report will be created


[Dubbo-1681] add test for dubbo common module

What is the purpose of the change
Improve unit test for common module.
dubbo-common/src/main/java/com/alibaba/dubbo/common/concurrent
dubbo-common/src/main/java/com/alibaba/dubbo/common/io
dubbo-common/src/main/java/com/alibaba/dubbo/common/json
dubbo-common/src/main/java/com/alibaba/dubbo/common/logger

Close #1681
Brief changelog

Add test for concurrent, io and logger.
Json module is deprecate since last year, ignore it in codecov config

Verifying this change
CI Pass https://travis-ci.org/diamondblack/incubator-dubbo/builds/372700464
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn clean install -DskipTests & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[x] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #1721 into master will increase coverage by 1.33%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1721      +/-   ##
============================================
+ Coverage     35.53%   36.86%   +1.33%
- Complexity     3784     3875      +91
============================================
  Files           628      618      -10
  Lines         30983    29852    -1131
  Branches       5447     5270     -177
============================================
- Hits          11010    11006       -4
+ Misses        18080    17004    -1076
+ Partials       1893     1842      -51

Impacted Files
Coverage Δ
Complexity Δ

...om/alibaba/dubbo/rpc/filter/ActiveLimitFilter.java
83.33% <0%> (-5.56%)
6% <0%> (-1%)

...rpc/protocol/dubbo/telnet/InvokeTelnetHandler.java
51.89% <0%> (-3.8%)
11% <0%> (-2%)

.../java/com/alibaba/dubbo/config/ProtocolConfig.java
34.02% <0%> (-3.48%)
39% <0%> (-1%)

.../com/alibaba/dubbo/monitor/dubbo/DubboMonitor.java
74.76% <0%> (-1.87%)
7% <0%> (ø)

...bo/remoting/transport/netty/NettyCodecAdapter.java
53.12% <0%> (-1.57%)
3% <0%> (ø)

...java/com/alibaba/dubbo/config/ReferenceConfig.java
47.23% <0%> (-0.74%)
36% <0%> (ø)

.../java/com/alibaba/dubbo/config/AbstractConfig.java
37.67% <0%> (-0.71%)
60% <0%> (ø)

...java/com/alibaba/dubbo/common/json/JSONWriter.java

...main/java/com/alibaba/dubbo/common/json/Yylex.java

...java/com/alibaba/dubbo/common/json/J2oVisitor.java

... and 30 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 9e9e778...1e821da. Read the comment docs.


Updating log emit code to allow for programatic emit from JS.

Simplified emit host code in ch
Update TTD code to support multiple different emit directories.
Add JS call to programatically do emit.
Update unit tests.

@agarwal-sandeep @kfarnung please review.

Closing, as included in PR #2474.


Create LICENSE

Your interest in this code may me take another look at it. I realized that
I didn't handle namespaced attributes because it wasn't and issue for my
use case. Went ahead and fixed it along with some comments and overall
structural improvements. You might want to pull the latest.
Regards
On Fri, Aug 4, 2017 at 7:12 PM, Erik Gustavson<EMAIL_ADDRESS>wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/amdonov/xmlsig/pull/1
Commit Summary

Create LICENSE

File Changes

A LICENSE https://github.com/amdonov/xmlsig/pull/1/files#diff-0
(175)

Patch Links:

https://github.com/amdonov/xmlsig/pull/1.patch
https://github.com/amdonov/xmlsig/pull/1.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/amdonov/xmlsig/pull/1, or mute the thread
https://github.com/notifications/unsubscribe-auth/AArhFBNKdTHq-i3hm7PXjDFw1BHnpRc1ks5sU6VhgaJpZM4OuRtX
.


Password entry, Enter does not accept password (UX issue)

USABILITY, NOT FUNCTIONALITY
When entering the password for the encrypted Authenticator accounts, pressing Enter does nothing, you have to click Ok.  It would be faster when first unlocking Authenticator to enter the password and press enter, as would be the expected behavior, rather than be forced the extra click.  #firstworldproblems

Nice suggestion, thanks!
发自我的 iPhone
在 2015年8月23日，上午4:15，Dustin<EMAIL_ADDRESS>写道：

USABILITY, NOT FUNCTIONALITY
When entering the password for the encrypted Authenticator accounts, pressing Enter does nothing, you have to click Ok. It would be faster when first unlocking Authenticator to enter the password and press enter, as would be the expected behavior, rather than be forced the extra click. #firstworldproblems
―
Reply to this email directly or view it on GitHub.

done in develop branch, and new version will be available soon.


Use header shim to support local Postgres install

This branch adds a header "shim" to allow detection and configuration of Postgres header and library files. If the user's paths are configured, swift build is sufficient. Otherwise, a specific Postgres can be given by, say:
swift build -Xswiftc -I/usr/local/pgsql/include -Xlinker -L/usr/local/pgsql/lib

I wasn't previously aware of the #if os(OSX) technique being used in Perfect-PostgreSQL/Package.swift, but the shim approach here might allow fewer swift packages.


How to capture only canvas on page to png image ?

Hi, i use the createCaptureRequest method to convert web page to png image, but i only would like to retrieve a particular canvas on the page and convert it to png.
Can i "clean" the webpage before capturing ?
Is this possible ? Can you please help ?
Thanks

I'd look at combining this with DOMXPath to get the particular elements you need from the page before converting it.

Thanks @LiamMcArthur !
Solution came using CasperJS embedded into a PHP plugin : https://github.com/alwex/php-casperjs