text:
operator [O] multicluster-global-hub-operator (0.7.0-dev)

Thanks for submitting your Operator. Please check the below list before you create your Pull Request.
Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[x] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[x] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description of the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

allow/serious-changes-to-existing

/unhold

/merge possible

/merge possible

authors: framework-automation morvencao mvalarh


text:
Documentation and setup improvements

This change includes a number of things:

General reorganization
More onboarding content with specific instructions
More linking between docs/sections to improve navigation
A script to easily copy a bundle for testing
Redirection for non-developers
Flow and grammar fixes

@wcheang I resolved/commented on all your suggestions. Please take another look.

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
Bundle install is fetching version 0.0.0

Fetching redis-sinatra 0.0.0
Installing redis-sinatra 0.0.0

Just released v1.4.2 and this seems to be resolved:
Fetching gem metadata from https://rubygems.org/..........
Resolving dependencies...
Using bundler 1.16.1
Using mustermann 1.0.3
Using rack 2.0.5
Using redis 4.0.2
Using tilt 2.0.8
Using rack-protection 2.0.3
Using redis-store 1.5.0
Using sinatra 2.0.3
Fetching redis-sinatra 1.4.2 (was 0.0.0)
Installing redis-sinatra 1.4.2 (was 0.0.0)
Bundle updated!

source: gharchive/issue

repo: redis-store/redis-sinatra

license: mit

license_source: bigquery


text:
async callback functions

I have a question re. the hiredis async library.   In particular the callback function associated with a redisAsyncCommand command.   I am doing the following in my application.
// Get a redis async connection
_redidContext =   redisAsyncConnect(“127.0.0.1”)
//Executes a redis “subscribe” command and specifies a callback function “subCallback” defined //elsewhere in the application
Status =   redisAsyncCommand(_redisContext, subCallback, (char*)”sub”, command.c_str());
I'm using the libEvent library to listen for messages published to a redis channel.  When they occur the callback function is executed.  My main question is "Does the callback function run in a separate thread or does it execute within the main thread of execution?"  My concern is that hiredis or libevent will create a new thread for this callback that executes concurrently with the application's main execution thread. Thus introducing possible concurrent processing problems.
The hiredis readme.md file reads Note: A redisAsyncContext is not thread-safe.   Maybe you could explain in a little more detail what is meant by this statement. But my understanding of this is if you have a multi-threaded application you cannot use a single  redis connection with more than one thread and be assured exclusive access at any one time to redis data by a single thread of execution.   My application is single threaded so I don’t expect this is a concern for me.   But maybe you could you confirm this for me?
Thank you,   Paul Barry

I haven't done much work with async hiredis but it is my understanding that everything will run on one thread unless you explicitely create the event loop in a different thread.
Take for example, this quick and dirty program:
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <hiredis/hiredis.h>
#include <hiredis/async.h>
#include <hiredis/adapters/libevent.h>

void subscribeCallback(redisAsyncContext *c, void *r, void *privdata) {
    redisReply *reply = r;
    if (reply && reply->type == REDIS_REPLY_ARRAY) {
        for (int i = 0; i < reply->elements; i++) {
            printf("reply->element[i] = ");
            switch (reply->element[i]->type) {
                case REDIS_REPLY_STRING:
                    printf("%s\n", reply->element[i]->str);
                    break;
                case REDIS_REPLY_INTEGER:
                    printf("%lld\n", reply->element[i]->integer);
                    break;
                default:
                    printf("OTHER TYPE (not handled)\n");
            }
        }
    }
}

int main (int argc, char **argv) {
    signal(SIGPIPE, SIG_IGN);
    struct event_base *base = event_base_new();

    printf("Our PID is: %d\n", getpid());

    redisAsyncContext *c = redisAsyncConnect("127.0.0.1", 6379);

    redisLibeventAttach(c,base);
    redisAsyncCommand(c, subscribeCallback, NULL, "SUBSCRIBE %s", "foo");
    event_base_dispatch(base);
    return 0;
}

This works to print published messages, and I only see a single thread:
➜  examples git:(master) ✗ ./asyncsubscribe
Our PID is: 696
reply->element[i] = subscribe
reply->element[i] = foo
reply->element[i] = 1

➜  ~ ps huH 696
mike       696  0.0  0.0  11180  1036 pts/4    S+   10:02   0:00 ./asyncsubscribe
➜  ~ ls /proc/696/task
696

thanks,
So the pid for the main thread is 696.  I don't see how this shows that the callback executes within the same thread though.  Shouldn't you also execute getpid() within the callback function to see if it's the same?

The PID and TID (thread id) are the same in main() and subscribeCallback().  You can check for yourself with this modified example.
Our PID is: 5751, TID: 5751
Callback PID: 5751, TID: 5751
reply->element[i] = subscribe
reply->element[i] = foo
reply->element[i] = 1

It would be highly inefficient for libevent to spawn a new thread per callback invocation.  That would defeat the whole purpose of an event loop! :smile:

repo: redis/hiredis


text:
Redis sentinals with a kubernetes clusterIP serivice?

I'm using the following redis operator for kubernetes: https://github.com/spotahome/redis-operator
The operator creates redis instances, sentinals and a ClusterIP service that load balances between the sentinals. Is it possible to connect to the sentinals through the service using the ioredis library?

When I do the following:
const redis = new Redis({
  sentinels: [
    { host: "rfs-redis", port: 26379 }
  ],
  name: "mymaster",
});

redis.set("foo", "bar");

I get:
[ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1247:16)
[ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1247:16)
[ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1247:16

In fact if I try to directly connect to the sentinals:
const redis = new Redis({
  sentinels: [
	{ host: "10.244.0.76", port:26379 },
	{ host: "10.244.0.77", port:26379 },
  ],
  name: "mymaster",
});

redis.set("foo", "bar");

I get the same:
[ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1247:16)
[ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1247:16)
MaxRetriesPerRequestError: Reached the max retries per request limit (which is 20). Refer to "maxRetriesPerRequest" option for details.
    at Socket.<anonymous> (/code/node_modules/ioredis/built/redis/event_handler.js:182:37)
    at Object.onceWrapper (node:events:628:26)
    at Socket.emit (node:events:513:28)
    at TCP.<anonymous> (node:net:757:14)
[ERROR] 16:32:03 MaxRetriesPerRequestError: Reached the max retries per request limit (which is 20). Refer to "maxRetriesPerRequest" option for details.

I'm a bit confused as it tries to connect to 127.0.0.1, i.e. localhost.
Next I'll try to connect using the redis-cli
> redis-cli -h rfs-redis -p 26379
rfs-redis:26379> SENTINEL get-master-addr-by-name mymaster
1) "10.244.0.22"
2) "6379"
rfs-redis:26379> rfs-redis:26379> exit
> redis-cli -h 10.244.0.22 -p 6379
10.244.0.22:6379> SET test "TEST"
OK

So I can connect using the redis-cli, but for some reason ioredis fails.

I have some problem，I connect redis with sentinel  ，why connect redis localhost

repo: redis/ioredis

license: MIT


text:
Fundamental API design flaw -- with respect to encoding and serialization

Expected behavior
The stated purpose of the library behaves as documented and expected -- i.e. users should not need to be aware of implementation and it should "just work".   One stated goal/priority for reddison is that users can use existing or new java classes 'As Is' and simply use reddison as a transparent native object database.   This is a very compelling feature (which has been attempted many times over the last 30+ years).  Considering the maturity and feature rich nature of the product I nievely assumed that this would 'just work' as intended (of course accepting some edge cases that are problematic.)
In particular, with the variety of codecs, including Jackson -- which is if not the single most used JSON data mapper/serialization library, atleast in the top 3, that if a class could round-trip serialize with Jackson that class would be equally usable with Reddison -- this is explicitly stated (with some caveots).
By leveraging the work of existing encoders (like jackson) it is natural to assume that this is not magic -- it would work 'as good as' whatever encoder was configured, so if one has domain knowlege in that encoder and has created classes which behave nicely with that encoder then Reddison would indeed be a transparent 'Drop In' -- and be able to use the the other really awesome features provided.
Actual behavior
It simply does not work this way, and can not work as stated with the existing APIs.
I believe this is due to a fundamental difference in how various encoders/codecs work, and not fully understanding the subtleties.   Some encoders work by always storing the type information with data so that deserialization is possible from the data alone with no external context or special per-instance configuration.    Other encoders (such as Jackson) prioritize round trip to user controllable serialization formats.   The concept being that the codec can be configured such that the output (JSON in this case) is produced in a form that either pre-exists (must be matched exactly) or 'user friendly' (intentionally undefined -- but again, assumed to exist and must be matched).
To achieve this, the default mode, and in fact almost all features of Jackson are designed to NOT embed type into the JSON data itself, but rather to make use of the serialization or deserialization dynamic context (and other out-of-band configurations) to be able to parse 'arbitrary' JSON 'as is' into the expect type.   This is fundamentally different approach and goals then codecs which produce 'black box' output and instead focus on minimal or no out-of-band context needed to round trip Java objects.
The side effect is that in order for Jackson to function properly (i.e. in the use cases it was primarily designed for), type information MUST be provided out-of-band in order to deserialize.
The exception, which is not commonly used, and which recently has been shown to be a severe security problem,  is the special mode of embedding type information with each JSON element.
These modes are not interchangeable and have non-compatible requirements, and in general are 'all or nothing' -- you must code for one or the other mode explicitly and consistently.
The current Reddison APIs cannot handle either mode correctly in many cases.  For example, RBucket, without extreme hacks, cannot round trip most non-primitive objects -- even basic Java Bean or POJO.
This is NOT solvable by simply overriding the codec and tweaking it somehow -- because internally, in intentionally non-exposed implementation code, the necessary usage of the core Jackson APIs are incorrect and inconsistent in at least a few places.   The default Jackson codec uses a non-standard configuration of the ObjectMapper which is not able to round-trip consistently given the implementation of the deserializer (which in many places pasess a literal Object.class as the target type)
I have found that it is possible to hack this on a case by case basis by 'creative' (i.e. probably will break many other things) mangling of the codecs -- on a per use basis -- It still requires every API call to use a distinct codec taylored for the type,  and I have no idea what will happen with nested RObjects -- or other internal code -- What this demonstrates, in my opinion, is that the API itself needs to be enhanced slightly to accommodate the behaviour of codecs which need out of bound type information,
not by making this a burden on the users -- particularly since this relies on understanding many details of the private implementation of Reddison to work -- with no assurance that ones understanding is fully correct or that the undocumented internal implementation will not change.
This essentially makes Reddison unsuitable for large classes of its intended use cases.  That is sad, as I was looking forward to making use of the AWESOME features it does provide -- to be blocked by a few fundamental API flaws.
Recomendation:
Solving this problem is not complex, but it cannot be done cleanly by end users, it needs to be implemented internally and exposed through the APIs.
There are various other products which do this exact thing that can be used as a model for what is needed.
Essentially -- every API which deserializes a user defined object MUST have some mechanism of providing the target class explicitly.   For example:  Jackson itself has a Class argument for every method which does deserialization.   This is not just an 'advanced' feature, its necessary for all but a few special cases.
cache2k https://cache2k.org/  solves the problem by making use of a rarely known, subtle feature of Java which provides a way to prevent type erasure of generics.   E.g.
  Cache<String,String> cache = new Cache2kBuilder<String, String>() {}
This subtle 'trick' of creating a anonymous type explicitly (note the "{}" at the end -- critical), allows the cache to access the generic parameter types and use them later as needed for deserialization.
Using the first suggestion, I believe all it would take to make RBucket.get() to work properly is to add the class argument to get  (   RBucket.get( Type.class ) )
Yes this is ugly and yes this breaks some of the simplicity of implementing interfaces that do not have this signature -- but at least it works reliably and doesn't require the end user to have deep domain knowledge of both the codecs and reddison to handle basic simple java classes as the framework is designed to do.   This would have to be done likewise to all the methods which deserialize top level objects.   Once the top level class is properly deserialized, all its internal references will work fine (if you allow Jackson to do it for you)  -- Jackson will use the declared type of the parents reference variable to deserialize the children.   All the subtleties of how to get this to work are then defered to jackson and whatever customization one needs to do via annotations and configurations are all Jackson problems.
That way you could truly state that "If a class round trips through Jackson using the provided ObjectMapper then Reddison will work correctly for that class without changes or custom configurations needed"
I do not know the extent this affects internal code -- this is why I am not attempting to implement this as a PR -- I suspect that I would need to fully understand all the intricacies of Reddison to make sure I got all the cases correct -- I believe the author is the best source of this domain knowledge.   By the time I fully understood all the code enough to make this change, I would probably end up writing my own version -- which is exactly what I did NOT want to do when I discovered Redisson.
Note that these suggested approaches are NOT simply having the user customizing the codec -- the codec is not the right place to store per-type per-use information, that needs to come from the callsite directly, either in the creation of the R or in its methods -- One could still store the necessary class information in the codec as is done in the JsonJacksonMapCodec -- but 'hide' this from the user -- that is an implementation choice.
For JVM Languages which handle generics 'better' , such as Kotlin, one could write a wrapper around Reddison to provide the simpilier APIs and manage the explicit class arguments in the wrapper.
This is what the Jackson Kotlin module does
https://github.com/FasterXML/jackson-module-kotlin
Most of this module is a single source file that provides 'extension functions' which convert the generic template types into explicit class types to pass to Jackson.
E.g.
inline fun <reified T> ObjectMapper.readValue(src: File): T = readValue(src, jacksonTypeRef<T>())
This extension function exposes the intended user experience of
    val myclass = mapper.readValue<MyClass>(File("file.json"))
and under-the-hood converts this to roughly
   mapper.readValue( File , MyClass.class )
This is not possible in pure Java, which is why cache2k uses its subtle 'trick' during the cache creation to extract the generics class types.
Note: that the problem exists in Reddison even without user supplied classes begin generic/templates --
this is an issue with even basic POJO type classes with no inheritance, generics, or other 'advanced' features -- Reddison simply does not supply the API's necessary to deserialize these properly using codecs like Jackson which require out of band (or context provided) type information.
You just cant get there from here ...
Note: I was very surprised that such a simple use case failed -- until I checked the test cases in the examples and all of them which would have triggered these problems were using basic types (String, Int, Long) not custom classes.  Those types do not need any out of band type information so they do work just fine.   Similarly, the Reference class handles this problem in its own way (and may in fact be unnecessary if the above suggestions are implemented -- not sure)
Steps to reproduce or test case
Redis version
Redisson version
Redisson configuration

FSTCodec is used by default now. It solves such problem.

The largest mistake made by the writers of Redisson is try to implement java.util Map, List, ... interfaces rather than supply their own. There is plenty of methods that are supposed to work in a certain way according to java.lang such as the compute method on ConcurrentHashMap but is not properly implemented in Redisson.
Also, the iterators of a Map, for instance map.getEntries() simply uses the value and makes no round trip to redis server. This is in contract with how map.get(key) works, meaning the iterator is not concurrently safe, and should not be used but rather you should iterate keys and get the value yourself.
There are tons of similar usecases, as well as poor documentation overall on how things are supposed to work and what you can expect.
Main issue is trying to match the java api for all kinds of collections and objects rather than provide 100% bullet proof and limited ones themselves.
Also, having to name everything is not particularly great. If you have a map that contains keys to other Rmap or Rlist, you need to provide the key to the new values as well. What happens when you remove the key from first map? No body knows, but likely the value will continue to linger and pollute the redis database having no reference at all to it. So you need to do those things as well.
I would not recommend this library to anyone, or Redis for that matter. Serialization defaults to using Serializable required jboss. If you use Jackson, it can not handle cyclic references, while google GSON can. About to write a codec but that interface is massive. Not a fun job. Also everything is interface based and this makes little sense and makes everything harder to navigate.  No body will ever write another implementation of this API as the problem is the API itself.

Thank you for your feedback!

map.getEntries() simply uses the value and makes no round trip to redis server

I'm afraid you're mistaken, it uses Redis HSCAN command and not any local state of RMap object.

how things are supposed to work and what you can expect.

All Redisson objects excluding Local Cached Map are stateless and store state in Redis.

What happens when you remove the key from first map? No body knows, but likely the value will continue to linger and pollute the redis database having no reference at all to it. So you need to do those things as well.

If you remove key mapped to value as reference to other RMap or RList object then you need to delete these objects separtely, since cascade deleting is not supported in this case.

java.io.NotSerializableException:
java.io.NotSerializableException: org.redisson.RedissonMap
org.redisson.RedissonAtomicLong
wether with Jackson, Gson or Jboss.
I can't include these things in a wrapper class or instance? Jeezus. The limitations are tremendous. at least I would have figured I could serialize these things. Is it because of the ReddisonClient?
How are we supposed to create logic containing various things? Only singular values? I am lost as to how one should use this library.
I figured you could use an RList with an RMap for values, I don't see why I can't use them in a class. Am I required to setup a bunch of serialization logic for this to work?

RMap, RAtomicLong are wrappers around structures already stored in Redis.  You can't serialize them since you don't access to RedissonClient.

I can think of ways of circumventing that limitations. Several ways. ThreadLocal being one way. Another is through getters and setters and forcing the extending of RMap to get the client. But threadlocal is the way.
In fact, I decided a few hours (shortly after this message) ago to move on to Jedis and already implemented a serializer for a map and others, and what not that can do exactly this, and without having to have an instance of a client.
I figured this kind of things would be a given in such a giant library. Like declaring instance variables. I think you started with the wrong notion of trying to match the java util package and it backfired down the line. You also focus on given all kinds of options, such as the ability to serialize in 100 ways, rather than just rely on ONE option that sets the standard for how things should work even if that would have meant writing your own serializer. The serializer could have for instance provided the redisclient or through threadlocal.
Anyhow, I don't see how I can use this if my understanding of it are correct. I have not tried liveobjects, which is also a way, but I don't see why you would need the annotation of @REntity or @RClient on your own RMap, RList and what not. When the serializer encounters a RMap, it should replace it with a reference and when it reads it from redis it should fetch it from redis and create a copy of the previous RMap. I think you do that with live object surely, but why not living up your own collections? Would involve a rewrite? Too much work.
I am sure I am complaining too much, but I've spent a week on this and just keep hitting wall after wall, limitation after limitation.
Jedis gives me the oppurtonity to be in full control and your Redisson library while i think you are a genius indeed grew the scope of the project way too much. You should have focused on prodiving a copy of hibernate for redis. Meaning everything is managed and not neccessarily be limited of the various serializers that "automatically" will do stuff for you, while at the same time limiting you of that you can do, including initiating the classes and settting their property.
I am sure I am wrong but I am pretty sure I give up now. And that at the very end of getting the queue working, and I could just be able to get around the limitation by moving things around, but I don't see why I should continue build on this. For what I am trying to do it has already grown way too complex and without the feel of control of what is happening.

I can think of ways of circumventing that limitation. Several ways. ThreadLocal being one way. Another is through getters and setters and forcing the extending of RMap to get the client. But threadlocal is the way.

Sorry, which ThreadLocal object do you mean?

I have not tried liveobjects, which is also a way, but I don't see why you would need the annotation of @rentity or @RClient on your own RMap, RList and what not.

I'm afraid you missed LiveObject conception - it allows to bind entity objects to Redis hash and store field value as hash entry. If you look at Usage section you will find that @REntity annotation applied to POJO entity and not to RMap, RList object.

You should have focused on prodiving a copy of hibernate for redis

I think you missed the idea behind the project. I tried to provide convinent API for Java Developer to Redis. More other I implemented other useful Redis based objects which not avaialble in Redis itself.
Here is the feature comparision vs Jedis lib https://redisson.org/feature-comparison-redisson-vs-jedis.html
With Jedis you'll need to re-invent features offered by Redisson, maintain connection pool, care of thread safety and so on...

I am saying you could have used the concept of live object yourself on your own RMap, RList to avoid that annoying limitation. And you own implementation you would no have need to annotate them at all.

I just wanted to echo what @momomo and @DALDEI have already said in this thread. @mrniko you're definitely a brilliant engineer creating a library of this complexity, but there are also some gaps that need to be addressed. For my project, we're using RLiveObjectService to handle a wide variety of different Java-based entities. I think the general expectation of a service like this that as a developer I can throw in any Java POJO and "it just works™". Unfortunately, in reality there are a lot of "gotchas":

The default codec FST doesn't handle any type of changes to POJOs. So if you're changing your data model, but your Redis database still has data in the previous format, expect to see exceptions on read. Moreover, FST doesn't seem to support Java 17 at the moment, blocking our Java 17 upgrade.
Codecs that rely on Jackson can handle model changes, but the default config provided by Redisson only works for POJOs that use basic Java primitives. If you want to use java.time types like LocalDateTime or ZonedDateTime (which IMO is a very common use-case) you'll quickly end up rolling your own JsonJacksonCodec and you carefully have to setup its internals in order to correctly roundtrip data. Adding JavaTimeModule is not enough, for instance ZonedDateTime will deserialize but without the original timezone. Ouch. Moreover, using a type like this on the "root" object (the one annotated with REntity) will lead to a ClassCastException. This is the fundamental design flaw @DALDEI talks about, and makes sense considering how Redisson uses the ObjectMapper in this case: https://github.com/redisson/redisson/blob/master/redisson/src/main/java/org/redisson/codec/JsonJacksonCodec.java#L99 telling Jackson to deserialize to Object without providing any other details, meaning there's no way for Jackson to know it's dealing with a ZonedDateTime.
Behavioral differences between the root-entity and any nested classes within that root-entity. The "live" behavior only applies to the getters and setters on the root-entity, but doesn't propagate down to nested classes. Unless, it just happens to be a List or Map that automagically gets turned into something else by Redisson, which comes with its own rules (e.g. properly handling cascading deletes when the root-entity gets deleted).

I think, rather than trying to support every (de)serialization mechanism out there, I would focus on providing one (or a few) that are preconfigured to work well with Redisson and support a wider set of uses cases:

Support for Java primitives, and commonly used types from the JDK, such as java.time. With support I mean developers should be able to use these types out-of-the-box and without any issues.
Support for non-breaking changes to POJOS (e.g. additive changes).
Adequate tradeoff between storage-footprint and performance. I know I can wrap a JsonJacksonCodec in a SnappyV2Codec, but why not provide one by default? Or make it a configuration setting to use compression and optionally specify a compression method.

Again, Redisson is a great library and you've done excellent work in creating this. I hope these suggestions help you to improve your project.

@MartinDevillers
Thank you for your feedback.

FST doesn't seem to support Java 17 at the moment, blocking our Java 17 upgrade.

FstCodec is deprecated since it's too buggy. Default codec has been changed to MarshallingCodec since 3.13.0 version. Also you can try Kryo5Codec. Anyway you can always implement own codec.

Moreover, using a type like this on the "root" object (the one annotated with REntity) will lead to a ClassCastException.

The "live" behavior only applies to the getters and setters on the root-entity, but doesn't propagate down to nested classes.

Can you create an issues for these tasks?

I know I can wrap a JsonJacksonCodec in a SnappyV2Codec, but why not provide one by default?

Since for some data can't be compressed then it cause only excessive CPU consumption. It depends on use case and only developer can decide if compression is really necessary. JsonJacksonCodec is not the only codec. There are 9 codecs which developer should have ability to choose from.

@nachobot
MarshallingCodec was deprecated due to this issue https://github.com/redisson/redisson/issues/4634. Kryo5Codec has been a default codec since 3.19.0 version.

No shit. I realized that within 1 day of using it. I ended up writing my own library. 100X more powerful. Will see if I come to publishing it soon.

authors: DALDEI MartinDevillers momomo mrniko

repo: redisson/redisson


text:
A StackOverflow error after upgrading redisson 3.18.1 to 3.34.1

Redis version
3.2.12
Redisson version
3.34.1
Redisson configuration
final String raddr = String.format("%s://%s:%d", rproto, rhost, rport);
final Config rconfig = new Config();
rconfig.useSingleServer().setAddress(raddr);
Redisson.create(rconfig);

What is the Expected behavior?
RBucket.set(Test) should work without error.
What is the Actual behavior?
RBucket.set(Test) throws com.esotericsoftware.kryo.KryoException
Additional information
Error log
com.esotericsoftware.kryo.KryoException: A StackOverflow occurred. The most likely cause is that your data has a circular reference resulting in infinite recursion. Try enabling references with Kryo.setReferences(true). If your data structure is really more than 1740 levels deep then try increasing your Java stack size.

did you try to set Kryo.setReferences(true) ?

It worked with Kryo5Codec but Kryo5Codec has below vulnerability. Is any way we can do it KryoCodec
https://nvd.nist.gov/vuln/detail/CVE-2023-42809

you need to set registrationRequired = true to the constructor if you want to avoid this.

Sorry, Kryo.setReferences(true) won't help. A list of allowed classes should be passed. Try SerializationCodec instead.

I have updated Kryo5Codec. Now it accepts allowedClasses parameter

useReferences setting has been added as well

Fixed in https://github.com/redisson/redisson/commit/d938ae50c5951c747037afbb25b156d734f802f0 and https://github.com/redisson/redisson/commit/f0f91d4adcda3680beada710b2358d7945b8e5eb

authors: mrniko yogeshskale


text:
Offset error with Spelling and backtick before it

Given foo.txt:
I `Dockerfile`

redpen -r json foo.txt produces:

[{"document":"foo.txt","errors":[{"sentence":"I Dockerfile","endPosition":{"offset":14,"lineNum":1},"validator":"Spelling","lineNum":1,"sentenceStartColumnNum":0,"message":"Found possibly misspelled word "Dockerfile".","startPosition":{"offset":2,"lineNum":1}}]}]

The offset with startPosition is 2 here, but should be 3.
It seems like the backtick caused the offset error here.
Also the offset for endPosition seems to be off.

I will take this issue.

I fixed the problem. Please let us know when you still have the problem in the origin/master branch.

Thank you!

authors: blueyed takahi-i

repo: redpen-cc/redpen


text:
added a link to korean redux docs

Thanks for the PR!
To better assist you, please select the type of PR you want to create.
Click the "Preview" tab above, and click on the link for the PR type:

:book: New/Updated Documentation Content

Hi. as I mentioned in issue #3892, I have added the Korean redux documentation link to your docs.
I hope you accept this PR.
If you don't want to accept this, please let me know the reason and I will appreciate any feedback.
Thanks !!

Thanks!

authors: shawnscoding timdorr

repo: reduxjs/redux


text:
Follow-up on improved chat interaction

The AI model now returns references along with the reply (#241). We should update the frontend to use this improved response

From my read of https://github.com/refstudio/refstudio/pull/241, it looks like @gjreda did some work to get JSON-structured responses with citations including page numbers, but that was deemed suboptimal due to greater token use and difficulties rendering the structured information in the frontend, so it was rolled back?
What is the scope of this issue? I definitely don't want us to try to parse citations out of a text response from the language model.

It has been mentioned here that we could add a button to insert the reply in the editor.
One idea was to replace elements like (Machine Learning - The High-Interest Credit Card of Technical Debt.pdf, p3) with the proper reference syntax when inserting, but I understand we don't want to parse the response from the language model.
Do you think inserting the response in the editor makes sense? Otherwise, I think we have reached an "MLP state" for the chat interaction, so we can close this issue.

authors: hammer sehyod

repo: refstudio/refstudio


text:
Bug: unable to resolve environment 'glimmerx'

Seeing this error while migrating play-glimmer-core-ui-lib:
brehuang@brehuang-mn1 play-glimmer-core-ui-lib % migrate
info:    @rehearsal/migrate 1.0.18-beta
warn:    You have uncommitted files in your repo. You might want to commit or stash them.
✔ Validate project
✔ Initialize
✔ Install dependencies
✔ Create tsconfig.json
↓ Create eslint config [SKIPPED]
✔ Add package scripts
✔ Analyze project
✖ Unable to resolve environment 'glimmerx' from /Users/brehuang/dev/play-glimmer-core-ui-lib
error:   Unable to resolve environment 'glimmerx' from /Users/brehuang/dev/play-glimmer-core-ui-lib

This error is caused by the target project having existing @glint dependencies, but at lower versions, which don't satisfy the glimmerx environment requirement.

repo: rehearsal-js/rehearsal-js


text:
Update circe-core, circe-parser to 0.14.9

About this PR
📦 Updates

io.circe:circe-core
io.circe:circe-parser

from 0.14.5 to 0.14.9
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.circe" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "io.circe" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #250.

repo: reibitto/be-kind-rewind


text:
Update zio-prelude to 1.0.0-RC24

About this PR
📦 Updates dev.zio:zio-prelude from 1.0.0-RC23 to 1.0.0-RC24
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio", artifactId = "zio-prelude" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "dev.zio", artifactId = "zio-prelude" }
}]

labels: library-update, early-semver-pre-release, semver-spec-pre-release, commit-count:1

Superseded by #546.

repo: reibitto/command-center


text:
🛑 Collabees is down

In 37756fa, Collabees (https://dmd.binus.ac.id/collabees/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Collabees is back up in 0ddde3d.


text:
🛑 Library and Knowledge Center (LKC) is down

In 9da9d1a, Library and Knowledge Center (LKC) (http://library.binus.ac.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Library and Knowledge Center (LKC) is back up in d5c1d5d.


text:
🛑 BISANARA is down

In 68cbcbd, BISANARA (https://bisanara.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: BISANARA is back up in d58897d.


text:
🛑 GreatNusa.com is down

In f6907fb, GreatNusa.com (https://greatnusa.com) was down:

HTTP code: 403
Response time: 93 ms

Resolved: GreatNusa.com is back up in dfa1610.


text:
URGENT: Remove <keywords> value from BibXML files

In Relaton we can keep the keywords. However, in BibXML, it has been clarified by IETF in https://github.com/ietf-ribose/bibxml-service/issues/88 that they do not support the <keyword> element yet.
We have to drop all keywords in the BibXML format.
We will add them back when IETF xml2rfc supports them in the future.

@ronaldtse we've removed keywords already https://github.com/ietf-ribose/bibxml-data-rfcs/blob/main/data/RFC8126.xml

Thanks @andrew2net !

repo: relaton/relaton-ietf


text:
docs(parser): documentation for scipy-parser

I struggle a bit navigating these docs, so I am probably committing a blunder here. I added a paragraph to the list of parsers and then referred below for details where I ..automodule:ed the docstring that I wrote for the module.
(I then tamed the docstring to fit a little better with the existing style of the docs.)

Also @relekang , what do you think about turning on PR docs for this repo in RTD? It is as quick as ticking a box on the RTD website and then we can see how the docs render on RTD before committing them.

Thanks. PR builds for RTD looks nice, I enabled it now.

authors: FirefoxMetzger relekang

repo: relekang/python-semantic-release


text:
Changing v1 to reliably/v1

It was requested that we start using version such as reliably/v1 instead of v1 for apiVersion to follow conventions found in kubernetes. Currently the entity server takes the version from the url, so that can likely stay with /v1/ in the path. The CLI would have to consume manifest entities with the more verbose versioning.

Alternatively this can be a url like api.reliably.com/v1

do we use that to identify the api endpoint to talk to ?
how do we then handle the case with the api served on other hosts (ie possible on-premise api, staging, localhost)

using reliably.com/v1 as per docs

repo: reliablyhq/cli


text:
Delete user pods when deleting chart

helm delete should remove orphaned user pods.
Sadly we cant get sp-instance id from ShinyProxy API (https://www.shinyproxy.io/documentation/configuration/#app-container-labels-and-annotations)

fixed by d1a6700

repo: remche/zero-to-shinyproxy


text:
Associations via custom attributes

Is it possible to define has_one or has_many associations with attribute names on the parent that dont match a singular or plural pattern, e.g. User.recent_comments could have a has_many :comments association?

OK have dug into the tests and realised it can be done with
has_many :recent_comments, class_name: "Comment"
Would be great to add a quick note to the docs showing this.

If you PR the readme with the info, I'll merge it. Bonus points for adding
a rest if there isn't one already.
On Wednesday, August 26, 2015, Paul Mackay notifications@github.com wrote:

OK have dug into the tests and realised it can be done with
has_many :recent_comments, class_name: "Comment"
Would be great to add a quick note to the docs showing this.
—
Reply to this email directly or view it on GitHub
https://github.com/remiprev/her/issues/363#issuecomment-134935318.

Have created a PR.

@hubert does the PR look ok to merge or any feedback?

Sorry for the wait @pmackay. Thanks for helping us improve the docs 🎩

authors: hubert pmackay zacharywelch

repo: remiprev/her


text:
🛑 Remix Dashboard is down

In 4aa6259, Remix Dashboard (https://remix.fairuse.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Remix Dashboard is back up in be62439 after 8 minutes.

repo: remix-bot/status


text:
Express/Typescript template fails to start

What version of Remix are you using?
1.15.0
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce
npx create-remix@latest, select express adapter, select Typescript, run npm run dev
Expected Behavior
The dev server to startup
Actual Behavior
[nodemon] starting `cross-env NODE_ENV=production node ./server.js --require dotenv/config ./server.js`
node:internal/modules/cjs/loader:1078
  throw err;
  ^

Error: Cannot find module '/.../my-remix-app/server.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1075:15)
    at Module._load (node:internal/modules/cjs/loader:920:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:23:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Node.js v18.15.0
[nodemon] app crashed - waiting for file changes before starting...

The start command also doesn't work since it references the non-existent server.js. It seems like it is missing the steps to build and bundle the server code. Taking inspiration from the Blues stack template, I currently have my scripts section as follows and it seems to work:
"scripts": {
    "build": "run-s build:*",
    "build:remix": "remix build",
    "build:server": "esbuild --platform=node --format=cjs ./server.ts --outdir=build --bundle",
    "dev": "run-p dev:*",
    "dev:build": "cross-env NODE_ENV=development npm run build:server -- --watch",
    "dev:remix": "cross-env NODE_ENV=development remix watch",
    "dev:server": "cross-env NODE_ENV=development node --inspect --require ./node_modules/dotenv/config ./build/server.js",
    "start": "cross-env NODE_ENV=production node ./build/server.js",
    "typecheck": "tsc"
  }

The start command also doesn't work since it references the non-existent server.js. It seems like it is missing the steps to build and bundle the server code. Taking inspiration from the Blues stack template, I currently have my scripts section as follows and it seems to work:
"scripts": {
    "build": "run-s build:*",
    "build:remix": "remix build",
    "build:server": "esbuild --platform=node --format=cjs ./server.ts --outdir=build --bundle",
    "dev": "run-p dev:*",
    "dev:build": "cross-env NODE_ENV=development npm run build:server -- --watch",
    "dev:remix": "cross-env NODE_ENV=development remix watch",
    "dev:server": "cross-env NODE_ENV=development node --inspect --require ./node_modules/dotenv/config ./build/server.js",
    "start": "cross-env NODE_ENV=production node ./build/server.js",
    "typecheck": "tsc"
  }

yeah but this is using javascript for server.js..
would be nice to have express with ts

yeah but this is using javascript for server.js.. would be nice to have express with ts

Not really, the build:server command generates the build/server.js file from server.ts.

yeah but this is using javascript for server.js.. would be nice to have express with ts

Not really, the build:server command generates the build/server.js file from server.ts.

oh, i tried this now and it works great except for one thing, the dev script doesn't update the server after i change server.ts, it does say it rebuilds it into server.js but changes aren't applie unless i restart

yeah but this is using javascript for server.js.. would be nice to have express with ts

Not really, the build:server command generates the build/server.js file from server.ts.

oh, i tried this now and it works great except for one thing, the dev script doesn't update the server after i change server.ts, it does say it rebuilds it into server.js but changes aren't apply unless i restart

changing the dev:server script to use nodemon instead of node can fix this :]

I solved this locally by adding
npm i @digitak/esrun
npm i dotenv

Then, in server.ts I added:
import dotenv from "dotenv";

dotenv.config();

and in package.json made these changes:
diff --git a/package.json b/package.json
index dc239b6..af8d710 100644
--- a/package.json
+++ b/package.json
@@ -4,9 +4,9 @@
   "scripts": {
     "build": "remix build",
     "dev": "npm-run-all build --parallel \"dev:*\"",
-    "dev:node": "cross-env NODE_ENV=development nodemon --require dotenv/config ./server.js --watch ./server.js",
+    "dev:node": "cross-env NODE_ENV=development esrun --watch ./server.ts ",
     "dev:remix": "remix watch",
-    "start": "cross-env NODE_ENV=production node ./server.js",
+    "start": "cross-env NODE_ENV=production esrun ./server.ts",
     "typecheck": "tsc",
     "lint": "eslint app",
     "lintfix": "eslint app --fix && prettier --write app",

Seems to work. Doesn't generate a server.js file.

Waiting a an update from the official remix team 🙏

https://github.com/remix-run/remix/pull/6145
this one should fix the issue

for the record, the typecheck script also fails right the install
npm run typecheck

> typecheck
> tsc

node_modules/@remix-run/node/dist/upload/fileUploadHandler.d.ts:47:22 - error TS2420: Class 'NodeOnDiskFile' incorrectly implements interface 'File'.
  Property 'prototype' is missing in type 'NodeOnDiskFile' but required in type 'File'.

47 export declare class NodeOnDiskFile implements File {
                        ~~~~~~~~~~~~~~

  node_modules/typescript/lib/lib.dom.d.ts:2572:5
    2572     prototype: Blob;
             ~~~~~~~~~
    'prototype' is declared here.

Found 1 error in node_modules/@remix-run/node/dist/upload/fileUploadHandler.d.ts:47

authors: BUGO07 andrew-dias dpobel dteknolove gatesn lili21 peterbe

repo: remix-run/remix


text:
Add error type to server runtime meta args

Closes: There is no issue for this one yet

[ ] Docs (https://remix.run/docs/en/main/route/meta#error does not mention a specific package to import this from - no changes required)
[ ] Tests (there is a test "loader errors are passed to meta" in the meta-test.tsx file - no changes required)

I have a Remix app on the latest version (v2.3.1) and with a lot of debugging, I've found out that the MetaFunction type imported from '@remix-run/node' differs from the MetaFunction from '@remix-run/react'. If there is an error thrown in the loader with v.2.3.1, the error is set as expected in JavaScript but the types yelled at me.
Testing Strategy

Have a look at the inferred types of the MetaFunction imported from '@remix-run/node'
Verify that the error property is included

I think our CI bot is confused. This was merged to dev so is not included in the 2.4.0 prerelease


text:
php version?

What php version did you use?

Hi,
I am using php 7.4, but I think it should also work with php 8.1 or 8.2. Please tell me if you check any of these versions or any other versions.
Best regards


text:
Python 3 compliant version ?

I guess I already know the answer but is it a chance for this project to be adapted to python 3 ?

I modified some change to make it work for python3
https://github.com/Rockyzsu/CodePool/tree/master/remote-opencv-streaming-live-video

I have made a new update in the code. The code is now ready to be used with Python 3

I have made a new update in the code. The code is now ready to be used with Python 3.


text:
Request : make the project Android-Studio 2.0.x friendly

to import.

What do you mean?

currently when i try to import the project, it fails, as it shows this:

I'm developing on Android Studio, and IMO there's nothing more to do on my side. You're using an AS preview BTW.
What steps are you doing to import it?

The usual:
VCS->checkout...->git

1/ clone the project manually using git clone
2/ File -> Import, choose the root directory.

This is not Android-Studio friendly way to open a project. it's not even open a project. it's import.
In standard way to do so, you choose "file-open" and not "file->import". and, like most of the repos here on github, it should be possible to do what I did originally.
You should update the repo to include the project file as they are after the import is done and working.

also, btw, running the sample (which works well), I suggest that pressing back would not close the activity if the icon has changed to the arrow, but instead change back to a magnifying glass first

@AndroidDeveloperLB : IDE project files shouldn't be commited to a VCS, they just pollute the repo. They're IDE specifics - and the project have nothing to do with any IDE, this is a gradle project.  Android Studio allows you to properly import Gradle projects.

Android Studio also allows me to easily import github repos without the need of external tool, and run them just fine, but here it can't.

You're using a preview version of Android Studio. If you think there's a
bug, please report to the Android tools team.

Seems it doesn't occur on 1.5.1 version of the IDE. Odd. Do you suggest to write about it here:
https://code.google.com/p/android/issues/entry
?

Yep, choose the tools section.

Sure the tools? Isn't it related to the IDE? All the Android Studio versions should use the same sdk tools that I've installed, no?

Do they have an IDE section? If so, yes.

authors: AndroidDeveloperLB renaudcerrato

repo: renaudcerrato/FloatingSearchView


text:
Error: Invalid transport, must be an object with a log method.

I've installed winston 1.3.1 and it seems it was supported for 1.2.x and not 1.3.x. (from online) There were many subsections of winstons like winston-loggly etc and it would be helpful if someone who did this tutorial can help me out

maninuni commented 15 days ago
Change the code:
from logger.add(logger.transports.Console
to logger.add(new logger.transports.Console
it should work now
Found a solution. thanks

What was your solution? I tried changing the code in the above comment and I got no errors this time but the bot didn't go online

Sorry for the delay. That worked out for me. I didn't downgrade to 1.2.x, I left it as 1.3.1 and used "new" keyword. I have stopped using this way to develop the bot however.
Although, this example helped me get started but I moved on to using discord.js. Discord.js is very orderly, logical and simple and I was able to make a simple project using it

repo: renesansz/discord-greeter-bot


text:
How do you get the globbing to work?

$ eslint --ext jsx,js  --max-warnings 0 .

/Users/sontek/code/eventray/src/eventray/static/js/components/element_editor.js
  44:1  error  Expected 'multiple' syntax before 'single' syntax  sort-imports

then:
$ import-sort **/*.js --write
✨  Done in 19.14s.

and then run it again:
$ eslint --ext jsx,js  --max-warnings 0 .

/Users/sontek/code/eventray/src/eventray/static/js/components/element_editor.js
  44:1  error  Expected 'multiple' syntax before 'single' syntax  sort-imports

am I missing something?

I've tried a few variations, this is another:
import-sort --write ./static/**/*.js

I tried this as well:
import-sort --write --list-different **/**.js
import-sort --write --list-different static/**/*.js

which doesn't work, but this does:
import-sort --write --list-different static/js/components/element_editor.js
static/js/components/element_editor.js

Bash was expanding it, needed to quote the *'s

repo: renke/import-sort

license: isc


text:
🛑 WEB is down

In f66d8a3, WEB (https://oceba.gba.gov.ar) was down:

HTTP code: 0
Response time: 0 ms

Resolved: WEB is back up in 719373b.

repo: renzoalis/upptime


text:
Playing Aseprite animation fix

I've tried using an aseprite animation but can't get it to work. I've finally found the problem, and after changing
play(name, loop) {
	const anim = spr[this.spriteID].anims[name];

to
play(name, loop) {
	const anim = assets.sprites[this.spriteID].anims[name];

it worked.
I'm not sure if it's related to aseprite plugin, or related to core. I can make PR if needed

Nice catch, thanks! Fixed in bba3d1d and I just released v0.4.1 that includes this fix

repo: replit/kaboom


text:
fix #716

It looks like the recursive setting inside of game.root.get was not fully recursive, you needed to call flatMap on the children as well:
this.children.flatMap(function recurse(child) {
   return [child, ...child.children.flatMap(recurse)]
})

I am pretty sure it fixes the issue ( #716 ) as described:

Thank you!

authors: DryCreations slmjkdbtl


text:
Error with proxy

Everything works well on dev machine (windows) but when i deploying the app to the server (Ubuntu) strange error happened.
When i set http proxy to request it throws the error for every request
AssertionError: 20 == 0
  at ClientRequest.onConnect (/home/carmod/www/avitoparser/bundle/programs/server/npm/node_modules/tunnel-agent/index.js:159:14)
  at ClientRequest.g (events.js:260:16)
  at emitThree (events.js:97:13)
  at ClientRequest.emit (events.js:175:7)
  at Socket.socketOnData (_http_client.js:354:11)
  at emitOne (events.js:77:13)
  at Socket.emit (events.js:169:7)
  at readableAddChunk (_stream_readable.js:153:18)
  at Socket.Readable.push (_stream_readable.js:111:10)
  at TCP.onread (net.js:536:20)

No ideas how to catch the error and why it happened.

It has something to do with trying to open https://example.com when you have a http proxy. When I changed it to http://example.com no more errors were thrown.

authors: Deadly0 Laptinius pepzwee

repo: request/request


text:
Why save the same request twice?

It works with another API to overwrite the same request in the cache, but with this API it is saved twice.
from requests_cache import CachedSession
import requests

session = CachedSession('fmc_cache', backend='sqlite', ignored_parameters=['X-auth-access-token'])

FMC_HEADERS = {'X-auth-access-token': 'TOKEN'}
url = 'https://HOST/api/fmc_config/v1/domain/DOMAIN_UUID/devices/devicerecords'

response = session.get(url, headers=FMC_HEADERS, verify=False)

with session.cache_disabled():
    response = session.get(url, headers=FMC_HEADERS, verify=False)
    session.cache.save_response(response)

print(session.cache.response_count())
for response in session.cache.values():
    print(response)

UPDATE:
When I use the verify parameter it is saved twice in the cache.
Do you have any idea why?
Thank you!

Requests with and without verify are cached separately, because the server may return a different response if SSL cert verification is disabled (#70, #209). When you call save_response(), it's going to use a different cache key because verify happens to be the only piece of relevant request info that isn't saved on the response object, and it defaults to True.
I realize that behavior isn't obvious, but here is a workaround you can use:
from requests_cache import CachedSession, create_key

session = CachedSession('fmc_cache', backend='sqlite', ignored_parameters=['X-auth-access-token'])
response = session.get(url, headers=FMC_HEADERS, verify=False)

cache_key = create_key(response.request, verify=False)
session.cache.save_response(response, cache_key)

authors: JWCook Mosony

repo: requests-cache/requests-cache


text:
Drop Python 2.6 support

Yesterday marks 3 years since the last release of Python 2.6! 🎉
To celebrate, I'm attempting to drop support for it from 156 prominent Python packages (one for every week it's past end-of-life)--including this one!
I've tried my best to remove as much 2.6-specific cruft as I can, but at the very least, this PR will remove the 'Programming Language :: Python :: 2.6' trove classifier from this projects setup.py.

No.

Double no.

One year on, any thoughts on dropping 2.6?
If not now, what are the reasons for keeping it and when might it be droppable?
I see it's no longer being tested: https://github.com/requests/requests/commit/c3ecb825c41f90fb6bec28c282c70c84398e08c0.

This was eventually done in #4118.

authors: Lukasa di hugovk kennethreitz

repo: requests/requests


text:
Support grpc-web

We should add server-side support for the grpc-web protocol. The protocol itself isn't too different from standard gRPC, and it'd be nice for reRPC servers to directly support web clients.
That said, I'm not sure how much traction grpc-web actually has (i.e., does anyone care about this?). I'm also unsure what our cross-testing options are - would we need to run a headless browser in the reRPC tests?

One more caveat: the protocol document makes it pretty clear that the protocol follows the implementation, rather than the other way around. I can't tell how stable the protocol is, and whether we'll get ourselves into a bad semver situation by implementing it.
If we do implement it, I lean towards just putting it in and enabling it by default, like our current Twirp support. Unless there's some broader array of proto-over-HTTP dialects we see ourselves supporting in v1, a plugin system for this seems overly elaborate.

repo: rerpc/rerpc


text:
Actually unique RowIds 1: Forbid use of duplicate RowIds

In this PR:

Detect and forbid duplicated RowIds in the store
Update test suites accordingly

Part of a small PR series whose goal is to make RowIds truly unique: i.e. a RowId corresponds to one insertion in the store, using the store's atomic unit of insertion -- the DataRow (which itself might still carry arbitrarily many timestamps(!)).
This creates an invariant that downstream subscribers of store events can trust and build on: a RowId is introduced once and GC'd once, that's it.

#4174
#4175
#4176
#4180

Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested demo.rerun.io (if applicable)
[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

PR Build Summary
Docs preview
Examples preview
Recent benchmark results
Wasm size tracking

Uh-oh, I broke something.

curious, almost all our tests are fine with this (after slight fixup); so we never actually hit RowId duplication in the wild so far..?

curious, almost all our tests are fine with this (after slight fixup); so we never actually hit RowId duplication in the wild so far..?
EDIT: Ah. It happens when you have several processes logging to the same recording, right?

Oh no on the contrary, almost all our tests failed with this ^_^ (which is expected, they just copy rows left and right).
The slight fix up is really not so slight and makes it so every test just tries to increment RowId for as long as necessary until it's finally valid.

authors: Wumpf teh-cmc

repo: rerun-io/rerun


text:
Neovim client: fix semantic tokens

Neovim 0.9 add support for semantic tokens.
When opening a file and editing I get the following error: E5248: Invalid character in group name
I saw that the server registers tokens that are not in the specification: support-type-primitive, jsx-tag and jsx-lowercase.
This PR change name of tokens:

support-type-primitive -> type
jsx-tag -> class (class was used as module name, now it's namespace)
jsx-lowercase -> interface (div, h1)

One question: Why emit a token for jsx-tag, the < and > in <div>? Couldn't this be done via regex?
Forum post: https://forum.rescript-lang.org/t/neovim-vim-rescript-lsp-semantic-tokens-issue-and-maintenance/4387

Can semantic tokens be turned off in neovim until all works?

Can semantic tokens be turned off in neovim until all works?

yes

I'm afraid this PR will (from memory but I could be wrong) break some themes.

It seems not, because semanticTokenScopes maps to the same TextMate Scope.
This changes the name of the token the server emit, but the semanticTokenScopes field didn't change the TextMate scope target.
Example: previously the token jsx-lowercase was mapped to entity.name.tag, I changed jsx-lowercase to interface but it still gets mapped to entity.name.tag
VSCode Semantic token map

I'm going to do some tests.

Dark (default dark)
Before:

After:

Light (default light)
Before:

After:

Solarized Dark
Before:

After:

Solarized Light
Before:

After:

Monokai Dimmed ⚠
Before:

After:

Tomorrow Night Blue ⚠
Before:

After:

One Dark Pro ⚠
Before:

After:

Three themes have changed: Monokai Dimmed, Tomorrow Night Blue and One Dark Pro.
The changes were in the token < and >

Three themes have changed: Monokai Dimmed, Tomorrow Night Blue and One Dark Pro.
The changes were in the token < and >
Curious that the token </ is not emited.

The token </, if I remember correctly, is handled via regexp, as it's easy to recognise. While < and > are really overloaded and need the help of semantic highlighting.
So based on these findings, is it possible to handle the issue on the neovim side?

In general, I just don't know what the constraints are with neovim. One could also do everything via grammar, which is less precise but avoids breaking things. As long as that extra complexity does not affect the main extension.

So based on these findings, is it possible to handle the issue on the neovim side?

No, because it is necessary to change the name of the token emited by the server. Ideally, the specification would have a name for the token < and >, but it doesn't.
The best approach is to not emit < and > as jsx_tag.

So based on these findings, is it possible to handle the issue on the neovim side?

No, because it is necessary to change the name of the token emited by the server. Ideally, the specification would have a name for the token < and >, but it doesn't.
The best approach is to not emit < and > as jsx_tag.

That breaks things for 98% of users to benefit 2%? Or maybe I don't understand the suggestion.

Yes, you are correct.
What I'm saying is that the LSP specification should have a token to jsx.
I will continue emitting the token, but I will change the token type.

I changed the token from class to modifier.
One Dark Pro
After:

Tomorrow Night Blue
After:

So this seems to solve the issue.
Anything else pending, or can this go ahead?

I guess a quick check is needed that the other styles still work.

Yes, I tested it on all themes supported by the extension.

Yes, I tested it on all themes supported by the extension.

Fantastic. Thank you so much for sorting this out. Pretty subtle stuff.

authors: aspeddro cristianoc

repo: rescript-lang/rescript-vscode


text:
Comment gets formatted away in JSX

  // Comment

gets formatted to

Fixed in #553 and #555.

repo: rescript-lang/syntax


text:
Docker's recommended way of modifying path with ENV PATH /foo:$PATH doesn't work with resin images

I was trying to build an application based on resin/rpi-raspbian (and resin/armv7hf-debian) and found out that my sample Dockerfile:
FROM resin/rpi-raspbian:jessie-2015-08-05
ENV PATH /app/bin:$PATH

Would result in this error:
[root@alarmpi temp]# docker build -t pathtest . && docker run -ti --rm pathtest bash
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM resin/rpi-raspbian:jessie-2015-08-05
 ---> 6c85dc1dc385
Step 1 : ENV PATH /app/bin:$PATH
 ---> Using cache
 ---> 84731ec46cc5
Successfully built 84731ec46cc5
exec: "bash": executable file not found in $PATH
Error response from daemon: Cannot start container 21cb1e224fbca66f232d1bcfc132966df3fbf45faa9b90a8fcdef921b945c4e8: [8] System error: exec: "bash": executable file not found in $PATH

This was very confusing but I figured out the cause. First, here's an example of how it's actually supposed to work (from my MBP):
FROM ubuntu:14.04
ENV PATH /app/bin:$PATH

➜  foo  docker build -t pathtest . && docker run -ti --rm pathtest bash
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu:14.04
 ---> 8251da35e7a7
Step 1 : ENV PATH /app/bin:$PATH
 ---> Using cache
 ---> 84aa7b3f2b6b
Successfully built 84aa7b3f2b6b
root@fb52c1f6e6cf:/#

The problem is  commit 9cde84cabeca4114fbeb740edce2740caae892e8 that set LC_ALL=C.UTF-8 by default.
Here's how Docker knows how to fetch the initial value for $PATH:

There's a hardcoded default path in daemon/container_unix.go#L40
When processing FROM, Docker appends the default $PATH to the environment ONLY IF the base image doesn't set any ENV by itself, in builder/internals.go#L536

Indeed, if we check the base image config values, we can see the difference:
➜  foo  docker inspect ubuntu:14.04 | jq '.[].Config.Env'
null

[root@alarmpi temp]# docker inspect resin/rpi-raspbian:jessie-2015-08-05 | jq '.[].Config.Env'
[
  "LC_ALL=C.UTF-8"
]

So, because the resin base images have a non-empty Env, the default $PATH never gets added to the list, and hence my problem.
Setting the $PATH like I'm doing is mentioned in Best practices for writing Dockerfiles, so I don't think I'm the only one with this problem.
And just to further confirm the cause, the issue doesn't occur with your older images like resin/rpi-raspbian:wheezy-2015-06-17:
[root@alarmpi temp]# docker build -t pathtest . && docker run -ti --rm pathtest bash
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM resin/rpi-raspbian:wheezy-2015-06-17
 ---> cbcadcbfd9a3
Step 1 : ENV PATH /app/bin:$PATH
 ---> Running in 4ec6337818d9
 ---> 8d4921c7d38c
Removing intermediate container 4ec6337818d9
Successfully built 8d4921c7d38c
root@d6c146466dbd:/#

Can we get this fixed?

@sorccu Thanks for the report. We have a PR for this: https://github.com/resin-io-library/resin-rpi-raspbian/pull/4 and will get this fixed soon. Happy hacking with Resin!

repo: resin-io-library/resin-rpi-raspbian


text:
On Python3 the SDK also needs urlparse

While on Python 2 it works fine, the SDK seems to have a missing dependency on Python 3.
Python 3.5.2 (default, Jun 28 2016, 08:46:01)
[GCC 6.1.1 20160602] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import resin
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/greg/resin/prog/bluemix-resin-python/venv3/lib/python3.5/site-packages/resin/__init__.py", line 9, in <module>
    from .base_request import BaseRequest
  File "/home/greg/resin/prog/bluemix-resin-python/venv3/lib/python3.5/site-packages/resin/base_request.py", line 7, in <module>
    from urlparse import urljoin
ImportError: No module named 'urlparse'

 Front conversations

@imrehg, currently our SDK only supports python 2. I will make time for Python 3 version soon :)

@nghiant2710 thanks for the heads up! May we keep this issue open in the meantime as a reminder?

Hey @nghiant2710 how much work does this require? I just got a ping via support, we should bring to @lekkas attention if it's worthwhile.

This connects to #45

authors: craig-mulligan imrehg nghiant2710

repo: resin-io/resin-sdk-python


text:
Page menu links broken in engines

The links in the site menu are broken on engine pages.
To reproduce, start a new project on edge, install refinerycms-news (3.1 branch), create a test news item.
When on pages created by the Pages engine, menu links are fine.  As soon as you go to a page created by the refinerycms-news engine (or any other engine), links are broken.
"/about" becomes "/pages/test?path%5B%5D=about"

Because then we can't interact with other systems that desire catchall routes.
If you turn off marketable urls then instead of /about you get /pages/about

Hi all,
Here is what I had to do: https://github.com/maxime/refinerycms/commit/09ebfadaf2828c9fa44792220ada4df785221bc0
To fix the problem described here. If you guys can have a try and let me know if it works for you too, we can probably include this commit as a fix.
Maxime

@ugisozols give it a whirl please and let us know if it fixes it for you

Thank you @maxime! I was trying the same thing previously but something was interfering with the specs (got tons of failure) and that's when I decided it's not good :)

Happy to help :)

woot!  This was an issue for us as well and someone fixed it with a 'righteous hack' in our case that was in no way worthy of committing...

authors: jimjimovich knewter maxime parndt ugisozols

repo: resolve/refinerycms


text:
Unclear what to do with unreferenced packs mentioned by restic check

Output of restic version
restic 0.8.3
compiled with go1.10 on linux/amd64
How did you run restic exactly?
RESTIC_PASSWORD_FILE=/root/restic-password RESTIC_REPOSITORY=/srv/restic/ restic check
What backend/server/service did you use to store the repository?
fs
Expected behavior
I get lots of lines like

pack 9b1f020fbaa954ba0c456b4ac70c579ec8d8c68ea9cad67262d47eacaa221557: not referenced in any index
pack 158ed155e15d3d0ac3444b5ce62c055a75dca3bd840ba54c6aadd426c6166fc2: not referenced in any index
pack 8492c4a4f913d99b668c2d618c9417349d52017140bdac1126dba438cd00d88a: not referenced in any index
pack a61d84e22a7f668bbf86dd2401b25d5dcd6cabb3f42de8ff8b498dc50446f1c2: not referenced in any index
pack c13bd7c2d4e6b5054d42fd5076bdee9701ae53ec89acc10a2d91f315a3ac6932: not referenced in any index

#but nothing tells me what to do about it. man restic-check does not menion error conditions and what to do about them.
Actual behavior
I get error but no help in fixing them or understanding what the packs contain.
Steps to reproduce the behavior
Not sure how I got these errors. I only had 12 snapshots and did not notice any errors when I created them.
Do you have any idea what may have caused this?
Missing documentation.
Do you have an idea how to solve the issue?
Add help about how to inspect what the packs contain and how to remove or add them properly.

Yep, these errors need to be improved as well. For the record, what's going on here is that check finds files in the repo not mentioned in the metadata files anywhere, they were probably leftover files from an aborted/interrupted run of backup.
The next run of restic prune will take care of the files and remove them properly.

Thank you, restic prune helped.

Thanks for reporting the need for better documentation @tyll. I'm closing this issue in favor of #2683.

authors: fd0 rawtaz tyll

repo: restic/restic


text:
Restic forget fails with B2 and object locks despite --no-lock (and a crash in forget when remote lock fails)

Output of restic version
restic 0.12.1 compiled with go1.16.6 on linux/amd64
How did you run restic exactly?
restic --no-lock -r b2:restic-backup-2:/ forget e2f7d85
I have set these environment variables (with real values of course):
export B2_ACCOUNT_ID=00000000000000000000000
export B2_ACCOUNT_KEY=K001abcdabdbabcdabcdabcd
export RESTIC_PASSWORD_FILE=/home/user/restic-pw
This is the output of the command:
repository 35b4e101 opened successfully, password is correct
unable to create lock in backend: repository is already locked exclusively by PID 32487 on HOST by user (UID 1002, GID 1003)
lock was created at 2021-08-23 10:53:33 (42m34.573443863s ago)
storage ID 52256a07
the unlock command can be used to remove stale locks
The strange thing is that I have specified --no-lock on all commands, but a lock was made regardless.
What backend/server/service did you use to store the repository?
Backblaze with object locks enabled (with time set to two days as I was testing the feature)
Maybe this is relevant. I did CTRL-C my first backup proces at one point, after which restic has been complaining about "Access denied" (because of object lock I suppose).
Expected behavior
Expected restic being able to forget a snapshot (and also delete the stale files created by interrupted backup after few days as object lock period for the files created on the interrupted backup has expired). I tried to forget a backup created a week ago or so.
Also expected no locks being created on the backend due to "--no-lock" specified to restic.
Also didn't expect restic unlock to crash.
Actual behavior
Restic forget fails. This is the output of the
restic --no-lock -r b2:restic-backup-2:/ forget e2f7d85
repository 35b4e101 opened successfully, password is correct
unable to create lock in backend: repository is already locked exclusively by PID 32487 on HOST by user (UID 1002, GID 1003)
lock was created at 2021-08-23 10:53:33 (42m34.573443863s ago)
storage ID 52256a07
the unlock command can be used to remove stale locks
The restic unlock does not work either now (because the lock cannot be cleared due to the object locks).
This is the output of the
restic --no-lock -r b2:restic-backup-2:/ unlock
repository 35b4e101 opened successfully, password is correct
Remove(<lock/52256a0740>) returned error, retrying after 552.330144ms: Delete: b2_delete_file_version: 401: Access Denied
Remove(<lock/52256a0740>) returned error, retrying after 1.080381816s: Delete: b2_delete_file_version: 401: Access Denied
Remove(<lock/52256a0740>) returned error, retrying after 1.31013006s: Delete: b2_delete_file_version: 401: Access Denied
Remove(<lock/52256a0740>) returned error, retrying after 1.582392691s: Delete: b2_delete_file_version: 401: Access Denied
Remove(<lock/52256a0740>) returned error, retrying after 2.340488664s: Delete: b2_delete_file_version: 401: Access Denied
Remove(<lock/52256a0740>) returned error, retrying after 4.506218855s: Delete: b2_delete_file_version: 401: Access Denied
Remove(<lock/52256a0740>) returned error, retrying after 3.221479586s: Delete: b2_delete_file_version: 401: Access Denied
Remove(<lock/52256a0740>) returned error, retrying after 5.608623477s: Delete: b2_delete_file_version: 401: Access Denied
Remove(<lock/52256a0740>) returned error, retrying after 7.649837917s: Delete: b2_delete_file_version: 401: Access Denied
Remove(<lock/52256a0740>) returned error, retrying after 15.394871241s: Delete: b2_delete_file_version: 401: Access Denied
b2_delete_file_version: 401: Access Denied
Delete
github.com/restic/restic/internal/backend/b2.(*b2Backend).Remove
/restic/internal/backend/b2/b2.go:261
github.com/restic/restic/internal/backend.(*RetryBackend).Remove.func1
/restic/internal/backend/backend_retry.go:108
github.com/cenkalti/backoff/v4.RetryNotifyWithTimer
/home/build/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.1.1/retry.go:55
github.com/cenkalti/backoff/v4.RetryNotify
/home/build/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.1.1/retry.go:34
github.com/restic/restic/internal/backend.(*RetryBackend).retry
/restic/internal/backend/backend_retry.go:46
github.com/restic/restic/internal/backend.(*RetryBackend).Remove
/restic/internal/backend/backend_retry.go:107
github.com/restic/restic/internal/cache.(*Backend).Remove
/restic/internal/cache/backend.go:38
github.com/restic/restic/internal/restic.RemoveStaleLocks.func1
/restic/internal/restic/lock.go:282
github.com/restic/restic/internal/restic.ForAllLocks.func2
/restic/internal/restic/lock.go:336
golang.org/x/sync/errgroup.(*Group).Go.func1
/home/build/go/pkg/mod/golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:57
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1371
Steps to reproduce the behavior
I can retry and update the reproduction instructions tomorrow, as the old bucket is now unusable for two days do to the object locks.
I now created a new bucket with 1 day of object locks, so I can test things sooner, but will have to wait until tomorrow until I can try delete a snapshot.
But even creating the backup with --no-lock gave the error about not being able to delete the lock file.
Do you have any idea what may have caused this?
restic trying to use locks even if specified it should not. Not sure how working with object locks (or immutability in the backend) should be handled).
Do you have an idea how to solve the issue?
Not atm. Just wait until the object lock time runs out, but before that can't do much as back-end is strict.
Did restic help you today? Did it make you happy in any way?
I like the docs generally, and am just getting into restic, it looks like a well-maintained tool. Just think the operation on object-locked storage is not that well-specified/used.

The strange thing is that I have specified --no-lock on all commands, but a lock was made regardless.

Several commands like forget, prune, check and backup ignore the --no-lock option.

Backblaze with object locks enabled (with time set to two days as I was testing the feature)

restic assumes that it can delete lock files at any time (after 5 minutes to be precise). And to prune data restic must be able to delete any files it wants to. Or to be a bit more precise the files must be marked as deleted and don't show up again when listing files. With AWS S3 and the Object Lock feature buckets must be versioned which allows doing exactly what I've just mentioned. I wonder whether there's a similar feature for B2?

You could also try whether the S3 compatible API of B2 works with a beta release of restic (see https://beta.restic.net/?sort=time&order=desc ). restic 0.12.1 probably won't work as #3246 in not included in any released version so far.

Or you could try whether #2398 works for you.

Thanks. So I gather that working in read-only (or temporarily read-only due to object locked) repositories only works for taking snapshots, but not forgetting them at the moment?
AFAIK the above #2398 just hides the error if the deletion fails, so wont improve the actual behavior, right?. Atm I have also no easy way of building custom binaries based on PRs unfortunately.

#2398 tells B2 to hide a file, when it can't be deleted. That is enough that other restic operations won't process that file again and then forget and prune should work as normal. The only downside is that the hidden files still consume storage space. The hidden files still have to be deleted by e.g. lifecycle rules. And something also has to extend the file lock duration of files that should be kept.
If you check out the code from a PR, then you only need a go compiler and then call go build ./cmd/restic and you're done.

Thanks Michael. That something that could extend the file lock duration I suppose is not in place yet? Can't ask Restic to "touch" the files in B2 (that are still part of the latest snapshot), which I suppose would extend their life?

restic doesn't know anything about file / object locks so far. For now, it should work to (manually) extend the lock duration for all files that haven't been hidden. And to actually make sure that the repository is in a working state you have to run check from time to time.

@MichaelEischer Finally got the restic compiled from the #2398. Was a bit harder as I had an older golang-go version (1.6) which didn't work out of the box. Build failed for missing deps (fuse etc). After realising I do need to update the go instead of trying to manually fulfill the deps, it was an easy build. Maybe a version check of the golang-go to the build command to help future builders in this situation?
I tested the #2398 and it does indeed work better, by hiding files instead of deleting which works for me.
I also actually tried restoring an initially hidden snashots file in the repository side (after forgetting it first with restic), and then restoring the snapshots file manually in the b2 server side.
So, I could achieve nice ransomware safe backups with this using efficient snapshots to go back in time if needed. If the attacker manages to get hold hold of the backup side where restic is run, my backups would be still safe (thanks to object locks), and file versions on the server side (and life cycle rules).
I could actually live with these limitations with the PR, as they do give me truly ransomware safe backups albeit with manual work required in the case attacker has maliciously tried deleting all. The manual work is today required to restore the older versions on server side (especially for older data files, that object locks do not protect anymore). The restore in this case would involve some scripting to get the repo to an earlier state.
I guess the only few remaining optimizations that could be great features

Make #2398 an option in the main restic. Having to maintain an own build is not great.
Add some knowledge on object locks on restic. This would also be helpful with "cold backups" as well so that restic would be "forbidden" to modify files within some time period (to save money/costs). The object lock information could for example be given in the init, or be an backup option. Then in regular use case, user could just be running backup/prune without any scripting required or server side tricks.   If the super motivated attacker tried altering the object lock information, and deleting backups (that are object locked), the operation would just fail but on normal cases the operations would be seamless.
Some way of extending the object locks would be required (as you also point out earlier).

There are few other folks trying also achieve what I am trying:
https://github.com/restic/restic/issues/3195

Thanks for testing and nice to hear that it worked.
The manual and readme already mention that at least Go version 1.14 is required. There's also the possibility to build restic via go run build.go which includes a go version check, although I'm not sure whether that would have worked with Go 1.6. Sorry for not mentioning that a recent go version is required; it's just that nobody had complained so far ;-) .
I agree that object lock support would simplify usage with restic, but that feature request belongs into #3195.

@gabrielwhite Your problem is unrelated to this issue. Please have a look at #3541 instead.

Closing as #2398 has been merged a long time ago.

authors: MichaelEischer vsuontam


text:
feat: Enable table display on the table and inline arguments on the UI

Change description
In order to show a better test report let's show up the tables and inline arguments
Type of change

[ ] Bug fix (fixes an issue)
[X] New feature (adds functionality)

Related issues
Fix #232
Checklists
Development

[x] Lint rules pass locally
[x] Application changes have been tested thoroughly
[x] Automated tests covering modified code pass

Security

[x] Security impact of change has been considered
[x] Code follows project security practices and guidelines

Code review

[x] Pull request has a descriptive title and context useful to a reviewer. Screenshots or screencasts are attached as necessary
[x] Changes have been reviewed by at least one other contributor
[x] Pull request linked to issue tracker where applicable

repo: restqa/restqa


text:
Handle case where Content-Length header is not supplied

Example error:
simeon@RottenApple resync> resync-sync -v --capability-list https://pod.stanford.edu/.well-known/resourcesync/normalized-capabilitylist/marcxml --access-token $ACCESS_TOKEN -b  https://pod.stanford.edu/ pod
Reading capability list https://pod.stanford.edu/.well-known/resourcesync/normalized-capabilitylist/marcxml
Reading resource list https://pod.stanford.edu/organizations/normalized_resourcelist/marcxml
Traceback (most recent call last):
  File "/Users/simeon/.python_venv/py38/lib/python3.8/site-packages/resync/client.py", line 101, in read_resource_list
    resource_list.read(uri=uri)
  File "/Users/simeon/.python_venv/py38/lib/python3.8/site-packages/resync/list_base_with_index.py", line 99, in read
    self.content_length = int(fh.info()['Content-Length'])
TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'

Code was intended to handle this gracefully, but doesn't. In resync/list_base_with_index.py line 99:
self.content_length = int(fh.info()['Content-Length'])

a missing Content-Lenght doesn't end up generating a KeyError but instead a TypeError from the int(). Should change to catch both

Released in 2.0.1

repo: resync/resync


text:
Cosmos Managed Identity Implementation

Type of PR

[X] Documentation changes
[X] Code changes
[ ] Test changes
[ ] CI-CD changes
[ ] GitHub Template changes

Purpose of PR

Implemented Cosmos DefaultAuthorization mechanism (Managed Identity and others)

It can now use several sequential Cosmos Auth methods documented here

Defaults to SecretKey method for Backward compatibility
Updated instruction for Local development

Can use Azure CLI auth method as well as the SecretKey method

Does this introduce a breaking change

[ ] YES
[X] NO

Validation

[ ] Unit tests updated and ran successfully
[X] Update documentation or issue referenced above

Issues Closed or Referenced

Closes https://github.com/retaildevcrews/wcnp/issues/1052
References https://github.com/retaildevcrews/wcnp/issues/1051
References https://github.com/retaildevcrews/wcnp/issues/1053

@pragmatical @PurpleBriar @TravisFallsMSFT
The existing grype issue was handled before by AK in this task. But the snakeyaml stuffs are still not fixable (see this new task)
Hence I propose merging this PR since, the feature is essentially finished and can be used for development and production.

Created a new issue to track snakeyaml package and reversion of grype ignore.
https://github.com/retaildevcrews/wcnp/issues/1131

repo: retaildevcrews/ngsa-java


text:
fix DECLARE_HANDLE

This fixes structs generated by the DECLARE_HANDLE macro being private.

There shouldn't be any reason to have to refer to the inner struct. Any usage of the inner type, such as HWND__ is always done through a *mut which has a public alias such as HWND. Is there any reason why you can't just use HWND instead of trying to refer to HWND__?

Yea, it would seem that it was user error on my end. winapi::HWND is definitely callable - rustc likes to refer to it as winapi::windef::HWND__, however -- hence the confusion.


text:
Actualizaciones de get_current_2D_trans

Agregué versiones de casi todo el código nuevo que modifican los arreglos que se pasan por parámetros. No tiene mucho sentido porque en performance anda igual o un poco peor que el código anterior que hace allocations nuevas para todo, principalmente porque reduce(+, eachslice(local_results, dims=4)) hace algo de magia más rápida que sumar a mano.
Para usar la función nueva get_current_2D_trans! hay que crear un Current2DTransStorage que tiene todos los arreglos temporales que hacen falta para correr. get_current_2D_trans (sin !) muestra cómo usarlo.
Estoy viendo que hay una forma de hacer mejor esto (construir un callable en vez de un struct, que después se puede pasar llamar como si fuera una función), pero me va a tomar algo de tiempo pasarlo en limpio.

Gracias Charly!
Esto lo uso como pie para cambiar el resto entonces?
O sea cambiar el orden de los arreglos en caso todo.
No entiendo bien si la nueva versión es más rápida o decís que son
equivalentes?
Luego miro el detalle y te comento.
Gracias nuevamente!
El mié, 5 de abr de 2023, 20:29, Carlos Bederián @.***>
escribió:

Agregué versiones de casi todo el código nuevo que modifican los arreglos
que se pasan por parámetros. No tiene mucho sentido porque en performance
anda igual o un poco peor que el código anterior que hace allocations
nuevas para todo, principalmente porque reduce(+,
eachslice(local_results, dims=4)) hace algo de magia más rápida que sumar
a mano.
Para usar la función nueva get_current_2D_trans! hay que crear un
Current2DTransStorage que tiene todos los arreglos temporales que hacen
falta para correr. get_current_2D_trans (sin !) muestra cómo usarlo.
Estoy viendo que hay una forma de hacer mejor esto (construir un callable
en vez de un struct, que después se puede pasar llamar como si fuera una
función), pero me va a tomar algo de tiempo pasarlo en limpio.
You can view, comment on, or merge this pull request online at:
https://github.com/reula/PIC-1D/pull/2
Commit Summary

4f0fdb6
https://github.com/reula/PIC-1D/pull/2/commits/4f0fdb681b829b74b1b4301018113a3553850b4d
Fix get_current_threads_2D params order
dcb6704
https://github.com/reula/PIC-1D/pull/2/commits/dcb6704eda764ed134c0b3279b0e1d5f3fc77c59
Adding v_trans!
86e816e
https://github.com/reula/PIC-1D/pull/2/commits/86e816e421cb01be82a72c0bcb6d373bc6a1d89d
Adding get_indices_and_y_trans!
24b6245
https://github.com/reula/PIC-1D/pull/2/commits/24b6245ebd3c84cb684380a0c324e54260153855
Adding get_current_2D_trans!, don't sort arrays by indices
101d6a5
https://github.com/reula/PIC-1D/pull/2/commits/101d6a5c328c4f7eb1b9049ea5a33c3a21fb2117
get_current_2D_trans: Improve result traversal

File Changes
(2 files https://github.com/reula/PIC-1D/pull/2/files)

M aux_functions/aux_functions_density_charge.jl
https://github.com/reula/PIC-1D/pull/2/files#diff-cc2e5ac66286553b8399adf81cfcb6212ed43cd44a86cc246951a5b021e416e7
(67)
M aux_functions/aux_functions_grid.jl
https://github.com/reula/PIC-1D/pull/2/files#diff-6d97e9082a7113a59dc47c159a85819a8546eb412e4727b50b7eee68a2b8d87f
(12)

Patch Links:

https://github.com/reula/PIC-1D/pull/2.patch
https://github.com/reula/PIC-1D/pull/2.diff

—
Reply to this email directly, view it on GitHub
https://github.com/reula/PIC-1D/pull/2, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN2A34J5O4PPECUEDEMH7DW7X543ANCNFSM6AAAAAAWUWCRUU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Al menos habría que cambiar el código que usa el resultado de estas funciones para que respete el orden distinto.

Claro
El mar, 18 de abr de 2023, 17:47, Carlos Bederián @.***>
escribió:

Al menos habría que cambiar el código que usa el resultado de estas
funciones para que respete el orden distinto.
—
Reply to this email directly, view it on GitHub
https://github.com/reula/PIC-1D/pull/2#issuecomment-1513775165, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN2A37OBPBQVE3RQKM4NODXB34UXANCNFSM6AAAAAAWUWCRUU
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

authors: reula zzzoom


text:
Expect and output basis as positive number

Basis should be a positive number. It was helpful to think of it as a negative because total value fro a buy from the exchange is a negative value. Basis in accounting is really the positive that cancels the negative to leave zero (-8000 USD + 1 BTC * 8000 USD / BTC = 0 thus the 1 BTC has a basis of 8000 USD).

looking at this a bit closer, basis values were getting calculated incorrectly for BTC due to the use of sum along with the fact that the data used can be negative or positive. This needs to be corrected in order to get accurate basis value calculations.


text:
messages: remove watchtower opinion polling

This is sooooooo much cleaner without this complexity. Whose idea was it already?

Lol guys i dropped half the spending process doc.. Arg we should have catched it! :)

Lol guys i dropped half the spending process doc.. Arg we should have catched it! :)

delay: yea, it would make sense to make it configurable. I think a fraction of the CSV delay would be a sensible default (2%? With a 12 blocks CSV it's (12 - 1) / 10 = 2.2 seconds, with -1 accounting for the worst case event of a block being found just after our poll).
re fallback coordinator: definitely.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le lundi, mars 15, 2021 2:06 PM, Kevin Loaec @.***> a écrit :

@kloaec commented on this pull request.
Sorry for the late ack, but yes, much cleaner.
We need some kind of "delay" between asking the coordinator and triggering the cancel if no or wrong reply. Short but not stupidly short. Also might be a config option?
Also a fallback coordinator really makes sense here, if first one isn't responding (especially for external WT like the Revault corp ones.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or unsubscribe.

repo: revault/practical-revault


text:
Test sig fetcher robustness

Based on #165, closes #164
I still need to test it a bit more, as the test sometimes fails as the manager's revaultd dies

Failing even after rebasing on top of #169, sometimes manager dies and the log doesn't help at all (they're trimmed). Seems that I have to test in a real setup :/

Hopefully it's fixed (CI hates me though)

Oo CI is back to life

ACK 2445d33

Hmm CI is dying again but i never had a single die locally (ran the tests hundreds of times this week)

authors: danielabrozzoni darosior

repo: revault/revaultd


text:
Some documentation updates

Connects to #14

Document and spec functions defined by using XDR.Base
Fix the XDR.Base code example in the README
Move the custom_xdr test module to its own file

Thanks, @jmilamwalters! Just installed the plugin and made some updates to this PR

repo: revelrylabs/exdr


text:
🛑 API is down

In 4057840, API (https://api.revolt.chat) was down:

HTTP code: 403
Response time: 229 ms

Resolved: API is back up in cae6d5b.

repo: revolt-chat/status


text:
UserAgreementMiddleware does not redirect to tos_check_url

The UserAgreementMiddleware has the following lines:
if not user_agreed:
    return add_never_cache_headers(HttpResponseRedirect(tos_check_url))

But add_never_cache_headers does not return anything and middleware returns None.
Maybe there should be something like this:
if not user_agreed:
    response = HttpResponseRedirect(tos_check_url)
    add_never_cache_headers(response)
    return response

Yeah, I think you're right. PRs are welcome on this. Hopefully have time to make this fix soon.

authors: nicholasserra uishnik

repo: revsys/django-tos


text:
azure worker role - nothing gets done to my template

My app works fine when i run it locally.  When i deploy it to azure no exceptions occur at runtime, but the result string is purely my template. With no processing done at all.
Local
"hello david you are an adult"
Azure
"hello {{Model.name}} {{#If Model.Adult}} you are an adult {{/if}}"
Has anyone experienced this? Because i dont get any exceptions i am unsure where to look.  Could it be a .net dependency/vc++ redistributable/execute permissions/file share?
Thanks

Why did you mention vc++? Is that a factor in your app?

No. But I thought there might be some dependency I was unaware of

A

Glad you got it sorted!

authors: WilliamHBonney rexm