Return should be legal in Subs

Describe the bug
Trying to Return from a Sub raises a "internal error"
To Reproduce
Create the code:
    Public Sub Duh()
        Return
    End Sub

It will highlight Return as an error.
Expected behavior
No error. It should be legal to return. Had I put in something to return (e.g. Return 1 or Return "foo"), then it's appropriate to show an error since it's a Sub.
BTW, I prefer this over Exit Sub because this avoids the need to change the code should it change from Sub to Function (or vice versa).
Desktop (please complete the following information):

OS: Windows 7
twinBASIC compiler version 11.120

For continuity reasons I believe we should strive to get this Return syntax allowed in Subs. The runtime error of the old syntax is a consideration, but this is largely mitigated by us simply disabling the new Return syntax when the legacy Gosub is encountered within a procedure.
That just leaves the nonsensical use of Return, with it throwing a runtime error in the old syntax without any Gosub appearing in the procedure... and I feel that supporting that 'feature' would be taking the 100% compatibility goal too literally here, without considering the bigger picture.

Bump.
A Return outside of a Gosub block, then catching the runtime error that is certain to result is... bizarre?
I feel like this could easily be accommodated by an "absolute" project switch for legacy compatibility. Almost nobody would be caught by this, and a project switch could keep the 100% promise.

Just wanted to put out a different approach:
Private Sub Foo()
  Return Default
End Sub

Private Function Bar() As Long
  Return Default ' Returns 0
End Function

Private Function Fizz() As String
  Return Default 'Returns vbNullString
End Function

Private Function Buzz() As Variant
  Return Default 'Returns vbEmpty
End Function

The Return Default is a illegal statement in VBx so there is no backward compatibility issues,  and has the added bonus of simplifying the refactoring (e.g. changing a Sub into a Function and still getting a default value).

Need to be really conservative with taking over keywords... Default isn't exactly an uncommon name so you might be creating issues with Function Default() for a lot of people.

Hmm, Return Default is a syntax error so the problem would only exist in a tB project, rather than importing from legacy VBx projects. A warning could be issued if there's an ambiguity, though one might question whether it should be necessary in the first place. If we don't want the potential of an ambiguity, Return As Default would work, too if a bit more wordy.

Default is a legal function name in VBx; that's where I see the problem arising.
But I think so long as there's no GoSub, it shouldn't be needed to have anything besides Return at all.
Another possibility I was thinking about... do we even need a toggle based on the presence of GoSub? Couldn't the two be integrated by block?
Sub foo()
someCode
GoSub bar
Return
bar:
subCode
Return
End Sub

The Return at the bottom would be considered within a GoSub block, so it triggers an exit to the next higher level. The Return up top also returns to the next higher level-- exiting the sub entirely.

The issue is that in VBx, that's a runtime error 3 Return without GoSub. If there's VBx code that rely on this behavior, it would stop working and thus not be 100% backward compatible. However, I do agree with mansellan's earlier remark that it's bizarre. Just want to avoid the need to have a switch or anything like that.
That said, if we did go with just Return, I wouldn't shed a tear over the change in behavior WRT the error 3.

AFAIK Wayne has said it's been decided to not worry about compatibility with illegal syntax... that would be handcuffing the language for what's a theoretical benefit (I've never seen VB code rely on syntax errors). tB already allows AddressOf where VBx doesn't... that shouldn't be rolled back just on the off chance someone somewhere may have written a routine that relies on triggering that error.
If tB was taking backwards compatibility that far, there's things way higher on the compatibility list that aren't merely theoretical... when it's time to start advertising tB to the general public, there's going to be a need for an asterisk and explainer of what "100% compatibility" means, because there's a lot of code out there which will never run in tB because it's using elaborate hacks based on internal VB structures and undocumented runtime APIs. So there's already a limit here... and bizarre situations of people using illegal syntax to deliberately trigger errors is far less of an issue.

Nitpick: it's not illegal syntax. It's legal syntax that results in a runtime error.

What if Return on a Sub did something useful like set the HResult.
Return 0 for success, same as Exit Sub
Return N for failure
Enforcing an integer return code (or an expression that evaluates to one) would prevent syntax clash I think.
I could see this being handy for console applications, perhaps if the last HResult corresponded to the console app exit code.

I quite like Return Default tbh. It solves the problem quite neatly, and (in future) being able to assign Default explicitly could come in quite useful for generics (at least, it does in .net).

Btw, for functions the proposed Return Default behavior can almost be emulated by Return Empty (not sure about reference types on retval). Another option is to allow Return Empty on subs.

Just to throw some conversation gasoline on this fire, am I mis-remembering, or was there not a BASIC language implementation (or two...) that permitted:
...
GoSub Routine1
Label1:
...
GoSub Routine2
Label2:
...
End
Routine1:
...
If x then Return Else Return Label2
Routine2:
...
If x then return label2 else return Label1
...and if that's correct, will we need to accommodate that logic as well (since we're talking language specifications here)?

As for "Return Default" and "Return Empty" Well, We'll need to add "Return Nothing" to the list. Or, how about "Return " too?
I know! Let's add "Return WhateverTheHeckYouWant" while we're at it too!
What's wrong with allowing the programmers to decide explicitly what needs to be returned in ANY programming circumstance and MAKE THEM EXPLICITLY DO IT!?
Why are we trying to make these things fit into a specification for a language that was first meant for use as a TEACHING TOOL - and NOT to be the "Be-All-End-All Best-est Language Uber Alles!!" (as we seem to be drifting towards)?

Having Return be legal in functions but not in subs does make things more confusing for beginners. So we do need syntax for allowing it in subs. I would agree that if at all practical that should just be a plain old 'Return', but the others were just suggesting possible alternatives if it's too impractical to resolve the issue with GoSub/Return (I don't think it is, and believe my comment above outlines a way to handle syntax that would even allow mixed use).
I don't think that if Wayne determines we do need an extra keyword in Sub we should use ones that already have very specific meanings in this context... i.e. they're currently used in Function Return syntax:
Function foo() As IUnknown
    Return Nothing
End Function

Function bar() As Variant
    Return Empty
End Function

I agree that would raise an issue with reducing clarity.

(Your other comment, Return  isn't allowed in VB6 and the last thing we need to be doing is encouraging more use of this mistake by expanding it's features... maybe we should talk about a compiler warning similar to the one for DefType).

Just to be clear, I was not advocating FOR that capability. Nor did I say it was a VB6 feature. (I was trying to call it out as a possible tripping hazard, in terms of the tB language spec., at best). I just dimly recall being able to so things LIKE that in BASIC-variants of the past.

Having Return be legal in functions but not in subs does make things more confusing for beginners.

I disagree - that is entirely consistent with their basic definitions: a Function returns a value. A Sub does not. That is simple and clear.
What is less simple and clear is the semantics of allowing Return (as a flow control element) into Subs and having the same Return keyword mean something different in a Function (return a value as well as flow-control) -vs- Return for a GoSub again being only a flow-control keyword.
THAT is more confusing than the well-established (function name here) = (return value expression) syntax you all suddenly seem to abhor even though it is quintessential VBx syntax.
To me it would make more sense to treat all functions as if they were virtual objects(classes) with properties, and THEN
(functionnamehere).RetVal = (return value expression)
(OR Set (functionnamehere).RetVal = (return value expression) if you will)
(perhaps this is where the This-as-a-keyword for the current "virtual function object instance"...would at least make sense, permitting This.Retval = (whatever).
Then the "return this value from the current procedure" semantic would be separated entirely from the flow-control logic.  Now THAT would keep things simpler IMO.

Why do you think having two definitions of Return improves clarity?
GoSub/Return... Go SUB, RETURN (from SUB) without returning a value. The VB6 context of "Return" already defines it as 'return from' rather than 'return this'.
Adding on something after 'Return' to signify return with that value already marks a difference without any harm to clarity. Plus it's water under the bridge, I seriously doubt Return is going away in functions. You're proposing two different meanings for a free-standing Return. "When you use Return with GoSub, it's pure flow control logic. But if you use Return outside of GoSub, it's both flow control logic in functions and assignment logic in functions, but in Subs without GoSub, it's purely assignment logic, so because there's nothing to assign you're not allowed to use it. " This doesn't appear to be clear at all, it's extremely confusing how you're drawing this line that Return returns from a GoSub, and Returns from a function with the functions value after it, but doesn't mean you can return from a sub.

One other point, We all despise the Def(type) = (whatever) elements of the VBx language, right?
Well, your Return Default would tend to need a variation of those, like:
DefVarType = (one of vbString, vbLong, vbLongLong, etc.)
But instead of saying what variable types match which first-letter-in-the-variable-name that the Def(Type)s do tells the compiler what the Default SubType is used for all otherwise un-assigned Variants (once they are assigned a value, they adjust to the type of the value, of course as they do at present i.e. MyVar = "somestring" becomes variant(vbString) ).
This leaves open an interesting question about how those types may or may not change though. What should happen here:
DefVarType = vblonglong
Dim MyVar as variant
MyVar = 2

...Is MyVar a byte? Integer? Long? LongLong? or a single, Double, or Decimal?
All are logical possibilities, but I'd posit that Existing "Evil Type Coercion" rules should be adjusted in favor of the rule: If the assigned value to an uninitialized variant subject to a DefVarType statement keeps its DefVarType Subtype - IF the assigned value fits the type.
Meaning that MyVar in the above hypothetical example is a Variant(vbLongLong) with a value of 2.
...or should DefVarType be applied as a method attribute? That might make more sense than a module-wide or program-wide statement would.

Oh yes we can definitely agree on Def[Type] being bad.
But that's not valid Def__ syntax at all... there's DefVar but it's followed by a letter, not a type. MyVar is a Variant, because you've explicitly defined it, and follows the normal rules for whether it's VT_UI1, VT_I2, or VT_I4.

fafalone,
Don't confuse/conflate DefVar with my proposal for a DefVarTYPE. (Perhaps "DefVarSubType" would be clearer?)

Oh ok I see. Yes it could be useful to assign a default type... but I'd suggest we'd also then need syntax to change the type, and then there'd have to be a whole set of rules for when you assign something that doesn't fit. Seems to be getting into the weeds of the underlying VARIANT type in a way that goes against what you were saying about clarity and accessibility to beginners. I'm always up for more direct access to the lower levels though, easier than calling CopyMemory to overwrite the first two bytes storing the type.

I think it would promote clarity in that the DefVarType vbLongLong would allow removal of the mystery of how much memory is reserved for them (especially in terms of API calls to functions which will populate the variant on exit) - so going into the API calla the variant may be unitialized, but the memory for it was "predeclared" and not a surprise in any way - may help with  some "As Any" parameters too.

Wekkm with the cType() functions (cInt(), clng(), etc.) We kind of have that control already, don't we? ...even if it's mostly implicit in terms of changing the variant subtypes. Or am I not grokking the effect of Evil Type Coercion as fully as I need to here?

The memory reserved for a Variant is always the same, 16 bytes for 32bit, 24 bytes for 64bit.

It may be that VBA provides a way out of the return in sub conundrum.
In some senses VBA is quite advanced in that it allows the name of a function to be used as a variable in the body of the function.  i.e. It allows an implicit result variable
Consider the  legal VBA below
Public Function Foo(ByRef Bar1 As Long, Bar2 As Long) As String

    Dim myDefault As String
    myDefault = "abcdefghijklmnopqrst"

    If Bar1 < 1 Then

        Foo = myDefault
        exit for

    Else

        Foo = VBA.Mid(myDefault, Bar1, Bar2)

    End If

    If Mid$(Foo, 3, 1) = "d" Then

        Foo = VBA.UCase(Foo)

    End If

End Function

This code shows Foo being used as a function and as a variable.
Foo is the implicit return variable which has the same name as the Function name and which is the value returned at the end of the function or when an exit for is encountered.
The cognitive dissonance of this feature is quite high.
If however, @wayne could engineer an alias for Foo as a variable, e.g. result, then the above code could be written in a much clearer form.
Public Function Foo(ByRef Bar1 As Long, Bar2 As Long) As String

    Dim myDefault As String
    myDefault = "abcdefghijklmnopqrst"

    If Bar1 < 1 Then

        result = myDefault
        Exit Function
    Else

        result = VBA.Mid(myDefault, Bar1, Bar2)

    End If

    If Mid$(result, 3, 1) = "d" Then

        result = VBA.UCase(Foo)

    End If
    ' result is the value returned by foo
End Function

The introduction of the result alias would not replace 'Foo =', but provide an alternative expression of the intent so that both versions of the code above would be allowed.
To assist the use of 'result' the twinBasic ide should be enhanced to follow the lead of the VBA ide, such that changing a function to a property or sub should automatically rename the end statement and also any exit statements (but this is a good idea anyway which should be implemented independent of the above discussion).
This change would neatly eliminate the issue about the conflicting use of return, does not impact current code, and allows clearer expression of intent for future code.
I think the discission then evolves to how 'result' is implemented.  Is it an addition to the twinbasic syntax, is it a toggleable using a global attribute/local attribute.  My preference would be for a global attribute that can be overridden by a local attribute
Global attribute
[AllowResult]
Local Attribute
[Result = false]
or more interestingly
[Result as Foo]
for a method named foo
or even more interestingly
[Result as Foo = "HelloWorld"]
directs the compile to use the method name as the return value, using the default value of "Hello World"
[Result as FooBar = "HelloWorld"
direct the compiler to use the variable Foobar as the return variable with the default value of "HelloWorld".  Foobar would be the return type specified by the function, and no declartion of FooBar would be required in the function itself.
e.g.

<a global or module level option/attribute that allows/disallows function name aliasing>

' at the function level
[Result as FooBar = "HelloWorld"]
Public Function Foo(ByRef Bar1 As Long, Bar2 As Long) As String

    Dim myDefault As String
    myDefault = "abcdefghijklmnopqrst"

    If Bar1 < 1 Then

        Foobar = myDefault
        Exit Function
    Else

        FooBar = VBA.Mid(myDefault, Bar1, Bar2)

    End If

    If Mid$(result, 3, 1) = "d" Then

        FooBar = VBA.UCase(Foo)

    End If
    ' FooBar is the value returned by foo
End Function

I just realised, using the features discussed above, the return syntax would also be allowable as a keyword for any type of method, because for properties and functions, the value to return on encountering a the return keyword is specified elsewhere.

I just realised, using the features discussed above, the return syntax would also be allowable as a keyword for any type of method, because for properties and functions, the value to return on encountering a the return keyword is specified elsewhere.

@FullValueRider I'm confused, your examples don't include the Return keyword? How does that fit in?

Do we really need a 3rd way to return a value from a function? What benefits does taking over "result" (a breaking-change for thousands of codebases using this common variable name) offer over Return and foo=?

Instead of result = ... it could be Return = ... not to introduce a separate keyword.

Why do we need to add the =?
and what would go after the = in a Sub?
Return  is already disambiguated; there's no legal syntax in VBx where anything comes after Return. It already works fine in functions. (Forgive me is the is baseless, but is it not universally known here that Return whatever is already legal tB syntax in functions? I doubt that's changing.

Using an implicit variable has some advantages. The main one not mentioned above is that you can read it's value i.e. in Foo a statement like Call SomeOtherProc(Foo, 42) is valid.

@wqweto Sorry it was an afterthought.  The return would just replace any Exit .... statement as an alternative to the exit .... for those who prefer the different syntax.

But it wouldn't be a result in Subs, and nobody is talking about removing Function Foo(): Foo = x
        foo = 2
        Debug.Print bar(foo, 2)
    End Function
    Function bar(x As Long, y As Long) As Long
        Return x + y
    End Function

This is already legal and prints the expected 4.

@fafalone Its not a third way.  There would be no need for 'return Value' syntax so that new usgage in twinBasic could be retired before V1, a perfectly legitimate change.  The proposals I made were to try and resolve the issue around the use of return in a Sub.
The = is needed as I envisage result (or whatever name is used) being an alias for the Method name variable.

Oh, my.
This thread is sprawling far beyond what should be the original scope. Some of the points sounds like they are a separate proposal, and probably should be dealt in their own issue, and other points seems to be taking a different approach altogether.
Let's recap:
VBx currently:

Require that the return value be assigned to the implicit variable of the same name of the function it is defined.
The assignment does not immediately leave the routine. A separate Exit Function or Exit Sub would have to follow if one wants to leave the routine.
If there is a cleanup subroutine that must be performed, one has to be careful to use GoTo <cleanup label> instead of Exit <procedure>.
Return is a legal keyword, and the following code is legal and will compile but fail with a runtime error 3 which gets swallowed up by the error handler.

Private Sub Derp()
  On Error GoTo Duh

  Return

  Exit Sub

Duh:
  Debug.Print "Ha-ha!"
End Sub

While I seriously doubt there's anyone trapping for run-time error 3 Return without GoSub, I hope that shows how we might have a VB codebase that seems to work because it's swallowing the run-time error 3 and nobody has noticed.
tB currently:

Support the vB syntax for backward compatibility
In addition, provides a Return <value> for a function which both assigns a value and leaves the function immediately.
Does not allow Return (without a value) in a Sub for the backward compatibility with GoSub...Return syntax which is also legal.

Other languages tend to follow the same convention where:

Return usually leave the method immediately.  For "sub" (aka void method), return without value is used to leave the method.
...unless it is inside a try...finally block. In this case, the finally block is executed, thus guaranteeing that the code within the finally always execute regardless whether a value was returned or an exception was thrown.

tB currently doesn't have a try...catch...finally idiom but it will be provided via vbWatchDog once it is made available in tB. This is why error handling is relevant to the discussion because Return should not bypass the finally block and make it easier for programmer to avoid accidentally circumventing this by using Exit <procedure> instead of GoTo <label>. Changing the behavior of Exit <procedure> to always execute the finally block is potentially more problematic and may break backward compatibility in subtle ways even if we used a new keyword for the finally block. Using Return with the expectation that it will always execute the finally block is a preferable and safer way of enhancing the language in both how it handles the return value and error handling.
The ideal and simplest outcome would be to just allow Return as a legal syntax for use in Sub. This might be accomplished by either 1) disallowing GoSub...Return or 2) no longer raising runtime error 3 but instead exiting the procedure, which is a change in the behavior (e.g. the sample code shown above will no longer print Ha-ha!; if there's an OERN it might be even more drastic). I personally would rather prefer this.
The other idea of Return Default (or a variant thereof) was meant to be an alternative just in case simple Return is not practical for some reasons that I might be unaware of.
Using Exit Sub instead of Return means there's two different ways of doing the same and runs into the problem of cleanup as I described above. By having a Return or variant thereof in Sub, we can then expect the same behavior with try...finally when dealing with Return.

Now I figured out something which was not apparent immediately. With Return Default syntax in a sub the compiler can disambiguate from original Return statement while having Return Default working in a function is just a non-asked byproduct.

Hmm, that entails that for consistency, the .bas/.cls files wouldn't have other tB features (c.f. #13 ). I don't think that's the case currently. I'm not sure how I feel about the idea of having the file extension enabling/disabling the file extension.

Have we considered using Exit instead of Return
Sub Foo()
    Exit
    Debug.Print "not called"
End Sub

Function Bar() As String
    Exit "return value"
    Debug.Print "not called"
End Sub

Or some combination with With, As e.g.:
Function Bar() As String
    Exit With "return value"
    Debug.Print "not called"
End Sub

I'm not sure how I feel about the idea of having the file extension enabling/disabling the language features.

Agreed but it's also my suggestion for implicit namespaces; public code in .bas files goes into the global namespace but modules in .twin files are contained in a namespace for that file to add better encapsulation

Changing the behavior of Exit <procedure> to always execute the finally block is potentially more problematic and may break backward compatibility in subtle ways even if we used a new keyword for the finally block

I disagree. If we use vbWatchdog as-is then yes. If instead a new Try... Finally...End Try block is introduced then no VBx code will already be written in that scope, since it would be a syntax error, so we can define Exit <procedure> to call finally without breaking any backwards compatibility

Have we considered using Exit instead of Return

This would seem to avoid the compatibility issues though TBH I'm ambivalent about overloading the word Exit to mean to return a value which would make the language even more odd compared to other languages that uses the return keyword.
Also, from my POV, I find it mildly annoying that if you had a situation where you had to alter the procedure from Sub to Function (or vice versa), the End <procedure> was automatically updated but not the Exit <procedure>. @fafalone  has pointed out that it could be something that IDE could make it easier to do. Then there's the fact that we have multiple ways of doing same thing (e.g. Exit Sub or Exit for subs, Return <value> for functions) which seems to me unnecessary distinction. I find it easier when I can use Return everywhere without going "oh, that's a sub, I should be using Exit" and backspace then re-type.
If we were to implement Exit <value> or Exit With <value> with corresponding Exit for subs, I can see how that might lead to subtle logic errors entering Exit Function when it should have been Exit With <value> or vice versa, which means more bugs and therefore a frustrating language to use. I think we want to avoid that, too.

I disagree. If we use vbWatchdog as-is then yes. If instead a new Try... Finally...End Try block is introduced then no VBx code will already be written in that scope, since it would be a syntax error, so we can define Exit <procedure> to call finally without breaking any backwards compatibility I believe.

Just to point this out, we have an open issue on Try/Finally as a keyword ( #61 ) which also hits on the issues we already have to deal with the different keywords & strategies for leaving a routine and error handling which as I explained over there is ironically errorprone.
Anyway, to your point; I need to ask - is it a good idea to alter the behavior of the Exit <procedure> so that it always calls the Finally block? Personally, I think yes and for everybody's sanity, it ought to but the backward compatibility may be harmed by this subtle change in the behavior. Using Return at least makes this an explicit opt-in and we can then have IDE encourage the use of Return over Exit <procedure> as a hint to help promote good coding practices, rather than forcing them to choose a legacy mode because they can't be sure that it will work as-is when they import their original VBx codebase.

I'd be against modifying Exit <method> to jump to what's basically a label. Keywords that have different meanings in different contexts are a nightmare for language clarity, and are beginner-hostile substantial increases in learning curve. It's been a while since I used a language with this syntax, but isn't the traditional solution for this Exit Try? That's both far more clear, consistent with all the existing VB Exit syntax like Exit For or Exit Do, and has no impact on backwards compatibility at all as it's not legal syntax in VBx.

I think we're talking about different things.
Consider this hypothetical pseudo-code:
Private Sub Fizz()
  Try
    OpenHandle
    Exit Sub
  Finally
    CloseHandle
  End Try
End Sub

The question is if there's a Exit Sub inside the Try block, should it execute the Finally block? In my opinion, yes it should. Otherwise, we destroy the value of the try...catch...finally block. However, I'm uncertain if there's a problem with breaking the backward compatibility if we change that behavior. Furthermore, what I dislike is that the behavior changes for the Exit <procedure> just because it's inside a try...finally block versus being not inside one. Being able to use Return and thus having a consistent behavior (e.g. being assured that Finally block will always execute even if we leave the routine early) and having IDE highlight a good coding practice seems preferable than overloading the Exit keyword and giving it new meaning that might be not as apparent.

We're not talking about different things, I'm aware you meant if it was inside the Try block.
That's what I meant-- you're changing the meaning of Exit <method> based on where it is, which brings all the downsides I mentioned. If you want to get out of the Try block while executing Finally, you should need to use Exit Try or perhaps a new keyword after Exit could be added, like Exit Sub With Finally only more concise.
I'd say that yes, it's breaking backwards compatibility, because you're changing the meaning of existing code simply by virtue of someone wanting to add a Try block. I don't understand your statement that to not exit the procedure immediately is altering the behavior... there's no scenario in VBx where Exit <procedure> does anything other than exit the procedure immediately, but here you're proposing that it should.
This doesn't destroy the value of the Try block at all, because nothing stops someone from not using Exit <procedure> and instead using the proper Exit Try. I'd think if someone is going out of their way to add a Try block, they'd want Finally to execute so wouldn't use syntax that bypassed it. Being allowed to use syntax that bypasses it doesn't destroy the value.

My point is that when inside a Try block, it should not be possible to leave the block without executing the Finally block where present. With Exit <procedure> as-is, that would bypass the Finally execution, which makes it superficial and put us back to square one WRT having to remember to use right syntax in right place which I think is not user-friendly as I explained in the linked issue #61 .  Requiring using Return and disallowing the use of Exit <procedure> inside the Try block would at least avoid that problem without changing the behavior of the Exit <procedure> or alternatively do an Exit Try, then Exit <procedure> outside the block.
Note that the same problem would exist with GoTo <label> which allows us to leave any other blocks which feels totally wrong to me. The 90% of the value with the Try block is being guaranteed that the Finally will run, errors or no errors. Otherwise, it's just a keyword posing as a label.

I really can't see how having to figure out that Exit <procedure> takes on an entirely new meaning if you use it inside a Try block makes the syntax less difficult to understand. IMHO it's just not user-friendly to have context-dependent alternative meanings for "Exit" like "If Exit is within Try, Exit doesn't mean exit, Exit means GoTo Finally, Then Exit".
I think the value in Try is in allowing the user to have Finally always run, error or no error. I don't think the value of forcing them into it by breaking backwards compatibility and creating context-dependent alternative behavior for long-standing, well known core language syntax outweighs the substantial drawbacks of that.
Mind you I would, as mentioned above, support a different Exit syntax that would execute Finally before exiting-- that's the best of all worlds. Allows opting into the benefits without breaking things to force it.

I can't see the point in arguing about try/catch in the context of a return syntax.  In VBA, vbWatchdog was constrained by the need to work within existing VBA code.  With twinBasic,  try/catch/finally syntax can be added as new twinBasic syntax. The only constraints on such an addition being any potental conflicts between code implementing vbWatchdog try/catch and any new try catch syntax.

@bclothier

Anyway, to your point; I need to ask - is it a good idea to alter the behavior of the Exit  so that it always calls the Finally block? Personally, I think yes and for everybody's sanity, it ought to but the backward compatibility may be harmed by this subtle change in the behavior.

@fafalone

[Using Exit in a try block would be] breaking backwards compatibility and creating context-dependent alternative behavior for long-standing, well known core language syntax outweighs the substantial drawbacks of that.

I'm confused by the idea of calling this "altering the behavior" of Exit  or risking backwards compatability. Right now "Exit Sub" or "Exit Function" to me means not just jump out, there is also clean-up of COM objects calling Class_Terminate and probably clearing memory of variables.
The behaviour of "Exit " is not defined inside a try-catch-finally block because it doesn't exist in VBA yet, so we can't be "changing" the behaviour and breaking backwards compatibility, the behaviour is yet to be defined. And having "Exit " mean "Exit and perform any cleanup, either memory, Class_Terminate or Finally blocks" is very unsurprising and the precedent from all other languages with early return syntax and finally blocks.
There is no backwards compatibility to break because this:
Function Foo()
     Try
         Exit Function
     Finally
          ' Clean up before exit
     End Try
Exit Function

Is not valid code yet. So there is no backwards compatibility to consider. There is "expected behaviour" and language features that make sense in the context of VBA to consider, but you're not going to break any existing code by defining a finally block to run on an early Return or Exit, because no code exists yet to break. Or am I missing something?
@bclothier is right in that the value of a finally block is that it always runs regardless of what happens inside the try block. To free resources or close context managers.

@Greedquest

And having "Exit " mean "Exit and perform any clean-up, either memory, Class_Terminate or Finally blocks" is very unsurprising and the precedent from all other languages with early return syntax and finally blocks.

FWIW I had the same instinct, everyone has expectations for Finally from other languages. Would be non-controversial (IMO) to do the same, and potentially confusing or error-prone not to.

Apologies if I'm missing something here or misinterpreting. I'm confused by the idea of calling this "altering the behavior" of Exit or it posing a risk to backwards compatibility. Right now "Exit Sub" or "Exit Function" to me means not just jump out, there is also clean-up of COM objects calling Class_Terminate and probably clearing memory of variables.

Those are handled by the compiler whereas the Finally points to user-defined code. In VBx code, you'd have to use GoTo <label> or Resume ` to perform user-defined code.
The point is that if Exit <procedure> is allowed inside a Try block, the behavior will be different - it must be in order for Finally to be guaranteed to be executed. This is a change in the expectation because in VBx code, one could (ab)use Exit <procedure> to leave a routine without even calling the cleanup routine. Personally, I think that's not good coding but it is legal code and I've seen people (ab)use that feature as to avoid doing additional work in the cleanup. Example:
Public Sub Foo()
  On Error GoTo ErrHandler

  If Bar() Then Exit Sub

  'Do Foo

  If Foo_d Then
   GoTo ExitProc
  End If

  'Foo some more

ExitProc:
  'Unfoo
  Exit Sub
ErrHandler:
  Debug.Print "Bonk!"
  Resume ExitProc
End Sub

Now suppose we then update the procedure and put in a Try:
Public Sub Foo()
  Try
    If Bar() Then Exit Sub

    'Do Foo

    If Foo_d Then
     GoTo ExitProc
    End If

    'Foo some more
  Catch
    Debug.Print "Bonk!"
  Finally
    'Unfoo
    Exit Sub
  End Try
ExitProc:
End Sub

What's the behavior of Exit Sub and GoTo ExitProc?
You are correct that right now, the behavior of Exit <procedure> inside a Try block is undefined but the concern is keeping thing consistent so that users are not confused or surprised by the changes in the behavior. That's going to be important when they start updating their existing VB6 codebase in the ways I illustrated above.
In this view, I think I'm arguing that Exit <procedure> and GoTo <label> (possibly all GoTo and GoSub) probably should be disallowed and be a compiler error inside the Try block. As I said earlier, we can have IDE hint at using Return and Try block as the preferred syntax to help promote good coding practices. This also argues against the idea of using just Exit or Exit With because it'll have the problem of being too similar to the Exit <procedure> but not quite that it's off-putting. It might be me but I gave up on VB.NET exactly for that reason -- there were too many "this is just like VBA! No, wait.... it's not." mindtraps that it was difficult to be productive in VB.NET. I'd rather that tB avoid that kind of mindtrap.

note I'm ignoring vbWatchdog which I believe uses labels rather than keywords to mark the regions of code for a finally block, although I haven't used it myself. I'm assuming keywords will exist

Just FYI. In VBx's vbWatchDog, the Exit Sub will not call the finally block. If one wants the Finally to always run, one has to use ErrEx.DoFinally instead of Exit <procedure>:
Private Sub CallIt()
    DoIt
End Sub

Private Sub DoIt()
    Exit Sub
ErrEx.Finally
    Debug.Print "Finally!" 'not printed
End Sub

I should note that I've made boneheaded mistakes like this:
Private Sub Derp()
  Debug.Print "Derping"
ErrEx.DoFinally 'Oops! Should be ErrEx.Finally!
  Debug.Print "Derped" 'not printed
End Sub

People only have to convert their VBx code to tB once, but then they have to maintain it forever after. It seems better to me to err on the side of having a well behaved language feature vs. making the transition to tB a little easier. Otherwise the programmer will pay for that many times over instead of just once when they update to tB.
Personally I would expect that the Goto would not circumvent the Finally. Either that, or Goto within a Try to a label outside the Try should just be disallowed; but that seems less useful.

@bclothier thought experiment... If hypothetically there were an IDE refactoring that would transform from your first example to the second... that could indeed cause some surprises. Perhaps having the refactoring add a warning and/or comment about how it affects goto / exit would be a good idea in that case. The VS2010 VB migration assistant would very liberally add warnings like that. (E.g., for array bounds change from 1- to 0- based).

This was supposed to be an example of refactoring by hand. If IDE were to provide a refactor, it'd be probably smarter than that and substitute in Return or Return <value> and removing all GoTo or Exit <procedure> as well as any labels so that there is no ambiguity over how the code leaves the procedure and is guaranteed to always leave the procedure in a consistent and well-defined manner. I just don't think it's good idea to mix the paradigms of gotos/exits with try/catch/finally.
The more recent languages avoid  this problem by simply never giving the equivalent of GoTo in its syntax so that issue is a moot point in those languages; it's impossible to jump out in an uncontrolled manner. Because tB has the commitment to backward compatibility, this is not a moot point.

Apologies if I'm missing something here or misinterpreting. I'm confused by the idea of calling this "altering the behavior" of Exit or it posing a risk to backwards compatibility. Right now "Exit Sub" or "Exit Function" to me means not just jump out, there is also clean-up of COM objects calling Class_Terminate and probably clearing memory of variables.

I don't think hidden non-user code is a reasonable comparison here. VB programmers don't think about, or consider, hidden codepoints, whereas we very much expect consistent behavior in user code flow.

The behaviour of "Exit " is not defined inside a try-catch-finally block because it doesn't exist in VBA yet, so we can't be "changing" the behaviour and breaking backwards compatibility, the behaviour is yet to be defined. And having Exit  mean "Exit and perform any clean-up; such as memory, Class_Terminate and/or Finally blocks" is very unsurprising and the precedent from all other languages with early return syntax and finally blocks.

This also seems entirely unreasonable. Code doesn't cease to the VB6 language just because you've put it inside another type of code flow control block. This is like saying we can throw all the rules of the language right out the window because of some unrelated label. It's absolutely breaking backwards compatibility to change the meaning of existing code, end of story. It doesn't matter that it's a Try block any more than an If block, VBx code needs to execute as defined by VBx code in order to be compatible. If you want to argue for breaking backwards compatibility, ok, but let's not pretend this isn't what we're talking about.

@bclothier is right in that the value of a finally block is that it always runs regardless of what happens inside the try block. To free resources or close context managers.

And I for one certainly look forward to taking advantage of that value. I don't care to have it forced upon me by breaking the rules for existing syntax. I'll personally, in forseeable cases, not be using Exit <procedure> inside my Try blocks, because I do want Finally to run. But if, for some reason, I did want to break out without running Finally, I would not want to be in a situation where the language has forbidden that by altering the behavior of existing syntax.
If we are going to handcuff users, I much prefer Ben's alternative of disallowing Exit <procedure> inside a Try block.

People only have to convert their VBx code to tB once, but then they have to maintain it forever after. It seems better to me to err on the side of having a well behaved language feature vs. making the transition to tB a little easier. Otherwise the programmer will pay for that many times over instead of just once when they update to tB.

This was .NET's philosophy; I'm using VBx and tB because I prefer that language, despite it's shortcomings, over "better" languages, for the uses where it's practical (and even somewhat impractical, if it's possible).

... It's absolutely breaking backwards compatibility to change the meaning of existing code, end of story.

That seems to be 100% accurate - the essential definition of what "backwards compatibility" probably means to most people.
But once you alter your code deliberately, why would it be expected to behave the same way? Alteration could be updating it to use a tB language feature that did not exist in VBx, or anything else. I don't think this is the sense in which "backwards compatibility" really applies.

But once you alter your code deliberately, why would it be expected to behave the same way?

Keep in mind that typically in a migration project, it's seldom all at once. More likely, they'll want to keep everything as-is and update only this and that and gradually update stuff as they go, which helps amortize the development costs. That's the biggest win with the backward compatibility promise of tB that other languages can't even begin to fulfill.

Can't we just generalise Exit, so that it doesn't need to be told what it's exiting? Presumably for functions and property-gets, it just returns the default?
How about Exit Procedure, which is equivalent to Exit [Sub|Function|Property], without having to be explicit?

Don't think Exit is quite basic-y when you consider the block structures:
Public Sub Foo()
  Dim i As Long
  If True Then
    For i = 0 To 0
      Exit For
    Next
    Do
      Exit Do
    Loop
  Else
    Exit If 'Not a real keyword, included for illustration
  End If
  Exit Sub
End Sub

Compare with a C-family pseudocode:
void foo() {
  if(true) {
    for(var i = 0; i < 1; i++) {
      break;
    }
    while(true) {
      break;
    }
  } else {
    break;
  }
}

The appeal of BASIC is that you can at least identify what type of blocks you're closing. A generalized Exit & End would start to resemble more like a verbose form of C-family language and probably even more confusing:
Public Sub Foo()
  Dim i As Long
  If True Then
    For i = 0 To 0
      Exit
    Next
    Do
      Exit
    Loop
  Else
    Exit
  End
  Exit
End

So yeah, I don't think a generalized form will work very well.
Exit Procedure would be a possible alternative.
I find it interesting that you cannot break nor continue out of a non-loop structure. You can only return in this case case. tB does have Break and Continue (yay!), but not sure I'd want to overload it in this way.

Sorry, my first paragraph was disconnected from the first. I guess I initially envisaged a general Exit, but then saw the problems you detailed.
At this point, I'm only proposing Exit Procedure, which would be equivalent to Exit Sub, Exit Function, or Exit Property, depending on context.

Wait...
How about, in a Sub, you can Return Nothing? If you change a Function to a Sub, you'd have to change the return, but maybe that's a good thing? In that you have to think what that change means? C# does that...

FWIW, I think it comes close to Return Default proposed earlier in this thread. The thing with Nothing is that it's for an object which isn't always appropriate. Return Empty might be closer.


don't use cloth config

shedaniel doesn't want it being used
maybe use MidnightConfig not available on forge

since midnightLib is not available on forge, it is not an option


New IO kernels: Matrix Market, Parquet and DAPHNE Binary

In GitLab by @niclashedam on Mar 30, 2022, 13:34

Hey @pdamme. Do you have time to review our new IO kernels at some point?

Patrick is one vacation, but I try to have a look end of this week.

@mboehm7 Thanks, but you don't need to, I had already looked over it two weeks ago, just didn't find the time to summarize it.
@niclashedam @mortentc @phbonnet Thanks a lot for this contribution! It's an impressive amount of work and definitely brings us forward. I mainly paid attention to the integration into the code base rather than to the details of the readers/writers. In general, it looks very good to me. I've applied some minor adjustments myself (see 905a71a8df54bc459c4d87ee9e9cdd9e289bd4bf). However, I need your help/feedback on three points before we can merge it in:

Before my adjustments, the code didn't compile without Arrow. I quick-fixed that by inserting #ifdefs around the Arrow/Parquet case in Read.h. That works and I hope you're fine with that.

I've also tried to build/test with Arrow (by using the -DUSE_ARROW=ON you left as a comment in build.sh). Unfortunately, I get the following error:
CMake Error at CMakeLists.txt:105 (find_package):
  Could not find a package configuration file provided by "Parquet" with any
  of the following names:

    ParquetConfig.cmake
    parquet-config.cmake

  Add the installation prefix of "Parquet" to CMAKE_PREFIX_PATH or set
  "Parquet_DIR" to a directory containing one of the above files.  If
 "Parquet" provides a separate development package or SDK, be sure it has
  been installed.

I installed Arrow/Parquet following the instructions at https://arrow.apache.org/install/ (packages libarrow-dev, libarrow-glib-dev, libparquet-dev, libparquet-glib-dev). Is that the right way? It would be great if you could add some hints in GettingStarted.md. Or, if the Arrow-support is still meant to be experimental, then it's also fine to fix that later, please just let me know.

In the test case WriteDaphneTest.cpp/"WriteDaphne AIG (Frame)" the call to writeDaphne() was commented out; similarly the whole test case ReadDaphneTest.cpp/"ReadDaphne AIG (Frame)" was commented out. I uncommented it and it works well (tests pass). Is there a particular reason why this was commented out? I.e., should it rather stay inactive?

Hint: Since I saw you removed the DaphneLib/Python API test cases (I've reinserted them): You need to install numpy (e.g., by sudo apt install python-numpy) to make them work.

Hi @pdamme. Thanks for your contribution in https://github.com/daphne-eu/daphne/commit/905a71a8df54bc459c4d87ee9e9cdd9e289bd4bf.
I can only comment on points 1 and 2. Arrow is a bit complex to get working. All Arrow/Parquet related stuff should have the USE_ARROW, so it feels completely OK to have it in Read.h as well.
I personally installed Arrow and Parquet from source because we need a few features like CSV as well. This should install all needed libraries. I can schedule some time to write the documentation for it next week. Maybe we can handle that as a separate PR to avoid blocking this?

Thanks for the response @niclashedam. As USE_ARROW=ON is currently commented out anyway, I'd say it's okay if the right way to install Arrow is not documented yet. Once you find some time, it would be great to add an argument for it, e.g., like ./build.sh --arrow, and to briefly explain how to provide Arrow as an optional dependency in GettingStarted.md.
I also assume that point 3 about the test case should be fine, so I merge it in now. Thanks again to everyone involved!
I'm looking forward to the next contributions from your team. Whenever it is possible to divide contributions by different people into separate branches/pull requests, I recommend doing so. This often makes it easier to review a PR and apply/request changes if needed, as well as to squash commits if suitable. But in this case I can imagine that it was easier for you to jointly develop this initial set of readers/writers.

Thanks. Welcome back. Hope you had a nice vacation.
About 3. This is my bad. No reason to take it out.
Best,
Philippe.

From: Patrick Damme @.>
Sent: Friday, April 22, 2022 3:35 PM
To: daphne-eu/daphne @.>
Cc: Philippe Bonnet @.>; Mention @.>
Subject: Re: [daphne-eu/daphne] New IO kernels: Matrix Market, Parquet and DAPHNE Binary (PR #331)
@mboehm7https://github.com/mboehm7 Thanks, but you don't need to, I had already looked over it two weeks ago, just didn't find the time to summarize it.
@niclashedamhttps://github.com/niclashedam @mortentchttps://github.com/mortentc @phbonnethttps://github.com/phbonnet Thanks a lot for this contribution! It's an impressive amount of work and definitely brings us forward. I mainly paid attention to the integration into the code base rather than to the details of the readers/writers. In general, it looks very good to me. I've applied some minor adjustments myself (see 905a71ahttps://github.com/daphne-eu/daphne/commit/905a71a8df54bc459c4d87ee9e9cdd9e289bd4bf). However, I need your help/feedback on three points before we can merge it in:

Before my adjustments, the code didn't compile without Arrow. I quick-fixed that by inserting #ifdefs around the Arrow/Parquet case in Read.h. That works and I hope you're fine with that.

I've also tried to build/test with Arrow (by using the -DUSE_ARROW=ON you left as a comment in build.sh). Unfortunately, I get the following error:

CMake Error at CMakeLists.txt:105 (find_package):
Could not find a package configuration file provided by "Parquet" with any
of the following names:
ParquetConfig.cmake
parquet-config.cmake

Add the installation prefix of "Parquet" to CMAKE_PREFIX_PATH or set
"Parquet_DIR" to a directory containing one of the above files.  If
"Parquet" provides a separate development package or SDK, be sure it has
been installed.
I installed Arrow/Parquet following the instructions at https://arrow.apache.org/install/ (packages libarrow-dev, libarrow-glib-dev, libparquet-dev, libparquet-glib-dev). Is that the right way? It would be great if you could add some hints in GettingStarted.md. Or, if the Arrow-support is still meant to be experimental, then it's also fine to fix that later, please just let me know.

In the test case WriteDaphneTest.cpp/"WriteDaphne AIG (Frame)" the call to writeDaphne() was commented out; similarly the whole test case ReadDaphneTest.cpp/"ReadDaphne AIG (Frame)" was commented out. I uncommented it and it works well (tests pass). Is there a particular reason why this was commented out? I.e., should it rather stay inactive?

Hint: Since I saw you removed the DaphneLib/Python API test cases (I've reinserted them): You need to install numpy (e.g., by sudo apt install python-numpy) to make them work.
—
Reply to this email directly, view it on GitHubhttps://github.com/daphne-eu/daphne/pull/331#issuecomment-1106523021, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA2CDLAYFV6F7OMJQD472RDVGKTJXANCNFSM5SGMNU2A.
You are receiving this because you were mentioned.Message ID: @.***>


[Cosmos] Example incorrect

The first example on this page is incorrect, please fix it.

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

ID: f5102137-887d-0c3e-fe52-ff5c78f16121
Version Independent ID: 02210ea2-4cd6-5ceb-7638-567d32a65a9e
Content: Scripts.GetStoredProcedureQueryIterator Method (Microsoft.Azure.Cosmos.Scripts) - Azure for .NET Developers
Content Source: xml/Microsoft.Azure.Cosmos.Scripts/Scripts.xml
Service: cosmos-db
GitHub Login: @CamSoper
Microsoft Alias: casoper

Thank you for your feedback.  Tagging and routing to the team best able to assist.  Please be aware that due to the holidays, responses may be delayed.

Thank you for your feedback.  Tagging and routing to the team best able to assist.  Please be aware that due to the holidays, responses may be delayed.

The correct repo for this issue is https://github.com/Azure/azure-cosmos-dotnet-v3


Delete istiod pods on cleanup

Otherwise they stay around and can cause other tests to fail.
In a concrete example, deployment "istiod-canary" stays live
and interferes in pilot's TestMultiRevision test, which also
deploys a "istiod-canary", but, since a deployment with that
name already exists, operator doesn't redeploy it, because it's
already there.

@jwendell: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
b87f9a6a32f4dedfe03b844bd5bbccec3ef5a2ab
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@jwendell: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
b87f9a6a32f4dedfe03b844bd5bbccec3ef5a2ab
link
/test release-notes_istio

gencheck_istio
b87f9a6a32f4dedfe03b844bd5bbccec3ef5a2ab
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@jwendell: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
b87f9a6a32f4dedfe03b844bd5bbccec3ef5a2ab
link
/test release-notes_istio

gencheck_istio
b87f9a6a32f4dedfe03b844bd5bbccec3ef5a2ab
link
/test gencheck_istio

integ-pilot-k8s-tests_istio
b87f9a6a32f4dedfe03b844bd5bbccec3ef5a2ab
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@jwendell: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
b87f9a6a32f4dedfe03b844bd5bbccec3ef5a2ab
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

/retest

In response to a cherrypick label: new pull request created: #28222


ssh: tweak default controlPath

Instead of using the hostname %h, which can be changed by the
~/.ssh/config file, use the commandline-given hostname %c.
This allows to alias a host with different hostnames, which then point
to different configurations. A common use-case for this is if you have
multiple accounts on github with each access to different private repos:
Host github.com
  IdentitiesOnly yes
  User git
  IdentityFile ~/.ssh/id_rsa

Host customer.github.com
  IdentitiesOnly yes
  User git
  IdentityFile ~/.ssh/customer
  HostName github.com

Without this change, if a connection was established with the first
github.com alias, then the user would try to pull a repo from the second
account, ssh would re-use the SSH connection which doesn't have access
to that repository.

Thanks! Seems to work well for me. Rebased to master 40b279e3a33fd47b7e65e0303fcb9be621aeb7d3. Note, I changed the commit message to say %n instead of %c, which I assume was a typo.


Using Maybe instead of "UNKNOWN"?

I like this package a lot, but using "UNKNOWN" instead of Nothing means a user has to compare strings to handle this case specially. Would a variant returning Maybe be acceptable instead?

How do you think this should look, concretely? One of the big advantages to the string-based approach is the simplicity of the TH splices, but I'm happy to consider other ideas.

I was thinking of a primary API using Maybe String instead of String, where UNKNOWN is possible, and exposing wrappers that do the last step. For maximum compatibility, the wrappers could expose the same API as they do now. Here's one untested sketch for gitHash: this still provides gitHash with the same behavior but also provides gitHashMaybe that you can splice to get a Maybe String, either Just theActualHash or Nothing.
runGit :: [String] -> IndexUsed -> Q (Maybe String)
runGit args useIdx = do
-- Adapted implementation omitted—change: use Nothing instead of `def`.

-- XXX Can't pick a good name
defaultStringE :: String -> Maybe String -> ExpQ
defaultStringE def mStr = stringE $ maybe def id mStr

-- | Reify a Maybe String.
--
-- XXX No TH expert, do I need to write this by hand?
maybeStringE :: Maybe String -> ExpQ
maybeStringE Nothing = [| Nothing |]
maybeStringE (Just t) = [| Just $(stringE t) |]

gitHashBase :: Q (Maybe String)
gitHashBase =
  runGit ["rev-parse", "HEAD"] IdxNotUsed

gitHashMaybe :: ExpQ -- Containing a Maybe String
gitHashMaybe =
  maybeStringE =<< gitHashBase

gitHash :: ExpQ -- Containing a String
gitHash =
  defaultStringE "UNKNOWN" =<< gitHashBase

This would apply where UNKNOWN can be returned, that is, as of https://github.com/acfoltzer/gitrev/blob/450a7abf444260e95791649489705e54650c0232/src/Development/GitRev.hs, in gitHash, gitBranch, gitDescribe, gitCommitCount and gitCommitDate.
I'm not happy about the extra boilerplate for each command but I'm not sure it can be much better (yes, I can abstract a bit more away, not sure it's worth it or it's much better). Probably OK?

+1. I think having both options would be good, for a user who just wants a string (even if it's "UNKNOWN") and for a user that actually wants to check. It can be something like
runGit :: [String] -> IndexUsed -> Q (Maybe String)

runGit' :: [String] -> IndexUsed -> ExpQ
runGit' args = lift . runGit args

fromMaybeE :: String -> ExpQ -> ExpQ
fromMaybeE def (ConE ''Nothing) = stringE def
fromMaybeE _ (AppE _ s) = s

gitHash' :: ExpQ -- Maybe String
gitHash' = runGit' ["rev-parse", "HEAD"] IdxNotUsed

gitHash :: ExpQ -- String
gitHash = fromMaybeE "UNKNOWN" gitHash'


LSNBLDR-952; cleanup low-level code; use canSeeAll rather than site.upd to see all pages

Minor improvements to Dao.

This is in some sense incomplete. isInstructor is passed through from Portal, but I no longer use it. I've run out of time for testing though. I may come back to it later.

@clhedrick please do not merge before CI jobs run and before someone in the community can review your code.


images: update versions

We had horribly outdated builtin references, for no real reason different than lack of bandwidth. fix them for good.
Closes: #127
Signed-off-by: Francesco Romani<EMAIL_ADDRESS>

Superceded by #135


Method injection CommandHandler

Hey Jeffrey!
I am trying to do method injection in a CommandHandler class like so:
public function handle($command, \UserRepository $userRepository)
Still, I'm getting the following error:
Declaration of Site\Registration\RegisterUserCommandHandler::handle() must be compatible with Laracasts\Commander\CommandHandler::handle($command)
Is it even possible to do method injection here?

I think method injection would be cool if we have a way to "SelfHandling" the commands, like L5.
So, a handle method in the Command class will make sense to have dependency injection.


Make HTTP Listen Address configurable

What was wrong?
As explained in #1795, Trinity does currently not allow accessing its JSON RPC HTTP API from an external address. This should be configureable.
How was it fixed?

Exposed the listen address as --http-listen-address but kept the default at <IP_ADDRESS>

Fixed some casing inconsistencies in the help texts (Server > server)

Renamed --rpcport to --http-port to be more aligned and precise (RPC doesn't necessarily refer to the HTTP API as it is an umbrella term that includes RPC access via HTTP, IPC and potentially WS in the future)

To-Do

[x] Clean up commit history

[x] Add entry to the release notes

Cute Animal Picture

@hwwhww pinged you for a review since you've last worked on this and I'm also renaming a flag that you might be using.

@cburgdorf  Hi!
Other files that are using --rpcport flags need to be updated too:

https://github.com/ethereum/trinity/blob/48188a06d9b9df79eae6dd17b559f77c08e5e600/docs/api/api.cli.rst
https://github.com/ethereum/trinity/blob/84381f4fe19b18dddf2d2b210bd0780038728acd/eth2/beacon/scripts/run_beacon_nodes.py#L133

@hwwhww Ooops, sloppy me! Thanks for pointing me to these places. Should be fixed!


[Design] React to aspnet/Razor#705

Updated ScriptTagHelper and LinkTagHelper to maintain their quotes on generated script tags.
Removed TagHelperOutputExtensions. It's no longer needed.
We no longer string replace quotes directly. We rely on encoding and the initial representation of an attribute to ensure quotes don't break generated attributes.
Updated tests.

/cc @dougbu @pranavkm @ajaybhargavb

:watch:

:up: :date:

:up: :date: for rename of HtmlAttributeValueStyle.

:watch:

:up: :date: no longer in design.

:shipit: once aspnet/Razor#705 is in.


api - add OperationID

helps when using pyswagger and is visible via
http://localhost:8123/swagger/index.html?displayOperationId=true
gin-swagger can not set displayOperationId yet
addresses #52
for pyswagger the difference is such as

	op = app.resolve(jp_compose(['#', 'paths', '/provisioning/peers', 'post']))
# vs
	op = app.op['PostPeerDeploymentConfig']

Changes included in #58


[Doc]add pause routine load

Signed-off-by: hellolilyliuyi<EMAIL_ADDRESS>What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[x] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto backported to target branch

[x] 2.5
[x] 2.4
[x] 2.3
[x] 2.2

run starrocks_admit_test

@mergify backport branch-2.5

@mergify backport branch-2.4

@mergify backport branch-2.3

@mergify backport branch-2.2


docs: update cli args for logging

Modern logging has no location control

Not possible yet. We will add it post 1.0.


Remove sentence about old dependencies

The commands take care of downloading the only current dependency, chef-ingredient

Thanks for the update @gregkare


Ori/starknet/concurrency/add deployed contract to validate read set

This change is

Codecov Report
Attention: Patch coverage is 94.44444% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 75.74%. Comparing base (9b27b71) to head (9d9326c).
Report is 12 commits behind head on main.

Files
Patch %
Lines

crates/blockifier/src/state/cached_state.rs
94.44%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1804      +/-   ##
==========================================
+ Coverage   75.71%   75.74%   +0.03%
==========================================
  Files          61       61
  Lines        8675     8692      +17
  Branches     8675     8692      +17
==========================================
+ Hits         6568     6584      +16
- Misses       1675     1676       +1
  Partials      432      432

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


publish<EMAIL_ADDRESS>

Requested by: @andreiborza
Merge target: main
Using Craft config from: merge_target
Quick links:

View changes
View check runs

Assign the accepted label to this issue to approve the release.
Leave a comment containing #retract under this issue to retract the release (original issuer only).
Targets

[ ] npm
[ ] github

Targets marked with a checkbox have already been executed.  Administrators can manually tick a checkbox to force craft to skip it.

#retract


Recipes pages are unsuable on small screens

The recipes pages don't fit on smaller screens.  The most obvious solution would be to enable flex wrapping and set a minimum width for the article.  I'm sure someone with a better eye for design can think of something better.

Yep! Currently the whole website is not particularly mobile friendly. It needs to be designed before we can build it!

#42 improves on  the layout by moving the reicpe-list on top for smaller screens.
This is still not  ideal though, as it introduces a large scroll requirement.
Further improvement could be to have them as a dropdown on small devices.

I think the latest merge might have been a bit to aggressive on the media query width


[BUG] Mobile Menu does not retract upon route change

Describe the bug
After selecting an item on the mobile menu, it does not retract as expected.
To Reproduce
Steps to reproduce the behavior:

Open the site on a mobile device/mobile developer view
Click the hamburger menu
Click on a route
The menu is still there, in the way and the user has to manually close it

Expected behavior
After the user selects a route, the menu should neatly retract itself :))
Screenshots or Links
N/A
Environment

OS: Android 11
Browser: Chrome
Browser Version: 88.0.4324.93

Additional context
N/A

Oops closed wrong thing


update stub to reflect current MongoDB\Driver\Manager

See http://php.net/manual/en/class.mongodb-driver-manager.php for up-to-date interface
See issue https://youtrack.jetbrains.com/issue/WI-45538

A question in general: how does the "stub" solution work for people that are still working with an older mongodb library?
Because now the interface of an already existing, and previously valid function will be changed. (executeBulkWrite())
The @since tag doesn't help here since it is an already existing function.

For now, signatures should accept both old and new API if it's possible, cause there is only one version of stubs. I've added some suggestions on how to preserve backward compatibility in this case

@andrey-sokolov Thanks! I've followed up on your comment.
The PR is up for review again.


addTogether - error

When I run Test, an error is generated, "TypeError; addTogether(...) is not a funciton"
Challenge Arguments Optional has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:

function addTogether() {
 return false;
}

addTogether(2)(3);

@Mason-Rojik the error message is telling you what is wrong (albeit a little nuanced). It is saying that addTogether(...) is not a function. This is because you called addTogether(2)(3), where the JavaScript interpreter is assuming that addTogether(2) is your function being called on 3 (i.e. addTogether(...)(3)), which doesn't exist.
If you get stuck with a challenge or have initial questions, please ask questions to the Help Room first. Happy coding!

Could you expand? You explanation is not making sense to me. And yes, I have been to gitter, it’s a real hit and miss if someone answers a question, so then I have to submit a bug because I just don’t know if it is or not.
Thanks again.
From: Eric Leung<EMAIL_ADDRESS>Sent: Monday, May 16, 2016 3:01 PM
To: FreeCodeCamp/FreeCodeCamp<EMAIL_ADDRESS>Cc: Mason Rojik<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [FreeCodeCamp/FreeCodeCamp] addTogether - error (#8664)
@Mason-Rojik https://github.com/Mason-Rojik  the error message is telling you what is wrong (albeit a little nuanced). It is saying that addTogether(...) is not a function. This is because you called addTogether(2)(3), where the JavaScript interpreter is assuming that addTogether(2) is your function being called on 3 (i.e. addTogether(...)(3)), which doesn't exist.
If you get stuck with a challenge or have initial questions, please ask questions to the Help Room https://gitter.im/FreeCodeCamp/Help  first. Happy coding!
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/FreeCodeCamp/FreeCodeCamp/issues/8664#issuecomment-219513812 https://github.com/notifications/beacon/AQI02Il5hnCzgq70F3HyHjW6h3fR0usQks5qCL7YgaJpZM4Ifk0s.gif

@Mason-Rojik this link may help. What you have tried to do is called currying.
Yeah, Gitter can be overcrowded sometimes. You just have to be persistent. Tag me in Gitter if you still don't understand currying and we can discuss there if you need more explanation. Good luck!


feat: add resource-pruner cronjob

resource pruning is not enabled in the app-sre clusters, and we are not able to annotate
the namespace, hence we are going to use a cronjob for pruning instead.
Please do not merge this. I have to get in contact with app-sre first. This PR is intended as last resort, when everything else is not possible.
Also, I am not sure if the serviceaccount in our namespace has enough permissions to do this. :/ If not this will not work as well.

/hold

/lgtm


Custom zoom in ,zoom out button in svg pan zoom

Hi,
how to use zoom in,zoom out and reset functionality showed in svg-panzoom.js demo ,on click of my web page buttons like below show button,i want to do zoom and reset functionality on click of button
reset
reset
reset

Sorry, but this is not a helping board. You should write only issues here.
There is an API available. There is even an example with what you're asking.
You can post such questions on StackOverflow with svgpanzoom tag (as it is mentioned in Readme).


resolve path relative to public folder

I have mix copied semantic-sass assets from node_modules to public folder :
// /webpack.mix.js
mix.copy('node_modules/semantic-ui-sass/app/assets/images/', 'public/images/', false)
  .copy('node_modules/semantic-ui-sass/app/assets/fonts/', 'public/fonts/', false)
  .js('resources/assets/js/app.js', 'public/js')
   .sass('resources/assets/sass/app.scss', 'public/css')

This is how it looks like after copying:
source :
/node_modules
 |+semantic-ui-sass
     |+app
        |+assets
            |+fonts
               |+semantic-ui
                  |-icons.eof
                  |-icons.otf
                     ......
           |+stylesheets
               |+semantic-ui
                  |+elements
                      |_icon.scss
                 .......

dest:
/public
 |+css
     |-app.css
 |+fonts
     |-semantic-ui
     |-icons.eot
     |-icons.otf
     |-icons.svg
     |-icons.ttf
     |-icons.woff
     |-icons.woff2

Then imported icons inside /resource/assets/sass/app.scss
// resources/assets/sass/app.scss
@import 'node_modules/semantic-ui-sass/app/assets/stylesheets/semantic-ui/elements/icon';

After running npm run dev, this is the result produced :
source:
  src: font-url("semantic-ui/icons.eot");
  src: font-url("semantic-ui/icons.eot?#iefix") format('embedded-opentype')
    ...

dest:
/* public/css/app.css */
@font-face {
  src: font-url("./../../../node_modules/semantic-ui-sass/app/assets/fonts/semantic-ui/icons.eot");
  font-url("./../../../node_modules/semantic-ui-sass/app/assets/fonts/semantic-ui/icons.eot") format("embedded-opentype");
  .....
}

But this is want i want :
/* public/css/app.css */
@font-face {
  src: font-url("fonts/semantic-ui/icons.eot");
  src: font-url("fonts/semantic-ui/icons.eot");
  .....
}

I was wondering is there some way to configure mix to resolve urls inside scss relative to production public folder instead of dependencies source folder without changing the source?

I have this problem too.  I can't load FontAwesome via SCSS because webpack insists on absolute URLs instead of relative ones.
This works, but loads the URLs as a file looking at localhost/fonts instead of my public directory:
$fa-font-path: "/../fonts/";
@import "node_modules/font-awesome/scss/font-awesome";

This is what I need, but won't work because it's a relative directory:
$fa-font-path: "../fonts";
@import "node_modules/font-awesome/scss/font-awesome";

Aha!
Add this to your webpack.mix.js file:
.options({ processCssUrls: false })

As referenced here.

Dankie @swt83

Is this something webpack changed on their end recently?
One of my recent projects used laravel-mix 0.8.8 and I'm pretty sure I got bootstrap's glyphicons linked properly without extra configuration.
I'll be watching this issue.

How about relative asset path? e.g. ../img/image.png?
Also doesn't properly resolve.

I'm having a similar issue.
I'm not sure processCssUrls will help people that have non-standard directory layouts (such as in a shared hosting), or hosted in subdirectoreis.
Since fonts are already in the public/ directory, shouldn't paths be relative anyway?

Here's what I did for relative asset paths:
webpack.mix.js
mix.webpackConfig({
    resolve: {
        alias: {
            '@': path.resolve('src')
        }
    }
}).options({
    extractVueStyles: true
}).js('src/main.js', 'dist/').sass('src/assets/scss/app.scss', 'dist');

fonts.scss
@font-face {
  font-family: 'font';
  src<EMAIL_ADDRESS>format('woff2'),
<EMAIL_ADDRESS>format('woff');
  font-weight: bold;
  font-style: normal;
}

App.vue
  ....
<style lang="scss">

    @import 'assets/scss/module/fonts';
....

Offcourse these aren't node-modules but they are a use case that can be applied to this issue.


division by zero

Warning: Division by zero  in app/code/community/Adyen/Fee/Model/Total/PaymentFee/Tax/Creditmemo.php on line 36
maybe already known
but reported to help

Hi Sean,
The above fix should solve the issue.
Regards,
Rik
Adyen


[CSB-3069] - Opensearch system-x implementation

the whole service looks like just a copy paste of elasticsearch service - it would make more sense to extract common stuff into a parent or something

Hi @avano , let me understand, do you mean a single system-x for both? They are two totally separate products. In the past the opensearch client was compatible with elasticsearch, but starting from a certain version onwards, it is no longer. In my opinion it doesn't make much sense, but if you prefer, I can increase the abstraction, but it would be a bit confusing.

do you mean a single system-x for both
no, two separate services, but common stuff (which, at the first glance, seems to be like 95% of the code - correct me if I'm wrong) extracted into a separate artifact - something like the case with all the databases for example

do you mean a single system-x for both
no, two separate services, but common stuff (which, at the first glance, seems to be like 95% of the code - correct me if I'm wrong) extracted into a separate artifact - something like the case with all the databases for example

You are not wrong. Given the good level of abstraction provided by TNB, 70% of all services appear as a copy/paste. But that's okay. I can increase the genericity and put the common parts under a single artifact, like for AWS or DB. Would "search-engine " be okay in your opinion as a name?

@smongiar looks good :+1:


Test coverage for validate and deploy

Add test coverage for validating and deploying to S3.
These tests require AWS credentials.

coverage for validate added.


Provide a compatibility version with v4

animate's next version will include a major breaking change, class prefix (aka namespace), and this will make a direct update from previous versions harder and I see a lot of issues popping on this issue tracker related to this feature in the future.
It would be easy to provide a file for compatibility with previous versions (like animate.compat.css). The question is, should we provide this file out of the box in the new release?
We need as much feedback as we can get relating to this as it will be one of the biggest change in the whole library's story.

@WarenGonzaga, what do you think about this?

@eltonmesquita it would be nice to add that one since as you said it is a breaking changes for the entire library I saw some website is highly dependent on animate.css as their animation library. For that's okay.

@eltonmesquita I don't see this update in the current build...

It's now available on the dev branch.


make wbr end tag omissible

Fix issue #111
According to HTML specification, wbr element does not have end tag -- https://html.spec.whatwg.org/#the-wbr-element

http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_wbr
I try the demo failed in Chrome 49 and Firefox 44

I make a better fix: https://github.com/yaniswang/HTMLHint/commit/591f103a065336a2a5d561562c6965cf16f97bcb

Tks


Make key handling less strict

Sway has been very strict when it comes to key handling. Only on an
exact match would a bindsym be triggered.
This patch makes it less strict by for instance allowing the key combo
$mod+1+2 to act as $mod+2 if 2 was the last pressed key and $mod+1
if 1 was the last pressed key.
The new key handling uses the following algorithm:

List of bindings sorted by number of keys in binding (already the
default)
Find all bindings covered by the current keyboard state and list them
by same order as in 1.
Select the first binding from the list where the last pressed key is
part of the binding.

Addresses #452
@SirCmpwn we discussed the situation of $mod+Shift+s acting as $mod+s, but this will actually not happen because modifiers are checked separately from other keys, and I have not changed that behavior.

Looks good. Tested and can confirm it fixes #452. Will merge when build completes.


⚠ Bofrost.be has degraded performance

In 7351fd3, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1135 ms

Resolved: Bofrost.be performance has improved in d3cffd5.


fix: mask secrets in import logs

Saw this in the logs when trying to install jx in a k3s cluster.

/test pr


Question: About replicas and parallelism.

Thank you for the great samples.I would like to ask you a question.
https://github.com/dockersamples/example-voting-app/blob/e433be5d16aa4ea3aa8384c96565f4c2cafd9ddc/docker-stack.yml#L8-L12
If replicas is 1 and parallelism is 2 (or more than 2), what effect are you expecting? if replicas is 1, is it not a rolling update because there are times when containers are temporarily zero?

We're sorry for the late response. Linux images have been refreshed, cleaned up, and are now multi-platform. If you're still having issues with the latest images, feel free to reopen this ticket.


Updated jobs try catch to handle PHP7 Throwable exceptions

Codecov Report

Merging #159 (9ee529b) into master (3150dfa) will increase coverage by 0.01%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #159      +/-   ##
============================================
+ Coverage     30.94%   30.96%   +0.01%
- Complexity     2447     2451       +4
============================================
  Files            95       95
  Lines          7664     7669       +5
============================================
+ Hits           2372     2375       +3
- Misses         5292     5294       +2

Impacted Files
Coverage Δ

retailcrm/lib/RetailcrmJobManager.php
0.00% <0.00%> (ø)

...ailcrm/lib/templates/RetailcrmSettingsTemplate.php
0.00% <0.00%> (ø)

retailcrm/retailcrm.php
20.94% <0.00%> (+0.36%)
: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 3150dfa...9ee529b. Read the comment docs.


PHP Parse error

Laravel Version: 5.5.13
PHP Version: 7.1.2
Database Driver & Version: Mysql

Description:
Error when i deploy to server
Steps To Reproduce:
Error:
Generating optimized autoload files
  > post-install-cmd: php artisan clear-compiled
  PHP Parse error:  syntax error, unexpected '?' in /###/releases/1/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php on line 233
  Script php artisan clear-compiled handling the post-install-cmd event returned with error code 255

php -v PHP 7.1.10
php -l src/Illuminate/Foundation/helpers.php
No syntax errors detected in src/Illuminate/Foundation/helpers.php
Are you sure you are using php 7+?

This repo is for bug tracking. Use the forums or slack channel for solving your issue

As Dylan said here is not the place for such issues, but anyways...
You are not using PHP 7 that is for sure.

Thank for your replies. I resolved my issue. I will post to forum if i have next issue 😄


Add Zach Zollner to Contributors list

Hi  @zez9787, I'm quite elated about your pull request. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a pull request and learned that I merged it?
We’ve recently added social share  to our web app. Could you please go to https://roshanjossey.github.io/first-contributions/#social-share and share your first contribution to open source?
Also, check out projects with easy issues while you’re there.

Your tutorial was super easy to follow and I had no issues going through it. It's pretty intimidating trying to make contributions to other peoples projects.
Thanks for creating the project!

I’d urge you to continue contributing to other open source projects.
We also have a slack team to help/mentor people trying to contribute to open source projects.
You can join the team by going to https://goo.gl/PM1Jdh

I'd like to start contributing to more projects also.
Thanks for reaching out.


Versioning

LambdaBuffers should adopt a versioning scheme for the lbf schemas, frontend/compiled, codegen modules, runtime libraries, and the Nix packaging tools.
TODO:

[x] Settle on a versioning scheme and document it
[x] Figure out the versioning strategy for various parts (what changes are safe, compatible with previous versions, and which are breaking etc)

[x] LB Frontend, mostly syntax and module system related.
[x] LB Compiler, has a Protobuf API, this should be central to this.
[x] LB Codegen, has a Protobuf API, this should be central to this, but also the outputted code might affect users too.
[x] Runtime libraries for Prelude and Plutus

[x] Introduce CHANGELOG

Before we start releasing the tools and publishing packages, we must have this sorted out.

Done in #250


Nothing displayed after proper transfer learning with custom dataset

Hi all!
I wanted to use the model to get custom detection of guitar on video feed (plz dont ask me why ^^). I built my dataset properly, annotated it with labelimg, converted to suitable xml with the hierarchy similar to the voc2012 one. The training is going on very well, it produces 10 checkpoints along the way. But when I try to detect a guitar on one of the dataset image, it returns nothing...
Could you help on this one or at least provide better explanation for the transfer learning part ?
Thx in advance :-)

I ran into a  similar problem. HOPE SOME GUYS CAN HELP US   !!!!!!      ToT!!!

@IAFutur You may need to tweak the post-processing methods.

@IAFutur You may need to tweak the post-processing methods.

@IAFutur You may need to tweak the post-processing methods.

@innat yeah well maybe it was the problem. Anyway, this implementation of yolov3 was a little bit old and largely uncommented so I suppose my problem came from a bad comprehension of config files. For one year, I had been struggling with this implementation but now I suggest you to work on yolov4 which is muh more commented on https://alexeyab84.medium.com/yolov4-the-most-accurate-real-time-neural-network-on-ms-coco-dataset-73adfd3602fe.
Hope it helps
VA

@IAFutur You may need to tweak the post-processing methods.

@innat yeah well maybe it was the problem. Anyway, this implementation of yolov3 was a little bit old and largely uncommented so I suppose my problem came from a bad comprehension of config files. For one year, I had been struggling with this implementation but now I suggest you to work on yolov4 which is muh more commented on https://alexeyab84.medium.com/yolov4-the-most-accurate-real-time-neural-network-on-ms-coco-dataset-73adfd3602fe.
Hope it helps
VA


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

Codecov Report

Merging #438 (74a7198) into main (e4a2eac) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 74a7198 differs from pull request most recent head bd5f4d7. Consider uploading reports for the commit bd5f4d7 to get more accurate results

@@           Coverage Diff           @@
##             main     #438   +/-   ##
=======================================
  Coverage   95.69%   95.69%
=======================================
  Files           1        1
  Lines         395      395
  Branches       53       53
=======================================
  Hits          378      378
  Misses         17       17

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Integration for handles

Use asset_address_list (but latest one)

initially adahandles (or equivalent) could be used for testing
Add warnings about lack of standards for this approach to specs endpoints

asset_nft_address added as part of linked PR, does not require warning as it does not mention handle


Fixing syntax error on MailChimp->getLastError()

Fixing getLastError() return, using php5.6 on Wordpress v.4.7

The expression is correct as of PHP 5.3 and above. Why are you modifying it?

As in the image attached, i´m facing that error.

If you're getting an error from the elvis operator alone, then it's possible you're not running PHP 5.6 as you think. As @terrymun correctly says, that syntax is good from PHP 5.4 and up.
There must be something else going on here.


get related bib records for 12282751

VERY IMPORTANT
Search result lists four holdings, item view only two (CU, GT). problem with get related bibs routine
The records have these isbn values in common<PHONE_NUMBER>127<PHONE_NUMBER>
http://catalog.wrlc.org/cgi-bin/Pwebrecon.cgi?BBID=12282751
http://catalog.wrlc.org/cgi-bin/Pwebrecon.cgi?BBID=12282708
http://catalog.wrlc.org/cgi-bin/Pwebrecon.cgi?BBID=12239893
http://catalog.wrlc.org/cgi-bin/Pwebrecon.cgi?BBID=12266141

This issue was resolved by revisions to z3950.py in a related issue im m29_001, #854


"dead end" Recovery Strategy for malformed binary and hexadecimal literals?

To avoid an XY-problem, the problem I'm trying to solve is my Sail language lexer is failing to produce an error for malformed binary and hexadecimal values. For example the literal 0b2 should fail to parse with an error saying that it expected a 0 or a 1 after 0b. Instead it is successfully parsed as a Number(0) and Identifier(b2) tokens, despite trying many different combinations of orderings in the top level choice.
I wrote a DeadEnd strategy:
/// Recovery strategy for unrecoverable inputs
pub(crate) struct DeadEnd;

#[allow(deprecated)]
impl<I: Clone + PartialEq, O, E: Error<I>> Strategy<I, O, E> for DeadEnd {
    fn recover<D: Debugger, P: chumsky::Parser<I, O, Error = E>>(
        &self,
        recovered_errors: Vec<Located<I, P::Error>>,
        fatal_error: Located<I, P::Error>,
        _parser: P,
        _debugger: &mut D,
        _stream: &mut Stream<'_, I, <P::Error as Error<I>>::Span>,
    ) -> (
        Vec<Located<I, P::Error>>,
        Result<(O, Option<Located<I, P::Error>>), Located<I, P::Error>>,
    ) {
        (recovered_errors, Err(fatal_error))
    }
}

with the intention of adding it to only the hex and bin lexers, so if an error occurs after seeing a 0b then it is printed rather than recovered from, but this does not work and it still produces the Number(0) and Identifier(b2) tokens.
Full source here: https://github.com/fmckeogh/borealis/blob/51fa2df198436b0afdb56598618d8b6ce9b9a969/sail/src/lexer.rs
What am I doing wrong here? Thank you!

I suspect that a better approach for you would to just use the validate combinator rather than implementing a new recovery strategy. You can allow 0b<any number of numbers of letters> to parse, and then use validate afterwards to check that they match the radix prefix afterwards, generating an error if they don't.

@zesterer Thank you so much, I'll do that:)


Bugfix/format category link append store code

Fixed bug around appendStoreCode in formatCategoryLink.

conflicts are resolved.


metadata endpoint now supports offset and limit

Fixes #2315

@jedesah , I just restarted failing job (looks intermittent). Will merge once that passes


integrate vit in topomoe

Added ViT in topomoe. Also many files were moved to src beforehand so handled imports accordingly

Superseded by #18


[web][ff] web socket breaks when changing network

At Gitpod we received bug requests that in FireFox (117-118) VS Code Web (1.82) sometimes became unresponsive. See Loom for what unresponsive means.
It is hard to reproduce, but I was able with following:

Leave FF tab in the background.
Trigger reconnects by toggling your wifi for instance.
After a while come back to FF tab.

Debugging web part showed that frontend is keep asking to replay missing messages, but server keeps replaying with the same message. Unfortunately I was not able to debug the server part.

It is wort to mention that we observed this issue also without reconnection as well. Would maybe make sense to cycle a web socket if after replay the first replayed message don't satisfy this criteria: https://github.com/microsoft/vscode/blob/d532fad7425a5f2e17d321ee7a3c074595d093b7/src/vs/base/parts/ipc/common/ipc.net.ts#L1003 Otherwise it goes to loop forever?

I was able to reproduce it reliably with VS Code Server from sources by toggling VPN exit nodes. I've enabled server side diagnostics and noticed that server gets read and webSocketNodeSocketReadData events after toggling, but there are not more protocolHeaderRead and protocolMessageRead diagnostic traces. This loop does not seem to hit: https://github.com/microsoft/vscode/blob/63b61dc2a71f5763483d7f17da5f1c03e57aba43/src/vs/base/parts/ipc/common/ipc.net.ts#L363
cc @alexdima does it ring any bell? Would it help if i share such traces?

Here are traces one from Chrome and another from FireFox with the same test. You can see that at the end of FF log there are no anymore tracing for protocolHeaderRead and protocolMessageRead. (just a note I disabled compression while testing it here but it did not change results)
server.chrome.log
server.ff.log

I've tested a workaround that effectively resolves the issue; you can view the changes in our fork [1]. Should I send a pull request?
I've also filed a bug report for Firefox: 1855692.

Hmm, it's possible Firefox is sending a control opcode that we don't handle well https://datatracker.ietf.org/doc/html/rfc6455#section-5.2

@akosyakov If you still have an easy repro, could you perhaps log the opcode:
diff --git a/src/vs/base/parts/ipc/node/ipc.net.ts b/src/vs/base/parts/ipc/node/ipc.net.ts
index ed30467961b..e1f14c2361a 100644
--- a/src/vs/base/parts/ipc/node/ipc.net.ts
+++ b/src/vs/base/parts/ipc/node/ipc.net.ts
@@ -390,6 +390,8 @@ export class WebSocketNodeSocket extends Disposable implements ISocket, ISocketT
                                const firstByte = peekHeader.readUInt8(0);
                                const finBit = (firstByte & 0b10000000) >>> 7;
                                const rsv1Bit = (firstByte & 0b01000000) >>> 6;
+                               const opcode = (firstByte & 0b00001111);
+                               console.log(`opcode: ${opcode}`);
                                const secondByte = peekHeader.readUInt8(1);
                                const hasMask = (secondByte & 0b10000000) >>> 7;
                                const len = (secondByte & 0b01111111);

@alexdima here is output:

Created a PR fixing it https://github.com/microsoft/vscode/pull/194436 cc @alexdima

Thank you both! I confirm that handling ping control code resolves the issue. @alexdima I verified that @jeanp413's PR work both with Chrome and FireFox.

Thank you! ❤

Marking as verified due to @akosyakov's confirmation.


Implement wallet.dat encryption

Is it possible to implement wallet encryption like in bitcoin-core?

Unfortunately, the wallet.dat encryption needs to be implemented in zcashd, and is not possible to implement in zec-qt-wallet alone.
I think they already have an open issue on the zcashd github for this. Please feel free to comment on that issue. (https://github.com/zcash/zcash/issues)
Closing this one.


support prefix-tunning

hi guys,
We found that infer with vllm can greatly improve performance! But we need to use p-tunning prefix-tunning prompt-tunning for peft model or custom prefix encoder in inference.
We also found that the community has a strong demand for prefixtuning. https://github.com/vllm-project/vllm/issues/660
So we added an prefix-tunning for opt. The following is an example of use:
from vllm import LLM, SamplingParams
from vllm.model_executor.adapters import lora

# Create an LLM.
llm = LLM(model="facebook/opt-125m", adpater_model_and_path='your pet_model_id')

prompts = [
    "Hello, my name is",
    "The capital of France is",
    "The future of AI is",
]

sampling_params = SamplingParams(temperature=0, top_k=-1)

outputs = llm.generate(prompts, sampling_params)
for output in outputs:
    prompt = output.prompt
    generated_text = output.outputs[0].text
    print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")

Currently supports  ptunning prefixtunning prompttunning for peft model or custom prefix encoder， but only support  the  opt model

Translation: Prefix-Tuning Process
Generation and loading of the embedding model:
a. The model itself comes with a Prefix Encoder.
b. The Prefix Encoder from the peft model.
c. Embedding table.
Generating embeddings based on the configuration and storing them in the kv-cache.
For each worker's block_manager:
a. Generating a block list corresponding to a prompt.
b. Storing the corresponding prompt's kv_cache in the GPU's kv cache.
During computation:
Step 1:
i. The scheduler concatenates the length when multi_query_kv_attention
ii. When a sample is computed for the first time in the prompt, it is concatenated with the kv-cache.
Step 2:
i. add num_visuall_tokens with  context_len
ii. The GPU cache is directly read the total block table.

Rather than passing the prefix PEFT model into the LLM constructor, would it make sense to pass it into generate? (Or rather a loaded version of therefof).
One advantage of prefix tuning compared to e.g. LoRA is that it's much easier to "hotswap" between multiple tuned prefixes.

Closing as this PR is likely too stale to be merged.
@InkdyeHuang if you would still like to contribute your change, please either make a new PR or resolve the conflicts in this one.


Extend Validating Builders with ability to modify repeated fields

In order to replace a repeated field of a Validating Builder, we need to have a code like this:
static <T extends Message, P>
boolean replace(List<T> items, T item, Function<T, P> prop) {
    for (int i = 0; i < items.size(); i++) {
        T current = items.get(i);
        P passed = prop.apply(item);
        P found = prop.apply(current);
        if (passed.equals(found)) {
            items.set(i, item);
            return true;
        }
    }
    return false;
}

The calling code would look like:
@Subscribe
void updated(Column column) {
    boolean replaced = replace(builder().getColumn(), column, Column::getId);
    if (!replaced) {
        builder().addColumn(column);
    }
}

It would be more convenient to write:
boolean replaced = builder().replaceColumn(column, Column::getId);
if(!replaced) {
    builder().addColumn(column);
}

It would require generating replaceXxx() methods for all repeated fields.
Also, removeXxx() accepting a predicate is needed.

@alexander-yevsyukov @dmdashenkov
Regarding the removal. There is  Iterables.removeIf(iterable, predicate).

So basically, we can rewrite the code you wanted as:
// Remove the column if it exists.
Iterables.removeIf(builder().getColumns(),
                   c -> {c.getId().equals(column.getId())});
// Add the column, effectively replacing it if it was removed previosly.
builder().getColumns().add(column);

Yes, but this changes the order.

OK, there is one more option using JDK API.

Since we now use standard builders, this issue is no longer applicable.


packages.config missing from sample Droid project

It looks like the packages.config file is missing from the FreshMvvmSampleApp.Droid project.

packages.config correctly contains on here:
https://github.com/rid00z/FreshMvvm/blob/master/samples/FreshMvvmSampleApp/Droid/FreshMvvmSampleApp.Droid.csproj#L80
https://github.com/rid00z/FreshMvvm/blob/master/samples/FreshMvvmSampleApp/Droid/packages.config