Introduce syntax for free variables

Right now a free variable in a type restriction is one with a single letter, optionally followed by a digit. For example:
def foo(x : T)
  T
end

foo(1) # => Int32
foo("hello") # => String

Here T takes the type of the argument x.
This is used for example to create an Array filled with an initial value:
class Array(T)
  def initialize(size : Int, value : T)
    # ...
  end
end

Array.new(3, 'a') # => ['a', 'a', 'a']

Here T isn't set (because we didn't do Array(Int32), we didn't specify T explicitly) so T becomes Char, and because T is also that T of Array(T), the returned array is Array(Char).
Another use case is Enumerable#map:
module Enumerable(T)
  def map(&block : T -> U)
    ary = [] of U
    each { |e| ary << yield e }
    ary
  end
end

Here U becomes the block's type, and so we can create an array of the block's type.
The problem with this single-letter convention is that a type like U can't exist, because if someone defines class U at the top level, then U isn't a free variable anymore: U doesn't take the block's type, but must be that class U.
Because of this last problem, we disallowed naming types with single letters at the top-level.
Another bad side-effect of this is that type arguments, like the T in Array(T), must only be single letter because in the Array#initialize example above we needed T to be a free variable but also match the type argument.
This feels like the language is limiting us too much.
For the case where T can either be a free variable or match a type argument, like in the Array#iniitalize example above, we could actually note that the T is a type argument, and we never match it against a top-level type named T. We can implement this right now and this is backwards compatible and solves part of the problem.
The problem still remains for that U that isn't a type argument but we still want to set to a type inferred by the compiler. Or the first foo example above.
I propose we introduce syntax to say "this is a free variable, please deduce the type of this". Possible syntax can be:
def foo(x : 'T)

def foo(x : `T)

def foo(x : %T)
def foo(x : ^T)
def foo(x : @T)
def foo(x : ?T)
def foo(x : $T)

Or maybe another symbol. I'm personally inclined towards something that has good syntax highlighting out of the box :-)
I think this will be needed in very few places, so I'd prefer this and be able to name types and type arguments however I want than to be limited.
Enumerable#map then becomes (assuming we go with %):
module Enumerable(T)
  def map(&block : T -> %U)
    ary = [] of U
    each { |e| ary << yield e }
    ary
  end
end

/cc @bcardiff @waj

How do you imagine when the type variable need to be used multiple types?
def merge(a : Enumerable('T), Enumerable('T))
  # ...
end

I find that tedious.
If we want to differentiate type variables from constants we should introduce a scope for them. In types we have that using generics Array(T). So that will hide any T constant.
In generic types we need an order so we can create them. In methods we don't and that is why we avoid the issue.
I am still fine with the single letter(+ digit) convention.
But if we want to get rid of that I would vote for something like:
def (T) merge(a : Enumerable(T), Enumerable(T))
  # ...
end

Or
class Array(T)
  typevar S # so S can be used for all methods inside the lexical scope as a type var. (yet is reminds me to C++ tempates...

  def merge(other: Array(S)) : Array(T|S)
  end
end

Hmm... I didn't find your first example tedious. The problem with def (T) ... is that now a Def ASTNode will need an array of free variables, making them all a big bigger and the memory footprint will increase. With 'T or %T it's just a new AST node, FreeVar, that is only used when needed, and its analysis is straight-forward (no need to check if something is a free var relative to the def where it's used).
The typevar S syntax is more confusing for me. I think Swift and Rust have something like that and I find it extremely confusing (and I remember @waj told me the same thing regarding Swift).
In any case, they are valid proposals, we are just brainstorming :-)

what about _T, _U

def (T) ... may not increase the memory footprint if the freevars list is a context that will help you choose if T is a freevar or a constant. And after parsing the def def you will get rid of that context.
If we go for 'T then Array(T) should be Array('T) for consistency IMO. And it feels like again, just splitting the grammar with a rule.
a) starting with ' , or
b) single leters (+digit)
the other alternative is lexical scoping as I propose.
Any other will be inconsistent.
for sure: brainstorming open minded mode on ;-)

I don't understand why Array(T) needs to change to Array('T)... where? In the class declaration? When using it as a type restriction?

class Array('T)
  # T is a constant
  # T' is binding to the free var T
end

otherwise i find confusing what will the following def will accept
def merge(a: Array(T'), b: Array(T))
end

both a & b are of the same type or other.
And what does T means inside that def.

please without ', strange symbol, when single, not like it in Rust also, and editors should change syntax parsing.

python style U :)

In:
def merge(a: Array(^T), b: Array(T))
end

assuming ^T is the syntax for free variables, ^T is a free variable. Array(T) will try to match T to an existing type T and will of course fail if there's no such type. But I don't see why we need to declare class Array(^T).
It basically will work like this:
class Array(T)
  def foo(x : T) # this T is the T of the array
    T
  end

  def bar(x : ^T) # this is a free variable
    T
  end
end

def foo(x : ^T) # this is a free variable
  T
end

def error(x : T) # this is an error, because there's no top-level type T
end

ary = Array(Int32).new
ary.foo(1) # => Int32
ary.foo('a') # error, Char doesn't match Int32
ary.bar(1) # => Int32
ary.bar('a') # => Char (because ^T is a free variable)

foo(1) # => Int32
foo('a') # => Char

But also:
class Array(T)
  def initialize(size : Int, value : T) # this T matches the type argument
    # ...
  end
end

# 'a' matches T, which is the array type argument.
# Because it's not yet set, and because this is an `initialize` method
# (for `new` it would be the same), T becomes Char, which also becomes
# the type argument, so we get Array(Char)
Array.new(3, 'a') # => ['a', 'a', 'a']

# Here T is set to Char, so the T in the method will be Char,
# and it doesn't match Bool
Array(Char).new(3, true) # Error, Bool doesn't match Char

This last case seems a bit strange, but I think it makes sense, and it will keep the number of ^T low.
So in most cases, in generic types, we won't need to use that annoying symbol ^T. We only need it when we really want a free variable that's not an existing type argument, for example in Enumerable#map or Array#+(other : Array(^U)), so in very few places, so chances of ridding the language with strange symbols are very low.

I find this example confusing:
def merge(a: Array(^T), b: Array(T))
end

Are ^T and T the same type or not? If they are not (which I find less confusing than if they aren't) , then I should use ^T everywhere in the method definition. In other words, does the ^ symbol become part of the type name or not? That makes the syntax for locally (to the method) defined type vars different to class type vars.
If we wanted to keep the same syntax for the type vars, then we need a way to declare the type vars at the method level. If we had choose angle brackets this would be really simple (like in C#, Java or C++):
class Foo<T>
  def bar<Q>(x : Q)
  end
end

Instead we decided to use parentheses, easier for the eyes and for the parser. But having two pair of parentheses one after another in the method definition doesn't look nice (and is probably ambiguous to parse), so I think @bcardiff suggestion of putting them before the method name looks more appealing.
class Foo(T)
  def (Q) bar(x : Q)
  end
end

I find this syntax much more homogeneous, more clean, without strange characters added.
Given all this said, I don't find specially limiting the fact that single letter class names are reserved for free type vars. It's a really simple rule to learn that makes the syntax even simpler.
What if we allow longer type var names but still forbid declaring single letter classes? Type vars at the class lever are always declared explicitly so this is easy to fix. At the method level, if you want to use long type vars, use the @bcardiff syntax. Otherwise nothing has to be done, keep using the simpler syntax:
class Foo(Type)
  def bar(x : Q)
  end

  def (Another) bar(x : Another)
  end
end

The other alternative is to go with Haskell type variables that match variables grammar and not constants. As expressed in https://github.com/crystal-lang/crystal/issues/3112#issuecomment-239858693

The main issue with disallowing single-letter top-level type names is that examples become a bit longer: class A; end; ... vs; class NeedToThinkANameMaybeFoo; end; .... I don't know, I can create a class named T in Java, C#, Ruby... I think I should be able to do that in Crystal too. Maybe it's not a big deal :-)
It's true that we can remove the restriction of type variables being single letter names right now because in Hash(Key, Value), using Key inside Hash will always mean the Key of Hash, never a free variable (well, it will act as a free variable if it's a type parameter of the uninstantiated generic class that has the method, and that's OK). I'll at least implement this change and it'll make the language a bit more flexible.
I now understand the issue with ^T and T. In that case I would give an error, maybe at parse time, because T is used both as a type and as a free variable.
^T isn't part of the type name, it just means: T is a free variable in this method, assign it the type you deduce, either from the argument type or from the block's type.
Basically, what I proposed is that this (I'll use ~ because I find it less noisy):
def foo(x : ~T)
end

is the same as what you propose as:
def (T) foo(x : T)
end

The second form is longer, and now we have two pairs of parentheses, and a duplicated T. On the other hand we don't need to think of a new symbol, so either way is fine. I maybe prefer ~T only because I feel its uses are very little, so adding this as part of a method signature (explaining that a method can have an optional list of free variable names) instead of seeing it as a modifier (in a type restriction, ~T means T is a free variable) feels like the user has to learn more. Plus it increases a Def's size, and remember a lot of Defs are created (one for each instantiation plus one untyped).
For example:
module Enumerable(T)
  def (U) map(&block : T -> U)
  end

  # vs.

  def map(&block : T -> ~U)
  end
end

In the first method I feel my 👀 are going from left to right, while in the second form I just read it and when I read ~U I see it's a free var.
In any case, either way is fine with me, we just need to settle on a syntax, or decide to leave things like they are now.

I'm not fond of introducing a new syntax merely to reallow single letter types. In examples one may use Foo and Bar instead or A and B. It's not such a big deal.
 It helps understand that it's a placeholder type.
That being said, I prefer a definition that isn't separated from the freevar itself (def (T) foo(x : T) is weird). As long as the syntax is only for freevars and not for generics, I can live with ~T in the rare places it would be required.

If the case that you're trying to address with ~T is going to be rare, then why does it have to be identified by a single cryptic letter?

I like the idea of using a word like newtype(T), it's true that we don't need to use symbols for this.
I forgot to mention another example of why disallowing single-letter names at the top-level is "bad": #3269 . For example:
N = (ARGV[0]? || 10).to_i

N.times do
end

Or what about making it easy to use E in a short script?
E = Math::E

# ...

That is, top-level constants like these are also currently disallowed.
I prefer to use sometext(T) in a few places (I think most users will never need this) than limiting all scripts, benchmarks or small prototypes where one can use very short names to try things out.

I've bashed my head back and forth and written syntax upon syntax for this very issue back in the days, in my various toy-langs, (and coded C++ for shitloads of years) - with those biases in mind, this is my 2 satoshis take:
I've used the terms "typeparam" for T in class Foo(T) and "typevar" for T in def foo(x : T).

Allowing longer typeparam names for generic types sounds very good: class Foo(Bar, Qwo).

The Single Letter Limitation: no problem. Seriously! How hard is it to do Exp = Math::E or TMP = (ARGV[0]? || 10).to_i... or class Foo, class Bar, class FooSub, etc.?

Easily readable and grokable "real" source code should be priority one, making examples and throw-ups easy should be way second to that.

Using the same symbol for a method typevar and a typeparam with the intent of T being something else is bad practise imo. (class Foo(T), and then foo(x : T) - don't do that!

With long typeparam names - that's made a lot easier: use long names in generic types, and single letter for method specific! StdLib containers could use de facto naming ElementT etc.

The only reason I see to explicitly mark method typevars is to prevent accidental use of a typeparam instead of the intended method scoped use. And also to allow typevars that are not used in the method's formal parameters. But then additional syntax is needed for calls. And decoration is out of the question.

I think allowing only /[A-Z][0-9]/ for typevars is very much OK.
If the safe-guarding is wanted, I think the explicit listing is better: def (Q) foo(x: Bar(Q), y: Q) instead of resorting to decoration. It does look weird. Agree with that. As @drosehn points out, decoration should be saved for things that are done often. Also, decoration, if done only on first use, looks... sketchy: def foo(x: Bar(~Q), y: Q), in that case, it should be part of the name. But I don't like that.

I would then actually prefer an error if a method typevar has the same name as a generic typeparam, when it's been explicitly listed as such. One should use different names.

In my alternative-syntax-fork I use Type<T>, with that def foo<T>(x : T) becomes natural as per @waj 's example. But, agreed, with the paren-notation of Crystal, it does look at bit weird. But still better than decoration.
If we go one step further with generic parametrizations (I'd really like that: DRY and performant) this could also create function variations where the T is not used in the method formal parameters, or not even a typevar, but a "generic configuration" (make a variation of the method based on some constant value, etc., just like for generic types), for instance (the code from a PoC database I intend to re-implement from scratch in Crystal):

template <typename T>
inline auto read_varilen_integer(u8*& data) -> T {
    T unsigned_value = read_varilen_natural<T>(data);

    return ((unsigned_value & 1) ? ~(unsigned_value >> 1)
    : (unsigned_value >> 1));
}

Here the T is used only to generic-parametrize the call to read_varilen_natural (defined similarily) and for the return type. This would still require additional syntax for calls in Crystal though. An alternative for this in Crystal is of course to pass the type as an argument - but it's not certain that it will be optimized away by LLVM.

I don't thing the Def ASTNode size @asterite mentions should be an argument in the choice. Few defs (best case: none) will have the list, and so will just be an additional 8byte nil.

I know we all have very different backgrounds into Crystal. I want a cleaner, more productive, replacement for C++. Others come from Ruby and see everything in a dynamic perspective. I prefer to have control to make efficient stuff when I need too, and as clear straight forward readable code in most cases. If performance wasn't an issue, we'd all code in functional languages - right? The only reason for imperative langs to exist imo is to be able to tell the machine how to do what we want, to squeeze those extra cycles.

If performance wasn't an issue, we'd all code in functional languages - right?

I disagree with this. I mean, some things are just easier to represent with objects. In particular, plugins are nearly impossible with statically-typed functional languages, short of doing ugliness like:
data MyObj = MyObj { doSomething :: Int -> Int }

and then explicitly construct it:
myPluginEntryPoint = MyObj { doSomething = (\a -> a) }

But that's not any more readable than just using ABCs! Even functional languages that do have plugin systems usually use objects.
Back on topic: my vote:

Leave single-letter vars invalid at the top-level. Short code snippets are a bit longer (that's kind of ironic), but I think it makes code overall more readable/accessible.

If someone needs to have a generic parameter that isn't an argument, they can do something like:
def f(normal_arg : NormalType, T)

T isn't really an argument; it's just a generic parameter. So the type appears to be a normal argument, but it's all compile-time. Someone could call it like f(arg, SomeType).

Failing that, Haskell's solution could also work: use lowercase letters for generic parameters. They're not allowed as types to begin with, anyway. This wouldn't really hurt readability, and you don't end up with the weirdness of using symbols (e.g. %T).

I think the current situation is fine as it is, but merging #3294 would be nice. Not being able to define single-letter constants at the top level only affects short scripts, which use top-level code. And for that I say there's always a simple workaround: Just put it in a class/singleton.

@kirbyfan64 - yes, I exaggerated for effect, sorry for deviating from the subject.

So, today we discussed this with @waj and @bcardiff
The thing is... did you know that only top-level names like T and T1 are disallowed? But not nested names. But with just this rule things can still break.
I know, the solution is simply to disallow these short names as types everywhere, right? Well, what about Math::E? Should we rename it because of this?
In fact, I initially implemented the rule above and later decided to only do this for the top-level because Math::E would break. But this rule is incomplete, as we just saw.
So, for us it doesn't feel right that the language constraints names we can choose... it would take a lot of fun out if we'd have to rename Math::E to something else.
Also, free variables are not a very common feature, so adding syntax for that instead of disallowing short type names feels like the correct thing to do. But, free variables are usually short, like T and U, and we can still do that, so we can still use that as a convention, while at the same time allowing T, U and E for type names, be it for small scripts, sample code or math constants.
What syntax to use? We've settled with:
module Enumerable(T)
  def (U) map(&block : T -> U)
  end
end

This is because if we use something like ~U or newtype(U) it would be confusing to use U and ~U in the same method. With def (U) that's impossible to happen.
Don't worry, using free variables like that is very uncommon, most occurrences of that are in the standard library, and the syntax is not hard not full of strange symbols, so we think it's still a happy syntax.
We'll also free the names for type variables, so class Foo(Bar) can be written if someone wants too (#3294), though by convention one would use a short name.

👎  for, looks too strange:
module Enumerable(T)
  def (U) map(&block : T -> U)
  end
end

newtype(U) - :+1: interesting, not any change in syntax, just new compiler method, like is_a?

Uhhh...I'm sorry, but that looks kinda weird. :O
And the idea to use lowercase letters never even got any consideration. :(

@kostya I don't know why you say that it looks weird, in Java it's almost the same.
public <T> void foo(T x) { }

This:
def (U) map(&block : T -> U)
end

is read: "given U a free variable, the method map has the following signature".
Also, what about this:
def push(x : newtype(U), y : Array(newtype(U)))
end

Seems a bit long, we have to use newtype everytime we need to mention U as a free variable. With the proposed syntax:
def (U) push(x : U, y: Array(U))
end

Much simpler to read and to analyze.
@kirbyfan64 We considered lowercase letters, but it's weird:
def foo(x : a)
  a = 1 # ???
  a::T # ???
end

a usually means var or call, and now it could also mean a type, and some things, like a::T are not supported by the current grammar, so this would be a huge change.

The main cons of lower case is that simple highlighters won't be able to color : a as a type.
So from reading the source is not easily depicted which variables are type variables and which normal variables.
I really tried to push Haskell like type variables.
In haskell you don't mix type variables with variables in the same line, that is not what happen in crystal.
apply :: (a -> b) -> a -> b
apply f a = f a -- here a is a value of type a

One last attempt at more explicitness :P
def (forall U) push(x : U, y: Array(U))
end

If you want to introduce more than one free var:
def (forall U,V,W) zip(us : Array(U), vs : Array(V), ws : Array(W))
end

Based on a discussion that fired because of @mverzilli 's message :-), we finally settled on this syntax:
def map(&block : T -> U) forall U
def map(&block : T -> U) : ReturnType forall T, U

Pros:

Using forall U instead of (U) is more human, and there are less parentheses and symbols
Methods are still greppable (I can search def foo, with def (U) foo I can't do that anymore)
forall is used in Purescript, so it's not just a crazy idea of ours

Cons:

A method named forall can't be invoked in the same line as in the method definition (it still can be invoked with self.forall, like any keyword). We don't think this is a real breaking change.

Is it now a requirement, or is it just a feature for safety?

@ozra In the next version both forall and using a single-letter name will make a type be considered a free variable. Then in the subsequent version we'll remove the single-letter name rule and you'll have to use forall.

Only for freevars or also for generics?

@ysbaddaden Only for freevars.
In the standard library I only found 64 uses of freevars.

Ok


BUG: Fix week_start when Monday precedes the New Year.

The week_start date rule was incorrectly returning False for
2018-12-31 on NYSE calendar.
The root cause of the bug was that the groupby used in
TradingDayOfWeekRule.execution_period_values was using the pairing
of year and weekofyear. This pairing grouped 2018-12-31 with
the first week of January 2018 (2018-01-02, 2018-01-03, ...),
instead of with 2019-01-02, 2019-01-03, ...
This misgrouping occurred because the values of (year, weekofyear)
for 2018-12-31 are (2018, 1); however the other dates that are in the
same week as 2018-12-31 have a value of (2019, 1).
Since 2018-12-31 was misgrouped, the call to nth(0) would not select
it as the first of the week; since it appeared to be the last day of the
first week of 2018
Instead, use the isocalendar method of the datetime object.
https://docs.python.org/2/library/datetime.html#datetime.date.isocalendar
2018-12-31 is part of the ISO Week 2019-W01-1, as are 2019-01-02, etc.
(ISO Weeks location is determined by where the Thursday falls.)
Also, change the edge case tests so that a truth table of date and
expected 'should trigger' result is defined.
In the previous version of the test, moving the start date before
the New Year was hitting edge cases within the test construction around
offsets and calendar days.
Moving the first "sim date" would have been required to make sure that
a date like 2016-12-30 or 2018-12-31 was covered.
The change to use of the truth tables also takes the tests time down from 3.5
seconds to around 100ms on my dev machine.

Besides minor typo, LGTM.

Double checked with @ehebert. He said we're good to merge.


HashedWheelTimer hides exception

At this line:
https://github.com/netty/netty/blob/3a48010c42615e2f5403b89d631ca126fa068cfb/common/src/main/java/io/netty/util/HashedWheelTimer.java#L673
All throwable are catched and logged with an netty logger at warn level.
But throwable is a super class of Error and the javadoc says:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.

warn is a quite low level, that can hides more sever exceptions like NPE. I think a provided exception handler should be added here.

@fbacchella why exception handler ?

Something provided by the user of the library as a callback, to be notified of unexpected exceptions.

Hi, how is this going?
Maybe don't need an exceptionHandler, you only need to handle exceptions that require special handling in the run method of TimerTask:
try {
     // do business logic..
} catch(Exception e) {
    // do your exception handle..
}

The role of hashedwheeltimer is actually the same as scheduledexecutor, which periodically triggers tasks. The specific exception logic should also be handled by the user. (Scheduledexecutor also does not provide exceptionhandler)
WDYT..? @fbacchella

That's the way I solved this problem. But if you don't know how netty behave, you can miss that. And again I'm not sure that catching throwable is a good idea.


Thank you for your wonderful work.  Would you share codes for querying GPT4 ?

Absolutely! We will soon clean and upload API inference code for ToRA, which can support any models beyond ToRA, like GPT-4 or ChatGPT. It's very similar to the batch inference code inference.py. Furthermore, a demo will be made available in the coming days. Stay tuned!


Use RTT protocol to check connection status

The main websocket will use 2 protocols when connecting, if the protocol it is using is v4.1.networktables.first.wpi.edu, it will open a 2nd websocket with the RTT network tables protocol so it can send and receive timestamps much more frequently. This also means that it can use these timestamps to check the connection status instead of relying on the onDone() method of the main websocket.
In addition, there are some bug fixes implemented:

When closing the sockets, it will explicitly close the stream so there isn't a possibility of it still being connected on the server end
If the address is changed while the socket is connecting to network tables, it won't initialize the connection if it happens to connect with the old address

Not sure how much more you plan to make a PR for. Let me know when you're done and I'll hold off on publishing a release until then

Not sure how much more you plan to make a PR for. Let me know when you're done and I'll hold off on publishing a release until then

Right now there's only 2 more features I plan on adding before 2024, which should be done by the end of the week (it comes down to when I have the time to add it)
At some point I do want to add something for structs but I have no idea how that would be organized, that's a post kickoff problem for now


iPhone 11 Pro not Jailbreaked

iphone11 pro ios 13.3 unc0ver installed but not jailbreaked - only respring without cydia(

Device (please complete the following information):

iOS Version: 13.3
iOS Device: iPhone 11 pro
unc0ver Version: 4.0.0

Had the same problem, here is what i did:
Start JB -> Phone will restart.
Once restarted clear Unc0ver from App-switcher.
Open Unc0ver again, go to settings, tap on "clear diagnostic data" and then tap on "automatically select exploit".
Go Back, JB -> Profit.
Tried it 3 times like that and had success every time.
@pwn20wndstuff Maybe the exploit doesn't get set on iPhone 12,3? (11 Pro)

Thanx, no working on iPhone 11 Pro(((

16 февр. 2020 г., в 12:52, Vincent Niehues<EMAIL_ADDRESS>написал(а):
Had the same problem, here is what i did:
Start JB -> Phone will restart.
Once restarted clear Unc0ver from App-switcher.
Open Unc0ver again, go to settings, tap on "clear diagnostic data" and then tap on "automatically select exploit".
Go Back, JB -> Profit.
Tried it 3 times like that and had success every time.
@pwn20wndstuff https://github.com/pwn20wndstuff Maybe the exploit doesn't get set on iPhone 12,3? (11 Pro)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/pwn20wndstuff/Undecimus/issues/1685?email_source=notifications&email_token=AHBE7GMJXEIDYFPRHBXQBBDRDEEF3A5CNFSM4KV7ZRTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4CG6A#issuecomment-586687352, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHBE7GIIHBAE4SQGWJGN2M3RDEEF3ANCNFSM4KV7ZRTA.

Mhhhh... Airplane mode?

Airplane mode, light or dark mode, cleared diagnostics or not, app drawer fully empty or not, nothing seems to cut it for my iPhone 12,5 256Gb

No one question about a 12.5. Thousands - concerning 12.3. No matter airplane, dark-light, clear diagnostic and automatically select exploit - unc0ver rebooting iPhone after pressing a button JB. Thats all. unc0ver need fix. Don't know why this error escaped the attention of beta testers?

16 февр. 2020 г., в 14:38, Eastkap<EMAIL_ADDRESS>написал(а):
Airplane mode, light or dark mode, cleared diagnostics or not, app drawer fully empty or not, nothing seems to cut it for my iPhone 12,5 256Gb
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/pwn20wndstuff/Undecimus/issues/1685?email_source=notifications&email_token=AHBE7GL2FJ2WYHJR6AMVZQTRDEQULA5CNFSM4KV7ZRTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4EMAI#issuecomment-586696193, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHBE7GK4RZRNVRURPTP5EYDRDEQULANCNFSM4KV7ZRTA.

Again, i had exactly the same problems on my 11 Pro 256gb on iOS 13.3 (iPhone 12,3) and i fixed it using the steps i described above. It works every damn time for me.
Did you clear diagnostic data and tap on "automatically select exploit"?
Did you set "Reinstall Cydia" to true?
I also checked each switch to see if it was compatible with A13 and disabled every switch that wasn't.
I hope that helps.. otherwise unc0ver needs an update first :/

. It works every damn time for me

maybe u can show us the setting screenshot，thank u anyway!

Again, i had exactly the same problems on my 11 Pro 256gb on iOS 13.3 (iPhone 12,3) and i fixed it using the steps i described above. It works every damn time for me.
Did you clear diagnostic data and tap on "automatically select exploit"?
Did you set "Reinstall Cydia" to true?
I also checked each switch to see if it was compatible with A13 and disabled every switch that wasn't.
I hope that helps.. otherwise unc0ver needs an update first :/

maybe u can show us the setting screenshot，thank u anyway!

https://github.com/pwn20wndstuff/Undecimus/issues/1680#issuecomment-586710135
posted screenshots here.

Same device for me iphone 11 pro 512 GB ios 13.3 NOT working :(

Third day all right. What i done:
Make reserved copy, reset iPhone, restore from copy, install AltStore, install uncover, turn on airplane mode, jailbreak with 3 resprings pressing clean diagnostic data and automatically select exploit, turn off airplane mode,install appstore++ and other needed tweaks.
All working very good. But i do not test reboot and re-Jailbreak – afraid spending more time. Good luck! Issue is closed.


post /v1/checkout/sessions is not supported

I've switched to using new Checkout API to become compliant with SCA. So I had to change which API I am using, which is now Stripe::Checkout::Session. Those endpoints though are not supported by the gem at the moment.
    session = Stripe::Checkout::Session.create(
      customer: customer_id,
      payment_method_types: ['card'],
      submit_type: "donate",
      line_items: [{
        name: 'Donation',
        description: 'Thank you for donating!',
        amount: params[:amount],
        currency: 'USD',
        quantity: 1,
      }],
      success_url: dashboard_events_url,
      cancel_url: dashboard_events_url,
    )

Bump for this issue?

Would love to see this supported. Looks like there was some work done already: https://github.com/rebelidealist/stripe-ruby-mock/pull/648


Uncaught exceptions should be formatted as JSON by default

When a function executes and exits with an uncaught exceptions, the exception is logged as a regular plaintext Python traceback to stderr. The content is then captured into Cloud Logging as plaintext too, which makes it difficult to parse and analyze.
Consider the following dummy function:
import functions_framework

@functions_framework.http
def test_crash(request):
    raise ValueError("something doesn't work")

When calling this function, it (of course) crashes, and renders as follow:

This has several disadvantages:

The error is spread over multiple line: it's not possible to point to a single log entry which contains the traceback, you always need to see here ~20 lines to get the full picture.
The traceback only makes sense if Cloud Logging is sorted from oldest to newest (I typically shows newest entries first, and the traceback is reversed :facepalm: )
The error doesn't really show up in Error Reporting: only some of the exception, part of Flask, is caught into Error Reporting and it's really not useful:

Ideally, out of the box when running on GCP:

The framework should log the error into a single CRITICAL log entry
The error should be formatted to be reported automatically with the right content into Error Reporting

If it's something that makes sense to have (improving the default experience when running functions on GCP), I'd be interested to help :)


Update build.gradle

Fix incorrect app ID as described in issue #175.

LGTM.  Thanks for the fix, and thanks tpapak01 for the report.


feat: supported multi requests

:tada: This PR is included in version 1.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Support ARM cross-tenant authentication

Bug Report
When using the Client Secret Auth method, the multitenant authentication (a.k.a auxiliary tenant) doesn't work as expected. The ultimate bear token that is set in the header as x-ms-authorization-auxiliary is actually signed by the primary tenant.
With some debugging, it appears the problem comes from: https://github.com/Azure/azure-sdk-for-go/blob/8379ab2ff08eb677863373331cdaa981f663a9f2/sdk/azidentity/client_secret_credential.go#L65-L66, where the opts.TenantID is not used at all for acquiring the token in the call of c.client.AcquireTokenSilen. Instead, the tenant of the c.client is used, which is the primary tenant.
This issue doesn't only apply to Client Secret Auth method, but also (at least) to the Client Cert, MSI and CLI Auth method.

Thanks for opening this! We have API in place for ARM cross-tenant authentication but, as you've seen, the implementation is incomplete in that credentials always authenticate in the tenant set at construction. MSAL clients have the same limitation, so it's awkward for us to implement this today. It is technically feasible though--each credential could maintain a map of tenants to MSAL client instances. Still, that's a poor solution; it would be better to leverage MSAL support for this feature. I'll see where it fits on the roadmap.

Blocked on [Feature Request] Enable changing tenant after client construction

Blocked on [Feature Request] Enable changing tenant after client construction

@RickWinter I see https://github.com/AzureAD/microsoft-authentication-library-for-go/issues/296 is closed, so what's the status of this issue now?

Charles recently added support to MSAL for GO.  In order to leverage that in azidentity we need two more things to happen

A release of MSAL for GO with the changes
An update to AzIdentity to leverage the new release.

Both items are slated to happen in the first part of 2023.

azidentity v1.3.0-beta.3, in tandem with azcore v1.4.0-beta.1, supports ARM cross-tenant authentication. Usage looks like this:
import "github.com/Azure/azure-sdk-for-go/sdk/azcore/arm"

auxTenants := []string{"TODO", "..."}
cred, err := azidentity.NewClientSecretCredential(tenantID, clientID, secret,
      // AdditionallyAllowedTenants prevents the credential from trying to
      // authenticate in an unexpected tenant. All credential types capable
      // of multitenant auth have this option.
      &azidentity.ClientSecretCredentialOptions{AdditionallyAllowedTenants: auxTenants},
)
if err != nil {
      // TODO: handle error
}
// armsubscription is just an example, all ARM clients have this same options API
client, err := armsubscription.NewSubscriptionsClient(cred,
      // client will add a token for each of these tenants to every request
      &arm.ClientOptions{AuxiliaryTenants: auxTenants},
)


Feat Request: deploy to vercel

To do

[x] unify the dev tools (including tsconfig, eslint, lint-stage, etc) in the monorepo: #11
[x] make sure no sensitive information is stored, logged, or shared publicly. If necessary, encrypt it
[ ] deploy to vercel, or any other cloud platform

Updates: UI is successfully deployed to Vercel, but API needs another platform.


Stack generic AIR constraints structure

Describe your changes
This PR introduces a framework of stack operation's generic AIR constraints. It is generated based on the 7 stack operations implemented in the #370 and will be further upgraded once more stack operation's air constraints are introduced to the VM.
3 new composite flags have been exposed in the OpFlag struct for these constraints.
Checklist before requesting a review

[x] Repo forked and branch created from next according to naming convention.
[x] Commit messages and codestyle follow conventions.
[x] Relevant issues are linked in the PR description.
[x] Tests added for new functionality.
[x] Documentation/comments updated according to changes.

This approach works, but I think we should do it more holistically. Meaning, we should look at all operations, figure out which flags they require, and then find a good way to merge these flags into a smaller subset. I think doing this incrementally would be very difficult - so, might as well do the whole thing right from the start.
The simplest baseline I can think of is to have 3 flags per stack item - e.g., for item 0, we could have something like left_shift_0, right_shift_0, no_change_0, and similar flags for items 1 through 15. This would result in 48 additional flags. But we should be able to reduce this number considerably.
For example, I don't think there is an instruction which could cause a left shift of item 15 without also doing a left shift for item 14. So, these two can be combined together.
Another aspect of this is that we could probably compute the flags much more efficiently as compared to just summing up flags for relevant operations. This is because many operations which affect the stack in similar ways have common prefixes, and thus, we can use intermediate values (which we compute anyway) to simplify flag computations.

Thanks for the review! After going through all the operations, I've come up with the following composite flags for generic stack constraints which I think covers everything (except end control flow operation where the stack state depends on whether the previous block was a loop or not). In 25 additional composite flags we can express all the generic stack constraint in Miden VM.
Stack composite flags
No shift composite flags
$$
no\_change\_0 = f_{noop} + f_{u32assert2} + f_{mpverify} + f_{join} + f_{span} + f_{respan} + f_{halt}
$$
$$
no\_change\_1 = no\_change\_0 + f_{eqz} + f_{neg} + f_{inv} + f_{incr} + f_{not} + f_{neg} + f_{fmpadd} + f_{mload}
$$
$$
no\_change\_2 = no\_change\_1 + f_{swap} + f_{u32add} + f_{u32sub} + f_{u32mul} + f_{u32div}
$$
$$
no\_change\_3 = no\_change\_2 + f_{movup2} + f_{movdn2}
$$
$$
no\_change\_4 = no\_change\_3 + f_{movup3} + f_{movdn3} + f_{readw} + f_{mrupdate} + f_{swapw2} + f_{swapw3}
$$
$$
no\_change\_5 = no\_change\_4 + f_{movup4} + f_{movdn4}
$$
$$
no\_change\_6 = no\_change\_5 + f_{movup5} + f_{movdn5}
$$
$$
no\_change\_7 = no\_change\_6 + f_{movup6} + f_{movdn6}
$$
$$
no\_change\_8 = no\_change\_7 - f_{swapw2} + f_{movup7} + f_{movdn7} + f_{swapw}
$$
$$
no\_change\_9 = no\_change\_8 + f_{movup8} + f_{movdn8}
$$
$$
no\_change\_10 = no\_change\_11 = no\_change\_9
$$
$$
no\_change\_12 = no\_change\_9 - f_{swapw3}+ f_{swapw2} + f_{rpperm}
$$
$$
no\_change\_15 = no\_change\_14 = no\_change\_13 = no\_change\_12
$$
Left shift composite flags
$$
left\_shift\_1 = f_{assert} + f_{drop} + f_{mstore} + f_{fmpupdate} + f_{mstorew} + f_{split} + f_{loop} + f_{repeat}
$$
$$
left\_shift\_2 = left\_shift\_1 + f_{eq} + f_{add} + f_{mul} + f_{add} + f_{or} + f_{u32and} + f_{u32or}
$$
$$
left\_shift\_3 = left\_shift\_2 + f_{cswap} + f_{u32add3} + f_{u32madd}
$$
$$
left\_shift\_4 = left\_shift\_3
$$
$$
left\_shift\_5 = left\_shift\_3 + f_{mloadw}
$$
$$
left\_shift\_8 = left\_shift\_7 = left\_shift\_6 = left\_shift\_5
$$
$$
left\_shift\_9 = left\_shift\_5 + f_{cswapw}
$$
$$
left\_shift\_15 = left\_shift\_14 = left\_shift\_13 = left\_shift\_12 = left\_shift\_11 = left\_shift\_10 = left\_shift\_9
$$
Right shift composite flags
$$
right\_shift\_0 = \sum (f_{movupn} + f_{movdnn} + f_{dupn}) + f_{pad} + f_{push} + f_{sdepth} + f_{read}
$$
$$
right\_shift\_1 = right\_shift\_0 + f_{u32split}
$$
$$
right\_shift\_2 = right\_shift\_1 - f_{movup2} - f_{movdn2}
$$
$$
right\_shift\_3 = right\_shift\_2 - f_{movup3} - f_{movdn3}
$$
$$
right\_shift\_4 = right\_shift\_3 - f_{movup4} - f_{movdn4}
$$
$$
right\_shift\_5 = right\_shift\_4 - f_{movup5} - f_{movdn5}
$$
$$
right\_shift\_6 = right\_shift\_5 - f_{movup6} - f_{movdn6}
$$
$$
right\_shift\_7 = right\_shift\_6 - f_{movup7} - f_{movdn7}
$$
$$
right\_shift\_8 = right\_shift\_7 - f_{movup8} - f_{movdn8}
$$
$$
right\_shift\_15 = right\_shift\_14 = right\_shift\_13 = right\_shift\_12 = right\_shift\_11 = right\_shift\_10 = right\_shift\_9 = right\_shift\_8
$$

The approach is right, but a few notes:

We probably should cache the flag values. Otherwise, when we call something like no_change_12() we also be recomputing all the values which came before it, and we won't realize as much improvement as we could have.
Computation of right_shift_0() could be simplified quite a bit. Notice that most right shift operations have prefix 011. We compute value of this prefix when we compute operation flags, and thus should be able to get it for free.
a. You might be able to apply similar optimizations in other places, but I didn't check.
We should also add other composite flags as described here.
Regarding END operation, we can use the value of one of the helper registers to determine whether we are exiting a LOOP block or not (see here).

Lastly, would be good to know total number of field operations to compute these flags.

I've refactored the way the flags were earlier generated in order to reduce the field operations as much as possible.

All the composite flags have been cached in the commit f5e91a0.
I've tried to simplify the computation of composite flags by introducing as helper flags.
Added.
End has been incorporated.

Lastly, the computation now is taking only ~243 field operations. The benckmark is as follows:
compute_op_flags/op_flags
time:   [241.12 ns 241.44 ns 241.81 ns]
Found 8 outliers among 100 measurements (8.00%)
1 (1.00%) low mild
4 (4.00%) high mild
3 (3.00%) high severe
Interestingly it's now taking less time to run than earlier when it has less field operation. I'd need to investigate it.


Add tests for De-Identification

We already have tests for NER models, but we should add a category for De-Identification so that we can test models for this specific capability.
We could extend it to test on clinical relevant de-identification tasks such as being compliant with HIPAA, etc.

De-Identification examples

Category
Test Type
Original
Test Case
Expected
Actual
Pass

DeIdentification
Simple Masking
Patient John Doe was admitted on 01/01/2024.
Mask names and dates
PATIENT [MASK] was admitted on [MASK].
PATIENT [MASK] was admitted on [DATE].
True

DeIdentification
HIPAA Compliance
The patient's address is 123 Main St, Anytown.
Mask address according to HIPAA
The patient's address is [MASK] [MASK] [MASK].
The patient's address is [MASK] [MASK] CA.
False

DeIdentification
Redaction vs. Replacement
The patient suffered from depression.
Redact mental health conditions
The patient suffered from [MENTAL_CONDITION].
The patient suffered from [REDACTED].
True


Consolidate Scala libraries into single repository

In order that all developers can easily make updates to shared libraries and be sure of adoption to other projects we should:

Have a mechanism to auto-update & test downstream clients with new library versions
Have an established review mechanism for shared libraries
Have clear documentation on how to build/release and user shared libraries.

Implement https://github.com/wellcomecollection/docs/tree/master/rfcs/024-library_management to help with conflicting dependencies.

We should find want a way to allow heterogenous versions of our libs, as long as they are using the same third party dependencies.
For example a changed in a shared dependency on a version of Akka amongst the libs would need to be signposted to library consumers, or risk a clash with their project dependencies.
Pointed out by @warrd.

And done!

https://github.com/wellcomecollection/scala-libs


On Firefox, one-finger drag released outside browser causes second drag to zoom

How to reproduce

Leaflet version I'm using: 1.3.4
Browser (with version) I'm using: Firefox 63.0.1
OS/Platform (with version) I'm using: Windows 10 on Microsoft Surface
Open https://leafletjs.com, scroll down if necessary so you can see the map
With one finger, touch the map, drag to a point outside the browser window, and release
Touch with one finger and drag again - this time the map zooms in and out as you drag

What behaviour I'm expecting and which behaviour I'm seeing
The second drag should just drag the map. Instead the map behaves as for a pinch zoom.
Chrome, Edge and IE11 all behave correctly.
Minimal example reproducing the issue
As above.

@pjr11
Are you still own Surface?
I'd like to fix the issue.

Just revisiting this issue that my colleague logged years ago its still an issue and we would very much like to see it resolved

@adrian-ci @pjr11
Could you check if the issue can be resolved by #7029?

@adrian-ci @pjr11
Could you check if the issue can be resolved by #7029?

Tested with Microsoft Surface Pro 2017 and Firefox 93.0. Is working with the newest master and with the old 1.3.4 version (Video)
https://user-images.githubusercontent.com/19800037/139717422-f4ae69d3-2dd8-4477-9063-0c43804bd77e.mp4


Generate apps for JDBC Supplier and Rabbit Consumer

Let's do it for jdbc-source and rabbit-sink.
Acceptance:

[x] Adjust plugin to consume java-functions directly
[x] Generate apps for Kafka and Rabbit
[x] Test the apps standalone using the TestBinder

This task is complete.


chore: add v3 instructions

Add instructions for using Traefik v3 docker image
closes: #71

@kevinpollet all suggestions have been implemented

Updated with your suggestions @emilevauge 👍

all good now @emilevauge

All good now @kevinpollet need your approval so we can merge


Refactor API URL.

Coverage decreased (-0.08%) to 54.421% when pulling 5f634db2039802d5506a9a6bffb598d5e4b91d4f on ywk253100:170321_url into 7f099ebe50875dcf09c500b8cfec9201772df42b on vmware:dev.

Coverage decreased (-24.01%) to 30.491% when pulling 1ce456b85acb9ce989249127651587d362543233 on ywk253100:170321_url into 7f099ebe50875dcf09c500b8cfec9201772df42b on vmware:dev.

Coverage decreased (-0.04%) to 54.461% when pulling b461ba54a8df9611aaddfafe8a13eb06faa5a6df on ywk253100:170321_url into 7f099ebe50875dcf09c500b8cfec9201772df42b on vmware:dev.

Coverage increased (+0.004%) to 54.521% when pulling f74620961c45de67a1f32da7eabe6eca931df82b on ywk253100:170321_url into e2fe74598ba1ad590c172617bebc573ea238d2e8 on vmware:dev.

Coverage decreased (-24.07%) to 30.444% when pulling 2117dc817242d3a7215265a89dc31e7dfd5feed8 on ywk253100:170321_url into e2fe74598ba1ad590c172617bebc573ea238d2e8 on vmware:dev.

Coverage decreased (-0.09%) to 54.495% when pulling dfb6e4f417497f984d474a7680ae5b74f7b9f1c8 on ywk253100:170321_url into cb2377caf72df801a2a9e2d47867ea05412e54ec on vmware:dev.

Coverage decreased (-0.02%) to 54.429% when pulling 5c4808bf93e845e90ac4196b8fe760e8548dc09e on ywk253100:170321_url into bf83ea250687001b9a0c027c9639d907eb774492 on vmware:dev.


Travel Website

Is your feature request related to a problem? Please describe.
I have made a website for Travel agency

@Ayush7614 Please Assign the Task To me


Fix booleans and objects

Sqlite doesn't support TRUE and FALSE as boolean values, only 1 and 0.
Also, if trying to update using a JSON object, if the object didn't have an explicit .toString() method, it would end up trying to save '[object Object]' to the database.  Switched out to use JSON.stringify in that case.

@barryhammen I'm sorry it took me a while to get to this PR - got kinda behind on things at work for a while.  This is fantastic. I'm gonna merge it & push a new version today! :dancer: thank you sooo much!


build(sdk): switch from Setuptools to Hatch

Fixes WB-NNNN
Fixes #NNNN
Description
What does the PR do?
Testing
How was this PR tested?
Checklist

[ ] Include reference to internal ticket "Fixes WB-NNNN" and/or GitHub issue "Fixes #NNNN" (if applicable)
[x] Ensure PR title compliance with the conventional commits standards

Too old, won't do now.


cabana: support choosing color for signal

resolve https://github.com/commaai/openpilot/discussions/26091#discussioncomment-6860946

choose color dialog:

chat view. click Choose colors to choose color for signals in chart

3.signal view. click palette button to choose color for signals in message:

Is this worth 100 lines? cabana is already ~8k lines

I've tried to keep the code as concise as possible. @sshane  any thought? feel free to close it if it's not worth.

This feels like a useless menu, you can't choose any signals from here?

Pressing the button doesn't affect CANCEL_REQ, it affects the first(?) modified signal from the signals pane.

This feels like a useless menu, you can't choose any signals from here?

it's not a menu, it's used to choose color for selected signal on the left side, not quite sure why the color picker is missing on the right side in your screenshot. it should be something lie this:(my screenshot)

Oh it's a separate popup for me

how about know? added option QColorDialog::DontUseNativeDialog

Can we also remove yellow as one of the default color choices in light mode? I can't see it at all

Honestly if you just remove all the light colors from light mode then a color chooser probably isn't required

Think the color selector is still useful. Especially if multiple signals with similar colors are displayed in  one chart. Here's an example:

Is it better to just adjust the colors depending on the others when plotted on other signals?


Feature Request: Add more flexibility to send_announce or make send_activity_to_followers a public function.

What
Currently the send_announce function  is not suited for handling general announces, it is tied especially to the blog/user actor behavior, where the blog actor might announce posts of users of both actor types are enabled.
Why
General reasons:

Other plugins might want to send Activities to followers that are not native to the ActivityPub plugin.
There could also be the desire in the future that e.g. an Announce can also be done for external ActivityPub objects.

Concrete use-case:
E.g., for the ActivityPub Event Bridge WordPress-Plugin, I was implementing a feature that would schedule a single self-announce of an Event ActivityPub object at a defined time before the event starts.
How
Two solutions come up my mind:

Make the send_activity_to_followers a public static function, allowing other plugins to totally create custom activities.
Make the send_announce function more flexible: add a third user_id param that might override the current behavior.

This a general problem we have to address! The current dispatching is only working for the current setup and scales not very well.
But this is such a big feature, that I procrastinated it :)
See: https://github.com/Automattic/wordpress-activitypub/pull/593

I totally forgot about #593. It's on hold for quite some time indeed! Since that might indeed be a breaking API change, a possible clean solution until then could be that we create a public static wrapper for send_activity_to_followers which will be deprecated once #593 gets completed.


Toggle panel doesn't display or have working a keyboard shortcut.

VSCode Version:1.5.3
OS Version:Windows 10

Steps to Reproduce:

Open View menu. Toggle Panel does not have a keyboard short cut.
Open Default Keyboard Shortcuts and search for workbench.action.togglePanel.

Ctrl+J is shown as default shortcut.
Pressing Ctrl+J instead shows status bar message:
"(Ctrl+J) was pressed. Waiting for second key of chord..."

User error.  I had added a chord for ctrl+j ctrl+j to my keybinding.json
{ "key": "ctrl+j ctrl+j", "command": "_generateCommandsDocumentation"},


Notifications module: auto generated lang keys issue.

Auto generated Title and Action keys in BxBaseModNotificationsModule::serviceGetActionsChecklist method should be module (unit) related.

Check in both Notifications and Timeline modules.


ShopEmailPreviewTask should also allow previewing of OrderStatusLog Emails

Order Status Log emails were introduced here: https://github.com/silvershop/silvershop-core/pull/534
@anselmdk can you add this?

Yeah, that was the plan. Thanks for reminding me. I'll look into it.


Is it normal behavior for the container to stop once the sync is complete?

Is it normal behavior for the container to stop once the sync is complete?

@cirrusflyer Yes, this is normal behavior. The container does not run as a continuous service, it rather is a "one-time run" application created for the periodic use triggered by, for example, cron.

I will close this issue now.


Update To Allow Twig 2.x

Just adds support for Twig 2.x in addition to keeping current support for 1.x.

Nice - thanks for the update! Do you know offhand if there's any deprecated handling in 2.x that would cause the current code here to break? I haven't looked at the difference...

Deprecations: http://twig.sensiolabs.org/doc/1.x/deprecated.html
Expose's only Twig code is here ./src/Expose/Notify/Email.php#L100-L102 and of course the template ./src/Expose/Template/Notify/Email.twig
The template has no breaking code. The only Twig calls made is for Twig_Loader_Filesystem() and Twig_Environment() and loadTemplate() none of which appear to be deprecated. I'd have another set of eyes verify though :)

Confirmed - looks good to me, merging.

@enygma could we have a new release pushed out? Haven't had one since 2015 and there's been quite a few changes. Thanks!

@quantumpacket done! Welcome to 3.0 :)


Google Analytics in Maps

Extent Google Analytics into the Maps. I can see the other pages, not the maps.

Incorporate analysis of what people search for on the app


Not working on Windows 10

Getting the following error:
C:\Users\paolo.delmundo\AppData\Roaming\nvm\v4.4.4\node_modules\image-diff\bin\image-diff:29
        throw err;
        ^

Error: Could not execute GraphicsMagick/ImageMagick: identify "-ping" "-format" "%wx%h" "run-first/login-2-after.png" this most likely means the gm/convert binaries can't be found
    at ChildProcess.<anonymous> (C:\Users\paolo.delmundo\AppData\Roaming\nvm\v4.4.4\node_modules\image-diff\node_modules\gm\lib\command.js:299:14)
    at emitOne (events.js:77:13)
    at ChildProcess.emit (events.js:169:7)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:198:12)
    at onErrorNT (internal/child_process.js:344:16)
    at nextTickCallbackWith2Args (node.js:442:9)
    at process._tickCallback (node.js:356:17)

paolo.delmundo@WLREM1611473 MINGW64 ~/Code/discover/e2e/test-reports (discoverjs)

I installed the ImageMagick Windows binaries.
The installer included the path to the binaries.

What happens when you run the command outside of image-diff?
identify -ping -format %wx%h run-first/login-2-after.png

paolo.delmundo@WLREM1611473 MINGW64 ~/Code/discover/e2e/test-reports (discoverjs)
$ imagemagick identify -ping -format %wx%h run-first/login-2-after.png
bash: imagemagick: command not found

Prepending with imagemagic works:
paolo.delmundo@WLREM1611473 MINGW64 ~/Code/discover/e2e/test-reports (discoverjs)
$ magick identify -ping -format %wx%h run-first/login-2-after.png
1008x675

That's peculiar; ImageMagick never has a prefix and GraphicsMagick typically uses gm as its prefix. Can you link us to where you installed ImageMagick from?

http://www.imagemagick.org/script/binary-releases.php in the Windows binaries section

Ah, interesting. After doing some research on the gm repo, this is due to name conflicts with some Windows executables.
https://github.com/aheckmann/gm/issues/559
It still isn't patched in gm so we can't upgrade to anything newer. For now, the workaround from that linked issue is to use "Install legacy utilities" during installation

@mlmorg Can we add a new label named "blocked" with color #000000 and add it to this issue?
https://github.com/uber/image-diff/labels


root attribute does not work as expected when loading a model in voyager-explore

The documentation says:

root: Path to the root folder (base folder for all assets)
document: Path to the SVX scene descriptor JSON documen to load (relative to the root folder).
model: URL of a model (supported formats: gltf, glb) to load and display at startup (relative to the root folder)

When I try to embed the voyager in a website by means of the <voyager-explore> element with root, model and document attributes, the following works:
        rootUrl = "/data/editions/1/3d/4/models/original/"
        model = "clanwilliam.gltf"
        scene = "../../annotations/clanwilliam.json"

You would expect that the following would also work:
        rootUrl = "/data/editions/1/3d/4/"
        model = "models/original/clanwilliam.gltf"
        scene = "annotations/clanwilliam.json"

And it works for the scene: root and scene values are concatenated, but it does not work for the model, the console says:
Error: fetch for "http://<IP_ADDRESS>:5000/data/editions/1/3d/4/clanwilliam.gltf"

Apparently, when voyager constructs the model url it leaves out the models/original bit.
This is against the expectations.
I am using voyager-explorer.min.js from the 0.21.1 release.

Ah, it might be that the model path is not derived from the model attribute on the <voyager-explore> element but from the uri in the assets in the scene file.
Is the model attribute just a default, to be overridden by the scene file?

Hi @dirkroorda - the intent behind the 'model' attribute was for loading models not specified in the scene file. Our recommended workflow is to include the asset references in the scene file itself. We don't often use the 'model' attribute so it's entirely possible there is an issue. I will take a look.

If you have model references in your scene file as well, I think that's the error you are seeing. Your second example above works for me without the 'document' attribute. I agree the documentation implies that they can/should be used together. I will adjust that. I'm honestly not sure how much utility the 'model', 'geometry', and 'texture' attributes have these days so we may just get rid of them for clarity.

Got it. I now load the voyager-explorer with just the document attribute and not the model attribute, and indeed the scene specifies the model to load.
Thanks @gjcope  for the explanation and confirmation. So it is all about documentation on the one hand and me getting in tune with the thinking behind voyager on the other hand.

Yes, definitely a documentation deficiency. I will leave this issue open to make sure it is addressed. Thanks for pointing out the confusion @dirkroorda !

Hi @dirkroorda , I've updated the documentation here: https://smithsonian.github.io/dpo-voyager/explorer/api/ to better address the issue in this thread. I'll close this issue, but feel free to re-open if you feel it needs more clarity in the docs. Thanks!

🍦


Adding default service_urls

https://github.com/ssut/py-googletrans/issues/165

Coverage increased (+0.04%) to 89.453% when pulling 1144eae9b0a7d5bd05714f3b8383b9e103487819 on terryyz:master into 9fdb2346f0285f47c196856bd2e27f2392a5e4ff on ssut:master.

I'm sorry for giving you one more thing: I think it would be better to use tuple instead because list type is mutable by default.

Sure, let me have it changed.

I merged down to master, and also this will be in the release 3.0. Thanks!

I'll try to continue working on this repo and manage it as well if possible :p


Revert "Fix precedence of prefix expressions vs nav expressions"

Reverts alex-pinkus/tree-sitter-swift#275

Fixes #278


Update zio-prelude to 1.0.0-RC34

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

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

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

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

Superseded by #579.


monir: 修改个别文件换行符和配置

Codecov Report

Merging #818 (0f4122d) into v2.6.x_develop (8e0f6a3) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@                Coverage Diff                 @@
##           v2.6.x_develop     #818      +/-   ##
==================================================
- Coverage           61.19%   61.19%   -0.01%
==================================================
  Files                 461      461
  Lines               29262    29264       +2
==================================================
  Hits                17908    17908
- Misses              11354    11356       +2

Impacted Files
Coverage Δ

itsm/iadmin/models.py
88.34% <0.00%> (-1.10%)
:arrow_down:

Continue to review full report at Codecov.

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


Can't use default extras (dicts)

When I try to use the default extra files (e.g. gif.dict from testcases_extras folder) with the -x flag with afl-fuzz.exe, I get this error:
[-] PROGRAM ABORT : Extra '...path\to\gif.dict' is too big (298 B, limit is 128 B)
         Location : load_extras(), ...path\to\winafl\afl-fuzz.c:1931

It seems like the default gif.dict doesn't work - maybe it should be minimized or the threshold should be increased?

Could you give me a command line to reproduce this? There are two ways the -x flag can be used:

you could point it to an individual file which contains all the tokens
you could point it to a directory where each file in the directory is considered a token
so I'm wondering how you used it. In this case gif.dict is not a token, but rather a file containing the tokens and should be parsed as such.

afl-fuzz should detect if you pointed it to a file or directory, see https://github.com/googleprojectzero/winafl/blob/55bde9dad30854e33e625cf6565d450bac8e1472/afl-fuzz.c#L1920. But perhaps that check is wrong and thinks it's directory even though you pointed it to the exact file?

If this check is failing, then we could do a better check with GetFileAttributesA

So maybe I misused it? I pointed it at a directory (I think pointing it at a file failed, but I'll have to recheck) containing several dict files (gif.dict, jpeg.dict, etc.).
If, for example, I want to use all image-related dict files, I need to concatenate them all to a single file (simple file concatenation)?

Right, either (a) concatenate it all in a single file, or (b) extract all tokens from all files as separate files to a directory. (a) is probably simpler.


Implement mass machine type transition: virtctl update machine-types cmd

What this PR does / why we need it:
This is the initial implementation phase of this Design Proposal.
As stated in the design proposal, as newer OS versions are released, machine types become deprecated and/or unsupported, and a user will want to update the machine type of VMs with these deprecated/unsupported machine types. There may be also be other reasons a user will want to update the machine type of VMs. Currently, the only way for the user to do this would be to manually patch the machine type of each VM individually, manually taking any running VMs offline and restarting them in order for the patch to take effect.
This PR aims to provide an automated way for the user to update the machine types of the VMs, all at once, or in batches based on specific parameters (i.e. by namespace or label-selector). By default, the command will not automatically restart any affected VMs that are running, but the user can also set a flag to automatically restart the affected running VMs.
This is implemented through a virtctl cmd: virtctl update machine-types. This command will generate and deploy a Job, which will update the machine type of VMs with machine types that match the machine type(s) provided by the user (as a glob) with the required flag --which-matches-glob. The user will be able to specify flags: --namespace, --force-restart, --label-selector. By default, this will update any of the applicable VMs to the latest machine type by using the default machine type alias; the ability to specify a target machine type to update the VMs to may be added in future implementation phases, as well as more flags to allow the user more freedom in selecting which VMs to update.
Please see the Design Proposal for more details on the specific implementation of this feature and things that will be added in future implementation phases.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

virtctl update machine-types command has been added with required --which-matches-glob flag specifying what machine type(s) to update, and optional flags --namespace, --force-restart, and --label-selector
This command is used to update the machine types of VMs with machine types that match the specified glob.

/cc @iholder101

cc @iholder101 fwiw I've left some of these comments in a previous pr, or a previous version of this pr, but they were not looked at

Hey, good to see the pr and work.
A few relevant items:

The machine types you are using are vendor specific, thus they must not be hardcoded. Other vendors have other mts

+1

The problem to determine if a VM needs an update or not is not really solved.

WRT 1+2 - Can't we provide the list of supported MTs to the cli, everything else will be updated ie virtctl … --keep rhe-9.2,q35,rhel-9.3

We had a little discussion regarding it here.
In any case, in the design proposal we suggest to implement it as a follow-up, and in the initial version to only get the targeted type as an argument.
Do you think it's a blocker for the PR to be able to retrieve the available types dynamically?

The problem of updating an MT in a VM is solved in a complex way.

WRT 3 - Was it explored to just remove the MT from the VM. It should be immediately set to the current cluster default due to our adm webhook.

One concern would be that the VM could be using either pc or q35 based types. So if a VM uses pc-something-1.23 and we remove it, the new VMIs would be spawned with q35 since it's the default. Our cluster-wide default can be overridden by individual VMs, so we might confuse the user with this.
WDYT?

The cli command should not be top-level

WRT 4 - Currently it's a top-level command, but this simply bloats all top-level commands. To me this is an update ot a VM, or multiple. Can we intorduce virtctl update to then take a list of subcommands (mt update being the first) to perform vm level updates? Or something in a sub-command at least

+1

There is no way to get the supported MTs from the cluster
WRT 5 - When we ask users to work with MTs then let's also provide a way to query the current available ones. Including marking the ones that are deprecated.

As said above, this is planned as a follow-up

cc @iholder101 fwiw I've left some of these comments in a previous pr, or a previous version of this pr, but they were not looked at

@fabiand Sorry to not respond! I must have missed them.
However, I can't find any comments that weren't looked at either in this PR, the previous PR, and the design proposal. Would you kindly refer me to these comments so I could address them?

@iholder101

Do you think it's a blocker for the PR to be able to retrieve the available types dynamically?
I think hardcoding any machinetype is difficult, anybody who is rebuilding kubevirt has to adjust them.
Thus make them to be provided by the user should be the first step.
Combined with the ability to query MTs from the cluster

One concern would be that the VM could be using either pc or q35 based types. So if a VM uses pc-something-1.23 and we remove it, the new VMIs would be spawned with q35 since it's the default. Our cluster-wide default can be overridden by individual VMs, so we might confuse the user with this.
WDYT?

Yes, unconditionally unsetting the MT would be dangerous. But I was thinking of the unsetting the context of the above:

We need a mechanism to specify which MTs are outdated (this is what we discussed above)
We need a mechanism to determine the new machine type
We need a mechanism to set the new machine type

(1) can be solved by i.e. virtctl update machine-types --which-matches-glob *rhel-8.*. Thus here the user provides a glob pattern to identify MTs that should be updated
(2) and (3) are then solved by unsetting MTs that match the glob pattern from (1).
An alternative for (1) would be  `virtctl update machine-types --in-list rhel-8.2,rhel-8.1,[…]*

However, I can't find any comments that weren't looked at either  […]
Yes. I also failed to find them. Maybe I missed to submit :-/

Yes, unconditionally unsetting the MT would be dangerous. But I was thinking of the unsetting the context of the above:

We need a mechanism to specify which MTs are outdated (this is what we discussed above)
We need a mechanism to determine the new machine type
We need a mechanism to set the new machine type

(1) can be solved by i.e. virtctl update machine-types --which-matches-glob *rhel-8.*. Thus here the user provides a glob pattern to identify MTs that should be updated (2) and (3) are then solved by unsetting MTs that match the glob pattern from (1). This is becuase the KubeVirt CR already has the default MT (it kows it), and by unsetting it in a VM, this MT will be defaulted on the VM (it's seeting the new MT).
An alternative for (1) would be `virtctl update machine-types --in-list rhel-8.2,rhel-8.1,[…]*

So, just to make sure I understand you correctly, the following would identify VMs with the specified machine types and would unset the machine type to be defaulted:
virtctl update machine-types --which-matches-glob *rhel-8.*
Now, let's say that some VMs use a different machine type than the default defined by Kubevirt CR. Then, we can do something like:
virtctl update machine-types --which-matches-glob pc.* --target-type pc"
In other words, the user would have the choice between "unset the machine type and let the default kick in" and "set a non-default machine type to certain VMs". Is this how you picture it?
I like the idea of getting a list of supported machine types automatically, but moving the responsibility to the user to filter them out by regex and determining which one they wish to set, as least initially. However, at least in my eyes, this is not a blocker for this PR and we could first merge a logic which puts all the burden on the user to pass the targeted machine type without a mechanism to query the supported ones, and without a hard-coded targeted type. It would still be valuable to advanced enough users, and we can improve this in a follow-up. However if you think otherwise it's possible to implement it here.
@lyarwood, since you were also discussing this problem here, do you have any thoughts on this?

However, I can't find any comments that weren't looked at either  […]

Yes. I also failed to find them. Maybe I missed to submit :-/

Ah, sorry to hear that :/

So, just to make sure I understand you correctly, the following would identify VMs with the specified machine types and would unset the machine type to be defaulted: virtctl update machine-types --which-matches-glob *rhel-8.*
Now, let's say that some VMs use a different machine type than the default defined by Kubevirt CR. Then, we can do something like: virtctl update machine-types --which-matches-glob pc.* --target-type pc.X

Yes
(Althought I'd do virtctl update machine-types --which-matches-glob pc.* --to pc.X)

In other words, the user would have the choice between "unset the machine type and let the default kick in" and "set a non-default machine type to certain VMs". Is this how you picture it?

Yes. While I think that the first use-case is more important than the second. Just from a relevance pov.

I like the idea of getting a list of supported machine types automatically, but moving the responsibility to the user to filter them out by regex and determining which one they wish to set, as least initially. However, at least in my eyes, this is not a blocker for this PR and we could first merge a logic which puts all the burden on the user to pass the targeted machine type without a mechanism to query the supported ones, and without a hard-coded targeted type. It would still be valuable to advanced enough users, and we can improve this in a follow-up. However if you think otherwise it's possible to implement it here.

Today the user knos what MT is set on a VM, thus we can work with this.
This available data owuld limit us to the first use-case (just unsetting based on glob).
In order to let a user set the MT to a specific value, the user MUST know what is available in the cluster. Without a fature to retrieve the MTs this is really difficult (qemu in cluster and on client could be different).
Thus without the ability to retrieve cluster supported MTs the second (set MT to asomething specific) should depend on this feature.
Guiding principle: Let the user work with the data that is available to them. Let the system stay self-contained.

/cc

/test pull-kubevirt-unit-test

/retest

/cc @EdDev for the kind/api-change label


Some initial feedback

curl options - I'd suggest using ... or similar to allow curl options to be passed
into GET/POST/etc.
authentication: I haven't dug into this, but i imagine passing in the
session bit to each function call makes sense more so if there are multiple
potential accounts a user could have, while if a user will only ever have
one, then perhaps the auth function could be run once by a user, and then
run internally within function calls so the user doesn't have to worry about
it

looking through this more, but these are the first two things...

@sckott, what uses do you think passing the curl options would have? Are you referring to supplying additional or different query parameters?
Right on about authentication. It was kinda a stopgap measure to get the project rolling.

@lawinslow for curl options I'm talking about this stuff http://ropensci.org/blog/2014/12/18/curl-options/ - not to plug my own blog post, but just easier to point to that - basically for curl debugging, etc. - Some non-debugging usage too, like printing progress(), and setting a timeout()  so that a call fails if it hasn't succeeded within a certain time frame.

Ah, excellent point. Thanks!


fix broken test

Codecov Report

Merging #249 (619156f) into master (767e296) will decrease coverage by 0.55%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #249      +/-   ##
==========================================
- Coverage   87.16%   86.60%   -0.56%
==========================================
  Files          10       10
  Lines        2049     1971      -78
==========================================
- Hits         1786     1707      -79
- Misses        263      264       +1

Impacted Files
Coverage Δ

src/abstractinterpret/abstractanalyzer.jl
80.64% <0.00%> (-3.36%)
:arrow_down:

src/analyzers/jetanalyzer.jl
91.91% <0.00%> (-1.03%)
:arrow_down:

src/abstractinterpret/typeinfer.jl
94.16% <0.00%> (-0.33%)
:arrow_down:

src/analyzers/optanalyzer.jl
86.74% <0.00%> (-0.32%)
:arrow_down:

src/JET.jl
67.08% <0.00%> (-0.24%)
:arrow_down:

src/toplevel/virtualprocess.jl
96.65% <0.00%> (-0.17%)
:arrow_down:

src/toplevel/graph.jl
100.00% <0.00%> (ø)

src/abstractinterpret/inferenceerrorreport.jl
88.32% <0.00%> (+0.55%)
:arrow_up:

src/ui/print.jl
90.56% <0.00%> (+0.56%)
:arrow_up:

Continue to review full report at Codecov.

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


WordPress /wp-admin/site-health.php triggers

Description
Trying to open /wp-admin/site-health.php triggers a 403 despite being a legit request; despite the WP exception rules being enabled in /etc/modsecurity/crs/crs-setup.conf:
SecAction  "id:900130,  phase:1,  nolog,  pass,  t:none,  setvar:tx.crs_exclusions_wordpress=1"

Audit Logs / Triggered Rule Numbers
Message: Warning. Pattern match "(?i)(?:System\\.Data\\.OleDb\\.OleDbException|\\[Microsoft\\]\\[ODBC SQL Server Driver\\]|\\[Macromedia\\]\\[SQLServer JDBC Driver\\]|\\[SqlException|System\\.Data\\.SqlClient\\.SqlException|Unclosed quotation mark after the character string|'80040e14' ..." at RESPONSE_BODY. [file "/usr/share/modsecurity-crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf"] [line "340"] [id "951220"] [msg "mssql SQL Information Leakage"] [data "Matched Data: SQL server is up to date\x22,\x22status\x22:\x22good\x22,\x22badge\x22:{\x22label\x22:\x22Performance\x22,\x22color\x22:\x22blue\x22},\x22description\x22:\x22
The SQL server is a required piece of software for the database WordPress uses to store all your site’s content and settings.<\x5c/p>\x22,\x22actions\x22:\x22
Learn more about what ..."] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "applic
Message: Warning. Pattern match "(?:\\b(?:f(?:tp_(?:nb_)?f?(?:ge|pu)t|get(?:s?s|c)|scanf|write|open|read)|gz(?:(?:encod|writ)e|compress|open|read)|s(?:ession_start|candir)|read(?:(?:gz)?file|dir)|move_uploaded_file|(?:proc_|bz)open|call_user_func)|\\$_(?:(?:pos|ge)t|session))\\b" at RESPONSE_BODY. [file "/usr/share/modsecurity-crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf"] [line "72"] [id "953110"] [msg "PHP source code leakage"] [data "Matched Data: session_start found within RESPONSE_BODY: <!DOCTYPE html>\x0a\x0a\x0a<meta http-equiv=\x22Content-Type\x22 content=\x22text/html; charset=UTF-8\x22 />\x0a\x09<title>Site Health Status ‹ mysite.com — WordPress</title>\x0a


Add doctype to webview html

Reference: #7626
Not having a doctype declaration can cause some CSS renderings to do weird things.  This is seen for instance in KaTeX as described in #7626.  This will allow KaTeX to render properly in .previewHTML invocations.

Hi @cbreeden, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

@cbreeden thanks for your help on this, it's a valid bug fix and we ran into this issue several times and felt really painfull! We've had a fix for this issue while implementing Markdown Extension Extraction, see https://github.com/Microsoft/vscode/blob/kieferrm/markdown/src/vs/workbench/parts/html/browser/webview.html#L109 . Sorry for the late reminder :)
I'm Okay to have this merged first, totally up to @jrieken .

Oh nice.  I was writing a markdown editor extension myself when I came across this.  No need to merge this if @jrieken is on his way to merging the Markdown Extension.  I suppose this means that we will be able to change out the markdown rendering engine and even perhaps have access to those buttons in on top of the documents.  Exciting stuff :) I'll wait, thanks for the response. :+1:

Thanks. My plan is to merge the markdown branch this week.


Dependency conflict with org.apache.pdfbox, fontbox

Since this package uses the shade plugin, classes from org.apache.pdfbox and org.apache.fontbox are copied into the jar in the package phase. This is great for creating a standalone executable jar to execute from the commandline as it includes everything needed in the specific version.
When using the package as a library in a project that also depends on pdfbox or fontbox, the copied classes may conflict with the versions defined as dependencies of the project. For example the version specified in mustangproject is 2.0.5 but the project using mustangproject needs 2.0.8, leading to conflicts.
In my case, version 2.0.8 of pdfbox fixes an issue with embedding subsets of fonts in PDF/A files. Normally when specifying a different version in the project using mustangproject I would add pdfbox to the dependencies and maven would load my version instead of the version mustangproject depends on. Unfortunately this is not possible since mustangproject already provides version 2.0.5 copied to the jar.

We use in a large project all kind of PDF and XML processing and we tried to add mustang, but these bundled classes generate all kind of errors and unwanted effects. It is fine for an application to bundle the dependencies in a single jar, but for a library that should be used in a bigger concert it is an absolute no-go. Especially for a Maven-based project, where all required dependencies are automatically managed, it is essential to have a normal library and POM with declared deps.
Please consider Markus' advice. A separate commandline artifact that contains all stuff is fine, but for a proper projects with dependency management we need the base library. In the current form it is not usable.

This is also quite a showstopper for us. Artifacts pushed to the maven repo should never contain the dependencies. The shade plugin is fine for standalone jars (which should be named as such, mustang-standalone.jar or smth.), but not for libraries.

We also have the problem that we need the Mustang library without the dependencies.
Is it possible to provide the library without dependencies with pom file. (no fatjar)

the library without dependencies is available via https://www.mustangproject.org/deploy/original-mustang-1.7.8.jar and the whole thing is now also on maven central (in case anybody needs it with gradle)


Wrong Link for Get private link service

should link to '/powershell/module/az.network/new-azvirtualnetwork' instead of '/powershell/module/az.network/new-azloadbalancer'

@YixuanEric : Thanks for your contribution! The author(s) have been notified to review your proposed change.

This fix has been applied in the live article. I'll close this PR now.


Markdown

Let's leave what we have now since it's a logo and doesn't need to be a part of the set. I'll move over the old markdown octicon and put it into a 16x16 frame.


Unsafe does not invoke initializer

I see that you fixed  #124 for constructors. Can also initializer be called? I discussed this in this SO question.

why you delete question?

I do not deleted it. It got one downvote for obscure reasons and auto-deleted :)


Link to API docs gives 404

In your readme file your link to the API Docs, https://seaneking.github.io/react-portal-overlay/, is giving me a 404.

The correct url is https://madeleineostoja.github.io/react-portal-overlay/ and will be fixed in #8.

The correct url is https://madeleineostoja.github.io/react-portal-overlay/ and will be fixed in #8.


[SPARK-30432][Graphx]reduce degree recomputation in StronglyConnectedComponents

So the computation happens every time in the do-while loop, the first time the outer while loop executes. although just once per do-while loop after, it seems, but It does reduce a lot of recomputation；because every time it jump out of the do-while loop，there are no vertices have only out-degree or in-degree，so it's no need to recompute degree to tag the vertices true.
I have done a small code proposal, because there is a problem when the pregel executions have done,  the degree no need to be recomputed.

for example，the Email-EuAll  data set：http://snap.stanford.edu/data/email-EuAll.html
do-while loop execute 10 times，and the reduce logic happend 8 times；so it would be helpful when computing StronglyConnectedComponents to reduce degree computation.

I created a branch in my fork: https://github.com/xs-li/spark/blob/master/graphx/src/main/scala/org/apache/spark/graphx/lib/StronglyConnectedComponents.scala
I hope you can consider this small code proposal.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

I don't quite understand your description of why it's not necessary. @ankurdave would you happen to have context on this?

i mean，when the second pregel execution done ，and it will go to the do-while loop，because now it had find some SCCs，but no vertice has only out-degree or in-degree；so the first time enter the do-while loop，it not need to outerJoin degree。


Default setup w/ redis not working (Windows)

Hi guys,
I have just followed the instructions in the README, i.e. installed fuse globally, generated the scaffold, then started it with fuge run ./fuge/compose-dev.yml.
During the scaffolding, I selected redis as the communication mechanism, for both of the default services.
This is on Windows 7, 64bit.
The errors below indicate an issue with the redis transport layer. The whole thing went a little fast so I can only surmise that the redis docker container wasn't downloaded properly?
> fuge run ./fuge/compose-dev.yml
compiling...
starting proxy...
  proxy frontend 10000 -> <IP_ADDRESS>:20000
  proxy service1 10001 -> <IP_ADDRESS>:20001
  proxy service2 10002 -> <IP_ADDRESS>:20002
running: frontend
running: service1
running: service2
running: __proxy
[service2 - 6604]: 2016-01-28T09:06:35.222Z uw9y8dlaklfo/1453971995207/3108/- INFO      hello   Seneca/0.7.2/uw9y8dlaklfo/1453971995207/3108/-
[service1 - 10472]: 2016-01-28T09:06:35.239Z mpqkftac8swp/1453971995207/10152/- INFO    hello   Seneca/0.7.2/mpqkftac8swp/1453971995207/10152/-
[frontend - 11324]: 2016-01-28T09:06:35.550Z 66urhk3syiy2/1453971995519/6376/- INFO     hello   Seneca/0.7.2/66urhk3syiy2/1453971995519/6376/-
[service2 - 6604]: 2016-01-28T09:06:35.597Z uw9y8dlaklfo/1453971995207/3108/- INFO      listen  {type:redis-queue,pin:role:db,cmd:*}
[service1 - 10472]: 2016-01-28T09:06:35.613Z mpqkftac8swp/1453971995207/10152/- INFO    listen  {type:redis-queue,pin:role:db,cmd:*}
[service2 - 6604]: 2016-01-28T09:06:35.628Z uw9y8dlaklfo/1453971995207/3108/- INFO      plugin  redis-queue-transport   ACT
0nqaqjbtovi8/4iaacxe1ih9h       hook:listen,role:transport,type:redis-queue     listen  open    {timeout:10556,type:redis-queue,host:localhost,port:6379,pin:role:db,cmd:*,msgprefix:seneca_,callmax:111111,msg        {did:(wuy8k),fixedargs:{},context:{}}
[service1 - 10472]: 2016-01-28T09:06:35.644Z mpqkftac8swp/1453971995207/10152/- INFO    plugin  redis-queue-transport   ACT
bts0f3fxccyz/0e660z758mi0       hook:listen,role:transport,type:redis-queue     listen  open    {timeout:10556,type:redis-queue,host:localhost,port:6379,pin:role:db,cmd:*,msgprefix:seneca_,callmax:111111,msg        {did:(5tt3b),fixedargs:{},context:{}}
[frontend - 11324]: 2016-01-28T09:06:35.784Z 66urhk3syiy2/1453971995519/6376/- INFO     client  {host:<IP_ADDRESS>,port:10001,pin:{role:service1}}
[frontend - 11324]: 2016-01-28T09:06:35.784Z 66urhk3syiy2/1453971995519/6376/- INFO     client  {host:<IP_ADDRESS>,port:10002,pin:{role:service2}}
[frontend - 11324]: listening on port: 20000
[service2 - 6604]: events.js:141
      throw er; // Unhandled 'error' event
      ^

Error: Redis connection to localhost:6379 failed - connect ECONNREFUSED <IP_ADDRESS>:6379
    at RedisClient.on_error (c:\Git\fuge-test\service2\node_modules\seneca-redis-queue-transport\node_modules\redis\index.js:196:24)
    at Socket.<anonymous> (c:\Git\fuge-test\service2\node_modules\seneca-redis-queue-transport\node_modules\redis\index.js:106:14)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at emitErrorNT (net.js:1253:8)
    at doNTCallback2 (node.js:441:9)
    at process._tickDomainCallback (node.js:396:17)
[service1 - 10472]: events.js:141
      throw er; // Unhandled 'error' event
      ^

Error: Redis connection to localhost:6379 failed - connect ECONNREFUSED <IP_ADDRESS>:6379
    at RedisClient.on_error (c:\Git\fuge-test\service1\node_modules\seneca-redis-queue-transport\node_modules\redis\index.js:196:24)
    at Socket.<anonymous> (c:\Git\fuge-test\service1\node_modules\seneca-redis-queue-transport\node_modules\redis\index.js:106:14)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at emitErrorNT (net.js:1253:8)
    at doNTCallback2 (node.js:441:9)
    at process._tickDomainCallback (node.js:396:17)
process exit [6604]: service2
process exit [10472]: service1

I don't want to add too much noise, but let me know if you want me to also post the contents of the three log files (frontend, service1 and service2).
Any idea what went wrong?

Actually, never mind. I just saw that this doesn't happen automatically and I'm supposed to get the redis container myself.
That didn't work either, i.e. docker pull redis failed with this error:
An error occurred trying to connect: Post http://localhost:2375/v1.21/images/create?fromImage=redis%3Alatest: dial tcp <IP_ADDRESS>:2375: ConnectEx tcp: No connection could be made because the target machine actively refused it.

But I then started from scratch without redis and that went fine as far as I can see.

Ok well, got excited too quickly.
While using the http method didn't produce any errors (i.e. all three processes seem to be running fine), actually accessing the frontend via the browser produces another connection refused error:
> fuge shell ./fuge/compose-dev.yml
compiling...
starting proxy...
  proxy frontend 10000 -> <IP_ADDRESS>:20000
  proxy service1 10001 -> <IP_ADDRESS>:20001
  proxy service2 10002 -> <IP_ADDRESS>:20002
starting shell..
? fuge> client error: 10000 -> <IP_ADDRESS>:20000 => ECONNREFUSED
please retry operation
client error: 10000 -> <IP_ADDRESS>:20000 => ECONNREFUSED
please retry operation

I get the feeling Windows support is still a little rough around the edges.

@batjko thanks for testing this on Windows. You are right, Windows support is definitely not on par. We'll have a look and we'll get this fixed.
There seem to be an issue with the proxy.

Have published an update with improved windows support. Also I have removed the redis support for now as this was not working correctly. If you could please upgrade, generate a fresh system and let us know if this is now working for you on windows, that would be awesome!

Yup, that seems to have done the trick.
Updated fuge, generated a new system (I wasn't asked anymore whether to use http or redis), and localhost:10000 gives me the expected page. The services are up and produce proper output.
I'm happy to close the issue, even though Redis isn't working but since that's essentially descoped now that's fine.

Awesome - thanks!


Use IPAM for ctlplane with pre-provisioned

recheck

recheck

Need to test this locally.

recheck

/test all

recheck

/test install-yamls-deploy

/override rdoproject.org/github-check


Provide basic support for CockroachDB

What should be done?
At least uncomment CockroachDB in the GitHub Actions config and make the tests pass.

Saw the application on HN today, and my first thought was this could be pretty cool on top of CockroachDB, which I know has a more limited surface than PostgreSQL proper, but would really appreciate this.

@tracker1 Thanks for reaching out!
Have you seen the articles of Artem Ervits at CockroachDB? I linked them below.
He experimented with FerretDB+CockroachDB and wrote a series of articles on it.  We haven't tested it ourselves, so we don't support it officially. Please test it, and let us know how it went.
Also, these are older articles, so the feature set has improved since.
https://dzone.com/articles/migrating-mongodb-collections-to-cockroachdb-with
https://dzone.com/articles/using-cockroachdb-as-a-backend-for-oss-mongodb-alt
https://dzone.com/articles/experimenting-with-unique-constraints-in-cockroach
https://dzone.com/articles/cockroachdb-multiregion-abstractions-for-mongodb-d

I really like CockroachDB compared to postresql.

@ptrfarkas did you find any code samples from those links ? would like to test.

hi @gedw99, I don't have any code samples as I was just improvising. What specifically do you need? Here's my docker compose repo https://github.com/dbist/cockroach-docker/tree/main/cockroach-ferretdb. You can run CDC with CockroachDB core but its limited compared to the enterprise version. Frankly, I've never tried it. You can run cockroach demo which gives you a fully capable enterprise version for an hour or use CockroachDB Serverless, which has a generous free tier and CDC is included.

Also, here are the gists with the code used in the articles:
https://gist.github.com/dbist/df732ae51cb290db08bbabaf506ca154
https://gist.github.com/dbist/c94fa979663b27ab35e896fd455024c7
https://gist.github.com/dbist/31ccdf25ee33644ffb66e7ef3540549c
https://gist.github.com/dbist/935194a62edcef8fd24822c7eeb6f1f0


Need a separate Internship Page

Sir, can I work on this Issue, Please Assign me

@SahityaRoy pls assign me this

@SahityaRoy add me in assignee


samples: drivers: lora: receive: add formatted received packet display

Added more descriptive introductory prints to show settings being used,
then "sanitized" string and byte hex dump prints for each packet
received.  Packet counter also shown.
Signed-off-by: Dean Weiten<EMAIL_ADDRESS>

One thing that I've noticed is that I restrict the size of received packets.  That's a bit of an oversight on my part.  My own custom LoRa system has packets that are limited in size, but in general that's not the case.  I could expand it back out to the maximum LoRa packet size, if you think that would be appropriate...

One thing that I've noticed is that I restrict the size of received packets. That's a bit of an oversight on my part. My own custom LoRa system has packets that are limited in size, but in general that's not the case. I could expand it back out to the maximum LoRa packet size, if you think that would be appropriate...

I will make that change.  Also realized that I had wasted stack space, found out when I tried to increase the buffer sizes.  Also think it's appropriate to try again on failed receive.  Hope that's OK.
Please advise if any of this is no reasonable to you.

It turns out that the compliance check has interesting rules on formatting :-)  I believe I've fixed the issues found.
This is my first time doing this type of workflow.  If there is an issue with the way that I'm doing the commits, the commit messages, or the push, please let me know.
I'm not that attached to the changes that I've proposed... if you really don't like them, I would cancel them.

Hi, it has been some time without feedback. Is there something else I should be doing?

Hi, it has been some time without feedback. Is there something else I should be doing?

I've been advised that it's a busy time, trying to get a release out, that everyone is busy, so I will just chill :-)


[MMBNLC] Could not encode character with french accents

Hi, thanks for your software!
I have some problems when reinserting; if two special characters (For example éé in the sentence "On créé" (We create)), the reinsertion fails and gives me the error :
"FATAL: Could not encode character  in script 0 of text archive 70BD8C."
The character is missing in the log, so I guess it tries to get a character that never existed
Even adding é or éé in the bn-1-utf8.tbl, the problem occurs
This does it even with àà
Any idea how to fix this?
Thanks!

Please read the relevant guide: https://forums.therockmanexezone.com/mmbnlc-modifying-adding-new-characters-to-the-font-t16728.html


SourceFile top level comment

Hello. I use ts-simple-ast to generate the code like this:
const sourceFile = typescriptProject.createSourceFile(...);
...
sourceFile.save();

Because output code is not written by man, it should not be analyzed by the linter.
How can I add top level comment like
// tslint:disable
to prevent analysis?

You can use addStatements, insertStatements or addStatement with a writer. See docs
sourceFile.insertStatements(0, "// tslint:disable");

Yup that's it. Thanks @Gerrit0!
@sosoba I recommend doing that as the last step because of #189. That has to do with how comments are not stored in the ast.


[Advanced Paste > Paste with AI] Does the preview costs extra quota (paied credits)?

Provide a description of requested docs changes
Does enabling the preview for Paste with AI costs extra AI quota (paid credits) compared to not enabling the preview?
There should be a hint about the behavior in PT Setting and/or the docs page on learn.microsoft.com

@jaimecbernardo
Is this something we should add to settings ui or docs on learn.microsoft.com?

It doesn't 🤔 Guess it would be a good detail on docs.

Will you add this to the clarification PR in the docs repository?