text:
Added SurroundingSimilarity() and type of the same name. Fixes #49

This change is

Codecov Report

Merging #58 into master will increase coverage by 1.41%.
The diff coverage is 93.33%.

@@            Coverage Diff             @@
##           master      #58      +/-   ##
==========================================
+ Coverage   88.25%   89.66%   +1.41%
==========================================
  Files          20       20
  Lines         783      813      +30
==========================================
+ Hits          691      729      +38
+ Misses         84       74      -10
- Partials        8       10       +2

Impacted Files
Coverage Δ

individual_node.go
94% <100%> (+9.07%)
:arrow_up:

family_node.go
88.23% <66.66%> (-4.63%)
:arrow_down:

Continue to review full report at Codecov.

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

authors: codecov-io elliotchance

repo: elliotchance/gedcom


text:
Remove global color stripping

Since the introduction of the messaging functions it is no longer
necessary to strip color codes globally.

I still need that so we can pipe ellipsis around iirc.

Does msg.print automatically strip color codes?

It does!

It doesn't seem to detect whether there is a controlling terminal, that's what that little bit does. Should do that somewhere else if we don't want to do it globally.

It's implemented like this
# Show message
msg.print() {
    if [ -t 1 ] || [ -n "$ELLIPSIS_FORCE_COLOR" ]; then
        echo -e "$@"
    else
        msg.log "$@"
    fi
}

When msg.log is called colors are stripped first!

Ah right, okay cool.

Exit status when piping is unchanged right?

Yes, it will just exit with the exit status of the last command, which is cli.run.

You only needed the $PIPESTATUS variable because you piped cli.run through sed. A normal exit would then use the exit status of sed instead of cli.run.

source: gharchive/pull-request

authors: groggemans zeekay

repo: ellipsis/ellipsis

license: mit

license_type: permissive

license_source: bigquery


text:
add support for vim.g.gruvbox_cursor_line

There is already a bunch of possible configuration for other kind of color like vim.g.gruvbox_sign_column and vim.g.gruvbox_number_column.
This PR brings the same feature for the CursorLine to be able to create an homogeneous theme variation.

:tada: thanks!

license: MIT

license_source: github-api


text:
Proposal: remove record syntax for field addition and field deletion

The idea is to remove the following syntax:
{ point - z }      -- remove field z

{ point | z = 4 }  -- add field z

We keep all the type system stuff that makes record update work, but this surface syntax is removed.
I created the simple-records branch which actually implements this.
Talking with @JoeyEremondi, it came up that these operations may impose a significant performance cost. I had a discussion along these lines with one of the creators of Julia at Curry On which kind of pushed me over on this.
Arguments in favor of removal
Usage: I have never seen either of these features used in practice. Furthermore, the uses that I have seen are crazy and cool (see @Apanatshka's example here) but in a way that I'd probably recommend against in general :)
I also suspect there's something antimodular about this in that you can add a field x to any record, even one that already has an x. This issue has never come up in practice (since no one uses this) but it's something to think about.
Performance: The fact that you can add and remove fields in JS was a big part of why performance was terrible back before Chrome came along and started mapping things onto "static classes" as much as possible (i.e. fixed set of fields so that lookups are constant time)
We piggy back on their work for this, but this will not be true if we are compiling to assembly some day. The ideal case is that we know the exact shape of a record, so we'd have the following code gen:
-- elm
point = { x = 0, y = 0, z = 0 }
newPoint = { point | x <- 4 }

// generated js
var point = { x: 0, y: 0, z: 0 };
var newPoint = { x: 4, y: point.y, z: point.z }

This may mean we can just copy the bits when we are going lower level. Furthermore, when you are doing field lookup, the fastest way is if you know the offset of each field so that lookup time is constant: r.x becomes "get offset N in r" and I think this will be harder if we have extension. We'll at least have to do a bunch of work, and it's all for a feature that seems not too useful so far.
Remaining Questions
Okay, this is a distraction. It does not change the core idea at all, but it's the part of this proposal that is the most controversial.
Now that = is free, maybe it makes sense to use that for record updates. In other words, should we switch from <- to =?
Let's talk about this only to the extent that it touches on the broader question.

Here's todo-mvc with equal signs instead of arrows. I personally prefer equal signs to arrows.
https://gist.github.com/TheSeamau5/f08d4e5e6bf0967a91a6

Thanks @TheSeamau5 :) I find that case + record updates often means a mix of -> and <- that can look quite odd.

Yup, I agree. Especially given the fact that record updates happen very often within case expressions.

To play devil's advocate, this feature gives you stacks that are checked at compile time:
push x s = {s| data = x}
peek s = s.data
pop s = {s - data}
empty = {}

--legal
val1 = empty |> push 3 |> push 7 |> peek
val2 = empty |> push 3 |> push 7 |> pop |> peek

-- compile-time error!
val2 = empty |> push 3 |> push 7 |> pop |> pop |> peek

But then I tried myStack = List.foldl push empty [1..4] and caused the compiler to stack overflow. So yeah, get rid of it. And switch to = too.

With the stack thing that Jeff noticed, I think you can do the same with ADTs. It's the same type trick either way.
type EmptyStack = EmptyStack
type StackFrame a stack = StackFrame a stack

push x stack = StackFrame x stack
peek (StackFrame x _) = x
pop (StackFrame _ stack) = stack
...

You don't get the kind protection where the substacks must be StackFrame or EmptyStack, but generally speaking, you can still do this.
In any case, I wouldn't say this example should guide our overall thinking. Can't imagine typed stacks being a major feature :P

The reasons for removing add and delete make sense to me, and I've never used either feature, so +1 from me.
On the separate syntax question, I have no strong feelings. Either <- or = seem fine.

LGTM. Don't care about <- vs. =, I'd rather get rid of that whole update syntax and use something more functional. But that's a discussion which is already going on in another proposal ;)

One thing that is not in that discussion is a concern about performance. If you want to update 3 fields, record update syntax is going to be way faster. The compiler maybe can be clever, but this way it's not necessary. The other issue should have that as part of the discussion if it is going to be an alternative.

I mentioned that to Richard this morning. IIUC as long as the function is fully applied then the compiler should be able to emit the same syntax as currently. When it's curried all bets are off.

@evancz We chatted about it briefly at the end of this comment and the two after it, but did not come up with any solutions.
I proposed a pipe-dream-ish "best of all worlds" solution just now, but I suspect it may be impossible.

+1 for = over <-
I've actually tried to use that syntax reflexively, and filed an error message catalog issue that could be closed if this were switched: https://github.com/evancz/error-message-catalog/issues/16

Okay, I'm gonna merge this into master. We can switch back to <- if we don't want to do 0.16 for some reason, but getting rid of extend and remove syntax seems pretty well accepted. Might be time to whip up an upgrade script though, this change should be totally mechanical!

My two cents: keep the breaking changes in branches, get the patch-level features done, and then decide if 0.16 looks far away enough to make 0.15.2 worthwhile.
Since when are we getting rid of multi-way if? I don't like the pipes but the language construct is useful. String interpolation would be great. There was a thread on the list about redoing mailboxes and I think we should try to fit that into 0.16 as well. Also, opinions are divided on the comma proposal.

@mgold We're working on migrating these discussions to elm-plans for more focused discussion and visibility into process. Please raise issues there. It'll be announced on the mailing list soon along with regular live remote meetings. Looking forward to collaborating!

If we also overhaul update I'm still in favor of @dobesv's proposal.
:+1: for branching. Is everyone familiar with Git Flow? It's best practice for very active projects.
IIUC multi-way-if has issues: 1) there are scenarios where cases are undecidable to the compiler and 2) complex conditionals are a code smell in FP. IME case usually fits better.
I wish string interpolation had a more concise syntax. I'm reviewing the thread and various language implementations tonight. Looking forward to it regardless.
I think asynchronous effects in general are stumping many users (me too). It sounds like @evancz is rethinking effects and concurrency together with types and usability in broad strokes. I expect Mailbox will evolve organically at that time.
Evan patiently and persuasively convinced both @rtfeldman and myself that trailing commas are the best option. @Apanatshka and I raised concerns about allowing them to be optional but they'd look awkward on a single line.

Got it, thanks, I'll comment on the individual concerns in their respective threads.

I actually use field addition and deletion to check certain constraints in a DSL at compile time.
I am not sure if it's worth the hassle and I am not advocating for or against the proposal. I just want to illustrate that there are use cases for field additions/removals, which facilitate compile time checks that would be hardly possible otherwise.
In my Firebase wrapper ElmFire there are functions to specify a query like that:
q1 = valueChanged |> orderByChild "height" |> limitToLast 2
q2 = childAdded |> orderByPriority |> startAtPriority (NumberPriority 5) Nothing

There are a bunch of constraints how these options may be combined. For example you can use ony one orderByX option and you can use startAtPriority only when used together with orderByPriority.
Using record fields to sum up the options used so far enables us to check the validity of the next option.
These a the relevant types and functions used in the example above:
{-| A query specification: event type, ordering, filtering, limiting -}
type alias Query q = { q | tag : QueryOptions }

type QueryOptions = QueryOptions
emptyOptions =
  { tag = QueryOptions
  , noOrder = True
  , noLimit = True
  , noStart = True
  , noEnd = True }

type QueryEvent =
  ValueChanged | ChildAdded | ChildChanged | ChildRemoved | ChildMoved

valueChanged =
  { emptyOptions | queryEvent = ValueChanged }

orderByChild :    String
               -> { r | noOrder : a }
               -> { r | orderByChildOrValue : Maybe String }
orderByChild key query =
  { query - noOrder | orderByChildOrValue = Just key }

orderByPriority : { r | noOrder : a }
               -> { r | orderByPriority : Bool }
orderByPriority query =
  { query - noOrder | orderByPriority = True }

startAtValue :    JE.Value
               -> { r | noStart : a, orderByChildOrValue : o }
               -> { r | orderByChildOrValue : o, startAtValue: JE.Value }
startAtValue value query =
  { query - noStart | startAtValue = value }

startAtPriority : Priority -> Maybe String
               -> { r | noStart : a, orderByPriority : o }
               -> { r | orderByPriority : o, startAtPriority: (Priority, Maybe String) }
startAtPriority priority key query =
  { query - noStart | startAtPriority = (priority, key) }

limitToFirst :    Int
               -> { r | noLimit : a }
               -> { r | limitToFirst : Int }
limitToFirst num query =
  { query - noLimit | limitToFirst = num }

limitToLast :     Int
               -> { r | noLimit : a }
               -> { r | limitToLast : Int }
limitToLast num query =
  { query - noLimit | limitToLast = num }

Complete code for query specs is here.

I think this is a good example of something useful you can do with addition/deletion.
If at all possible, I'd like addition and deletion of fields to stay around in a way that's hard to stumble upon accidentally, more as an advanced feature that you can use for things like this.

I'm in favor of this proposal. I never needed "remove" or "add" for records. And it seems like right now this even can cause inconsistent compiler behavior.

I actually used it last night making an example to experiment with components. I'd like to wait till architecture questions are resolved to evaluate impact on major demos.

+1, because I tried to use = to update a value in a record. <- did not occur to me.
= is the original way to put values in a record (at initialization), and I'd love to use it for copy-constructor-style changes too.
As to adding or removing a field from a record, haven't wanted to. If I did do it, because it would be rare, I'd rather have a named function than syntax.

Okay, thanks for all the feedback! :)
I talked with a JS dev new to Elm at the meetup last week and he was running into lots of -> and <- in ways that felt weird. So between seeing that and the feedback here, I'm pretty into this idea.
The remaining concerns for me are:

Does this impact [glsl| ... |] blocks for elm-webgl?
Can we find an API for @ThomasWeiser's case that works well and does not rely on the features that would be removed?

Alright, I am closing in favor of https://github.com/elm-lang/elm-plans/issues/16 which will track a couple things along these lines. It's good to have them all in one place. Furthermore, I think it's not making sense to have proposals in the elm-compiler repo anymore, so I am laying the groundwork for doing this in a better way. For now, please let me manage elm-plans, no new stuff there!

My use case mentioned above (constraints in a DSL in the API of ElmFire) should not block this proposal in any way.
I can surely drop the compile-time checks and instead check the constraints at run-time. The tasks involved can fail anyway, so this would be just another error case.
In general, checking constraints on combining pieces of data at compile-time is nice. But I guess such combinations will be a static thing in most applications, so violating them would be obvious quickly with basic testing.

The case of @ThomasWeiser kind of convinced me, that addition and deletion can be very useful after all. I guess I initially only voted in favour of the proposal because of the assosiated bugs (1,2). If they will be fixed fixed, I would vote for keeping record addition and deletion in the language.

If I'm understanding correctly, the motivation behind this DSL is to avoid bugs where you accidentally specify something twice, and only meant to specify it once. If all the DSL can do is update syntax, then you can accidentally call startAtValue twice on the same query, and the second one will "win" - whereas it would be better to make that a compile error, so you could make sure only to call it once.
Assuming that's the case, couldn't you get the same level of safety if this change were coupled with a "no duplicate fields in the same record update" rule?
In that case you wouldn't even need a DSL here; compare:
-- Current
emptyOptions = { noOrder = True, noLimit = True }

q1 = valueChanged |> orderByChild "height" |> limitToLast 2
q2 = childAdded |> orderByPriority |> startAtPriority (NumberPriority 5) Nothing

-- Alternative
type OrderOptions = NoOrder | ByPriority | ByChild String
type LimitOptions = NoLimit | ToFirst Int | ToLast Int
type StartOptions = NoStart | StartAtValue JE.Value | StartAtPriority Priority (Maybe String)

defaults = { order = NoOrder, limit = NoLimit, start = NoStart }

q1 = { defaults | queryEvent = ValueChanged, order = ByChild "height, limit = ToLast 2 }
--Formerly: q1 = valueChanged |> orderByChild "height" |> limitToLast 2

q2 = { defaults | queryEvent = ChildAdded, order = ByPriority, start = StartAtPriority (NumberPriority 5) Nothing }
--Formerly: q2 = childAdded |> orderByPriority |> startAtPriority (NumberPriority 5) Nothing

Assuming there's a "no duplicate fields in record updates" rule in effect, you have the same characteristics as before:

Query validity guaranteed at compile time
Easy way to build up a query without the ability to accidentally overwrite your previous values

Thoughts?

If I'm understanding correctly, the motivation behind this DSL is to avoid bugs where you accidentally specify something twice, and only meant to specify it once.

Thanks Richard, this is one type of constraints, and I agree this could be expressed the way you propose (given the new "no duplicate fields in records or record updates" rule).
There is an additional constraint that I currently check, e.g.: startAtPriority is only valid if it's used with orderByPriority, startAtValue is only valid if used with orderByChild or orderByValue, etc. In other words: the parameter type of startAt and endAt depends on the used ordering.
I couldn't find a way to check at compile-time without using record-field addition/deletion.

I have a feeling that some other use cases of field addition/deletion may emerge in the future. So I would propose to remove the syntax only but leave the operations in place (using named functions).
I'm not sure I fully understand Evan's original performance concerns. I don't think that dynamically updating existing JS objects is involved here.
But I would appreciate the proposed syntax change (= for updating a field). And it should be possible to update several fields at once (both for nicer code and for performance reasons):
m1 = { x = 1, y = 2, z = 3 }
m2 = { m1 | x = 10, y = 20 }

startAtPriority is only valid if it's used with orderByPriority, startAtValue is only valid if used with orderByChild or orderByValue, etc. In other words: the parameter type of startAt and endAt depends on the used ordering...I couldn't find a way to check at compile-time without using record-field addition/deletion.

Ah! I'd encode that restriction into the union type, e.g.
type OrderOptions
  = NoOrder
  | ByPriority (Maybe (Priority (Maybe String))) -- Nothing means no startAtPriority
  | ByChild String (Maybe JE.Value) -- Nothing means no startAtValue

type LimitOptions = NoLimit | ToFirst Int | ToLast Int

-- This is now obsolete
-- type StartOptions = NoStart | StartAtValue JE.Value | StartAtPriority Priority (Maybe String)

Yup, using union types to make impossible states unrepresentable is a great skill to have.

Yep, that should work. Thanks for your efforts, much appreciated!

Happy to help! :smile_cat:

Please excuse my inanity, @rtfeldman, but I do not yet understand how the union approach can prevent mistakes like this
unorderedThing |> startAtPriority

at compile time as opposed to valid operations like that?
unorderedThing |> orderByPriority |> startAtPriority

Would you mind elaborating or giving a minimal example?

I'd probably approach the API by trying to only allow the construction of acceptable values. So maybe have a few ways to construct a Query where you do all the settings as arguments, not as functions that modify a Query. I think with Richard's route about favoring union types it may even be possible to have the functions and be sure that you always end up with a Query in a safe configuration.
As things stand, I tend to see this as a recommendation for removing the syntax for extension and deletion. Perhaps the realization here is that "it's possible to encode these problems with union types and end up with a simpler API" which is actually a pretty cool insight if I'm understanding things correctly.

Perhaps the realization here is that "it's possible to encode these problems with union types and end up with a simpler API" which is actually a pretty cool insight if I'm understanding things correctly.

Is that the same as saying extension and deletion is a nice sugar for problems that need union types in other MLs though?

I don't think so; as per the original post, they're more than just "nice sugar" - they have some legit drawbacks!

Once this is done (in fact, I think it has been, since the simpler-records branch has now been merged), is code of the following kind still intended to work? (Note that I would just build the master branch and see, but I'm having trouble doing that right now, and I think it's a known problem at the moment that's beyond my ability to solve.)
Note that I've simplified this a bit, and it's incomplete (just imagine the extra bits that would make this compile) -- so the point of this is modular construction of an extensible record.
The reason I ask is that what initialLanguageModel, initialAccountModel and initialFocusModel are doing below amounts adding a new field -- that is, they take a record of one type, and return a record of a different type by adding a field. However, they aren't literally using the syntax that has been removed. So perhaps this is still intended to work?
My apologies if it was obvious that this was still intended to work -- I may be worrying about nothing.
-- in Main.elm, with suitable imports
type alias Model =
    LanguageModel (
    AccountModel (
    FocusModel (
      {}
    )))

initialModel : Model
initialModel =
    initialAccountModel <|
    initialLanguageModel <|
    initialFocusModel <|
    {}

-- in Language.elm
type alias LanguageModel m =
    { m | useLanguage : Language }

initialLanguageModel : m -> LanguageModel m
initialLanguageModel model = LanguageModel EN model

-- in Account.elm
type alias AccountModel m =
    { m | currentUser : Maybe User }

initialAccountModel : m -> AccountModel m
initialAccountModel model = AccountModel Nothing model

-- in Focus.elm
type alias FocusModel m =
    { m | focus : Focus }

initialFocusModel : m -> FocusModel m
initialFocusModel model = FocusModel (Home HomeTypes.Home) model

I have a similar question, will this still work?
distFromOrigin : {a| x : Float, y : Float} -> Float
distFromOrigin {x, y} = sqrt <| x*x + y*y

foo = distFromOrigin {x = 5, y = 2, dx = 3, dy = -9.8}
bar = distFromOrigin {x = 1, y = 4}

This is the closest thing Elm has to interfaces and related features. It's true that you can't keep these records in a list (they have different types) but being able to apply the same function to both is very handy.

@rgrempel, your thing will not work. Even though it is different source syntax, it is defined in terms of the underlying record extension mechanism. So in the master branch, you can create record constructors for records with known shape, but cannot make record constructors that add a bunch of fields.
@mgold, your stuff all works. None of the types are changing, there is just a few syntactic constructs that are going away.

Thanks. I guess I have a follow-up question. Isn't what I was doing part of Elm's ambition for extensible records?
I'm thinking of this page:
[http://elm-lang.org/docs/records](http://elm-lang.org/docs/records)

... and in particular, everything following "You can also define extensible records. This is generally recommended because it makes your functions more reusable."
I guess what confuses me a little is that the discussion above was partly premised on the idea that no one uses this stuff -- e.g. "I have never seen either of these features used in practice. Furthermore, the uses that I have seen are crazy and cool (see @Apanatshka's example here) but in a way that I'd probably recommend against in general :)"
But, I thought that the idea of extensible records was actually pretty important to Elm, and pretty useful.
Now, perhaps it's the case that we'll still be able to define records extensibly -- that is, perhaps this syntax (from the Elm documentation page mentioned above) is still intended to work.
type alias Positioned a =
  { a |
      x : Float,
      y : Float
  }

type alias Named a =
  { a |
      name : String
  }

type alias Moving a =
  { a |
      velocity : Float,
      angle : Float
  }

dude : Named (Moving (Positioned {}))
dude =
  { x = 0
  , y = 0
  , name = "Clark Kent"
  , velocity = 42
  , angle = degrees 30
  }

But, if I understand you correctly, this is only intended to work if dude is fully initialized all-at-once ... that is, the record is extensible in terms of the type system, but not extensible at run-time. That seems like a strange gap -- not a "no one uses this exotic feature" type of thing.
For instance, it would mean that while the type definition can be modularized -- that is, the various parts of the extensible record can be defined in different modules for the purposes of the type system -- but, the actual initialization of the data cannot be modularized -- it would have to happen all-at-once at the top level. It seems to me that this will be inconvenient for programming "in the large" -- since Elm promotes the idea of a single, master model type, for instance, to which many, many modules might contribute in a large program. You would end up with a ton of decisions about initial state being located in a central module, when it would be much more convenient to locate the initial state with the definition of the types in the various sub-modules.
Now, clearly the central module is going to have to reference them. But, at least modification could then happen purely in the lower-level module. Imagine, for instance, if you have 20 submodules that define aspects of your big Model type. I don't see that as a ridiculous example at all -- Elm will get used in apps that big, and bigger, eventually, if not already. Now, imagine changing the type alias in one of the submodules to add a new field. With record extension at run-time, you can change the initial value of the data right in its own submodule (since it already is referenced from the main module). Without record extension at run-time, you have to change the initial value in the main module.
All of which to say that I think something important has been removed here, not something exotic.

Having thought this through a little more, I have realized that one can still achieve a reasonable level of modularity after this change.
What one would need to do is something like this:

Each sub-module would define a record type representing its portion of the big record (possibly with many fields, whatever was needed).

Each sub-module would define an initial value for its record type.

The main module would define the 'big' record as the combination of the many sub-module types, assigning a field name to each one.

The main module would define an initial value for the big record type using the field names it assigned, but referring to the initial values defined in the sub-modules.

That is, even if the field names can no longer be added by sub-modules, the right-hand side -- that is, the values -- can still be supplied by referring to sub-modules.
To make this concrete, I think my original example could be re-written something like this:
-- in Main.elm, with suitable imports
type alias Model =
    { language : LanguageModel
    , account : AccountModel
    , focus : FocusModel
    }

initialModel : Model
initialModel =
    { language = initialLanguageModel
    , account = initialAccountModel
    , focus = initialFocusModel
    }

-- in Language.elm
type alias LanguageModel =
    {  useLanguage : Language }

initialLanguageModel : LanguageModel
initialLanguageModel = LanguageModel EN

-- in Account.elm
type alias AccountModel =
    { currentUser : Maybe User }

initialAccountModel : AccountModel
initialAccountModel = AccountModel Nothing

-- in Focus.elm
type alias FocusModel =
    { focus : Focus }

initialFocusModel : FocusModel
initialFocusModel = FocusModel (Home HomeTypes.Home)

Then, imagine adding an additional field to LanguageModel, AccountModel or FocusModel. You'd only need to modify the sub-module -- you could add the new field to the type, and to the initial value, and you wouldn't need to touch the main module.
In fact, philosophically, it might make some sense to have to list the field names in the main module explicitly -- after all, in a way it makes sense for the main module to be in charge of the field names, since it is with respect to the overall record type that those names should not clash (or, at least, it is the main module that ought to be explicitly aware of such clashes). So, this is sort of like the way that the main module is in charge of the tag names for union types, even where the various types it is unifying are themselves defined in separate sub-modules.
Now, compared to my previous code, there would be an extra layer of indirection -- that is, what one could previously refer to as model.useLanguage would now be model.language.useLanguage. But, I'm not sure that's such a bad idea -- it leaves the 'tagging' (so to speak) of the main Model to the main module, which might be sensible -- again, it's sort of like the way union type tags work.
So, I withdraw my previous comment. Well, I suppose I could have just deleted it, but I'll leave it and this in case anyone finds the topic interesting.

In general there are a lot of features we can live without.  We can theoretically just program in lambda calculus, or assembly language.  So, it's not necessarily a question of where a feature is a necessity, especially in this case.  Rather, it's a cost benefit analysis.
I definitely have mixed feelings about this proposal. I like simplification, that reduces the cost.  And it sounds like the benefits of this particular feature turned out to be small so far.  But I also thought the row polymorphism stuff was pretty sexy, including adding fields.  It can be hard to let go :).
I think there is potential in record concatenation instead of fields addition.  But that's a whole other story and I don't have much to back that up yet.  It would have a different syntax and it should replace field addition since you can append whatever fields you were going to add.  So, it doesn't go counter to this proposal either.
So based on the limited data I have it seems okay to let go of field add and delete syntax.

I updated my actual code so it will work without adding fields at run-time. There was one little twist I didn't anticipate, but it wasn't that bad -- the results are pretty reasonable. Here's the commit, in case anyone's interested in what difference it made:
https://github.com/rgrempel/csrs-elm/commit/49b9b165c06d24b9deb009fcaa4ea0b0e967b405

Wow this is a great example of using records. I think doing it the new way
makes reading your core much clearer.
On Saturday, September 5, 2015, Ryan Rempel notifications@github.com
wrote:

I updated my actual code so it will work without adding fields at
run-time. There was one little twist I didn't anticipate, but it wasn't
that bad -- the results are pretty reasonable. Here's the commit, in case
anyone's interested in what difference it made:
rgrempel/csrs-elm@49b9b16
https://github.com/rgrempel/csrs-elm/commit/49b9b165c06d24b9deb009fcaa4ea0b0e967b405
—
Reply to this email directly or view it on GitHub
https://github.com/elm-lang/elm-compiler/issues/985#issuecomment-137925032
.

It's not entirely related, but I while playing with Focus-like kind of manipulations, I thought that if the .prop to "get" a property became something more like the :keyword in clojurescript along with getter and setter functions, it would allow a big deal of abstraction on top of records:
getFoo = get .foo
setFoo = set .foo

mario =
    { physics = { position = { x=3, y=4 }
                , velocity = { x=1, y=1 }
                }
    }

freeze object =
    Focus.set (.physics => .velocity) { x=0, y=0 } object

Do you think that it's interesting enough to start a conversation over the forum or another issue?

@Warry the discussion for that is over here: https://github.com/elm-lang/elm-compiler/issues/984

thanks @laszlopandy

Not sure if this would be appropriate here. But I'm just starting to learn Elm. And I thought the syntax was pretty smart with the delineation with = and <-, coming from an F# background (although I would consider myself proficient in said language).
I do find that I can do the following a bit disconcerting though:
type alias Person = { name : String, age : Int }

bill : Person
bill = { name = "Gates", age = 57 }

suzy = { bill | name <- 7 }

The behavior I expected was that suzy would still be a Person and that a compile error would be thrown when setting name in Person as 7. I saw the = and thought that was a nice use case for changing types:
jill = { bill | name = 7 } -- OK since replacing the type from { name : String } to { name : Int }
suzy = { bill | name <- 7 } -- expect compile error since just updating the record

I realize I'm a tad late on this - in fact I'm writing the following as much for personal reference as for helping others who may run into the same problem as me.
Elm requires having a top-level "Model" type that contains everything. Note that "contains everything" does not necessarily imply "knows the details of everything".
When building an app using generic widgets (eg. a date-time picker), we generally do not want the top-level Model (or the other widgets, for that matter) to know the knitty-gritty of our date-time picker. So you use an opaque type for the date-time picker and put it as a field in the top-level record type Model. That's fine, but often you have one or more layers of widgets between the more generic (ie. reusable) low-level widget (such as the date-time picker) and the completely specific overall application and that's where the problems start.
In Elm's architecture tutorial, there are two extreme cases:

The same model is shared by all widgets
Each widget has its own independent model

However, I find myself in a situation where I have three layers:

the overall application (which I will call Widget0)
the "subwidgets" Widget1and Widget2 composing this application
the elementary widgets composing the subwidgets.

Part of my model must be shared by all subwidgets, while other parts (eg. the elementary widgets' model) are completely specific. I haven't been able to find any examples of this (certainly not in the elm architecture tutorial). I discovered I came up with the same pattern as @rgrempel when initializing my widgets:
At the top-level (Widget0):
type alias Model a =
  { a
  | foo : Int
  | widget1 : Widget1.InternalModel
  | widget2 : Widget2.InternalModel

In module Widget1:
type alias Model a =
  { a
  | foo : Int
  , widget1 : InternalModel
  }

type InternalModel = Foo | Bar | Baz | Whatever

In module Widget2:
type alias Model a =
  { a
  | foo : Int
  , widget2 : InternalModel
  }

type InternalModel = {bla : Int, azd : String }

Just like @rgrempel, I want each module also provides its 'init' function to initialize its part of Widget0's model. With extensible records, I could simply do (eg. in Widget1):
init : a -> Model a
init foo =
  {foo | widget1 = initInternal}

and for Widget0 I would have the very clean and composible chain:
init : Model
init =
  {foo : 345}
  |> Widget1.init
  |> Widget2.init

So the extensible records were an easy way for me to build composable applications. With the removal of this feature, the initfunction can no longer be type-parametrized. This is really important so let me emphasize a bit: no extensible records means init must know the full record it operates on.
So I decoded to use @rgrempel's strategy, but he was in a case where all parts of his model were independent. The only workaround I found is to do the following for Wiget0 (top-level):
type alias Model a =
  { a
  | common : {foo : Int}
  , widget1 : Widget1.InternalModel
  , widget2 : Widget2.InternalModel
  }

and then, eg. for widget 2:
type alias Model a =
  { a
  | common : {foo : Int}
  , widget2 : InternalModel
  }

It's probably cleaner to define "common" in its own module (that way the submodules don't need to know about the top-level module)
type alias Common =
  { foo : Int }

init : Common
init = { foo = 321 }

Then, at the top-level Widget0 you have:
type alias Model =
  { common : Common
  , widget1 : Widget1.InternalModel
  , widget2 : Widget2.InternalModel
  }

init : Model
init =
  { common = Common.init
  , widget1 = Widget1.init
  , widget2 = Widget2.init
  }

The important thing to note here is that you must separate the internal part of the model from the common part: the full models of Widget1 and Widget2 are not exported - just their internal part (which seems a bit paradoxical, as the internal parts are typically the ones you wouldn't want to expose).
That in itself is not a problem. It becomes one when you loose extensible records because you have to put all common parts in a Common record, which essentially means you know in advance how your widget will be used.  For instance, what do you do if the data shared by Widget1 and Widget2 is not the same as the data shared by Widget2 and Widget3? Do you have two commons? Do you have one big common (and all widgets have to know about stuff they'll never need)? What happens when the application grows and a new widget Widget4 needs to share some of its data with Widget1 and Widget3?
As previously stated, as soon as you define an init function, the record it returns (or operates on) can no longer be type-parametrized (i.e. extensible), which means that if init returns the Common part, Common is no longer extensible. If Common is not extensible & you want to include Widget0 in a bigger application, Widget0's model will have to be completely independent from the other widgets' model at the same level, ie. it will not be able to share part of its model with the other widgets.
In fact, only the update & view functions can be type-parametrized to ensure the widgets don't have to know about one another:
update : Msg -> {a | common : Common, widget1 : Widget1.Internal} -> {a | common : Common, widget1 : Widget1.Internal}

With extensible records, you could apply the same pattern to any number of levels, but as soon as you put shared data in a common field you're basically preventing sharing something else (part of Common plus other fields) at the next level up the widget chain because Common can no longer be type-parametrized.
Sorry to ramble on about this, but it's been a thorn in my side for a long time now.
I would really appreciate any thoughts on this.

@Deimos28 My initial thoughts:

We try super hard to avoid the XY problem. So I would strongly recommend re-framing this in terms of the specific thing you're trying to build. "Widget1, Widget2, Widget3" doesn't give us an idea of the specific problem you actually ran into. I realize this requires giving extra context, but that context very often leads to a completely different answer. 😄
The right place to post this is definitely elm-discuss.

See you over there!

source: gharchive/issue

authors: Apanatshka Deimos28 Dobiasd TheSeamau5 ThomasWeiser Warry dnalot dobesv evancz jessitron jon49 laszlopandy mgold rgrempel rtfeldman

repo: elm-lang/elm-compiler


text:
Closing script tag in string causes data to be injected into the DOM

Quick Summary: If a string containing a </script> tag is passed to any function that causes the string to be inserted as-is into the JavaScript that Elm generates, the remainder of the Elm-generated code is injected into the DOM outside of a script context.
SSCCE
import Html exposing (text)

main =
  text "</script><script>alert(`This shouldnt be allowed`)</script>"

Output (line 4378):
var $author$project$Main$main = $elm$html$Html$text('</script><script>alert(`This shouldnt be allowed`)</script>');

Elm: 0.19.1
Browser: Mozilla Firefox 60.5.1esr (64-bit) and 71.0 (64-bit)
Operating System: Debian GNU/Linux 9 and Windows 10 Home Pro

Additional Details
This occurs because the browser's HTML parser runs before the JavaScript parser. The </script> tag closes the JavaScript context generated by the compiler. This doesn't seem to be a security issue unless the developer enters an untrusted string into Elm application code.
Another example of the behavior is if a developer calls Http.get and places the closing script tag in the URL value.
All of the following variations will reproduce the bug: </SCRIPT>, </script >, </script foo>
Probably the same bug referenced in issue #1780.
Proposed Fix Approaches

Escaping or filtering the tag would change the expected value of the string, which could lead to correctness issues.
If the JavaScript builder separates the tag in Elm into multiple JavaScript strings, this would preserve correctness. For example, the text from the SSCCE could be built into '</' + 'script><script>alert(`This shouldnt be allowed`)</' + 'script>');

HTML standard recommends escaping </script as <\/script, and also escaping <!-- as <\!-- and <script as <\script.
From 4.12.1.3 Restrictions for contents of script elements

The easiest and safest way to avoid the rather strange restrictions described in this section is to always escape "<!--" as "<!--", "<script" as "<\script", and "</script" as "</script" when these sequences appear in literals in scripts (e.g. in strings, regular expressions, or comments), and to avoid writing code that uses such constructs in expressions. Doing so avoids the pitfalls that the restrictions in this section are prone to triggering: namely, that, for historical reasons, parsing of script blocks in HTML is a strange and exotic practice that acts unintuitively in the face of these sequences.

Thanks @malaire. Per ECMAScript specifications (5, 6, 7), a CharacterEscapeSequence followed by a NonEscapeCharacter has a character value of the NonEscapeCharacter.  That means that the JavaScript interpreter interprets <\/script> as equivalent to </script>. I think that the best solution here is to escape forward slashes when parsing Elm string literals into JavaScript string literals. I've tested this approach and it produces the correct behavior for the SSCCE.

Thanks @malaire. Per ECMAScript specifications (5, 6, 7), a CharacterEscapeSequence followed by a NonEscapeCharacter has a character value of the NonEscapeCharacter. That means that the JavaScript interpreter treats '<\/script>' as strictly equal to '</script>'. I think that the best approach here is to have the parser escape forward slashes in Elm string literals. I've tested this approach and it produces the correct behavior for the SSCCE.

Oh, cool! <!-- <script> causes the closing script tag to be evaluated in a script context, provoking a SyntaxError so that the script never executes.
import Html exposing (text)

main =
  text "Consider this string: <!-- <script>"

authors: liamkirsh malaire

repo: elm/compiler


text:
error: invalid use of non-static member function ‘void legged::Ylo2HW::ImuCallback(const ConstPtr&)’

/home/ylo2/catkin_ws/src/ylo2_legged_control/legged_control/ylo2_legged_hw/src/ylo2hw.cpp: In member function ‘virtual bool legged::Ylo2HW::init(ros::NodeHandle&, ros::NodeHandle&)’:
/home/ylo2/catkin_ws/src/ylo2_legged_control/legged_control/ylo2_legged_hw/src/ylo2hw.cpp:36:68: error: invalid use of non-static member function ‘void legged::Ylo2HW::ImuCallback(const ConstPtr&)’
   36 |   ros::Subscriber sub = root_nh.subscribe("imu/data", 100, Ylo2HW::ImuCallback);
      |                                                            ~~~~~~~~^~~~~~~~~~~
In file included from /home/ylo2/catkin_ws/src/ylo2_legged_control/legged_control/ylo2_legged_hw/src/ylo2hw.cpp:7:
/home/ylo2/catkin_ws/src/ylo2_legged_control/legged_control/ylo2_legged_hw/include/ylo2_legged_hw/ylo2hw.h:56:8: note: declared here
   56 |   void ImuCallback(const sensor_msgs::Imu::ConstPtr& imu_message);

working.


text:
C binding namespace causes errors in leptos builds

Hi there,
Been trying to use this lib and found when installing it it caused all prog macros to panic. Turns out the C bindings clash with other name spaces (I think it's just the new method but could also be the others didn't look too deeply into it).
(I use leptos with SSR and axum)
I fixed it by doing this:
#[wasm_bindgen]
extern "C" {
	#[derive(Clone, Debug)]
	type QrScanner;

	#[wasm_bindgen(constructor, js_name = new)]
	fn qr_new(
		video_elem: &web_sys::HtmlVideoElement,
		callback: &js_sys::Function,
		options: &JsValue,
	) -> QrScanner;

	#[wasm_bindgen(method, js_name = start)]
	fn qr_start(this: &QrScanner);
	#[wasm_bindgen(method, js_name = stop)]
	fn qr_stop(this: &QrScanner);
	#[wasm_bindgen(method, js_name = destroy)]
	fn qr_destroy(this: &QrScanner);
}

Feels like a good work around and a good thing to do in general. I'm happy to submit a PR if you're keen on this.
Another thing I changed in my copy of this repo is co-locating both the js files within my own public folder as to not make a round trip to a CDN. Would be nice as an option perhaps but maybe this is a separate issue.

Feels like a good work around and a good thing to do in general. I'm happy to submit a PR if you're keen on this.
Another thing I changed in my copy of this repo is co-locating both the js files within my own public folder as to not make a round trip to a CDN. Would be nice as an option perhaps but maybe this is a separate issue.

Both are great improvements I'd love to merge PRs for, especially the CDN issue was annoying me too!

authors: dominikwilkowski elsirion

repo: elsirion/leptos-qr-scanner


text:
Able to redeem same offer multple times, need offer redemption state

I can keep "redeeming" offers until I manually reload the page.
Offers have been updated to use the minter to redeem. Since the minter runs every minute we need some sort of way to keep track of offer state while the minting process is going on. Without this the UI allows me to keep redeeming offers until both of the following criteria are met:

I reload the page
1 minute has passed to allow for the offer to mint

Here is a video example
https://user-images.githubusercontent.com/79117605/206329115-a75ab846-0d04-4805-883c-61e9b7d72636.mov

added to elv-apps-projects

repo: eluv-io/elv-live


text:
🎉: feat: add UnionEnum type with JSON schema enum usage

it('JSON schema', () => {
		expect(t.UnionEnum(['some', 'data'])).toMatchObject({
			type: 'string',
			enum: ['some', 'data']
		})
		expect(t.UnionEnum(['some', 1]).type).toBeUndefined()
		expect(t.UnionEnum([2, 1])).toMatchObject({
			type: 'number',
			enum: [2, 1]
		})
		expect(t.UnionEnum([null])).toMatchObject({
			type: 'null',
			enum: [null]
		})
})

Related - https://github.com/elysiajs/elysia/issues/512
JSON Schem 7 spec - https://json-schema.org/draft/2020-12/json-schema-validation#section-6.1.2
Docs - https://json-schema.org/understanding-json-schema/reference/enum

Great addition, I immediately wanted to use it, but it doesn't allow readonly input. Shall I open PR, @SaltyAom? :)

authors: BleedingDev kravetsone

repo: elysiajs/elysia


text:
Fix to Whisper Geth node issues

Fix issue where Whisper logs were printed twice because it had the same name as the blockchain, so the event to listen to process logs was registered twice. Just needed to change the name.
Fix Windows issue where the Whisper Geth node was conflicting with the main blockchain node over the IPC. Reason is that on Windows, the IPC link is made through a pipe file on disk. Changing that would mean to only change it on Windows, so it would be a pain. Instead, just putting ipcdisable in the Whisper node fixes it, and IPC is not really needed for Whisper anyway.

Fixed the commit message. Merging

repo: embark-framework/embark


text:
Replace auto-load with "loader" function

I think we should move away from having the tests "automagically" load; I'd like to see us move to something more explicit.
We should provide a "loader" function that consumers invoke from their test-helper.js file. This should allow us to remove the ready logic and the setTimeout while also providing an easy way for users to reason about how their tests get loaded. It would also make it easier to pass options to ember-cli-qunit without having to use the global QUnit.config object.
Thoughts?
Originally brought up here: https://github.com/ember-cli/ember-cli-qunit/pull/155#issuecomment-259609411

Yes, agreed.
We should move https://github.com/ember-cli/ember-cli-qunit/blob/master/vendor/ember-cli-qunit/test-loader.js#L24-L68 to our own addon-test-support directory (and rewrite to use normal import statements), then have consumers do something like this in thier test-helper.js:
import { TestLoader } from 'ember-cli-qunit/test-support';

TestLoader.load();

authors: rwjblue trentmwillis

repo: ember-cli/ember-cli-qunit


text:
What are the credentials for Keycloak?

I'm unable to proceed after clicking on "administration console" because I don't know the credentials. Can you please add them to the README?

Hi Matt,
Please review point 4, which covers environment configuration, in the deploy-the-poc section of the readme. There, you will see the column credential with the value admin / password

Thanks, @embesozzi!

authors: embesozzi mraible

repo: embesozzi/keycloak-openfga-workshop


text:
Updated description of NetworkName

The description now represents the real usage for the parameter. It is used when a storage platform is advertising a device to a networked host.  The networked host needs to a hint or name that it can use to properly discover the device being advertised.

Current coverage is 36.44%

Merging #14 into master will not affect coverage as of c5e85ec

@@            master     #14   diff @@
======================================
  Files            7       7
  Stmts          354     354
  Branches        12      12
  Methods          0       0
======================================
  Hit            129     129
  Partial         12      12
  Missed         213     213

Review entire Coverage Diff as of c5e85ec

Powered by Codecov. Updated on successful CI builds.

authors: akutz codecov-io

repo: emccode/libstorage


text:
Should there be a "SafeMessageSender" wrapper that would wrap an underlying Transport?

This would handle the task of thread safety and reconnects.
For example, sending could be simply posting to a BufferBlock which is consumed async from a single consumer, serializing access to the underlying transport but getting it off of the producing thread.
Options could be provided for retry counts, circuit breaker max failures (if the destination just can't be reached) and open time, etc.
This would be an opt-in wrapper. Could be included in the core package (would pull in a DataFlow dependency, though that is a System level package) or as a separate one.

It sounds like a custom implementation that a user of this library should implement himself according to his special needs.

authors: grubman rwkarg

repo: emertechie/SyslogNet


text:
Macos memory consumption issue

Describe the bug

When using the latest eframe, a very abnormal memory usage issue happens.
Resizes the main window can affect the program memory consumption in macos
When you maximize the window, it will take about 160MB.
When you shrink the size to 100 * 100, it will only take about 30-40MB.
To Reproduce
Steps to reproduce the behavior:

Create a hello world app by using only eframe
cargo run -r
Open activity monitor in macos
Resize your window to maximium
Check the hello world program in activity monitor, let's assume the memory usage is A.
Resize your window to about 100 * 100
Check the hello world program in activity monitor, let's assume the memory usage is B.
You will find out that A is way bigger than B.

Desktop (please complete the following information):

OS: MacOS 12.5.1 M2 chip

Is this real memory consumption or perhaps some artifact of mmap() usage?

@adamierymenko it seems to be a graphic memory usage, macos with integrated graphic card will count the cpu memory and gpu memory together in activity monitor.

authors: adamierymenko qdwang

repo: emilk/egui


text:
Merged with latest upstream

Closes https://github.com/emilk/egui/issues/THE_RELEVANT_ISSUE

sorry, wrong thing


text:
Issue with input

Input zoom in Drawer stop working
When we use noBodyStyles={true}

I have the same. It seems like noBodyStyles has no effect any longer. Can we please restore this functionality?

repo: emilkowalski/vaul


text:
TypeScript version of the kata

Hi Emily,
I recently run a TypeScript version of this kata so thought i would contribute it here.
Mark

Thankyou!

authors: braddle emilybache

repo: emilybache/TirePressure-Kata


text:
dependencies in package.json with "^"

hello.
we've just seen that your package json, also in released versions, does include the following dependencies:
"dependencies": {
"bluebird": "^3.4.1",
"lodash": "^4.13.0",
"mkdirp": "^0.5.1",
"mongodb": "^2.2.1",
"nomnom": "^1.6.2"
}
the usage of "^" leads to the fact that installing the "released" mongodb-migrations module installs potential changed submodules.
In our case, the used implementation of mongodb (2.2.19) seems to be incompatible with mongodb-migrations 0.5.2.
is that a desirable behaviour?
there are possibilities like npm shrinkwrap or just using static versions which would prevent such problems.

Semver is specifically designed to not use the static versions.
Using carets is the common practice advised by npm and it's the default behavior with npm install.
You would see this in almost any npm package.
Of course it assumes that the library authors do follow the semver principles. In particular that means that patch changes (like from mongo 2.2.1 to 2.2.19) should never change the API, and minor changes (from 2.0.0 which is the dependency of 0.5.2 to the modern 2.2) should only add the new APIs in backward-compatible way.
I've just ran the tests with the mongodb module 2.2.16 and 2.2.19, passed in both cases with the current master which is 0.8.3.
I've also checked 0.5.2 with mongodb 2.2.19 and it passes the tests suite too.
But 0.5.2 is an old version and it can obviously have bugs fixed in the later versions.
I don't have resources to provide support for older 0.x versions, so upgrading to the newest version is strongly advised.
Shrinkwrapping is a good idea regardless though, will implement it later together with yarn.lock.

Thanks for information.
I totally agree with you about that. I was just not sure if this is a desired handling.
I've had too many problems with using caret for everything that is "productive" for me, because of exactly such issues with external packages.
I'll check if upgrading mongodb-migration itself is fixing the problems.
Br

Closing it unless more specific issue is reported.

I've reproduced the problem in an indenpendet environment:
windows 10 prof.
npm --version: 3.10.6
node --version: v5.7.0
package.json
{   "name": "test-mongodb-migrations",   "version": "1.0.0",   "description": "",   "main": "index.js",   "scripts": {     "test": "echo \"Error: no test specified\" && exit 1"   },   "author": "",   "license": "ISC",   "dependencies": {     "mongodb-migrations": "^0.8.4",     "mongoose": "4.0.8"   } }
index.js
`var mm = require('mongodb-migrations');
var mongoose = require("mongoose");
function execute() {
var migrator = new mm.Migrator({
host: 'localhost',
port: '27017',
db: 'db,
collection: '_migrations',
poolSize: 5
});
}
execute();`
this seems to be a incompatibility between the mongodb versions used by mongoose@4.0.8 and most current version of mongodb-migrations.
This is just an information for others, I'll fix this on my side.

Interesting, thanks for reporting!
I'll try to repro and see what specifically is an issue.

Because in case of incompatible versions npm should just install the 2 copies of the package and no conflict should occur.

This is what i would expect either.

@emirotin yarn and the new npm@5 solve this using lock files.
I'd close this issue.

authors: amongouser emirotin pszabo1

repo: emirotin/mongodb-migrations


text:
Test suite should block non-locally-built images

The integrations tests need backend services to test with; mostly this role is filled by kat-server, but there are a few other stand-alone images in docker/test-*/.  Those are fine.  But there are also a handful of backends that are entirely 3rd-party... those are a problem.
Take an example:
I was looking at the KAT tests today, and saw this bit of YAML getting applied:
    image: docker.io/johnesmet/go-websocket-echo-server:latest

This isn't to pick on John in particular, there have been other images like this from Cynthia and even from Flynn; it's just that the one I came across today happens to be from him.
This image is a problem for several reasons:

It's not clear where the source code is; this amounts to a part of the test suite that can't be edited.
It's an opportunity for someone outside of the Emissary org to break our CI (not that I think John or anyone else would intentionally break it)
If John is compromised, the image could be changed to compromise embargoed secrets.

We've been counting on code review to make sure that all images we use are sourced from emissary.git; clearly this isn't working. It's too easy for a contributor to hack together an image, mean to clean that up later, and then it gets merged. We should set up policies in test clusters to disallow pulling images from registries other than the registry that the test pushes its locally built images to.

This may dovetail with @kflynn's work on not having CI require registry credentials.

repo: emissary-ingress/emissary


text:
chore: updating README.md, adding tests, updating to go 1.23.3 and fixing bugs

…xing some bugs

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Flag
Coverage Δ

unittests
100.00% <100.00%> (+100.00%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines
Coverage Δ

main.go
100.00% <100.00%> (+100.00%)
:arrow_up:

authors: codecov-commenter emmesbef

repo: emmesbef/go-graceful


text:
Package with project code is not added to PYTHONPATH if it is run from package

Thanks for a great project. I am currently testing the available ASGI servers and I found that granian behaves differently than other ASGI servers. I have no idea if this is correct because the directory structure of my application is a bit non-standard, but I'll describe it here anyway, maybe it will help someone.
My use-case is as follows: My project has the following stucture: C:\project_root\tests\django_test_application, where:

tests is a package (contains __init__.py)
django_test_application is also a package (contains __init__.py) and under that is asgi.py which I want to run
the code in django_test_application doesn't know that it is part of the tests package. So it uses the imports: from django_test_application.foo import bar.
From the C:\project_root\tests\ directory, I then run the individual ASGI servers and test if my application works correctly with them.

But under granian my application crashes on ModuleNotFoundError: no module named 'django_test_application'. I think it's because the prepare_import function (https://github.com/emmett-framework/granian/blob/master/granian/_internal.py#L13-L35) doesn't add django_test_application to PYTHONPATH when it's part of a package. I've prepared a minimal working project here that demonstrates the described problem: https://github.com/illagrenan/granian-app-in-package.
I tested uvicorn, hypercorn and daphne and they add the package django_test_application to PYTHONPATH.
A little background on why my project is structured this way: I'm writing a package that adds ASGI lifespan protocol support for Django. I'd like to have all the major ASGI servers running as part of the integration tests to make sure my code is compatible with all of them.

Hi @illagrenan, thank you for reporting this.
Would you be able to run Granian using the Python interface? If so, you can define a custom loader:
import importlib

def target_loader(target: str):
    mods, _, attrs = target.partition(":")
    instance = importlib.import_module(mods)
    for attr in attrs.split("."):
        instance = getattr(instance, attr)
    return instance

and pass it to the Granian.serve method.
I'm not able to test the upper code immediately: if you manage to, then I'll be happy to publish a patch revision of granian with the loader upgraded.

Sorry for the late reply. I can confirm that the latest version https://github.com/emmett-framework/granian/releases/tag/v1.1.1 works perfectly. 🚀  Thanks a lot for the great work!

repo: emmett-framework/granian


text:
typescript typings

This allows people to seamlessly access the library from TypeScript.

I believe the CI build failure is related to a dependency of coveralls using versioning syntax unsupported by npm 1.2.30. I think it's the "delayed-stream": "~1.0.0" in combined-stream's package.json.

Can this be accepted anyway?

sorry, didn't notice this.

add this feature in v0.3.0

authors: JasonKleban emn178 rapropos


text:
Subfolders for playlists

I really love in DeliPlayer that you can put tracks into subfolders. This is also used when you scan folders with subdirectories which are then reflected in the resulting playlist, makes dealing with huge playlists much more convenient.

How do you mean put tracks into subfolders? Is these virtual subfolders (i.e doesn't exist on disk) more like a structure within a playlist?

Exactly! Virtual tree style folders, like seen in this shot (even featuring subfolders for recognized sub tracks)

Cool. Yeah I have thought about having sub songs as "sub tree" to the main song. This is something that will behave similar when zip support and similar things is added is my plan.

authors: emoon knochenhans

repo: emoon/HippoPlayer


text:
Support multiple ordered lists

Set different numId to each ordered list paragraph to avoid continuous numbering

It was an attempt to change target branch to show less changes in PR

repo: empoweredsystems/wordinator


text:
Add more parameters for acl

add new parameters for acl request

Server listen port
Peer name and port
Mount path for pub/sub

We will support it in version 3.2.

Thank you for your participation, already supported in the latest version, I will close this issue.

authors: funwun turtleDeng

repo: emqx/emqx-auth-http


text:
option-parser: add webpackExtraResolvePaths

This will be used in webpack config to allow the user to supply additional
paths to the resolve.modules section, allowing for users to specify their
source or other paths, and use them with paths relative to the source
root instead of '../../..' etc.
Enact-DCO-1.0-Signed-off-by: Eric Blade blade.eric@gmail.com

Closing this in favor of #86.

authors: MikyungKim ericblade

repo: enactjs/dev-utils


text:
Fix compile error

❯ cargo build
   Compiling lldb-sys v0.0.19
   Compiling lldb v0.0.7 (file:///home/hugh/tmp/lldb.rs)
error[E0433]: failed to resolve. Use of undeclared type or module `SBCommandInterpreter`
   --> src/debugger.rs:181:9
    |
181 |         SBCommandInterpreter::wrap(unsafe { sys::SBDebuggerGetCommandInterpreter(self.raw) })
    |         ^^^^^^^^^^^^^^^^^^^^ Use of undeclared type or module `SBCommandInterpreter`

error[E0412]: cannot find type `SBCommandInterpreter` in this scope
   --> src/debugger.rs:180:42
    |
180 |     pub fn command_interpreter(&self) -> SBCommandInterpreter {
    |                                          ^^^^^^^^^^^^^^^^^^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
    |
7   | use commandinterpreter::SBCommandInterpreter;
    |

error: aborting due to 2 previous errors

Some errors occurred: E0412, E0433.
For more information about an error, try `rustc --explain E0412`.
error: Could not compile `lldb`.

To learn more, run the command again with --verbose.

That's embarassing. Thanks!

authors: hghwng waywardmonkeys


text:
added front corner assembly for left y belt

Added an STL in Stage 1 for a belt tensioner for the left y-belt
issue mentioned: https://github.com/endorphin3d/endorphin/issues/9

Works great!

Added an STL in Stage 1 for a belt tensioner for the left y-belt
issue mentioned: #9

Works great!

authors: NaServas SirNukalot


text:
Unable to build Data Custodian using maven CLI

Attempting to build the Data Custodian using the following maven CLI format produces a failed build:
mvn clean -Dmaven.test.skip=true package

Results in the following build error and subsequent failure:
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building DataCustodian 1.3-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for org.energyos:Common:jar:1.3-SNAPSHOT is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.164s
[INFO] Finished at: Thu Oct 29 11:27:22 EDT 2015
[INFO] Final Memory: 9M/59M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project DataCustodian: Could not resolve dependencies for project org.energyos:DataCustodian:war:1.3-SNAPSHOT: Failure to find org.energyos:Common:jar:1.3-SNAPSHOT in http://maven.springframework.org/release was cached in the local repository, resolution will not be reattempted until the update interval of spring-maven-release has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1]         http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

No longer occurring

repo: energyos/OpenESPI-DataCustodian-java


text:
Poop always moves.

I can't stop the poop. It's always moving.

@wadek2 you might want to ask your doctor about this.


text:
Soak testing

Fixes #N/A
Description
How was this change tested?
Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build 6869278055
Warning: This coverage report may be inaccurate.
We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 79.297%

Files with Coverage Reduction
New Missed Lines
%

pkg/providers/amifamily/ami.go
1
89.78%

Totals

Change from base Build 6869271467:
-0.01%

Covered Lines:
5711

Relevant Lines:
7202

💛  - Coveralls

authors: coveralls engedaam

repo: engedaam/karpenter


text:
Use yo-yo instead of HBS

Convert to using yo-yo instead of handlebars.

Converted to yo-yo, but seems like rendering new components is really expensive.
Might try with react instead and see if I get better perf. Otherwise will just use template strings and set innerHTML, then never re-render and just update components like before.

Made a custom dom helper and dropped yo-yo, it was just too slow.

repo: englercj/phaser-debug


text:
init(coder) must be failable

init(coder) is failable in the superclass, so it must be failable in this class

still have the error, any solution?

repo: enisgayretli/EGFloatingTextField


text:
Added functionality for deep freeze in SOD

Added option for glowing action button in season of discovery

In case you're curious about what I meant by default settings, there you go: ef40c991f248dc8cc02b99e2ad1497085af4cdfc

In case you're curious about what I meant by default settings, there you go: ef40c99

Ah! i missed that :)

authors: ennvina steijner

repo: ennvina/spellactivationoverlay


text:
Release 1.14.0

Release checklist:

[x] Create a new Release Issue

[x] Replace 1.13.0 with the former release, and 1.14.0 with THIS

[x] Update the Roadmap calling out shipped features
[x] Create and update a Milestone for the release

[x] Assign this task
[x] Assign all the shipped roadmap Issues
[x] Assign the relevant recently closed Isssues

Code changes:

[x] Create a release branch 'release-x.y.z': git checkout -b release-1.14.0
[x] Create a temporary tag git tag v1.14.0 && git push opensource --tags
[x] Create a New Draft GitHub Release, and generate the automated changelog (for new contributors)
[x] Update the release version in package.json, and npm i
[x] Update in-app News src/apps/news/news.data.tsx
[x] Update the in-app News version number
[x] Update the README.md with the new release
[x] Copy the highlights to the docs/changelog.md

Release:

[x] merge onto main git checkout main && git merge --no-ff release-1.14.0
[x] re-tag git tag -f v1.14.0 && git push opensource --tags -f
[ ] verify deployment on Vercel
[ ] verify container on GitHub Packages
[ ] update the GitHub release
[ ] push as stable git push opensource main:main-stable

Announce:

[ ] Discord announcement
[ ] Twitter announcement

Links

Milestone: https://github.com/enricoros/big-AGI/milestone/14
GitHub release: https://github.com/enricoros/big-AGI/releases/tag/v1.14.0
Former release task: #405

Artifacts Generation
You help me generate the following collateral for the new release of my opensource application called big-AGI. The new release is 1.14.0.
To familiarize yourself with the application, the following are the Website and the GitHub README.md.

paste the URL: https://big-agi.com
drag & drop: README.md

I am announcing a new version, 1.14.0.
For reference, the following was the collateral for 1.13.0 (Discord announcement, GitHub Release, in-app-news file news.data.tsx).

paste the former: discord announcement,
GitHub release,
news.data.tsx,
changelog.md

The following are the new developments for 1.14.0:

- ...
- git log --pretty=format:"%h %an %B" v1.13.0..v1.14.0 | clip

paste the link to the milestone (closed) and each individual issue (content will be downloaded)
paste the output of the git log command

news.data.tsx
I need the following from you:

1. a table summarizing all the new features in 1.14.0 with the following columns: 4 words description (exactly what it is), short description, usefulness (what it does for the user), significance, link to the issue number (not the commit)), which will be used for the artifacts later
2. then double-check the git log to see if there are any features of significance that are not in the table
3. then score each feature in terms of importance for users (1-10), relative impact of the feature (1-10, where 10 applies to the broadest user base), and novelty and uniqueness (1-10, where 10 is truly unique and novel from what exists already)
4. then improve the table, in decreasing order of importance for features, fixing any detail that's missing, in particular check if there are commits of significance from a user or developer point of view, which are not contained in the table
5. then I want you then to update the news.data.tsx for the new release

Readme (and Changelog)
I need you to update the README.md and the with the new release.
Attaching the in-app news, with my language for you to improve on, but keep the tone.

GitHub release
Please create the 1.14.0 Release Notes for GitHub, following the format of the 1.13.0 GitHub release notes attached before.
Use a truthful and honest tone, understanding that people's time and attention span is short.
Today is 2024-XXXX-YYYY.

Now paste-attachment the former release notes (or 1.5.0, which was accurate and great), including the new contributors and
some stats (# of commits, etc.), and roll it for the new release.
Discord announcement
Can you generate my 1.14.0 big-AGI discord announcement from the GitHub Release announcement?
Please keep the formatting and style of the discord announcement for 1.13.0, but with the new messaging above.

Partial Release Notes:

Gemini: support for 1.5 models, and the new list format
Improved search and folder experience

Screenshots
Improve Latex rendering:

news.data.tsx
{
versionCode: '1.14.0',
versionName: 'Modelmorphic',
versionCoverImage: coverV114,
versionDate: new Date('2024-03-06T08:00:00Z'),
items: [
{ text: <>Perplexity support, including Online models</>, issue: 407, icon: PerplexityIcon },
{ text: <>Groq support, with speeds up to 500 tok/s</>, issue: 427, icon: GroqIcon },
{ text: <>Support for new Mistral-Large models</>, icon: MistralIcon },
{ text: <>Support for Google Gemini 1.5 models and various improvements</>, icon: GoogleIcon as any },
{ text: <>Deeper LocalAI integration including support for model galleries</>, icon: LocalAIIcon },
{ text: <>Major performance optimizations: runs faster, saves power, saves memory</> },
{ text: <>Improvements: auto-size charts, search and folder experience</> },
{ text: <>Perfect chat scaling, with rapid keyboard shortcuts</> },
{ text: <>Also: diagrams auto-resize, open code with StackBlitz and JSFiddle, quick model visibility toggle, open links externally, docs on the web</> },
{ text: <>Fixes: standalone LaTeX blocks, close views by dragging, knowledge cutoff dates, crashes on Google translate (thanks dad)</> },
],
},

README.md
What's New in 1.14.0 · March 6, 2024 · Modelmorphic

New Perplexity and Groq integration (thanks @Penagwin). #407, #427
LocalAI deep integration, including support for model galleries
Mistral Large and Google Gemini 1.5 support
Performance optimizations: runs much faster, saves lots of power, reduces memory usage
Enhanced UX with auto-sizing charts, refined search and folder functionalities, perfected scaling
And with more UI improvements, documentation, bug fixes (20 tickets), and developer enhancements
Release notes, and changes v1.13.1...v1.14.0 (233 commits, 8,000+ lines changed)

GitHub release:
🚀 big-AGI 1.14.0 - Modelmorphic
The new shape of intelligence and performance.
We're releasing big-AGI 1.14.0, "Modelmorphic." This update expands models support, focuses on improving performance, and delivers user experience enhancements. With over 230 commits and over 8,000 lines of code changed, it's designed to make big-AGI smarter, faster, more reliable.

Added support for Perplexity, including Sonar Online models, and Groq, including models with up to 500 tok/s speeds. Contribution by @Penagwin.
Added Mistral Large models, and Google Gemini 1.5 models.
Deeper LocalAI integration with support for model galleries and keys.
Performance Optimizations: comprehensive improvements for faster operation, lower power consumption, and better memory use
UI and Usability: updated navigation, search, scaling, shortcuts, and chat interactions for a smoother experience.
Addressed issues with image warnings, standalone LaTeX blocks, hidden personas in the selector, and more.

For Developers:

Customizable PlantUML Server via an environment variable, thanks to @fredliubojin.
New customization documentation and analytics support are now included.
Added /info/debug for better diagnostics.
Introduced a "controller-based" chat architecture to simplify per-chat data management, including ephemerals.
Full changelog: https://github.com/enricoros/big-AGI/compare/v1.13.1...v1.14.0

New Contributors
Special thanks to our new contributors @Penagwin and @jacksongoode. @Penagwin work has been instrumental for making this release a success.
In Summary
Version 1.14.0 - Modelmorphic represents a leap forward in our commitment to providing advanced, reliable, and user-centric AI tools. We continue to eschew fluff in favor of substance, focusing on what truly matters to our users and developers.
Explore the new features and improvements and upgrade to Modelmorphic today, available via code, Docker, or directly on big-agi.com.
Join our AGI community on Discord and get involved with us! Your feedback and contributions are what drive us forward. And now enjoy Modelmorphic 🚀

Discord Announcement
@everyone :sparkles: big-AGI 1.14.0 - Modelmorphic Launched
:partyblob~1: The new era of AI performance & integration. :partyblob~1:
"Modelmorphic" turbocharges big-AGI with enhanced model support, performance leaps, and UX refinements. Over 230 commits and 8,000 lines of code have shaped this release.

Perplexity & Groq models now onboard, thanks to @Penagwin's brilliance. Experience online llms and up to 500 tok/s speeds!
Mistral Large and Gemini 1.5 models are here
LocalAI digs deeper with model galleries and key integrations
Performance Optimizations: We've cranked up the efficiency dial - expect lightning-fast operations, minimal power usage, and optimized memory
UI/UX Polish: Navigating, searching, scaling, and chatting just got smoother and more intuitive
Fixes Galore: From image warnings to LaTeX quirks, we've ironed out the creases for a seamless experience

For the Tech-Savvy:

Say hello to customizable PlantUML Servers (hat tip to @fredliubojin).
Dive into our fresh customization docs and analytics support.
Debug with ease using /info/debug.
Embrace our new "controller-based" chat architecture for streamlined data management.

:rocket: Enjoy Modelmorphic - available on https://get.big-agi.com, and on Docker, on GitHub, and you know the drill - and our little fella also does! :rocket:

repo: enricoros/big-AGI


text:
Bugs in GUI2

This task gather all remaining issues which prevent us for signing-off GUI1 removal.
### Tasks
- [x] When clicking at nested selector, two are opened at once (Picture 1). Addressed by #8749
- [x] Sometimes when dropping connection, it's connected to last used selection. Addressed by #8749
- [ ] https://github.com/enso-org/enso/issues/8822
- [x] Fullscreen visualizations has areas where mouse is not visible (@farmaazon)
- [x] Reconnecting: highlight does not say which endpoint will be disconnected (@farmaazon)
- [x] Reconnecting: dropping edge with disconnected source does not work (it should disconnect, but it reverts) (@farmaazon)
- [ ] https://github.com/enso-org/enso/issues/8854
- [ ] https://github.com/enso-org/enso/issues/8756
- [ ] https://github.com/enso-org/enso/issues/8534
- [ ] https://github.com/enso-org/enso/issues/8810
- [x] create `Table.at` node and set index - the placeholders are broken (Picture 3) - @farmaazon - not reproducible anymore
- [x] Soft wrap of the documentation in CB sometimes does not work (Picture 3) (@vitvakatu)
- [ ] https://github.com/enso-org/enso/issues/8884
- [ ] https://github.com/enso-org/enso/issues/8684
- [ ] https://github.com/enso-org/enso/issues/8799
- [ ] https://github.com/enso-org/enso/issues/8801
- [ ] https://github.com/enso-org/enso/issues/8899
- [ ] https://github.com/enso-org/enso/issues/8932
- [ ] CB Preview is evaluating too many things at a time (no canceling of previous evaluation).
- [x] Boolean values should not show a dropdown, only a "dot" widget. - moved to #8962
- [x] Boolean widget should insert "True" and "False", not "Boolean.True" - moved to #8962
- [x] Replace documentation button with "edit" icon that starts editing the node - already part of #8612
- [ ] https://github.com/enso-org/enso/issues/8963
- [x] Minor: new node is created over opened visualization
- [ ] https://github.com/enso-org/enso/issues/8964
- [x] Sometimes, when node is updated while edited in CB, the CB change is discarded

re: multiple "you may be a victim of scam" messages
this is intentional, otherwise it's possible that it's scrolled out of view by the time the user opens the console. it's true that usually this shouldn't happen because currently no real logging happens, but i think it's better to be on the safe side

repo: enso-org/enso


text:
constraint failed: one of [x] is already connected to a different y but it's the same ID

Current Behavior 😯
I'm encountering this strange issue:
query=UPDATE "players" SET "team_player" = $1 WHERE "id" = $2 AND "team_player" IS NULL args=[6 11]

error="ent: constraint failed: one of [11] is already connected to a different team_player"

the "different team_player" is the same, but it doesn't understand it.
I think this is a bug.
Expected Behavior 🤔
It recognizes is the same ID.
Steps to Reproduce 🕹
I don't have time right now. :sad:
Your Environment 🌎

Tech
Version

Go
1.18.3

Ent
entgo.io/contrib v0.2.1-0.20220623093601-df0921394080, entgo.io/ent v0.10.2-0.20220622152053-3bb5292c83bf

Database
PG

Driver
pgx

Hey @frederikhors and thanks for opening this issue.
This is the expected behavior and not a bug. Unlike Set, you can't Add an edge multiple times, even if it's connected to the same node. We treat it as a duplicate edge and therefore calling Add with the same values fails as duplicate edges are not allowed (they may contain metadata with different values). This behavior is the same for all non-unique edge types (O2M, M2M).
In case users want to override all edges in each Update, they can call: ClearE().AddE(...).

Worth mentioning a few words about the implementation of the example above:
When adding a one-2-many edge, the generated statement looks as follows:
UPDATE child_table SET parent_id=parent_id WHERE id IN (child_ids...) AND parent_id IS NULL

This way, we ensure destination nodes are not connected to other nodes under the same edge type. The only way to check if the operations succeed is to compare affected_rows == child_ids. In case it's not, we know that one of the destination nodes is already connected with this edge and we fail (we don't know which one). This way, we can ensure the behavior expected above without loading the records or executing additional queries to the database.
Closing as there's no action item here and this behavior is not going to change. Thanks and I hope it helps.

repo: ent/ent


text:
Add disallowed package external references rule

The purpose of this is to ban packages that have an externalReference in their cyclonedx sbom that match some regex in the policy rule data.
This is meant to be useful in particular in conjunction with the oci-copy task. That task permits copying arbitrary binary content for the purposes of distributing it via an OCI registry. It is not safe in general. Policies should generally forbid it, and not treat it as a trusted task.
In scenarios where it is deemed permissible, the task should be trusted, but only if this rule is also in place which will put limits on what artifacts can be redistributed.
Ref: https://issues.redhat.com/browse/EC-676

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (718386d) to head (02252ba).

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1060   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          111       111
  Lines         5397      5411   +14
=========================================
+ Hits          5397      5411   +14

Files
Coverage Δ

policy/release/sbom_cyclonedx.rego
100.00% <100.00%> (ø)

policy/release/sbom_cyclonedx_test.rego
100.00% <100.00%> (ø)

A bit late to the conversation, but is a denylist the way to go?

That task permits copying arbitrary binary content

only if this rule is also in place which will put limits on what artifacts can be redistributed.

If we ban a few urls, it will still be mostly arbitrary content

Yes, we usually do allow-lists as a preference, it is not a hard stance I think
@chmeliik would you prefer an allow-list instead? WDYT @ralphbean?

Yes, we usually do allow-lists as a preference, it is not a hard stance I think
@chmeliik would you prefer an allow-list instead? WDYT @ralphbean?

Yeah, that would make more sense to me

authors: chmeliik codecov-commenter ralphbean zregvart

repo: enterprise-contract/ec-policies


text:
Documentation

Check with Chris on his standard on SDAfile.  Spinx and presentation of final tests.

Hi all. I used Sphinx for the SDA project. The SDA documentation source is here. To get started, you can copy this directory and change the relevant information. Besides the docs, you'll need to modify the metadata in the make files and conf.py.
You may also want to start from scratch using sphinx. There is a command-line tool available with sphinx (sphinx-quickstart) that will build the documentation scaffolding for you. Once you know it, this is easier and faster than copying the directory and modifying it. Either way, you'll want to read a bit of the sphinx documentation to get the most out of it.

repo: enthought/sandia-blusky


text:
build: update envoy and disable h3 (for now)

Description: Adds new upstream flag for temporarily disabling HTTP/3.
Risk Level: Low
Testing: Local and CI
Signed-off-by: Mike Schore mike.schore@gmail.com

@junr03 since you have https://github.com/envoyproxy/envoy-mobile/pull/1325

There's a quiche bug in the current upstream dependency (https://envoyproxy.slack.com/archives/C9UGU858E/p1617048013001500), but it's being updated.

quiche dependency fix is merged, now waiting on this PR I opened upstream with a couple more fixes: https://github.com/envoyproxy/envoy/pull/15751

repo: envoyproxy/envoy-mobile


text:
Question: file upload support of envoy.filters.http.grpc_json_transcoder

i have concluded with a simple POC i did, that envoy.filters.http.grpc_json_transcoder extension does not support file uploads. I am talking about files like images or tar files . For example support for
curl -F "data=@/home/transcodingEnvoy/dummytarfile" http://127.0.0.1:5000/savebulk/
I would be grateful if you could confirm this to me

cc. @qiwzhang @nareddyt

No, file upload like this is not supported by the filter or gRPC itself.
If your gRPC backend needs to handle file upload, you would do something like this: https://stackoverflow.com/a/47385602/4402434
Then based on the transcoder configuration, you can send client-streaming HTTP requests with the metadata+data in the request body. Something simple like curl -F data=@file.targz will not work.

authors: dio nareddyt sotirisk

repo: envoyproxy/envoy


text:
May the metrics upstream_cx_total decrease

I'm reading the official doc: https://www.envoyproxy.io/docs/envoy/latest/configuration/upstream/cluster_manager/cluster_stats, and I find that upstream_cx_total means "Total connections".
I'm kind of confused by this description.
So it counts the number of all of connections since Envoy is started (case A)? Or it counts the number of connections real time (case B)?
For case A, upstream_cx_total will never decrease, whereas for case B, upstream_cx_total could decrease.
I'm trying to figure it out because I can't understand when the health check mechanism uses no_traffic interval.
I found the source code of health check:
std::chrono::milliseconds HealthCheckerImplBase::interval(HealthState state,
                                                          HealthTransition changed_state) const {
  // See if the cluster has ever made a connection. If not, we use a much slower interval to keep
  // the host info relatively up to date in case we suddenly start sending traffic to this cluster.
  // In general host updates are rare and this should greatly smooth out needless health checking.
  // If a connection has been established, we choose an interval based on the host's health. Please
  // refer to the HealthCheck API documentation for more details.
  uint64_t base_time_ms;
  if (cluster_.info()->trafficStats()->upstream_cx_total_.used()) {
    // interval
  } else {
    // no_traffic interval
  }

If the case A is applied, it means no_traffic interval won't be used anymore once a request is routed to the endpoint. Buf if the case B is applied, it means health check will use no_traffic interval as long as upstream_cx_total become 0.

Right, upstream_cx_total will always increase as a counter, and I don't find it is latched anywhere. So case A is right, and you are right for health check no_traffic interval.

authors: YvesZHI botengyao


text:
Document is inconsistent with code, bazel.dev use clang instead of gcc

Description:
Document is inconsistent with code
in ci/README file,

bazel.dev — build Envoy static binary and run tests under -c fastbuild with gcc.

but in do_ci.sh
elif [[ "$1" == "bazel.dev" ]]; then
  setup_clang_toolchain

@hello-ming PR appreciated.


text:
build: update bazel to 3.4.1

Note that Bazel's toolchain for 3.4.1 is tagged 3.4.0: https://github.com/bazelbuild/bazel-toolchains/releases/tag/3.4.0
Signed-off-by: Michael Rebello me@michaelrebello.com
Risk Level: Medium
Testing: CI
Docs Changes: N/A
Release Notes: N/A

The Windows failure looks legit. @wrowe @sunjayBhatia thoughts?

@htuch envoy-build-tools would need to have a toolchain generated and committed for bazel 3.4.x, we can’t do docker in docker on windows so generating a toolchain on the fly doesn’t work

See: https://github.com/envoyproxy/envoy-build-tools/blob/923df85a4ba7f30dcd0cb6b0c6d8d604f0e20f48/toolchains/regenerate.sh#L41

Updating there: https://github.com/envoyproxy/envoy-build-tools/pull/85

authors: htuch rebello95 sunjayBhatia


text:
[WIP] python: Set line length to 80 chars

Signed-off-by: Ryan Northey ryan@synca.io
Commit Message: python: Set line length to 80 chars
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]

I will defer to @htuch and you to sort this out, but it's 2021, do we really need to do 80? Can we do 100 like the C++ code? That would be my preference. :)

it's 2021, do we really need to do 80?

80 is the standard - perhaps originally from a legacy of low resolution consoles - but i think adopted in python more to discourage overly-nested code
i vote 80, but happy to keep/implement/go with the consensus
i raised this pr mostly to get the autoformat fixes and see what it would do

also even if we do go with this change, i would like to finish other linting issues first

@phlax my vote would be to go with 100 for consistency with C++; this is basically an opinionated decision Envoy has made that is inconsistent with everyone else anyway.
I'd be persuaded otherwise if there are implications of not doing 80 in terms of tooling or IDEs.
It's not a hill I'm going to die on though :)

closing as it seems the consensus is to keep the 100 limit

authors: htuch mattklein123 phlax


text:
Fix bazel analysis errors across Envoy WORKSPACE

Commit Message: Fix bazel analysis errors across Envoy WORKSPACE
Additional Description:
There does not appear to be a :lightstep_tracer target, but rather a
:manual_tracer_lib target. I confirmed that with this change analysis
passes and the binary builds.
The //docs/... subtree requires python3.10 to build. On systems (such
as Debian) where multiple versions of python can be co-installed,
bazel auto-detection may (and empirically, does) pick an older
version, producing analysis errors.
This change explicitly selects the python3.10 toolchain, causing
analysis and later builds of //docs/... to succeed.
Risk Level: Low
Testing: bazel build -k ...
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

I expected to get some CI failures, but that's not the one I was expecting :)
"ERROR: @com_googlesource_googleurl//build_config:system_icu :: Error loading option @com_googlesource_googleurl//build_config:system_icu: no such package '@base_pip3//': python interpreter None not found in PATH"

It seems the CodeQL build is using Ubuntu focal (20.04LTS), but python3.10 is not available until impish (21.04), but realistically we probably want jammy (22.04LTS).
It is a bit unfortunate we have picked up a python3.10 dependency but don't have python3.10 available in CI.
I see a few options:

Upgrade the CI system to a base OS that has python3.10 available
Switch to a hermetic python3 toolchain, e.g., using py_download from rules_py_simple and python-build-standalone
Use select() to pick the Python toolchain, falling back to whatever is present if python3.10 is not available. This has the downside that python3.9 and older will not be able to build //docs/..., including the CI system.

hi @achernya i already have an open PR to use the new python toolchains here #20432 - i think this PR - at least the python parts are unncessary
there were a few wrinkles that needed to be ironed out to make it work - but it now does, with one exception - the windows thrift test
cc @wrowe it would be really good to resolve the python toolchains issue as it is a source of developer pain/confusion and provides quite a few benefits besides. Can we disable the failing test for now to land the toolchains PR ?

Hi @phlax thanks for your review. I looked at #20432 and I agree that using python_register_toolchains is superior to the alternatives I had proposed above (and I feel silly for having missed that in the rules_python documentation yesterday). I'll drop the python bits from this PR and just focus on the fix lightstep.

@phlax PTAL I removed the python3.10 bits from this PR.

authors: achernya phlax


text:
datadog: event scheduling portion of new tracing library

This is part of the initiative described in https://github.com/envoyproxy/envoy/pull/23958.
This revision introduces a new library dependency for Datadog tracing, and adds a component that will be used in the future when more of the new library is integrated into the Datadog tracing extension.
EventScheduler allows the new tracing library to schedule a recurring timer that fires every two seconds; this is when the tracing library will send its batched traces to the Datadog Agent.

The dependency changes are in multiple PRs - https://github.com/envoyproxy/envoy/pull/25121/files#diff-a2ca502474bb8ec5f092176f7ee6d2f11fc395ebb00e1717d6fbad9b16ee8fd8
Is this intentional?

Yes, it's intentional. In retrospect, it might have been better to first add only the dependency changes, wait for those changes to be merged into main, and then propose the lowest level of new code.
I wanted instead to propose the first round of pull requests ASAP, and so duplicated the shared added dependency in all of those lowest level PRs.
I could create a dedicated dependency PR and rebase the others onto it, if you like.

ping myself, sorry for the delay. 😞

Thanks for the review. I'll push a commit and merge from main within the next couple of days.

/wait

Code coverage for source/extensions/tracers/datadog is lower than limit of 96.6 (96.5)

Hmmm. Looks like calling config_json in a test might help: https://storage.googleapis.com/envoy-pr/0f305a0/coverage/source/extensions/tracers/datadog/event_scheduler.cc.gcov.html
Also interesting in the logger, which was recently merged, I'd except these kinds of tests: https://github.com/envoyproxy/envoy/pull/25025/files#diff-ab9f820e99ec92b52dd7334d825976ab5b5e2240dc9693e58fd4c99fab4c7dddR96-R103
to cover these kinds of branches: https://storage.googleapis.com/envoy-pr/9763eb9/coverage/source/extensions/tracers/datadog/logger.cc.gcov.html
but they don't.
I'll have to look closer.

Ping @jmarantz

Thanks!
Another week has gone by and I still haven't produced the final pair of pull requests. Those are coming soon...

authors: dgoffredo moderation wbpcode


text:
bazel/distribution: Add bundled rule and compiler transition

This allows the output from differently compiled outputs to be packaged together

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/retest

example usage here https://github.com/envoyproxy/envoy/pull/26409/files#diff-5bfd1a5cee89d834ac40d8ea140a9dee9469d3018c3461591561c5e524b95445R10

im confident enough that this does what we want that i would like to land - not sure if its much more performant but its a better organisation of our release bundle, and is a step towards some other optimizations

only comment is about the --linkopt from our own .bazelrc, but sgtm

lets land it and i will test further - its not used yet


text:
generic proxy: change the encoding interface to sync mode

Commit Message: generic proxy: change the encode interface to sync mode
Additional Description:
In the initial design of generic codec, full async interface is used for both encoding and decoding. it make that offloading encoding and decoding to other hardware is possible. But, after the practice in the production env, we found the offloading just a illusion.
The async decoding is just well. But the async encoding bring nothing except complexity. This PR removed the async encoding and make it to use sync interface.
Risk Level: low.
Testing: unit, integration
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.

friendly ping for a blind approve for this contrib only change @jmarantz 🌷

@jmarantz can you PTAL?

authors: adisuissa wbpcode