Original frame isn't being shown (annotator)

Hi,
I need to work with the annotator at the moment. However, despite not receiving any error messages, as shown in the attached image, the original frame isn't being displayed; only the annotations are visible. Initially, I thought that having different data ranges was the problem, but even after normalizing the original frames (.tiff files) to both [0-1] and [0,255], the issue persisted.
I should also mention that the output of get_slice() is of shape (2, 188, 242, 626), and the function itself operates smoothly during tracking.
What can be the issue? Please let me know if I should provide more details.

Are you using a custom getter function? Could you post your get_slice implementation and your metadata?

yes, I am using a custom getter_function. Here is the implementation of get_slice():
def get_slice(dataset: Path, t: int, cropy=(50, 150)) -> np.ndarray:
    filenames, _ = get_volumes_list(volumes=volumes, folder=str(dataset))
    file_green = filenames[0][t]
    file_red = filenames[1][t]

    red = np.array(pims.open(file_red))
    red = (red - np.min(red)) / (np.max(red) - np.min(red)) * 255
    green = np.array(pims.open(file_green))
    green = (green - np.min(green)) / (np.max(green) - np.min(green)) * 255

    return np.array(np.stack([red, green]))

and here is the metadata:
{"shape_t": 5000, "shape_c": 2, "shape_z": 188, "shape_y": 242, "shape_x": 626, "dtype": "uint16"}

Hm... What is volumes in get_volumes_list? I don't see that variable declared. Also, is it possible the fluorescence is just dim? Can you see anything when you use the LUT sliders for red/green channels?

We do use uint8 internally for volumes. I thought we did convert the dtype implicitly, but there might have been an oversight. Is the result any better if you convert your data to uint8?

So basically, when I used the sliders to change the colour channels' intensity or change the gamma value, the screen went black (showed in the attached video)
https://github.com/venkatachalamlab/ZephIR/assets/46346942/5f701c6b-a325-48e9-a441-375cea95970e
However, changing the data type from uint16 to uint8 solved the problem. Now not only are the original frames showing, but I can use the sliders flawlessly.
Thanks for your help and prompt replies.

Awesome! Glad that solved the issue. I'll make sure to add dtype casts to avoid this in the future.


Return old look of the Contacts on the Products and In Progress tabs.

Now we have all three contact names visible in full representation:

Even on a squished screen:


feat(v2): allow title and label for docs in sidebar

Motivation
Resolve #2337
Add label option in type : 'doc' to reduce the need to inject sidebar_label in frontmatter of md files manually. However, this option do not override sidebar_label in md files if specified.
Have you read the Contributing Guidelines on pull requests?
Yes.
Test Plan
before:

after adding this code,
// docusaurus/website/versioned_sidebars/version-2.0.0-alpha.43-sidebars.json
   . . .
        {
          "type": "doc",
          "id": "version-2.0.0-alpha.43/blog"
        },
        {
          "type": "doc",
          "label": "test-doc-label",
          "id": "version-2.0.0-alpha.43/blog"
        },
    . . .

I get:

If on top of previous code, i add sidebar_label to blog.md,
---
id: blog
title: Blog
sidebar_label: 'Blog sidebar label'
---

I get:

Related PRs
https://github.com/facebook/docusaurus/pull/2375

@lex111 @slorber are you all in favor of this change? I feel that it's unnecessary but I guess it might not hurt. Leave it up to you guys to decide.

I'm fine with the idea.
What about:

making the sidebar label override the frontmatter label (instead of the opposite, currently implemented)?
warning if a label is provided both by sidebar and by frontmatter?

inactive and not really needed, so closing for now


Bug fix 349: handled issue of missing test directory at location of s…

…tatic_path

Good idea.
However, better would be to disable the menu item if the directory doesn't exist, or at least inform the user that we're not showing anything because there isn't anything to show. As you have it here, it would be just empty, and not obvious for the user why (<=which you can be sure will be reported as a bug).
At least, try something like
response.warning = T("No test results available")

in the except-branch.
Note that the test suite that produces the test results is deprecated and not working at the moment ;) so this "bug" is only the very tip of the iceberg.
What is really needed is something that actually produces test results - and while we don't have that, I would recommend to comment this menu item and put in a ToDo (in s3menus.py). No point to show a menu item that doesn't ever work.

We do have a new smoke test functionality, however - it's just not wired up to show any test results inside the application. And while it isn't, there's no point to have that menu item visible for the users.

Thanks for the review @nursix . That response warning is definitely a better way to communicate to the user there are no test results. I'll do what you said regarding removing the menu item and adding a ToDo.

Superseded by:
https://github.com/nursix/eden/commit/656045f74ef5ccfacf86cf722a58ea9683c4759b
...hence closing this one.
Thanks Matt :)


Update gdb_model_with.go

Codecov Report
Base: 79.61% // Head: 79.64% // Increases project coverage by +0.03% :tada:

Coverage data is based on head (308b474) compared to base (39fede6).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2418      +/-   ##
==========================================
+ Coverage   79.61%   79.64%   +0.03%
==========================================
  Files         598      596       -2
  Lines       49682    49562     -120
==========================================
- Hits        39554    39475      -79
+ Misses       8131     8094      -37
+ Partials     1997     1993       -4

Flag
Coverage Δ

go-1.15-386
?

go-1.15-amd64
?

go-1.16-386
?

go-1.16-amd64
?

go-1.17-386
?

go-1.17-amd64
79.64% <ø> (-0.01%)
:arrow_down:

go-1.18-386
?

go-1.18-amd64
?

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

Impacted Files
Coverage Δ

database/gdb/gdb_model_with.go
74.56% <ø> (ø)

os/gcron/gcron_schedule_fix.go
81.81% <0.00%> (-9.10%)
:arrow_down:

os/gfsnotify/gfsnotify_watcher_loop.go
78.15% <0.00%> (-7.57%)
:arrow_down:

net/gtcp/gtcp_pool.go
72.22% <0.00%> (-3.34%)
:arrow_down:

container/gmap/gmap_hash_str_any_map.go
97.00% <0.00%> (-1.00%)
:arrow_down:

container/gtree/gtree_avltree.go
95.40% <0.00%> (-0.58%)
:arrow_down:

contrib/config/kubecm/kubecm_kube.go

contrib/config/kubecm/kubecm.go

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Unable to download the TF provider version

TF Version: 0.15.5
Plan: Airbyte OSS
terraform {
  required_version = ">= 0.15.5"
  required_providers {
    airbyte = {
      source  = "registry.terraform.io/airbytehq/airbyte"
      version = "0.3.4"
    }
  }
}

The above TF provider results in the following error. Can you please help in resolving this issue?
Finding airbytehq/airbyte versions matching "0.3.4"...
╷
│ Error: Incompatible provider version
│
│ No compatible versions of provider registry.terraform.io/airbytehq/airbyte were found.

source should be "airbytehq/airbyte"
Latest documentation should always be on https://registry.terraform.io/providers/airbytehq/airbyte/latest/docs under "Use Provider"

Thanks. This can be closed


[#237] Move tpch mock statistic to UT

Move tpch mock statistic to UT
Remove tpch mock flag in session
Refactor code style of Utils.java/Config.java

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


How to use similarity settings  other then "BM25" in Elasticsearch index ?

QUESTION : How should we use other similarity algorithms supported by Elasticsearch other than "BM25"  ?
ES Reference
https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-similarity.html
HF doc reference:
https://huggingface.co/docs/datasets/faiss_and_ea.html
context :
I used the latest Elasticsearch server  version 7.9.2
When I set DFR  which is one of the other similarity algorithms supported by elasticsearch  in the mapping, I get an error
For example DFR that I had tried in the first instance in mappings as below.,
"mappings": {"properties": {"text": {"type": "text", "analyzer": "standard", "similarity": "DFR"}}},
I get the following error
RequestError: RequestError(400, 'mapper_parsing_exception', 'Unknown Similarity type [DFR] for field [text]')
The other thing as another option I had tried was to declare "similarity": "my_similarity" within settings and then assigning "my_similarity" inside the mappings as below
`es_config = {
"settings": {
"number_of_shards": 1,
"similarity":  "my_similarity": {
"type": "DFR",
"basic_model": "g",
"after_effect": "l",
"normalization": "h2",
"normalization.h2.c": "3.0"
} ,
"analysis": {"analyzer": {"stop_standard": {"type": "standard", " stopwords": "english"}}},
    },
    "mappings": {"properties": {"text": {"type": "text", "analyzer": "standard", "similarity": "my_similarity"}}},
}`

For this , I got the following error
RequestError: RequestError(400, 'illegal_argument_exception', 'unknown setting [index.similarity] please check that any required plugins are installed, or check the breaking changes documentation for removed settings')

Datasets does not use elasticsearch API to define custom similarity. If you want to use a custom similarity, the best would be to run a curl request directly to your elasticsearch instance (see sample hereafter, directly from ES documentation), then you should be able to use my_similarity in your configuration passed to datasets
curl -X PUT "localhost:9200/index?pretty" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "index": {
      "similarity": {
        "my_similarity": {
          "type": "DFR",
          "basic_model": "g",
          "after_effect": "l",
          "normalization": "h2",
          "normalization.h2.c": "3.0"
        }
      }
    }
  }
}
'


Style doesn't look properly

Hi everyone,
I'm using the bootstrap datepicker and I have a trouble with the calendar style.
Below a screenshot shows my issue clearly:

Can anyone please help me to fix this issue.
Thank you very much.

Here's the order of css and js files:

Hi,
It looks like something extraneous is messing with you css.
I recon to use some dev tools and look for suspicious css rules, most likely on the .odd class.
There is what you should have:


JSON Diagrams example not working

https://github.com/SAP/chevrotain/tree/master/diagrams

https://github.com/SAP/chevrotain/commit/d28eb378d5704e82e189f05ff3333cf29601b27c


fix: update required ibm provider version to < 1.7

/run pipeline

:tada: This PR is included in version 1.3.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Fixes segfault for when initializing Target list.

Fixes #1093
When initializing the targets, it is possible to remove the current item. The fix is to update the iterator pointer before initializing the target.

@ccaraman is going to be out for a few days so I fixed the compiler issue so we can get this fix in.


GPIO Interrupts Lost (IDFGH-8258)

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.

IDF version.
v5.1-dev-644-g867745a05c
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
No response
Development Kit.
LOLIN32 v1.0.0
Power Supply used.
USB
What is the expected behavior?
I have two sensor ICs, generating edge triggered GPIO interrupts, waking their respective worker tasks.
After a random period, between minutes and hours, one of these interrupts is missed. In the case of our particular device the missed interrupt results in a FIFO overflow and no further communication from the device.
I've captured several of these events on a logic analyser, and found them to be related to the two interrupts arriving at virtually the same time (separated by microseconds).
I'd expect the ESP32 to be able to handle interrupts arriving close together.
What is the actual behavior?
Instead the earlier interrupt is handled and the slightly later interrupt is lost.

In the screenshot above:
The blue trace "Pres ISR", signal is one of the interrupt lines.
The purple trace "IMU ISR" is the other interrupt line.
Both rising edge triggered.
The blue rising edge occurs in this case 1.55uS before the purple rising edge.
The green trace "IMU ISR -> Task" is that of a GPIO line which is set in the GPIO interrupt handler and cleared in the FreeRTOS task after the interrupt has been handled.
It remains low the entire time, indicating that the interrupt handler hasn't been called, which in turn hasn't woken the worker task.
Steps to reproduce.
I was able to reproduce this behaviour with a signal generator and the following minimal application.
main.c.zip
Providing 1Khz square waves on GPIO 23 and 27 (selected due to being the lines used in our product), synchronised but delayed with respect to one another.
In the interrupt handlers, the lower numbered GPIO (23), sets a GPIO line high and the higher numbered GPIO (27)'s handler clears the same GPIO. The expected behaviour is therefore short pulses on the GPIO line, as follows:

Varying the delay between the first and second interrupt and zooming out, we see periods where the second interrupt begins to be missed (indicated by the GPIO line remaining high).

The "sweet spot" on this particular device appears to be 2.44uS.

Marker 3 with a delay of 2.41uS is handled correctly, where as marker 4 with a delay of 2.44uS is consistently missed. Increasing the delay further to 2.46uS resolves the issue and both interrupts are once again seen.
The duty cycle of the first interrupt is longer to match my original hardware setup, the same behaviour occurs with similarly short duty cycles.
While debugging this issue I found changeset 0637ea91a3c2c0f3a7ef4a80be685a1dc85a9cdf by @songruo which I'd hoped would resolve the issue, unfortunately it hasn't.
I'm happy to help debug the issue / try and fixes / workarounds....I just really need to get it fixed.
Debug Logs.
No response
More Information.
No response

Check errata 3.14 in ECO documents https://espressif.com/en/support/documents/technical-documents

Hi @pgreenland,
Very nice troubleshot! Based on your troubleshot result, I do think it is due to the hardware bug with ESP32 (see the document ECO and Workarounds for Bugs in ESP32 section 3.14 mentioned by @negativekelvin).
Let me give you some more information about this bug: At the clock when the GPIO_STATUS_W1TS_REG or GPIO_STATUS_W1TC_REG is being operated, the GPIO status of the whole 32-bit register cannot be updated. Therefore, the edge-triggered interrupt will be lost if the GPIO interrupt is sampled at the same time of an interrupt status clear operation. And this is what I believe have happened at the "sweet spot" moment!
Please try to see if you can workaround this problem by changing edge-triggered GPIO interrupt to level-triggered.

Hi @songruo and @negativekelvin ,
Thanks for the reply and explanation.
I believe the hardware bug indicated is what I've been experiencing.
I Implemented the workaround as described and can no longer see the issue with test performed above.
Considering the nature of this issue, it may be worth either fixing it in the SDK, such that all edge triggered interrupts are converted to level triggered, as per the workaround?
Or adding a warning in the documentation noting that edge triggered interrupts do not work properly. I had a quick look and couldn't see anything to suggest there is a problem with them.
I've attached the my workaround in case other users find it useful.
gpio_isr_workaround.h.txt
Which can be used as follows
static stGPIO_ISR_WORKAROUND_State_t eISRState

void SetupInterrupt()
{
	gpio_isr_handler_add(INTERRUPT_PIN_NUMBER, ExampleInterruptHandler, NULL);
	GPIO_ISR_WORKAROUND_InitAndEnableISR(&eISRState, INTERRUPT_PIN_NUMBER, false);
}

static void IRAM_ATTR ExampleInterruptHandler(void* pvArg)
{
	if (!GPIO_ISR_WORKAROUND_Process(&eISRState))
	{
		/* Workaround says interrupt hasn't really triggered */
		return;
	}

	/* Handle interrupt as required */
}

Regards,
Phil

With this workaround I get a
Guru Meditation Error: Core  0 panic'ed (Cache disabled but cached memory region accessed).
in gpio_set_intr_type. Will try to investigate further.

Put the functions called from the ISR and eISRState in D/IRAM or don't pass the ESP_INTR_FLAG_IRAM flag to interrupt setup functions.

@KaeLL Could you correct my example above?
I've not seen any issues with guru mediation myself, but any pointers on getting the interrupt handling code into the right memory would be appreciated
Thanks, Phil

Espressif needs to make gpio_set_intr_type IRAM_ATTR.

Or use
GPIO.pin[NUMBER].int_type = GPIO_INTR_HIGH_LEVEL;
and
GPIO.pin[NUMBER].int_type = GPIO_INTR_LOW_LEVEL;
in the ISR.

@songruo

Why isn't the workaround suggested by the errata already in IDF?
What exactly are the risks making changes to the GPIO struct directly instead of through the public APIs/gpio_spinlock?

Also, either the wording for workaround 1 in the errata is ambiguous, or I'm completely oblivious as to what it means.

Set the GPIO interrupt type to low/high
Set the interrupt trigger type of the CPU to edge.

Aren't interrupt type and trigger type the same thing, in the context of the GPIO public API or otherwise? If so, is that really suggesting to call gpio_set_intr_type twice, one after the other, the first setting the interrupt type to level and the second to edge? Seems redundant, which is why I'm wary of my interpretation.
And if they're not the same, how exactly 'interrupt type' and 'interrupt trigger type' differ?

Hi @KaeLL,
The workaround suggested by the errata is more like a workaround at application level. However, I think there might be something we can add to the GPIO ISR to workaround the hardware bug by comparing the GPIO.in.val before and after the interrupt status clear operation, but concurrency needs to be handled carefully, we will investigate into this.
Regarding the difference of writing to the GPIO struct directly and calling public GPIO APIs is only the spinlock protection. GPIO driver provides this additional protection for register write process. The reason why we didn't make gpio_set_intr_type function being placed in IRAM as an option is because we don't recommend calling it from the ISR content. However, now it looks like a "must" operation to workaround the ESP32 interrupt lost bug in the application layer. We will either provide a built-in workaround in IDF or consider making gpio_set_intr_type IRAM-safe.
Lastly, the peripheral interrupt sources are mapped to the CPU interrupts (this is so-called the Interrupt Matrix, please check TRM Interrupt Matrix chapter for more information). Both the GPIO interrupt source and the CPU interrupt have the choice of their trigger types.

I have a system with 10 independent edge trigger interrupt inputs, and I have been chasing this issue for weeks.  None of the other "fixes" I have found have corrected this problem.  I am hopeful that this approach may.  I am not specifically sure how to go about implementing it....does anyone have some more specific details?

Hi @pgreenland could this method be used for the scenario where you would like to have edge interrupt on pin state change?  I need to determine the Rising and Falling edge as I am calculating duty cycle of a signal.  Also, how hard would this be to integrate in into the Arduino ESP32 2.0.5 core library?

Hi @tommy1394,
I believe it should do. In terms of integrating with the Arduino ESP32 core, I suspect (haven't checked) that you'd be able to do everything with API on offer.
The issue as I understand it is a race condition between the processor resetting the interrupt status, and a new edge triggered interrupt arriving, causing an edge triggered interrupt to be lost.
The workaround is to use level triggered interrupts to emulate an edge triggered interrupt.
In the Arduino environment you'd reconfigure your edge triggered interrupts as level triggered, looking for either a high or low level. On the next interrupt you swap the config to look for the opposite level.
In my case my hardware uses active low interrupts, so the interrupt line idles high. I configure my GPIO pin to interrupt on low level. When the interrupt is triggered, I've seen my falling edge. In that interrupt handler I perform the required action (schedule a task to handle the interrupt). Then reconfigure the interrupt to trigger on a high level. When the interrupt line is de-asserted by the interrupting device and returns to a high level, I get another interrupt which I ignore using a flag and again reconfigure for a low level.
Slightly annoying in my case as I'm handing two interrupts for every real one. Although it sounds like you're interested in both edges, so this wouldn't be a problem for you.
Hope that helps,
Phil

@songruo whatever happened to

We will either provide a built-in workaround in IDF or consider making gpio_set_intr_type IRAM-safe.

?

If you ask me, as soon as someone compiles an app for the ESP32 using edge interrupts, a warning should appear.


Theme idea help no dupe

This builds upon/includes #1740
It introduces a live "Please consider if these other themes aren't similar enough to what you are writing that you don't have to suggest it yourself".
It's not perfect but it's a start:

It's hard to capture what may be similar ideas for themes without understanding them so I weighted two common metrics into a single score. It has issues on very short suggestions (2-3 characters long), saying that everything is very similar to everything else short. That might be fine. It will still find if there's an identical or near identical match and present it first.
The other issue is that the <input onchange/> function seems a bit buggy or at least sub-optimal. It lags one character in firing the events so if you had previously typed hell and just entered an o, you would see hello but the event to fire would be hell. If you defocus the input or add another character like  . It would fire hello. This means that the suggestions are lagging behind all the time (can sort of be seen in the gif).
It uses historical data of LD-event, recent events (on new site), everyone's suggestions thus far on this event.
If you suggestion according to the metrics is awfully close to an existing, they are colored red. If what is similar is an old theme, it will say LD 32 or such (as you see towards the end of the gif).

Indirect interaction
Guardian
Construction/destruction (sheep)
Preparation – Set it up, let it go
Infection
Random
Light and darkness
Growth
Swarms
Moon/anti-text
Build the level you play
Chain reaction
Weird/unexpected/surprise
Minimalist
The tower
Roads
Advancing wall of doom
Caverns
Exploration
Islands
Enemies as weapons
Discovery
It’s dangerous to go alone! Take this!
Escape
Alone (kitten challenge)
Tiny world
Evolution
You are the villain (goat)
Minimalism (potato)
10 seconds
You only get one
Beneath the surface
Connected Worlds
Entire Game on One Screen
An Unconventional Weapon
You are the Monster
Growing/two button controls
Shapeshift
Ancient Technology
One Room

Plain text list of old themes if you would like.

Thanks, I think $ThemeHistory.Get() gives the same but there might be a point in storing it directly in the HTML rather than doing the extra API request. Mike can decide on that.

Yeah http://api.ldjam.com/vx/theme/history/get was written specifically for
this. Speaking of, if you can think of anything data-wise that should be
added or tweaked (I'm thinking we should have a field for ID, so history
can make reference to locally run events) let me know. We definitely need a
shell script for adding to the list. I may tweak the internals a bit to
better parallel the true data also (i.e. include a path or slug).
On Sun., Aug. 19, 2018, 05:46 Martin Zackrisson<EMAIL_ADDRESS>wrote:

Thanks, I think $ThemeHistory.Get() gives the same but there might be a
point in storing it directly in the HTML rather than doing the extra API
request. Mike can decide on that.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/ludumdare/ludumdare/pull/1741#issuecomment-414116238,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2CRiXJnj9rBYA4N3Dj3tK9cLZHjRkks5uSTPigaJpZM4WCGvA
.

Oh ok, I didn't know there was an API to get old themes.
On Sun, Aug 19, 2018, 9:42 AM Mike Kasprzak<EMAIL_ADDRESS>wrote:

Yeah http://api.ldjam.com/vx/theme/history/get was written specifically
for
this. Speaking of, if you can think of anything data-wise that should be
added or tweaked (I'm thinking we should have a field for ID, so history
can make reference to locally run events) let me know. We definitely need a
shell script for adding to the list. I may tweak the internals a bit to
better parallel the true data also (i.e. include a path or slug).
On Sun., Aug. 19, 2018, 05:46 Martin Zackrisson<EMAIL_ADDRESS>
wrote:

Thanks, I think $ThemeHistory.Get() gives the same but there might be a
point in storing it directly in the HTML rather than doing the extra API
request. Mike can decide on that.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<https://github.com/ludumdare/ludumdare/pull/1741#issuecomment-414116238
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ABf2CRiXJnj9rBYA4N3Dj3tK9cLZHjRkks5uSTPigaJpZM4WCGvA
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ludumdare/ludumdare/pull/1741#issuecomment-414128707,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMGa8GSq0ZLdC-B6v9USP9OAPh-uvVjyks5uSWs8gaJpZM4WCGvA
.

@mikekasprzak I parse the ld-number now because I wanted it short (as you can see in the gif), if endpoint had it that would be sweet.


Update the version of x86_64 crate

Old asm! is no longer supported.

Thanks!
Can you bump the version one up to version = "0.1.3", so I can directly release to crates.io afterwards?

Published at https://crates.io/crates/qemu-exit


🩹 Fix deprecation warning for using xr.Dataset.dim

This change fixes the deprecation warning:
FutureWarning: The return type of `Dataset.dims` will be changed to return a set of dimension names in future, in order to be more consistent with `DataArray.dims`. To access a mapping from dimension names to lengths, please use `Dataset.sizes`.
  center_λ = min(res.dims["spectral"], round(res.dims["spectral"] / 2))

When center_λ has its default value of None.
However, when fixing this I found that we have a bug.
First of all:
min(res.sizes["spectral"], round(res.sizes["spectral"] / 2))

will always return round(res.sizes["spectral"] / 2) since res.sizes["spectral"] is the length of the spectral coordinate (same goes for the current and past behavior of res.dims["spectral"])
But since this value is later used with xr.DataArray.sel it leads to a wrong behavior since now center_λ isn't a spectral value but the index of it, resulting in the first wavelength being selected.
Example plot for the 4TT case study
Current behavior with omitted center_λ

Current behavior with set center_λ

So I think we should change the fallback to:
center_λ = res.coords["spectral"].mean().item()

or
center_λ = res.coords["spectral"].isel(spectral=res.sizes["spectral"]//2).item()

to take none equidistant spectral axes into account.
Change summary

🩹 Fix deprecation warning for using xr.Dataset.dim

Checklist

[x] ✔ Passing the tests (mandatory for all PR's)

Historically we've always selected the first wavelength if not explicitly provided.


How to change the color when I hover over a row in a table?

If I understood correctly, there are 3 elements that decide on how to customize our table which are:

MUIDataTable
MUIDataTableBodyRow
MUIDataTableBodyCell

But I cannot find any documentation on how to customize them. I keep google'ing but nothing comes up. For example,
MUIDataTableBodyCell: {   root: {             fontSize: "16px",           },         },
How can I know that there is a property called "fontSize"? Where can I find the documentation?
I'd like to change the color when I hover over a row in a table
Edit: I also want to choose the color when I select a row on the table
Thanks.
Emirhan Ulken

See: https://github.com/gregnb/mui-datatables/issues/1517


feat(TranslateService): streaming translations that update on language change

Description
As mentioned in #330 this method would drastically simplify several of our components and allows for the idiomatic use of the async pipe with the TranslationService in the cases where using the translate pipe is - for some reason - undesirable. As a comparison:
Current:
@Component({
  template: `

{{a}}

{{b}}

{{c}}

  `
})
export class TestComponent implements OnInit, OnDestroy {
  a: string;
  b: string;
  c: string;
  private subscription: Subscription<any>;

  constructor(private translate: TranslateService) { }

  ngOnInit() {
    this.subscription = this.translate.get(['a', 'b', 'c'])
      .concat(this.translate.onLangChange.map(event => event.translations))
      .subscribe(translations => {
        this.a = translations.a;
        this.b = translations.b;
        this.c = translations.c;
      });
  }

  ngOnDestroy() {
    this.subscription.unsubscribe();
  }
}

New (per-translation Observable):
@Component({
  template: `

{{a$ | async}}

{{b$ | async}}

{{c$ | async}}

  `
})
export class TestComponent implements OnInit {
  a$: Observable<string>;
  b$: Observable<string>;
  c$: Observable<string>;

  constructor(private translate: TranslateService) { }

  ngOnInit() {
    this.a$ = this.translate.stream('a');
    this.b$ = this.translate.stream('b');
    this.c$ = this.translate.stream('c');
  }
}

New (array-based Observable):
@Component({
  template: `
    <ng-container *ngIf="translations$ | async as translation">

{{translation.a}}

{{translation.b}}

{{translation.c}}

    </ng-container>
  `
})
export class TestComponent implements OnInit {
  translations$: Observable<{ [key: string]: string }>;

  constructor(private translate: TranslateService) { }

  ngOnInit() {
    this.translations$ = this.translate.stream(['a', 'b', 'c']);
  }
}

I want to note here that the middle solution is suboptimal: it creates 3 subscriptions instead of one. Still, the last example is pretty motivating I think: mostly everything is declarative and we don't have to bother with manually unsubscribing from any Observables.
Implementation
I tried to mirror the implementation of get/instant, using the building blocks that are already there. Please tell me if there's anything to improve on (the same goes for the unit tests).
Closes #330

I like the middle example but what about adding this capability?
[
  this.a$,
  this.b$,
  this.c$
] = this.translate.stream(['a', 'b', 'c']);

That condenses things a little.

The current API deliberately mirrors that of get and instant: translating an array of keys returns an object where the keys are the translation keys you've given and the values are the translated text.
If you don't actually need the three observables and you don't like <ng-container> for some reason, you can modify the 3rd example slightly:
@Component({
  template: `

{{($translations | async)?.a}}

{{($translations | async)?.b}}

{{($translations | async)?.c}}

  `
})
export class TestComponent implements OnInit {
  translations$: Observable<{ [key: string]: string }>;

  constructor(private translate: TranslateService) { }

  ngOnInit() {
    this.translations$ = this.translate.stream(['a', 'b', 'c']);
  }
}

I would argue that the original 3rd example is objectively better than this one:

It makes it more obvious that you need to handle the case where the translations aren't loaded yet
It only creates a single subscription

Thanks a lot for this PR, it's merged!


Capybara fill_in does not trigger the search

Since I updated to version 4.2.2, my integration test does not works. The method fill_in does not not trigger the search. So, there is some way to trigger the search manually? I would like something like that:
page.execute_script $('#user_id').val('bevacqua').trigger('search')
Just .val() does not trigger the search, neither the Capybara fill_in.
Thank you.

My hack was:

keep the horsey object on field as data (to be possible to access from outside).
Capybara set a value.
Call show method on horsey object (doc does not tell that it makes the search).
Trigger a focus on field (the show method still needs a focus to show the list).

Full solution:
var horse = horsey(document.getElementById('horsey'), {});
var field = $('#horsey');

field.data('horsey', horse).val('bevacqua').data('horsey').show();
field.trigger('focus');


Failed to execute 'appendChild' on 'Node'

Description
I'm getting a really weird issue, that only appears to be happening on Chrome on Android (v72.0.3626, can't confirm other versions).
Steps to reproduce
On a Android device (ideally hooked up via ADB + Chrome inspector):

go to https://2019.steveedson.co.uk
click on one of my articles
notice no console errors
refresh the page
Get the error:

Failed to execute 'appendChild' on 'Node': This node type does not support this method.

It will then break the rest of the JS execution, the router links and other Vue bindings no longer work. This is fine on desktop though.
"Error: Failed to execute 'appendChild' on 'Node': This node type does not support this method.
    at Object.appendChild (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5161:8)
    at insert (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5472:17)
    at createElm (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5390:9)
    at createChildren (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5481:9)
    at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5809:11)
    at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5824:34)
    at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5824:34)
    at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5824:34)
    at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5824:34)
    at VueComponent.patch [as __patch__] (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5900:17)"

Expected result
No errors on mobile.
Environment

Libs:
- gridsome version: 0.5.4
- @gridsome/cli version: 0.0.7

Browser:
- [ ] Chrome (desktop) version XX
- [x] Chrome (Android) version v72.0.3626
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX

For Tooling issues:
- Node version: v8.12.0
- Platform:  Mac / Linux

I think I've just figured this out actually, the only thing I could think of was a share button, that is only enabled if the browser supports the navigator.share API. I check for this in my main.js file:
export default (Vue, {router, head, isClient}) => {
    Vue.prototype.$sharingEnabled = isClient && !!navigator.share;
    ...

and then use it in my templates like so:
            <button class="uk-button uk-button-primary" v-if="$sharingEnabled" @click.prevent="sharePost">

                Share
            </button>

I've just changed the v-if to v-show, and it's solved the issue. My only guess is that because the v-if removes the element during SSR, it can't be hydrated during the client side render, causing the issue? Would this make sense?

v-if should have worked while server-side rendering. You can try to build in development mode by adding config.mode('development') to your webpack config. That will give you a better error message to understand where hydration went wrong. Alternatively, disable JS in the browser and see if the DOM is how you would expect it to be.

I'm getting the same issue on a site I recently deployed.
I'm traversing the DOM in the mounted() hook of a component. It simply gets all headings on the page and adds them to the data, so I can loop over them and show a table of contents to the side of the article.
More details in the issue; code can be seen here.
v-if really doesn't work, you can see on that site that the next/prev pagination at the bottom of the article is broken: if you come from the homepage, it works fine, but if you load some page directly, you'll see it's not actually there in the HTML...

@cossssmin You could check out the headings field for markdown nodes. It will generate a list of headings for you.

Thanks @hjvedvik , that solved it for me! :)

For others that are having a similar issue, I was having the same error in sentry.io reports. It turned out to be that I had a computed property called gpsAvailable and was doing a  v-if="gpsAvailable" in my template, I changed it to  v-show="gpsAvailable" and that fixed it. apparently something to do with SSR re-hydration. Other googling lead me to similar things all dealing with newer browser API's like location or websharing etc or malformed HTML.
computed: {
gpsAvailable() {
     if(process.isClient && typeof window !== 'undefined' && typeof window.navigator !== 'undefined'){
        return navigator.geolocation ? true : false;
      }else{
        return false;
      }
    }
}

I've tried replacing v-if with v-show but I'm still getting this error. I'm not using any new browser APIs, and it's happening in Firefox as well but with a slightly different message: HierarchyRequestError: Node cannot be inserted at the specified point in the hierarchy. Here's a deployment: https://5da7f3765d0dd7000b7a1eea--macguire.netlify.com/
Any ideas?

Hi,
I run the exact same bug, and i'm kind of surprised that it is close
to us, a v-show is not an option since it will be rendered even if the condition is falsy - and so may duplicate some unwanted content...
I've made an exemple in this repo
Here's what we try to do
in main.js, we create a store that will compute a layout data state (desktop|mobile) based on our current viewport (and updated on resize)
so we may be able to display differents components based on our viewport
Since we don't have access to window during build, we default our state to a mobile layout
state(){
  return {
    layout: computeLayout(),
  }
},
...
function computeLayout() {
  if (process.isClient && document.body.offsetWidth >= 600) {
    return 'desktop';
  }
  return 'mobile';
}

Then, in our pages, we want to display different component so we use the v-if directive to do so
exemple
<Big3dHero class="hero" v-if="layout==='desktop'" />
<SimpleImageHero class="hero" v-else />

The error
since we build for mobile
if we load our page directly within a desktop viewport, we run this error
DOMException: Failed to execute 'appendChild' on 'Node': This node type does not support this method.
and then some part of our application break
But, if we load our same page from a mobile layout and then resize, or from an other page and then navigate to our buggy page, it will work as expected
Thanks
Please, have a look to that repo, I've tried to be as explicit as i can :)
Thanks a lot in advance

Another instance where I've seen this error appear (just spent 2 hours debugging it 🤕) is if you have a  tag anywhere in your site. After I removed them and replaced them with v-ifs and a variable to see if a component has been mounted or not the error went away.

Same issue here.  I'm not using any v-if or v-show.  Inserted no-ssr tag on netlify form, removed all g-image tags.  Tried just about every fix I could find in these threads, though I didn't understand what @hjvedvik meant about headings  field for markdown nodes.
I think it's a hydration error, but I can't figure out what to do about it.  It only occurs when directly accessing the About page and trying to navigate elsewhere.
Console error is copied below, repo is here.  Any help is appreciated!
Uncaught (in promise) DOMException: Failed to execute 'appendChild' on 'Node': This node type does not support this method.     at Object.appendChild (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5190:8)     at insert (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5501:17)     at createElm (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5428:7)     at createChildren (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5510:9)     at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5838:11)     at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5853:34)     at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5853:34)     at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5853:34)     at VueComponent.patch [as __patch__] (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5929:17)     at VueComponent.Vue._update (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3588:19)     at VueComponent.updateComponent (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3676:10)     at Watcher.get (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:4062:25)     at new Watcher (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:4051:12)     at mountComponent (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3683:3)     at VueComponent.Vue.$mount (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:7819:10)     at init (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:2816:13)     at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5827:56)     at VueComponent.patch [as __patch__] (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5929:17)     at VueComponent.Vue._update (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3588:19)     at VueComponent.updateComponent (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3676:10)     at Watcher.get (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:4062:25)     at new Watcher (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:4051:12)     at mountComponent (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3683:3)     at VueComponent.Vue.$mount (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:7819:10)     at init (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:2816:13)     at merged (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:2997:5)     at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5827:56)     at VueComponent.patch [as __patch__] (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5929:17)     at VueComponent.Vue._update (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3588:19)     at VueComponent.updateComponent (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3676:10)     at Watcher.get (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:4062:25)     at new Watcher (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:4051:12)     at mountComponent (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3683:3)     at VueComponent.Vue.$mount (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:7819:10)     at init (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:2816:13)     at hydrate (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5827:56)     at Vue.patch [as __patch__] (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:5929:17)     at Vue._update (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3588:19)     at Vue.updateComponent (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3676:10)     at Watcher.get (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:4062:25)     at new Watcher (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:4051:12)     at mountComponent (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:3683:3)     at Vue.$mount (webpack:///./node_modules/vue/dist/vue.runtime.esm.js?:7819:10)     at eval (webpack:///./node_modules/gridsome/app/entry.client.js?:115:7)     at eval (webpack:///./node_modules/vue-router/dist/vue-router.esm.js?:1960:11)     at Array.forEach (<anonymous>)     at eval (webpack:///./node_modules/vue-router/dist/vue-router.esm.js?:1959:25)     at eval (webpack:///./node_modules/vue-router/dist/vue-router.esm.js?:2074:7)     at step (webpack:///./node_modules/vue-router/dist/vue-router.esm.js?:1758:7)     at step (webpack:///./node_modules/vue-router/dist/vue-router.esm.js?:1765:9)

Same problem, same solution as @MFukazawa , had a

changed it to a DIV tag and that was it.
Hard to find though ...

I had invalid HTML. I found a duplicate id attribute by changing all v-if on the app to v-show.
[DOM] Found 2 elements with non-unique id #apero-firstname: (More info: https://goo.gl/9p2vKq)

Maybe this helps somebody struggling with this super unhelpful error message.

Using Gridsome 0.7.13, I got the following error in Firefox (not Chrome):
HierarchyRequestError: Node cannot be inserted at the specified point in the hierarchy
Replacing v-if with v-show throughout my code fixed the issue.

Another instance where I've seen this error appear (just spent 2 hours debugging it :face_with_head_bandage:) is if you have a  tag anywhere in your site. After I removed them and replaced them with v-ifs and a variable to see if a component has been mounted or not the error went away.

@weaversam8 I'm running into this too. (Luckily I stumbled upon your post after 2 hours; else I'd have still been stumbling). Removing s solved the problem. Should I open a new issue/bug report for this?

Should open new issue/bug report for this?

@badrihippo - so far this issue is okay for recognizing and preventing the behavior, but if you want to open a new issue specifically targeting Gridsome's lack of  support, that wouldn't be a bad idea.

Thanks @weaversam8. Had the same issue. I can confirm the problem with the missing support for . This should definitely be mentioned in the docs.

@badrihippo @weaversam8 @Tummerhore I don't think Vue has support for  tags. I had the same problem when making the <g-image> component. It renders a fallback image in a  tag and I had to insert the fallback image as an HTML string to make it work (see here). I haven't tested, but  might work too.

I've been running into this on build when deploying to Netlify (not in local dev).
Here's the error message in the latest Chrome:

Uncaught (in promise) DOMException: Failed to execute 'appendChild' on 'Node': This node type does not support this method.
at Object.appendChild (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:40605)
at h (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:53337)
at d (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:53074)
at p (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:53423)
at k (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:56761)
at k (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:56696)
at k (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:56696)
at k (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:56696)
at k (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:56696)
at k (https://www.dharmaworks.com/assets/js/app.af37cffe.js:7:56696)

I don't have a clue as to how to debug this. Any pointers would be appreciated.

Hi @platform-kit!
Did you follow the debugging steps listed in this thread? The main cases of this error we've seen so far are:

Including a  tag - a  tag anywhere in your project could cause this
Adding HTML to an inline element - using the v-html directive on a
 tag instead of a
 tag could cause this, for example
Using v-if - If you're using the v-if directive instead of v-show, this can sometimes cause this issue. If it's possible to use v-show, give that a try.

Am I missing anything here folks? If none of these solve your problem, could you post a link to your repository?

I did see those ideas and none of them fixed the issue. For now, wrapping my entire layout in client-only has done the trick.

@platform-kit - if you progressively move the <ClientOnly> tag to deeper and deeper levels, can you isolate the element / component which is causing this issue?

I seem to have some odd variant of this issue. My site (based on github.com/calebanthony/gridsome-bulma) works normally in Firefox or Safari. In Chrome or Vivaldi, it initially loads properly. I can reload the "Index" page and it all reloads successfully.  Until I do an intentional reload on the Index page.
Here is the Console error:

The main cases of this error we've seen so far are:
Including a noscript tag - a  noscript tag anywhere in your project could cause this

"noscript" is not found anywhere in the part of my project I control. It appears 148 times in the \dist\ files, \node_modules.cache, and \node_modules... js files that are automatically built that I've never touched.
Each image has a noscript section - but they are there exactly the same when the site loads properly:

Adding HTML to an inline element - using the v-html directive on a p tag instead of a div tag could cause this, for example
Using v-if - If you're using the v-if directive instead of v-show, this can sometimes cause this issue. If it's possible to use v-show, give that a try.

"v-html" is likewise all over the cache and js files, but only two in my files - Post.vue:

        <PostTags :post="$page.post" />

And PostCard.vue

      <g-link
        :to="post.path"
        class="width-770 is-size-4 has-text-weight-bold"
      >
        {{ post.title }}
      </g-link>

      <PostMeta :post="post" />

Neither of those seem particularly focused on the images. "v-if" is in PostCard, plus Author.vue, PostMeta, and Default.vue. Also related to lots of elements which do not seem to be problems.
So the noscript section for every image seems most suspicious. But I don't (that I know of) have any control over that. And as I said, it is only a problem in Chrome-based browsers, and only if the user reloads a "Post" page - even though all images in all pages have the noscript section.
If anyone understands this I'd love to hear your thoughts!

Here's a hunch - are you dynamically setting the src attribute of g-image? Something like <g-image :src="boundVariable /> vs something like <g-image src="~/assets/image.png" />?

@weaversam8 Thank You! Looks like I am - in the "Post" pages that fail:

  <g-image
    alt="Cover image"
    :src="$page.post.cover_image"
  />

[Wow - the "code" and "quote" options here both still interpret a bunch of what I try to include...  Had to cut it to bare minimum.]
And also in the template for Index page items:

    <g-image
      alt="Cover image"
      :src="post.cover_image"
    />

I see what you're saying about an actual file as the target, but those templates format all of the posts on my site, reading the actual file instances from post files with only Markdown in them. Seems the variable is essential.
But then how does this work - the Index page strings together all of those "post card" instances with the variables for file name, and it works! Refreshing it fixes all the images (and doesn't get the exception) after refreshing a single post ruins them all:

  <PostCard
    v-for="edge in $page.posts.edges"
    :key="edge.node.id"
    :post="edge.node"
  />

Pretty obvious I'm in over my head here...
Also, I was wrong about Firefox and Safari not showing this problem. I couldn't make it happen last night, but when they woke up today both of them now show the same problem as Chrome / Vivaldi. I'm pretty sure this wasn't a problem a month ago. Could one of these updates have triggered it:

bulma                       ^0.7.5  →   ^0.8.2
gridsome                   ^0.7.13  →  ^0.7.14
babel-eslint               ^10.0.3  →  ^10.1.0
eslint                     ^5.16.0  →   ^6.8.0
eslint-config-airbnb-base  ^13.2.0  →  ^14.1.0
eslint-plugin-gridsome      ^1.4.0  →   ^1.4.9
eslint-plugin-import       ^2.19.1  →  ^2.20.2
eslint-plugin-vue           ^5.2.3  →   ^6.2.2
gh-pages                    ^2.1.1  →   ^2.2.0
lint-staged                 ^8.2.1  →  ^10.2.2
node-sass                  ^4.13.1  →  ^4.14.0
sass-loader                 ^7.3.1  →   ^8.0.2

@LorenAmelang - it's been a minute since I had this issue, but it was my understanding that you can run into issues when using dynamic image URLs with <g-image> specifically.
I just checked another one of my Gridsome projects though, and I use the same sort of thing.
The question you should ask yourself: can Gridsome easily calculate the image URLs during the build process? Since Gridsome has to generate the static HTML, we have to make sure the data is there and doesn't change during the generation process.
Sometimes, invalid code for the static site generator appears to work when you're navigating the application as a hydrated SPA (for example, start on the home page and click to a broken page and suddenly it works, but it doesn't work when you navigate to that page directly and reload.) Sometimes it's the other way around. Can you isolate either of these as the failure mode?

@weaversam8  - Really appreciate your help!
Start on the home "Index" page, or refresh it if the images are broken, and everything works. Start on a "Post" page, or refresh one, and all images all over the site appear as the blurred initial version and never load the full resolution version. If I go click on \dist<post>\index.html, even the image in the unstyled page is blurred.
I'm not attached to the blurred initial images. I guess that "lazy load" thing supposedly gives you better performance stats? But my site is really simple, I'd be happy to just eliminate the blurred versions - but I haven't a clue how to do that.
"we have to make sure the data is there and doesn't change during the generation process" - I have no idea what order it creates things in, but I'm certainly not changing any sources during the build.
Here's the index.html version of the blurred image, with some line breaks added. The same stuff I see in DevTools in my browser:
<img alt="Cover image" src="data:image/svg+xml,%3csvg fill='none' viewBox='0 0 770 35' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'%3e%3cdefs%3e%3cfilter id='__svg-blur-afb0f020fcfe09814c87a8675443b991'%3e%3cfeGaussianBlur in='SourceGraphic' stdDeviation='1'/%3e%3c/filter%3e%3c/defs%3e%3cimage x='0' y='0' filter='url(%23__svg-blur-afb0f020fcfe09814c87a8675443b991)' width='770' height='35'

xlink:href='data:image/jpeg%3bbase64%2c/9j/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAADAEADASIAAhEBAxEB/8QAFwABAQEBAAAAAAAAAAAAAAAAAAECCP/EACQQAAECBQMFAQAAAAAAAAAAAAEAAgMREjJhFCEiBDFCUXFB/8QAGAEAAgMAAAAAAAAAAAAAAAAAAQIAAwb/xAAfEQACAQQCAwAAAAAAAAAAAAAAAUECERIxIbFSssH/2gAMAwEAAhEDEQA/AOatREDZcJTAsb6%2bK6iJsOHkbG%2b/iItEqacrWmr4UvRD1ESnw2aJcG%2bhha1DzE3ouAsb2BOERKqU4hewTI6mJTVwnImxveQwmoiBplR%2bCxucIibFZaldMEFHURJgcJVHwbjCzqIlLbNmk2N774REuK4VvLpEg//Z' /%3e%3c/svg%3e" width="770"

data-src="/assets/static/dnaComp-770-35.8253719.0a243b868cff8b60aa0fcb682eaa2d15.jpg"
data-srcset="/assets/static/dnaComp-770-35.8253719.0a243b868cff8b60aa0fcb682eaa2d15.jpg 770w" data-sizes="(max-width: 770px) 100vw, 770px" class="g-image g-image--lazy g-image--loading">

And here's the full resolution version, always shown below the blurred code, in a noscript section - but pointing to the same exact .jpg file:

Obviously the correct image file is built into the html. Somehow the appendChild DOMException just prevents the second form from being loaded over the first blurred one. But it only appears if the Post is accessed or refreshed directly, without loading the Index first. Maybe there is some "lazy load" routine that loads with Index but not with individual Posts?
I see people talking about a "replaceChild" call, which sounds like what needs to happen rather than appending another image. But I don't even know if that's what the appendChild call is trying to do. And my site used to work, with the current code...

@LorenAmelang - if it's loading in certain scenarios and not others, that means you might have done something that doesn't work in the static site (like dynamic src attributes on g-image) but does work when the page hydrates into a Vue SPA.
If you want to load images without the blur / lazy loading, then just use an  tag instead of a <g-image> tag, and it should work fine.

If you go to
https://calebanthony.github.io/gridsome-bulma/
it behaves exactly like my site did - refresh works on Index, shows blur image on Post, Index is then blurred and must be refreshed, which fixes Post.
If you go directly to
https://calebanthony.github.io/gridsome-bulma/markdown-test-file
Vivaldi and Firefox show the blur image right away and refresh doesn't fix it. For awhile, the Index page did not get corrupted, you could go there and see sharp images, and opening the Post again from the Index page loaded the full image.
Somebody is apparently caching some files even through forced reloads!
Changing g-image to img flips the sort of the Index page, and shows no Post images at all:

Changing back leaves the sort reversed, but the image blur is fixed!
Apparently the May 3 updates I installed replaced my modified utils.js file:
C:\Users\loren\Documents\Psychoros\Gridsome Test\bulma\node_modules\gridsome\lib\graphql\nodes\utils.js
// 200408LA - changed DESC to ASC:
exports.createSortOptions = function ({ sort, sortBy, order }) {
  if (sort && sort.length) {
    return sort.map(({ by, order }) => [by, order === 'ASC'])
  } else if (sortBy) {
    return [[sortBy, order === 'ASC']]
  }

--> Requires Ctrl+C and new Develop!
BUT somehow the Develop process didn't notice until just now when I changed my Post.vue! The sort order stayed reversed through tons of Develop and Build sessions over four days! Somehow calling img instead of g-image in Post.vue triggered the system to notice the new utils.js file.
The problem has been around for awhile - the build I saved before the updates shows it, as does the original starter site which I have no control over. The js updates have apparently fixed the problem - now that they have been noticed!
Is there some trick required when you change certain files, to get them noticed? It looks like everyone now uses Yarn to install updates. This machine has lots of other Node projects, like Node-RED, and all of it has been installed with npm. I tried using Yarn once to update Gridsome, and it destroyed my project. I ended up deleting everything and recreating all my work from scratch. So I'm now afraid to try Yarn on this machine. Maybe things aren't being tested with npm any more? Does the build system use Yarn info to detect updates?
As for how the image fail happened...
Blurred:
<img alt="Cover image" src="data:image/svg+xml,%3csvg fill='none' viewBox='0 0 770 70' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'%3e%3cdefs%3e%3cfilter id='__svg-blur-0867bd701f8786bbbbce6cfed6e6dc12'%3e%3cfeGaussianBlur in='SourceGraphic' stdDeviation='1'/%3e%3c/filter%3e%3c/defs%3e%3cimage x='0' y='0' filter='url(%23__svg-blur-0867bd701f8786bbbbce6cfed6e6dc12)' width='770' height='70' xlink:href='data:image/jpeg%3bbase64%2c/9j/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAAGAEADASIAAhEBAxEB/8QAFwABAQEBAAAAAAAAAAAAAAAAAAUDBv/EACUQAAIBBAIBAwUAAAAAAAAAAAECAwAEESEFEoExQVETMkJh0f/EABcBAAMBAAAAAAAAAAAAAAAAAAIEBQP/xAAhEQACAgIBBAMAAAAAAAAAAAABAgADESEEEhMxQUJh0f/aAAwDAQACEQMRAD8Aq3b3LF1uJVWAsFMcIx2B3gk1b5fjDx1iswdW7EK6417Yx5pSoljEW1oPB8x5tVNZ8tyRFb8lPyMTRTwRFsIBgsAD6nY9a6bkrYWTiOMBlba9vb5/tKURc99V9bmnFYkFydkTmZrdJL4zyjMy5%2bCuBrWtVmOJmuLZoredYY3bP27XO9eaUqjgKuot0C%2b09zepRtuLv7WAfT5N1GfxXGf2axFneQOZkvXLuer9z3DeDSlAiKxJI3C5FK146cjH2f2f/9k=' /%3e%3c/svg%3e" width="770" data-src="/assets/static/histomap-770-70.8253719.9a963660098a26a3c5de51515be7f6c9.jpg" data-srcset="/assets/static/histomap-770-70.8253719.9a963660098a26a3c5de51515be7f6c9.jpg 770w" data-sizes="(max-width: 770px) 100vw, 770px" class="g-image g-image--lazy g-image--loading">
Working:
<img alt="Cover image" src="/assets/static/content/posts/images/histomap-770-70.jpg?width=770&fit=inside&blur=1&key=b2d844e" width="770" data-src="/assets/static/content/posts/images/histomap-770-70.jpg?width=770&fit=inside&blur=1&key=b2d844e" data-srcset="/assets/static/content/posts/images/histomap-770-70.jpg?width=770&fit=inside&blur=1&key=b2d844e 770w" data-sizes="(max-width: 770px) 100vw, 770px" class="g-image g-image--lazy g-image--loaded" srcset="/assets/static/content/posts/images/histomap-770-70.jpg?width=770&fit=inside&blur=1&key=b2d844e 770w" sizes="(max-width: 770px) 100vw, 770px">
Both have the same noscript section below this.

@LorenAmelang The problem here is that the post content is wrapped in a paragraph. That will make the generated HTML invalid if it contains any block elements (h1, ul etc.). Changing it to
 should help.

@hjvedvik  - Thank You! My site was already working properly in "Develop" mode when I posted last, apparently due to the js updates being noticed. But when I actually used "Build", it went back to blurry images in the dist version. Your suggestion to use
 instead of
 seems to have made both versions work! Wonderful birthday present - thanks again!

I'm having the same problem with no  is used in my code, I use v-html on some posts (from a starter kit where those worked) and in <svg /> tags.
Also, some v-if/v-else.
I'm not seeing any error on the dev version other than this on the production site which outputs:
app.cfad7772.js:7 Uncaught (in promise) DOMException: Failed to execute 'appendChild' on 'Node': This node type does not support this method.
    at Object.appendChild (http://localhost:5000/assets/js/app.cfad7772.js:7:40599)
    at d (http://localhost:5000/assets/js/app.cfad7772.js:7:53331)
    at l (http://localhost:5000/assets/js/app.cfad7772.js:7:53068)
    at h (http://localhost:5000/assets/js/app.cfad7772.js:7:53417)
    at A (http://localhost:5000/assets/js/app.cfad7772.js:7:56755)
    at A (http://localhost:5000/assets/js/app.cfad7772.js:7:56690)
    at A (http://localhost:5000/assets/js/app.cfad7772.js:7:56690)
    at A (http://localhost:5000/assets/js/app.cfad7772.js:7:56690)
    at A (http://localhost:5000/assets/js/app.cfad7772.js:7:56690)
    at a.__patch__ (http://localhost:5000/assets/js/app.cfad7772.js:7:57155)

@Berkmann18 - in my experience, this error has tended to show up when there's invalid HTML. In the most recent example on this issue, it was because block elements (like
,
) were being placed inside an inline element (a
 tag, for example)... Check out the comment above for an example on how to fix that.
If that isn't what's happening for you, maybe what you're doing inside the SVG is causing problems... try removing that and see what happens?

If that isn't what's happening for you, maybe what you're doing inside the SVG is causing problems... try removing that and see what happens?

That's possibly the case, I commented out all the SVGs with a v-html="..." and I still get Error: Input file contains unsupported image format on the terminal when trying to build the site.

Huh, haven't seen that one before. Are you using a weird image in a <g-image> tag somewhere?

@weaversam8 I do have a <g-image> but turning it from <g-image src="/images/favicon-32x32.png" class="logo"></g-image> to  doesn't change the error.

Can you try moving the image to src/assets/favicon-32x32.png, and then setting your <g-image> to have a src attribute equal to ='~/assets/favicon-32x32.png'... Not sure if it's an issue but the <g-image> tag imports your images via the webpack module loading system, so I usually provide a relative path into the src directory to make it work.

@weaversam8 I did that and still get the "Error: Input file contains unsupported image format".

changing from v-if to v-show reproduced what I had in dev in deployment but v-show breaks my app badly

Did you folks try using self-closing tags for img and/or g-image?

@hacknug Yup and that made no difference on the g-image tag I had.

wrapping page layouts with  solved my problem. explained here

Had the same problem.
Both <ClientOnly> and changing v-if to v-show worked for me.
The thing I've noticed is that when there is a tag with v-if, and this tag is not rendered during SSR, SSR puts a comment DOM node in its place. Then the client-side tries to appendChild to this comment node instead of appending it to the parent tag.
Having invalid/malformed HTML does not seem like a good excuse for this functionality not to work, as it is handled by the browser without a problem. So maybe this should be a bug in vue repository, and not gridsome?

It seems rather strange that this is necessary (ie. not using v-if as normal), but I did realize that in my case I was using the result of a window size query to hide/show elements, which makes sense that it would only be done on the client (using ClientOnly).

Is there a way to make the error message more helpful for this? I've run into this at the wrong time, unfortunately

I ended manually editing the app.XXXXX.js file in dist
From:
// ...
appendChild: function (t, e) {
        t.appendChild(e)
}

To:
// ...
appendChild: function (t, e) {
        if (t.nodeType === Node.TEXT_NODE) return;
        t.appendChild(e)
}

I know this issues is somewhat old, If anyone is still running into this issue I found a simple solution that works for my complex Gridsome/Shopify project thanks to this comment by Jason.
Basically if I have a v-if v-else statement that is dependent on my state I need to have it in a client-only wrapper, otherwise all state-dependent arguments that do not rely on v-if v-else should use v-show instead.
Here is an example (using client-only to wrap a v-if v-else):
<client-only>

        <wishlist-card :product="product" />

You have no items in your wishlist.

</client-only>

computed: {
  wishlist() {
    return this.$store.state?.wishlist || []
  }
},

And on my header.vue I only use v-show since there is no v-if v-else required:
<g-link to="/wishlist">
  <heart-icon />

      {{ wishTotal }}

</g-link>

computed: {
  wishTotal() {
    return this.$store.getters.wishlistTotalItems
  }
}

Hope this helps someone out! I have a really complex Gridsome site and was able to fix my Failed to execute 'appendChild' on 'Node' issue


redmine: 4.2.5 -> 4.2.6

Description of changes
WIP
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

WIP

is this ready?

Closing in favor of #190454 that I just opened, please reopen if that's an error.


(maint) Accept localization commits

Localized translations are committed using (L10n) as the summary prefix.
Accept them case-insensitively.

CLA signed by all contributors.


Documentation on data limits?

Hi,
The old oData feed had a limit of 5k CRM records (and could be bumped up). I've never run into record count limitations for the new API connector. Is there any documentation on record limits for the new API connector?
Thanks! Scott

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

ID: b0ff6d67-ecf6-567a-a05c-3b1d1724b35e
Version Independent ID: db544eb9-7eaf-1009-8ca9-31992b3dc180
Content: API Limits
Content Source: ce/developer/api-limits.md
Service: crm-online
GitHub Login: @MicroSri
Microsoft Alias: jdaly

Hello - Which API connector are you referring to in this case?  The OData and SOAP endpoints both return up to 5k records.  The connector for canvas apps and flow has a page size of 512.  In canvas apps it will delegate queries to the server for certain filter conditions, which enables it to page as necessary.  Flow also supports paging in the list records action.
The API limits defined on this page you are referring to apply to the SOAP and OData endpoints.  The similar throttles on the canvas apps/flow connector are defined here (1000 req/min): https://docs.microsoft.com/en-us/connectors/dynamicscrmonline/
Hope this helps!
-Brandon

@systamper Closing the issue as we haven't got a response from you on Brandon's question.

I am confused. In this article, there was previously an API limit of 60.000 API requests within the 5 minutes sliding interval described. Right now, there is no single word about the limit itself, just about the possible workarounds. So please tell us, WHAT IS CURRENTLY THE LIMIT!

@RobertRybaric The API Limits doc was recently updated and it mentions the maximum allowed API calls as 4000 requests in 5 minutes.
Related issue: https://github.com/MicrosoftDocs/dynamics-365-customer-engagement/issues/895

@susikka : Thanks, I have scanned the text and found this number only in an error message text, which I believe is not sufficient, since everybody reading the article is first of all interested in the number of calls. So this piece of information needs a more prominent position. Secondly, I am wondering why have you reduced the API limit from 60.000 to only 4.000 in 5 minutes, so basically to 1/15 th of the previous value. How would you suggest to implement complex and data-heavy integrations and even more data migrations with this low limit?

Looping in @brandonsimons who might be able to answer your question.

The guidance that we are providing today is to ensure that clients that are built against the CDS platform take into account that they may get throttled.  The specific throttles are currently not strictly defined as it can vary based on the load of the system.  By handling the request/response patterns as defined on this page you can ensure that your client(s) will work well with the platform to ensure reliability and consistency.

Hi @brandonsimons, Are you able to clarify how these limits are implemented and if it can be monitored? The original version of the article suggested we would get a limit of 60,000 requests. That limit is ample for most and didn't present us with any concern at the time the artical was published. However, this article and api limit has since been changed to 4,000 around the same time the limits seem to have been introduced. This is a substantial decrease from 60,000 and now presents us with an instant problem. As I am sure you can understand introducing this limit requires some planning and refactoring of code to ensure services ar not interupted in our production systems and I would have expected better communication.

The numbers within the error messages are not standard for every CDS database.  Our intention with the throttles was to deploy without causing rework upon the clients side.  If your business processes are not working as expected then please contact support.  Note that in some cases you may hit the thottle limit, but I would expect that to be handled with exponential back off similar to how you currently handle 5xx errors.
If you are specifically looking at how to best integrate with the platform then please follow the best practices in this page as that will enable the most efficient processing of your integrations.  Within the platform there are several items (Plugins, workflows, business rules, auditing) that can impact the throughput of your integrations, so it is key to validate your integration for functional and performance.  The throttles are put in place to ensure that the integrations that you are building up do not impact other users of the system.  This is important whether you own the integration as a customer, SI, partner or ISV.

This answer is simply not good enough. We are delivering on an enterprise platform, where we need to plan things ahead. When you introduced the first limitation of 60.000 februaru 2018 (ish) we had to redesign integrations to handle this limitation.
With the latest release of Dynamcis we are now over to the azure database. It is something I supposed would be more scalable. Suddenly without a major notification anywhere you are enforcing a limit of 4000!!
I hope the community stands up against this!

I got this response from MS support:

Burst Throttle (Existed before, but we have lowered limits): 6000 (I believe 4000 is for trial orgs) requests using the same user identity within a sliding 5 minute window.


Missing sweep?

Relai: https://github.com/breez/breez-sdk-relai/issues/37
Closing tx has more than 3500 confirmations and closing outputs haven't been swept.
Analysis here: https://github.com/breez/breez-sdk-relai/issues/37#issuecomment-2133587600

Tracking this in https://github.com/Blockstream/greenlight/issues/490


explicits && nowarn

I currently see this when I compile:
sbt:pstor-root> test:compile
[warn] There may be incompatibilities among your library dependencies; run 'evicted' to see detailed eviction warnings.
[info] Compiling 1 Scala source to /Users/david/workspace/pstor-compute/server/target/scala-2.13/classes ...
[info] Compiling 5 Scala sources to /Users/david/workspace/pstor-compute/index-builder/target/scala-2.13/classes ...
[error] 'nowarn' is not a valid choice for '-Wunused'
[error] 'nowarn' is not a valid choice for '-Wunused'

So here's a PR to remove nowarn for 2.13 and introduce explicits to address https://github.com/DavidGregory084/sbt-tpolecat/issues/18
Thanks for the plugin

-Wunused:nowarn was added in 2.13.2. using https://github.com/dwijnand/scala-runners,
% scala --scala-version 2.13.1 -Wunused:nowarn
'nowarn' is not a valid choice for '-Wunused'
...

% scala --scala-version 2.13.2 -Wunused:nowarn
Welcome to Scala 2.13.2 (OpenJDK 64-Bit Server VM, Java 1.8.0_252).
Type in expressions for evaluation. Or try :help.
scala 2.13.2>

Oh, I only see that because I'm not on the latest scala version, I'll fix my MR

I've removed the commit where I was removing playing with nowarn. I can confirm that using 2.13.2 works fine.

Mergeable or should I close?

Sorry @daddykotex I didn't spot this - looks good to me!

Thanks @daddykotex!


Filter occasionally hangs

Describe the bug
A call to .filter occasionally hangs (after the filter is complete, according to tqdm)
There is a trace produced
Exception ignored in: <function Dataset.__del__ at 0x7efb48130c10>
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/datasets/arrow_dataset.py", line 1366, in __del__
    if hasattr(self, "_indices"):
  File "/usr/lib/python3/dist-packages/composer/core/engine.py", line 123, in sigterm_handler
    sys.exit(128 + signal)
SystemExit: 143

but I'm not sure if the trace is actually from datasets, or from surrounding code that is trying to clean up after datasets gets stuck.
Unfortunately I can't reproduce this issue anywhere close to reliably. It happens infrequently when using num_procs > 1. Anecdotally I started seeing it when using larger datasets (~10M samples).
Steps to reproduce the bug
N/A see description
Expected behavior
map/filter calls always complete sucessfully
Environment info

datasets version: 2.14.6
Platform: Linux-5.4.0-137-generic-x86_64-with-glibc2.31
Python version: 3.10.13
Huggingface_hub version: 0.17.3
PyArrow version: 13.0.0
Pandas version: 2.1.2

It looks like I may not be the first to encounter this: https://github.com/huggingface/datasets/issues/3172

Adding some more information, it seems to occur more frequently with large (millions of samples) datasets.

More information. My code is structured as (1) load (2) map (3) filter (4) filter. It was always the second filter that failed. Combining the two filters into one seems to reliably work.

@lhoestq it'd be great if someone had a chance to look at this. I suspect it is impacting many users given the other issue that I linked.

Hi ! Sorry for the late response. Was it happening after the first or the second filter ?
It looks like an issue with the garbage collector (which makes it random). Maybe datasets created with filter are not always handled properly ? cc @mariosasko

It was after the second filter (and combining the two filters into one seemingly resolved it). I obviously haven't tried all settings to know that these details are causal, but it did work for me.

Thanks, that's good to know.
The stacktrace suggests an issue when del self._indices is called, which happens when a filtered dataset falls out of scope. The indices are a PyArrow table memory mapped from disk, so I'm not quite sure how calling del on it can cause this issue. We do del self._indices to make sure the file on disk is not used anymore by the current process and avoid e.g. permission errors.
Hopefully we can find a way to reproduce this error, otherwise it will be quite hard to understand what happened

Yeah, I have a reliable repro, but it is not even close minimal and uses a dataset I can't share. Perhaps you could try getting close to my setting.
(1) make a large (~20GB) jsonl with prompt/response pairs
(2) load it on a linux machine (dataset = load_dataset(...))
(3) map a tokenizer to it, with multiprocessing (tokenized_dataset = dataset.map(...))
(4) filter it once based on something, with multiprocessing (filtered_1 = tokenized_dataset.filter(...))
(5) filter it again based on something, with multiprocessing (filtered_2 = filtered_1.filter(...))
I included the variable names just in case it is relevant that I was creating new datasets each time, not overwriting the same variable.

@lhoestq I have another version of the repro that seems fairly reliably. I have lots of jsonl files, and I iteratively load each one with load_dataset('json', data_files='path/to/my/file.jsonl', streaming=False, split='train') and then dataset.map(..., num_proc=<int>). This iteration hangs in a random place each time. So seems like there is a bug that hits with some frequency.

I am also having similar issue to #3172 when trying to tokenize the data. My dataset contains 10M samples. Is there anything that could be done without having to split up the processing into multiple datasets?


Add .circleci/config.yml

This PR adds support to CircleCI

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Overlay different from ArcGIS pro

The results of the overlay node have none values which different from ArcGIS pro.
@UrbanGISer

Solved


Can't seem to import manimlib or cairo on macOS mojave.

Don't know if it's an import error or something else.
1. Steps to reproduce the issue (e.g. the command you ran)
python3 extract_scene.py example_scenes.py SquareToCircle -pl
Ran this in the folder and venv. Get the same error.
2. The unexpected behavior that occurred (e.g. error messages or screenshots)
Traceback (most recent call last):
  File "extract_scene.py", line 9, in <module>
    from manimlib.scene.scene import Scene
  File "/Users/username/Code/ManimInstall/manim_9jul/manimlib/__init__.py", line 4, in <module>
    import manimlib.extract_scene
  File "/Users/username/Code/ManimInstall/manim_9jul/manimlib/extract_scene.py", line 9, in <module>
    from manimlib.scene.scene import Scene
  File "/Users/username/Code/ManimInstall/manim_9jul/manimlib/scene/scene.py", line 11, in <module>
    from manimlib.camera.camera import Camera
  File "/Users/username/Code/ManimInstall/manim_9jul/manimlib/camera/camera.py", line 9, in <module>
    import cairo
  File "/Users/username/Code/ManimInstall/manim_9jul/venv/lib/python3.7/site-packages/cairo/__init__.py", line 1, in <module>
    from ._cairo import *  # noqa: F401,F403
ImportError: dlopen(/Users/username/Code/ManimInstall/manim_9jul/venv/lib/python3.7/site-packages/cairo/_cairo.cpython-37m-darwin.so, 2): Symbol not found: _cairo_font_options_get_variations
  Referenced from: /Users/username/Code/ManimInstall/manim_9jul/venv/lib/python3.7/site-packages/cairo/_cairo.cpython-37m-darwin.so
  Expected in: flat namespace
 in /Users/username/Code/ManimInstall/manim_9jul/venv/lib/python3.7/site-packages/cairo/_cairo.cpython-37m-darwin.so

3. The environment (e.g. operating system and version of manim)
macOS mojave 10.14.5
P.S. This is my first support ticket ever here, so feedback is appreciated.

manim has been module-fied so do python3 -m manim example_scenes.py SquareToCircle -pl
What installation guide did you follow?

@Kolloom
I followed Theorem of Beethoven's video install guide and this tutorial.
After running python3 -m manim example_scenes.py SquareToCircle -pl, I get the following error:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/jagraj/Code/ManimInstall/manim_9jul/manim.py", line 2, in <module>
    import manimlib
  File "/Users/jagraj/Code/ManimInstall/manim_9jul/manimlib/__init__.py", line 4, in <module>
    import manimlib.extract_scene
  File "/Users/jagraj/Code/ManimInstall/manim_9jul/manimlib/extract_scene.py", line 9, in <module>
    from manimlib.scene.scene import Scene
  File "/Users/jagraj/Code/ManimInstall/manim_9jul/manimlib/scene/scene.py", line 11, in <module>
    from manimlib.camera.camera import Camera
  File "/Users/jagraj/Code/ManimInstall/manim_9jul/manimlib/camera/camera.py", line 9, in <module>
    import cairo
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/cairo/__init__.py", line 1, in <module>
    from ._cairo import *  # noqa: F401,F403
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/cairo/_cairo.cpython-37m-darwin.so, 2): Symbol not found: _cairo_font_options_get_variations
  Referenced from: /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/cairo/_cairo.cpython-37m-darwin.so
  Expected in: flat namespace
 in /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/cairo/_cairo.cpython-37m-darwin.so

I had the same ImportError: dlopen .... Symbol not found and tried running a virtual environment with a downgraded python (3.6 instead of 3.7), then pip installing requirements, pip installing pycairo, and brew installing ffmpeg, and ended up working.
This might not directly be a solution for you, but here's what I used:
conda create -n manim3.6 python=3.6
conda activate manim3.6
pip install -r requirements.txt
pip install pycairo
brew install ffmpeg

@vbartle After running the commands you listed, I get the exact error in response to Kolloom. I'm still seeing Python 3.7 in the /Library/Frameworks folder but when I run python -V, it shows 3.6.8. Is that how it's supposed to be?

Did all of those commands successfully finish?
If you're still seeing import attempts on 3.7, 3.6 isn't being used -- you could try using python instead of python3 in python3 -m manim example_scenes.py SquareToCircle -pl but there are several reasons 3.6 might still not be used.

I see that blog post, which was written September last year, referenced a couple times here. The installation guide is no longer applicable on the current code base.
manim uses subprocess and does not make use of those python wrappers.
pip3 install sox
pip3 install ffmpeg
pip3 install latex

Media output now defaults to manim/videos so modification at step 8 is not necessary.
The command to run example scene is outdated. (though it will probably work still)
I am not sure what step10 is modifying.
tex_template.tex shoud work as is from the current repo.

what?

https://github.com/3b1b/manim/issues/286
https://github.com/3b1b/manim/issues/420
https://github.com/3b1b/manim/issues/430
https://github.com/3b1b/manim/issues/512

@Kolloom
Thanks for the links.
#286: I tried uninstalling and reinstalling Python 3.7. Still get the same errors.
#420: Installed pycairo using the commands, no luck.
I uninstalled and reinstalled the contents in requirements.txt. Downgraded numpy to 1.15.0 and scipy to 1.1.0 (the versions required).
After all that, I tried python3 -m manim example_scenes.py SquareToCircle -pl to get a slightly shorter version of the same error:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/jagraj/Desktop/manim/manim.py", line 2, in <module>
    import manimlib
  File "/Users/jagraj/Desktop/manim/manimlib/__init__.py", line 4, in <module>
    import manimlib.extract_scene
  File "/Users/jagraj/Desktop/manim/manimlib/extract_scene.py", line 9, in <module>
    from manimlib.scene.scene import Scene
  File "/Users/jagraj/Desktop/manim/manimlib/scene/scene.py", line 11, in <module>
    from manimlib.camera.camera import Camera
  File "/Users/jagraj/Desktop/manim/manimlib/camera/camera.py", line 9, in <module>
    import cairo
ModuleNotFoundError: No module named 'cairo'

I'm in the process of removing Anaconda to see if that helps.

Uninstalling Anaconda worked! Thanks @Kolloom @vbartle


depth_aligned_to_color crashes when debugging

Required Info

Camera Model
R200

Firmware Version
<IP_ADDRESS>

Operating System & Version
Windows 10

Kernel Version (Linux Only)

Build System
VS2014

When I try to get frame data using the depth_aligned_to_color stream while debugging, the program crashes here with the message Debug Assertion Failed! Expression: Invalid Comparator . This affects cpp-alignimages example as well when built with debugging enabled.

Any progress on fixing it?

I found that changing the lambda from lines 556 to 561 fixed my issue:
[out_z, z_pixels](int z_pixel_index, int other_pixel_index) {
    const unsigned short a = out_z[other_pixel_index];
    const unsigned short b = z_pixels[z_pixel_index];
    out_z[other_pixel_index] = a ? std::min(a,b) : b;
})

Not sure why std::min couldn't generate correct implementation, but this seemed to resolve my problems.

There is type miss match between "other_pixel_index" and "z_pixel_index", "other_pixel_index" should be of type const uint16_t * ,unlike "z_pixel_index" ,for std::min() to compare the objects.I hope following correction in the source code will fix this bug.


Translucent toolbar

Add translucent toolbar in movie and serie details activity.

This will not be rolled forward due to migrating to the new Material Design


Add mention of "make checks payable to" organization name on Accounts page

We should make it really easy for diners to pay their bill. This could be as easy as including the words "Make checks payable to XXX" where XXX is:

Touchstone Cohousing
Common Kitchen
Great Oak Coho Association (Meals in memo)

From Andrew Kraftson (5/8/2016)
If you are receiving this message, it is because your meals check cannot be cashed as written. Unfortunately, there has been some confusion about the name of the account.
Checks should be written to "Touchstone Cohousing" NOT "Touchstone" and NOT "Touchstone Meals". (it is confusing since if you mail the check, you mail it to Touchstone Meals - but the check is written to Touchstone Cohousing)
The bank has started rejecting these checks and is charging us a $20/denied check fee. We incurred $60 of fees last time I deposited checks - so I am watching like a hawk, now.
Consequently, it means inconvenience to you. Please re-write and re-submit your most recent meals check (or can wait for the next statement, if you choose).
I will hang on to the unusable checks, for now, and will void/tear up upon receipt of the new checks.
Contact me with questions/comments/concerns.
Originally created by Willie Northway at 2016-05-14 03:48, migrated from redmine-#4533

Priority changed from 3 to 2

By Tom Smyth at 2016-09-28 04:27

Version changed from 2.4 to 2.5

By Tom Smyth at 2016-10-24 16:30

Version set to 2.4

By Tom Smyth at 2016-10-23 03:15

Status changed from New to Closed

By Tom Smyth at 2016-10-26 04:19


Proposal: Instead of using int, double and BigDecimal, the Number abstract class can be used

Checklist

[X] I made sure that there are no existing issues - open or closed - which I could contribute my information to.
[X] I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
[X] This issue contains only one feature request/enhancement.

Description
Advantages are;

Instead of using int, double and BigDecimal, you can create shorter classes using the Number abstract class.
Sometimes there may be null or Double.NaN values in the data. https://www.chartjs.org/docs/latest/general/data-structures.html#object

Therefore, my suggestion is to create an interface NumberDataset.java file instead of BigDecimalDataset.java file and remove int, double, BigDecimal and use Number abstract class instead.
As an example, the current ScatterDataPoint file;
public class ScatterDataPoint extends XYDataPointBase<ScatterDataPoint>
{
	public ScatterDataPoint()
	{
	}

	public ScatterDataPoint(final int x, final int y)
	{
		super(x, y);
	}

	public ScatterDataPoint(final double x, final double y)
	{
		super(x, y);
	}

	public ScatterDataPoint(final BigDecimal x, final BigDecimal y)
	{
		super(x, y);
	}
}

and  after the change
public class ScatterDataPoint extends XYDataPointBase<ScatterDataPoint>
{
	public ScatterDataPoint()
	{
	}

	public ScatterDataPoint(final Number x, final Number y)
	{
		super(x, y);
	}

}

and proposed NumberDataset.java
public interface NumberDataset<S extends Dataset<?, Number>>
{
	S self();

	default S setData(final Number... data)
	{
		this.self().clearData();
		if(data != null)
		{
			Arrays.stream(data).forEach(this::addData);
		}
		return this.self();
	}

	/**
	 * Add the data point to this {@code Dataset}
	 *
	 * @see Dataset#setData(Collection)
	 */
	default S addData(final Number data)
	{
		this.self().addData(data);
		return this.self();
	}
}

Additional information
No response

In a project I'm working on, the following errors are thrown because null or Double.NaN values are not accepted by the current BigDecimalDataset.
For the Double.NaN value;

Caused by: java.lang.NumberFormatException: Character N is neither a decimal digit number, decimal point, nor "e" notation exponential mark.
at java.base/java.math.BigDecimal.(BigDecimal.java:586)
at java.base/java.math.BigDecimal.(BigDecimal.java:471)
at java.base/java.math.BigDecimal.(BigDecimal.java:900)
at java.base/java.math.BigDecimal.valueOf(BigDecimal.java:1368)
at software.xdev.chartjs.model.dataset.BigDecimalDataset.addData(BigDecimalDataset.java:60)

The graphical output I expected;
label: [2026-01-01, 2026-11-26, 2026-11-27, 2027-01-01]
dataset1: [2.8, NaN, NaN, 3.8]
dataset2: [0.0, 0.0, 0.0, 0.1]

Since I am unable to set null or Double.NaN value, I cannot have the chart that I expected.

Thank you for the issue,
This is from the original implementation and was never changed.
But I have to agree that this makes a lot of sense. I will do a quick PR


Explicitly indicate use of RFC3339 for DateTime attributes

What type of PR is this?

documentation

What this PR does / why we need it:
Explicitly indicate use of RFC3339 for DateTime attributes
Which issue(s) this PR fixes:
Fixes #14
Special notes for reviewers:
Fix the issue with PR 19 from @bigludo7
Changelog input
Explicitly indicate use of RFC3339 for DateTime attributes
fix #14

Additional documentation
This section can be blank.
docs

Agreement is to merge


Discoverd deployment fixes

These are some preliminary fixes to issues that can occur during discoverd deployments.
The main one is the addition of the deployment ID to the discoverd metadata as it fixes stale reads of service meta.

LGTM

LGTM


Feature Request: Timed tx Broadcast

The Problem - Timing attacks
When a user is moving bitcoin from one wallet to another in a privacy preserving way (one utxo at a time), they are still exposed to timing attacks. For instance, they send all the tx at the same time into the mempool in the same way (via the same node or tx publisher). This can allow chain surveillance to associate a heuristic on these transactions.
Potential Solution
One potential mitigation for this would be the option to queue up transactions and either have a random or a user set publishing schedule into the mempool. You may have 10 UTXOs to move and you decide you will publish them into the mempool at a random interval of between 4 and 8 hours each time.
Issues with this Approach
Fee rate spikes would obviously cause issues with this not only for the delayed publication of the tx not getting confirmed but also if the user uses the same fee rate for all the tx and then uses delayed publication that would allow another method for heuristic matching.
Mitigations
To mitigate this you may have to sign multiple tx with different fee rates and publish the one with the fee rate that best matches the mempool fee rate at the time of publish or withholds the publish of the tx if the fee rate is not sufficiently high.
Alternative Solutions
I have not given the above excessive consideration so if there are better ways to automatically mitigate timing attacks on batch spending, I'm open to suggestions.

Duplicate of #1421.


"msg": "Cannot write to ControlPath /home/ansible/.ansi

please tell how to fix this error!!

create user adduser username
enable passwordbaseauth  /etc/ssh/sshd_config
make as sudo user visudo
restart ssh   systemctl restart sshd
install python in node

if you done close this issue with solutions


incr/decr doesn't check for -ve deltas, causing silent lossage

Using pylibmc against memcached 1.4.5:
cache.set('wibble", 0)
>> 0
cache.decr('wibble', 1)
>> 0
cache.incr('wibble', -1)
>><PHONE_NUMBER>L
cache.incr('wibble', 1)
>><PHONE_NUMBER>L

This causes head-scratching lossage since there's no warnings or errors. The memcached protocol specifies that the Memcached will generate an error if a negative integer is passed using the ascii protocol - the problem is in pylibmc's conversion from Python to C.
The memcache command trace is:
<28 set :1:wibble 2 100000 1
> NOT FOUND :1:wibble
>28 STORED
<28 decr :1:wibble 1
> FOUND KEY :1:wibble
>28 0
<28 incr :1:wibble<PHONE_NUMBER>
> FOUND KEY :1:wibble
>28<PHONE_NUMBER>

Note that the -1 has been cast to an unsigned number, with resultant weird results.
The correct behaviour should be to error if passed a negative number. If it's felt that's an unexpected API change, then the incr()/decr() functions should detect a -ve number and call the inverse function with a +ve integer.

Four years later I realize 60fa2d90 was sufficient to fix #74 as well. Removing the so-called signedness check -- for how else would the two differ, unless the signed version is negative?


Add documentation on path being directory

Document behaviour in case the input path is a directory.
resolves #231

Thanks!


ROOMID

Type of issue
Typo
Description
[Enter feedback here]
Page URL
https://learn.microsoft.com/en-us/dotnet/api/azure.communication.rooms.roomsclient.addorupdateparticipants?view=azure-dotnet
Content source URL
https://github.com/Azure/azure-docs-sdk-dotnet/blob/master/xml/Azure.Communication.Rooms/RoomsClient.xml
Document Version Independent Id
176d1f70-e9d6-bdd4-0c36-1b3c9b9d8d46
Article author
@azure-sdk
Metadata

ID: eaa04f65-d618-75f4-3dd2-327fb225911d
Service: azure

Not enough detail to understand what is being reported as a typo, but using the RoomId from the title as a context clue, I've confirmed that the parameters in code match the docs.   Closing.


Use env options in runScript

to set environment variables in script runtime

To support pre-stop hook
#164262378

Co-authored-by: Belinda Liu<EMAIL_ADDRESS>Co-authored-by: Charles Hansen<EMAIL_ADDRESS>Note that there a lots of files changing because the linter ran.
The important parts are in run_scripts.go, generic_script.go and their tests. The concrete_job_script_provider.go also had to change a little because of the interface change.
There are currently no integration tests since that would require some new architecture that is only available for the windows tests.

Yeah looks like the integration tests are a bit messy. I think we'll take some time trying to untangle them for next PRs :)