iFrame video not resizeable?

Hi, thanks for your work on this lib!
Image resizing is working great, but iframe videos don't. Should videos be able to be resized? I see data-blot-formatter-unclickable-bound="true" is set on the iframe. Is that to prevent play so it can be resized or is that to prevent resize? Am I missing something obvious?

Thanks for your time!

Hi. Are you using the v2.1.2 code from the repository or the published version (v2.1.1)? I didn't quite get to finishing testing the v2.1.2 code yet (which is why it isn't published yet). v2.1.1 should resize iframes fine (Code Pen).
There is a change in 2.1.2 that dismisses the overlay if you click outside of the editor, but I missed the fact that the thumbnail overlay for iframes is created at the end of the doc body - this is what gets clicked on when you click the video embed. I'll update it first thing Monday morning before I publish the new version.
The data-blot-formatter-unclickable-bound="true" is just for handling the thumbnail click events.
I'll let you know here when it's up.

I've updated the repository with the beta fix - I just need to do a complete round of testing before it's published. There's a small tweak to the css included that I also picked up, taking fit-content out of iframe-align-center - some YouTube videos weren't resizing properly with this (it's only needed for the inline image format).

Good points! I've included those in the new version.

I've added a note to the readme re the proxy image - I didn't include it in the css as it has the potential to interfere with other elements, particularly with toolbars (it needs a lower z-index than the toolbar in case the proxy image scrolls up, or it needs the quill container to have overflow hidden). I've left it as a conscious design decision.
I've changed the proxy image logic to only create an image if one doesn't already exist. In your case, it will leave one proxy image once the modal is dismissed but no more. I looked at removing if the editor is destroyed - too much potential for breakage and it means expanding the scope to introduce a document mutation observer. Better to keep it simple. If you need the image gone completely you can add a call to your modal dismissal to remove any 'img.blot-formatter__proxy-image' remaining.
I could replicate your overlay issue by making the quill root scrollable with a max-height. I've added listeners for scroll and resize on the quill.root element (.ql-editor) which will reposition the overlay in response. I couldn't see which was your scrolling element in the vid - in case it's not the quill.root, you can add your own scroll listener and call repositionOverlay() on the blot formatter instance. The overlay sits in the quill.container element - I'd recommend setting overlay: hidden; on that one to ensure the overlay isn't displayed beyond the editor.

That's all published in 2.1.2 now.
https://github.com/user-attachments/assets/b0c39080-e7a9-4b34-9376-4f6126aaebdf

Hmmm, I can't find anything in the code that expects the iframe to be a direct child of the editor. The overlay is positioned relative to the quill container:
    const parent: HTMLElement = this.quill.root.parentNode;
    const specRect = overlayTarget.getBoundingClientRect();
    const parentRect = parent.getBoundingClientRect();

    Object.assign(this.overlay.style, {
      display: 'block',
      left: `${specRect.left - parentRect.left - 1 + parent.scrollLeft}px`,
      top: `${specRect.top - parentRect.top + parent.scrollTop}px`,
      width: `${specRect.width}px`,
      height: `${specRect.height}px`,
    });

The proxy is repositioned whenever the mouse hovers over an iframe.
The mouse click event that activates the overlay is dependent on the clicked target being an image:
  onClick = (event: MouseEvent) => {
    const el = event.target;
    if (!(el instanceof HTMLElement) || el.tagName !== 'IMG') {
      return;
    }

    this.img = el;
    this.formatter.show(this);
  };

If you add a visible border to the proxy image, do you see it align with the iframe on mouse hover?

I think this is it (I haven't noticed this before, it's from the original code).
export default class IframeVideoSpec extends UnclickableBlotSpec {
  constructor(formatter: BlotFormatter) {
    super(formatter, 'iframe.ql-video');
  }
}

It causes the IframeVideoSpec to look for elements matching 'iframe.ql-video' and sets the mouseenter event listeners on elements that match that.
https://github.com/enzedonline/quill-blot-formatter2/blob/cf4587a27154a1299ac4b08c275f3bd0b9a4a726/src/specs/UnclickableBlotSpec.ts#L94C1-L101C5
onTextChange = () => {
    Array.from(document.querySelectorAll(this.selector))
      .filter((element): element is HTMLElement => !(element.hasAttribute(MOUSE_ENTER_ATTRIBUTE)))
      .forEach((unclickable) => {
        unclickable.setAttribute(MOUSE_ENTER_ATTRIBUTE, 'true');
        unclickable.addEventListener('mouseenter', this.onMouseEnter);
      });
  };

Since your iframe is missing the ql-video class it won't match.
You can either add the ql-video class to your blockEmbed, or extend UnclickableBlotSpec into a custom class with a suitable selector and include that with the ImageSpec in your options as per docs
Something like:
import BlotFormatter2, { ImageSpec, UnclickableBlotSpec } from 'quill-blot-formatter2'

Quill.register('modules/blotFormatter2', BlotFormatter2);

class CustomIframeSpec extends UnclickableBlotSpec {
  constructor(formatter: BlotFormatter) {
    super(formatter, 'div.ql-editor iframe');
  }
}

const quill = new Quill(..., {
  modules: {
    ...
    blotFormatter2: {
      image: {
        registerImageTitleBlot: true
      }
      specs: [
        ImageSpec,
        CustomIframeSpec
      ],
    }
  }
});

^ I haven't tested that but I'm 90% sure it's right 😉
I'll be changing that document.querySelectorAll to quill.root.querySelectorAll next update, shouldn't be searching the whole document.

Just a quick other suggestion that I noticed, currently you can't scroll if the cursor is on top of the overlay. Maybe a way to watch scroll and add pointer-events: none; while scrolling to allow the element beneath to scroll?

The more I dig into this, the more I see that this package wasn't designed with scrollable editors in mind. The proxy was also blocking scroll and not updating position after scroll so that it ended up in the wrong position. Then it could also scroll beyond the end of the document causing the window to start scrolling. This also made me see that the proxy is overlaying areas outside of the editor.
The only way to prevent that was to move the proxy to the quill container then rewrite the positioning formula (did my head in) then listen for wheel events and pass that into the quill root. Scroll doesn't help as it's not fired if the window/ancestor is not in overflow. Can't use pointer events as this enables click events on the iframe. I have my doubts about the necessity of the proxy image, but that's for another time.
I can't replicate your resize issue though and can't see what would cause it. getTargetElement() would only return null if the overlay had been deactivated.
When you say responsive, what is it you want to do? Different behaviour for different screen widths? I'm not sure what you need that can't be addressed with media queries. Maybe send me your custom format, I can try to replicate it and see what's happening.

This is what's preventing the resize:
.ql-video-inner iframe,
.ql-video-inner object,
.ql-video-inner embed {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

Your setting the iframe width & height to 100% in css so the height/width element attributes have no effect.
I could achieve the same behaviour with this though without needing wrappers. It assumes you want aspect ratio 2:1:
const VideoEmbed = Quill.import("formats/video");

class VideoResponsive extends VideoEmbed {
    static create(value) {
        const node = super.create(value);
        node.setAttribute('width', '100%');
        node.style.aspectRatio = 2;
        return node;
    }
}

Quill.register(VideoResponsive);

https://github.com/user-attachments/assets/55470cc3-6b24-4f70-a732-65ae058c1413
(My wifi is snail pace ...)
If you want the width to remain relative to the container after resizing instead of px, you could extend your video BlotSpec.onHide() - delete the height attribute as set the width attribute as a percentage of the current quill.root width if it has a px value.

Great, glad that's working now.
You should really call super in your onHide() as this method takes care of hiding the proxy image and clearing out the unclickable variables.
When I get the v2.1.3 out this week there are a couple of enhancements you can take advantage of - the unclickable selector can be set in the options, the height attribute won't be set if there's an aspect ratio specified (either via style or css) and the responsive class is included in the package and can be registered via options. This would probably eliminate the need for your custom code there.
The onHide() change I was suggesting was about keeping width relative to quill.root width instead of fixed pixel. You could do that with something like:
editorStyle = this.formatter.getComputedStyle(quill.root);
editorWidth = this.formatter.quill.root.clientWidth -
              parseFloat(editorStyle.paddingLeft) -parseFloat(editorStyle.paddingRight);
this.unclickable.width=`${100 * this.unclickable.clientWidth / internalWidth | 0}%`

Maybe I should just add relative resizing as an option.

I'm still getting there ... I've ended up on a major rewrite to flush out a lot of the buggy behaviour from the original, and also sorting out the iframe proxy situation so that it can work with touch screen. Mostly done, hopefully by this weekend if other demands stay away ...

There was a lot more to rewrite than first thought, plus other stuff getting in the way.
Not quite finished testing, but I think it's more or less done.
Relative sizing mode (px or %) can be set per blot via toolbar, or for every resize action on every blot.
Each iframe gets its own proxy now - eliminates all the bugs with the mouse enter event and tracking the cursor, also means it can be used with touch screens now. There's an option to set the style on the proxies which would let you add the z-index there.
You can test the compiled version if you like, downloadable from here. Happy to know if you can find any bugs.
The updated readme is there for reference.

v2.2.0 released now.
Scroll by wheel or touch now sorted.
You can amend video selector and proxy image style with
  video: {
    selector: 'iframe.ql-video',
    proxyStyle: {}
  }

Relative sizing option available (never, by default, by option, or always). For 'by default' or 'by option', a % button is added to the toolbar to change modes.
There is a ton of other updates, worth looking at the change log and readme for stuff that might be useful.


docs: improve / fix documentation

Particularly improves tracing-honeycomb's docs & readme.
Puts more of the doc examples in rustdoc so they can be automatically tested.

Pushed spelling fixes.

Pushed spelling fixes.


Update CLI extensions available doc

Update CLI extensions available doc.
Triggered by Azure/azure-cli-extensions - TRAVIS_BUILD_ID=497839875
https://github.com/Azure/azure-cli-extensions/commit/477859d0a00cb8a2754106da7207698b17b69456

OPS Build status updates of commit 4282347:
:clock10: Preparing: average preparing time is 57 sec(s)

OPS Build status updates of commit 4282347:
:clock10: Incremental building: average incremental building time is 13 min(s) 49 sec(s)

OPS Build status updates of commit 4282347:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-extensions-list.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Outer middlewares

Hi,
One more PR to fine tune the code. The base purpose is to provide an out of the box middleware for request that just clear the context and if activated, tries to push the request object itself.
I updated the task middleware to have the same behaviour.
That may sound redundant with the extractor logic. extractor is actually a specific case of adapter.
What do you think of this ?

cc @aRkadeFR @toopy

Updated.

Updated.

👍


Introduce Oppia proto API v1: Android

Note that this PR was written largely in collaboration with @anandwana001 & @seanlip (see commit history for specific attribution if necessary),
Overview
This introduces the initial version of Oppia's backend proto API, which is currently only spec'd for the Android client.
Design details
Some things in particular to note:

This is introducing the request & response-based structures for both the topic list & individual topic content, based on the latest defined backend specification for Android support
The TopicSummary & related structures include some extra data that the client technically doesn't need for the preview experience: descriptions & thumbnails for stories, and skill IDs. This is primarily to (1) provide sufficient details to the client so that it can correctly download the content it needs, and (2) avoid the need for non-summary structures to be downloaded (all of the data needed for topics & stories are fully captured in these summary structures which simplifies the content download portions a bit).
Compatibility for matching against versions is designed based on the versioning scheme introduced here. See the next section in this comment for more specifics.
The content download API has pagination inherently built in. The client can request multiple structures (of the same or different types), and the backend has the choice of what to respond with. If, for example, the client requests 10 explorations, the backend may choose to only respond with 2 which will prompt the client to request the other 8 in a follow-up request.
Questions are being introduced to ensure they are at least defined, but they won't be used by the GA version of the Android app (per the current roadmap). That being said, they are worth noting because they behave a bit differently from the other structures. Since it's not known how many questions can be associated with a given topic, and that list could eventually be quite large (consider 20-100 skills per topic and dozens of questions per skill), the API is designed to provide the full list of questions separately based on a specific skill ID. This is done in three steps:

First, by receiving the list of skills associated with a topic
Second, by requesting the list of question IDs associated with a given skill (the client expects to receive the full list)
Third, by requesting the questions themselves. This approach does not require pagination since, per the previous design point, the backend has full flexibility over how many questions it decides to provide.

The proto design here favor strong-typing aggressively (hence substantial duplication in the state interaction definitions) to reduce assumptions or validity checks being needed for clients that consume this API (at the expensive of having less generic interoperable code)
The repository is initially being set up to be Bazel compatible (the repository has been confirmed to build) for Java
The layout of the repository facilitates potentially supporting more than just the Android client in the future (or future versions of the Android client with evolved APIs)
The initial proto structure is very focused on the exact needs of the Android client, hence the structures are substantially reduced compared with the total data available for each structure in the backend

Data flow expectations
All data that the Android client needs to fetch is divided into two categories:

The metadata necessary to:

Show the topic list
Provide the user with enough context (topic details) to know whether they want to download/update a topic
Know whether a downloaded topic has an update available
Have sufficient technical context to ensure that topic downloads/updates are fully compatible with the local client

An explicit download/update as initiated by a user

The metadata is expected to always be automatically downloaded, and is a prerequisite to downloading or updating topics since it provides the necessary context for the client to make this availability determination.
Downloading/updating topic list metadata
Topic metadata provides all the context necessary for users to decide to download/update topics, and for the client to actually make this happen. At a high-level, this is:

Lists of topics, stories, chapters, and subtopics/revision cards
Versioning information needed to request specific topic content when downloading/updating (see below sections for specifics on versioning & content downloading)

Metadata is always automatically downloaded by the client when connectivity is available to ensure users have the most up-to-date context. However, there's one key challenge that needs to be accounted for in this design: some of the metadata is tied to versioned structures that can change in incompatible ways. For example, if a new incompatible chapter is added to a story, we don't want to display that chapter since the user wouldn't be able to download it, and this would lead to an inconsistency. Another such scenario is if a story's title is updated without the corresponding topic being downloaded.
To properly account for this, metadata is requested with the client's compatibility context so that the server can ensure that it's only providing compatible results. Further, the response for this metadata will distinguish between metadata for undownloaded topics vs. downloaded ones (so that titles & thumbnails aren't updated for topics that are downloaded until the topic itself is updated).
One other issue that crops up here is the time that the user may need to wait in the client for metadata to be available to display the homescreen. While this design is not stipulating frontend design, it is expected that the client may make use of several techniques to improve this experience, including:

Embedding an initial topic list that's up-to-date as of the time of that app version's launch
Downloading the latest topic list during sign-in to avoid needing to have a loading experience in the home screen
Never updating the topic list after the home screen is loaded until app restart (though this might not actually need to happen if the app only ever exposes update/download availability and never changes metadata for already-downloaded topics)

Downloading/updating topics (content downloading)
While directly user initiated, topics are downloaded/updated piecemeal. Topics consist of potentially thousands of files (dozens to ~hundreds of structures, and hundreds to ~thousands of images). An active design decision is to keep topics fragmented and put the onus for downloading each of these to the client. While this increases complexity, it has the key advantage of making topic downloads highly pausable/restartable by introducing more granularity when downloading the constituent pieces of topics.
The image part of topics are naturally piecemeal since they are separate statically GCS-hosted assets that must be individually downloaded. Structures, on the other hand, aren't quite as composed. To make that more viable, pagination & selection were key design choices in the proto API proposed here. In particular, the API is designed to:

Allow the client to limit how much it can download (based on actual data sizes rather than arbitrary limits)
Allow the client to select exactly the structures that it needs from a single endpoint rather than needing to bounce between multiple endpoints

It's expected that topic content endpoints provide exactly what's requested based on content & structure versions. See the versioning section below for specifics on how versioning is expected to work. Keep in mind that versioning information for topic content is retrieved via metadata (see the section above for more specifics).
Versioning
Versioning starts getting a bit complicated when considering the backend VersionedModels, the model structures themselves, schema structures, proto structures, the API, snapshots of the API, and other things. To try and keep things simple, this design intends to define a separate set of versions that are specific to this API. How these map to Oppia backend's many versions is an implementation detail not actually relevant to this design.
API version
The API itself is versioned and has separate releases. To keep things simple, it has a major & minor version (e.g. 1.0). The major version is represented directly in the directory structure (e.g. 'v1') since the repository could, in the future, house multiple major versions (which is necessary for the backend to maintain long-term backward compatibility with older API versions). The major version is only incremented if a breaking change must be introduced into the API (generally this will only come when we want to make substantial changes to the API/redesign it).
The API's minor version essentially counts the number of releases that major version has been changed. This means we increment the minor version anytime we make a compatible change to the API, and then release it. The main benefit of having distinct releases is it allows the backend & frontends to opt into taking on a particular version of the API. Due to the backward/forward interoperability nature of protobuf, it's unlikely there will ever be an incompatibility so long as structure versions are respected (see below), and even in those cases there should be potential for graceful failures. Note that the minor version is only ever represented in the release numbers and never in code form since it only serves the purpose of cataloging.
Content versions
Content versions are meant to be the version of the entity itself corresponding to a particular structure (such as a topic, skill, or exploration). These are used to track whether there are content updates for a particular structure. These are expected to map exactly to the versions stored in the corresponding structure's VersionedModel in the backend, but how this versioning behaves is up to the backend so long as it's monotonically increasing and positive.
Structure versions
Structure versions correspond to groups of proto structures themselves. These are unique versions to the proto structures and are not shared with schema structure versions in the backend. Generally, these only need to be incremented when a proto structure is updated in such a way that the default data will break existing logical assumptions (thus requiring a data migration). Proto structures should never be updated in an incompatible way (without incrementing the major version--see the API version section above), but sometimes data migrations are necessary and these versions help track when those need to occur. Unlike schema versions in the backend, these are likely to not increment as often since most proto changes can be safely ignored by older clients.
Note that one aspect of this is a bit complicated: some of the substructures are shared across high-level structures (such as SubtitledHtml, or other language-based substructures). To ensure these are properly tracked, some substructures are grouped into their own combined version to track changes. The following are the list of structure types whose versions are tracked:

TopicSummaryStructureVersion
RevisionCardStructureVersion
ConceptCardStructureVersion
ExplorationStructureVersion
QuestionStructureVersion
StateStructureVersion
LanguageStructuresVersion
ImageStructureVersion

A note on interaction versioning
I did want to briefly note that it was discovered during the creation of this PR & structure versions that separate versioning for interactions is not actually needed since, per the strong typing of State's substructures, the structures of individual interactions & how they relate to the exploration/question experience is implied as part of State's structure version. This does not mean the backend won't need additional version tracking for interactions in order to compute compatibility with specific proto State structure versions, but it does serendipitously simplify version tracking at the sub-State level a bit.
Open tasks

[ ] Add documentation comments to all proto, messages & proto fields (assignee: @anandwana001 & @BenHenning)

One example: https://github.com/oppia/oppia-proto-api/pull/1/files#r684713437
Added doc for most of the proto, message, and proto fields. Some of them are left which I didn't understand. I will ask my doubts in today's meeting, assigning for partial review.

[x] Add documentation comments to all BUILD files(assignee: @anandwana001)

Commit 47dfb60f7736af52854700ef4c4b7c09b8333a5c

[x] Add README to capture the versioning scheme outlined above for the repository (assignee: @anandwana001)

Commit a5edbf5a45e4557b5cae4e4cf1d459a2bfd50115

[x] Update README to have oppia-proto-api as the top header (not oppia-android-api) (assignee: @anandwana001)

Commit a5edbf5a45e4557b5cae4e4cf1d459a2bfd50115

[ ] Clarify in the README the release process for the repository (assignee: @BenHenning)
[x] File an issue to add Buildifier & Bazel verification GitHub actions, and to explain exactly what we should be adding to check in this repository (assignee: @anandwana001)

Issue #2

[ ] File issue to describe compatibility checking (specifically, enforcing proto best practices to ensure compatibility is never broken when the API changes) (@BenHenning)

Issue #3

[x] Remove all 'reserved' fields (assignee: @anandwana001)

Commit f6b3210577b2f10679fd1ef3d595465b27cd643a

[x] Rename 'structure version' to 'proto version', and update this PR comment accordingly (assignee: @anandwana001)

Commit b41cf7d71c5644683c15d78bf1f89e5f7b40f2fa

[x] Rename StructureDownloadResult to just DownloadResult (assignee: @anandwana001)

Commit be028d260925471398120fff2f25e230c27e0fe1

[x] Fix the proto indexes in ClientCompatibilityContext ('2' is currently skipped) (assignee: @anandwana001)

Commit 0ab3fc3532350a243dd7075a7d69ab40321e686e

[x] Remove placeholder comments per https://github.com/oppia/oppia-proto-api/pull/1/files#r684714510 (assignee: @anandwana001)

Commit abbdf136119835b0a5b4ca925235dbca5b2c85d2

[x] Rename fields per https://github.com/oppia/oppia-proto-api/pull/1/files#r684714982 (assignee: @anandwana001)

Commit c1e97fde94a2b8e8361b560ea1a9f8251c0ab651

[x] Add new enum per https://github.com/oppia/oppia-proto-api/pull/1/files#r684714738 (assignee: @anandwana001)

Commit 0e921d10f0f3bace12fd2ef5486c9242c9db02f1

[x] Investigate & fix broken message references per https://github.com/oppia/oppia-proto-api/pull/1/files#r685056344 (assignee: @anandwana001)

Nothing is broken, marking it as done.

[x] Investigate & apply needed changes to properly support Python generation per https://github.com/oppia/oppia-proto-api/pull/1/files#r685049638 (assignee: @anandwana001)

Python files are compiling correctly, marking it as done.

@anandwana001 @seanlip PTAL and let me know your initial thoughts. This isn't done yet (a lot of documentation still needs to be added for both the protos and the README), but this is the initial structure. I think it can potentially unblock the immediate next work until the PR can be checked in & an official v1.0 released.

FYI that I will need to follow up on this tomorrow.

@anandwana001 FYI: https://github.com/oppia/oppia-proto-api/pull/1#discussion_r688301637. Thanks!

Will need to take a pass tomorrow.

Evidently I did not take a review pass last Friday. :) Will need to push this back another day or two in favor of the time-sensitive GSoC reviews.

@BenHenning Are you aware of this issue in proto for python?
https://github.com/protocolbuffers/protobuf/issues/5374

Per chat with @BenHenning, deassigning myself until this PR is fully ready for review.

DTO sounds good, but per camel casing rules it would be 'AnswerGroupDto'.
Does that look good as well?
On Tue, Nov 16, 2021 at 7:34 PM Sean Lip @.***> wrote:

@.**** requested changes on this pull request.
In org/oppia/proto/v1/structure/state.proto
https://github.com/oppia/oppia-proto-api/pull/1#discussion_r750854041:

SubtitledText placeholder = 4;

}

// Represents the specific solution available to instances of the fraction input interaction.
message Solution {
option (org.oppia.proto.v1.versions.structure_proto_version_type) = STATE_PROTO_VERSION;

// The base properties of the solution.
BaseSolution base_solution = 1;

// The correct answer for this interaction that should be shown to the user.
Fraction correct_answer = 2;
}

// Represents the specific answer group used by instances of the fraction input interaction.
message AnswerGroup {

Hi @BenHenning https://github.com/BenHenning -- per our discussion
today, maybe we might need to call this ApiAnswerGroup, ApiHint, etc. so
that we can avoid having two classes in the same web python module which
refer to "Hint" (one being the plain Python object class and the other
being the proto representation).
Tbh though -- I don't like the name. The API is the thing that this data
interacts with, and not a description of the data. It's also kind of
generic (we have e.g. the client/server API on Web).
So -- what do you think about AnswerGroupDTO (for "data transfer object"
https://en.wikipedia.org/wiki/Data_transfer_object) instead? From the
Wikipedia page: "The difference between data transfer objects and business
objects or data access objects is that a DTO does not have any behavior
except for storage, retrieval, serialization and deserialization of its own
data (mutators, accessors, parsers and serializers). In other words, DTOs
are simple objects that should not contain any business logic but may
contain serialization and deserialization mechanisms for transferring data
over the wire." -- would you say that that is a good description of what
this is? (This contrasts with a "value object" that is more like our
Python/JS domain objects.)
/cc @anandwana001 https://github.com/anandwana001
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/oppia/oppia-proto-api/pull/1#pullrequestreview-808077721,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADDB3PTHSAKFZKSF7UYTKFDUMMPCXANCNFSM5BVLUYPQ
.

Hi @BenHenning
Could you please check my last 2 commits:

eabbdf2
937c883

I had added the Dto suffix and added 4 explorations in state.proto:
    AlgebraicExpressionInputInstance algebraic_expression_input = 10;
    MathEquationInputInstance MathEquationInput = 11;
    NumericExpressionInputInstance numeric_expression_input = 12;
    NumberWithUnitsInstance number_with_units = 13;

Let me know if these changes are correct.

I am guessing, the rules should only be *Spec and interaction name only be *Instance not the *Dto.
Let me know if this is correct thing I am thinking, I will update in next commit.

Thanks @anandwana001. To correct one thing: I think you mean 'interactions' not 'explorations.
Regarding the changes:

The 'DTO' change looks correct, but we should probably add a follow-up CI check (after this PR) to ensure all messages always end in DTO. Can you please update #2 to include details for such a check?
We shouldn't be including number with units--that isn't supported by the app, and should be actually be removed from android_validation_constants
The new interactions & objects are missing doc strings--please add these (I suggest referencing the other similar fields in the proto file for reference)
I think your math interactions are missing some of the customization arguments (specifically, numeric expression has 'useFractionForDivision', math equation & algebraic expression inputs use both 'useFractionForDivision' and 'customOskLetters'); also, math equation & algebraic expression have an incorrect customization argument 'value'. If it helps, you should reference the interaction's definition files: https://github.com/oppia/oppia/tree/develop/extensions/interactions (e.g. https://github.com/oppia/oppia/blob/develop/extensions/interactions/MathEquationInput/MathEquationInput.py).
Please make sure field names always use snake_case; some don't
The RuleSpec input names could probably be clearer. Suggest 'math_expression' given the type used in the rule templates: https://github.com/oppia/oppia/blob/develop/extensions/interactions/rule_templates.json.
The actual rule specs that we define should correspond to the new PRD not the existing templates since we're changing all three interactions; there's no planned legacy support here so we should design against the final solution on the outset for the proto API


Stop Using With

Is your feature request related to a problem? Please describe.
with is deprecated as it isn't that good for performance.
Describe the solution you'd like
Removing the with statements inside compute. This will make it so that users must use this.whatever instead of whatever.
Describe alternatives you've considered
None
Additional context
This is pretty simple but since it is a breaking change we should probably pile with the other ones in the vdom-refactor branch.

@aidenybai @octetd Thoughts?

Fine by me, keeps a bit of consistency

Also, a bit offtopic but you should join the Discord, this way we can have conversations off of Github issues and keep the issues tracker for more specific things


ux: DOI prefix error message improvement

:heart: Thank you for your contribution!
Description

Please describe briefly your pull request.

Fix https://github.com/zenodo/ops/issues/334
Before:

After:

Checklist
Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

[x] I'm aware of the code of conduct.
[x] I've created logical separate commits and followed the commit message format.
[x] I've added relevant test cases.
[x] I've added relevant documentation.
[ ] I've marked translation strings (for relevant code).
[x] I've followed the CSS/JS and React guidelines (for relevant code).
[x] I've followed the web accessibility guidelines (for relevant code).
[x] I've followed the user interface guidelines (for relevant code).
[x] I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
[x] I've NOT included third-party code (copy/pasted source code or new dependencies).

Third-party code
If you've added third-party code (copy/pasted or new dependencies), please reach out to an architect.
Reminder
By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

You license your contribution under the same terms as the current repository’s license.
You agree that you have the right to license your contribution under the current repository’s license.

Could you review/merge https://github.com/inveniosoftware/cookiecutter-invenio-rdm/pull/273 so we get THEME_SITENAME in the default config for RDM?

@carlinmack It looks like it's just formatting errors with black, can you take a look and update PR?

done :)


primusrun failed with "file exists" error

Starting this month (earlier may be), I found I cannot correctly run primusrun any more. It always failed with error. The variable PRIMUS_VERBOSE=2 does not help to provide any useful output at all. It also only shows below error message:
wood@Gentoo ~ $ primusrun glxgears
primus: fatal: failed to connect to Bumblebee daemon: File exists

However, I cannot figure out what is the exact file that causing this issue. My bumblebee daemon is correctly running, and of course, my user is a member of bumblebee group.
wood@Gentoo ~ $ LANG=C systemctl status -l bumblebeed
bumblebeed.service - Bumblebee C Daemon
Loaded: loaded (/usr/lib64/systemd/system/bumblebeed.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2015-03-28 00:16:31 CST; 39min ago
Main PID: 5589 (bumblebeed)
CGroup: /system.slice/bumblebeed.service
        └─5589 /usr/sbin/bumblebeed

Mar 28 00:16:31 Gentoo systemd[1]: Started Bumblebee C Daemon.
Mar 28 00:16:31 Gentoo systemd[1]: Starting Bumblebee C Daemon...
Mar 28 00:16:31 Gentoo bumblebeed[5589]: [ 4718.141907] [INFO]/usr/sbin/bumblebeed 3.2.1 started

I'm quite sure it works fine before. Could you kindly help to solve this issue?
optirun works fine, but I really need primus to run some of the steam games.
I'm using Gentoo, and here is some of my package version info. I'm not sure if it will be helpful to diagnose the issue:
linux-kernel-3.19.3
xorg-server-1.17.1
libdrm-2.4.60
xf86-video-intel-2.99.917
mesa-10.5.1
nvidia-drivers-349.12

I've pushed a commit that fixes a mistake in error handling, can you check if it helps? If not, please run primusrun strace glxgears and supply the resulting log.

The new commit fixed this problem! Now primus works like a charm.
Good job, and thank you so much, @amonakov


Update rangeslider to videojs v5

Hello Daniel,
First, congratulations for this plugin. I plan to update it to videojs v5. I already modified the new skin control bar layout to have a full width progress bar, like in pre v5 skin.
Do you already have started to port rangeslider to videojs v5 or should I start from scratch?
By the way, I use your (modified) plugin in a video analysis webapp that you might be interested to see. Let me know if it is the case.
Keep up the good work :)

Hello Billy,
I am not planning to upgrade the rangeslider, because I am in other project, but It would be great if you do it and share your results here to be merged.
Please, let me know if you need something to do it.
Best,
Daniel

In fact I could use some help on a specific point. I struggle on this issue: http://stackoverflow.com/questions/33389458/how-can-i-access-videojs-seekbar-and-controlbar-in-version-5
I am still new to Javascript so I could misunderstood how you designed the plugin. Can you please have a look?

I made some progress, as you might see on the SO question. It seems that it will be necessary to change completely the way the plugin load its components. Besides, there is a couple errors popping due to, I assume, deprecated function calls. I'll look further into it and keep you posted.

great! I have seen your issue on stackoverflow and I did not taken time for looking into the 5 version of videojs. But I have seen that there is a person that has created a fork with the solution that you are looking for. Please, take a look into this: https://github.com/mikaelnousiainen/rangeslider-videojs/commit/9e98433e881e18285301b6026621ef5588094917 and if this fix your problem, I will problably do something similar to upgrade.

@danielcebrian Thanks for the feedback. I gave a quick look into @mikaelnousiaine fork but I guess he did a quick and dirty try (no offense :smile: ) or it is a work in progress. However, he did add the videojs.registerComponent I planned to add tomorrow.
By the way, I also added several events related to the selection bar left and right handles (clicked and grabbed events). I will include them in a PR if I successfully make this work (as I hope).
Have a nice evening!

@Billybobbonnet None taken :) Well, I guess the dirty part of the code are the videojs utility functions that were removed from v5 API and had to be re-implemented (in the beginning of the file) to make the code work. I really just tried to make the plugin work with a minimal set of changes. Anyway, I can verify that the plugins works perfectly with my changes using the default skin on Video.js v5, so you can use the changes as a basis for your PR. Note that there is another commit in my repo that changes videojs.extends() to videojs.extend(), which was an API change made later in the v5 release candidates.


fix: Add Server Service check to apply the changes in case the service exists

What type of PR is this?
/kind bug
What does this PR do / why we need it:
This PR adds logic to reconcile any manual changes on Server Service properties.
Which issue(s) this PR fixes:
Fixes #1390
How to test changes / Special notes to the reviewer:
I performed an upgrade test as follows:

Ran make run
Created an ArgoCD CR.
Check the Server Service Type is ClusterIP (by default)
Apply

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  server:
    service:
      type: NodePort

6.Check the Server Service Type is NodePort

Thanks @nmirasch. Congratulation on your first contribution :tada: .


Models will not download through model downloader.

step 1: I clone repo
step 2: cd jetson-inference
step 3: docker/run.sh
When I run the above command and the model loader pops up, I select the models I want to use but every one of them gets a
"Download Error"
My only option is to quit because retry does not thing but produce the error again.
The image downloaded perfect when doing a git clone so it can't be a connection problem.
Any thoughts?

Hi @RoninHunter, I just ran the model downloader again from here, and was able to download the models without issue.   If you are in China they may block the URL.  In that case, there is a mirror of the models that you can manually download from here:  https://github.com/dusty-nv/jetson-inference/releases/tag/model-mirror-190618


Add form option to sse() action

This adds a new contentType option to the sse() action as discussed in https://github.com/starfederation/datastar/issues/293.
<form>
  <input name="foo">
  <button data-on-click="sse('/endpoint', {contentType: 'form'})">
    Submit GET request
  </button>
  <button data-on-click="sse('/endpoint', {contentType: 'form', method: 'post'})">
    Submit POST request
  </button>
</form>

<button data-on-click="sse('/endpoint', {contentType: 'form', selector: '#myform'})">
  Submit GET request from outside the form
</button>

When the contentType option is set to form, the following steps are taken.

If a GET request, set Content-Type to application/x-www-form-urlencoded, otherwise multipart/form-data.
Find the closest form element or use the selector, if one is provided. If no form is found, throw an error.
Add an event listener to prevent submission of the form.
Perform form validation. If invalid, report the validity, remove the event listener, and return.
If a GET request, set the query params, otherwise the request body.
Remove the event listener.

Does this work if you use on-submit instead of on-click ?

@delaneyj there’s a TODO in sse.ts that needs your input, please.

Looks like we didn't need to do any engine.ts changes, just cleanup the form event listener. @bencroker

I was working on a form yesterday and was thinking about this last night. I believe that forms should always be submitted by listening for the submit event on the form tag instead of using a click handler on a button. The main reason is that it usually breaks being able to hit the return key while inside the form to submit it. My preference would be to have a data-on-submit attribute that would go on the form tag itself, so it will work no matter how the form was submitted.
Great framework, btw. I started working on a project with it a few days ago and am liking it a lot.

For reference, since I already had it open: HTMLFormElement: submit event

I was working on a form yesterday and was thinking about this last night. I believe that forms should always be submitted by listening for the submit event on the form tag instead of using a click handler on a button. The main reason is that it usually breaks being able to hit the return key while inside the form to submit it. My preference would be to have a data-on-submit attribute that would go on the form tag itself, so it will work no matter how the form was submitted.
Great framework, btw. I started working on a project with it a few days ago and am liking it a lot.

Both should work actually to make up for forms being the worst part of HTML

I was working on a form yesterday and was thinking about this last night. I believe that forms should always be submitted by listening for the submit event on the form tag instead of using a click handler on a button. The main reason is that it usually breaks being able to hit the return key while inside the form to submit it. My preference would be to have a data-on-submit attribute that would go on the form tag itself, so it will work no matter how the form was submitted.

@eltimn @bencroker made sure data-on-submit would work.


x/tools/go/ast/astutil: AddImport removes imports

Please answer these questions before submitting your issue. Thanks!

I added a test case to golang.org/x/tools/go/ast/astutil's imports_test.go for adding an import of "net/http" the following file:
package main

import "bufio"
import "net/url"

What did you expect to see?
I expected the output file to include all three imports, probably in a single import block.
package main

import (
	"bufio"
	"net/http"
	"net/url"
)

What did you see instead?
package main

import "bufio"

It seems that this doesn't happen when the new package doesn't share a prefix with an existing package, or when the packages are all listed in a single block-style import.

You want to fix?

I'll take a stab at it, though I'm not yet familiar with manipulating the AST.
Do you want to review?

I'm scarred by and now scared of the AST package.
I think @griesemer likes those CLs.  :-)

@bradfitz "likes" is a strong word. I prefer "unfortunately spent too much time with"... - I'll review it, but I cannot promise a quick turn-around as I am under water at the moment with other stuff.

I've got a fix (https://golang.org/cl/29688), though I may have messed up the multi-commit workflow (it requires the change for #17213). I'd be happy to do them as a single commit, if that ends up being easier.


Memory issue

Hello,
I have a context with several after parties pending to run, and when I run with bundle exec rake after_party:run, I have the feeling between after_parties is not running the garbage collector, I see the memory growing...
Is it possible?
Thanks!

not sure if at this point:
https://github.com/theSteveMitchell/after_party/blob/master/lib/tasks/deploy_task_runner.rake#L6
after run after each after_party force the garbage collector, I can create a PR and try by myself.


the form of idx

Hi,thanks for sharing your code! I have a question  in demo_uda , line 169. dis[di, idx[di]] = torch.max(dis)   What is the form of idx, I can't get it through iter.next() in the dataset I built myself (not the image public dataset)，thank you

Hi,thanks for sharing your code! I have a question in demo_uda , line 169. dis[di, idx[di]] = torch.max(dis) What is the form of idx, I can't get it through iter.next() in the dataset I built myself (not the image public dataset)，thank you

Sorry, I just find this question today. idx is the index of images in the dataset. you can check Line 246 in the utils.py for more details.

I've solved the problem, thank you very much for your great work

Thank u


TelemetryInitializer, Middleware, and TargetingContext rework

Why this PR?
Primarily a refactor.
Also resolves https://github.com/microsoft/FeatureManagement-Dotnet/issues/424.
Related to- but explicitly not resolving here since the middleware was moved out of the main AspNetCore package https://github.com/microsoft/FeatureManagement-Dotnet/issues/396.
ITargetingContextAccessor is async and could not used reached by ITelemetryInitializer. We currently get around this by having our middleware add TargetingContext to HttpContext so it can be read synchronously.
This PR adjusts the middleware to instead place TargetingId on the RequestTelemetry object instead. This object is specific to Application Insights and we were already adding TargetingId to it with our existing initializer. By adding this earlier, we allow the initializer to depend on this field rather than the key on HttpContext. It also allows us to simply use the "TargetingId" key, rather than having a custom one for HttpContext.
This also allows ITargetingContextAccessor to cache however it wants and we're not caching in multiple places.
In short: Middleware stores on RequestTelemetry instead of HttpContext. Initializer now simply moves fields from RequestTelemetry to other Telemetry (like custom events).
Visible Changes
HttpContext will no longer have the key "Microsoft.FeatureManagement.TargetingId" added to HttpContext.Items.

Met with Zhenlan offline. My takeaway is:
Should we be setting TargetingId on RequestTelemetry?
If the answer is no- then this PR is not the correct way to solve this problem and we should use a cache.
If the answer is yes- this PR is a valid way to persist the TargetingId to custom events without needing a cache.
Our current preview release is placing TargetingId on the RequestTelemetry. However Split is not reading RequestTelemetry today, so it's not currently helpful to experimentation to be on there.
Currently I'm on the fence if we should add it. It's not helpful to split yet- but it could be helpful in App Insights today. If we go with "no" and pursue a caching solution instead, would adding TargetingId to RequestTelemetry 6 months from now make the cache obsolete? If so, our caching solution better not be a breaking change to take away.

Should we be setting TargetingId on RequestTelemetry at all?

Comparing to the current way (putting it in httpcontext.items), I will vote for setting TargetingId on RequestTelemetry. This is the recommanded way in App Insights [docs[(https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#enrich-data-through-http).

I am bit on the fence regarding whether we should add TargetingId to RequestTelemetry because we don't have any out-of-box usage scenario for RequestTelemetry today, but I'm not opposed to it. It could be handy for customers if they want to correlate feature evaluation with request telemetry. Of course, it could be handy for customers if we add TargetingId to all other ASP.NET telemetry (e.g. performance counters). I almost feel we should give customers an option to opt-in/out.
Regardless of whether we add TargetingId to RequestTelemetry (and other ASP.NET telemetry), it doesn't feel right to use RequestTelemetry as a caching mechanism in the middleware. We already have an initializer, and we must add TargetingId to the custom events. Even if we want to add TargetingId to RequestTelemetry (and any other ASP.NET telemetry), we should add it in the initializer.

I agree, customers should probably be able to opt out of it. And if that's something we might offer- we would still need the custom events to be populated with it. I think that's a good argument for decoupling these. Going to close this PR.

I agree, customers should probably be able to opt out of it. And if that's something we might offer- we would still need the custom events to be populated with it. I think that's a good argument for decoupling these. Going to close this PR.

This PR moves the middleware into the asp.net core project though. Will you be opening a new PR for that?

Yes I will. Going to solidify the shape of the caching first- since it has implications on what projects the middleware depends on.
For example, with the changes in this PR- it made a lot of sense to place the middleware under App Insights. I want to make sure that's still the case after changes.


Toggle Inline Chat Icon gutter item appears when inline chat isn't available

Open a repo in insiders.vscode.dev
Right click on the gutter
:bug: Toggle Inline Chat Icon is present in the context menu

Also #196739

Good catch thanks

The fix is not in the october stable release


Add docs about building downstream applications

Fixes #291

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/1662/
Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/1663/
Test PASSed.

Thanks @heuermh! I've merged.
I'll PR my additions on here.


[Governance] Polkassembly Integration

[ ] Rococo Testing (In progress)
[ ] Mainnet Testing

closing as its live https://frequency.polkassembly.io/


Travis python

Yay.. Green!

Not really green. Looks more like Travis gave up on my PR and skipped the check.


Adjust Text Appearance Timing on Scroll for Better Readability #73

improved scroll animation so that it works as aspected

LGTM!


USTL array missing methods

Hello !
Continuing to test ustl now I'm trying to compile https://github.com/Tessil/array-hash see attached:
array-hash.zip
USTL is including the header "<initializer_list>", in the past we could swap "std/ustl" using namespace but today with USTL also using "std::execption" it's not possible anymore and we need to use a neutral namespace alias like "lstd" to be able to swap between then. Is this accidental or it's a conscious choice ?
This implementation of array_map could be a good addition to USTL it's faster than std and uses less memory.
Cheers !
./test-mk
In file included from include/tsl/array_hash.h:48:0,
                 from include/tsl/array_map.h:41,
                 from test.cpp:22:
include/tsl/array_growth_policy.h: In member function ‘size_t tsl::ah::mod_growth_policy<GrowthFactor>::next_bucket_count() const’:
include/tsl/array_growth_policy.h:158:13: error: ‘isnormal’ is not a member of ‘lstd’
         if(!lstd::isnormal(next_bucket_count)) {
             ^
include/tsl/array_growth_policy.h:158:13: note: suggested alternative:
In file included from include/tsl/array_hash.h:43:0,
                 from include/tsl/array_map.h:41,
                 from test.cpp:22:
/usr/include/c++/5/cmath:670:5: note:   ‘std::isnormal’
     isnormal(_Tp __x)
     ^
In file included from include/tsl/array_hash.h:48:0,
                 from include/tsl/array_map.h:41,
                 from test.cpp:22:
include/tsl/array_growth_policy.h: In member function ‘size_t tsl::ah::prime_growth_policy::max_bucket_count() const’:
include/tsl/array_growth_policy.h:262:31: error: ‘const class ustl::array<long unsigned int, 39ul>’ has no member named ‘back’
         return detail::PRIMES.back();
                               ^
In file included from include/tsl/array_map.h:41:0,
                 from test.cpp:22:
include/tsl/array_hash.h: In member function ‘ustl::pair<tsl::detail_array_hash::array_hash<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::array_hash_iterator<false>, tsl::detail_array_hash::array_hash<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::array_hash_iterator<false> > tsl::detail_array_hash::array_hash<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::equal_range(const CharT*, tsl::detail_array_hash::array_hash<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::size_type, size_t)’:
include/tsl/array_hash.h:1158:53: error: ‘next’ is not a member of ‘lstd’
         return lstd::make_pair(it, (it == end())?it:lstd::next(it));
                                                     ^
include/tsl/array_hash.h: In member function ‘ustl::pair<tsl::detail_array_hash::array_hash<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::array_hash_iterator<true>, tsl::detail_array_hash::array_hash<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::array_hash_iterator<true> > tsl::detail_array_hash::array_hash<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::equal_range(const CharT*, tsl::detail_array_hash::array_hash<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::size_type, size_t) const’:
include/tsl/array_hash.h:1165:54: error: ‘next’ is not a member of ‘lstd’
         return lstd::make_pair(it, (it == cend())?it:lstd::next(it));
                                                      ^
include/tsl/array_hash.h: In member function ‘void tsl::detail_array_hash::array_hash<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::clear_old_erased_values()’:
include/tsl/array_hash.h:1293:34: error: ‘move_if_noexcept’ is not a member of ‘lstd’
             new_values.push_back(lstd::move_if_noexcept(it.value()));
                                  ^
In file included from test.cpp:22:0:
include/tsl/array_map.h: At global scope:
include/tsl/array_map.h:126:37: error: expected ‘)’ before ‘<’ token
     array_map(lstd::initializer_list<lstd::pair<const CharT*, T>> init,
                                     ^
include/tsl/array_map.h:146:32: error: declaration of ‘operator=’ as non-function
     array_map& operator=(lstd::initializer_list<lstd::pair<const CharT*, T>> il
                                ^
include/tsl/array_map.h:146:24: error: expected ‘;’ at end of member declaration
     array_map& operator=(lstd::initializer_list<lstd::pair<const CharT*, T>> il
                        ^
include/tsl/array_map.h:146:48: error: expected ‘)’ before ‘<’ token
     array_map& operator=(lstd::initializer_list<lstd::pair<const CharT*, T>> il
                                                ^
include/tsl/array_map.h:252:23: error: ‘lstd::initializer_list’ has not been declared
     void insert(lstd::initializer_list<lstd::pair<const CharT*, T>> ilist) {
                       ^
include/tsl/array_map.h:252:39: error: expected ‘,’ or ‘...’ before ‘<’ token
     void insert(lstd::initializer_list<lstd::pair<const CharT*, T>> ilist) {
                                       ^
include/tsl/array_map.h: In member function ‘void tsl::array_map<CharT, T, Hash, KeyEqual, StoreNullTerminator, KeySizeT, IndexSizeT, GrowthPolicy>::insert(int)’:
include/tsl/array_map.h:253:16: error: ‘ilist’ was not declared in this scope
         insert(ilist.begin(), ilist.end());
                ^

The use of std:: for initializer_list and exception is intentional and required for the compiler to recognize them and use the properly.
isnormal is part of cmath, which I do not intend to implement. Stop hating C headers and use math.h.
move_if_noexcept breaks expectations; you either move an element or you don't, and move_if_noexcept makes that dependent on type, requiring library users to examine its internals. That is always a bad thing.
next and prev, and have no idea what those are supposed to be for. Just ++iterator, like all the other STL code has done for decades.
So no, I don't want to implement any of these.

I do appreciate all the testing you do for the library; finding all these bugs is a good thing. It is not, however, a good thing to just pick random projects and push them to use uSTL. As I have pointed out in the documentation, there exist significant differences that library users must be aware of, such as iterator invalidation semantics, the moveable object requirement, the linking behavior, etc. Not being the author of these projects, you would not be able to determine whether these differences would cause problems. The stylistic differences you keep finding strongly suggest otherwise, as these projects were obviously designed by following the guidelines commonly taught in the academia today. Guidelines that specify a very different role and purpose for the standard library than what I designed uSTL for. As I explain in the documentation, uSTL would be a better fit for a "C with classes" programming style and projects using it would work best if they were designed specifically with that in mind.
Furthermore, with the space savings having been considerably reduced when compared with the current gcc libstdc++, I would no longer recommend anybody to use uSTL at all. Sometime in the near future I'll probably deprecate the project altogether and post a notice on the web page stating that this libarary is obsolete and people should move on to libstdc++.

Hi Mike, (in case of disadvantages of this project) can you please clarify why did you recently said that this project is not a proper solution for the embedded directions like stm32f4 or anything more powerfull like rpi?

Embedded microcontrollers such as stm32 do not have enough memory to waste on C++ containers. On such platforms you typically do not even use dynamic memory at all, but rather preallocate the blocks you are going to use statically. If you use any C++, you would certainly not use anything from the standard library, simply because there is no room. Even uSTL in its tightest build is way too big to fit there.
As for the raspberry Pi, it is pretty much a normal Linux platform, where you can use anything you like. You should use the regular C++ standard library. uSTL had big space savings over libstdc++ back in 2003 when I first wrote it, but those savings pretty much disappeared by now. The major difference now is the size of the shared library, and it is irrelevant once you use any application linked to libstdc++, such as firefox, that will load it in memory anyway. Back in 2003 C++ apps were much scarcer and you could get by without them. Now, libstdc++ is used extensively and, being already in memory, is almost always the better choice.


Added Rust Hook -> BaveOven - OnCosumeFuel

Used to give items when charcoal is made by furnace. Can be used with campfire too.

Thanks for the PR! I did notice a few issues with your PR though, so I'll need to manually merge it with the appropriate changes. :)

Ok, Thanks for adding the hook. I'll w8. =]


(x3270): packaged x3270 IBM terminal emulator

I added a nix expression to build the x3270 IBM 3270 terminal emulator, to be found there:
http://x3270.bgp.nu/index.html
I packaged the current stable version (3.4ga9 stable (23. October 2015), according to their downloads page). Though I pull the source code from the git repository instead of the provided tar balls. A small patch to fix the interpreter of an utility bash script was needed.
Actually this package now provides multiple binaries. One could add support to only build a subset of these binaries (and thus removing tcl, x dependencies). Also there are no man pages, because the respective install target fails and I don't have the time to investigate further.
As for testing I'm successfully running the applications on my laptop (NixOS on x86_64), using them to participate in the IBM Master the Mainframe contest. No further testing than this was done, though.
Please let me know if there's something that needs to be changed (this is my first to be contributed package).

@musteresel Could you squash your commits into a single one, and set the commit message according to the style defined in http://nixos.org/nixpkgs/manual/#chap-submitting-changes?

Also this seems to be targeting the release branch, this should go to master first and only then cherry-picked to release-15.09.

Squashing into a single commit and formatting that according to the rules worked as expected. Rebase to the master branch worked, too, but github didn't get it, so I create a new pull request #11080


Disable incremental regen when Archives enabled for 3.0 compatibility

Incremental regen messes up the content of generated archives (they show raw content instead of generated content), so we need to disable it if jekyll-archives is included as a gem.
Should fix the failing test(s) from #47.
For https://github.com/jekyll/jekyll/issues/3945
@parkr @pathawks

Oops. Applying @pathawks' commit from his PR.

no incremental regen makes me sad. :sob: :wink:

Cool! :snowman:

OK, all tests passed this time, with Jekyll 2 compatibility kept.

Thanks, Alfred!!!!!!

Perhaps a note re: incremental regen being disabled should be added to the Readme?

Great idea!

Cool. I’ll Write some words when I get a chance.

:+1:


docs: Fix SQS queue policy statement conditions usage

Description
Fix the SQS Queue policy statement conditions usage example.
Motivation and Context

Resolves https://github.com/terraform-aws-modules/terraform-aws-sqs/issues/53

Breaking Changes
None
How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects

[ ] I have executed pre-commit run -a on my pull request

This PR is included in version 4.0.2 :tada:


Write up a post on how WikiData, YSL & EaaSI work together and how the software info could be surfaced

WikiData/YSR contain useful data that could help people if surfaced e.g. via the Format Registry Index. To do that, I need a better understanding of how the bits fit together.

[ ] Work with project team to understand how data is arranged across WikiData/YSR/EaaSI.
[ ] Consider using code block render hooks to make it easier to re-use SPARQL queries.
[ ] Consider if the COPTR data would be better integrated into WikiData and then summarised elsewhere.

Consider using code block render hooks to make it easier to re-use SPARQL queries.

FFMprovisr and its sister projects sets a precedence here and should work easily enough for SPARQL: https://github.com/amiaopensource/ffmprovisr (and makes it easy for others to contribute).

@ross-spencer thanks - good call. Also added some notes in other issues to look to ffmprovisr as an exemplar.


Default icons when opening a folder appear gray since v2.4

Description
Opening a folder there's a delay in rendering file icons, thumbnails, etc. Currently Files latest version displays each file as a gray box before rendering the final icon.
I suggest changing from a gray box, to a default icon for the respective filetype, before the final icon is rendered.
Note: I run Icaros for media thumbnails
Steps To Reproduce

Open folder for the first time
Icons start as gray boxes

Steps to fix

Open a folder once to cache rendered final icons

Files Version
Versão: <IP_ADDRESS>
Windows Version
OS Version: 10.0.22621.963
Relevant Assets/Logs

debug.log
debug_fulltrust.log

There are too many file types to display default icons for, but we are working on optimizing the performance when loading thumbnails. Merging with #4180

I suggest just using Windows defaults or alternative, a generic icon for each group of:

documents
images
video
audio
exes
blank for other groups.


[Relay] Dead Code Elimination

add dead code elimination for relay.
dead code elimination is a compiler optimization pass that remove unused code, so future pass run faster, and generated code is smaller (and run faster too).

I address the review posed by jared, and add a lot of test case. can anyone give one last round of review?

@MarisaKirisame I have made some followup comments, this PR need to be rebased against the current master. @ZihengJiang can you also do a round of review on this?

Please format the code. The style is not consistent to what currently tvm has.
I also have a more general question, probably for relay, not just for this PR. Do we need to have liveness analysis to help opts like DCE?

Please format the code. The style is not consistent to what currently tvm has.
I also have a more general question, probably for relay, not just for this PR. Do we need to have liveness analysis to help opts like DCE?

liveness analysis will probably help DCE.

@tqchen I think it is pretty good. Can you give it one final round of review?

@tqchen can you review? I rebase, address all comment, and went through the file to fix some more style errors.

Thanks @MarisaKirisame for being patient and improving the code. Thanks @ZihengJiang @zhiics @jroesch for reviewing, this is merged


[ruby-head-wasm-wasi] Feature request to customize default import functions

Related to https://github.com/ruby/ruby.wasm/issues/126
I have looked around the code and the current JS extension is really impressive. The problem for me is I want to use subset of its capabilitiies for security concerns.
As far as I understand, it looks like this is the final list of the default import functions to WebAssembly and if we omit a function from here, the ruby side's JS extension will fail because there are no associated JS functions:
https://github.com/ruby/ruby.wasm/blob/802ecc5047ac9ee7270b58e7f11cea87b8172f36/packages/npm-packages/ruby-wasm-wasi/src/index.ts#L83-L199
For example, if I remove evalJs here, JS::eval in ruby fails, which is ideal for me.
For security concerns, evalJs and globalThis needs more control. Therefore, I'm wondering whether we can add an option to customize these default import functions. The interface might look like:
const { vm } = await DefaultRubyVM(module, {
  importEvalJs: false,  // I don't want to allow `JS::Eval`
  importGlobalThis: ["Promise"],  // I don't want to allow to access `document`, etc., but `Promise` to use `.await` in the JS extension
});

Or, more transparent to the import functions definition:
const { vm } = await DefaultRubyVM(module, {
  imports: { // Override default imports if the field has the same name.
    evalJs: (code) => {
      throw new Error("Not supported");
    },
    globalThis: () => {
      if (typeof globalThis !== "undefined") {
        return { Promise: globalThis.Promise };
      } else if (typeof global !== "undefined") {
        return { Promise: global.Promise };
      } else if (typeof window !== "undefined") {
        return { Promise: window.Promise };
      }
      throw new Error("unable to locate global object");
    },
    // Other functions are imported untouched.
  }
});

I imagine some functionalities rely on the others, so these options might not be such simple, but how does this sound to you? If it looks good, I can work on a PR. These changes are only inside JS code and no need to touch wasm side at all.
I believe there are some use cases to allow the customers to run arbitrary program code inside a secure sandbox and WebAssembly is really useful for this because it can control which JS functionality is exposed to WebAssembly and vice versa. I hope this could help not only me but also some others.

Yeah, I think it's an interesting sandbox use case in browsers. But limiting access to the global object is still vulnerable.
In your example, users can retrieve only the Promise object from the global object, but they can easily pollute Promise object in Ruby like below:
require "js"
JS.global[:Promise][:prototype][:then] = proc do
  puts "faked"
end

I'm not a security expert in JavaScript, so I think there should be more critical issues I haven't figured out.
Therefore, I think it's very difficult to reuse the js extension for secure sandbox purpose.
Just FYI: Figma's plugin system stories would be interesting for you:

How to build a plugin system on the web and also sleep well at night
An update on plugin security

Then, my suggestion is "Don't expose JS language operations. Expose functions statically". This is often used sandbox strategy in WebAssembly products.
You can refer Fastly's Compute@Edge interface as an example.
https://github.com/kateinoigakukun/ruby-compute-runtime/blob/main/ext/compute_runtime/compute_runtime.c

Thank you again for valuable information. The Figma's architecture is very similar to what I want to do.
For my use case, I'd like to just expose a blocking (or non-blocking) call to wait until a specific message (response) is received after an initial message is sent (request) to emulate network communication inside browser's JavaScript with sandbox.
I was wondering to implement a simple polling logic inside Ruby extension using an imported JS function "poll" to just check the message's arrival status to wait the response on Ruby side, but since it blocks entire WASM execution, it requires to run inside Web Worker, which is good but I was also looking for a simpler solution. The ruby.wasm has await functionality so that I thought I could run it inside the main thread.
However, as you mentioned, minimizing the scope is much better. Let me explore the options with the C extension.

@riywo await and PromiseScheduler is very simple, so you can imitate them for your specific usecase easily.


New-BurntToastNotification Button Overflow Menu

Summary of the new feature/enhancement
As a user, I would like to see an overflow menu of the varying options with buttons. Right now, there are only 4 options allowed within the notification tile.
Proposed technical implementation details (optional)
With the New-BurntToastNotification, allow for more than 4 buttons in an overflow state (i.e., in a dropdown or buttons on top of one another).

Unfortunately, limitations like this are imposed by Microsoft via the Notifications API and isn't something that can be overcome when using that API (which this module does).


nls error on reload page - from time to time - vers 0.19.0

Chrome: Version 79.0.3945.88 (Official Build) (64-bit)
Windows 10 Pro: 1909
Doesn't always occur - but on many fast reloads - running in Webpack debug mode.
nls.js:47 Uncaught TypeError: Cannot read property 'replace' of undefined
    at n (nls.js:47)
    at Object.localize (nls.js:85)
    at folding.ts:869
    at Function.t._invokeFactory (loader.js:1036)
    at t.complete (loader.js:1046)
    at s._onModuleComplete (loader.js:1660)
    at s._onModuleComplete (loader.js:1666)
    at s._onModuleComplete (loader.js:1666)
    at s._resolve (loader.js:1578)
    at s.defineModule (loader.js:1266)

BTW: pretty cool with all the closed issues and fixes! Well done! :-)

@cintaccs The first stack trace leads to here -- https://github.com/microsoft/vscode/blob/7400168b53411a48ec345218e765c83e1a97b6b8/src/vs/editor/contrib/folding/folding.ts#L876 -- but that one calls nls.localize with a defined string. I wonder if you have done something custom around nls that might lead to a timing error where your nls strings are not ready sometimes?

From your snippet, it appears you are loading things very much like in this simple sample -- https://github.com/microsoft/monaco-editor-samples/blob/master/browser-amd-editor/index.html
I have executed that repeatedly/reloaded repeatedly and cannot reproduce any exception. The only explanation I have is that somehow the editor installation is corrupt, or that an older version of editor.main.nls.js is loaded with a newer version of editor.main.js. I have seen this happen when the server is written incorrectly and the browser caches the files indefinitely, so it might fetch editor.main.js from<EMAIL_ADDRESS>and editor.main.nls.js from cache at<EMAIL_ADDRESS>or something like that...

@alexdima - sure! Thanks a lot for the feedback! will do and let you know!

@alexdima : Cleared all cache - upgraded from 18.1 to 19.2. Now I get when loading a CSS editor:

and after that - a page reload gives:

a Ctrl Refresh (on latest Chrome) gets rid of the nls error.
Loading the CSS editor - brings back the "completionItems" error. And a normal Page reload will then bring back the nls error again.
Not sure whether it is related - but loading a SQL mode editor in the same context seems to work...??

it also appears to have an issue when in HTML mode:

FYI: I am using CSS, HTML, SQL modes from the same initial loader in a SPA.

what is super weird - I can reload the page many times without the nls error - and then suddenly it comes back again.

FYI - I only "copy" these folders from the npm node-modules into the application.

@cintaccs The stack traces you have are just not possible and again indicative of mixin files from two distinct editor versions.
Let's take the stack you have in htmlMode.ts, in the setupMode function.

Cannot read property 'completionItems' of undefined
The line of the error is here -- https://github.com/microsoft/monaco-html/blob/c4d683af71ad4d61b58fc67c839d889e3078f95a/src/htmlMode.ts#L63
The undefined variable must be modeConfiguration, which comes from defaults.modeConfiguration.
defaults is an argument passed in to setupMode
The setupMode is called here and always with defaults which contain the field modeConfiguration -- https://github.com/microsoft/monaco-html/blob/c4d683af71ad4d61b58fc67c839d889e3078f95a/src/monaco.contribution.ts#L125-L133

The property modeConfiguration has been recently added, see https://github.com/microsoft/monaco-html/blame/master/src/monaco.contribution.ts#L18 .
This finally 100% convinces me that you have mixed up files, i.e. editor.main.js from a certain editor version, and htmlMode.js from a newer editor version.
Please do the following:

delete all the contents of min, min-maps or anything you have in your project regarding the monaco editor.
download again and unpack the editor files
clear your caches or reconfigure your server to do correct caching

I am sorry, at this point I am 100% convinced you are loading an older version of vs/editor/editor.main.js with a newer version of vs/language/html/htmlMode.js. Please open those files in the dev tools and look at their headers. Do they look like this:

editor.main.js:

/*!-----------------------------------------------------------
 * Copyright (c) Microsoft Corporation. All rights reserved.
 * Version: 0.19.2(6dc59eb294d3df102203e7a04fde6f032157ff51)
 * Released under the MIT license
 * https://github.com/Microsoft/vscode/blob/master/LICENSE.txt
 *-----------------------------------------------------------*/

htmlMode.js:

/*!-----------------------------------------------------------------------------
 * Copyright (c) Microsoft Corporation. All rights reserved.
 * monaco-html version: 2.6.0(c4d683af71ad4d61b58fc67c839d889e3078f95a)
 * Released under the MIT license
 * https://github.com/Microsoft/monaco-html/blob/master/LICENSE.md
 *-----------------------------------------------------------------------------*/

@alexdima Hi again - and thanks a lot for looking into this!! I really appreciate it!
I have now reset my browser cache and all related web data again + removed my monaco "copy" from npm node_modules + made a new fresh copy after checking that the package-lock.json and package.json is indeed 19.2. During my various checking I see the following:

the workers are having 2 different versions:

I don't think I am loading any of that in "my" part of the code - but i will double check again.

btw: I tried to remove the esm and dev folders from the monaco-editor folder. Currently and in the results above I have them in (the monaco-editor folder I "serve" = the node_modules/monaco-editor) I assume that these 2 folders are only needed for development versions of monaco-editor and not needed during production builds. However when removing them (leaving min and min-maps in the folder) I began to see the nls error again.

Well, that is the problem. In your browser, on your machine, when loading your application, you have editor files loaded from mixed versions. If they look fine on disk, perhaps it is the browser cache that is broken, or your web server.
Have you tried reproducing on another browser, or with Chrome with a fresh user data profile? If the problem reproduces on another browser, then this is an issue with your files on disk or server implementation, which is probably serving different files than the ones you are editing. If you can reproduce in another browser, then install an HTTP proxy and look at the HTTP requests going from the browser to your server and check if your server is broken and responding with old content to new HTTP requests.
You can also try renaming the folder on disk to monaco-editor-0.19.2 and load it from that path, that might help with caching problems.
I have to say, at this point, I am 99.99% convinced this is not a Monaco Editor issue and pursuing this here further is not helping our community.
Good luck to you!

Thanks for your help!


Winston Logging Transports crashing

Environment details

OS:  Google App-Engine
Node.js version: 8
npm version:  6.7.0
@google-cloud/logging version:  4.2.0

Steps to reproduce

?
?

<rejected> TypeError: Cannot read property 'length' of undefined
at BundleExecutor.schedule (/app/node_modules/@google-cloud/logging/node_modules/google-gax/build/src/bundling.js:319:43)
at status.call (/app/node_modules/@google-cloud/logging/node_modules/google-gax/build/src/bundling.js:443:30)
at Canceller.call (/app/node_modules/@google-cloud/logging/node_modules/google-gax/build/src/api_callable.js:78:27)
at Bundleable.call (/app/node_modules/@google-cloud/logging/node_modules/google-gax/build/src/bundling.js:442:20)
at funcWithAuth.then.then.apiCall (/app/node_modules/@google-cloud/logging/node_modules/google-gax/build/src/api_callable.js:312:23)
at <anonymous> at process._tickCallback (internal/process/next_tick.js:189:7)

Greetings!  Can you share the code you're using to get this callstack?

const { loggers, format } = require('winston'); const { LoggingWinston } = require('@google-cloud/logging-winston'); const {   combine, label, printf, splat, } = format; const logFormat = printf(info => [${info.label}] ${info.level.toUpperCase()}: ${info.message}); const loggingWinston = new LoggingWinston({   serviceContext: {     service: 'api',     version: pjson.version,   },   logName: logfile-v${pjson.version}.log, });  loggers.add('api', {     level: 'debug',     format: combine(label({ label: 'api'}), splat(), logFormat),     transports: [loggingWinston],     exitOnError: false,     silent: false,   });
This is how I initialize the logger,  the error just intermittently goes out, cannot locate which actual code.

@alexander-fenster uh...  do you recognize anything in this call stack?

Somewhere in bundling.ts - I will take a deeper look today. Haven't seen this before.

This is where we create Bundleable instance:
https://github.com/googleapis/nodejs-logging/blob/05edc862a8d5d052e35497bf5f063a219db880d9/src/v2/logging_service_v2_client.js#L142-L151
Here bundledField is entries.
The call starts here:

and the sequence of nested calls eventually comes to BundleExecutor.schedule where it finds that request["entries"] is undefined:

(and we fail trying to get .length of undefined)
Now the fun part is that the Logging library does great job making sure that entries property is always defined. By looking at its code:
https://github.com/googleapis/nodejs-logging/blob/6cf18aac0133709770596d405242f86d912fda48/src/log.ts#L783-L807
I can see the only way of having it undefined: it will happen if decorateEntries_ throws an exception, which will leave decoratedEntries undefined, and reqOpts.entries will become undefined as well.
Long story short...  https://github.com/googleapis/gax-nodejs/pull/424 to make GAX not fail in this case, and in scope of this issue, we must make sure that undefined is never passed to logging API.

I can see the only way of having it undefined: it will happen if decorateEntries_ throws an exception, which will leave decoratedEntries undefined, and reqOpts.entries will become undefined as well.

It kind of seems like we shouldn't let that be undefined. It actually doesn't seem like we should send the request, and we would want to give the error to the user. I think I did this error ignore because we were just doing our best to get additional information we could send with the request, but it wasn't something the user required us to do. So if it fails, it's not a big deal. But the kind of error that would be thrown in the snippet you shared is when a JSON object cannot be serialized because of circular references. The user would probably want to know that, but maybe my memory is failing me on how this all works.

@stephenplusplus I'm not sure what is our policy re: throwing exceptions from logging calls. I think users don't expect that regular log writes could throw 😱 Would it be OK if we make sure the decorateEntries_ never throws, and does whatever it can possibly do even for objects with circular references? (e.g. dump incomplete object, or anything else)

Hello,
I have the same issue on Google AppEngine, with the same error appearing in Error Reporting.
Have you identified any circumstances that lead to this error?
I noticed that a certain (older) version of our application has no issues with this bug. This may relate to other parameters handed to winston (we use the winston transport)? If I knew which conditions are responsible I could prevent this error from happening (for now), until this is fixed.
Would switching to another version help with this issue?

Hello @seriousManual,

Have you identified any circumstances that lead to this error?

Yes and no. I made a fix https://github.com/googleapis/gax-nodejs/pull/424 in exactly the place where it fails so it should not fail anymore (we'll release the new version of that package today). When all the dependency chain upgrades, the error condition should stop happening.
As for what causes the error - i.e. what causes the undefined value to be passed to logging - I don't have an answer I'm confident in. One idea is that it might be doing that if it gets an object with circular references, but it makes me think there should be another explanation, given that all these bug reports started coming from several people at the same time. @stephenplusplus can I ask you to take a deeper look at what's going on (why this undefined value appears there)?

Thank you for the efforts you're putting into this.

but it makes me think there should be another explanation, given that all these bug reports started coming from several people at the same time.
I'm glad it is not only us.
I am currently trying to pinpoint the time and place in the commit history where a possible change has been introduced that may relate to the issue. But this is quite cumbersome as the only way is to redeploy and wait for the bug to happen / not to happen.

How long do you think it will take until the fix patch has been introduced at the upstream deps? (gax -> nodejs-logging -> winston-logging)

Hello,
I have the same issue on Google AppEngine, with the same error appearing in Error Reporting.
Have you identified any circumstances that lead to this error?
I noticed that a certain (older) version of our application has no issues with this bug. This may relate to other parameters handed to winston (we use the winston transport)? If I knew which conditions are responsible I could prevent this error from happening (for now), until this is fixed.
Would switching to another version help with this issue?

Hi,
I would like to share my workaround as of this time, while waiting for the fix.
I tap into the process.on('unhandledRejection')  and check if it is the same error:  then I use logger.configure(...)   to initialize another LoggingWinston  transport -- (this time another filename, it did worked for me for (although it creates another file in stackdriver, but its ok as I can still capture the logs)

To all who spent time on this issue, I would like to thank you for your dedication to solve this.  I have been tracing all logging combination that we do in our code (NodeJS in App-Engine) to find what is the exact scenario this happen.  But if this can be solved on your end,  Thank you very much!

Greetings folks,
I have released google-gax v0.25.2 which should not crash in case if an undefined value is passed. From what I understand, it means you may get an incomplete / malformed log message but at least nothing will crash. Since logging uses "google-gax": "^0.25.0" the fix will be picked up automatically.

Hi,
thank you for the fix, I updated the dependencies today, redeployed and promptly got the following output on stderr:
"Request does not contain field entries that must present for bundling. Invoking immediately"
I suppose that this is directly related to the fix?
Either way, though this case occured the logs keep coming in, so far it's looking good!

@seriousManual Yes, it's exactly that warning message that should be printed in this case. Note that it will be only printed once per each running process (otherwise your stderr would've been spammed a lot).

Hi Guys,  I also did used the fix and deployed to our staging instance.  Its been there for 3 days now and I never got the error again.  Hopefully this is going to be stable now.  Thanks a lot.

Same here,
haven't seen the issue on our development system for a while now!
Thank you!

I observe the same issue with winston 3.2.1 and google-gax 1.0.0. I get the same error "Attempt to write logs with no transports" after a while.
I can see there was a huge refactoring done recently, so maybe there was a regression during the process ?

@la-urre Did you ever get to the bottom of your issue? I am seeing the same thing currently.

If you're running into issues, please open a new bug with details 🤗


Update to support EventStore version 21.6.0 or greater

Current supported version is 20.6.0-buster-slim which is last year release and it has a set of few bugs, most notably in persistent subscriptions which are resolved in 21.6.0.
What needs to be done

Check if streams proto is updated and generate new golang code and update stream implementation.
Docker image with gRPC test data needs to be updated with EventStore version 21.6.0. grpc Test Data Docker Image
Tests which use pre-populated database should be updated to use 21.6.0 grpc Test Data Docker Image.

Persistent subscriptions are already up to date with EventStore 21.6.0.

@hayley-jean
Hi, is there a repository where I could find test data used to fill the database for gRPC Test Data Docker Image?

Regarding points 2. and 3. I would suggest that we ditch the grpc Test Data Client and rewrite tests for streams so that they include data setup phase (writing events).
That way it would be easier for developers to read tests and understand the behavior of features.

Not in favor of your 2nd point as the testdata set is about testing invariants. If you push your events yourself, it's possible to be blind to some implementation errors. I think writing your own data to the database should be done alongside the testdata tests.

If I understand you correctly, we need to have pre-filled database (done by some other client or some other method) in order to be able to test other client (Golang client in this case) so that we can guarantee that client which is tested implements invariants properly?
If so, could we maybe provide a more transparent process on how database for gRPC test data docker image is filled. For example, provide JSON files for events and streams which are written to the gRPC test data docker image. That way each developer can use desired EventStore version through docker image to create it's own EventStore docker container, prefilled it's database and extract that database from that container and use it whenever they need to use desired version of EventStore with pre-filled database in their tests.
This would require to maintain those JSON files to accommodate for invariant type updates in EventStore. But still we would not need to wait for someone to release a new version of gRPC test data docker image. We could built it ourselves locally for our own needs.


ESP-IDF V5.2.3 Bug or Miss Interpret in Compiler at Printf level (IDFGH-13927)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
There is an error inside the Printf compiler optmizations and also with the stub.
unsigned long sensor_received = 12345647;
unsigned long last_sensorid_received = 12345649;
unsigned long sensor_length = 0;
struct timeval tv2;
gettimeofday( & tv2, NULL);
printf("Time: %ld seconds\n", tv2.tv_sec);  // Separate print for tv.tv_sec
	printf("Before first printf: sensor_received = [%lu]\n", sensor_received);
	printf("RECEIVED [%lu]\n", sensor_received);
	printf("Before second printf: sensor_received = [%lu]\n", sensor_received);

	printf("[%d] [%ld] RX433 Received: SENSOR [%lu] - last_sensorid_received [%lu]\n",
   __LINE__, tv2.tv_sec, sensor_received, last_sensorid_received);

	printf("[%d] RX433 Received: SENSOR [%lu] - last_sensorid_received [%lu]\n",
				 __LINE__, sensor_received, last_sensorid_received);

	printf("RX433 Received: SENSOR [%lu] - last_sensorid_received [%lu]\n",
				 sensor_received, last_sensorid_received);

to validate all kind of possible acttions the code try all kinds.
Before first printf: sensor_received = [12345647]
RECEIVED [12345647]
Before second printf: sensor_received = [12345647]
[1526] [0] RX433 Received: SENSOR [0] - last_sensorid_received [12345647]
[1529] RX433 Received: SENSOR [12345647] - last_sensorid_received [12345649]
RX433 Received: SENSOR [12345647] - last_sensorid_received [12345649]
1526] [0] RX433 Received: SENSOR [0] - last_sensorid_received [12345647]
this could be related to the %ld type not being correct alligned with the compiler in this arguments?
as of using
printf("[%d] [%" PRId64 "] RX433 Received: SENSOR [%lu] - last_sensorid_received [%lu]\n",
LINE, tv2.tv_sec, sensor_received, last_sensorid_received);
this prints correct, so, why in the esp-idf the type is PRId64 ?

@filzek , please refer to https://github.com/espressif/crosstool-NG/issues/62#issuecomment-2302593315


On-disk database path

What is the path that is expected to the on-disk database file? Is it a relative or an absolute path?
I have different locations for development and production, and to be able to configure them I need to know what is expected.

Vote to close


Why doesn't the data change when I move items

No matter how I move the items, the array has not changed

Please follow the instructions in the README for using a state management library. I'll try and make them more clear, as they don't just apply to vuex. https://github.com/MaxLeiter/sortablejs-vue3#vuex

Yeah, this confused me as well.
I too had issues with Vue3+Vue-Draggable, and so migrated to sortablejs-vue3.
It's a small bit of code to add to manually "moveItemInArray", but I wonder what the reasoning behind it is, why not mutate the array, like vue-draggable does (is it because side-effects are "bad"?)? Some clarification (a. that you must do this, and b. reason) would go a long way, thanks in advance!

If I'm following the conversation correctly, this tool does not keep track of the changes made on the list? So If I have a list of items and I move the 1st item to the last position, the original array will not display this change? I have to do this change manually?

@Sjoerd82 the reasoning is I built this library for what I needed, and I already had a custom store and the relevant functions setup. A pull request improving the API is welcome!

So If I do not use Vuex then I can't use this library?
I have use case that I use swap plugin from sortable and when I move items manually in array then it is not rendered.


Metric tag serialization

This PR modifies MetricWithTags so that the serialized name+tags string is consistent from one call to the next. It now appends the tags in sorted order by tag name.
This also changes the metric tag separator from "::" to "\x00", which prevents breakage when the metric name, tag name, or tag values include "::".
Internal tracking: OY-3963

This looks good to me, though I did want to point out that grodd uses two different separators for this data:
#define TAGSET_DELIMITER	((char) 0x01)
#define TAGPAIR_DELIMITER	((char) 0x02)

So you get something like foo{0x02}bar{0x01}baz{0x02}qux. I don't know if that's helpful or useful in any way here.


[Arith] Add internal NarrowPredicateExpression utility

Implements tvm::arith::NarrowPredicateExpression, a utility that removes free parameters from a boolean expression, such that the resulting expression being true implies that the original expression is true.  For example, the predicate (0 <= i+f) && (i+f < 16), where f is a free parameter on the range 0 <= f < 2), can be narrowed to the expression (0 <= i+0) && (i+2 < 16).
In effect, NarrowPredicateExpression functions as a context-sentive tvm::tir::Substitute, where the value substituted is selected such that the resulting expression errs on the side of being false.  This is an internal utility used as part of the simplifications for layout transformations (tracking issue link).

Marking as a draft PR until it passes CI.  This utility could also be moved to be internal to an upcoming data-flow analysis utility.

Rebasing onto main to get the bug fix from #13067

0 <= f < 2), can be narrowed to the expression (0 <= i+0) && (i+2 < 16)

Hi~ I feel a bit confused about here: when f == 0, the i could take value in range [0, 16), thus what is the purpose to get narrowed predicate i + 2 < 16?

Hi @wrongtest-intellif !  The goal is to produce an expression that, when true, implies that the original expression is true.  For this specific example, suppose we know that i + 2 < 16.  Because we also know that the free parameter f satisfies 2 < f, we know that i + 2 < i + f.  Therefore, since i + f < i + 2 < 16, i+f < 16.
The NarrowPredicateExpression is part of a larger data-flow analysis that I'm preparing as part of handling padded buffer transforms.  When analyzing whether a specific index corresponds to padding, conditions such as pad_left <= i+f < original_width + pad_left (identifies a non-padding data value) frequently show up.  By converting these into expressions that are true regardless of the value of f, or expressions that are false regardless of the value of f, we can remove reduction axes from the overall predicate expressions.