Replace entities option isGeneratingCustomCodingKeys with isUsingStringsForCodingKeys

Background

closes #75
#57

Using individual enums for CodingKey types can unexpectedly bloat the binary when generating a lot of Decodable types (apple/swift#60287).
Prior to this change, the default behaviour of CreateAPI is to generated individual enums but we believe that we should generate efficient code by default in this case.
Changes
To support this, I've deprecated the old isGeneratingCustomCodingKeys option and in it's favour have introduced isUsingStringsForCodingKeys. While making this transition, the default behaviour is now flipped meaning that:

If you didn't define isGeneratingCustomCodingKeys in your config, you will need to set isUsingStringsForCodingKeys to false to match your previously generated output
If you did set isGeneratingCustomCodingKeys to false, you don't need to do anything apart from remove the flag before it is removed in 0.2.0

Because we're changing the default behaviour, this also results in a lot of changes to the expected tests, hence the big diff 🙏 You can however focus most of the review outside of the Tests/CreateAPITests/Expected/ directory
Release Note

Generated entities will now use string literals via a generated StringCodingKey type by default instead of custom CodingKey enums. To match behaviour prior to 0.1.0, set entities.isUsingStringsForCodingKeys to false. For more information, see #75.

Will close this for now. I'm going to approach in two steps:

Mass rename properties (#89)
Change default behaviours


fix: gcp retriever is able get the updated flags file

Description
What was the problem?
It was not possible to use an instance of gcstorageretriever.Retriever{} since it is only able to get the file on the initial bootstrap of go-feature-flag instance. After feature flag client is up and running, the internal flags cache is no longer updated when gcstorageretriever is used.
How it is resolved?
The issue has been resolved avoiding the use of the file reader as a field of Retriever. So, after the first bootstrap of Retriever the file reader was closed because the code closes the reader after done reading. If we try out another call to Retriever.Retrieve() the reader is not nil and it was closed, so that, it was not able to get the updated file. In that case, we could see some log trace like:
fmt.Errorf("unable to read from GCP Object %s in Bucket %s, error: %s", retriever.Bucket, retriever.Object, err)

How can we test the change?

Unit tests
Example script using gcstorageretriever.Retriever{}

Changes include

[x] Bugfix (non-breaking change that solves an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking changes (change that is not backward-compatible and/or changes current functionality)

Closes issue(s)
https://github.com/thomaspoignant/go-feature-flag/issues/310
Checklist

[x] I have tested this code
[x] I have added unit test to cover this code
[ ] I have updated the documentation (README.md and /docs)
[x] I have followed the contributing guide

Coverage increased (+0.3%) to 95.096% when pulling cf3fb8ba5db7664685556977960a6922583354ce on jferrl:fix/gcs-retriever into 34b159e689de5ba1347af5dd9eabb8e0098d1148 on thomaspoignant:main.

Don't worry about the linting issue, I will fix it in another PR and will works for you.

@thomaspoignant PR able to merge! 🚀


Low peer count post-merge

A discord user is experiencing a low peer count post merge:

https://discord.com/channels/593655374469660673/593655641445367808/1019901205629108244

might need to stop lodestar and clear peerstore directory in lodestar root directory

Would definitely get them to upgrade to v1.1.0 once released to see if it persists.

i  feel that v1.1.0 has shown auto peer recovery on my installations even after dropping to low double digits because of network turbulence, without requiring me to clear peerstore that i had to do with v1.0.0


[FLINK-7630] [Java API] Allow passing a File or an InputStream to ParameterTool.fromPropertiesFile()

Add two version with different parameter type for ParameterTool.fromPropertiesFile() method
Update unit test ParameterToolTest.testFromPropertiesFile()
Update best practice document to introduce these two ways to use Parameter.

The changes look good! 👍 I especially like the added tests and documentation.

I merged, could you please close this PR?
And thanks for working on this! 😃

I thought it would be closed automatically. But it's okay, I will close it. Thanks for your quick review.


Obsolete Link

HI team the hyperlink for the appliance points at an obsolete version (6 vs. the latest at the time of writing is versions 8).

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 60d3e532-e3e5-219a-ce0c-502b48faaebb
Version Independent ID: 19765a75-4ee0-7ce7-5d34-1cac117cf80c
Content: Discover physical servers with Azure Migrate Discovery and assessment - Azure Migrate
Content Source: articles/migrate/tutorial-discover-physical.md
Service: azure-migrate
GitHub Login: @vineetvikram
Microsoft Alias: vivikram

Please assign it to @Vikram1988

@barbarabel Thanks a lot for taking time to share your feedback, our team will review it and fix the document accordingly.

Hi @barbarabel,
The link to the latest appliance version has been updated at https://docs.microsoft.com/en-us/azure/migrate/tutorial-discover-physical#2-download-the-installer-script.
Hence, closing this issue.
#please-close


Add object store level support for counters

c.f. https://github.com/realm/realm-sync/issues/16
It seems like making counters a type apart from Int is a good idea, as originally suggested in the linked ticket. Although the underlying engine supports a type which mixes 'set' and 'add' operations, it's not clear how useful such a type would be in practice.
Actual implementation work should be very easy. Core and sync both provide the necessary primitives and expose them as APIs already. We just need to figure out what this feature should look like as a public API, which will affect what support object store provides for bindings (if any).
@jpsim @bdash @tgoyne

The reasoning for making it the same type is that you also want to be able to reset the counter to specific state, which is functionally the same as updating an integer value.

I don't see introducing a new type as a clear cut solution.
New Type Advantages

No way to accidentally call "set", overriding past history of increment/decrement
Communicates intent of how a property should be used at the type system level
Add/Subtract can be methods directly on the type rather than on the parent object

Int Type Advantages

No need to add a new type and protocol (e.g. RLMCounter)
Works with existing code that expects integers without "unwrapping"
It's useful to be able to "reset" the counter. There's no reason to force that reset value to be zero, so if it was on a new type, that'd just be .reset(_ value: Int). At that point, it's functionally equivalent to just prop = value.

Based on this, I think I prefer the new type option, but only slightly. I may be missing arguments on either side here too. In any case, we should sketch out what we want the final public API would look like.

Any thoughts, @cmelchior @kristiandupont @AndyDentFree?

Java doesn't have an option. It will have to be a new type since we cannot add functionality to existing classes. Something like
public class RealmCounter implements Comparable {

  // Constructors
  public RealmCounter(String val);
  public RealmCounter(long val);
  // Possible others?

  // Only required operation, arguable if substract is needed or not
  public void add(long val);

  // Convert to java primitive types. Integer in Java also have to float/double conversion
  public int intValue();
  public long longValue();
  public short shortValue();
  public float floatValue();
  public double doubleValue();

  // Comparable
  public int compareTo(RealmCounter other);
}

You can probably argue how many utility methods to add to it, but since this will be a class we can probably ship a MVP of it and add more methods later depending on feedback. I assume we are bounded by 64 bit values and don't support e.g. BigInteger. That is probably of questionable value anyway.
Some inspiration:
From Riak: https://github.com/dclements/riak-java-crdt/blob/master/src/main/java/com/readytalk/crdt/counters/CRDTCounter.java
This one has different classes for various semantics (seem a bit overkill to me).
https://github.com/dclements/riak-java-crdt/tree/master/src/main/java/com/readytalk/crdt/counters

We also have to consider how migrations on this work, e.g it should be possible to change the field from a counter field back to a normal int. That seems hard to do if you overload Int?

We also have to consider how migrations on this work, e.g it should be possible to change the field from a counter field back to a normal int. That seems hard to do if you overload Int?

Since counter-style add/subtract are instructions on core int columns, there's no impact on schema between a property of type Int or "Counter". Even if we go with a custom Counter type, we can not require a schema bump when converting a property from Int to Counter.

Java doesn't have an option. It will have to be a new type since we cannot add functionality to existing classes. Something like

We also can't realistically have these methods on Int in cocoa, which is why I was referring to the "existing type" option above as having its add/subtract methods on the parent object, which is ugly as sin:
extension Object {
  func add(amount: Int, toProperty: String)
  func subtract(amount: Int, fromProperty: String)
}

Since counter-style add/subtract are instructions on core int columns, there's no impact on schema between a property of type Int or "Counter". Even if we go with a custom Counter type, we can not require a schema bump when converting a property from Int to Counter.

I think we need to find a way to do that then, as this is a semantic breaking change with very surprising consequences. Consider a case for sync where
public class Person extends RealmObject {
  // V1
  public int muffinsEaten;

  // V2
  public RealmCounter muffinsEaten;
}

muffinsEaten = 4 // V1 device
muffinsEaten.add(4) // V2 device -> state is now 8
muffinsEaten = 6 // V1 device
muffinsEaten.add(2) // V2 device -> state is now 8

In my mind, this is a breaking schema change and as such shouldn't be allowed for Sync and would require a schema bump for non-synced Realms.

In .NET we have no problems using a system structure type DateTimeOffset and so I see no problems with a RealmCounter which provides operator overloading to inc and dec.

I think we have a consensus, then, that it should be a separate type? If we want users to be able to arbitrarily set a value (bad idea) we can always expose a reset() API that is functionally identical to set(), but at least provides the intended semantics.

Separate type, backed by int property so no different storage needed, works for me.
ObjectBrowser needs to be aware of the type as we may want to warn people if they try to arbitrarily set it (not ban arbitrary setting because that would enrage devs).

ObjectBrowser needs to be aware of the type as we may want to warn people if they try to arbitrarily set it (not ban arbitrary setting because that would enrage devs).

Not sure what you are talking about here?

Even though backed by an int, ObjectBrowser needs to have rules aware this is a counter so it can warn people when they go to reset.

No, I don't think tracking in metadata table that the "int" column is really a "counter" is helpful.

No, I don't think tracking in metadata table that the "int" column is really a "counter" is helpful.

 It seems we are as a consensus leaning towards a separate type for bindings.
I'm not sure if Counter behaviour needs to be different from int for sync also, as the comments suggest it will map to something like counter_inc, counter_dec and counter_set instructions which could as well be applied to integer columns.
If it is a separate type for bindings then of course they need to be able to infer that from the schema to support dynamic actions.
However, if the underlying storage is just an int, I agree with @jpsim that it doesn't seem to require a schema bump to move between Counter and int types - it's behavioural change rather than data change. However, I do think it's dangerous to start adding special case logic or some property type changes so that inclines me back to treating it like any other schema change - a version bump is required.
I have spent so much of my career being a toolsmith that I always tend to think of people writing tools against the engine. Not just for our ObjectBrowser but, increasingly, as we move into the Enterprise Space we will have people wanting to write their own tools - this has been a driver behind at least two of the Win32 desktop requests.

FYI, Sync does not treat counters and integers as separate types. You can perform an AddInteger instruction on any integer column, and SetInteger just resets the counter. These instructions can be freely mixed with no odd effects (SetInteger is equivalent to resetting the counter, as others have mentioned).

In that case, at least in .net, I'd say it would be cleanest to simply add dedicated Add and Setfunctions that works on integer columns.

I strongly disagree. Counters should not be treated as simple integers in the bindings. Just because Core can optimize the underlying representation doesn't mean that has to surface to the bindings (Just like the old Date implementation wasn't an Integer either). The difference in semantics requires treating it as a separate type IMO with the impact it has on API/Browser/Etc.

I think we're all in agreement to expose a Counter type in the bindings. What's less clear is whether or not this should be annotated in the Realm's metadata, and if so how? Introducing a new way to specialize or refine types in a schema would need to be done with some consideration of how it should scale in the future too.

@simonask Is it intentional that there's no RowFuncs implementation of add_int()? It's a bit cumbersome to get the table from a column from the object store to use the instance method on Table.

One way could be to have a new mapping table between types understood by the OS and Core types:
// Enum defined in the Object Store, enumerating all specialized types
enum RealmType {
  Counter, IncrementOnlyCounter, ....
}

// New meta data table
class | field | type
-----
Party | guests | Counter

Being able to annotate Table Columns would be nicer, and could be used for other things as well, but that would require some help from Core I would assume (and probably a file-format upgrade as well).

Please remember to consider that the Realm's metadata is also being synchronized. If you want to treat counters truly as separate types, the migration to upgrade existing integer columns will be schema-breaking, whereby it has to be disallowed for sync'ed Realms for the time being.
This would be a case where that limitation is entirely artificial and solely motivated by our desire to prevent users from shooting themselves in the foot. I'm questioning how this benefits the user, exactly. If the user does it wrong, there wouldn't be a way for them to fix their code later on (because it would require schema-breaking migrations).
In short, I don't really think there is a good reason to persist the counternance ( 😄 ) of an integer field in the schema. Just let it be up to the app developer to use the binding's Counter type if they wish to have a counter.

If the user does it wrong, there wouldn't be a way for them to fix their code later on.

So far we have been going to great lengths trying to prevent users from shooting themselves in the foot, and I don't see how preventing switching between Integer and Counter are any different than not allowing people to migrate a column from Integer to Strings or a host of other schema breaking migrations. Sync schemes are just very restrictive at the moment (See e.g. https://github.com/realm/realm-sync/issues/400)
As my example https://github.com/realm/realm-object-store/issues/357#issuecomment-275613063 showed. The semantics for mixing Integer and Counter across app versions will be completely unintuitive which strongly suggests you shouldn't be able to switch types for synced Realms.

I would say that unintuitive results is still better than exclusion from synchronization altogether. It's easy to explain what happens, and to instruct users to just use a different type for the field in their model. It's not so easy to guide them through migrating the schema with destructive changes. :-)

On that we disagree then. It might be "easy" to explain, but my default stance is that we should not introduce bugs in users app if they don't read the docs (which most of them won't).
Also, we are not preventing them from synchronizing. They need to create a new field with the Counter type (which they must do for other type migrations as well), which will also make the behavior difference explicit in their code base.

Also, we are not preventing them from synchronizing. They need to create a new field with the Counter type (which they must do for other type migrations as well)

This is just as bad, and should be avoided when possible. In all other instances where we ask users to do this, it is because there is no good alternative. Here it would be completely artificial.

which will also make the behavior difference explicit in their code base.

That will be the case no matter what (for bindings to languages that don't have operator overload - note that a C++ binding in the future probably doesn't need or want a separate Counter type).

This is just as bad, and should be avoided when possible

Yes it is bad, but somehow I feel you don't fully acknowledge my argument that semantic breaking behavior is just as bad as API breaking behavior. If we don't agree on that, we probably won't agree on how to approach Counters.

Yes, I don't agree with you on that. :)
I think it is much more important to provide users with a way forward. Temporarily wonky behavior due to initial misunderstanding is better than being permanently locked to a data model that is less than ideal. I really think breaking the user's schema should be a very last resort.

Fair enough :)
I would much prefer https://github.com/realm/realm-sync/issues/400 as a way to handle breaking schema changes though since it would enable people much more flexibility with regards to how they approach schema changes.

Yes, we definitely need a better long-term solution for breaking schema-changes. :+1:

I was just thinking about this and wondering where the original  user scenarios come from.
In the process, I had a couple of ideas which may help the debate:

if we want a Counter type to function as a robust counter which you increment/decrement and occasionally reset then we want to make accidental reset hard. This led the conclusion that we should disallow assignment from an integer, which makes it more obviously a separate type.
Having merge-safe arithmetic with add/del as operations rather than just assigning their result, seems generally useful. It then seems weird we don't therefore allow it on floats and that we lack multiplication.

I was thinking about one possible scenario of financial balances (I've worked on a lot of accounting software). Traditionally, a balance is calculated as a result of summed journal entries creating a delta from a given starting point.
Our Add/Del operations could be seen as unannotated jounal entries as they are just the operation without accompanying explanation. However, they can also be an optimisation - say we also log immutable journal entries but in the same Realm transaction have these math operations. The net effect, regardless of order, should be the same without the app having to sum its accounts.

Thinking about original user scenarios are a good idea. My inclination is that #1 is more useful. However, maybe the sample apps folks might have more ideas.

I would like for us to really consider if this needs to introduce a new type. In general we will want to continue making it possible for users to express the intent of their changes in more and more detail.
As an example of this you can see strings. Today we only (in the bindings) allow strings to be set, but in the future we will also allow inserts and deletes within strings, and later possibly moves and swaps. For all of these new operations there should be no need for new types as they are perfectly backwards compatible (apps that only support full string changes will only see the end result of these sub-string modification, so from their perspective they are equivalent of an atomic update).
Today with integers you can only set them atomically, but allowing people to express their intent more clearly seems valuable. If you want to set it you should do that, but if what you are really doing is to increment or decrement the the integer, you should be able to express that in a way that records the intent. Just as with strings it ought to be totally backwards compatible. An older app should not have to be aware of how the integer was modified, it will just see the end result.
If we start adding new types every time we give the user more fine-grained options for expressing how they use them, we could easily end in a combinatorial explosion of types.

As I noted in https://github.com/realm/realm-object-store/issues/357#issuecomment-275349370, Java doesn't have any option in this regard, we will need to introduce a new type since we cannot add functionality to existing classes due to language constraints.
I think we all agree that allowing people to express their intent more clear is better (hence adding Counter in the first place), I'm just extremely concerned that allowing you to mix set with add/increment semantics will not behave in an intuitive way (for the end user), which is the entire reason I'm advocating for making them different binding types that require migrations.
The simple case
v1 app (int)       v2 app (counter)
0                  0
set(2) = 2
                   2
                   add(1) = 3
                   add(1) = 4
4
----------- disconnect -----------
                   add(1) = 5
                   add(1) = 6
set(2) = 2
----------- connect --------------
2                 2
// old client will make it look like new client is loosing data

The above is clearly backward compatible and will converge given the rules for our merge algorithm, but any old client will just override the intent expressed by the Counter.
I'm pretty sure that isn't what the user wants if he is switching to a Counter in the first place. And yes, we could just document the behavior like Simon is advocating for but if we strive for the Principle of Least Astonishment then that is the wrong approach IMO. That intent is better expressed in the type system with Counter and Int as separate types. That way developers will need to handle the different semantics before the app is shipped to customers.

Sorry, maybe my head is buried in OT, but that result does not seem unintuitive to me at all. Explaining it is as easy as "the problem you have is that old clients reset the counter instead of adding/subtracting". I still don't see how it's helpful to break compatibility to prevent this situation.
I agree, by the way, that the binding should expose counters as a separate type in the data model. I don't think there's a good enough reason to make Counter and Int incompatible.

Yes, explaining the problem is easy. But how would you suggest the user going about fixing it? Since they cannot prevent old clients from syncing to new ones currently?

Bugs in old apps that get synchronized to newer versions is a much broader general issue that I don't think we can solve for people, at least not right now. Schema versioning with distributed migrations may be the right answer, but that definitely needs more thought before we can start designing on the assumption that it exists, IMO.
You could also argue that the amount of wonkiness introduced to the user experience by forcing developers to add a new Counter field in their new app version is pretty much equivalent to the amount of wonkiness introduced by old apps updating a counter field. The latter is just less work for us. ;-)

I still think it is a slippery slope. What happens when we start getting requests for setting and clearing individual bits on integers (which also commute)? We already have people asking for support for querying against bit patterns (which is a standard NSPredicate feature). Do we then have to add another type?

Let's all remember that language constraints sometimes prevent us from doing "the obvious" thing.
For example, you can't override the increment/decrement operators in ObjC or Swift, which means that a user could do obj.intProp++ and expect that to be an increment operation where in reality it'd be a (re)set operation. A new type prevents that from happening if the integer unwrap is a get-only operation.

I think @astigsen referred to exposing the counterness in the schema, not the binding. I think we all agree that none of the bindings can expose this functionality using system types.

if we don't have it in the schema, how does a binding know to use the type? I am thinking of enterprise settings where people write multiple language apps and if you have compatible types in the schema with no indication of a different semantic, they can build an app with an int access to a counter. Also, it impacts dynamic opening and browser behaviour.

they can build an app with an int access to a counter

What would that mean? A counter is just an int. The only difference is which operations you choose to do on it.

Also, it impacts dynamic opening and browser behavior.

There is no change in behavior when reading the values. So for browsing the data there should be no change. For editing the browser only supports setting values now, so when more ways of changing them becomes possible, we could consider making them available in the browser as well (that goes for strings a well).
One reason I like the idea of just augmenting the existing type with more operations, is that it is not always easy to predict ahead of time what you want to do with them. You might initially only need to set full values, but at some time later you might see a need to do increments and decrements. It would be nice for that to just work, without having to involve a migration that breaks old apps.
The point here is that the old apps explicitly communicate the intent that they are setting values. So as long as that was the correct intention at that point, it should still be valid and the app should keep working just fine. If we force a migration that changes the type of an existing property, just because they found out that there are now places where an increment operation is needed, then we break all the old versions of the app.

If we expose a custom type in the bindings, then operator overloading such as in C# and Swift can capture operators that are performing an increment or decrement. We could have functions in Java such as Add or Inc.
If the property is exposed only as an integer then any user operation on it is a reset.

@astigsen Think of it the other way. Is there any scenario where it would be the correct behavior if the field was an Integer in V1 of the app and a Counter in V2 of the app? (especially given the example in https://github.com/realm/realm-object-store/issues/357#issuecomment-278286497). I cannot come up with any, but if you have a use case I would be all ears.
If not, that is a strong argument for keeping them as separate types. There is also a reason that ideas like Hungarian notation came into existence and languages like ML allow you to define custom datatypes. Types carry information about intent far better than implicit knowledge.
E.g I cannot tell from an Integer if it is a Date, Bit pattern, Counter, Color or what it represents. In Android they added a huge number of annotations precisely because Integer is so unprecise: https://developer.android.com/reference/android/support/annotation/package-summary.html
I totally get the concern about type explosion, but IMO having e.g. just anRealmInteger type with set/increment/decrement/setBit methods would only benefit us because it would be less code to write, but users would suffer from unclear code and impose a hidden requirement that they cannot mix semantics across app versions anyway.
Note: My concern is only for synced Realms. Non-synced Realms would work fine with just one type, but I'm pretty sure we don't introduce different rules for sync/non-synced Realms.

To me breaking the schema just in case feels like overprotecting. As a developer, it would be clear to me that when old versions set an integer they'll reset my counter. If we make the new counter type implicitly convertible, they'll still be able to assign to an int in newer versions, so that kind of protection seems insufficient/unnecessary.

A counter set/reset is different than a pure integer set. A counter (re)set would be equivalent to int.add(target - int.get()), and we would probably expose that on a counter as an utility method anyway. It would merge very differently than a pure integer set.

A counter (re)set would be equivalent to int.add(target - int.get())

That's not true, and that would produce very unexpected results. A counter reset is exactly equivalent to assigning to the integer (and will be treated as such by the merge rules already).

Yeah, your right, I was imprecise. There is a difference between set and reset.

No, there is no difference between set and reset. :)

Arguing semantics, but I disagree. A reset sounds like a destructive operation (which it is), set is an operation that is fundamentally at odds with how a counter is supposed to work. But that is probably not relevant for the discussion about types 😄

Isn't it exactly at the heart of the discussion, though? I really don't see a reason to distinguish between the two things.

Please provide one single use case where it would make sense to mix increment/set between app versions? Because if such a case doesn't exist, I don't see why we should allow it?

Any sort of imprecise counter where loss of data is acceptable would be perfectly fine example. E.g. total number of steps - the rare case where an older version (implementing a poor man's counter by doing steps++) is offline, assigns new values, then comes back online and overwrites increments from a newer version will lead to a data loss, but in my opinion would be acceptable.
There are many other approximate vanity counters that would be fine to reset - e.g. number of games played, total amount of gold in a clicking game, etc. Resetting those will not corrupt state (e.g. because the user will have already consumed the gold). As a developer, I could see myself migrating to the new counter type and just ignoring the inconsistencies that might happen due to older versions syncing after being offline for a prolonged period of time.
Now, for the counter-question, can you provide a legitimate recipe for handling breaking the schema from a developer's point of view? 😛

Please provide one single use case where it would make sense to mix increment/set between app versions?

There are plenty. Obvious ones are everything related to inventory control. You can easily have the first version of an app used for counting inventory, where they manually count the number of products in each category and enter the number in the app. Then later they find out that they would like the number to also be somewhat up-to-date between the full recounts, and it really sucks for each employee to have to recount the entire category every time they add or remove an item, so they either update the app of make a new app for employees where they can increment or decrement the count when adding or removing product. They will still occasionally do a full inventory where they count everything and enter the verified values.
Another one I have seen many times is participant tracking at events, where you have people doing manual counts at each entryway (usually done today with a manual ticker) to get an approximation of how many people are at the venue or in the bus, and then when the doors are closed they do a real count to update it to the precise number (my mom is a tourist guide, so I have seen this process happen thousands of times :-)).
But I think it is more relevant to look at it the other way around. How often do you do a ++ or += on integers in regular programming? What are the examples of this being done, where if it happens in concurrently, you would not want to to merge as increments (as opposed to the end results just overwriting each other). To me it is just about exposing a set of semantics that you do anyways on integers, but which needs to be recorded to make sense in a concurrent setting.

@nirinchev Fair enough. I did not consider fuzzy counters although they seem more like acceptable data loss than something you would desire.
Regarding migrations, you would do what you need to do in any other breaking change: Create a new field and copy the value over. Right now our migration story is pretty weak though as we do not run migration blocks on synced Realms, so people would have to track it manually, and yes that would mean data loss when doing the migration as well, but at least you would know it happened instead of it coming as a surprise (at which point it is too late to fix).
In any case, no case in arguing this to death, so lets just start with a RealmInteger class or similar like @jpsim suggested. It can then encode all the custom methods we want on it and be fully compatible with a standard int. Then we just have to be exceedingly clear in the docs how it actually works.
At least it will keep the number of classes low and would also have nice symmetry with e.g RealmString for substring manipulation. If enough people get burned by it, I guess we can re-evaluate.

@jpsim So, to sum up, at the object store levels Integer properties should get access to the add functionality. Then bindings will implement a new Counter type backed by an Integer, just like the regular Integers. Is that correct?

Yes, that's optimal in my opinion.

I disagree. If we want to have a super-int. It shouldn't be named RLMCounter, especially if it will also gain bitwise operations as hinted by @astigsen. If it is just intended as "Int with special capabilities", RLMInteger or similar would be preferable. It would also make it more apparent that you can switch between Integer and RLMInteger at will.

@cmelchior You are referring to how bindings choose to expose this functionality to end users, right?

I disagree. If we want to have a super-int

A counter is exactly a super-int, though. Add/Subtract/Reset. It'd be incredibly confusing to users to call that an RLMInteger or similar when int is also an option.

Yes, but it bleeds down to OS as well, e.g. it seems weird to add a Counter and BitPattern (or whatever name) class in OS if you combine them in the bindings.

I wasn't planning on adding additional object store types, just exposing the add_int() Core API to bindings through the object accessor mechanism.

@jpsim I would agree if we only had Counter functionality, but how I read https://github.com/realm/realm-object-store/issues/357#issuecomment-278411081 is that will most likely change, so it can have multiple special methods not just related to counters.

I'm beginning to put together a PR: https://github.com/realm/realm-object-store/pull/375. I want to test it (especially since templates aren't instantiated unless you actually use them somewhere...), but it doesn't seem like we exercise any of our existing object accessor functionality in our object store tests. So I have to think about it some more.

The core (as in "bulk", "central") implementation of RealmIntegers is now in Java mainline ( https://github.com/realm/realm-java/pull/4953 )

Counters are now implemented in the Java bindings: #4266

@austinzheng, did we determine whether anything needs to be done in the object store for this? Java and .NET seem to have been able to support counters without any object store support. Is that because they're not using object store's accessor logic?

Object store support is unnecessary for counters for Cocoa either. I originally made this issue in the object store repo because I thought we might need underlying changes.


Float window rule not always working with Firefox Picture-in-Picture

Hyprland Version
Hyprland, built from branch  at commit b08b72358ad549fd066e5be0fc3aa4c9df367607 dirty (). Tag: v0.27.2  flags: (if any)
Bug or Regression?
Bug
Description
Window rules with Firefox Picture-in-Picture works inconsistently
How to reproduce

Using Mozilla Firefox 116.0.2
Open YouTube
Toggle PiP mode for a video
Window rule works and window float
Close PiP window
Toggle PiP mode again for a video
Window does not float

Crash reports, logs, images, videos
My window rules (third one for debugging):
windowrulev2 = float, title:(Picture-in-Picture)
windowrulev2 = size 600 337.5, title:(Picture-in-Picture)
windowrulev2 = bordercolor rgb(FF0000), title:(Picture-in-Picture)

Hyprland logs:
[LOG] Searching for matching rules for firefox (title: Picture-in-Picture)
[LOG] Window rule float ->  title:(Picture-in-Picture) matched 55bce45b12b0 [Picture-in-Picture]
[LOG] Window rule size 600 337.5 ->  title:(Picture-in-Picture) matched 55bce45b12b0 [Picture-in-Picture]
[LOG] Window rule bordercolor rgb(FF0000) ->  title:(Picture-in-Picture) matched 55bce45b12b0 [Picture-in-Picture]
[LOG] Window 55bce45b12b0 set title to Picture-in-Picture

The windows when the rule worked (hyprctl clients command):
Window 55bce4549dc0 -> Picture-in-Picture:
	mapped: 1
	hidden: 0
	at: 1669,22
	size: 600,337
	workspace: 10 (10)
	floating: 1
	monitor: 1
	class: firefox
	title: Picture-in-Picture
	initialClass: firefox
	initialTitle: Picture-in-Picture
	pid: 63524
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenmode: 0
	fakefullscreen: 0
	grouped: 0
	swallowing: 0

The windows when the rule didn't work  (hyprctl clients command):
Window 55bce4549dc0 -> Picture-in-Picture:
	mapped: 1
	hidden: 0
	at: 2712,22
	size: 931,1036
	workspace: 10 (10)
	floating: 0
	monitor: 1
	class: firefox
	title: Picture-in-Picture
	initialClass: firefox
	initialTitle: Firefox
	pid: 63524
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenmode: 0
	fakefullscreen: 0
	grouped: 0
	swallowing: 0

I noticed that it works when the initialTitle is Picture-in-Picture, so it probably is Firefox's fault
If the float rule was dynamic like bordercolor it would work, but that could cause other problems I don't know

just in case you want to open an issue this started 2 releases before firefox 116.0.2-1

Not sure about vanilla Firefox since I don't use it, but here my window rules for LibreWolf:
# LibreWolf Picture-in-Picture
$librewolfPiPClass = LibreWolf
$librewolfPiPTitle = ^(Picture-in-Picture)$
windowrulev2 = float, class:$librewolfPiPClass, title:$librewolfPiPTitle
# Fix for Picture-in-Picture only floats once
$librewolfPiPInitialTitle = Firefox
windowrulev2 = float, class:$librewolfPiPClass, title:$librewolfPiPInitialTitle

shout-out to hyprctl client
related: #2943 #2876

Any fix?

Recent update caused it to not work the same. This works:
windowrulev2 = size 640 360, title:(Picture-in-Picture)
windowrulev2 = pin, title:^(Picture-in-Picture)$
windowrulev2 = move 1906 14, title:(Picture-in-Picture)
windowrulev2 = float, title:^(Picture-in-Picture)$

Also, there is neat keybinding for Firefox PIP Ctrl+Shift+{ puts video PIP.


es6 classes

what's wrong with es6 classes?
could you explain the not having property initializers?

Writing getters for everything is gross.

Agreed!

ah got it, thanks

Also, Marionette Wires right now depends on extend being called in a couple of places.


chore(deps): update terraform terraform-ibm-modules/secrets-manager/ibm to v1.16.0

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/secrets-manager/ibm (source)
module
minor
1.15.1 -> 1.16.0

Release Notes

terraform-ibm-modules/terraform-ibm-secrets-manager (terraform-ibm-modules/secrets-manager/ibm)
v1.16.0
Compare Source
Features

added a new secrets terraform module for adding secrets into secrets groups in an existing Secrets Manager instance (#157) (04c2bc9)

v1.15.2
Compare Source
Bug Fixes

deps: update terraform ibm to latest for the deployable architecture solution (#158) (a858b59)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

:tada: This PR is included in version 1.0.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Building on Windows

Even after a couple hours of trying, I still cannot get this library to build on Windows (Rust Nightly 1.10 64-bit GNU). So far I've got the following:

Build environment using MSYS2 + MinGW 64
Protobuf binaries compiled from sources
PortAudio binaries from Github Repo somewhere

Right now I'm having trouble building librespot-protocol, respectively linking against libz (can't find the .dll, linker option: -lz). Using the one from zlib.net doesn't work, because it's not 64-bit, and I'd prefer having a 64-bit executable in the end.
Has anybody tried building librespot on Windows recently? Any ideas on how to do this?

Anybody made any progress with this?

I've been working on a (partial) rewrite which, among other things, should support windows (got rid of protobuf and portaudio dependencies). I've just pushed it branch v0.2. You'll probably need a nightly rust to try it.
I've only tried cross compiling using mingw. The audio wasn't completely smooth on my vary slow VM, but it should be alright on a real machine.
There's probably some rough edges. Seeking and caching don't work yet. Oh and the AP is hardcoded to London, change https://github.com/plietar/librespot/blob/v0.2/src/connection/mod.rs#L68 if you don't live around there (use the first value from https://apresolve.spotify.com/).
If your run into any issues, please let me know, preferably on gitter rather than creating a new issue since this is still a WIP.

I'm trying to cross-compile from ubuntu using mingw as well, I'm using the latest rustc nightly, but I'm getting compilation errors. I'm not to clear on all the options described, so I've tried various cargo commands, each fails in its own way.
using the command I think is correct: "cargo build --no-default-features --features "nightly with-syntex" --target=x86_64-pc-windows-gnu --release", it fails building simple-signal.
"error[E0432]: unresolved import self::platform::*
--> /home/kingmob/.cargo/registry/src/github.com-1ecc6299db9ec823/simple-signal-1.0.6/src/lib.rs:100:5
|
100 | use self::platform::*;
|     ^^^^^^^^^^^^^^^^^^ Maybe a missing extern crate platform;?
"
I assume that it is not actually missing an extern, so I'm not quite sure what is wrong here.


Update testing suite

This cleans up the dependencies in composer.json so that we can use php 8.2 during testing. I also added some configuration for codeception to generate code coverage reports and got all the utility class methods tested:

Going forward, this should really help make sure that we're testing things properly.

@tarecord also note the composer caching would not work for this currently:

Ignore this if you're planning to update to https://github.com/stellarwp/uplink/pull/67 after the fact.

Need to update to the new outputs format for this.
This project doesn't have a composer.lock file, so this needs to be updated to use composer.json instead.
Also best to update all actions/checkout@v2 to actions/checkout@v4 and actions/cache@v2 to actions/cache@v4 as the older versions are using deprecated ways to do things.


Fix incompatibility with Bazel 6

Adds a missing None to an otherwise failing getattr.

@stefanbucur Could you create a 0.5.2 release with this fix? Turns out that it does block a few other Google repos from being added to the BCR.

Oops, let me do this now.


error while writing response

Hi team , the proxify writing response error
OS:win11
CMD:   .\proxify.exe -ha ":18888"
VERSION: v0.0.15
I can not receive response when visit website(http/https) , error message as follow:
                      _ ___
   ___  _______ __ __ (_) _/_ __
  / _ \/ __/ _ \\ \ // / _/ // /
 / .__/_/  \___/_\_\/_/_/ \_, /
/_/                      /___/

                projectdiscovery.io

[INF] Current proxify version v0.0.15 (latest)
[INF] HTTP Proxy Listening on :18888
[INF] Saving proxify logs to proxify_logs.jsonl
[ERR] martian: got error while writing response back to client: http: ContentLength=9678 with Body length 5581
[ERR] martian: got error while writing response back to client: http: read on closed response body
[ERR] martian: got error while writing response back to client: http: read on closed response body
[ERR] martian: got error while writing response back to client: http: ContentLength=7876 with Body length 3779
[ERR] martian: got error while writing response back to client: http: ContentLength=8187 with Body length 4090
[ERR] martian: got error while writing response back to client: http: read on closed response body
[ERR] martian: got error while writing response back to client: readfrom tcp <IP_ADDRESS>:18888-><IP_ADDRESS>:10335: http: read on closed response body
[ERR] martian: got error while writing response back to client: http: read on closed response body
[ERR] martian: got error while writing response back to client: http: read on closed response body
[ERR] martian: got error while writing response back to client: http: ContentLength=10508 with Body length 6411
[ERR] martian: got error while writing response back to client: http: read on closed response body
[ERR] martian: got error while writing response back to client: readfrom tcp <IP_ADDRESS>:18888-><IP_ADDRESS>:10363: http: read on closed response body
[ERR] martian: got error while writing response back to client: http: read on closed response body

The same problem occurs in both next configurations:
OS=win10 22H2 19045.3803, Proxify=version v0.0.15 (latest)
OS=AlmaLinux release 9.4 (Seafoam Ocelot), Proxify=version v0.0.15 (latest)


Refactor to use techpatterns.com's database

Uses the same database as https://github.com/skratchdot/random-useragent from  http://chrispederick.com/work/user-agent-switcher/
Fix #4
I can also help in maintaining and releasing this gem.

@debbbbie please have a look ;)

@brauliobo thanks

@debbbbie can you release a new version?

@brauliobo 0.1.6 is released, please make a test and enjoy it!


Fix CI

Executing /home/vsts/work/1/s/startup/00-startup.py in CI
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-1-19fca0ca65e8> in <module>
     11         raise FileNotFoundError(f'File {f} cannot be found.')
     12     print(f'Executing {f} in CI')
---> 13     ip.parent._exec_file(f)

~/miniconda/envs/collection-2021-1.0/lib/python3.7/site-packages/IPython/core/shellapp.py in _exec_file(self, fname, shell_futures)
    378                                                  self.shell.user_ns,
    379                                                  shell_futures=shell_futures,
--> 380                                                  raise_exceptions=True)
    381         finally:
    382             sys.argv = save_argv

~/miniconda/envs/collection-2021-1.0/lib/python3.7/site-packages/IPython/core/interactiveshell.py in safe_execfile(self, fname, exit_ignore, raise_exceptions, shell_futures, *where)
   2740                 py3compat.execfile(
   2741                     fname, glob, loc,
-> 2742                     self.compile if shell_futures else None)
   2743             except SystemExit as status:
   2744                 # If the call was made with 0 or None exit status (sys.exit(0)

~/miniconda/envs/collection-2021-1.0/lib/python3.7/site-packages/IPython/utils/py3compat.py in execfile(fname, glob, loc, compiler)
    166     with open(fname, 'rb') as f:
    167         compiler = compiler or compile
--> 168         exec(compiler(f.read(), fname, 'exec'), glob, loc)
    169
    170 # Refactor print statements in doctests.

~/work/1/s/startup/00-startup.py in <module>
      4 configure_base(get_ipython().user_ns, 'local',
      5                configure_logging=False,
----> 6                ipython_exc_logging=False)
      7 bec.disable_plots()
      8

TypeError: configure_base() got an unexpected keyword argument 'ipython_exc_logging'

@AbbyGi, do you remember why we had to use these kwargs to nslsii.configure_base(...) in the past?

@AbbyGi, I am going to self-merge it, but if you have a chance to remember why we added those logging parameters, that would be great. I think there was a temporary issue with too verbose logging, so we tried to disable that completely. I think right now it works as expected.

@mrakitin I don't 100% remember why we used those kwargs, but I think I was getting errors without them that probably had to do with the configuration I was using. Looks like profile_simulated_hardware was doing a similar thing here.


Font Request: Geist by Vercel

Font Name
Geist
Link to font source
https://github.com/vercel/geist-font
Link to font license
https://github.com/vercel/geist-font/blob/main/LICENSE.TXT
Additional context
Both the Geist Sans and Geist Mono.

Duplicate of #46.


When installing locally I get a fatal error from git when running "npm run packages"

Bug description
roman@Ubuntu20:~/github.com/deep-foundation/dev$ npm run packages

><EMAIL_ADDRESS>packages
> (npx gulp packages:get) && (npx gulp packages:ci)

[15:32:12] Requiring external module ts-node/register
[15:32:13] Using gulpfile ~/github.com/deep-foundation/dev/gulpfile.ts
[15:32:13] Starting 'packages:get'...
[15:42:03] 'packages:get' errored after 9.82 min
[15:42:03] Error: Cloning into '/home/roman/github.com/deep-foundation/dev/packages/deep-memo-app'...
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
fatal: clone of 'https://github.com/deep-foundation/deep-memo-app' into submodule path '/home/roman/github.com/deep-foundation/dev/packages/deep-memo-app' failed
Failed to clone 'packages/deep-memo-app'. Retry scheduled
Cloning into '/home/roman/github.com/deep-foundation/dev/packages/deepcase-app'...
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
fatal: clone of 'https://github.com/deep-foundation/deepcase-app' into submodule path '/home/roman/github.com/deep-foundation/dev/packages/deepcase-app' failed
Failed to clone 'packages/deepcase-app'. Retry scheduled
Cloning into '/home/roman/github.com/deep-foundation/dev/packages/deeplinks'...
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
fatal: clone of 'https://github.com/deep-foundation/deeplinks.git' into submodule path '/home/roman/github.com/deep-foundation/dev/packages/deeplinks' failed
Failed to clone 'packages/deeplinks'. Retry scheduled
Cloning into '/home/roman/github.com/deep-foundation/dev/packages/gh-pages'...
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
fatal: clone of 'https://github.com/deep-foundation/deepcase.github.io.git' into submodule path '/home/roman/github.com/deep-foundation/dev/packages/gh-pages' failed
Failed to clone 'packages/gh-pages'. Retry scheduled
Cloning into '/home/roman/github.com/deep-foundation/dev/packages/sdk'...
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
fatal: clone of 'https://github.com/deep-foundation/sdk.git' into submodule path '/home/roman/github.com/deep-foundation/dev/packages/sdk' failed
Failed to clone 'packages/sdk'. Retry scheduled
Cloning into '/home/roman/github.com/deep-foundation/dev/packages/deep-memo-app'...
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
fatal: clone of 'https://github.com/deep-foundation/deep-memo-app' into submodule path '/home/roman/github.com/deep-foundation/dev/packages/deep-memo-app' failed
Failed to clone 'packages/deep-memo-app' a second time, aborting

    at Object.action (/home/roman/github.com/deep-foundation/dev/node_modules/simple-git/src/lib/plugins/error-detection.plugin.ts:38:28)
    at PluginStore.exec (/home/roman/github.com/deep-foundation/dev/node_modules/simple-git/src/lib/plugins/plugin-store.ts:24:29)
    at /home/roman/github.com/deep-foundation/dev/node_modules/simple-git/src/lib/runners/git-executor-chain.ts:114:40
    at new Promise (<anonymous>)
    at GitExecutorChain.handleTaskData (/home/roman/github.com/deep-foundation/dev/node_modules/simple-git/src/lib/runners/git-executor-chain.ts:111:14)
    at GitExecutorChain.<anonymous> (/home/roman/github.com/deep-foundation/dev/node_modules/simple-git/src/lib/runners/git-executor-chain.ts:88:40)
    at Generator.next (<anonymous>)
    at fulfilled (/home/roman/github.com/deep-foundation/dev/node_modules/simple-git/src/lib/runners/git-executor-chain.js:5:58)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

Expected Behavior
No response
Current Behavior
No response
Steps to reproduce
No response
Workaround
Local usage
Installation

Install node 18 (we recommend to use [nvm](https://github.com/nvm-sh/nvm#installing-and-updating))

Install docker and docker-compose
If you have Docker Desktop with docker compose (not docker-compose) you should enable this setting in Docker Desktop: image Or use this command (if your are on linux):

echo 'docker compose --compatibility "$@"' | sudo tee -a /usr/local/bin/docker-compose && sudo chmod +x /usr/local/bin/docker-compose

[Install docker on Ubuntu](https://docs.docker.com/engine/install/ubuntu/) or use this commands:

sudo apt update
sudo apt install -y git curl docker.io docker-compose

Optionally set up docker group and add user to this group (it may be done automatically on installation):

sudo groupadd docker
sudo usermod -aG docker $(whoami)

These commands must be able to run without sudo, if it is not the case restart computer or relogin as user.

docker run hello-world
docker rm $(docker ps -a -q --filter "ancestor=hello-world")
docker image rm hello-world

Run this script to initialize and launch deep

git clone https://github.com/deep-foundation/dev.git
cd dev
npm ci
rm -rf packages/deepcase
rm -rf packages/deepcase-app
rm -rf packages/deeplinks
npm run packages

Environment
Linux Ubuntu20 5.15.0-91-generic #101~20.04.1-Ubuntu SMP Thu Nov 16 14:22:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

roman@Ubuntu20:~/github.com/deep-foundation/dev$ git show
commit 18207b70274d637b1e081cf63054e1b95dd41171 (HEAD -> main, origin/main, origin/HEAD)
Author: Konstantin Dyachenko<EMAIL_ADDRESS>Date:   Fri May 3 01:19:12 2024 +0000

    sync

diff --git a/package-lock.json b/package-lock.json
index ba987f3..a580692 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -53383,7 +53383,7 @@
     },
     "packages/deepcase": {
       "name": "@deep-foundation/deepcase",
-      "version": "0.0.115",
+      "version": "0.0.118",
       "license": "Unlicense",
       "dependencies": {
         "@amcharts/amcharts5": "^5.5.1",
@@ -53480,14 +53480,14 @@
         "node": "^18"
       },
       "peerDependencies": {
-        "@deep-foundation/deeplinks": "0.0.*",
+        "@deep-foundation/deeplinks": "0.0.x",
         "next": "^14.2.2",
         "react": "*"
       }
     },
     "packages/deepcase-app": {
       "name": "@deep-foundation/deepcase-app",
-      "version": "0.1.0-beta.18",
+      "version": "0.1.0-beta.19",
       "license": "Unlicense",
       "dependencies": {
<EMAIL_ADDRESS>"^0.8.2",
@@ -54052,7 +54052,7 @@
     },
     "packages/deeplinks": {
       "name": "@deep-foundation/deeplinks",
-      "version": "0.0.338",
+      "version": "0.0.340",
       "license": "Unlicense",
       "dependencies": {
         "@chainsafe/libp2p-yamux": "^6.0.2",
diff --git a/packages/deepcase b/packages/deepcase
index cf7d2f4..78df971 160000
--- a/packages/deepcase
+++ b/packages/deepcase
@@ -1 +1 @@
-Subproject commit cf7d2f4a834d8de8270b97705cefb6e89b3f5ed0

Можно уменьшить объем скачиваемых сабмодулей используя git clone --depth 1


fix double quoting strings in HTTP headers

Description
Before a header like {'string': 'some-string'} would result in the header: {'string': '"some-string"'}. This PR fixes this and returns the correct header {'string': 'some-string'}.
Checklist

[x] I have run this code in development and it appears to resolve the stated issue
[x] This PR includes tests, or tests are not required/relevant for this PR
[ ] I have updated the CHANGELOG.md and added information about my change to the "dbt-databricks next" section.

Thanks! merging.


Version bump and cloud firestore dependency bump

Cloud firestore version bump
Did a flutter test to make sure everything works

merged and published thanks.


Fix deprecated webpack warnings

Fix #295
Content:

Fix deprecation warnings
Code formatting

@nicholasrq @hlomzik can someone please review it?


Incomplete Icon Set

Hi, i noticed this particular icon isn't listed.

also the screenshot used in the Readme is quite misleading as most of them are also missing.

I also notice that. wanted to use the icons for a project of mine but it is missing quite a few icons.


⚠ api.piste.gouv.fr healthcheck has degraded performance

In 9494697, api.piste.gouv.fr healthcheck (https://api.piste.gouv.fr/cassation/judilibre/v1.0/healthcheck) experienced degraded performance:

HTTP code: 200
Response time: 2833 ms

Resolved: api.piste.gouv.fr healthcheck performance has improved in 9315606.


Attempt to fulfill the request of sagas-thunks use cases

Fulfilling @markerikson twitter request https://twitter.com/acemarke/status/1013801105162108928
It may be no sense or even garbage, but at least I wanted to give it a try.
If you think it's something acceptable, you can let me know what to improve.

Thanks, appreciate the PR!
Let's see.  My first observation is that I'd prefer to put this in an existing FAQ page.  The "Actions" page makes the most sense, since that's where we already discuss using middleware for async behavior.
Second, I'd suggest condensing this a bit into one larger question+answer:  "What async middleware should I use? How do you decide between thunks, sagas, observables, or something else?".
Go ahead and update the PR to move this content over to the "Actions" page instead, and condense it into one larger question.  We'll see what else needs to be done from there.

Yeah, I agree that placing it into the "Actions" page make more sense! I think I just misinterpreted your tweet :)
Anyway wouldn't be this title more precise?
"What side effect middleware should I use? How do you decide between thunks, sagas, observables, or something else?"
Since middleware are not used just to perform async logic.
PS. pr is coming :)

any news? @markerikson :)

Sorry about that, forgot this was here.  Sure, let's get it in.


Shader code is not compatible in webgpu mode

float Get3DNoise(vec3 pos)
{
float p = floor(pos.z);
float f = pos.z - p;
const float invNoiseRes = 1.0 / 64.0;

float zStretch = 17.0 * invNoiseRes;

vec2 coord = pos.xy * invNoiseRes + (p * zStretch);

vec2 noise = vec2(texture(iChannel0, coord).x, texture(iChannel0, coord + zStretch).x);

return mix(noise.x, noise.y, f);

}
example url:
https://playground.babylonjs.com/#MSV6UG#18

As indicated in the template, please first discuss the issue in our forums so that it can benefit the whole community.


How to scale time axis in Pulse Wave Doppler mode

Looking to get a time measurement in milliseconds on pulse wave doppler mode. Using the pinch gesture for the x axis doesn't seem to work. Is there another way?

you can measure using the tools from the tools menu, if you want to change the LRF, you can go to modes menu and find the sweep speed toggle

Is there a way to scale the x-axis to more accurately measure time using the tools?

Just the sweep toggle


Include nbserverproxy or describe how to use it in the docs

See https://github.com/dask/dask-jobqueue/issues/80#issuecomment-400797727.
To prevent from doing a lot of ssh tunneling, using nbserverproxy could be helpful!

Cross referencing the work of @jhamman on https://github.com/pangeo-data/pangeo/pull/304 here, this already work in progress!

Probably worth linking this comment as well since that has a little more details about how to set it up. Not that there is much to setup at all.

@jakirkham, I tried nbserverproxy with no luck, as mentionned in pangeo thread. Could you look at it to see if you're doing things differently? I'll give it another go when I have some time.

@guillaumeeb I was the same. I ended up opening an issue over there https://github.com/jupyterhub/nbserverproxy/issues/45 but closed it once I had the ssh solution working.

Okay, so I've found the problem with my setup : Dask dashboard was bind to a given network interface, but apparently nbserverproxy was not able to proxy to this one, it was probably trying another interface, don't know why though.
So in order to make nbserverproxy work, I add to use the trick described in #90: bind the dashboard to all interfaces.

@raybellwaves, could you give another go to nbserverproxy solution, now that #119 is in master?

I haven't actually used jupyterhub before so you may want to ask someone with more experience than I. I still gave it a go though and my build notes from scratch are below. I made it as far as to 'sign up with github button' but it wasn't really responding after that
$ conda create -n djq_nbs python=3.6
$ conda activate dqj_nbs
$ pip install git+https://github.com/dask/dask-jobqueue.git
$ conda install -c conda-forge psutil jupyterhub nbserverproxy bokeh
$ pip install install oauthenticator
$ jupyter serverextension enable --py nbserverproxy
$ jupyterhub --generate-config

# Not sure if now needed with github login method
$ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -subj '/CN=XX.XXX.XXX.XXX'
# Horrible hack to get rid of bad password phrase error when starting jupyterhub ( https://github.com/jupyterhub/jupyterhub/issues/1134; https://github.com/mcollina/mosca/issues/421)
$ cp key.pem key.old.pem
$ openssl rsa -in key.pem -out newkey.pem

# use github for logging in https://github.com/settings/applications/new
# Setup as environmental files (in your .bashrc
OAUTH_CALLBACK_URL=https://XX.XXX.XXX.X:8000/hub/oauth_callback
GITHUB_CLIENT_ID=xxx
GITHUB_CLIENT_SECRET=xxx

# edit jupyterhub_config.py:
import os
from oauthenticator.github import GitHubOAuthenticator
c.JupyterHub.authenticator_class = GitHubOAuthenticator
c.MyOAuthenticator.oauth_callback_url = 'https://XX.XXX.XXX.X:8000/hub/oauth_callback'
c.MyOAuthenticator.client_id = 'XXX'
c.MyOAuthenticator.client_secret = 'XXX'
c.JupyterHub.admin_access = True
c.Authenticator.admin_users = {'GITHUBUSERNAME'}
c.JupyterHub.ssl_key = 'newkey.pem'
c.JupyterHub.ssl_cert = 'cert.pem'
c.Authenticator.whitelist = {'GITHUBUSERNAME'}
c.LocalAuthenticator.create_system_users = True

$ jupyterhub --ip XX.XXX.XXX.XXX --port 8000

# On laptop open https://XX.XXX.XXX.XXX:8000

@raybellwaves ah sorry, I did not make myself clear enough. I just wanted you to test the nbserverproxy solution with your current procedure : user launched notebook. Something like that :
pip install git+https://github.com/dask/dask-jobqueue.git
pip install nbserverproxy
jupyter serverextension enable --py nbserverproxy
jupyter lab --no-browser --ip=`hostname` --port=8888

Do the ssh tunneling thing to access to your notebook (and only your notebook). Then in your notebook, launch Dask using jobqueue, and go to
http://localhost:8888/proxy/8787/status

or wathever port Dask Dashboard has been launched to.

No problem. I've been meaning to try jupyterhub for a while anyway so it was a good learning experience.
Ok. I'll give it a go later or tomorrow.

That's better.
Were your workers started at that moment?

Yes. I just checked again.
Actually it works now if I just click on the dashboard link

I may do a quick test without nbserverproxy. I think your recent PR's helped my problem in https://github.com/dask/dask-jobqueue/issues/116#issue-347245340

@raybellwaves it looks like you're not using nbserverproxy in your last comment. Is is probably as you say, just the binding to all interface that solved your problem.
Could you try again with the http://localhost:8888/proxy/dashboardport/status URL? Maybe its what you just did and there still was a problem?

it looks like you're not using nbserverproxy in your last comment

Correct. It seems to work without nbserverproxy for me now.

Could you try again with the http://localhost:8888/proxy/dashboardport/status URL?

Yes. I made sure that my jobs were running. I still get the empty dashboard as shown above
I don't think I am missing something in the setup of the nbserverproxy?

Yes. I made sure that my jobs were running. I still get the empty dashboard as shown above
I don't think I am missing something in the setup of the nbserverproxy

You could be on a dashboard from another cluster, maybe the dashboard port is not the right one.

It sounds like this is a bug fixed in master. Though downgrading should be equally effective at resolving the issue.
xref: https://github.com/jupyterhub/nbserverproxy/issues/39


T05a.03 TODO 1 description not complete

The first TODO in T05a.03 reads:
// TODO (1) Declare and instantiate an ArrayList of Strings called mLifecycleCallbacks
It should read:
// TODO (1) Declare and instantiate a static ArrayList of Strings called mLifecycleCallbacks
This code doesn't work if the ArrayList isn't static.

Good point! Fixed in https://github.com/udacity/ud851-Exercises/commit/0da96dbc19196ce21eed44b141e3fa6b6f0f34dc


build-and-test is failing

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I'm convinced that this is not my fault but a bug.

Description
build-and-test action is failing in the main branch since this PR was merged. I don't know why it passed in the CI from the PR, but the build also fails locally as well.
failing action: https://github.com/autowarefoundation/autoware.universe/actions/runs/11586899175/job/32258240074
Expected behavior
build-and-test CI passes.
Actual behavior
build-and-test CI failes
Steps to reproduce

Build autoware locally
I get the following error messages:

/home/mitsudome-r/autoware/src/universe/autoware.universe/perception/autoware_traffic_light_arbiter/test/test_node.cpp: In function ‘void generateMap(LaneletMapBin&)’:
/home/mitsudome-r/autoware/src/universe/autoware.universe/perception/autoware_traffic_light_arbiter/test/test_node.cpp:53:19: error: ‘lanelet::utils::conversion’ has not been declared
   53 |   lanelet::utils::conversion::toBinMsg(vector_map_ptr, &vector_map_msg);
      |                   ^~~~~~~~~~
gmake[2]: *** [CMakeFiles/autoware_traffic_light_arbiter_test.dir/build.make:76: CMakeFiles/autoware_traffic_light_arbiter_test.dir/test/test_node.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:185: CMakeFiles/autoware_traffic_light_arbiter_test.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
---
--- stderr: autoware_traffic_light_arbiter
/home/mitsudome-r/autoware/src/universe/autoware.universe/perception/autoware_traffic_light_arbiter/test/test_node.cpp: In function ‘void generateMap(LaneletMapBin&)’:
/home/mitsudome-r/autoware/src/universe/autoware.universe/perception/autoware_traffic_light_arbiter/test/test_node.cpp:53:19: error: ‘lanelet::utils::conversion’ has not been declared
   53 |   lanelet::utils::conversion::toBinMsg(vector_map_ptr, &vector_map_msg);
      |                   ^~~~~~~~~~
gmake[2]: *** [CMakeFiles/autoware_traffic_light_arbiter_test.dir/build.make:76: CMakeFiles/autoware_traffic_light_arbiter_test.dir/test/test_node.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:185: CMakeFiles/autoware_traffic_light_arbiter_test.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
---
Failed   <<< autoware_traffic_light_arbiter [25.5s, exited with code 2]

Versions

Ubuntu 22.04
ROS 2 Humble
Autoware.Universe commit hash: https://github.com/autowarefoundation/autoware.universe/commit/e58a158eb9d993bf4a066b910affa74f51a3f7e5

Possible causes
Missing include file from autoware_lanelet2_extension
Additional context
No response

No more issue to the build and test ci, so closing.


[CI] Only install Mosek if license is available

Since Github action secrets are not copied to forks, the CI fails on PRs after adding Mosek.
This PR skips the Mosek install in case the secret is not available. It is not an ideal solution, as there is some chance that a test only fails on Mosek after the PR is merged.

LGTM.


[24.05] python3Packages.imap-tools: unbreak

Cherry-picks to get it to build again.
Fixes #354725
Things done

Built on platform(s)

[x] x86_64-linux

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 354728 run on x86_64-linux 1

1 package failed to build:

paperless-ngx

8 packages built:

python311Packages.deltachat
python311Packages.deltachat.dist
python311Packages.imap-tools
python311Packages.imap-tools.dist
python312Packages.deltachat
python312Packages.deltachat.dist
python312Packages.imap-tools
python312Packages.imap-tools.dist

@ofborg build paperless-ngx
I can build it locally. But there's nothing obvious in the diff.

@ofborg build paperless-ngx
I can build it locally. But there's nothing obvious in the diff.

I can confirm that the PR builds paperless-ngx locally successfully (I haven't tried whether the imap-tools dependency actually does anything useful, though).
I'm wondering where I should be looking for the error that was mentioned by the nixpkgs-review comment ...

You can check the PR corresponding to the last cherry-pick

We don't need to backport all the updates, we just need to backport disabling the broken test (5dd7acc523425ad1e565a90eee8afb9d4b928a96).
What's really confusing here though is that this test shouldn't be broken on 24.05; it's only supposed to happen with python 3.12 and the default for 24.05 is python 3.11. What gives?
cc @mweinelt

That is not the broken test though.
_____________________ UtilsTest.test_parse_email_addresses _____________________

self = <tests.test_utils.UtilsTest testMethod=test_parse_email_addresses>

    def test_parse_email_addresses(self):
>       self.assertEqual(
            parse_email_addresses('=?UTF-8?B?0J7Qu9C1=?= <name@company.ru>,\r\n "\'\\"z, z\\"\'" <ya@ya.ru>\f'),
            (EmailAddress('Оле', 'name@company.ru'),
             EmailAddress('\'"z, z"\'', 'ya@ya.ru'))
        )
E       AssertionError: Tuples differ: () != (EmailAddress(name='Оле', email='name@comp[55 chars]ru'))
E
E       Second tuple contains 2 additional elements.
E       First extra element 0:
E       EmailAddress(name='Оле'<EMAIL_ADDRESS>E
E       - ()
E       + (EmailAddress(name='Оле', email='name@company.ru'),
E       +  EmailAddress(name='\'"z, z"\'', email='ya@ya.ru'))

tests/test_utils.py:110: AssertionError

That's exactly the failure we're seeing on stable though:
=================================== FAILURES ===================================
_____________________ UtilsTest.test_parse_email_addresses _____________________

self = <tests.test_utils.UtilsTest testMethod=test_parse_email_addresses>

    def test_parse_email_addresses(self):
>       self.assertEqual(
            parse_email_addresses('=?UTF-8?B?0J7Qu9C1=?= <name@company.ru>,\r\n "\'\\"z, z\\"\'" <ya@ya.ru>\f'),
            (EmailAddress('Оле', 'name@company.ru'),
             EmailAddress('\'"z, z"\'', 'ya@ya.ru'))
        )
E       AssertionError: Tuples differ: () != (EmailAddress(name='Оле', email='name@comp[55 chars]ru'))
E
E       Second tuple contains 2 additional elements.
E       First extra element 0:
E       EmailAddress(name='Оле'<EMAIL_ADDRESS>E
E       - ()
E       + (EmailAddress(name='Оле', email='name@company.ru'),
E       +  EmailAddress(name='\'"z, z"\'', email='ya@ya.ru'))

Then I misunderstand why it disables tests_utils or maybe that is way to pass the whole module to pytest. cc @K900

Okay it seems this was caused by a patch in python for a CVE. Upstream has this patch which they released in 1.7.4:
https://github.com/ikvk/imap_tools/commit/3e4f9142f4486f5e487461e74244cfca574b0d93
I'll try just backporting the fix.

@ofborg build paperless-ngx

https://github.com/NixOS/nixpkgs/pull/355108

Paperless-ngx is deployed with the linked patch on my server right now. Hexa backported the required patch.
This does not unbreak anyhing anymore. I did miss that this disables a flaky test which could be useful.


FIX: Fix division

Hopefully this makes Travis happy

Fixes the 3.4 division problem, now I'm working on the 2.7 full scipy import problem...

Looks like latest commit fixes the Travis issue, will merge if CIs come back happy so that other PRs can be evaluated properly.


After renaming files, fuzzy finder can't find them.

I had a file Approvals/queue.tpl that I renamed using the tree-view. I renamed it to Approvals/index.tpl.
After renaming the file, I opened up the fuzzy finder and tried to open the file, and the fuzzy finder could not find the file.

If I searched for approvals/queue.tpl it would show a result and allow me to open it, but it resulted in opening a blank file.
After restarting Atom, it was able to find approvals/index.tpl.

Hi. This library assume it has been feed a valid list of file name. Then search in that list.
If the list is cached and not updated fast enougth then I think it's a fuzzy finder issue.
I'll close this, if there's a problem with actual search I'll reopen.


How to disable/enable "All Workflows" at once?

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
I was not able to find any information on how to disable [All Workflows] under the Actions menu.
This is a really important feature, as any user who forks from https://github.com/Azure/ResourceModules repo will get more than 255+ emails with the header "Run failed: XYZ Description - main".
And if I want to disable those 255+ workflows it will take me close to 50 minutes to do that :(
In addition, this is a waste of GitHub resources to run those automated workflows on each new fork.
Thus, I propose to introduce/enable functionality on the "All Workflows" level that could basically, disable and enable all workflows.
Plus, disable all workflows on newly forked repositories to save the processing power of the GitHub platform,
Please, let me know where to raise this concern, as it is very beneficial for the community, and for GitHub. Thanks!
What changes are you suggesting?
I suggest to introduce/enable functionality on the "All Workflows" level that could basically, disable and enable all workflows.
Plus, disable all workflows on newly forked repositories to save the processing power of the GitHub platform,
Additional information
Please, let me know where to raise this concern, as it is very beneficial for the community, and for GitHub. Thanks!

@ElYusubov Thanks for opening an issue! We maintain the Docs site, so if you have any suggestions for how we can update the Docs, please let us know. 👍
Otherwise, the best place to send your feedback is to https://github.com/community/community/discussions 💖
I'm going to go ahead and close this issue now 💛


Expected behaviour of Async functions in the template

Hi,
Is it possible to explain the expected behaviour of the async functions in the template. I'm unable to find documentation and we in our team feel that the expected behaviour is different from how it's currently implemented.
When using the async functions, the callbacks from these functions are executed after all of the components lifecycle events have been fired. We encountered this when trying to perform actions on a components position in a lifecycle event but noticed that the values were either 0 or would return the actual async function. We were trying to perform an animation on a value which was being return as a function so this completely broke.
I've attached a very basic version where you can see that in the template the width and height are used at the root of the template and all other components are using the async functions for these values. In the _init function I am printing out the value so you can see the results.
I would expect that the async functions would be executed prior to the lifecycle events being fired but it is the other way around.
Could you please clarify what is the expected behaviour?
import { Lightning, Utils } from 'wpe-lightning-sdk'

export default class App extends Lightning.Component {
  static getFonts() {
    return [{ family: 'Regular', url: Utils.asset('fonts/Roboto-Regular.ttf') }]
  }

  static _template() {
    return {
      w: 1920,
      h: 1080,
      Background: {
        w: w => {
            console.log('Background Async Fired (W): ', w)
            return w;
        },
        h: h => {
            console.log('Background Async Fired (h): ', h)
            return h;
        },
        color: 0xfffbb03b,
        src: Utils.asset('images/background.png'),
      },
      Text: {
        mount: 0.5,
        x: x => {
            console.log('Text Async Fired (X): ', x)
            return x / 2;
        },
        y: y => {
            console.log('Text Async Fired (Y): ', y)
            return y / 2;
        },
        text: {
            text: "Async function example",
            fontFace: 'Regular',
            fontSize: 64,
            textColor: 0xbbffffff,
        },
      },
        Logo: {
          w: 250,
          h: 250,
          x: 1920 / 2,
          y: h => h / 3,
          mount: 0.5,
          src: Utils.asset('images/logo.png')
        }
    }
  }

  _build() {
      this._background = this.tag('Background')
      this._text = this.tag('Text')
      this._logo = this.tag('Logo')
  }

  _init() {
      console.log('Background (W) :', this._background.w)  // This value will be 0 at this point as the async function for W has not been completed
      console.log('Background (H) :', this._background.h) // This value will be 0 at this point as the async function for W has not been completed
      console.log('Text (X) :', this._text.x) // This will return the async function. Trying to perform any action on this value will be invalid
      console.log('Text (Y) :', this._text.y) // This will return the async function. Trying to perform any action on this value will be invalid
      console.log('Logo (X) :', this._logo.y) // This will return the async function. Trying to perform any action on this value will be invalid

      // Now if i attempt to animate the logo on the Y axis it will fail and not render as I am trying to use the Y value which at this point is a function
      // rather than a number.
      this._logo.setSmooth('y', 900, { duration: 10 })

      // Instead if i force the Y position without using an animation it will work as I am replacing the async function with a number
      // this._logo.y = 900 <-- This will work, you must comment out line 67 though!
  }
}

Hi @dale976,
According to documentation:

You can use a numeric value (in pixels), but it is also possible to specify a function that returns the value based on the parent's width (x, w) or height (y, w). These functions will only be called again if the parent's dimensions (might) change.

There are 4 properties that can have a function assigned to them instead of a value: x, y, w and h. The function will be called internally with either parent's width (for x and w) or height (for y and h) as argument and should return child's final value, e.g:
{
  w: (parent_w) => parent_w / 2 // child's width should always be half of its parent,
  x: (parent_w) => parent_w / 2 // child's x should always be positioned in the middle
}

This means they can be used when you want your element to be positioned or have size in some relation to its parent's dimensions (example)
Now, when it comes to animation:

Every action should have a v property specified, which defines the value that is applied to the action property during the animation.
You can specify:

a fixed value ({p: 'visible', v: true, rv: false})
a function ({p: 'alpha', v: (p => Math.sqrt(p)})
a literal value object, defining the value several progress control points

Since in your case y is a dynamic function it cannot be used by animation handler (it cannot interpolate values of a function).
Possible solution to your problem would be wrapping your logo in additional element and have it fixed y while relative position would be maintained by the wrapper, e.g:
  LogoWrapper {
    x: 1920 / 2,
    y: h => h / 3,
    Logo: {
      y: 0,
      w: 250,
      h: 250,
      mount: 0.5,
      src: Utils.asset('images/logo.png')
  }
}

Let me know if you have any further questions.
Best regards

Hi @g-zachar ,
Thanks for taking the time to give a detailed response and example.


Implement installer.0 role.

This allows one to place the ceph ansible installer node on another machine.
It defaults back to the lowest monitor if there is no installer.0 role.
Signed-off-by: Warren Usui<EMAIL_ADDRESS>

@wusui has this been tested yet?

This has been tested running with installer.0 on its own machine, with installer.0 on the mon.a machine, installer.0 on a machine where mon.a was not running, and without installer.0 (so it defaults to mon.a).

@wusui can you add a link to tests ?


Remove excessive notifications (toasts)

This line is taken from a comment by @sanderaido on issues #77
I would also apply this logic to everywhere else, where the outcome of the action is as expected (for example any Resource/Outcome/whatever add/update dialog) - when update succeeded (which is the normal and expected behaviour), congratulating a user each time that our system is actually working as it should seems a little unnecessary (and would get annoying over time as well - if it works, great - no need to tell me every time I do something). Gives a more professional feel as well.
But ultimately this should be decided by @vtomberg

Seems that all excessive toasts have been removed.


Enable background Mica or Acrylic

Background Mica and Acrylic is enabled as of WASDK 1.1

This probably won't happen soon
Activating it is quite clunky in the current version of the Windows App SDK (1.1.2), and requires a lot of platform dependency checks and PInvoke native API calls. Microsoft has said that this API will be simplified in a future release.

Article on activating Mica backdrops on win32 apps (including unpackaged), all example code is writted using C++/WinRT
API docs for the MicaController class (needed for enabling mica backdrops)
API docs for the DesktopAcrylicController class (needed for enabling acrylic backdrops)

Example code for checking whether or not mica or acrylic is compatible with the current system, enabling it, and accessing relevant APIs in C# is available in the WinUI 3 controls gallery.

I looked at the code for enabling acrylic and mica backdrops and while it's pretty stupid, I can pretty much just copy paste Microsoft's code for it.
I'll probably see if it's viable when i'm working on my next bug bash


Complete lab 10

Fixes #503
Review of colleague's PR #485
Changes proposed in this PR:
Implement lab10

If this PR is approved, please also take a look at: https://github.com/anz-bank/go-course/pull/489

@linuxmonk Could you review please?

@juliaogris Thanks for the review. Almost everything is fixed. In some cases, I just put comments as a response.

@juliaogris Thanks for reviews. They are awesome!

@juliaogris Could you review once again please?

Horray! Time to implement lab11. Thank you Julia


Support for Homebrew Formula

I have been investigating possibly allowing Mockolo to be installed via Homebrew. Are there any blockers to doing this? My strategy was to use the tarball creation script
./install-script.sh -s [source dir] -t mockolo -d [destination dir] -o [output filename]
To generate a tarball that the brew formula would install and then use homebrew's bin linking to make mockolo globally executable

It's a nice idea. I think there are no technical obstacles. On the other hand the formula might be not accepted for homebrew/core just yet. One of the requirements is for the formula to "be known". Maybe mockolo is already "known" - don't know :) Check out https://docs.brew.sh/Acceptable-Formulae for more info. It's quite common solution and allows to quickly upstream new versions.
Another option would be to create a custom tap, maybe Uber org (https://github.com/uber) already has one (I haven't checked); in that case the formula could be pushed there.

Can we just update the latest release with the output from ./install-script.sh -s [source dir] -t mockolo -d [destination dir] -o [output filename]. If we do that our teams can at least make their own taps and start using mockolo via homebrew

There's nothing preventing it; it's been on the todo list.  Looks like brew cask might be an option for a binary only distribution if we go down that road.  We can look into this soon.

Can I build a cask for you guys? Is that okay?

Can I build a cask for you guys? Is that okay?

Yes go ahead

Formula PR is here https://github.com/Homebrew/homebrew-core/pull/51274

This will not work, building the formula takes too long on CI to even pass, we need to create a Cask. Can we make a new tagged release with a tar.gz of the built binaries attached to it? I need that tar.gz to create the cask https://github.com/Homebrew/homebrew-cask/blob/master/doc/development/adding_a_cask.md

Added https://github.com/uber/mockolo/releases/download/1.1.5/mockolo.tar.gz

https://github.com/Homebrew/homebrew-cask/pull/78324

Fyi, the dylib in the same tarball, which is needed to run mockolo (and has to be in the same directory as the executable), requires xcode 11.0+ (swift 5.1+).

Okay I am attempting this again, https://github.com/Homebrew/homebrew-core/pull/51274 , I am not sure the build will finish in time, sometimes the swift build times out

Thanks for pushing the pr. Looks like all checks have passed, pending a final review.

Do you want to comment on that PR, I am not sure when they will get around to looking at it

done
On Wed, Mar 11, 2020 at 5:34 PM Maxwell Elliott<EMAIL_ADDRESS>wrote:

Do you want to comment on that PR, I am not sure when they will get around
to looking at it
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uber_mockolo_issues_97-23issuecomment-2D597947890&d=DwMCaQ&c=r2dcLCtU9q6n0vrtnDw9vg&r=sTqCC7cTwGN2QCw_Vq6sKQ&m=txt3XLy2Njco4q9WIERWY2BNj_kl9kP11qCGbqTY7Mk&s=dFnjmbZARdhuDmR1zMJCG3lDHLq3qeZSXa_rGcVbbHg&e=,
or unsubscribe
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAUG5PEW3BO7FG442P2JMQDRHAU25ANCNFSM4LBNKNWQ&d=DwMCaQ&c=r2dcLCtU9q6n0vrtnDw9vg&r=sTqCC7cTwGN2QCw_Vq6sKQ&m=txt3XLy2Njco4q9WIERWY2BNj_kl9kP11qCGbqTY7Mk&s=lyFPJ8wnmwiLLT1tKzbfm0p2HcD6CW3qXjV8csvjgGE&e=
.


add missing localization

this is a follow up of
https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1867
English localization is added for now
@hiura2023

Missing translations can be checked by CI?

We started that recently
On Wed, Sep 13, 2023, 06:16 metalefty @.***> wrote:

Missing translations can be checked by CI?
—
Reply to this email directly, view it on GitHub
https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1902#issuecomment-1716916749,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQ5KUFA4HRDUXMOSE5RN3TX2EXR3ANCNFSM6AAAAAA4VM6Y7E
.
You are receiving this because you authored the thread.Message ID:
@.***>

I can't get installer of "Softether VPN" from azure.
Errors are found in azure pipelines.
https://dev.azure.com/SoftEther-VPN/SoftEther VPN/_build?definitionId=6

yep. please try this build https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1905


Use tracectx instead of traceCtx in log fields

The core CP4NA microservices use tracectx.transactionId instead of traceCtx.transactionId. Ignition should be updated to use the same.

Fixed by #107


Searching by coordinates

It could be great if the BRouter-web was able to search for the points not only by an address or place name, but also by the coordinates in usual formats.
It is very common during solving the routing issues, that users provide coordinates. I have used them indirectly,  searching in google maps, locating the place, and searching it in the BRouter-web.
That is not very convenient..

Search/Geocoding is currently provided by Nominatim (via Leaflet Control Geocoder plugin), which is also used on osm.org.
With a quick search I found the resolved issue "Be generous in accepting coordinate formats" and from there the current implementation for coordinate support and some test cases.
So it does support coordinate input in some formats/variations. For missing formats I would suggest to open an issue for Nominatim (although I might switch to some other service with autocompletion in the future). Or maybe someone knows a JavaScript coordinate parser?

I guess the provided links are sufficient.


Update shared:core to 1.2.4

Updates com.softwaremill.sttp.shared:core from 1.2.2 to 1.2.4.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (1.2.2).
You might want to review and update them manually.
project/plugins.sbt

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.shared", artifactId = "core" } ]

labels: library-update, semver-patch, old-version-remains

Superseded by #324.


remove code that avoid saving the note

I've removed this check to ensure that notes are saved regardless of whether they have been created or not.
Previously, we checked if a note with the same ID exists in the database before saving.
However, this check was causing issues when a new note was being created.
By removing it, we allow all notes to be saved, whether they exist in the database or not.

I think the new notes not being saved is a feature. what problem is this trying to solve @gonzalovelasco ?

There's a cache and we want to save the note to the cache and then when I open a new note then it'll save the cache into the "database"

There's a cache and we want to save the note to the cache and then when I open a new note then it'll save the cache into the "database"

Save the cached note before opening a new one fe2ec9faa33bff414723ad926711d382b6fd5825

LGTM


add helper for using functions as builtins

This adds a function fn.Execute that can be used to run functions as builtins. There is an example of using this with the replacements function in go/fn/examples/example_builtin_function_test.go.
Fixes https://github.com/GoogleContainerTools/kpt/issues/2897

@yuwenma @mengqiy PTAL. This one is not blocked by https://github.com/GoogleContainerTools/kpt-functions-sdk/pull/534.


XXX/diffusion_pytorch_model.safetensors not found

vae/diffusion_pytorch_model.safetensors not found

Could you paste your python package versions here? With pip list?


WIP: Berlin 2023 recap

[x] missing group picture
[ ] missing correct Category
[x] review links in footer / signature
[ ] are there other examples of contributions?

I've checked some other packages but couldn't find any contribution time line similar to Stats.
If Beth already got all talk slides, we could add them to this repository and then promote/distribute the collection. But I agree, we should focus on getting the blog post finished soon. I'm happy with the github link to my profile.
@kMutagene I think for you it should be easy to solve the category issue, right?

I think for you it should be easy to solve the category issue, right?

What would be ideal for this? General ? Announcements?

What would be ideal for this? General ? Announcements?

Announcements :+1:

i pushed the addition of the category directly to this branch @mathias-brandewinder @bvenn. note that you can use any string for category, if it does not match our preset categories it will not have a description though, so adding a new one here made sense.