proposal: x/tools/cmd/godoc: add support for sections

Problem Statement
As packages grow organically over time, their API surface often expands to the point where it is hard to understand how to use the package when all functions and types are shown as a vast alphabetically ordered list. Aside from reading examples (and other 3rd party tutorials), it becomes nearly impossible figuring out how to use a package by the godoc alone.
For example, it is not clear from the godoc of the proto package that the core set of functions are Marshal, Unmarshal, Equal, Clone, and Merge apart from reading the example. The vast majority of other functions are for more advanced (and legacy) functionality that should be categorized separately from the core functionality.
I propose that godoc provides support for user-defined sections.
Proposed Solution
(Approach presented here is Solution A)
It is observed that Go code is often written in such a way that declarations that would be grouped together under a section are already located in proximity of each other within the source code. Assuming that most sections follow this pattern, I propose that a special Section: marker in a top-level comment be used to signify the start of a section. All const, var, func, and type declarations below that marker will be considered part of that section. A section will not cover methods since those are already implicitly grouped under the receiver type.
The coverage of the section group extends either until:

The end of the source file.
The next occurrence of a section marker.
The next occurrence of a special End section. marker, which must be a top-level comment with a blank line above and below it. As a matter of style, it will be discouraged practice to use the end marker unless necessary.

The section marker syntax allows for a required title and an optional description:
// Section: My wonderful title
//
// Let me tell you more details about my wonderful section
// in multiple lines of exciting text.

The title is a string that follows the Section: magic string and must be one line. The title may be any arbitrary string, but white space will be collapsed together. The description is optional and comprises of zero or more paragraphs (similar to package documentation) and must be preceded by a blank line.
For example, the proto package contains a set of helper functions that are only used when dealing with proto2 messages. In the source code, they are already co-located near each other with a comment that looks very similar to a section header. This portion could be modified to be more presentable in the public documentation:
// Section: Basic type helpers
//
// The proto2 format uses pointers for optional basic types (ints, uints, floats, and strings)
// It uses the the nil value to signal that they were are not present in the marshaled message.
// The proto package provides some helpers to aid in allocating values for these types.
//
// These helpers are not necessary for proto3 messages.

All of the helper functions (Float32, Float64, Int, Int32, Int64, String, Uint32, Uint64) will be grouped together under this section until the next top-level end marker:
// End section.

Sections without source locality
The observation that related declarations are often close together in the source does not always hold true. There are certain rare use cases of sections where the related declarations are not necessarily close by (or even in the same source file).
To solve this use case, we permit multiple section headers that have the same title. All declarations under sections with the same title will be considered to be under the same section. Only one of those section headers may have a description. This feature, combined with the end marker, can be used to indicate which declarations in separate files belong in the same section.
For example, the proto package has several types and functions that are only used by generated code and should never be called by user code. These types and functions live in different files. A section can be used to clearly identify these types and functions that are of no interest to the user by add a section in lib.go:
// Section: Internal implementation
//
// These types and functions are only used by generated .pb.go files and
// should never be called directly by user code.
// The compatibility agreement does not cover any of these declarations.

Elsewhere in message_set.go:
+ // Section: Internal implementation

  // RegisterMessageSetType is called from the generated code.
  func RegisterMessageSetType(m Message, fieldNum int32, name string) { ... }

+ // End section.

Elsewhere in properties.go:
+ // Section: Internal implementation

  // RegisterFile is called from generated code and maps from the
  // full file name of a .proto file to its compressed FileDescriptorProto.
  func RegisterFile(filename string, fileDescriptor []byte) { ... }

+ // End section.

How is godoc rendered?
All const, var, func, and type declarations that do not have a section will be shown at the top of the index as they are currently shown. Methods will always be grouped under their receiver type. The "core functionality" of a package should be a small set of declarations that do not have a parent section so that they appear first in the index.
For each section, the title will be printed and then the section's declarations will be shown. The list of sections are ordered alphabetically and the list of declarations are also listed alphabetically in the same way that they are shown today.
See the attached images for an example of what the proto package could look like.

GoDoc before
GoDoc after

Questions:
Q: Will there be support for arbitrary ordering of sections?
No. Since sections are ordered alphabetically, it is trivial for the ordering to be defined by prepending the section title with some prefix (e.g., the section number). It is unlikely that the number of sections will exceed 10, but if it does, a leading 0 can be prepended to the prior 9 sections. People are welcome to design their own ordering system (or carefully choose titles such that they appear in the desired order).
Q: Will there be support for sub-sections?
No. The number of indentations needed to visually show nested sections would make godoc too unreadable. Again, since the sections are ordered alphabetically, a prefix (e.g., 3.1.) can be used to create the concept of a "sub-section".
Q: What about other approaches to describe a section?
I looked other approaches of describing what was in a section and evaluated possible designs. They are described below.
Alternative Solution B (File-based locality)
(Idea by @josharian)
A variation on the source locality idea is to restrict it such that the section header can only be applied at most once at the top of the source file. The same section title may be present on multiple files. This approach avoids the need for a End section. marker since sections effectively span the entire file.
Alternative Solution C (Forward References)
An alternative to defining sections by source locality is to use forward references. In this approach, each section header contains a list of all the consts, vars, funcs, and types that belong in that section.
  // Section: Basic type helpers
  //
  // The proto2 format uses pointers for optional basic types (ints, uints, floats, and strings)
  // It uses the the nil value to signal that they were are not present in the marshaled message.
  // The proto package provides some helpers to aid in allocating values for these types.
  //
  // These helpers are not necessary for proto3 messages.
+ //
+ // References:
+ //  Float32
+ //  Float64
+ //  Int
+ //  Int32
+ //  Int64
+ //  String
+ //  Uint32
+ //  Uint64

Alternative Solution D (Reverse References)
An alternative to defining sections by source locality is to use reverse references. In this approach, the comment for each const, var, func, and type declaration contains a reference to the parent section it belongs in.
  // Int64 is a helper routine that allocates a new int64 value to store v and returns a pointer to it.
+ //
+ // Section: Basic type helpers
  func Int64(v int64) *int64 { ... }

Summary
A summary of the possible solutions:

Source Locality (A)
File locality (B)
Forward references (C)
Reverse references (D)

Provides sections to godoc
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:

Similar to how people naturally document Go code
:white_check_mark: (1)
:white_check_mark: (1)
:x:
:x:

New syntax does not negatively affect older doc-like tools
:white_check_mark:
:white_check_mark:
:white_check_mark:
:x: (2)

Using sections requires no movement of actual code
:white_check_mark:
:x: (3)
:white_check_mark:
:white_check_mark:

Renaming a section is trivial
:warning: (4)
:warning: (4)
:white_check_mark:
:x:

Renaming or deleting a declaration is trivial
:white_check_mark:
:white_check_mark:
:x: (5)
:white_check_mark:

Easy to associate declarations with a section
:white_check_mark:
:white_check_mark:
:x: (6)
:warning: (6)

Avoids End section. marker
:x: (7)
:white_check_mark:
:white_check_mark:
:white_check_mark:

(A, B) In looking at examples of what could use sections, it was common to find a comment block that was very similar to a section header. Unfortunately, the beautiful prose written is not visible on the godoc.

(D) The Section: Foo title string will be visible for doc-like tools with no understanding of sections.

(B) Since sections are defined on a per-file basis, it may be necessary to move code around, which muddle the code history.

(A, B) In the common case, there is only one section title and renaming is trivial. In rarer cases the same title may be used in multiple places and will need to be updated together.

(C) It is easy for the forward references to get out of sync when declarations are renamed or deleted. This is trivially checked by the lint tool.

(C) Any approach using references needs to provide that reference information somewhere and specifying these references can be cumbersome.
For forward references, in the event that two section headers references the same declaration, which section should that declaration be in? Also, if there are many identifiers (e.g., lots of constants), do all identifiers have to be listed in the section header? The problem gets worse when different section headers refer to different identifiers within the same declaration block. Should the block be split apart to be in different sections?
For backward references, a reference is still needed, but it avoids the problem with block declarations since the parent section is applied on the entire block.

(A) The end section marker is not always needed since the end of a file or start of a section ends the current section's scope. Forgetting the end section marker can accidentally add more declarations to a section than intended. Getting this wrong is obvious when viewing the godoc.

I propose that godoc add support for user-defined sections by source locality (Solution A) as opposed to other approaches (using forward references or reverse references). I believe that Go documentation is often clean and palatable when the package is small, but quickly becomes overwhelming as the number of exported declarations in the package grows. User defined documentation sections solves this problem and encourages clean documentations at scale.
Related proposals:

#18130: support gradual code repair while moving a type between packages

It may be the case that when a package accrues many types over time that they should to be broken off into their own seperate package. However, support for movement of types does not change the fact that these types still exist in the original package for compatibility reasons. If support for #18130 happens, that is more reason that we should support sections so that documentation can clearly identify that a group of types have moved and provide details about the move.

#17056: godoc: hide deprecated things by default

As a possible alternative to #17056, a section could be used to contain all deprecated items under it. However, sections would not be able to group deprecated methods or fields. The existence of both features in godoc do not hamper the other, but could be used powerfully augment each other. You can imagine allowing godoc to hide an entire section with the Deprecated: magic string in the section description.

\cc @neild @light @bcmills @bradfitz @lmmilewski

Should we just split huge packages or have better introduction
in package docs and package level example instead?

In retrospect, some of these packages should be split apart and doing so will definitely help the situation. The reality is, many packages are currently bloated and are unlikely to shed API surface anytime soon due to compatibility reasons.

Even if we start gradually moving types using aliases (or whatever the solution ends up being), there is still a reference in the package. Sections help categorize and document the move.
Even after some cruft is remove from a package, there are usually still a number of distinct sections that still belong together in a package, and it makes sense to document them as such.
Better introductions help, but I believe are still insufficient. Some internal packages at Google have ridiculously long introductions, and they don't really help make the package docs be any more readable. IMHO, most of that introduction should be split into the relevant sections that they describe.
Examples help, but I believe are still insufficient.

+1 for some form of sections in godoc.
Splitting large packages can make sense, but it's very difficult to do after the fact and a maze of highly interdependent small packages is not necessarily any clearer than a single large one. Even small packages can benefit from sections, too; for example, database/sql is not particularly large, but grouping the Null* types into a single section might provide a small boost in readability.

Please keep godoc as simple as it is. It's a great value, though some would realize that only after it's gone.
Projects needing more structured documentation can easily link to any of the uncountable formats available. For example guru or go/types do that.

It appears that the godoc on golang.org already supports sections to some extent.  For example, there are now heading links to the Examples section of the testing package.
Another option might be to expand godoc to accept package comments from multiple source files.  The package comment(s) in source files without any other declarations would become the top-level "Overview", and the package comment in each other source file would be the section header for the declarations in that file.  Declarations in files without their own package comment would be grouped into the main section with the overview.

For the example of the proto package in particular: I maintain that it would be cleaner to split that package into two (or more) distinct packages: one with only the user-facing API, and another with the pseudo-internal hooks for generated proto packages.
(I could envision even-finer-grained splits, too: one for the proto2 pointer-to-primitive helper functions, perhaps one for the extension API, etc.)

It appears that the godoc on golang.org already supports sections to some extent.

I contend that the most useful feature of sections that I want to see is the ability to group a set of const, var, func, and type declarations together. Right now, all we have is the ability to pretty print some header title.

I maintain that it would be cleaner to split that package into two (or more) distinct packages.

Absolutely agree the pseudo-internal hooks should have been a different package. I believe the exported stuff to help with custom implementations of Message should also be split out. But those pointer-to-primitive functions are so pervasively used (over 200k usages!) that it's probably pretty annoying needing to import both a proto package and proto2 package. The point of sections is to group those functions together without creating a tiny package just for them.

I contend that the most useful feature of sections that I want to see is the ability to group a set of const, var, func, and type declarations together.

Thinking out loud...
What if that grouping was determined, perhaps optionally, by source file? Code is frequently already organized this way, with some exceptions, like autogenerated files. And if feels less fragile than relying on any ordering within a file. Perhaps if you still want section headers and more control, there could be zero or one section header per file, which applied to all code in that file, with identical section headers being coalesced.

But those pointer-to-primitive functions are so pervasively used (over 200k usages!) that it's probably pretty annoying needing to import both a proto package and proto2 package. The point of sections is to group those functions together without creating a tiny package just for them.

The pointer-to-primitive functions aren't needed for proto3 messages, so only a subset of users of the proto package will actually use them.
goimports makes having lots of tiny packages fairly benign, as long as there is some reasonable heuristic to figure out which item is in which package.  (Contrast: io vs. ioutil.)

The net and http packages in the standard library might be other good examples to consider.  If you had support for sections, how would you want to split those out?  (And does that split match the division of files today?)

I disagree that lots of tiny packages are benign, even with goimports. The user still needs to remember which package contains which function; easy when you have one or two packages, less so when you have a dozen.
Obviously, stuffing unrelated functionality into a single package isn't right either. It's a balance. (For the proto package, I'd say the pointer-to-primitive functions should stay--they're small, cheap, and anyone who uses proto2 will want them--but obviously all the internal hooks should get pulled out. Something to work on once type aliases or the moral equivalent become available.)

What if that grouping was determined, perhaps optionally, by source file?

In the example I posted, when I was organizing the proto package, 5 of the sections were pretty much by file. The last section, which was about "pseudo-internal stuff" was spanning several files. Arguably, those functions and types could be all moved to a single internal.go file and be made one section. Thus, grouping by file can lead to an unfortunate amount of code-churn.
If we end up going with grouping by source alone, I'd be fine with that approach.

As a specific example from the net package, it contains eight error types:
DNSConfigError
DNSError
Error
InvalidAddrError
OpError
ParseError
UnknownNetworkError

Those are currently spread throughout the package index; collecting them into a single section would improve clarity.
These type names could be rewritten to use a common prefix (e.g., ErrParse) so that they sort together, but using less-natural names to work around godoc doesn't seem like a good situation.

These type names could be rewritten to use a common prefix (e.g., ErrParse)

Not to mention that's not the convention. It's ErrFoo (or errFoo) for variables, and FooError (or fooError) for types.

As another data point. The need for sections is not just for bloated packages, but even small packages can benefit from sections. I mentioned earlier the example of the binary package and the problem with ByteOrder and LittleEndian being on opposite sides of the page.
Here's what the GoDoc would look like with sections: binary doc
The sections as seen in godoc also matches exactly how they are laid out in source code.

What do other languages do? I agree that godoc could do better. It would be great if we could do better automatically. It's easy to group errors, for example. Are there automatic groupings that we can explore? Alternately, what do other languages do.
One thing I do not want to see is CLs moving code around and breaking 'git blame' just so that things appear in a different order in godoc.

Are there automatic groupings that we can explore?

Grouping functions with similar signatures would help with the binary package.  Grouping types with similar method sets would help with the net package.
Unfortunately, I don't see any obvious heuristics that would help with the net/http package: the logical groupings there, I think, are "client", "server", and "data", but determining which declaration goes with which cluster seems to require a fairly sophisticated traversal spanning struct fields, method receivers, and method sets.

Python has pydoc, which I do not believe has sections. The Python standard library documentation is a separate set of reStructuredText files with internal sections; it does not use pydoc.
I don't believe Javadoc has sections. My experience in reading Javadocs does not lead me to consider it a system in need of emulation.

Someone spends more time in godoc, someone else might spend more time reading source code. Nonetheless, the better/richer/fancier the godoc output gets in terms of anything based on some magic/metadata/markup/... in comments, the less overaly source code comments will be usable without the godoc "interpreter".
It's a zero sum game.

Alternately, what do other languages do?

The Haskell Haddock markup language has heading annotations.
Rust uses Markdown with some distinguished sections and some special parsing for examples.
I believe that ocamldoc keeps comments and declarations in source-file order, but only allows one source file per package.
C and C++ have dedicated third-party websites because their documentation story is so poor.  😦

I don't see any form of zero-sum game between godoc and source code comments. The proposed section comments read naturally in either location.

As a step toward solving the underlying problem, what if the mentions of exported names in the package doc comment automatically turned into links? The net package doc has, for example:

Name Resolution
The method for resolving domain names, whether indirectly with functions like Dial or directly with functions like LookupHost and LookupAddr, varies by operating system.

Imagine if instead each of those words - Dial, LookupHost, LookupAddr - were hyperlinked to the real thing. Then the package doc would work better and could contain the sections people are talking about, without any new syntax or non-prose.
It seems like maybe that should be the first step at least? It's unclear who should work on this. @neild, @dsnet, @bcmills, any takers?
-rsc for @golang/proposal-review

what if the mentions of exported names in the package doc comment automatically turned into links

Not just package doc comments, but all comments.

Automatic linking will result in some words inadvertently becoming links. I don't know if we care about that. I've certainly wished for internal links on a number of occasions.
Adding sections to the existing index seems simpler to me than creating an entire second table of contents in the package doc.

I think that's an interesting and I would like to see that feature as well. ISTM that what you're describing is a form of "bottom-up" documentation. That is, you look at some specific component and the feature helps you answer the question: "how does this relate to all the other components in this package?"
However, sections are designed to be a form of "top-down" documentation. That is, they should help answer the questions: "I'm new to this package, how do I even grasp the high-level organization? what's important?"

The "top-down" documentation should be given via a good package comment. If we can make the appropriate words in that comment link to the relevant pieces elsewhere we can probably go a long way. We do have all the exported identifiers, so it's a matter of being smart about connecting them with the prose. I think it can be done but it may take some experimentation.

@griesemer. A good package comment is not sufficient for complex packages. For example, even with a nice package comment, it only marginally helps the proto package to be readable.
Furthermore, if you spend time writing a good package comment about what is conceptually a "section", then shouldn't that block of text be located next to the related identifiers on godoc?

As a data point: https://godoc.org/github.com/google/gopacket. There was actually time invested into the package documentation for gopacket, but I still it very hard figuring out how the exported indentifiers should be used.

@griesemer another easy win would be to automatically generate a table of contents for the package comment that links to its headers. That would make large package comments easier to navigate.

what if the mentions of exported names in the package doc comment automatically turned into links

Not just package doc comments, but all comments.

One small piece of evidence that this might be useful: #18644.

That's indeed pretty small.

It still seems like automatic linking is worth doing regardless, and it may (or may not) help enough that we don't need to do anything else. It seems like we should do that before we consider more invasive changes.

I can tackle this (i.e.,  automatic linking) in a few weeks unless someone else wants to do it. I'll assign it to myself when I start working on it.

FWIW, @ianlancetaylor proposed the automatic linking in Jun 2013 in #5637 (still open).

On hold for @dsnet's work.

I hacked up an implementation of "hotlinking" exported identifiers based on @rsc's comment and also an implementation of "sections" based on my initial proposal.
I have mailed out the prototypes as:

CL/66311: godoc: add support for hotlinks
CL/66312: godoc: add support for sections

I have also setup some test godoc servers running those CLs:

https://godoc-vanilla.digitalstatic.net/pkg
https://godoc-hotlinks.digitalstatic.net/pkg
https://godoc-sections.digitalstatic.net/pkg

link to servers running godoc with no changes (vanilla), with hotlink support, and with sections support.

Analysis of "hotlinking":

Examples: net/http, cmp
My current approach does not handle struct fields and interface methods.
The algorithm is susceptible to false-positives (i.e., we hyperlink what looks like an exported identifier to the wrong thing).

Example of false-positives: Set-Cookie, Equal method

The algorithm is susceptible to false-negative (i.e., we fail to hyperlink what is obviously a reference to some exported identifier).

Examples of false-negatives: CheckRedirect

For both cases, we can keep tuning the algorithm, but it is impossible to be accurate all of the time. False-positives are especially bad since it causes godoc to be lying about what something actually is.
We only perform hyperlinking for export identifiers from within the same package. Hyperlinking external packages (e.g., io.ReadCloser) gets tricky.

Analysis of "sections":

Examples: encoding/binary, encoding/json, cmp, iolimit, proto
Even small packages like binary can benefit from sections since it groups ByteOrder with the specific implementations LittleEndian and BigEndian. It also groups all of the varint-related functions together since the names don't sort nicely.
Very large packages like proto actually becomes understandable by grouping related functionality into sections.
There is an open question of whether methods can be moved as a result of being in a different section from the parent type. My prototype does allow methods to be separated from their parent type (e.g., methods of iolimit.Limiter).

@dsnet maybe the precision of hotlinks could be improved by having more strict rules

Only attempt to match at the start of a line or when preceded by white space (takes care of Set-Cookie)
Only match Name with a top-level variable, const, func, or type.
Only match fields/methods with an explicit Type.Name

The first rule would allow the false-positive with Equal to be suppressed by writing:
// [...] and no "Equal" method is defined [...]

Alternately, it could be written to say something along the lines of: "and does not satisfy the Equaler interface." (Which would require defining said interface purely for documentation purposes or writing the definition in a pre block in the comment itself)
That could mean having to rewrite documentation to make sure things link correctly and do not link incorrectly but no matter how fancy the heuristics are that's going to be a problem. At least simple heuristics are easy for people to reason about.

Subjective impressions: The hotlinks are really nice when they work. The sections are great, even in the case of small packages like encoding/binary. The proto package is hugely improved with sections; that's in large part because the proto package is a complete mess, but I think improving the documentation of packages which are complete messes is a worthy goal.
I think the history of wiki linking (from WikiWords to [[brackets]]) argues that the most practical approach to avoiding false positives and negatives is to explicitly tag links. It's easier to consistently tag things which should link that it is to remember the link-detection heuristics and tag things which should not link. (e.g., and no "Equal" method is defined.) This isn't necessarily an argument for explicit tagging, just an observation about the limitations of a heuristic approach.

Thanks Joe. It looks like there are some minor adjustments to make, but the general "automatic" approach does look right. Let's mark this proposal as accepted and leave the fine details for code review. @griesemer will take a look at the CLs.

To be clear, what has been accepted? hotlinking, sections, or both?

@dsnet Correct. We didn't look into the sections idea in the meeting - but I see that it looks pretty nice and is not intrusive. Let's discuss this in a 2nd round.

I made a CL to add a table of contents to the overview section based on the headers in the package document per my comment on https://github.com/golang/go/issues/18342#issuecomment-271431021 I realize that didn't get an official go-ahead and that it would likely need to be updated to work with the autolinking CL (I would be happy to do so), but I wanted to see if there was any benefit to having such a ToC. I tried godoc out on some packages with larger comments and it was quite pleasant, imo.

@jimmyfrasche, thanks for prototype, do you have a test server running that you can point people to? Which packages best demonstrate the benefit of this feature?

I do not, sorry. I'm just running the modified godoc locally.
The standard library does not have many packages with long package comments and those that do do not tend to have headers. The go/build package was the best example I could find—and I've often had to ctrl+F or page down, page down, page down to jump to the section I wanted before so it was personally satisfying to see the ToC there.
Outside the standard library, the nicest obvious improvement in a very commonly used package was github.com/gorilla/websocket which has 5 useful subsections whose quick links benefit the return reader.
The github.com/google/gopacket package you posted earlier in this thread has many headers in the package document so it looks like it would be useful there as well.

I suppose I could at least post a screenshot, though. Sorry for not thinking of that earlier.

There's an existing table of contents; why not include the overview sections table in there?
Overview
    Go Path
    Build Constraints
    Binary-Only Packages
Index

@neild That was my first thought as well, but this way I only had to render the doc to html once and I didn't have to worry about what happens if someone clicks the link but the overview is collapsed. I don't mind changing it but I figured why go to that trouble for a first iteration.

CL 72890 is my first cut at implementation hotlinks. It's a vastly cleaned up version of my former CL.
The render_docs.go file uses the render package to statically generate HTML for the entire standard library. You can see the results here: https://static-hotlinks.digitalstatic.net/

Any chance we can get this in for go 1.10? It would be really nice to get this in sooner than later. I reckon that this change can go in, as it doesn't affect running programs, but it makes a useful tool much better. Waiting for go 1.11 means waiting until August/Sept 2018 - a very long time away.

The 1.10 release is in beta and only bug fixes are going in. Aside from that, the code still needs some polishing and to go through code review, both of which is going to take time and most certainly will not complete before 1.10 release.
Secondly, suppose the code for this feature gets submitted not long after 1.10 is release, nothing is stopping you from go getting the godoc tool yourself and using it ahead of the 1.11 release. Thus, saying that you have to wait for August 2018 is not a fair assessment either.

Experience report: We're considering defining some exported types as interfaces rather than as concrete types, entirely because interfaces allow related methods to be grouped together in godoc and concrete types don't.
e.g.,
type ContainerType interface {
  // NumCats is the number of cats in the container.
  NumCats() int
  // Cat returns the i'th cat in the container.
  Cat(i int) Cat

  // NumPigs is the number of pigs in the container.
  NumPigs() int
  // Pig returns the i'th pig in the container.
  Pig(i int) Pig
}

This is a different than the sections proposal (which would allow grouping types, but not methods within a type), but seems related.

Removed the "accepted" label, because what was accepted was something other than sections (and @griesemer's last comment about sections is that there should be a section review round about sections).

How far along are we on that plan?

It's not far off from integration with x/tools/godoc (but won't make it for the Go1.11 cycle). When I looked at what it would take to integrate with other godoc tools (e.g., godoc.org), I came to the sad realization that every tool does front-end rendering in their own way, which makes a change like this lots of work.
Arguably, the place that benefits most is in the godoc.org tool, not the x/tools one.
I wonder whether we should strive to unify the godoc tools first. I'm not saying they should be the same tool, but they are a lot more opportunities for shared code than what exists today.

It sounds like the plan is to do both #25449 and #25444. At that point more proposals can be made about what is left. But until then it seems like we should close this proposal as having spawned two concrete next steps. I agree about sharing code between godoc, gddo, etc but that probably doesn't need a proposal (it doesn't affect how programmers write doc comments, for example).

Coming late to this conversation, but does closing this proposal imply that sections will NOT be done? The spawned proposals are good, but they do not easily satisfy the origial premise of being able to guide readers of documentation through an API by pointing them first to the general purpose or most likely used functions, and then to more specialized fuctions. Yes, one could do that through package comments and hotlinking, but sections are easier to maintain.
Another reason for sections is to guide various consumers of an API in a large project. Go does not have protection semantecs like other languages, so large groups have to communicate and use conventions to work well together. It would be nice to reinforce these conventions through the documentation.
Also, I am concerned about this comment from the original proposal:

A section will not cover methods since those are already implicitly grouped under the receiver type.

The purpose of sections applies to methods as well. The grouping provided by receivers is for programmatic purposes, not for documentation purposes. The need to group parts of an API for the consumers of a receiver is the same.
Currently, in order to do this, one could use a naming convention that adds a prefix to the names of functions and methods in order to group them, but I hate having to change an API for something that could be handled with a simple documentation mechanism.
I am not sure if tagging was ever considered as an alternate solution to sections to solve this. It looks like the Deprected: keyword is getting some traction, but really in a limited scope. Being able to put a tag in a comment, like Deprecated: or the BUG(): mechanism, and using those to define sections could alternately be used, and also satisfy the Deprecated: problem (but a sort order would need to be added too.)
Just some thoughts.

@spekary Did you review the above discussion? I believe various possible approaches, as well as their pros and cons, are discussed quite exhaustively, starting already from the Summary section in the initial post. There doesn't seem to be a clear winner, all approaches appear have some cons. On first reading, I'm afraid I can't see what your post adds to the discussion, that was not already discussed.
As far as I understand, the current idea is to start by implementing the 2 linked proposals, which have the advantage of also fixing/improving some other issues. Afterwards, with some more experience w.r.t. how they work, the situation could potentially be reevaluated. That said, as far as I understand, those proposals will enable de facto realizing the "Alternative Solution C (Forward References)" approach, by thoughtfully composing the "package level" docs for a package in appropriate Sections. Personally, I suppose this will then become the advised approach for solving this issue.

I did read it. I saw tagging mentioned but not seriously considered, and I think that should be evaluated.
Another goal and benefit of godoc is the minimal amount of effort developers need to put in to get reasonably good documentation. By using a locality approach or tagging approach, the developer need do nothing else but make sure a function or method is defined in the right place in the file or given a correct tag. If he/she gets that wrong, running godoc will make it clear whether the new functions appear in the wrong place. Developers tend to work serially, writing code first with minimal doc, and then adding more extensive doc later.
Relying on the two linked proposals means developers must maintain documentation in two places. If a developer in a fit of inspiration writes a bunch of new functions, and then later goes back to try to document them, running godoc will not help identify which functions are missing from the package doc, since they will not appear at all. The developer will have to visually compare the package doc with the generated TOC. It will be easy for a developer to miss some, especially in a large project. As the project grows, the header's description will diverge from what is actually in the TOC.
Well, that is just a prediction based on my observed human behavior. As you say, we can see how it goes and revisit later. I am hoping that closing this proposal doesn't end it.

I re-filed sections as a proposal again (see #44447). I revisited some of my prototype work with hotlinking (#25444) and I'm increasingly convinced that it's troublesome since it can't completely eliminate the presence of false-positives, which is harmful because it actively links users to the wrong information. Furthermore, it goes against the Go philosophy that "clear is better than clever". See the end of the proposal in #44447 for detailed arguments against hotlinking.


Update visual-studio-github-copilot-extension.md

Updated to include correct version for prerequisites (Visual Studio 17.8)

@anandmeg

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Basic News Frontend

Have basic front end for news html template using Mustache template. JSON file is currently hardcoded.

@googlebot I signed it!


Some strangeness in fips checksummed sources

We include all the sources in libimplementations.a in the fips checksummed sources. That seems incorrect as there are clearly some sources that compile to object files that are not supposed to be included in the fips provider at all.
Namely:
providers/common/der/der_sm2_gen.c.in
providers/common/der/der_sm2_key.c
providers/common/der/der_sm2_sig.c
providers/implementations/asymciphers/sm2_enc.c
providers/implementations/ciphers/cipher_aria.c
providers/implementations/ciphers/cipher_aria_ccm.c
providers/implementations/ciphers/cipher_aria_ccm_hw.c
providers/implementations/ciphers/cipher_aria_gcm.c
providers/implementations/ciphers/cipher_aria_gcm_hw.c
providers/implementations/ciphers/cipher_aria_hw.c
providers/implementations/ciphers/cipher_camellia.c
providers/implementations/ciphers/cipher_camellia_hw.c
providers/implementations/ciphers/cipher_chacha20.c
providers/implementations/ciphers/cipher_chacha20_hw.c
providers/implementations/ciphers/cipher_chacha20_poly1305.c
providers/implementations/ciphers/cipher_chacha20_poly1305_hw.c
providers/implementations/ciphers/cipher_null.c
providers/implementations/ciphers/cipher_sm4.c
providers/implementations/ciphers/cipher_sm4_hw.c
providers/implementations/digests/blake2_prov.c
providers/implementations/digests/blake2b_prov.c
providers/implementations/digests/blake2s_prov.c
providers/implementations/digests/md5_prov.c
providers/implementations/digests/md5_sha1_prov.c
providers/implementations/digests/sm3_prov.c
providers/implementations/encode_decode/decode_der2key.c
providers/implementations/encode_decode/decode_msblob2key.c
providers/implementations/encode_decode/decode_pem2der.c
providers/implementations/encode_decode/decode_pvk2key.c
providers/implementations/encode_decode/encode_key2any.c
providers/implementations/encode_decode/encode_key2blob.c
providers/implementations/encode_decode/encode_key2ms.c
providers/implementations/encode_decode/encode_key2text.c
providers/implementations/encode_decode/endecoder_common.c
providers/implementations/kdfs/scrypt.c
providers/implementations/macs/blake2b_mac.c
providers/implementations/macs/blake2s_mac.c
providers/implementations/macs/poly1305_prov.c
providers/implementations/macs/siphash_prov.c
providers/implementations/rands/seed_src.c
providers/implementations/rands/seeding/rand_cpu_x86.c
providers/implementations/rands/seeding/rand_tsc.c
providers/implementations/rands/seeding/rand_unix.c
providers/implementations/rands/seeding/rand_win.c
providers/implementations/signature/sm2sig.c
providers/implementations/storemgmt/file_store.c
providers/implementations/storemgmt/file_store_der2obj.c

I've tried to put some of these into libnonfips.a instead of libimplementations.a but that did not seem to work for some reason.

I've tried to put some of these into libnonfips.a instead of libimplementations.a but that did not seem to work for some reason.

Ah, the weak dependency of libimplementations.a on libnonfips.a causes that. If I comment it out it will work as expected.
Obviously it is not a good idea. Probably the get_sources query should somehow avoid weak deps.

This is a clash of ideas.
libimplementations.a came with the idea that all implementations would be placed in one library, and that each provider could simply refer to whatever they see fit, and linking would do the rest.  It's a nice idea, but doesn't allow the segregation of FIPS vs non-FIPS stuff, so we get everything.
I can see two ways this could be solved:

Throw away libimplementations.a and rather use the source directly with the applicable provider.
In all build.info files, it would mean changing any of these lines:
SOURCE[libimplementations.a]=something.c

to:
SOURCE[providers/fips]=something.c
SOURCE[libcrypto]=something.c

Pros:

I think it would diminish confusion, 'cause it seems like all those static libraries aren't well understood.

Cons:

More object files from the same source, basically everything that we use for the FIPS provider will have duplicated object files for the detault provider.

Doing deeper analysis of symbol references in providers/fips.so and providers/libimplementations.a and see what object files define them...  I can already feel my head explode at the thought.

Why can't we use libfips and libnonfips instead of providers/fips vs libcrypto?
It would still have the "more object files from the same source" problem I suppose though.

Why can't we use libfips and libnonfips instead of providers/fips vs libcrypto?

They lose their value as intermediary libraries.  The original intention was that everything that can be compiled the same (i.e. doesn't have any conditions on FIPS_MODULE) would end up in libimplementations.a, and libfips.a / libnonfips.a would contain support functions that would be compiled differently depending on FIPS_MODULE.
However, with libimplementations gone, this is how the providers would linked:
FIPS provider (providers/fips.so): fips provider object files + libfips.a + libcommon.a
Default provider (built into libcrypto): default provider object files + libnonfips.a + libcommon.a
Legacy provider (providers/legacy.so): legacy provider object files + libnonfips.a + libcommon.a
So looking at it now, we might want to keep linnonfips.a around, but libfips.a isn't very useful any more...

I'd still keep it to keep the linkage of the providers more uniform.

I would ignore the disk space issue.  What is way more important is being able to clearly understand what is in the FIPS provider, and therefore what is in the module boundary.
Repeat object files and make it explicit.  It should be easy for someone (I'll open an issue if necessary) to list what source files are in a provider, or at least the FIPS provider).
Sharing implementation is a premature optimization and therefore the root of this evil :)


Integration test shows up in prod

Just a dumb question, but should the integration test be showing up in prod?
https://data.humancellatlas.org/explore/projects/4d4a41ef-c655-40c3-9ee8-5ce3ecd06774

All bundles show up in prod. They do (or should) get deleted at the end of the test
Azul has no indication that "integration test" bundles are different from any other.
If they weren't indexed then what would be the point of the test?
Should we be running integration tests in prod at all?
What are your view @jahilton ?

They'll also be (temporarily) visible via the DSS and Query Service APIs, so this is not just a Data Browser issue.

My views...
The Integration Test projects shouldn't be visible to the user via DSS, Browser, or any API. Could throw a false positive for anyone pinging for new submissions. They only appear for a short time, so it's not a major concern.
I don't know enough about the integration tests to know whether they should stop running or a new test should be considered to replace them.
Maybe this is another use case for a public on/off switch for projects. These tests could still run, but the public wouldn't be aware.

@parthshahva Who "owns" the integration tests? Is this an item for the DevSecOp or TechArch meetings?
I'm concerned that it would be a considerable effort to "hide" integration tests from any public view.

The integration tests are owned by Tech Arch and all components. I have managed a lot of the codebase as well but am not an explicit owner. With the DCP architecture in mind, the only real way to make this work while keeping the tests useful would be a public on/off switch or staging area concept.

Once the project-completion RFC Phase 1 is implemented, we can have these tests submitted as 'unreleased'. Not much we can do until then, unfortunately, unless we think they could be displayed more obviously as test data (they seem pretty obvious to me).

Closing as we are switching to a release snapshot that presumably will not contain integration tests


Documentation missing/unclear on RailsContext?

I can't seem to find any solid information on how railsContext works and how to access the railsContext from within a component.
I have some server side size variables such as ENV variables that I want react components to be able to access. Normally I'd just pass them as props however reading the documentation it says:

While you could manually pass the railsContext information in as "props", the rails_context is a convenience because it's passed consistently to all invocations of generator functions.

I thought this mean I could set up a rails_context to contain the information i need, and then whenever I use react_component it will have a railsContext parameter automatically added that I can use to access the railsContext from within the component.
the definition of these components are
export default (_props, _railsContext) => {
}
which seems to suggest some how there is a railsContext being passed in. But although my _props contain values as expected, _railsContext is always null and I can't find any documentation that explains how you pass this value in. Searched online for a few hours to no avail. In the end I just decided to pass rails_context in as a prop, which works, but I'm still confused as to what this railsContext is for or if it is broken or just lacking documentation.

Hi, @ceres629
I use the rails context a lot in my app. To sure you load the context appropriately
see https://facebook.github.io/react/docs/context.html.
The child component need define contextTypes
Button.contextTypes = {
  color: PropTypes.string
};

I miss a good documentation for react on rails context, I implemented a custom context provider and pass the context in as a prop.

I created an example:
https://github.com/shakacode/v8-demo/pull/2
I'm working on making the documentation more clear.

See #886, @MiguelSavignano and @ceres629. Please review.

The example with generator function it's great but Why if my component it's a React Class the context don't appear.
import React from 'react';
class RailsContextExample extends React.Component {
  render(){
    return (

props are: {JSON.stringify(this.props)}

railsContext is:
          {JSON.stringify({ ...this.context, serverSide: false})}}

    )
  }
}
export default RailsContextExample;

And other thing i try to add new context key like params_action or current_user_id I try to override rails_context helper method but this method it's private and I can't do this.

@MiguelSavignano There's no reason that the railsContext would ever get passed to your React component unless the value is explicitly put into the props used for rendering. If you create a react component, rather than a generator function, for use by React on Rails, then you get whatever props are passed in from the view helper, which does not include the Rails Context. It's trivial to wrap your component in a "generator function" to return a new component that takes both:
import React from 'react';
import AppComponent from './AppComponent';
const AppComponentWithRailsContext = (props, railsContext) => (
  <AppComponent {...{...props, railsContext}}/>
)
export default AppComponentWithRailsContext;

Consider this line in depth:
  <AppComponent {...{ ...props, railsContext }}/>

The outer {... is for the JSX spread operator for attributes and the innner {... is for the Spread in object literals.
@MiguelSavignano Should this go in the docs?

@ceres629 @MiguelSavignano Please see my updates to #886 and review.

@MiguelSavignano and @ceres629, while I merged, I'd still like to get your feedback.

@justin808 Thanks for update the docs and include both examples.


[Bugfix/LIVE-11922]: Error message when network fees are above account balance

✅ Checklist

[x] npx changeset was attached.
[ ] Covered by automatic tests.
[x] Impact of the changes:

📝 Descriptio
https://github.com/user-attachments/assets/b3db7779-84d9-488c-a177-1081e59cfc31

❓ Context
https://ledgerhq.atlassian.net/browse/LIVE-11922

🧐 Checklist for the PR Reviewers

The code aligns with the requirements described in the linked JIRA or GitHub issue.
The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
There are no undocumented trade-offs, technical debt, or maintainability issues.
The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
Any new dependencies have been justified and documented.
Performance considerations have been taken into account. (changes have been profiled or benchmarked if necessary)

/generate-screenshots

/generate-screenshots


Does not support react-native 0.35

I'm trying to install the package into my project which is written on react-native 0.35 using this command:
npm install --save react-native-device-info
This outputs an error:
├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>Can you tell which version of react-native-device-info supports react-native 0.35? I've tried to downgrade several versions including 0.9.6 to 0.9.0, had no success.

I use it within react 0.36.0 and it works fine. Try to manually link package like it is described in description, and preliminary install Google repository in SDK manager

Closing this old stale issue, please re-open if you're still facing a problem!


Can not build in Windows 10

Hi
I can't seem to build my current project under windows 10.

Please stop opening bug reports if you aren't going to provide enough information.

@BurntSushi Sorry. I have summit the detail to https://github.com/BurntSushi/rure-go/issues/4
Please check it. Thanks


Make level 26 easier with 40px gap #66

Level 26 is unintuitive because to leave a gap of 50px with 5 rows, the 50px must be divided into 4 rows (of 12.5px each, or 50+0+0+0). To make this level easier, I've changed the gap to 40px, which is easier to divide by 4.

Hope the translations aren't messed up - I only changed the number

Hey @cxong, thanks for the PR. I understand where you're coming from, but I wanted to make the calculation less straightforward so people slow down and consider different approaches. For example creating one 50px row and three 0px rows, or using repeat() with the calc() function. But I'm open to discussion on this.


[youtube] specify %(channel_id)s in output template

Please follow the guide below

You will be asked some questions, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your pull request (like that [x])
Use Preview tab to see how your pull request will actually look like

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x] Searched the bugtracker for similar pull requests

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[ ] I am the original author of this code and I am willing to release it under Unlicense
[x] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Bug fix
[x] Improvement
[ ] New extractor
[ ] New feature

Description of your pull request and other information
Resolve issue #9676
output template support for %(channel_id)s
Implement the code provided by @glenn-slayden to specify %(channel_id)s in youtube template output. This is a relatively small Improvement that allows youtube-dl to work with channel ids that are the default way of identifying channels in Data API v3. See: https://developers.google.com/youtube/v3/guides/working_with_channel_ids

You should modify existing extractor not create a new file.

I seemed to have made a mistake in uploading directly with github. I've pushed a commit with modifications to 'youtube_dl/extractor/youtube.py' and another with removal of the extra file. Should I start over with another fork and pull request?


Conditionnal CSS based on props

Hi!
I would like to use some CSS when I have some props.
For example, if socialButtonIsFixed == true, I would like to add CSS to a styleComponent

I know it is possible to add conditional property by font-size: ${ props => props.primary ? '4vw' : '18vw'} but I think it's not what I need.
Someone knows how to do that please?

I know it is possible to add conditional property by font-size: ${ props => props.primary ? '4vw' : '18vw'} but I think it's not what I need.

It is! This is probably what you want:
const Buttons = styled.button`
  ${props => props.fixed && css`${socialButtonsActive}`}
`;

Please direct usage question to the community: https://spectrum.chat/styled-components Thanks!


job.properties fails validation

Information

Qiskit Terra version: master
Python version:
Operating system:

What is the current behavior?
ModelValidationError: {'gates': {0: {'qubits': ['Missing data for required field.'], 'parameters': {0: {'unit': ['Missing data for required field.'], 'date': ['Missing data for required field.'], 'name': ['Missing data for required field.'], 'value': ['Missing data for required field.']}}, 'gate': ['Missing data for required field.']}}, 'general': {0: {'unit': ['Missing data for required field.'], 'date': ['Missing data for required field.'], 'name': ['Missing data for required field.'], 'value': ['Missing data for required field.']}}, 'backend_name': ['Missing data for required field.'], 'backend_version': ['Missing data for required field.'], 'last_update_date': ['Missing data for required field.'], 'qubits': ['Missing data for required field.']}

Steps to reproduce the problem
q = QuantumRegister(2)
c = ClassicalRegister(2)
qc = QuantumCircuit(q, c)

qc.h(q[0])
qc.cx(q[0], q[1])
qc.measure(q, c)

backend = IBMQ.get_backend('ibmqx4')
job = execute(qc, backend)
job.properties()

What is the expected behavior?
Suggested solutions

It seems that this is true only if the job is not done.  So perhaps there should be a check for the job status before the query for the properties to avoid this error.

This is an IBMQProvider issue.

I guess we can't just change self._wait_for_submission() to self._wait_for_completion(), because we would want to have some properties for a running job? But even submitted, it seems it has no set properties before completion, or I missed something?

Moved to: https://github.com/Qiskit/qiskit-ibmq-provider/issues/116


fixing bug where tokens can be transferred on account creation + test

Motivation
Fix to enforce account limits on account creation
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Added a functional test to prevent regression. Ran other functional tests. Relying on CI for further testing.

@jamesmeijers LGTM just need a rebase from main before I can merge.


className not working?

Hi there!
I'm trying to override the styling of the picker, but after specifying a className and adding my styles, I'm not seeing any results. In my case, I've used my-picker as the className, but there is no reflection of this in the DOM (the class "my-picker" doesn't appear anywhere), and hence, my style overrides are never applied.
As you can see, I'm using this together with createPopup - is it possible there is a bug here?

Hi, thanks for trying the beta version! I just gave this a try and it seems to work, even for popup pickers.
Can you verify that you are using version 5.0.0-beta.8? That is the version the custom theme support was added in.
To make sure you have the latest beta you can run npm install picmo@beta - I goofed and forgot to specify the beta tag on an earlier version so if you did npm install picmo alone you probably have 5.0.0-beta.7.
Can you try npm install picmo@beta and see if that resolves the issue? Thanks again! I'll leave the issue open until I hear back.

Thank you for the pointer @joeattardi, I was indeed on 5.0.0-beta.7 of picmo, and in fact 5.0.0-beta.4 of picmo/popup-picker. After upgrading both to the latest 5.0.0-beta.9, it is now working as expected. 🚀


Corrected GQ -> LQ data acquisition in slices

Fixes #11452
Status
not-tested
Description
Iterate through all the available elements, in slices of 2.5k docs, until the configured number of elements (200 atm) has been successfully acquired - or until all rows have been exhausted. This PR adds two new WorkQueueManager configuration parameters:

RowsPerSlice: defining the slice size, i.e., how many rows/elements can be retrieved from workqueue within a single HTTP request;
MaxRowsPerCycle: maximum number of rows/elements to be queried in workqueue. Currently 50k, meaning that if there are more than 50k elements in Available status, those won't be considered for data acquisition (they are, of course, ordered by priority though).

An element "succcessfully" acquired means that:

it passes all the work restrictions, especially matching the resources available
and, during post processing in WorkQueueManager, that it has a priority higher than the workflows already in the queue.

Is it backward compatible (if not, which system it affects?)
YES
Related PRs
None
External dependencies / deployment changes
None

I had to test it in one of the production agents, to make sure it gets tested in the most meaningful scenario (many WQEs, diff priorities, busy agent/jobCounts, etc). I consider these tests successful, and from the logs below, we can see that it keeps iterating until numElem or total_rows is reached:
2023-01-26 21:01:18,448:140557188196096:INFO:WorkQueueBackend:Getting up to 200 available work from https://cmsweb.cern.ch/couchdb/workqueue
2023-01-26 21:01:18,448:140557188196096:INFO:WorkQueueBackend:  for team name: production
2023-01-26 21:01:18,448:140557188196096:INFO:WorkQueueBackend:  with excludeWorkflows count: 0
2023-01-26 21:01:18,448:140557188196096:INFO:WorkQueueBackend:  for thresholds: {'T2_US_Caltech': 252.5, ...}
2023-01-26 21:01:18,448:140557188196096:INFO:WorkQueueBackend:  with limit docs: 2500
2023-01-26 21:01:18,448:140557188196096:INFO:WorkQueueBackend:  and skip first docs: 0
2023-01-26 21:01:24,212:140557188196096:INFO:WorkQueueBackend:Retrieved 85 elements from workRestrictions list for: https://cmsweb.cern.ch/couchdb/workqueue
...Accepting a bunch of workflows ...
2023-01-26 21:01:24,221:140557188196096:INFO:WorkQueueBackend:  with limit docs: 2500
2023-01-26 21:01:24,221:140557188196096:INFO:WorkQueueBackend:  and skip first docs: 2500
2023-01-26 21:01:30,630:140557188196096:INFO:WorkQueueBackend:Retrieved 2500 elements from workRestrictions list for: https://cmsweb.cern.ch/couchdb/workqueue
2023-01-26 21:01:30,869:140557188196096:INFO:WorkQueueBackend:  with limit docs: 2500
2023-01-26 21:01:30,870:140557188196096:INFO:WorkQueueBackend:  and skip first docs: 5000
2023-01-26 21:01:38,527:140557188196096:INFO:WorkQueueBackend:Retrieved 2500 elements from workRestrictions list for: https://cmsweb.cern.ch/couchdb/workqueue
2023-01-26 21:01:38,784:140557188196096:INFO:WorkQueueBackend:  with limit docs: 2500
2023-01-26 21:01:38,784:140557188196096:INFO:WorkQueueBackend:  and skip first docs: 7500
2023-01-26 21:01:47,928:140557188196096:INFO:WorkQueueBackend:Retrieved 2341 elements from workRestrictions list for: https://cmsweb.cern.ch/couchdb/workqueue
2023-01-26 21:01:48,089:140557188196096:INFO:WorkQueueBackend:Accepting workflow: pdmvserv_task_SMP-RunIIFall18GS-00029__v1_T_221213_030638_1919, with prio: 70005, element id: 7dd9c4860f218f0fa688db6c865ee371, for site: T2_US_Florida
2023-01-26 21:01:48,124:140557188196096:INFO:WorkQueueBackend:And 42 elements passed location and siteJobCounts restrictions for: https://cmsweb.cern.ch/couchdb/workqueue
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:Assigned work to the child queue for:
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:    11 elements for: cmsunified_task_TAU-RunIISummer20UL16wmLHEGENAPV-00021__v1_T_230126_145940_3018
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:    1 elements for: cmsunified_task_HIG-RunIISummer20UL17wmLHEGEN-12349__v1_T_230126_153113_9874
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:    1 elements for: cmsunified_task_HIG-RunIISummer20UL16wmLHEGEN-13167__v1_T_230126_152920_2680
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:    1 elements for: cmsunified_task_B2G-RunIISummer20UL16wmLHEGENAPV-04172__v1_T_230126_150640_2473
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:    1 elements for: cmsunified_task_SMP-RunIISummer20UL16wmLHEGEN-00589__v1_T_230126_150421_1622
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:    1 elements for: cmsunified_task_SMP-RunIISummer20UL16wmLHEGEN-00586__v1_T_230126_155044_4584
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:    1 elements for: cmsunified_task_HIG-RunIISummer20UL16wmLHEGEN-13164__v1_T_230126_155906_5462
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:    24 elements for: cmsunified_task_TAU-RunIISummer20UL16wmLHEGEN-00015__v1_T_230126_155715_8597
2023-01-26 21:01:48,293:140557188196096:INFO:WorkQueue:    1 elements for: pdmvserv_task_SMP-RunIIFall18GS-00029__v1_T_221213_030638_1919
2023-01-26 21:01:48,294:140557188196096:INFO:WorkQueueManagerWorkPoller:Obtained 42 unit(s) of work

@todor-ivanov the 3rd commit in this PR has the changes that you requested in your review (I still need to test them though).

No code changes applied in my last commit, I was just squashing all the 3 initial commits together.

@vkuznet Valentin, I was forgetting to use the new parameters when fetching data from the parent queue (they were applied only when fetching data from the local queue). I made the relevant changes and they are available in this 2nd commit, in case you want to have a look:
https://github.com/dmwm/WMCore/pull/11457/commits/87452dbbce4787d8cdfc2f2af607d1c69dcf81b0

Unit test failure comes from an unstable test. Merging it and will get it backported to the wmagent branch.


0.9.1 not in Gradle plugin portal

The Gradle plugin portal shows 0.9.1 as the latest version of the plugin, but apparently 0.3.4 is the latest version.
This build.gradle (still under development) produces this error:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'kafka-streams-demo'.
> Could not resolve all files for configuration ':classpath'.
   > Could not find com.commercehub.gradle.plugin:gradle-avro-plugin:0.9.1.
     Searched in the following locations:
         https://plugins.gradle.org/m2/com/commercehub/gradle/plugin/gradle-avro-plugin/0.9.1/gradle-avro-plugin-0.9.1.pom
         https://plugins.gradle.org/m2/com/commercehub/gradle/plugin/gradle-avro-plugin/0.9.1/gradle-avro-plugin-0.9.1.jar
     Required by:
         project :

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

Is 0.9.1 out there anywhere? :)

0.10.0 is actually the latest, and is published to JCenter, as will future versions. I believe that 0.9.1 is correctly published to the plugin portal, but I'll check once I get back from vacation on October 10.

 I can't seem to build with 0.10.0 either, so I think there's a problem with what's in the portal, but we'll get this figured out when you get back. I currently have it working with a Maven build for the Avro stuff and Gradle for everything else, so it is not a huge hurry (other than wanting to expunge the pom.xml from my repo as anyone might).

Looks like 0.9.1 is broken due to a plugin portal issue; submitted https://discuss.gradle.org/t/gradle-avro-plugin-0-9-1-missing-artifacts/24423 to attempt to address.

https://github.com/tlberglund/streams-movie-demo/pull/1 has what appears to be a working example of using version 0.10.0

0.9.1 was broken in the Plugin portal (due to a bug we had with the publishing plugin)
I've removed 0.9.1 from the portal, so you should be ok to publish this, or a later version.
I have checked, and 0.9.0 is ok and has the expected artifacts

0.9.1 has been re-published to the plugin portal, and I've verified with a test project that it now appears to be resolvable.

Works for me now as well. Thank you!

@davidmc24  - can this one be reopened - seems that https://plugins.gradle.org/plugin/com.commercehub.gradle.plugin.avro contains out-of-dated version

@mykolapolonskyi Per @davidmc24 's comment on Oct 4, 2017, releases are now published to JCenter rather than the Gradle plugin portal. Per CHANGES.md, 0.9.1 was the last version published to the Gradle plugin portal. I believe the Usage section of the README does show how to pull versions > 0.9.1 into a Gradle project. Here's the most trivial working example project I could come up with: https://github.com/mhurne/gradle-avro-plugin-test

@mhurne hi
And now - Im fully confused - maybe was wrong completely misunderstand this block Alternatively, if you prefer to use the incubating plugins DSL, see the following example: - Im using kotlins dsl and I should use this block firs of all. but I thought that this block is for use snapshots repo.
my miss, probably, tnx for help!

I see - the statement "Alternatively, if you prefer to use the incubating plugins DSL, see the following example" is referring to Gradle's plugins DSL which is in incubating, not an incubating feature of gradle-avro-plugin.


GAPIC samples: support subfield and optional parameter init values

What
Currently Python GAPIC samples only initialize top-level fields on the request message that are marked as "required". This feature request is to enable initializing optional fields and subfields (i.e., fields of message fields).
Why
Samples are more helpful when they mirror actual use. Some API calls in practice require complex initialization of the request message, and in these cases, our generated samples are not as helpful as they should be. (See, for example, cloud vision.)
How
Assuming that Python is not yet on the MVVM architecture:

Modify PythonImportHandler for snippets to read the init values from config and add their imports, instead of relying on required fields.
Verify that method_sample.snip can pick up optional fields and subfields to be initialized from the GAPIC config.

/cc @bjwatson @Landrito

@geigerj @lukesneeringer Is this still relevant?

The sample generator handles subfields now (test example), so I don't think so.


Update to 1.1.2

Note that tests currently fail due to: https://github.com/akkadotnet/akka.net/pull/2338
But I have verified that the plugin still works as normal.


Bump service version from 2.9.4 to 2.9.5

Coverage remained the same at 99.759% when pulling 96d183a81ed283aec8fc8b823b4334b32a3b301a on release-2.9.5 into 499f5b5a28faaae0a3c2210ff17d71c550b4b793 on main.


Update Readme

Add more information about the project

[x] Add information regarding tech stack used
[x] Add Release Feature updates for the API
[x] Add use case
[x] Add description about the routes for the api
[x] how to locally deploy the API
[x] Contribution.md
[x] About the Author

7629d99954e74b99d95a681ce4c1a04972ab590b solved this
LGTM 🌈
Closing 😄


WIP: CI TEST: DO NOT MERGE

Signed-off-by: Francesco Romani<EMAIL_ADDRESS>
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

bogus PR, with unintended testing changes.


Rename JsonFields.h to jss.h:

At this point all of the jss::* names are defined in the same file.  That file has been named JsonFields.h.  That file name has little to do with either JsonStaticStrings (which is what jss is short for) or with the text "jss".  The file is renamed to jss.h so the file name better reflects what the file contains.
All includes of that file are fixed.  A few include order issues are tidied up along the way.
Include order rules:

If the including file is a cpp file and it has a corresponding .h file, the corresponding .h file should be included first.  This assures that the corresponding .h file stands alone.

In general, more specialized includes should come before less specialized includes.  For example, local includes come before boost includes which come before standard library includes.

Within groupings of includes, files should be listed alphabetically.  This makes it easier to find duplicate include files.

I didn't look for (or fix) all include order issues.  But if I spotted something in the area I was touching I tried to fix it up.
This would be considered a trivial pull request except for the large number of files touched.  No (intentional) risky changes are included.
Travis is failing consistently with timeouts.  I don't believe those failures are a result of these changes.

Jenkins Build Summary
Built from this commit
Built at 20190401 - 04:43:25
Test Results

Build Type
Log
Result
Status

msvc.Debug
logfile
1158 cases, 0 failed, t: 604s
PASS :white_check_mark:

gcc.Release -Dassert=ON, MANUAL_TESTS=true
logfile
915 cases, 0 failed, t: 5m12s
PASS :white_check_mark:

docs, TARGET=docs
logfile
1 cases, 0 failed, t: 0m1s
PASS :white_check_mark:

gcc.Debug -Dcoverage=ON, TARGET=coverage_report, SKIP_TESTS=true
logfile
1158 cases, 0 failed, t: 16m57s
PASS :white_check_mark:

clang.Debug
logfile
1158 cases, 0 failed, t: 2m59s
PASS :white_check_mark:

clang.Debug -Dunity=OFF
logfile
1157 cases, 0 failed, t: 1m18s
PASS :white_check_mark:

msvc.Debug, NINJA_BUILD=true
logfile
1158 cases, 0 failed, t: 651s
PASS :white_check_mark:

gcc.Debug
logfile
1158 cases, 0 failed, t: 3m6s
PASS :white_check_mark:

clang.Release -Dassert=ON
logfile
1158 cases, 0 failed, t: 4m55s
PASS :white_check_mark:

gcc.Debug -Dunity=OFF
logfile
1157 cases, 0 failed, t: 11m42s
PASS :white_check_mark:

gcc.Release -Dassert=ON
logfile
1158 cases, 0 failed, t: 5m11s
PASS :white_check_mark:

rpm
logfile
1158 cases, 0 failed, t: n/a
PASS :white_check_mark:

gcc.Debug -Dstatic=OFF
logfile
1158 cases, 0 failed, t: 3m3s
PASS :white_check_mark:

msvc.Debug -Dunity=OFF
logfile
1157 cases, 0 failed, t: 1159s
PASS :white_check_mark:

gcc.Debug -Dstatic=OFF -DBUILD_SHARED_LIBS=ON
logfile
1158 cases, 0 failed, t: 3m5s
PASS :white_check_mark:

gcc.Debug, NINJA_BUILD=true
logfile
1158 cases, 0 failed, t: 3m0s
PASS :white_check_mark:

msvc.Release
logfile
1158 cases, 0 failed, t: 422s
PASS :white_check_mark:

clang.Debug -Dunity=OFF -Dsan=address, PARALLEL_TESTS=false, DEBUGGER=false
logfile
1157 cases, 0 failed, t: 11m18s
PASS :white_check_mark:

clang.Debug -Dunity=OFF -Dsan=undefined, PARALLEL_TESTS=false
logfile
1157 cases, 0 failed, t: 12m26s
PASS :white_check_mark:

The travis issue is because you're trying to build both boost and rippled on a weak build machine in under 50 minutes. Once a build succeeds, it would cache the boost build and then rippled (barely) should manage to build in 40-50 minutes on Travis-CI too.


Can't install on LM20: Cannot add PPA: ''This PPA does not support focal''.

I've moved up to Mint 20 on a new machine and need to install drive (which I rely on a lot).
Installation falls at the first hurdle:
sudo add-apt-repository ppa:twodopeshaggy/drive
results in
Cannot add PPA: ''This PPA does not support focal''.

The repo seems to have been abandoned for some time.
Download a suitable executable from here...
https://github.com/odeke-em/drive/releases/tag/v0.4.0
Mark the file as executable
Reverence it directly or put it in $HOME/bin folder to execute.
Note that it displays its version number as <IP_ADDRESS>
test by $ drive version
regards CB

The repo seems to have been abandoned for some time.
Download a suitable executable from here...
https://github.com/odeke-em/drive/releases/tag/v0.4.0
Mark the file as executable
Reverence it directly or put it in $HOME/bin folder to execute.
Note that it displays its version number as <IP_ADDRESS>
test by $ drive version
regards CB

Thank you @CountryBumkin! @endicay thanks for filing this issue, but the PPAs are out of my control, and as @CountryBumkin showed, please tag a look at the released binaries, or build using Go. I am going to close this issue as there isn't more I could do here.
Wish you both a happy New Year, and thank you for using drive!

Thank you @CountryBumkin! @endicay thanks for filing this issue, but the PPAs are out of my control, and as @CountryBumkin showed, please tag a look at the released binaries, or build using Go. I am going to close this issue as there isn't more I could do here.
Wish you both a happy New Year, and thank you for using drive!


feat: add content es/portability

Closes https://github.com/cncf/glossary/issues/695

/lgtm

/lgtm


dependency management

Running go get ./... strikes me as not the greatest thing to be doing, any thoughts on using a package manager to handle the deps?
I ran dep init . and found many of the dependencies to have sane versions released.

@mmlb pls post more details about this.

@mmlb it's not necessary, thanks!

@mehrdadrad can you expand on why you think it is not necessary? If build vflow today I have no guarantees that when I go to build it next month that it will build again. Both sarama-cluster and gopkg.in/yaml are at major version 2 which is evidence of this happening once before and possible in the future.


Dont send storage.vol.remove event for root vols

Related but not tightly coupled to this PR: https://github.com/rancher/agent/pull/103

NOPE. THiS IS BAD. DO NOT MERGE.


get one transaction

used to generate the PDF on the website

@asood123 can I merge this? Should I just go ahead while you are on holidays?

Merging because Aseem is off.


added ability to skip opening of profile

Thanks @crylico, using include? totally makes sense, no idea why I missed that.


Styling the current day/time indicator

I need to be able to shade in the current day on month view and the current time on the day and week view. Being able to restyle this as we want would be helpful. Also, on your demos, the current time on day and week view is bolded. It does not show up that way for me.

you can use css to style stuff, the current day/time cells have a rbc-now class

I'm kind of stuck with this also. The thing is that the cell rbc-day-bg doesn't receive rbc-now class, only rbc-date-cell does. I actually don't know why cell and date label are separated into different DOM branches, I would suggest putting date label into the cell's div and having 'rbc-now' on the cell.

You can make the rbc-now cell to have a background color and make it position absolute.


Controller module + loop=true causes destroy() to crash

Check that this is really a bug

[X] I confirm

Reproduction link
https://codesandbox.io/p/sandbox/swiper-react-infinite-loop-forked-04uv5n?selection=[{"endColumn"%3A18%2C"endLineNumber"%3A51%2C"startColumn"%3A18%2C"startLineNumber"%3A51}]&file=%2Fsrc%2FApp.jsx
Bug description
I know this issue likely goes outside the bounds of React but since I only have reproduction case for React I thought I'd just put it here.
The issue is fairly simple in nature.
When using the Controller module and loop=true together the component crashes when unmounted.
Expected Behavior
No error thrown
Actual Behavior
An error is thrown
Swiper version
9.1.0 as well as 9.0.5
Platform/Target and Browser Versions
Test case in Chrome on windows. Error observed via Sentry in a multitude of browsers on both iOS and Android.
Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a Swiper issue and not a framework-specific issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

@nolimits4web this still occurs in the reproduction example on the latest version of Swiper.
I forgot to mention that to make the error consistently occur, you need to Swipe over to a slide that's part of the loop feature (e.g swipe back one from the first slide slide forward until you hit the first slide again).

Hey, main account here.
Looking at the issue it looks like this is primarily connected to the controller system performing actions on controls without checking if they're still around. I'm gonna have a crack at fixing it the best I can but a closer look would be greatly appreciated as I'm not very familiar with the architecture of this library.


Langchain / llama_hub integrations

Describe changes
We implemented several materializers that allow you to use Langchain / LlamaIndex code in your ZenML pipelines:

LangchainDocumentMaterializer for Langchain documents
LlamaHubDocumentMaterializer for LlamaIndex documents
LangchainVectorStoreMaterializer for Langchain vector stores
LlamaIndexGPTIndexMaterializer  and LlamaIndexGPTFaissIndexMaterializer for LlamaIndex indices (equivalent to vector stores in Langchain)

TODO

Fix pyyaml version mismatch
Try to replace pickle
Tests
Docs
Integrations webpage

Pre-requisites
Please ensure you have done the following:

[x] I have read the CONTRIBUTING.md document.
[ ] If my change requires a change to docs, I have updated the documentation accordingly.
[ ] If I have added an integration, I have updated the integrations table and the corresponding website section.
[ ] I have added tests to cover my changes.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Other (add details above)

(Just getting the CI to run to check pyyaml. Not ready for reviews yet).


\d+ not supported in Hugo

\d+ regex doesn't work in findRE.
Example:
{{ if findRE "reading\/\/d+" .Slug }}
Input of findRE:
reading/
reading/123
reading/123/245
reading/3241/5352

The regex pattern is reading\/\/d+
Expected Output:
reading/123
reading/123/245
reading/3241/5352

Error Output:
ERROR 2018/12/23 21:12:03 Failed to add template "_default/single.html" in path "_default/single.html": template: _default/single.html:9: invalid syntax
ERROR 2018/12/23 21:12:03 _default/single.html : template: _default/single.html:9: invalid syntax
ERROR 2018/12/23 21:12:03 _default/single.html : template: _default/single.html:9: invalid syntax

Stack overflow that I asked:
https://stackoverflow.com/questions/53908925/regex-adding-a-url-path-except-the-current-one-im-at

Please use https://discourse.gohugo.io/ for questions/troubleshooting. Also see  Hugo Documentation.


[Enhancement] Add exit dialog when entering passphrase

Enhancement made:

Issue #510
Updated test suite accordingly

Description
When entering a long passphrase, one can push accidentally the back button, so an exit dialog is added to prevent the accidentally loss of all the work to type in a long passphrase.
A new Warning Screen view is added:

The actual dialog may be a bit too sober and could be modified to a more friendly "Are you sure you want to cancel?"
This pull request is categorized as a:

[x] New feature
[ ] Bug fix
[ ] Code refactor
[ ] Documentation
[ ] Other

Checklist

[x] I’ve run pytest and made sure all unit tests pass before sumbitting the PR

If you modified or added functionality/workflow, did you add new unit tests?

[ ] No, I’m a fool
[x] Yes
[ ] N/A

I have tested this PR on the following platforms/os:

[x] Raspberry Pi OS Manual Build
[ ] SeedSigner OS on a Pi0/Pi0W board
[ ] Other

Note: Keep your changes limited in scope; if you uncover other issues or improvements along the way, ideally submit those as a separate PR. The more complicated the PR the harder to review, test, and merge.

Check passed 😀✅

Since a release is around the corner (currently targeting Monday July 8th for finalization of all prs), please consider joining the SeedSigner Community group on telegram and/or the SeedSigner New Devs group to argue for this pr.
And thank you for contributing.

As of 59bcfda:
ACK for the concept because what's the point of a bip39 passphrase if its not a strong one? and this is useful for that
ACK on the code review
ACK tested on rpi0 dev device
ACK on one more new contributor to the next release...
But I still think improvements might be made on the title/text,
AND I'd like to have input from other devs.
Thank you Alroble!

Thank you for the comments, @jdlcdl! I thought this would be a good first issue to learn about SeedSigner dev environment.
I'd love to join the Telegram groups and get more involved around here. How can I join?

Duh, I didn't even include the links. :p
https://t.me/seedsigner_new_devs for new devs, most appropriate for dev discussions
https://t.me/joinchat/GHNuc_nhNQjLPWsS for the main SeedSigner Community discussions.

The new proposed screen is the following:

The texts were improved as @jdlcdl suggested
The button position was swapped to avoid (again) accidentally exiting

w/o altering my comments above,
I repeat my ACK tested at 1670bf6

Love this, @alvroble. Solid enhancement that will help reduce mistakes.
Looking at the other messaging screens, I’d recommend content like this to align with the rest of the UX, specifically the “Discard Seed” dialog:

We use "discard" elsewhere, and "keep/discard passphrase" clarifies the specific actions and aligns with the rest of the content.
Thanks for your contribution!

Thanks @easyuxd for the comment.
I agree to mantain the UX alignment. However, maybe a better text fo the "Continue editing" button would be "Edit passphrase" instead of "Keep passhprase", because when you push that button you are not specifically keeping the passphrase you were writing, you are just going back to continue editing it. What do you think?

@alvroble
Agreed, "Edit" makes more sense here. Good catch!

@easyuxd
Updated in the new commit.  Thanks for the feedback!

Looking pretty good!
Minor note on the warning text: "Discard passphrase and go back" has two small issues:

The top title is already "Discard passphrase?" so it's repetitive to reiterate the same phrase in the body.
"and go back": I'm sure most people will understand based on the context, but it would be reasonable for a user to think, "I want to go BACK to entering my long passphrase".

So... I'm not sure what text should go in the body.

Thanks @kdmukai! I understand, it's kind of tricky because of the context and limited space.
Maybe something like: "Your current passphrase entry will be erased. Proceed?"

Maybe something like: "Your current passphrase entry will be erased. Proceed?"

I like this language. I do think it's a good practice to repeat the action, at least in the H1 and the CTAs -- it should be clear to users what their action is without having to read the whole screen, with the body copy as added context.

Currently working in the dict approach as @kdmukai suggested. Regarding the warning screen, the text I proposed fits in three lines, which doesn't look quite right. Since we are already asking in the title, I removed the "Proceed?" to make it better looking. @easyuxd what do you think?

as of d7efbb3
ACK tested
@alvroble, great job on being responsive and flexible with others, and thank you.

Just merged and tested after resolving some conflicts with the current dev branch

tACK
closes #510


[ci] Soft fail Entrypoints, Samplers, LoRA, Decoder-only VLM

A lot of tests broke due to transformer upgrade to 4.45 following Llama3.2 release. Soft-failing tests until they are fixed so we don't block CI

https://github.com/vllm-project/vllm/pull/8829 is hopefully now ready which will fix all of these, just waiting for the tests to finish.


Raise a validation error if multiple query parameters are specified for non-List fields

As of now, at least flaskparser, not sure about the others, fetches anything other than the first query parameter only if the field is a List. I think an error should be raised if multiple query parameters or headers are passed and only one value is expected by the schema, at least by default.

I'm not sure about this. I understand why you would want an error to be returned. On the other hand, "Generous on input, strict on output" could be considered a valid rule of thumb.
I welcome other user's feedback on this.
For the time being, one workaround would be to override querystring parsing.
from webargs import core
from webargs.flaskparser import FlaskParser

class Parser(FlaskParser):
    def parse_querystring(self, request, name, field):
        if len(request.args.getlist(name)) > 1 and not core.is_multiple(field):
            raise core.ValidationError(
                'Multiple values provided for "{}". Expected one value.'.format(name),
                field_names=[name],
                fields=[field]
            )
        return super().parse_querystring(request, name, field)

The problem with accepting multiple values where only one is expected is that there's an ambiguity about which option should work, e.g if user does ?delete=true&...&delete=false I would really refuse the temptation to guess or rely on the fact that normal parsers would reliably return the first value all the time. For all we know, the user might just be writing a long query manually and forget to remove one copy-pasted query parameter.
DTRT principle resonates with me, so using "sane defaults" and allowing "1, 0, T, F, Y, N, TRUE, FALSE, YES, NO, etc." feels fine. It kind of makes sense to accept ?delete=true&...&delete=1 when you expect only one value, because there's no ambiguity. However I'd expect such situations to be quite rare and probably not worth the complexity of deserializing multiple values and ensuring that all inputs are equivalent.

Fair points. I do not feel strongly in favor of allowing multiple values for singular fields, so I would likely accept a PR implementing this change.
I'm not sure whether to consider this a breaking change or not. Depends on what we assume to be the expected behavior.

Closing this for now. Feel free to reopen if there is still interest in changing this.


URL calendar no name, events won't show up

I'm trying to set up a URL calendar on Google.
I have another one working fine but this one just doesn't work with gcalcli...
Here is how I added it on calendar.google.com

I named it 'epita':

Here is what I get from gcalcli
λ gcalcli --nocache list
 Access  Title
 ------  -----
  owner  life
 reader  https://acu.epita.fr/chronos/calendars/CSI.ics
 reader  LRDE
 reader  Anniversaires
 reader  Jours fériés en France
 reader  Numéros de semaine

λ gcalcli agenda --calendar epita

No Events Found...

λ gcalcli agenda --calendar https://acu.epita.fr/chronos/calendars/CSI.ics

No Events Found...

Delete your $HOME/.gcalcli_cache file or use the --nocache option.  The only thing that is cached today is the list of calendars.


Suggestion for the Project

Block_latter.txt
We can also print all letters by using the triple inverted comma to print multiline strings.

great idea shubham! adding

great idea shubham! adding


Reorg Parameter notebooks and add basic complex numbers notebook

As a warm-up exercise for extending plot_by_id to handle complex input, I made a small notebook about complex-valued parameters. We might as well get that in. And we might as well move the notebooks a bit about, now that we're at it.
The notebook doesn't use the dataset, and should as such live at the "top level".
Changes proposed in this pull request:

Add a little notebook about complex-valued parameters. In practice, that means the ComplexNumbers and the Arrays validators

@QCoDeS/core

Looks good. Since we have learned that sphinx does not always check links to notebooks can you grep and make sure that there are no now broken links to these notebooks?

Perhaps this notebook https://qcodes.github.io/Qcodes/examples/writing_drivers/Simple-Example-of-ParameterWithSetpoints.html should be moved there too

@WilliamHPNielsen Should we get this in? Would be nice to ,move that other notebook

I have moved that notebook and updated all links in the documentation that points to any of the moved notebooks


New unit tests

My second attempt to close #91. This time hardly anything changed but the unit tests itself. I did not squash the commits in #101, because the changes made to other files messed things up. So this is simply one commit replacing the old unit tests with a whole bunch of new unit tests. Would that be okay for you, @scelis?

This looks great. Thanks for breaking this out from the other pull request. A single commit is fine here.


Invalid html crashes post-parsing of data

I tried converting on my DO droplet tonight, and one of the posts caused the process to crash. I'm not sure where to fix the error, I just got this error:
8/3 03:00 [10791] - error: DOMException: Invalid character: "href"http:" did not match the Name production: Expected "-", ".", ":", "\xB7", "_", [0-9], [A-Z], [\u0300-\u036F], [\u0370-\u037D], [\u037F-\u1FFF], [\u200C-\u200D], [\u203F-\u2040], [\u2070-\u218F], [\u2C00-\u2FEF], [\u3001-\uD7FF], [\uD800-\uDB7F], [\uF900-\uFDCF], [\uFDF0-\uFFFD], [\xC0-\xD6], [\xD8-\xF6], [\xF8-\u02FF], [a-z] or end of input but "\"" found.
    at exports.name (.../nodebb/node_modules/nodebb-plugin-import/node_modules/bbcode-to-markdown/node_modules/to-markdown/node_modules/jsdom/lib/jsdom/living/helpers/validate-names.js:10:11)
 ....

some more forgiving error handling should happen, or it should point to the offending post somehow

hmm .. well, if it fails.. i think i should throw a warning and don't convert the post, is that Ok you think?

I think that would be more appropriate. An output of the problematic post
content and id would be even more helpful
On Mon, Mar 21, 2016 at 8:45 AM Aziz Khoury<EMAIL_ADDRESS>wrote:

hmm .. well, if it fails.. i think i should throw a warning and don't
convert the post, is that Ok you think?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/akhoury/nodebb-plugin-import/issues/179#issuecomment-199347572


Migrate ListPagerAdapter to kotlin

Description
Convert codebase from java to kotlin
Issue Resolved
Fix #66
Screenshots
Provide some screenshots of the changes made (if applicable).
Checklist
Please make sure to review the following before submitting your PR:

[x] I have read the contribution guidelines.
[x] I have read the code of conduct.
[x] I have reviewed my submission in detail.

lgtm thanks for your work 💯


[1.10.2] SkeletonTrap

How do i make these http://minecraft.gamepedia.com/Horse#Skeleton_trap unable to spawn inside a claim
the flag entity-spawn is set to false, but they still spawn
using:
spongeforge-1.10.2-2052-5.0.0-BETA-1675
forge-1.10.2-<IP_ADDRESS>5-universal
PermissionsEx-Sponge-2.0-SNAPSHOT-b140
griefprevention-1.10.2-<IP_ADDRESS>

@FiveEYZ This sounds like a bug with sponge 1.10.2 as GP just listens for the spawn event and cancels as required.

@FiveEYZ This should be fixed in SF 1793+


add local-build cmd

change makefile to be easy to use .

[ x ] Make a local lib so that we needn't to install libs into system
[   ] replace ci-config file by makefile( it's not import , so that you can merge this PR .)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

@wayslog Thanks for your contribution! Please sign the CLA.

@shenli  , signed

LGTM

PTAL @siddontang

@wayslog Ping

@ngaut ，pong . Sorry , I was a little busy now . After get everything gone , I will fix it .


Update free-programming-books-bn.md

line 2 and line 50 links are replaced
What does this PR do?
Add resource(s) | Remove resource(s) | Add info | Improve repo
For resources
Description
Why is this valuable (or not)?
How do we know it's really free?
For book lists, is it a book? For course lists, is it a course? etc.
Checklist:

[ ] Read our contributing guidelines.
[ ] Search for duplicates.
[ ] Include author(s) and platform where appropriate.
[ ] Put lists in alphabetical order, correct spacing.
[ ] Add needed indications (PDF, access notes, under construction).
[ ] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

Thanks, and welcome to free-programming-books!


HTMLFileContent and component for extracting IDL fragments

This work is towards #41. This PR is dependent on foam-framework/foam2#415 and foam-framework/foam2#423

Refactor is complete. The test will not pass until foam-framework/foam2#415 and foam-framework/foam2#423 are merged into the beta-1 branch.

Codecov Report

Merging #46 into master will increase coverage by 0.33%.
The diff coverage is 98.14%.

@@            Coverage Diff             @@
##           master      #46      +/-   ##
==========================================
+ Coverage   94.32%   94.66%   +0.33%
==========================================
  Files          81       83       +2
  Lines         564      618      +54
==========================================
+ Hits          532      585      +53
- Misses         32       33       +1

Impacted Files
Coverage Δ

config/files.js
100% <ø> (ø)
:arrow_up:

lib/org/chromium/webidl/IDLFileContents.js
100% <ø> (ø)
:arrow_up:

lib/org/chromium/webidl/HTMLFileContents.js
100% <100%> (ø)

lib/org/chromium/webidl/IDLFragmentExtractor.js
98.11% <98.11%> (ø)

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 441f1c5...ad7669e. Read the comment docs.

All requested changes should be made by now. @arobins please let me know if you have any feedback the latest set of changes and comments.

LGTM. @mdittmer should probably look over it as well, because I'm definitely not a FOAM expert.


support new UMP message types that were added in June 2023 spec. updates

With the latest additions to the library, I can say we support June 2023 updates. Ideally more (like high-level flex data parser), but we can add them later (when we need them).