KILL TASK error - failed to delete .../0_descriptor.json

Affected Version
0.12.1 - HDP 3.1.4 install
Description
Dear All,
I am trying to delete unused segment data from hdfs deep storage. I encounter a weird error and the kill task failes, with:
2020-03-19T15:39:39,737 ERROR [task-runner-0-priority-0] io.druid.indexing.overlord.ThreadPoolTaskRunner - Exception while running task[KillTask{id=kill_PONTMASTERDB.druid_vasarlas_2011068_2017-02-01T00:00:00.000Z_2017-03-01T00:00:00.000Z_2020-03-19T15:39:30.395Z, type=kill, dataSource=PONTMASTERDB.druid_vasarlas_2011068}] io.druid.segment.loading.SegmentLoadingException: Unable to kill segment, failed to delete [hdfs://namenodeha/druid/segments/PONTMASTERDB.druid_vasarlas_2011068/20170201T000000.000Z_20170301T000000.000Z/2020-03-13T10_14_25.197+01_00/0_descriptor.json] 	at io.druid.storage.hdfs.HdfsDataSegmentKiller.kill(HdfsDataSegmentKiller.java:93) ~[?:?] 	at io.druid.segment.loading.OmniDataSegmentKiller.kill(OmniDataSegmentKiller.java:46) ~[druid-server-<IP_ADDRESS>.1.4.0-315.jar:<IP_ADDRESS>.1.4.0-315] 	at io.druid.indexing.common.task.KillTask.run(KillTask.java:103) ~[druid-indexing-service-<IP_ADDRESS>.1.4.0-315.jar:<IP_ADDRESS>.1.4.0-315] 	at io.druid.indexing.overlord.ThreadPoolTaskRunner$ThreadPoolTaskRunnerCallable.call(ThreadPoolTaskRunner.java:445) [druid-indexing-service-<IP_ADDRESS>.1.4.0-315.jar:<IP_ADDRESS>.1.4.0-315] 	at io.druid.indexing.overlord.ThreadPoolTaskRunner$ThreadPoolTaskRunnerCallable.call(ThreadPoolTaskRunner.java:417) [druid-indexing-service-<IP_ADDRESS>.1.4.0-315.jar:<IP_ADDRESS>.1.4.0-315] 	at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125) [guava-28.0-jre.jar:?] 	at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69) [guava-28.0-jre.jar:?] 	at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78) [guava-28.0-jre.jar:?] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_112] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_112] 	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_112]
My first guess is that it is trying to delete 0_descriptor.json but it does not find the file. On my HDFS tree, inside all the segments, there are 2 file:
0_index.zip
descriptor.json
The kill task successfully deletes the 0_index.zip, but returns error when it tries to delete 0_descriptor.json but that does not exists...
Where do I go wrong?
Thanks

I'm seeing the same issue 0_descriptor.json does not exist anywhere in hdfs... thought this might have been a permissions issue
@dataedgehungary was this problem ever resolved?
Thanks

Hey! I havent seen an official solution yet. We got around it with a small python script removing the data for the unused segments from the metastore and deleting the underlying files via hdfs api.
-------- Original message --------From: Adam Kahr<EMAIL_ADDRESS>Date: 23/06/2020  21:49  (GMT+01:00) To: apache/druid<EMAIL_ADDRESS>Cc: dataedgehungary<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [apache/druid] KILL TASK error - failed to delete .../0_descriptor.json (#9540)
I'm seeing the same issue 0_descriptor.json does not exist anywhere in hdfs... thought this might have been a permissions issue
@dataedgehungary was this problem ever resolved?
Thanks
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/apache/druid/issues/9540#issuecomment-648381860",
"url": "https://github.com/apache/druid/issues/9540#issuecomment-648381860",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

Thank you @dataedgehungary, looks like we will be doing the same type of thing... By any chance are you using the hive druid storage handler for ingest?
Adam

Yes we ingest via Hive.
null

interesting this might be a bug with in the Hive Druid Storage Handler...


Added UI to enable user in sulu admin

Added UI to enable user in sulu admin
tasks:

[x] test coverage
[x] enable user

informations:

q
a

Fixed tickets
fixes #1953

Related PRs
none

BC breaks
none

Documentation PR
none

Changelog is missing


Step 8 of docker build pulls oraclejet-preact from private URL

During step 8 of the docker build the oraclejet-preact file is being pulled from a private URL unable to be accessed, build fails.

thanks, I can see that there is an issue with docker build.
RUN npm install
 ---> Running in 9945c6dd376f
npm ERR! code ENOTFOUND
npm ERR! syscall getaddrinfo
npm ERR! errno ENOTFOUND
npm ERR! network request to https://artifacthub-phx.oci.oraclecorp.com/ojet-dev-local/oracle-oraclejet-preact-14.0.7.tgz failed, reason: getaddrinfo ENOTFOUND artifacthub-phx.oci.oraclecorp.com
npm ERR! network This is a problem related to network connectivity.
npm ERR! network In most cases you are behind a proxy or have bad network settings.
npm ERR! network
npm ERR! network If you are behind a proxy, please make sure that the
npm ERR! network 'proxy' config is set properly.  See: 'npm help config'

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2023-04-17T13_48_08_206Z-debug-0.log

updating package.json config to the latest Oracle JET did the trick
 "dependencies": {
    "@oracle/oraclejet": "~14.1.0",
    "@oracle/oraclejet-core-pack": "~14.1.0"
  },
  "devDependencies": {
    "@oracle/ojet-cli": "~14.1.0",

I will publish update soon


Exec commands that need sudo

How to execute commands that need sudo, like:
let vec: Vec<u8> = exec.send_command("sudo systemctl stop some.service").unwrap();
println!("{}", String::from_utf8(vec).unwrap());

Can try like this：
let vec: Vec<u8> = exec.send_command("echo 'password'|sudo -S rm -R /xxx/xxx").unwrap();

Or use the shell channel for interactive operations.

Thanks, yes echo 'password' | sudo -S somecmd works nicely.


Fix OpenAI model context length error by updating condition for maximum context length

It appears that the tokenizer in a third-party library is counting the tokens slightly differently than GPT, leading to a context length error:
OpenAIError: This model's maximum context length is 4097 tokens. However, you requested 4170 tokens (3170 in the messages, 1000 in the completion). Please reduce the length of the messages or completion.
To prevent this error, I updated the condition for checking the maximum context length to include a 10% buffer. This ensures that the maximum context length is not exceeded, while also accounting for any discrepancies in token counting by the tokenizer.
Note that a buffer of 0.95 would probably be enough to prevent the context length error in most cases. However, I set the buffer to 0.9 to make the code more robust and prevent any edge cases where the token counting may be even more different than expected.

This is the correct way to calculate tokens on chat completion API.
https://github.com/dqbd/tiktoken/issues/23#issuecomment-1483317174

I'm getting that error for a reason.

@ziizii, your solution is commendable for eliminating the error/bug. However, @dotneet raises a valid point that accurately counting the number of tokens used is preferable to incorporating a 10% buffer. While the 10% buffer method does work, it results in a loss of 10-9% of the message's total input to the model.
Checkout how it can be implemented: https://github.com/dotneet/smart-chatbot-ui/blob/main/pages/api/chat.ts#L26


Channel Files -> open -> MM goes blank and needs to be restarted

Summary
Open channel files overview and try to open a file.
MM desktop client channels pane goes gray and connat be restored until client is restarted.
Environment

Operating System: Linux, Debian/SID
Mattermost Desktop App version: 5.0.4
Mattermost Server version: 6.0.2

Steps to reproduce

open list of channel files
click on a file
MM goes gray, can switch to "Boards" or "Playbooks", but when switching back to "Channels" pane is still gray and unresponsive
need to quit the client and restart
nothing in the log
experienced it with both XLS files and CSV. While XLS may, in fact, ask too much of MM (in which case it simply should pop up a dialog asking for an application), CSV is just plain text -- so I am assuming it is not necessarily the file type but opening a file as such that breaks something

Expected behavior
File opens (inside MM or with system default application) or a dialog asks for an application to open the file with.
Observed behavior
"Channels" page goes gray and unresponsive, apparently no other way to get out that restarting the client

Possible fixes

@2019-05-10 We fixed this issue in server v6.2.0. Would you be open to upgrading?

I am but a lowly user.
Will ask the providing party next time I met them.

I'll close this for now as the bug will be fixed with a server upgrade to a newer version.


SAM: GSMF implement double schechter functions with redshift evolution from Leja et al.

Completed in https://github.com/nanograv/holodeck/pull/74
Basic tests added.


Accessibility and mark-up: make sure labels are clickable in form elements

Bug description
Accessibility and mark-up: make sure labels are clickable in form elements
Expected result

When I click a form label
It focuses on the form element

[ ] text area
[ ] text input
[ ] select box
[ ] radio button
[ ] checkbox

It works for all form elements in datasets, publications, and on all tabs

[ ] Description
[ ] Full text & files
[ ] People & affiliations
[ ] Datasets
[ ] Biblio Messages

Reason: attribute for in our labels point to the name instead of to the id. And we often do not assign an id to an input field

FYI: focusability can also work without for/id attributes if you wrap the input/textarea/select inside the <label> element but that is probably not feasible in a two column layout.

Already created branch fix_issue_1237 for this.

During writing of the test, I found that this will probably not work for the "Keywords" field as the tagify component does not support this in any way. This doesn't work with a regular <input> field but with a <span contenteditable>. You can set focus programmatically however but that needs separate implementation so probably not worth bothering. I'll prepare assertions for this field but comment them out by default.

Written quite a few tests for all publication type forms and new dataset hitting every field that I could find. Are there any other forms that should be addressed?
To run the tests:
$ npm install
$ npm test -- --spec=cypress/e2e/issues/issue-1237.cy.ts

@verheyenkoen There are no other forms to be added. Thanks!

Cannot work also on repeatable input elements (what element should you focus on?).
e.g. "language", "isbn" ...

And the access levels on the file edit form already have a label for each checkbox.

Checkbox fields indeed seem to be ok already.

Some extra test scenario's:

[ ] In the "Full text & Files" tab > "Document details" popup you can select Access level "Embargoed access" and 3 new fields appear:

[ ] Access level during embargo
[ ] Access level after embargo
[ ] Embargo end

[ ] For datasets, if you select License "The license is not listed here", an extra field "Other license" appears


View as immutable java.util collections without copying

For efficient interop with general Java code, it would be very handy if the collections could be viewed as immutable java.util collections, without having to populate (eg) a new java.util.HashMap.

List.asJavaList()
Map.asJavaMap()
MultiMap.asJavaMap()
Set.asJavaSet()

Great idea!!

There's some similar code in Dexx Collections which may or may not be useful: https://github.com/andrewoma/dexx/tree/master/collection/src/main/java/com/github/andrewoma/dexx/collection/internal/adapter

What should happen with the illegal method, e.g. remove when they're backed by an immutable collection?

#ThrowAllTheThings™

Theoretically we could, but what wouldn't it be very counter-intuitive, e.g.
final java.util.List<T> list = source.toJavaList();
java.util.Collections.shuffle(list);
return ofAll.apply(list);

would either throw new UnsupportedOperationException or would shuffle a linked list in O(N^2) time

I was just thinking the standard throw new UnsupportedOperationException approach, as taken by the immutable wrappers in the JDK[1], Guava immutable collections[2] and Scala[3]. It's not pretty, but it is documented behaviour for the Java collections - "Throws: UnsupportedOperationException - if the put operation is not supported by this map"[4].
If someone wants to get a mutable Java Map out of a Javaslang Map, that's what toJavaMap() is for - in most cases mutations would probably far more efficient with a standard java.util.HashMap than a tricksy delegating implementation. Except in cases where the initial copy is expensive and there are few mutations afterwards. But I think that would be a less common use case.
[1] https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#unmodifiableMap-java.util.Map-
[2] https://google.github.io/guava/releases/snapshot/api/docs/com/google/common/collect/ImmutableList.html#add-int-E-
[3] http://docs.scala-lang.org/overviews/collections/conversions-between-java-and-scala-collections.html
[4] https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#put-K-V-

If someone wants to get a mutable Java Map out of a Javaslang Map, that's what toJavaMap()

But if we give them a wrapper, they won't get a mutable Map

I'm not suggesting a change to the existing method toJavaMap(), just to add a new method.

asJavaMap() -> view as immutable java.util.Map
toJavaMap() -> copy contents to java.util.HashMap

But for a future Javaslang API, I suppose it would be possible to remove the toJava* methods if desired. The standard Java collections can easily be constructed (by copying) from another collection, like this:
java.util.Map<Foo> myMutableMap = new java.util.HashMap<>(myJavaslangMap.asJavaMap());

But it might be better to have both methods, to make it more obvious that the view is immutable.
Now I'm thinking asJavaMap() should be called asImmutableJavaMap()? That should make it obvious.

FYI: @danieldietrich, @seanf: https://github.com/javaslang/javaslang/pull/1736

As always we align to Scala. Scala has JavaConverters. See also this.
scala> import scala.collection.JavaConverters._
import scala.collection.JavaConverters._

scala> Vector(1, 2, 3).asJava
res0: java.util.List[Int] = [1, 2, 3]

Naming
For Javaslang this means that we have one new method, named asJava.
Type hierarchy
We really want to have a Traversable.asJava() that returns java.util.Collection<T>. But this isn't possible in Java. Especially java.util.Map does not extends Collection. Therefore we can't define asJava() at the top level (Traversable). Instead we have these methods:
interface Seq<T> extends Traversable<T> {
    java.util.List<T> asJava();
}

interface IndexedSeq<T> extends Seq<T> {
    @Override
    default java.util.List<T> asJava() {
        return TODO("random access specific view");
    }
}

interface LinearSeq<T> extends Seq<T> {
    @Override
    default java.util.List<T> asJava() {
        return TODO("linear access specific view");
    }
}

interface Set<T> extends Traversable<T> {
    default java.util.Set<T> asJava() {
        return TODO("set view");
    }
}

interface Map<K, V> extends Traversable<Tuple2<K, V>> {
    default java.util.Map<K, V> asJava() {
        return TODO("map view");
    }
}

interface Multimap<K, V> extends Traversable<Tuple2<K, V>> {
    @Override
    default java.util.Map<K, Collection<V>> asJava() {
        return TODO("map view");
    }
}

Notes:

For now we do no conversion for PriorityQueue or Tree. For sure, we could convert to sth. (like java.util.List) just for the sake to convert it to sth. But for now it is not needed.
In Javaslang we do not have Iterator.asJava(). Iterator already extends java.util.Iterator. Additionally, as of 3.0.0, Iterator will not extends Iterable any more (see also #1295).

This one needs definitely a section in our documentation. I will do that.

@paplorinc Also I would love to see a packag-private javaslang.collection.JavaConverters helper class that contains static helpers that are called from within our collections.
Example:
public interface IndexedSeq<T> extends Seq<T> {
    @Override
    default java.util.List<T> asJava() {
        return JavaConverters.toJava(this);
    }
}

class JavaConverters {
    static <T> List<T> toJava(IndexedSeq<T> source) {
        return TODO("random access specific view");
    }
}

@danieldietrich, please check my solution at https://github.com/javaslang/javaslang/pull/1736/commits/28d5c60eb3139d361163858c957ec27acecd2f6b

@paplorinc my parents in law visit us - will do it this evening...

Information on next iteration

It is a good practice to define a clear interface (_the asJava() methods) rather than exposing our internal view implementation types.
We need to implement appropriate equals, hashCode and toString methods. The toString should output the same as ArrayList.
We should also implement serializable
Please always fully qualify java collection types in our Javaslang codebase, even if there is actually no name clash. (Fully qualifying java.util.functions is not necessary.)

class JavaConverters {

    private JavaConverters() {
    }

    static <T> java.util.List<T> asJava(IndexedSeq<T> seq) {
        return new IndexedSeqAsJavaList<>(seq);
    }

    static <T> java.util.List<T> asJava(LinearSeq<T> seq) {
        return new LinearSeqAsJavaList<>(seq);
    }

    static <T> java.util.List<T> asJava(Set<T> set) {
        return new SetAsJavaSet<>(seq);
    }

    static <K, V> java.util.Map<K, V> asJava(Map<K, V> map) {
        return new MapAsJavaMap<>(map);
    }

    static <K, V> java.util.Map<K, Collection<V>> asJava(Multimap<K, V> map) {
        return new MultimapAsJavaMap<>(map);
    }

    // -- private view implementations

    private static abstract class SeqAsJavaList<T> implements java.util.List<T> {

        protected abstract Seq<Object> delegate();

        // override only methods of List that share the same implementation for IndexedSeq and LinearSeq!
        @Override
        public int size() {
            return delegate().size();
        }

        @Override
        public boolean isEmpty() {
            return delegate().isEmpty();
        }

        @Override
        public boolean contains(Object o) {
            return delegate().contains(o);
        }

        // et cetera

        @Override
        public boolean equals(Object o) {

//            if (o == this) {
//                return true;
//            } else if (o instanceof java.util.List) {
//                return Collections.areEqual(delegate(), (java.util.List<?>) o);
//            } else {
//                return false;
//            }

            // java collections are not equal if references refer to the same memory location
            return o == this;
        }

        @Override
        public int hashCode() {
            return delegate().hashCode();
        }

        @Override
        public String toString() {
            // not tested, should output the same as java.util.ArrayList
            return delegate().mkString("[", ",", "]");
        }

    }

    private static class IndexedSeqAsJavaList<T> extends SeqAsJavaList<T> implements Serializable {

        private IndexedSeq<Object> delegate;

        IndexedSeqAsJavaList(IndexedSeq<T> delegate) {
            this.delegate = IndexedSeq.narrow(delegate);
        }

        @Override
        protected IndexedSeq<Object> delegate() {
            return delegate;
        }

        // override the unimplemented methods
        // ...
    }

}

@danieldietrich, it's difficult to code in the browser, do you think it would be easier if you would merge the PR and change those instead?

Throwing is no good idea, it will lead to endless suffer. We should implement the mutating methods.

There might be a use case for that too, but there's a reason people use Guava's ImmutableList etc, despite the impurity of "optional" mutation methods. Sometimes you just want it to be an immutable list. OTOH if you want a mutable list, you should start with one of the many mutable list implementations, not an immutable one. (Or call toJavaList() to make a mutable copy.)
Scala does throw if you convert an immutable collection and then call a mutator method: http://docs.scala-lang.org/overviews/collections/conversions-between-java-and-scala-collections.html

@seanf

but there's a reason people use Guava's ImmutableList etc

In Guava there is no other way around throwing, they just wrap a mutable List. If they would allow to modify it they effectively would have ... a mutable List.
The one bad thing with throwing RuntimeException is that it happens at runtime. No one can beware us of ending up with an application with undefined behavior (which is the worst thing that can happen).
Scala did not choose the right path in any case regarding their collection library. That's also a reason for an effort to completely rethink the collection library.
These are the pros and cons I see by making the view writable:
Pros:

The implementation is safe(!)

No 'broken' programs in terms of throwing RuntimeException
No problems with variance / heap pollution like described in our Cats & Dogs blog post because the underlying delegate is a persistent collection

Especially we can be sure that the original collection (our delegate) is not modified
We widen the use cases. If a user needs to use the java collection interfaces he may create a modifiable view in O(1). That's blazing fast!

Cons:

Not really a con: The application does not throw, if the user calls a mutator method but did not want to call it.
If the user needs unmodifiable versions he may call one of the unmodifiable*() helpers in j.u.Collections. The other way round is not possible: We can't simply make an unmodifiable collection modifiable.

Summed up I see only pros.   But our underlying delegate is persistent. This security hole does not exist for us.
Which is your biggest fear / what can go wrong? Or is it only "but the other guys do it the other way"?

The one bad thing with throwing RuntimeException is that it happens at runtime.

:+1:

If the user needs unmodifiable versions he may call one of the unmodifiable*() helpers in j.u.Collections.

:+1:, haven't thought of that!

Summed up I see only pros.

Let me give a few additional pros and cons to make your list more balanced :)
Pro:

The user expects a mutable java List, as that's what he's used to. By trying to access the last element via the listiterator (which is possible in an ArrayList and the doubly linked LinkedList), he will be surprised that it's linear - minor issue in my opinion.
using it the view for a small Vector as if it were mutable will result in linear append - still a minor issue
the advantages of persistence (i.e. that mutations don't propagate globally) is not preserved

Pro:

Users can convert to and from the java world (we may want to optimize for these cases when users want to convert back to immutable views) basically for free
Immutable collections can be disguised as mutable ones when giving it out to the world

Which is your biggest fear / what can go wrong? Or is it only "but the other guys do it the other way"?

Proud of you @danieldietrich, I like it when we dare to be pioneers!

I'm just pointing to Guava because I see an important use case for immutable java.util.Lists, and so did Google. (Some of their reasoning here: https://github.com/google/guava/wiki/ImmutableCollectionsExplained)
I guess I also think creating another (much less efficient) form of mutable list is a lot of effort (and perhaps maintenance complexity) for very limited value.  I like immutable objects. Being able to say this java.util.List is "the same" as that javaslang List is very useful. Once you introduce mutability, that might not be true for long. Just because you can implement the optional mutation methods doesn't mean you must, or should.
I assume javaslang's Iterator.remove() throws UnsupportedOperationException?
For me as a new user, I use javaslang collections for their immutability. (I've been looking for a good, well-documented persistent collection in Maven Central for quite a while.) If I need to view such a javaslang collection as a Java collection, it's for interop, not because I wish I had created a mutable collection.
If you implement a mutable java.util.List view of a javaslang immutable List, will you also be creating a javaslang.MutableList (view) for completeness? The java.util interfaces have a few warts, and they don't have all the nice javaslang methods.
I'm not saying there's no use case for mutable views of immutable collections. In a way, they remind me of Clojure's refs, and seem like a clever idea. But maybe they aren't a core feature for a library which (to me) is about immutable collections, and could instead live outside the javaslang core.
Yes, Collections.unmodifiable* is an option. I think it would be friendlier if the immutable view were available directly from the javaslang collection methods though. (Especially since I think the immutable collection is the truer representation of the javaslang collection, although I'm apparently alone in that view. The possibility of unwanted exceptions is just an unfortunate consequence of the optional methods in the Java Collections API.)
Note that adding an unmodifiable wrapper may make it difficult or impossible to emulate Scala's ability to give you the same Java List every time you convert a Scala/Javaslang list, or to do round-trip conversions. http://docs.scala-lang.org/overviews/collections/conversions-between-java-and-scala-collections.html
In any case, if you're willing to break from Scala precedents where it makes sense, I think trying to make a Seq look like a List (despite the big differences in performance guarantees for some operations) is a Scala mistake which should not be emulated.

I'm just pointing to Guava because I see an important use case for immutable java.util.Lists, and so did Google. (Some of their reasoning here: https://github.com/google/guava/wiki/ImmutableCollectionsExplained)

Guava says: Safe for use by untrusted libraries.
I think: How can throwing a RuntimeException be safe!?
Guava says: Thread safe: can be used by many threads with no risk of race conditions.
I think: Same here
Guava says: Doesn't need to support mutation, and can make time and space savings with that assumption. All immutable collection implementations are more memory-efficient than their mutable siblings (analysis)
I think: The memory footprint is equivalent (plus a constant for the wrapper) to that of the persistent collection.
Guava says: Can be used as a constant, with the expectation that it will remain fixed
I think: An unsafe constant that throws if it is touched at the wrong place. Not good, I will not build my code on such 'things'.

I guess I also think creating another (much less efficient) form of mutable list is a lot of effort (and perhaps maintenance complexity) for very limited value. I like immutable objects. Being able to say this java.util.List is "the same" as that javaslang List is very useful. Once you introduce mutability, that might not be true for long. Just because you can implement the optional mutation methods doesn't mean you must, or should.

I see no maintenance hell here: flat hierarchy, few methods, mostly delegating - easy!
"much less efficient" -> tradeoff between fast creation (= view) and most efficient ops (= converted), user can decide

I assume javaslang's Iterator.remove() throws UnsupportedOperationException?

I thought about implementing it in a second step, if easily(!) possible (did I mention it?)

For me as a new user, I use javaslang collections for their immutability. (I've been looking for a good, well-documented persistent collection in Maven Central for quite a while.) If I need to view such a javaslang collection as a Java collection, it's for interop, not because I wish I had created a mutable collection.

Persistence is much more than immutability. Writing operations is possible but new versions are created. For me a writeable List presentation is more natural.
But yes, indeed, the security hole already mentioned (heap pollution) does also exist for our mutable List view. But that's expected by users because... it is a mutable List!

If you implement a mutable java.util.List view of a javaslang immutable List, will you also be creating a javaslang.MutableList (view) for completeness? The java.util interfaces have a few warts, and they don't have all the nice javaslang methods.

No, definitely not. I was asked that several times and I always answered that Java already has mutable collections and the Stream extension for additional operations. I see no use-case for creating more mutable collections. The effort of creation and maintenance will be overkill compared to the gain.

I'm not saying there's no use case for mutable views of immutable collections. In a way, they remind me of Clojure's refs, and seem like a clever idea. But maybe they aren't a core feature for a library which (to me) is about immutable collections, and could instead live outside the javaslang core.

(see above / persistence vs immutability)

Yes, Collections.unmodifiable* is an option. I think it would be friendlier if the immutable view were available directly from the javaslang collection methods though. (Especially since I think the immutable collection is the truer representation of the javaslang collection, although I'm apparently alone in that view. The possibility of unwanted exceptions is just an unfortunate consequence of the optional methods in the Java Collections API.)

:+1:

Note that adding an unmodifiable wrapper may make it difficult or impossible to emulate Scala's ability to give you the same Java List every time you convert a Scala/Javaslang list, or to do round-trip conversions. http://docs.scala-lang.org/overviews/collections/conversions-between-java-and-scala-collections.html

No, we achieve the same. The conversion in both directions will be O(1). (That's the essence they talk about.)

In any case, if you're willing to break from Scala precedents where it makes sense, I think trying to make a Seq look like a List (despite the big differences in performance guarantees for some operations) is a Scala mistake which should not be emulated.

There are single linked Lists, lazy linked lists, random access Lists, etc. Java has only random access Lists. Converting IndexedSeq to Java List seems to be more straight-forward... But we will do it also for Seqs because it works out of the box.

@seanf but maybe you are right... let me think a while about it... Javaslang should not be the next Cats & Dogs library.

@seanf @paplorinc I thought about the whole topic.
My strategy with Javaslang collections is to provide a safe, more concise and more powerful alternative to the old-school, mutable Java standard collections.
The following is considered to be a safe programming style:
List<T> f(List<U> input) {
    // 1. we don't modify input
    // 2. we might use mutable local variables that do not escape to the outside
    // 3. we return an immutable output
}

In general we follow this programming style as implementor of f. But also we expect this when we are caller of f. It seems to be a good idea to let asJava() return immutable objects. Given that we enforce (by throwing) that no mutator methods are called when passing our objects to other functions.
But in the end, the developers are responsible to produce stable code with a defined/reproducable behavior.I see use-cases where it might be of interest to have mutable views:
Returning a mutable list is ok, when created in a local context:
List<T> localContext() {
    Seq<T> seq = ...;
    ...
    // users of our API will not mutate the result for security reasons
    // if a mutable List is needed we might use toList() instead
    return seq.asList();
}

When having conversions Seq-List-Seq, a mutable List might come handy:
Seq<T> localContext(Seq<U> seq) {
    j.u.List<T> list = seq.asJava(); // produce a List view on seq in O(1)
    mutateTheSeqBehindTheCurtain(list); // performs operations with a time/mem complexity of seq
    return Seq.ofAll(list) // recognizes the view and pulls out the current delegate in O(1)
        .map(...);
}

We might provide a special API that makes the mutable context local:
Seq<T> localContext(Seq<U> seq) {
    // conversion back and forth in O(1)
    return seq.asJava(list -> {
            mutateTheSeqBehindTheCurtain(list);
    }).map(...);
}

But how often is this use-case really needed?
I now aggree to @seanf that returning immutable objects might be the better variant.

just to add my grain of salt: IMO the option to easily convert to mutable java collections is crucial. We've been able to convert a relatively big codebase to (mostly) javaslang because we knew we can port an isolated unit to generate and operate on javaslang collections, then get a java collection from it trivially and pass it on to the rest of the program. We ported the app piece by piece in that fashion. If by default asJavaList() returns an immutable collection that throws when you attempt to modify it, then that cannot be used for that purpose, because we can't assume anything about what the legacy code we're communicating with is doing. So for such a porting, I think you really need a functionality such as the existing toJavaList(). If it gets verbose to achieve that, we (our team) would have had to write helpers for conversion, and that's just friction getting in the way of migrating to javaslang.

@paplorinc Additionally we should provide j.u.SortedMap, j.u.SortedSet conversion.
Accordingly we need to change method declarations within our type hierarchy:
// Ok
Seq: abstract j.u.List asJava()
IndexedSeq: default j.u.List asJava()
LinearSeq: default j.u.List asJava()

// TODO
Set: default j.u.Set asJava()
SortedSet: @Override default j.u.SortedSet asJava()

// TODO
Map: default j.u.Map asJava()
Map: @Override default j.u.SortedMap asJava()

toString() looks like this:
        SortedMap<Integer, String> map = new TreeMap<>();
        map.put(1, "a");
        map.put(2, "b");
        println(map);

// output:
{1=a, 2=b}

        SortedSet<Integer> set = new TreeSet<>();
        set.add(1);
        set.add(2);
        println(set);

// output:
[1, 2]

@paplorinc In fact we should convert sorted variants to j.u.NavigableSet and j.u.NavigableMap. But for now we can't do that because there is an open issue to add this functionality to Javaslang: #1317 (I'm on it).
For now we return SortedSet and SortedMap. I will create another issue for the navigable interfaces that depends on #1317

@emmanueltouzery Thank you for your feedback. The conversion methods toJava*() will stay with us. What we need to know is if it would help in a real-life application to have a way to additionally create mutable views.
// Takes new mem by creating a new ArrayList and copying all elements in O(n).
// As a result, operations on that List are the same as those of ArrayList.
toJavaList()

// Additional method. creates a List in O(1) by providing a wrapper around a persistent collection.
// As a result, operations on that List are the same as those of the underlying persistent collection.
asJava()

What do you think? Would you propagate a mutable view to the outside or copy a collection instead?
/cc @paplorinc @seanf

@danieldietrich, we should create real-world tests to see how both feel and decide later.
I'm ok with both, though I like your new approach more now that I've tried it (i.e. the mutable, backed by immutable).

For me as I said, I think the toJava* are needed, glad they're not in question. For the new asJava views, no opinion. I'm sure there are useful use-cases, didn't need it so far though. They definitely sound cool (although allowing modifications sounds overkill, but maybe it can be implemented without the complexity exploding).

On 6 December 2016 at 22:46, Daniel Dietrich<EMAIL_ADDRESS>wrote:

@emmanueltouzery https://github.com/emmanueltouzery Thank you for your
feedback. The conversion methods toJava*() will stay with us. What we
need to know is if it would help in a real-life application to have a way
to additionally create mutable views.
// Takes new mem by creating a new ArrayList and copying all elements in O(n).// As a result, operations on that List are the same as those of ArrayList.
toJavaList()
// Additional method. creates a List in O(1) by providing a wrapper around a persistent collection.// As a result, operations on that List are the same as those of the underlying persistent collection.
asJava()
I think it's very important that the method names make a clear distinction
between the mutable version and the immutable version, to minimise
surprises.

In fact, at the risk of taking things too far (or too far off track), I
wonder if it's a good idea to add an ImmutableList *interface *which would
look a bit like Guava's ImmutableList class:
https://google.github.io/guava/releases/snapshot/api/docs/com/google/common/collect/ImmutableList.html
Basically It would just extend java.util.List, but with deprecation
warnings on the mutation methods.
(In my own experience with Guava, I sometimes use deliberate references to
Guava's ImmutableList, to help keep straight mutable versus immutable
lists. It's certainly not a guarantee because an ImmutableList is still a
List, but it does help a little, just as a form of documentation.)
If the user just assigns the result to a java.util.List variable, this
interface will be useless, naturally. But if the object is assigned to a
variable of type javaslang.jcollection.ImmutableList (which IDEs would
offer to do automatically in various situations, eg "create local
variable"), this may help to remind the user that this is a special
immutable list, and that mutator methods should be avoided.
What do you think? Would you propagate a mutable view to the outside or

copy a collection instead?

So far I've just been using toJava* when mutation was required, and it was
perfectly fine in that particular situation.
But are you asking whether the existing method toJava* should switch from
copying, to providing a mutable view? Given the performance differences, I
don't think the *existing *method should make such a change.
I suppose someone should ask the obvious next question. Does it make sense
to provide three options, or is it too much bloat?

toJavaList - O(n): copies to a java.util.ArrayList
asJavaList/asMutableJavaList - O(1): provides a mutable view by
wrapping a mutable pointer to a javaslang List
asImmutableJavaList - O(1): provides an immutable view[1]

[1] Preferably by wrapping a javaslang List, *not *by wrapping an
unmodifiableList around a mutable wrapper around a javaslang List.

/cc @paplorinc https://github.com/paplorinc @seanf
https://github.com/seanf
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/javaslang/javaslang/issues/1728#issuecomment-265141479,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADTi7cBggSRYuCIZ-eDR6tVVHf0lji9ks5rFVlCgaJpZM4K_0Ve
.

I see valid use-cases for all variants. We should

add asJava() that returns mutable j.u. collections
add asJava(Consumer<List<T>> that allows list mutation in a local scope. The mutated seq is returned.finally
add asJavaImmutable() that returns an immutable view

@paplorinc or you do it more JIT friendly, like in Vector:
@Override
public boolean add(T element) {
    if (isValid(index)) {
        delegate = delegate.append(element);
        return true;
    } else {
        throw new UnsupportedOperationException();
    }
}

I agree that both alternatives have value (mutable and throwing), but combining them makes this more than simple delegation, which I find worst than any simple alternative.

Depends on #1800 because ListView.addAll(empty) needs to return false, i.e. not modified.

Note: First I thought it is a good idea to mimic Java's j.u.List behavior. But that applies only to the mutable case. The immutable impls are inconsistent.
Simple example: set(index, T)  and remove(index) (but there are more...)

I vote for the immutable version, with the API method called asJavaImmutable() or asImmutableJava(). This way the API consumer should we very well aware what gets, even without reading the javadocs for that method. That is, he/she will get an immutable view of the collection through the standard Java Collections API. He/She shouldn't try to mutate it and shouldn't pass it to some other black box code which would try to mutate it (which would we a bad practice anyway from that black box code). You might say that throwing a runtime exception is unexpected behavior happening at runtime. I think that isn't the case (i.e. it's not unexpected), considering the above, but even then, it should be quite obvious with minimal amount of testing. I don't think Javaslang shouldn't try to guard against every possible misuse of the library, it's enough to aim for a well defined behavior, which IMO is satisfied with the above.

@nfekete Agreed, we shouldn't obfuscate things and raise the possibility of errors by choosing the wrong naming. I liked the short asJava() but I'm totally ok with naming the methods asJavaMutable() and asJavaImmutable().

The Java Collection API docs:

The "destructive" methods contained in this interface, that is, the methods that modify the collection on which they operate, are specified to throw UnsupportedOperationException if this collection does not support the operation. If this is the case, these methods may, but are not required to, throw an UnsupportedOperationException if the invocation would have no effect on the collection. For example, invoking the addAll(Collection) method on an unmodifiable collection may, but is not required to, throw the exception if the collection to be added is empty.

In order to keep things (and code!) as simple as possible, our immutable views will throw an UnsupportedOperationException before performing non-null and index checks. Half of the standard immutable java.util.List implementations do it this way, the other half performs checks first.

Yes, I think throwing unconditionally is better, because accepting an empty collection by addAll() could let people believe the receiver collection is actually mutable. Calling any kind of mutating method on an immutable collection is an error by itself.

@nfekete

I think Javaslang shouldn't try to guard against every possible misuse of the library, it's enough to aim for a well defined behavior, which IMO is satisfied with the above.

your views are thoroughly thought through and very helpful - good to have you here!

We layed the grind stone here. Remaining views will be implemented in #1933


NuGet tests - Remove skipping in case of non-Windows operating system.

Will open new PR with all non-windows support.


Drag handles

My question is a simple one - is it possible to use only a certain child element as the drag handle? For example, only drag when an icon inside the draggable element is clicked?
I know I can set {draggable: false} to disable it for all child elements, but is it then possible to re-enable it for a certain element?
An example can be seen from react-draggable's demo page
http://mzabriskie.github.io/react-draggable/example/

You would need to fork this repo and modify code to make, this happen. This functionality in not implemented.


remove  in reply to mention

when the tweet is replying to another tweet, the tweet.text will add the mention example:
"@iam2sw4g @tweek BASTA" instead of "BASTA" so I use display_text_range to remove the mentions

https://twitter.com/convex_dev/status/1536835775542661120

Nice! looks good to me 👍🏻 Thank you again!


insertion sort  program created

This Pull Request resolves Issue #
Description:
In this Pull Request we have done the following additions/edits for the code:
Note: Delete all the text including this!

Make sure you replace #<IssueNumber> with the particular Issue that you are referencing with!
Make sure you describe the Issue properly and ask as many people as possible to review your Pull Request so that it can be merged as soon as possible!

Please resolve Merge Conflicts

PR closed due to inactivity!


Deduplicate Addon Assets

Currently, when an addon is included in multiple locations with lazy Engines, that addon's code is duplicated. This problem breaks down into two scenarios:

Duplication when a parent and child have the same addon. This is easy to solve, as the parent copy should be the only copy, since it is guaranteed to be loaded first.

Duplication when siblings have the same addon. This is difficult to solve as we can't make assumptions as to which Engine will be loaded first. There are three potential approaches in this scenario:

Include the asset in both Engine bundles -> this is easy to implement and use (and is our current reality), but has negative impact on asset download size for our users. Also has potential to run into weird, state issues by clobbering previously loaded copies of the module.
Bundle shared assets separately and load with first Engine that needs them -> relatively easy to implement and use, but can incur multiple network requests for potentially small assets. The Asset Manifest/Loader has easy support for this use case.
Hoist shared assets into the closest common ancestor's bundle -> no more difficult to implement than the above, but bloats the main assets with potentially unused features. Also can make it difficult to reason about where assets wind up.

It is likely that each of the above approaches can be good or bad depending on circumstances.
Thus, we need to discuss and arrive at a solution for deduplication in sibling engines. The parent and child scenario just needs to be implemented.

Point one is crystal clear, agree.
About point 2, I think that all three approaches are valid options depending on your app. I don't think there is a single solution. 'd like the decission to be in the hands of the developer. Ideally expressed just in terms of package.json, but I don't know if it will be doable.
By example, the last option, hoist shared addons to the parent app is as simple for the user as include that addon in the package.json of the parent app. That would mean we're now in point 1, in which we agree there it should be hoisted.
However repeat the addon or bundle it as a separate file is tricky and will probably depend on your app and the addon. An entra request might make sense for big addons, not so much for those that just give you a couple helpers. It will become more and more if your app leverages SW download deltas between versions.
Without giving it too much though I think that the default approach for duplicated addons that are not in the parent app could stay as today and duplicate them, and if the user wants to bundle some addons separately those can be listed in some sort of special config key, either in the package.json or in the ember-cli-build.js of the host app.

A PR has been opened for Point 1: https://github.com/ember-engines/ember-engines/pull/356.
For Point 2, I think the approach @cibernox outlines is good. Which means for the 3 scenarios I outline above we have:

Duplicate: This is, and will continue to be, the default behavior for sibling issues.
Hoist: Define the dependency in both Engine and host, and the solution to Point 1 will deduplicate the shared code.
Separate bundle: We should determine an API for allowing the Application to specify which addons should be separately bundled. This will only apply to addons included by Engines. Anything that is a dependency of the application will just be included in the initial payload (again, Point 1).

#356 has been merged. Some additional edge cases came up in that PR that still need to be addressed. Linking them here so they aren't forgotten:

https://github.com/ember-engines/ember-engines/pull/356#issuecomment-288571816
https://github.com/ember-engines/ember-engines/pull/356#issuecomment-288645644

On a related note, can I duplicate the dependencies for my engine?
I'm trying to build an engine separately. Since the Deps of the engine and dummy app will be the same, the generated vendor files (js and css) will always be same. It makes impossible to inject an engine into an actual consuming app without marking it as an explicit dependency. Can I make a standalone build for an engine?

Hi @gokatz - Did you had any luck with building engine standalone and using alongside the host app?

AFAIK, this is not yet supported in Engines yet, @JoseWebby
I switched to another stack instead.

It was fixed by #595
can you close it @rwjblue @dgeb ?


linux additional arguments fix

Task name: AzureMysqlDeploymentV1
Description:
Task fails for below combination

Linux Agent + Mysql script file selection + Additional arguments
Task fails because of not having semi-colon (;) following the MySQL Script file path.

Documentation changes required: (Y/N) N
Added unit tests: (Y/N) N
Attached related issue: (Y/N) https://github.com/microsoft/azure-pipelines-tasks/issues/14075
Checklist:

[x] Task version was bumped - please check instruction how to do it
[x] Checked that applied changes work as expected

Will this be required for MysqlDeploymentOnMachineGroupV1 task as well ?

Will this be required for MysqlDeploymentOnMachineGroupV1 task as well ?

This update has broken builds on our Windows build agents

I did a bunch of testing this morning.
The issue is related to the source command itself on Windows and specifically where the full file path is specified, but only where there is a semicolon at the end of the file path.
All of the following tests are on Windows in cmd.exe
Both of these work
source foo.sql
set @foo='bar';source foo.sql

Both of these do not work:
source c:\users\foo\bar\foo.sql;
set @foo='bar';source c:\users\foo\bar\foo.sql;

Both result in the same error locally:
ERROR at line 1: Unknown command '\U'.

I'm not sure why, but the error from the agent is different:
ERROR at line 1: Unknown command '\a'.

MySQL Manual on source client command
The MySQL client manual for commands: https://dev.mysql.com/doc/refman/8.0/en/mysql-commands.html
For the source command:

source file_name, \. file_name
Read the named file and executes the statements contained therein. On Windows, specify path name separators as / or \\.
Quote characters are taken as part of the file name itself. For best results, the name should not include space characters.

Important: I tried switching the path separator \ with \\ and MySQL client emitted a different error:
ERROR at line 1: Unknown command '\\'.

Before I went searching for the manual, which reads "Quote characters are taken as part of the file name itself" I tried quotes and backticks. So it makes sense adding these didn't work.
The final alternative was to switch out the path separators for / which is the manual's first recommendation.
Finally, both of these work:
source c:/users/foo/bar/foo.sql;
set @foo='bar';source c:/users/foo/bar/foo.sql;

Microsoft docs on AzureMySqlDeployment task
Docs: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-mysql-deployment?view=azure-devops
The documentation for the SqlFile parameter says:

(Required) Full path of the script file on the automation agent or on a UNC path accessible to the automation agent like, \BudgetIT\DeployBuilds\script.sql. Also, predefined system variables like, $(agent.releaseDirectory) can also be used here. A file containing SQL statements can be used here

(note case difference on S in SqlFile between the usage example at the top of the page and the Arguments table. Example is lower, table is upper. Probably makes no difference, but... consistency... our usage is upper)
The docs are wrong in this case so would need updating too. Probably adding a note about the path issue.
Weirdness in version 1.179.0
Looking at the way the -e option was wrapped in double quotes in the previous version makes me wonder if there was some sort of issue being worked around, in the first place.
"-e source c:\foo\bar\foo.sql"

Rather than the updated, I would say, correct version:
-e "source c:\foo\bar\foo.sql;"

I've looked through the changes and cannot work out why the previous version was wrapping the -e option in double quotes.
Changes

4abbef2c It looks like the original change was simple, to just add a semicolon to the end of the source client command.
faa86dbd Added a regex replace which would have kept my builds working, I think
7452d2fc Removed the Windows fix :'-( - See here: https://github.com/microsoft/azure-pipelines-tasks/pull/14183#discussion_r556264648

Shame about commit 7452d2fc, really. But would that have caused issues where \ was escaping a path character?
Conclusion
Change \ path separator to / as recommended in the MySQL manual (linked above). Probably better to use a tool that understands file paths, rather than regex.
Definitely don't try \\ as recommended in the MySQL manual. This doesn't work
Failing that
Update documentation to document the issue and ask that Windows users use hand-crafted relative paths, using / separator. This might be a painful solution when developing pipelines.

Issue reported here: https://github.com/microsoft/azure-pipelines-tasks/issues/14352

@mattboothman thanks for reporting this.
Initial issue was in Linux agent. this fix contains two things string interpolation + adding semicolon
when I tested this fix on windows agents it failed, realised that path requires / so added this fix 7452d2fc73026e41fd24172e06947b218ebf787b
To make sure whether this is failing because of fix or not, I removed semicolon and replace regex, (but did not remove interpolation) still task failed.
Since it was failing without my changes and nobody reported it I thought users might have workaround for this and by changing path in code I might break users so reverted replace part.
But I think because of interpolation, command is being formed like this, (which is correct though)
-e "source c:\foo\bar\foo.sql;"
instead of this (not sure why this was working)
"-e source c:\foo\bar\foo.sql"

@AmrutaKawade I agree, -e "source c:\foo\bar\foo.sql;" is the correct format.
inlineSql formats as "-e select * from foo;" which sqlFile used to to before the change. I'm really ot sure why that is.
It's quite a confusing problem, please bear with me:
The actual problem, for windows, is the addition of the ; delimiter, which is also correct. It terminates a SQL statement, it's valid SQL, it's right that it should be there. But for some unknown reason, the combination of the use Windows path separators \ and inclusion of the semicolon causes the MySQL client to emit an obscure error message that's difficult to understand and debug.
The fix, on Windows, is to do as the MySQL Client manual asks and switch the path separator for either \\ or /. However, I tried \\ on the commandline, locally, and mysql emitted an error citing the \\ characters as an invalid command. The unix style path separator /, however, does work.
The PR that introduced this issue was raised by someone using this task with an agent running on a Linux platform. Their issue was actually related to the introduction of additional -e parameters into the command line, essentially adding additional SQL statements that were executed by the MySQL client before the -e "source ..." option's SQL. This introduction of additional statements before the source statement caused the MySQL client to require that the source statement be terminated with a semicolon ;. But, the addition of that semicolon caused the issue we have, now, on Windows build agents, using Windows style path separators.
I've no doubt, without testing, that the omission of the ';' delimiter after the source statement would have been working on Linux until the OP added additional -e options.
It's a very odd problem.
I believe the only fix that is required, to make this problem go away, is that when the task builds the absolute path used to reference the SQL file passed into the sqlFile argument, it uses Unix style path separators /, rather than Windows \, as the MySQL Client manual suggests.
So rather than:
-e "source c:\foo\bar\foo.sql;"
We sould get:
-e "source c:/foo/bar/foo.sql;"
If you wouldn't mind pointing me in the right direction for documentation on developing DevOps pipeline tasks, I'm quite happy to take a bash at it, testing on both Windows and Linux, with and without additional -e options. I can then sumbit a fix in PR.


Regression tests for ODE solver and integration tests for production model is in place

Fixes #462
Fixes #1412
At some points, both issues are depending on the MiniO bucket. And I would like to try to set up the TC as fur as I can during the waiting time. So two issues will be closed at the same time by this PR.
This PR has a working regression test for ODE solver, and a integration test for HWS model.
For the regression tests, only 4 models was chosen for regression testing. In trivial model, because it is a very simple model, all the solvers are tested under 4 different settings of autodiff and sparsity. No arrow file was used for benchmarking the trivial model because it has only one basin, and the results from different settings/solvers doesn't vary much. For other 3 models, only the default solver was tested. It is tested under 4 settings of autodiff and sparsity. The benchmark arrow files will be in MiniO bucket instead of repository.
For integration test, the benchmark arrow file for HWS model will be in MiniO bucket as well.
Now if you enter pixi run test-ribasim-regression in terminal, regression tests are run. And pixi run model-integration-test, integration test is run.
@visr can you review the Julia part?
@Manangka can you review the Kotlin part?

The structure is not consistent with the other teamcity projects in this repo.
I would have structured it something like:
Ribasim/
├─ Ribasim_Linux/
│  ├─ ...
├─ Ribasim_Windows/
│  ├─ ...
├─ TestBench/
│  ├─ TestBench_WindowsProject .kt
│  ├─ TestBench_LinuProject .kt

In the a main project you define a composite build step. This buildstep will have the trigger. The composite buildstep will have dependencies to the 2 test. The composite build step will trigger the dependencies when it itself is triggered so the dependend steps don't need triggers anymore
Something like this (i havent tested it)
TestBench_WindowsProject .kt
object TestBench_WindowsProject : Project ({
    id("IntegrationTestHWS")
    name = "IntegrationTestHWS"

    buildType(TestBench_Windows)
    buildType(IntegrationTest_Windows)
    buildType(RegressionTest_Windows)

    template(IntegrationTestWindows)
    template(RegressionTestWindows)
})

object TestBench_Windows : BuildType({
    name = "TestBench_Windows"

    allowExternalStatus = true
    type = Type.COMPOSITE

	# Your triggers here
	# ...

	 dependencies {
        snapshot(IntegrationTest_Windows) {
            onDependencyFailure = FailureAction.FAIL_TO_START
        }

		snapshot(RegressionTest_Windows) {
            onDependencyFailure = FailureAction.FAIL_TO_START
        }
	}

})

object IntegrationTest_Windows : BuildType({
    name = "IntegrationTestWindows"
    templates(WindowsAgent, GithubCommitStatusIntegration, IntegrationTestWindows)
})

object RegressionTest_Windows : BuildType({
    name = "RegressionTestWindows"
    templates(WindowsAgent, GithubCommitStatusIntegration, RegressionTestWindows)
})

Take note of your revert merge commit, you should eventually merge main again and make sure that any conflicts are resolved by using --theirs (as this PR now proposes to undo commits present in the main branch).


Put patch-level labels in a Dataloader, ensure it loads in notebook

ImageNet labels are way too coarse-grained. @themachinefan put ImageNet through a SAM pipeline to get a label for each patch.
The results are here: https://huggingface.co/datasets/Prisma-Multimodal/segmented-imagenet1k-subset
We need to make sure these results load cleanly into a Dataloader, which we can cleanly query to get the label per patch
Some things to keep in mind are:

The DataLoader should keep in mind that patch size is a hyperparameter that can vary. Patch size usually 8, 16, or 32.
The above labels currently are in the form of a boolean mask. Could we make this code more efficient?
Ideally, there is a function that takes the the patch number, and returns the labels for that patch returned as a list of strings.

picking up this issue

Picking up this issue!


Missing imagePullSecret configurations guidance for a developer in DEVELOPMENT.md doc

Now, I am deploying tekton-pipeline locally according to this guide: https://github.com/tektoncd/pipeline/blob/master/DEVELOPMENT.md#install-pipeline
I set up a kubernetes cluster and run ko apply -f config/ to deploy it. Everything looks good. But when I check tekton-pipelines-controller's status, it showed me below error:
failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized

So I create a secret for pulling image and add it to tekton-pipelines-controller and tekton-pipelines-webhook serviceAccount accordingly. Then everything is fine.
I am saying this because DEVELOPMENT.md doc is missing this guidance. It only tells us should configure authentication for pushing images:
Make sure to configure authentication for your KO_DOCKER_REPO if required.

But it doesn't tell us, we also need to configure authentication for pulling images. I think we should add this part to DEVELOPMENT.md part.
If my understanding is wrong, pls correct me. Thanks in advance!

@xiujuan95 hey 👋🏼 indeed, I think this is missing, mainly because, I think we tend to use public image repository by default, and thus imagePullSecret is not required. But yeah, it would be nice to add a little something in the doc about this.
/kind documentation

@xiujuan95 hey 👋🏼 indeed, I think this is missing, mainly because, I think we tend to use public image repository by default, and thus imagePullSecret is not required. But yeah, it would be nice to add a little something in the doc about this.
/kind documentation

@vdemeester Thanks for your attention! Maybe I will submit a PR about this later.

@vdemeester Thanks for your attention! Maybe I will submit a PR about this later.

@vdemeester PR is submitted: https://github.com/tektoncd/pipeline/pull/3699, please help review it, thanks a lot!

@vdemeester PR is submitted: https://github.com/tektoncd/pipeline/pull/3699, please help review it, thanks a lot!

PR is merged, I will close this issue, thanks!


Update Github issues template

What does this PR do?
Update Github issues template to contain app details.

Does your PR introduce any breaking changes? If yes, please list them.

Before submitting

[x] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[x] Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
[x] Did you list all the breaking changes introduced by this pull request?
[x] Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

also, do you think a bug_report template should be added for app?


Uncaught ReferenceError: dataHour is not defined

dataHour is not defined at time when the hour is 12 pm

I tried to reproduce this, but that was unsuccessfull.
Be sure you use the last version which is 2.7.1

How can I identify the current version

The undefined issue is not present now.. But see, the Hour 12 is not filled. Why is this.?
Once I click the 12, the fill appears

Same problem, i can't reproduce it.
Can you tell me which browser you are using, please ?

Android webkit... Implemented in a hybrid app developed using cordova.


⚠ ClamAV has degraded performance

In 49002e4, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 178 ms

Resolved: ClamAV performance has improved in 0675bbb.


Add '-emit-archive' option to mark modules as being part of static libraries

Following discussion here, this is a draft PR to add a -emit-archive option to Swift that controls the linkage of symbols within Swift modules (and potentially more in the future).
The core problem is that Windows needs different linkage – DLL import vs. default – for shared vs. static libraries. For Swift, cache whether a module is built as a static or shared library on a per-module basis, and use that to determine what linkage should be applied.
cc @compnerd

@jrose-apple

This isn't even really ready to look at - this cannot generate static libraries yet as clang does not know how to generate static libraries.

This isn't even really ready to look at - this cannot generate static libraries yet as clang does not know how to generate static libraries.

The main reasons I put this up were to make sure I was adding the flag in the right place, have the serialisation logic checked, and to have you look over the DLL storage changes.
In terms of generating static libraries, would the invocation ar crs outputLibraryName objectFiles... work on every platform? Additionally, do you think it'd be worth searching for llvm-ar and prioritising that, or just assuming the user has a sufficiently-modern ar tool installed?

Ish - that needs a bit of a tweak to be truly portable.  BSD uses a BSD style archive and you need to indicate that (as llvm-ar --format=bsd) and most others can do --format=gnu.  I believe that Darwin can get away with the BSD archive, though llvm-ar does have a special darwin format as well.  That said, if we do not find llvm-ar, we should fall back to ar which should be fine except when cross-compiling where the host is BSD (or a derivative cough Darwin cough) and the target is a non-BSD target or the inverse.  I think that searching explicitly for llvm-ar makes sense and should be relatively cheap.

I've updated the PR with a minimum-viable invocation of ar. It still needs tests, but I've tried locally and am able to successfully produce a static library.
If the implementation looks good, I'll make a start on tests – just want to make sure I'm not testing incorrect behaviour.

I think this is almost ready for tests (and splitting out the frontend parts into a separate PR). However, I'm still not sure about what we want to do for llvm-ar vs. ar vs. libtoolvs. lib.exe. The approach I'm thinking makes most sense is to just use each platform's default (ar for GenericUnix, libtool for Darwin, and lib.exe for Windows).
That has some issues for Linux/Windows <-> Darwin cross-compilation; however, since the Linux and Windows archive formats are apparently the same Linux <-> Windows should just work with the default linker. Not sure what to do about the Darwin case – we could maybe use llvm-ar as a fallback?

Let's worry about cross-compilation later. Using swiftc to link when cross-compiling for Darwin also assumes you have dsymutil if you're using debug info, not to mention an ld that supports Mach-O and -add_ast_path.

The driver portion of this PR has been extracted into https://github.com/apple/swift/pull/25202

@jrose-apple - dsymutil is now llvm-dsymutil which is present :-)

@jrose-apple - dsymutil is now llvm-dsymutil which is present :-)

It might be present. It's not installed by default, and I don't think we want it to be. Nor do I think we should automatically look for LLVM variants of tools; it'd be better to just allow overriding them in general.

Do we currently have a general way of overriding the tools? I'm only aware of -use-ld, which isn't exactly the same situation – for static libraries we need to find the archive tool ourselves, whereas -use-ld just passes its argument through to Clang.
I'm also perfectly happy (and would probably prefer) to just drop support from anything other than the system default tools in the PR rather than trying to scope-creep a more general solution.

Yeah, I was more talking about future expansion. I only care about the system tools. @compnerd, however, has been cultivating cross-compilation stacks for a while now, so I see the tendency to not box ourselves into a situation where we can't support cross-compilation.

FWIW swiftpm (llbuild) uses ar to create libraries. Should we change that to use libtool on macOS as mentioned above, or is ar an acceptable choice for here too? (Since this was discussed above)

Can one of the admins verify this patch?

@troughton Are you still pursuing this?

This is still necessary if we want to support static linking on Windows, but that's not something I've been actively pursuing recently, and the remainder of the patch (since https://github.com/apple/swift/pull/25202 was merged) is fairly minimal. I'm fine with this PR being closed if that's what you're checking.

Thanks. I can file an SR for somebody to finish this up of you’d like.

There's already https://bugs.swift.org/browse/SR-10797 filed, which was the main blocking piece of work. Once that's fixed (assuming it hasn't been already) I can revisit this patch, but I'll close it for now.


missing icons due to wrong svg content type

Issue Type: Bug
Try to set File Icon Theme to other than Seti (Visual Studio Code), and file icons will show no icons (or an empty tab space as icon). Also, somehow the root cause affected my 'Bookmarks' Extension which shows no icon.

I've downgraded VSCode to version 1.42, and the issue is not present there.
I'm pretty sure the issue is not related to VSCode version, as I have installed the latest version to another PC, and the issue is not present there.
I've also reinstalled VSCode as many as four or five times, deleting some tmp files from VSCode, but have not got rid of the issue.
VS Code version: Code 1.45.0 (d69a79b73808559a91206d73d7717ff5f798f23c, 2020-05-07T16:18:48.860Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz (8 x 1896)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.85GB (1.98GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (6)

Extension
Author (truncated)
Version

Bookmarks
ale
11.2.0

bracket-pair-colorizer
Coe
1.0.61

python
ms-
2020.4.76186

cpptools
ms-
0.28.0-insiders3

vscode-icons
vsc
10.1.1

srecord
xia
0.0.3

Maybe a dup of https://github.com/microsoft/vscode/issues/92323
From https://github.com/microsoft/vscode/issues/92323#issuecomment-611045838:
Can you check

open regedit.exe
search for svg
You should see Content Type image/svg+xml

Ok, saw #92323.

Looked for HKEY_CLASSES_ROOT\.svg
Found Content Type text/xml.
Replaced Content Type with image/svg+xml, as suggested.
The issue is gone.

Thank you, so much.!

@deepak1556 @sandy081 This issue has been reported several times.
Any chance we can force Electron to use 'our' content types? For VSCode as a application, there's no point of using a custom content types for svg images.

Yup we can, we already do something close enough to block svg images from remote urls https://github.com/microsoft/vscode/blob/master/src/vs/code/electron-main/window.ts#L404-L413 . We can modify the condition a bit for local urls and edit the content-type in onHeadersReceived. The headers received in this method are from network layer before they have reached the renderer, so any response modified here will only be used for further processing by the renderer.
if (details.url.indexOf('.svg') > 0) {
   const uri = URI.parse(details.url);
   // I assume the svg are currently served over file
  // If its vscode-resource, changing according to the scheme
   if (uri && uri.scheme.match(/file/i)) {
      responseHeaders['content-type'] = 'image/svg+xml'
      return callback({ cancel: false, ...responseHeaders });
   }
}

Triage: if this is indeed a dup of #92323, perhaps this issue can be closed?

@wmertens this issue tracks the solution to prevent svg being loaded with incorrect Content-Type headers.

I still see the issue in
Version: 1.53.0-insider (user setup) Commit: 5a52bc29d5e9bc419077552d336ea26d904299fa Date: 2021-01-29T05:13:48.533Z
Electron: 11.2.1
OS: Windows_NT x64 10.0.19042

open regedit, search for .svg, change image/svg+xml to text/xml
open code-insiders, switch to the minimal file icon theme -> file icons are empty

I still see the issue in
Version: 1.53.0-insider (user setup) Commit: 5a52bc29d5e9bc419077552d336ea26d904299fa Date: 2021-01-29T05:13:48.533Z
Electron: 11.2.1
OS: Windows_NT x64 10.0.19042

open regedit, search for .svg, change image/svg+xml to text/xml
open code-insiders, switch to the minimal file icon theme -> file icons are empty

/cc @rzhao271

/cc @rzhao271

I have an issue that looks similar with VSCode 1.53.2 on Ubuntu 20.04: the SVG icons I use in an extension, on both tree view items and inside webviews, don't show.
Their PNG equivalents show, so it seems that SVG is specifically blocked (confirmed by the Webview Development Tools that show a download size of "0 B" for the SVG).
Could it be related, or shall I open another ticket?

Hi guys, can someone point me to a similar fix on mac. I have this issue with my docker extension. thanks

The current mitigation is https://github.com/microsoft/vscode/issues/97564#issuecomment-627351149
I used those steps to intentionally change the type back to text/xml, and I noticed that the issue still repros.


Addition of two new assert functions for better validation of different integer types

To complete the integer checks, nonNegativeInteger and negativeInteger checks have been added.
This PR belongs to the ticket https://github.com/webmozarts/assert/issues/296

I guess you are missing a positiveInteger check?

@loevgaard that one exists already

@loevgaard sorry, I think the naming is poorly chosen. Maybe it is wise to rename the nonNegativeInteger to unsignedInteger, because it should only be checked if the value is 0 or higher.
What do you think?

@loevgaard that one exists already

Didn't know that :)

@loevgaard sorry, I think the naming is poorly chosen. Maybe it is wise to rename the nonNegativeInteger to unsignedInteger, because it should only be checked if the value is 0 or higher. What do you think?

I think nonNegativeInteger is the way to go because that's what's used in other places, .e.g https://psalm.dev/docs/annotating_code/type_syntax/scalar_types/

@loevgaard @loevgaard The psalm was the motivation to write this pull request. I think it would be great if this missing implementation could be added to make such checks so that Psalm understands the variables correctly:

/**
* @psalm-param non-negative-int $age
*/
public function __construct(private readonly $age)
{
}

public static function create(int $age): self
{
      Assert::nonNegativeInteger($age);

      return new self($age);
}

/**
* @psalm-return non-negative-int
*/
public function getAge(): int
{
      return $this->age;
}

Yeah, exactly. Makes a lot of sense :)


Update README.md

Required some reading to find out how to get to the console :-)
I'm a newbie with this OSGI thing.

awesome, thanks for the contribution!


HTML Tags get removed while requesting money but not while sending money

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Request money from a user and enter   as the message
Notice that the tags are automatically removed
Now, send money to a user and enter   as the message
Notice that the tags are not automatically removed

Expected Result
The tags should be removed
##Actual Result
The tags are not removed
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.2.72-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/219442757-b4eef27d-a738-401b-bba7-94ed84ee8476.mp4
https://user-images.githubusercontent.com/43996225/219442814-4cfd65a8-d098-4c0c-85f9-4160b1fa4190.mov
Expensify/Expensify Issue URL:
Issue reported by: @esh-g
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1676492524133929
View all open jobs on GitHub

Triggered auto assignment to @maddylewis (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Should probably just be rolled into https://github.com/Expensify/App/issues/14610 where we are holistically fixing these? cc @ctkochan22

@ctkochan22 - should this be rolled into - https://github.com/Expensify/App/issues/14610 ?

Yes, I think so. Going to handle it (discussion/implementation) in https://github.com/Expensify/App/issues/14610 . Can we just close this out since this was already a known issue at the time of the reporting?

Oh whoops. Its actually a little different. Same vein, but different solution. I think here, we need to probably apply the same validation or inputRules as we do for requesting notes

Asking in original slack thread whether it is specific to android. The html seem to be stripped when testing both ways in web

Okay, so the html is being stripped even from android. The reason why it doesn't disappear is more on how we handle onyx data I believe

We show the html embedded originally because we don't validate for html tags or anything and place that in the optimistic response. So we show something as paid or requested, before we know it succeeded. Then we wait to update what we have with the server response.
For some reason, the report action for when we send money does not get updated by the server because its caught by Front-end filtered out reportAction keyed by sequenceNumber! -. This is something I need to investigate further

PR here: https://github.com/Expensify/Web-Expensify/pull/36554

Fixed, PR is merged. Should be on prod this week

@ctkochan22, @maddylewis Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

@ctkochan22, @maddylewis Whoops! This issue is 2 days overdue. Let's get this updated quick!

@ctkochan22, @maddylewis Huh... This is 4 days overdue. Who can take care of this?

this is complete! https://github.com/Expensify/Web-Expensify/pull/36554#issuecomment-1451003419

https://expensify.slack.com/archives/C01GTK53T8Q/p1678457363664279

eligible for reporting bonus - https://expensify.slack.com/archives/C049HHMV9SM/p1676492524133929

@esh-g - can you apply to the job here so that i can process payment for the reporting bonus? thanks!
https://www.upwork.com/jobs/~010428e90c397da96c

paid!


TextField hide error icon

Which platform(s) does your issue occur on?

Android

Please, tell us how to recreate the issue in as much detail as possible.
I using TextField with validation message via prop:  :error="error"
Is any way to hide error icon on right side of TextField?

@wesoly935 not implemented yet. PR are welcome


Doesn't work in Chrome 71+

If you open the page in Chrome 71 or newer, it displays a blank rectangle with a Stop/Start button. Clicking the button, even multiple times, doesn't do anything.
The DevTools console displays a warning:

The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. https://goo.gl/7K7WLu

The URL linked at the end of the message explains the issue. tl;dr is included in one box:

Key Point: If an AudioContext is created prior to the document receiving a user gesture, it will be created in the "suspended" state, and you will need to call resume() after a user gesture is received.

This is a measure preventing websites from playing potentially unwanted audio, as I understand.
Tested on macOS 10.13.6 (17G4015) but the issue should be present on all operating systems.

+1. Same for me on Ubuntu 18.04: Visiting http://reactmusic.surge.sh/ I can see the same warning in the console, empty square on the screen, and no music in Chromium Version 73.
But in Firefox it works.

I am exploring react and decided to take a stab at fixing this in Chrome.  I'm sure there are better ways to address this, but I got it working with changes to handlePlayToggle in demo.js:
`  handlePlayToggle() {
this.setState({
playing: !this.state.playing,
});
if (this.state.playing) {
	console.log('audio state playing');
	if (this.audioCtx == undefined) {
		var audioCtx = (window.AudioContext || window.webkitAudioContext);
		this.audioCtx = new audioCtx();
	}
	this.audioCtx.resume();
} else { //state.playing
	console.log('audio state not playing');
  if (this.audioCtx == undefined) {
  	var audioCtx = (window.AudioContext || window.webkitAudioContext);
	  	this.audioCtx = new audioCtx();
	}
	this.audioCtx.suspend();
} //state.playing

}`
Now I can have some fun with this.

Well,
Apologies as it seemed to be working, but I think it was just a fluke. A better answer is modifying song.js:
  componentDidUpdate(prevProps: Object, prevState: Object) {     if (prevState.buffersLoaded !== this.state.buffersLoaded ||       prevProps.playing !== this.props.playing) {       if (this.state.buffersLoaded === true && this.props.playing === true) {         setTimeout(() => {           this.scheduler.start(this.loop); 	this.audioContext.resume();	\\<==add this to make play work         }, 0);       } else {         this.scheduler.stop(true); 	this.audioContext.suspend();  \\<==add this to stop an error       }     }   }
I ran into other issues  like the Play/Stop button label  being reversed, and not knowing react, I came up with what I am sure is the wrong way to do it, but it works for me. There is definitely some weirdness in the demo constructor in setting state as it seemed to be always reinitializing the state of things after the toggle call.
and so, I added these tests:
     this.state = {       playing: true,       lightMode: true,     }; //+++++++++ added these 	if (this.state.showPlay == undefined) { 		console.log('setting showPlay');     		this.state = {       		showPlay: true,	     	}; } 	if (this.state.lightMode == undefined) {  //a react error was thrown on load if you changed lightmode without first playing. 		console.log('setting lightMode');     		this.state = {       		lightMode: true,	     	}; }
I modified handlePlayToggle to handle the new variable for the button:
  handlePlayToggle() {        this.setState({       playing: !this.state.playing,       showPlay: !this.state.showPlay, 	}); 	console.log('showPlay is '+this.state.showPlay);   } //handleplaytoggle
last change was to the button:
 {this.state.showPlay ? 'Play' : 'Stop'}
This seems to be working reliably in Chrome now and seems to work in Firefox too. But again, I don't know react and just want to use this to play with music.


feat: delete insight page

What type of PR is this? (check all applicable)

[x] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Description
This PR adds the ability to delete the insight page. Once the user clicks on the button "delete page" a confirmation modal will appear and ask the user to write DELETE in order to confirm the deletion.

Related Tickets & Documents
Fixes #853

Mobile & Desktop Screenshots/Recordings

Added tests?

[ ] 👍 yes
[ ] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[ ] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

Thanks @shamimbinnur. Would love to see this PR as a Highlight

@bdougie I just did it!


Support for translations?

Hi!
First of all, congrats for a great program.
I want to ask if there are some plan to add a feature for easily translate to other languages.
Probably is not needed, because you can create your own scripts with your own responses, but at least the program language.
What do you think?
Thanks in advance

I didn't build EDDI with translations in mind, mainly because it started out being a pure VoiceAttack plugin and so didn't have any external UI.  Now that it has one some localisation would be nice, but I don't have the time to add localisation ability in any time soon.  Pull requests are always welcome!

Ok, no problem, is more a secondary feature, probably I can help in the future, but now I'm really busy in my work.
Thanks for the answer.


GnuPG 2.0

Estimated time: [10]m

(Got an error while following MN installation guide. At the Install Docker Repositories paragraph)
What:
After sending the command
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
I got the following error:

gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory

Solution: User should install GnuPG 2.0 when it's not on system yet with following command
sudo apt-get install gnupg2
Maybe this exception could be added to the guide for others that are setting up a MN.

If you do take https://github.com/tomochain/docs/issues/157 , please incorporate that change too, thanks!


Typesetting module Unit tests

Unit tests for the typesetting module are needed (Converter, ...)

Does not make sense right now as changes are to be expected a lot. Simply not feasible right now in my opinion.


Note about the VPN in the README

Adds VPN to the steps.

Gonna close this actually as an upcoming PR will deprecate


Update README documentation

Update README documentation
In this PR, I have updated the documentation to include more relevant information and information on how the TIFF files are named after being extracted from the nd2 files. Solves issue #6.

@MikeLippincott Thank you for the review and feedback! I will be merging now!


Better errors on import failure

We override the Type traitlet to provide a better error message on
import error, and raise nice error messages for cluster managers that
have extra dependencies.
Fixes #58.

👍


Bolt12 dev environment

Description
This solves the first point of https://github.com/stackernews/stacker.news/issues/1317 by adding an eclair node as receiver and lndk as sender.
Additional Context
Before deciding to use Eclair, I tried various configurations with CLN as the receiver, connected directly to LND and also with a CLN or LND routing node in between. I couldn’t get it to work reliably with those setups. Eclair, however, worked pretty much out of the box after making a few changes to the bitcoind configuration.
Testing
$ bash sndev cli eclair tipjarshowoffer
<OFFER>

$ bash sndev cli sn_lndk get-invoice <OFFER> 10000
<INVOICE>

$ bash sndev cli sn_lndk pay-invoice <INVOICE-HEX> 10000

The changes I made:

moved eclair, lndk, and cln to wallets docker compose profile which seemed more fitting (and downloads/builds for lndk and eclair are pretty slow)
specified x86 platform for lndk (no build support for arm on linux)
fixed lndk port conflict with router_lnd


TypeError undefined is not an object (evaluating 'f.fetch[this._fetchKey]')

Versions

nuxt: 2.14.7
node: 12.16.1

Steps to reproduce
Bug is intermittent, I personally cannot reproduce on an emulated device.

Site is built with ssr: true and target: 'static'
fetchKey is not set
fetchOnServer: true
fetch is a function that returns a Promise

Only occurs on this page and only on Safari 14.0.1 or higher (seeing 87% of occurrences on 14.0.3).  Seeing on iOS 14.4 mostly.
What is Expected?
The error not to occur
What is actually happening?
An error is thrown during hydration
TypeError undefined is not an object (evaluating 'f.fetch[this._fetchKey]')
    https://www.carbmanager.com/_nuxt/f7c09ed.js:2:904036 d
    https://www.carbmanager.com/_nuxt/6413c5a.js:2:14962 Vt
    https://www.carbmanager.com/_nuxt/6413c5a.js:2:28812 Qe

@danielroe still happens after upgrade to 2.15.5.  I don't have a replication unfortunately.  What information can I provide to you to help you diagnose the issue?

Hey @jonpreececm, did you ever find a solution for this?


Allow select cases to be numbers (#116625)

(cherry picked from commit 583a8122bc895208da53d2a5728255450537a5ae)
As a pre-cp of #120678 suggested at https://github.com/flutter/flutter/pull/120678#issuecomment-1432016460.
Pre-launch Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I signed the CLA.
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

LGTM but just to make sure, cherry-picking the other commit on top of this one works without merge conflicts?

I'm not sure I can fully understand your purpose, but after this has landed, we can rebase another request so it won't have conflicts then.

@thkim1011 You'll need to approve the request issue too. :)


React API must be now required from react package

#35 with the pull request, should be able to upgrade react-native to version 0.25.0. Tested on both iOS and Android.

Thx for this PR
:+1:


Support OpenDroneMap

I wonder if you would consider eventually adding support for OpenDroneMap reconstructions. This could be useful for users aiming to build an entirely open-source workflow.
ODM internally uses OpenSfM for photogrammetry. OpenSfM saves reconstruction data (e.g., estimated camera locations and orientations) in a file reconstruction.json.
Thanks for considering, and thanks again for making and supporting this excellent software!

We do have the plan, but currently no more attention could be paid on it before fully supporting for all metashape features/issues listed here.
(and still need some time waiting for the optimization of ODM)


genreconciler: successful finalization breaks status updates

/area API
/kind bug
This is a largely superficial issue, which I only noticed because of some unit testing I was writing and trying to explain this odd behavior.
Expected Behavior
If in FinalizeKind a resource is marked Ready, and nil is returned, then we see both updates (path for finalizer, update status for Ready).
Actual Behavior
Instead the finalizer is removed and the status is NOT updated.
The bug
Using Deployment as an example...  If in FinalizeKind we update status and return nil then we will call through here:
https://github.com/knative/pkg/blob/bfab3c8fc5a0a3f725aa0e3478631384ec97d43c/client/injection/kube/reconciler/apps/v1beta1/deployment/reconciler.go#L242-L244
This function uses the input resource (with the updated status) to access the finalizers, find ours and remove it:
https://github.com/knative/pkg/blob/bfab3c8fc5a0a3f725aa0e3478631384ec97d43c/client/injection/kube/reconciler/apps/v1beta1/deployment/reconciler.go#L438-L441
The resource we pass in is used to compute a PATCH on the finalizers specifically:
https://github.com/knative/pkg/blob/bfab3c8fc5a0a3f725aa0e3478631384ec97d43c/client/injection/kube/reconciler/apps/v1beta1/deployment/reconciler.go#L373-L378
However, any other mutations (e.g. our status update) are ignored here.  This is a problem because the resource that is returned by this function is the updated copy that is returned by the PATCH which does not have our status update reflected:
https://github.com/knative/pkg/blob/bfab3c8fc5a0a3f725aa0e3478631384ec97d43c/client/injection/kube/reconciler/apps/v1beta1/deployment/reconciler.go#L388-L396

I think the best "fix" for this would be to not return updated directly, but to reflect its resourceVersion change back to resource and return that so the status is preserved.

cc @dprotaso @n3wscott

/lifecycle frozen


feat: support multiple queries, export functions

Description
This PR provides the ability to update multiple queries in the cache when a mutation is run.
It also exports valuable functions the client may want to use without using the full cache helper function.
Checklist

[x] npm test passes
[x] npm run build works
[x] tests are included
[ ] documentation is changed or added

Great work!


add basic folder operations to tree

adds SetFolder and AddTombstone operations
to the drive delta tree.

Does this PR need a docs update or release note?

[x] :no_entry: No

Type of change

[x] :sunflower: Feature

Issue(s)

#4689

Test Plan

[x] :zap: Unit test

@ashmrtn pushed a fairly significant rework to update this code to the latest graph behavior discoveries, and the assumption of a multi-enumeration backup.  Could I get a re-review, please?


Release messages from internal buffer when there is no active receive call

Take the below scenario:

ServiceBusReceiver.receive_messages() is used to ask for 100 messages, but only 30 came over the wire before timeout. We give these 30 messages to the caller.
40 messages come over the wire before the next call to receive_messages

If there is too much of a gap between the two calls to receive_messages then these 40 messages will be expired. Due to this the caller will get the lock lost error when settling these messages and will get the same messages again.
This is an expected loss if the user has chosen to use prefetch. But in the absence of prefetch, the client should not be holding on to messages if there are no receive calls from the user.
This feature request is to release such messages which will not affect the delivery count either.

I've done some initial testing here.
Our Python SDK design is slightly different to the .NET/Java SDK designs where prefetch is achieved via a background thread.
In the Python single-threaded design, extra messages can be received outside the context of the receive_messages call in the following circumstances:

The link credit on the link is set according to the max_message_count value.
Not all the messages allowed by the credit value are received at once (meaning there's extra credit pending on the connection)
The connection is then used outside of the receive_messages context, e.g. for different operations like sending, renewing tokens, sending empty keep-alive frames etc.

This can allow that remaining link credit to be used up receiving extra messages that will then sit in the buffer until the next time receive_messages is called, and they will potentially be expired.
One possible solution for this would be to, if prefetch=0, set the handler._on_message_received_callback to function capable of releasing incoming messages when not in a receiving context.

my investigation based on @annatisch 's approach:

message releasing only works when the message lock hasn't been expired yet. release message after lock expiration still increases the delivery count.
messages could arrive at socket when the client is not active.
those messages will stay in the socket unable to be handled until there're method calls (e.g. receive) triggering the transport layer to consume bytes from socket, it is until that moment that we are able to deal with messages.

as a fix, we could have a background task which keeps listening on the socket and consume messages, we release messages when messages not arriving in a receive context.
in my draft pr, I overload the keep-alive thread to listen on socket periodically, however, it may not be a best practice as

we violate single responsibility principle
we increase cpu workload with shorter checking interval


Implement support for insertion into Kafka tables

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
For changelog. Remove if this is non-significant change.
Category (leave one):

New Feature

Short description (up to few sentences):
DO NOT MERGE!

Should implement #5834

Part with output formats seems ok.
Probably, it is worth to add general settings class RowOutputFormatParams the same as RowInputFormatParams. Then next time you won't need to change every constructor in order to add new setting.

Probably, it is worth to add general settings class RowOutputFormatParams the same as RowInputFormatParams.

Don't see any reason to do it now - there is a single param.