enableCFoutputOnly=true wasn't being unset

enableCFoutputOnly=true was resulting in post-CFTag output being suppressed unless content was within cfoutput/writeoutput.

I'm so used to requiring explicit output, that I didn't notice. Your solution is fine, but we probably don't even need enableCFoutputOnly here to begin with. What do you think?

I've found that all ACF CFTags tend to leak whitespace and I always use enableCFoutputOnly as a result.
If you want to compare, you can omit it, add cf_dump to a single vanilla page to render a complex-ish object, use cfsavecontent and compare the length.
In my initial, simple comparison test:
enableCFoutputOnly=true = 17,675
no enableCFoutputOnly =  17,782 (+107 whitespace characters)

4f5cd988691051e2e3570226ba4173601899287d

My belief and best practice is: Whitespace should be suppressed within the CFTag:

without requiring any global application settings
requiring the developer to wrap usage in enableCFoutputOnly to manually suppress generated whitespace

There's no significant performance overhead from the changes I made, are there?  (We've used enableCFoutputOnly in every one of our CFTags going back over 20 years.)
Removing "all whitespaces" from the output buffer could be problematic as some devices (or APIs) have undefined hard limits regarding maximum line lengths. (ie, SendGrid only allows a maximum of 998 characters per line based on RFC 5322, section 2.1.1... so line lengths beyond this limit could cause problems.)
I performed a quick test and removing enableCFoutputOnly altogether increases unwanted whitespace.  For example, 100 extra whitespace characters are injected by the tag when dumping a 4 record, 4 column query object.  These extra whitespace characters count toward the output buffer and large queries could cause it to automatically flush in some cases.

I appreciate your concern, but if you are worried about the size of the output buffer, you probably shouldn't use this dump tag. Compared to native cfdump, this tag is sluggish in every way (except object inspection, where it outperforms ACF's dump for completely different reasons). Here is a benchmark (140 KB json, ~3000 kvp):

Stat
ACF
Lucee
cf_dump

Lines
24,942
159
99,643

Characters
840,229
664,537
2,586,616

Whitespaces
184,643
24,472
708,188

Nodes
14,109
31,313
34,511

DOM Parsing
45 ms
50 ms
102 ms

Draw Time
228 ms
428 ms
858 ms

I do not aim for the fastest or smallest dump tag, but one with the insight I require when doing diagnosis/debugging. The whitespace handling really doesn't matter in the big picture. That being said, I will consider optimizing these parts at some point.

I only care about unnecessary output that can be easily & permanently suppressed.  (Unnecessary whitespace was the first thing we noticed and disliked when Adobe released their built-in CFUI tags back in CF9... well, that and how they blindly injected JS/CSS in the header and failed to properly maintain the 3rd party dependencies.)
How did you generate the benchmark metrics? Did "whitespaces" constitute unnecessary whitespace? (Some whitespace is definitely required.)
I personally enjoy using your CFTag when experimenting with small data sets because it displays data types (like Lucee) when using ACF and helps expose occasional ACF casting issues.
I'd like to similarly compare Lucee & ACF with my internal CF_DumpLite CFTag.  While it's blazingly fast & much smaller compared to ACF, it lacks support for non-string/numeric/array/struct objects and has some dependencies on our global application framework. I made sure that it was responsive & includes support for ordered structs, redacted keys, CSS word-break-ing, CSP nonce, PCI compliance & optionally inlining CSS (using jsoup).  I still need to update the tag to work with Lucee. (I've been using ACF since v3 and am endeavoring to write cross-compatible cfml.)

I only care about unnecessary output that can be easily & permanently suppressed.

The real problem is using output="true" in the cffunction that is invoked recursively to not have to explicitly add to a StringBuilder (and return the string). This unfortunately means that every whitespace for indentation and line spacing is added automatically. enableCFoutputOnly doesn't help here. I updated the table(s) in my previous post with results for the current tag and your PR. Stripping the final output (either via whitespace management or manual replace) has the most impact, albeit still irrelevant.

How did you generate the benchmark metrics?

Lines = number of lines in output
Characters = total character count in output
Whitespaces = total character count in output filtered by \s
Nodes = document.querySelectorAll('*').length
DOM Parsing = "Parse HTML" metric in Chrome profiler
Draw Time = "Rendering" metric in Chrome profiler
<cfset x = deserializeJSON(...)>
<cf_dump var="#x#">

dummy.txt (GitHub doesn't allow the .json extension, lol)

I agree that whitespaces in CFM have always been annoying, especially in the era before Flexbox, when inline-block trickery was a thing - or that pesky arrow bracket because a coworker didn't use outputOnly and put >> somewhere. Yet I don't think that enableCFoutputOnly is a meaningful solution to the problem in this tag's case. I'd rather not touch cfsetting at all. Let the developer decide how he deals with whitespaces. I personally will continue doing the minifying (for browser output) as I have never had any trouble with it.

Regarding whitespace, I only tallied the difference between the regular output and trimmed output and ignored all internal spacing.  (It looks like Lucee's tag is rather conservative whereas Adobe is the greatest offender.)
The Dumplite CFTag that I wrote is a bare-bones CFM tag that leverages a separate CFC.  The CFC builds the content using an array (vs using StringBuilder; similar approach) to reduce odds of unintentionally filling the output buffer.  Here are some non-browser-performance comparisons. (My PC is a couple of generations older and performance would be different anyway.)
Here's my DumpLite stats using CFTag+CFC combo (using an array to create the output).

dumplite stat
dumplite

CFTime
130ms

Lines
3

Characters
392,297

Whitespace
23,915

Nodes
14,710

By comparison, ACF took 3,000-8,000ms on average and CF_Dump was consistently around 200ms.
MINIFICATION WARNING: I attempted to use Chrome's "view source" (CTRL+U) and kept running into performance issues and getting messages "This page isn't responding". There aren't any issues with ACF's CFDump.  I can quickly view the beginning of the source for my DumpLite before it displays the message, but nothing is displayed when using CF_Dump before getting the message.  I believe that this may be due to line length.
I didn't realize that this issue existed. To avoid, I updated our DumpLite function to inject chr(10) after each </table> tag. After reloading & viewing source, I confirmed that "long lines" were no longer causing any browser issues when viewing source.
It increased the output stats a bit, while performance remained consistent.

dumplite stat
dumplite

Lines
1,255

Characters
392,898

Whitespace
24,516

I only use CF_Dump during development and never on production, so I'm the only user/developer every impacted.
BTW, thanks for conversing with me!


Agent Removal Testing - Discovered and Inspection Ready fields blank out periodically. Reappear on refresh after clicking on 'Appliance Instances' and disappear again after sometime

Description
Expected Behavior
The values for Discovered and Inspection Ready fields should be accurately populated and stay without a refresh
NOTE - The second screen shot displaying blank fields for Discovered, Inspection ready and Last status is after an upgrade from 2.6-2.64. On the Freshly deployed OSC with 2.6-63 do not see this issue.
Actual Behavior
Steps to Reproduce
For ISM DAI, Discovered and Inspection Ready are showing blank on ‘Appliance Instances’ page whereas showing ‘true’ on ‘Appliance Instance Status’.
This should have been N/A, or at least consistent if we are using hard-coded (true) values for Discovered and Inspection-Ready.
A refresh of the page displays 'true', true for Discovered and Inspection Ready but blanks out after sometime.
EXPECTED RESULT - The values for Discovered and Inspection Ready fields should be accurately populated and stay without a refresh.
The screen shot should suffice for this bug.
NOTE - The second screen shot displaying blank fields for Discovered, Inspection ready and Last status is after an upgrade from 2.6-2.64. On the Freshly deployed OSC with 2.6-63 do not see this issue.

Tested with Build 116.
DE3476 - not reproducible and I do see Discovered and Inspection ready fields as N/A and not blanked out any more. I do not even see them blanking out periodically. Emanoel mentioned that he has not done anything to fix the bug but it can be closed as Non-Repro. (screen shot attached with Discovered and Inspection ready showing as N/A and not blank)
Part of Bug DE3494.
The bug was resolved previously but re-appears in Build 0.6.0.
Hence opening a new one for tracking.
Additional Information
DE4169 in Rally
Environment

OSC Version/Build: OSC 2.6-63, 0.6.0 - (Build:4-gc4547e9, 2017-05-26T18:35:23Z)
Cloud Provider Info:
Plugin Info:
Other:

Status

[ ] Reproduced
[ ] In Progress
[ ] Validated     =>    Verified in Version/Build:

Please try and reproduce the problem in 1.0.0.

Tested with Version: 1.0.0-SNAPSHOT (Build:78-gc0de361, 2017-09-25T22:59:09Z)
The fields 'Discovered' and 'Inspection Ready' are not blanked out any more. However, they show 'false' when 'Appliance Instance Status' Page shows then as 'true'. The fields will become consistent once we hit 'refresh'. This should be done automatically without a manual 'refresh'.

Workaround - Refresh the Appliance Instances page and then fields get consistent

Information provided - we can remove the triage label
Also severity is changed to low

Since it's minor and there is a bypass change severity to low


win: Add compatibility information in manifest file

Fixes #2586.

This might change all kinds of behavior in the app (i.e. opts you out of a bunch of crash mitigation, disables Version Lie, means you don't get shimmed), we should still do it but give people a heads-up

we should still do it but give people a heads-up

:+1:


Bigtable: add sync methods

Fixes #3635
Sync methods added in BigtableDataClient

Build issues should be fixed now.

Spanner and Logging IT test failures unrelated.


Push straight to master

Hey! Loving this plugin, but do you think it would be possible to configure (globally) that the app should just push to master without going through a PR? I don't want to get the notifications from the PRs, they're not interesting to me.
I suppose an option to turn them on per repo makes sense if people want

I'm currently using PRs to get the commit reference from upstream before resetting the fork's master to match upstream master's commit hash. I'm not sure if I'll be able to reset without the PR step. Let me know if you have any suggestions.
For now, I guess you can create email filters to drop emails with "[pull]" in the title or "Create by Pull" in the body.


Add argument to disable Submit anyway button in the questionnaire confirmation popup

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #2444
Description
Add bundle argument EXTRA_SHOW_SUBMIT_ANYWAY_BUTTON in QuestionnaireFragment.kt and QuestionnaireValidationErrorMessageDialogFragment.kt to optionally disable submit anyway if it's not needed. Default value for the same is true.
Defines a setter in QuestionnaireFragment.kt so that it's value can be easily set while creating an instance of QuestionnaireFragment. Add Relevant test methods for the same
Alternative(s) considered
N/A
Type
Bug fix
Screenshots (if applicable)
N/A
Checklist

[x] I have read and acknowledged the Code of conduct.
[x] I have read the Contributing page.
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
[x] I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

@jingtang10 I've incorporated review feedback here. Can you please take a look?


develop benchmark for commercial breaks and alternative cuts

True commercial breaks and alternative cuts are probably not necessary; we can likely simulate them with synthetic data. Still, real examples couldn't hurt.

I have a bunch of true-break videos, actually a season with many episodes, of which the black screen transitions are inconsistent with the subs, wonder how I can help?

@Sec-ant Apologies for the very late reply. Eventually I'll have some logic that allows users to package the extracted voice segments and subtitles together so that failure cases can be submitted without having to share the whole video (and any implications that may have wrt copyright). Something like:
subsync vid.mp4 -i subs.srt --make-test-case test.zip
I will reply to this thread once I (finally) have this implemented.


Profile management

Added ProfileDetails Controller,IProfileRepository & ProfileRepository, Changed  profile-dashboard.component.ts, profile-dashboard.html,profile-edit.component.ts,profile-edit.html,Injected service in startup.cs

SonarQube analysis reported 11 issues

 9 major
 2 minor

Watch the comments in this conversation to review them.


Create report form integrated with maps page

@kongsally make sure to make all the tests pass

Can we improve the styling of this a bit? https://www.dropbox.com/s/t1hty489y31ul4l/Screenshot 2016-01-21 14.37.18.png?dl=0

There is a box within a box
The text box for 'Additional Notes' goes beyond the box
Use current location is a blue "action" button while submit is an ordinary button. Should this be reversed?

Actually, I wouldn't delete poll244.csv since we need it in git to get it up to heroku

@sandlerben
Edited Incident Report's styling for the create report button and text area,
Edited the import statement for views.py,
Added back kwargs (not sure why I deleted it first... Maybe I had issues with the outdated forms model I was using)


Update save_and_load.py

"Line 73: to_return = {k.replace(f".{adapter_name}", ""): v for k, v in to_return.items()}" should inside or place before the condition "Line 68: if model.modules_to_save is not None:", or it will let Line 68 disfunction, and can't use it to update Lora model.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Validate API token is obtained using the expected methods

I did run the tests locally where I bumped the default Humio container image tag to 1.17.0, which worked just fine, but I'm guessing we want to stick with our stable releases as the default version.
Also, not sure what to do about the constants at this point. Right now the helper image only contains one package, which I can't import, so we'd need to split that up if we want to keep the constants in a separate package. If we split such things out, we may also want to refactor the other couple of things we have layout around which also has a copy in the main project as well as the helper image project.

One thing that comes to mind is that we could have some generator code where we write out the constants, or any other code that is shared between the main project and the helper to both modules without requiring imports/dependencies.
That doesn't necessarily need to be done as part of this PR.


Biological Consumers can select Cell Census v1 and v2 as basis data for Gene Expression

I'm going to close this issue for 2 reasons

i believe V2 is not going to be necessary until the end of the year and we are focusing only on H1 right now
Once we complete the sister ticket to allow v1, v2 should actually implicitly be allowed. So really its preferrable just to allow versioning in general, which is what the aim for the other epic will address


intellisense for fluent validator in visual studio 2015 is not working.Please help me out

That's not really a fluentvalidation issue, but will be more related to your setup of VS. There's not much I can do to help with that, other than suggest you check all the intellisense settings in VS are enabled and that you've repaired your installation. Sorry I can't really help further.

Thanks you for the quick response.Yep there was some issue with Visual Studio.


remove warnings, add logging, fix string observe

Signed-off-by: Bert Kleewein<EMAIL_ADDRESS>

Looks good to me.
Thanks


0219 - Contains Duplicate II

Description of the Problem
Given an array of integers and an integer k, find out whether there are two distinct indices i and j in the array such that nums[i] = nums[j] and the absolute difference between i and j is at most k.
Example 1:
Input: nums = [1,2,3,1], k = 3
Output: true

Example 2:
Input: nums = [1,0,1,1], k = 1
Output: true

Example 3:
Input: nums = [1,2,3,1,2,3], k = 2
Output: false

Code
class Solution:
    def containsNearbyDuplicate(self, nums: List[int], k: int) -> bool:

Link To The LeetCode Problem
LeetCode

I'd like to work on this

@vJechsmayr I would like to work on this issue. Please assign me.

@vJechsmayr  I would like to work on this issue. I have worked on python and am currently learning advanced algorithms too.


PROV: Use rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx() in RSA-OAEP

Fixes #11904

This is extracted from #11948, as that's pending on others, and this fix really doesn't need to wait on those.

This pull request is ready to merge

Merged
f7f53d7d61bba235b8babf4cf580114d74183e3e PROV: Use rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx() in RSA-OAEP


Add plural i10n to datetime

Right now, it simply appends an 's', which does not work in most languages.
Stundes sounds very wrong in german :D

Totally agree!

Absolute. Everything for the Stundes!


Serial: Bluetooth: Increase Throughput by tracking run-time ATT MTU Size

Is your enhancement proposal related to a problem? Please describe.
The UART over Bluetooth LE (NUS) currently fragments TX data in chunks of 20-bytes per Bluetooth notification. This is done since the maximum payload we can put through a single packet, assuming minimum ATT MTU size (MTU - 3). This, however, represents a throughput bottleneck and limits its usability (Simple but limited).
Describe the solution you'd like
Split data in chunks of the maximum possible payload-per-packet (min_current_mtu - 3), where the min_current_mtu is the minimum MTU of all the peers currently connected.
e.g:
		chunk_size = get_max_payload_packet_size();
		len = ring_buf_get_claim(dev_data->uart.tx_ringbuf, &data, chunk_size);
		if (len > 0) {
			err = bt_nus_inst_send(NULL, dev_data->bt.inst, data, len);
			if (err) {
				LOG_ERR("Failed to send data over BT: %d", err);
			}
		}

Describe alternatives you've considered
No additional alternatives.
Additional context
To achieve so, uart_bt.c needs to have run-time awareness of all connected peers and their MTU size at all times.

@jori-nordic @alwa-nordic @jhedberg LMK if you have any inputs on this!

@ubieda sounds like a good potential improvement to me


SQLite replacement ORM library

Issue
SQLite database is slow, hard to manage, hard to test and terse with lot joins and requires incredible amount of boilerplate code to create simple use cases
What should be done?
Replace SQlite with any of the modern ORM wrapper or for better efficacy, a different database solution overall, which provides:

reactive notifications about data changes as an event application should be as reactive as possible
easy to test as we would want to mock the database easily to create unit tests. Our goal should be to abstract the data layer behind repository pattern so that it is easily testable
easy to maintain as the open event API keeps changing, so we should be able to just change our object models and not worry about the app breaking. So either automatic migrations or a solution where it is easy to migrate data should be preferred
requires less maintenance as only maintaining the production is hard enough and we won't want to maintain the boilerplate as well
requires less time to implement

Strategy
Discuss about your preferences and their pros and cons and when it is decided, one person chooses to create a branch on his/her fork and other developers collaborate with him/her and complete the implementation as soon as possible.

My personal recommendations are -

Realm:
Pros:

Very stable
Battle tested and proven
Easy to implement
Fast
Easy one to many and many to many mapping
Viewable through Stetho
Reactive Notifications
Cons:
Huge library size without APK splits which will be hard to maintain
No support for primitives
No auto migrations

ObjectBox:
Pros:

Claims to be fastest
NoSQL structure favours our use case of JSON structured data
Small lib size
Can test real database in unit tests (no need of mocking)
Easy to implement
Reactive Notifications
Automatic Migrations - this is huge
Cons:
Manual one to many or many to many relations
Currently, no way to view the stored data

@free4murad @harshitagupta30 @rohanagarwal94 @Shailesh351
Please suggest/comment about the issue so we can start working on it. IMO, it should be the first issue to handle so that we can design tests and architecture accordingly and fix bugs faster

@iamareebjamal In my opinion Realm would be the best to use. All the reasons you've already mentioned so I will not write it again :+1:  :)

@iamareebjamal
Haven't heard about ObjectBox, but Realm I have used. I personally would go with Realm.

In my opinion Realm will be great.
On Fri, May 5, 2017, 2:01 PM Murad<EMAIL_ADDRESS>wrote:

@iamareebjamal https://github.com/iamareebjamal
Haven't heard about ObjectBox, but Realm I have used. I personally would
go with Realm.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fossasia/open-event-android/issues/1466#issuecomment-299410617,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARaybOBKaDlsk6d7ALsMu15IkSW36G6Oks5r2t5XgaJpZM4NParx
.

OK. So I also think Realm will be better as it is older and more stable.
I will open a branch on my fork and would request your support and collaboration on it.
@the-dagger @mananwason  Waiting for you approval...

Realm sounds good to me.
Let's wait for @mananwason's approval too.

--
Best,
Harshit Dwivedi

@harshitagupta30 Auto migrations are helpful when updating API structure, but Realm also provides a migration API
About the APK split, most of the time developer teams reject Realm is because of the size of the library which is about 4 MB. This is because the native code added to the project has to support multiple architectures like armv7, x86, x86_64.
To reduce this size, they have to use APK splits, which outputs different APK for different architectures. This reduces the size of lib to only 1 MB.
But then we have 4 APKs to upload. Realm is extremely reliable so its not needed to test on different platforms since only realm code changes but to point it out, I wrote in the points

@iamareebjamal @the-dagger I also agree that realm would be a better option but since our datasets are not that big that a lot of performance difference will be visible, I wonder if this is something that should be done right now? Perhaps this can be taken up at a later stage. Right now we should be making the app and generator bug free and improve their integration with the server.
So, In my opinion there's no point in wasting a lot of time changing the whole code of the app to reduce access time by a fraction. Please focus on writing tests and finding, fixing bugs right now.

@mananwason But tests for current db would be mundane if we replace it with Ream at a later stage. Also, there have been plans on implementing Realm from last year itself but it never happened. Along with the speed and performance, with every change in the API, there are a lot of changes required to be done in the app code, and sometimes even break the app update.

@iamareebjamal Changing api format is one reason why Realm would be better in our usecase. I am okay with you implementing it but you need to be on a timeline and strictly finish by then. Please share your timeline here.

@mananwason I'll complete the Realm integration in this week itself and the data layer test in the next week. If more detailed description is required, I will be happy to do so. Thanks :)

Almost all joins have been removed since now we get sessions with tracks and speakers with sessions and vice versa. Some bugs remain to ironed out. Except that, everything is fine


Crash on WROVER working with flash psRAM memory

I am working on a WROVER module using the latest ESP-IDF and toolchain for WROVER as of the date of this post.  When I run my application (which is very large ... too much to simply supply you as a sample), I crash with the following exception log:
Guru Meditation Error: Core  0 panic'ed (Cache disabled but cached memory region accessed)
Register dump:
PC      : 0x400953ed  PS      : 0x00060b34  A0      : 0x80095b3c  A1      : 0x3ffce760
0x400953ed: esp_rom_spiflash_read_data at /home/kolban/esp32/wrover/esp-idf/components/spi_flash/./spi_flash_rom_patch.c:412

A2      : 0x3ffae270  A3      : 0x001d2500  A4      : 0x3f800764  A5      : 0x00000050
A6      : 0xf0000040  A7      : 0x00000005  A8      : 0x0000000f  A9      : 0x00000001
A10     : 0x00042080  A11     : 0x3f800764  A12     : 0x00000ffc  A13     : 0x00000002
A14     : 0x00000000  A15     : 0xff000000  SAR     : 0x00000020  EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000  LBEG    : 0x400012c5  LEND    : 0x400012d5  LCOUNT  : 0xfffffff6

Backtrace: 0x400953ed:0x3ffce760 0x40095b3c:0x3ffce780 0x4008341b:0x3ffce7a0 0x40172332:0x3ffce800 0x401730c5:0x3ffce830 0x40174109:0x3ffce860 0x40174405:0x3ffce8d0 0x401759bd:0x3ffce910 0x40172d84:0x3ffce950 0x400df295:0x3ffce980 0x400deb18:0x3ffce9f0 0x4000bcc8:0x3ffcea10 0x4016894c:0x3ffcea30 0x400e5026:0x3ffcea50 0x400f5d2a:0x3ffceac0 0x400f9f38:0x3ffceb20 0x400f57b0:0x3ffceb40 0x400f5a84:0x3ffceba0 0x400f5c9d:0x3ffcec30 0x400f5ec8:0x3ffcec90 0x40108dac:0x3ffced60 0x400def66:0x3ffced80
0x400953ed: esp_rom_spiflash_read_data at /home/kolban/esp32/wrover/esp-idf/components/spi_flash/./spi_flash_rom_patch.c:412

0x40095b3c: esp_rom_spiflash_read at /home/kolban/esp32/wrover/esp-idf/components/spi_flash/./spi_flash_rom_patch.c:586

0x4008341b: spi_flash_read at /home/kolban/esp32/wrover/esp-idf/components/spi_flash/./flash_ops.c:405

0x40172332: esp32_spi_flash_read at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./esp_spiffs.c:66

0x401730c5: spiffs_phys_rd at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_cache.c:143

0x40174109: spiffs_object_find_object_index_header_by_name_v at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_nucleus.c:1114

0x40174405: spiffs_obj_lu_find_entry_visitor at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_nucleus.c:1114

0x401759bd: spiffs_object_find_object_index_header_by_name at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_nucleus.c:1655

0x40172d84: SPIFFS_stat at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_hydrogen.c:795

0x400df295: vfs_stat at /home/kolban/esp32/esptest/apps/workspace/duktape/main/./duktape_spiffs.c:76

0x400deb18: esp_vfs_stat at /home/kolban/esp32/wrover/esp-idf/components/vfs/./vfs.c:283 (discriminator 3)

0x4016894c: stat at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/syscalls/../../../.././newlib/libc/syscalls/sysstat.c:13

0x400e5026: js_fs_statSync at /home/kolban/esp32/esptest/apps/workspace/duktape/main/./module_fs.c:232

0x400f5d2a: duk__handle_call_inner at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f9f38: duk_handle_call_unprotected at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f57b0: duk__js_execute_bytecode_inner at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f5a84: duk_js_execute_bytecode at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f5c9d: duk__handle_call_inner at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f5ec8: duk_handle_call_protected at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x40108dac: duk_pcall at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400def66: duktape_task at /home/kolban/esp32/esptest/apps/workspace/duktape/main/./duktape_task.c:276

CPU halted.

As we see, we are failing deep in the heart of what appears to be ROM based code and far outside of my comprehension skills.  I will be happy to switch on any additional diagnostics requested or demonstrate live via screen share.

Currently, when using the pSRAM, you must make sure that buffers passed to spi_flash_read function (and spi_flash_write as well) are not located in external memory. If the buffer coming from the upper layer (in your case that is SPIFFS, spiffs_phys_rd ) can be allocated in external memory, you need to create a temporary buffer using heap_caps_malloc(size, MALLOC_CAP_DMA); to get some internal memory, read into this temporary buffer, and then copy to the buffer passed in by the application (which may be in pSRAM region).
The reason for this is that when we access SPI flash, we disable the cache, which is the mechanism which is used to memory-map SPI flash and SPI RAM into CPU's address space. With cache disabled, attempts to access memory-mapped SPI flash and SPI RAM will fail. This is why the buffer passed to spi_flash_read/spi_flash_write must be in the internal memory.
We will make this automatic within spi_flash_read functions, before integrating pSRAM support into master. For now, you need to do this yourself in your application.

I am not sure how this is currently controlled in the pSRAM support branch.

AFAIK it is not other than the fact that internal memory has higher priority in heap allocator

Thank you guys, this is pure gold.  I'm hoping I didn't miss a readme or other public memo.  Is there somewhere where we are collecting pSRAM notes like these?  Hopefully others who may run into the problem in future may find a match on a search on Github issues.  I will start work re-working my own code usage to exercise the new instructions/knowledge outlined above.   I'll keep the issue open until then and add notes and results ... hopefully for the benefit of others.  MANY thanks for responding.

Hmmm .... a puzzle.  I sat down this evening to try out this technique on the WROVER.  According to instructions, for the WROVER, I am supposed to use this version of the ESP-IDF:
https://github.com/espressif/esp-idf/tree/feature/psram_malloc
However, that doesn't have the component called "heap" which is where I believe the heap_caps_malloc() is supposed to be found.  I'm afraid I'm stuck.

@nkolban it was forked before heap was split out as a separate component skit is still in /components/esp32

@negativekelvin Thank you sir.  Based upon your clues and the info from @igrr, I found a recipe which seems to work:

Include <stdbool.h> in my C source
Include "esp_heap_alloc_caps.h" in my C source
Instead of calling malloc() (what I had been doing) or heap_caps_malloc() (as @igrr suggested) I ended up calling pvPortMalloc(size, MALLOC_CAP_DMA)

So far so good ... seems to be working ... (fingers crossed).

I think you mean pvPortMallocCaps

I'm also having occasional error:
Guru Meditation Error: Core  0 panic'ed (Cache disabled but cached memory region accessed)
Guru Meditation Error: Core  0 panic'ed (Cache disabled but cached memory region accessed)
Register dump:
PC      : 0x40085830  PS      : 0x00060834  A0      : 0x8008146e  A1      : 0x3ffaeac0
0x40085830: spi_flash_op_block_func at /home/LoBo2_Razno/ESP32/MicroPython/MicroPython_ESP32_psRAM_LoBo/esp-idf_psram/components/spi_flash/./cache_utils.c:84 (discriminator 1)

A2      : 0x3ffbfc01  A3      : 0x00000001  A4      : 0x3ffae5cc  A5      : 0x00000000
A6      : 0x00000000  A7      : 0x00000001  A8      : 0x00000000  A9      : 0x3ffaeaa0
A10     : 0x00000820  A11     : 0x3ffbfc08  A12     : 0x00000006  A13     : 0x3ff00040
A14     : 0x00000828  A15     : 0x00000002  SAR     : 0x00000000  EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000

Backtrace: 0x40085830:0x3ffaeac0 0x4008146e:0x3ffaeae0
0x40085830: spi_flash_op_block_func at /home/LoBo2_Razno/ESP32/MicroPython/MicroPython_ESP32_psRAM_LoBo/esp-idf_psram/components/spi_flash/./cache_utils.c:84 (discriminator 1)

0x4008146e: ipc_task at /home/LoBo2_Razno/ESP32/MicroPython/MicroPython_ESP32_psRAM_LoBo/esp-idf_psram/components/esp32/./ipc.c:64

CPU halted.

I'm working with a large project (MicroPython port) and most of the time it works perfectly.
As far as I can tell, the mentioned error occurs only when accessing flash file system (both FatFS and SPIFFS (I'm using pvPortMallocCaps(size, MALLOC_CAP_DMA) and I can read/write files without problem most of the time)).
The error occurs randomly, for no obvious reason.
I'm running on both cores, but the error is always: Core  0 panic'ed, and always on the same place, components/spi_flash/./cache_utils.c:84 (discriminator 1)

Howdy @loboris,
If you are interested, I'll be delighted to work with you to debug the issue.  I think the core of the story will be look at the underlying spi_flash_* calls and see what they are passing in and receiving.  From there we can take a look and see if are certain that we know the the memory was allocated from the MALLOC_CAP_DMA pool.  My tests seemed to show that when I crashed, it was as a result of performing spi_flash calls using malloc'd memory that came from the pSRAM ... which based on the documented restrictions in the post from @igrr I seem to have circumvented by validating that I am allocating from the MALLOC_CAP_DMA pool.

@nkolban
I hope you'll have more success in debugging this issue, but maybe it's best to wait for the psRAM branch update.
I've tried all combinations of SPI RAM settings and SPI Flash/SPI RAM speeds, and the error always eventually occurs.
Even if I disable malloc() can also allocate in SPI SRAM option, so that psRAM memory can be allocated only explicitly (and I'm doing this in one place only, when allocating MicroPython heap)  using pvPortMallocCaps(size, MALLOC_CAP_DMA), the error still occurs.
It looks like it is not related to SPI flash read/write from application, but to instruction fetching/caching from flash, on more lower level than I'm capable of and willing to debug.
I was never able to find the exact place in application code which causes the error. Sometimes the application runs for hours and then crashes for no obvious reason.

Oh my ... the key to me in the above was that you disabled malloc() for SPI SRAM and still the problem was encountered.  This should result in no allocation of RAM from pSRAM that could possibily be used for flash source or destination for the file system APIs.  If that's the case ... then (although I already was) ... I'm out of my depth and can't offer anything other than a fresh pair of eyes to listen to colleague thinking.   I'll be happy to do that if you desire.  Do we have any knowledge on when the "psRAM branch update" may be scheduled for?

and I'm doing this in one place only, when allocating MicroPython heap) using pvPortMallocCaps(size, MALLOC_CAP_DMA)

I think you mean MALLOC_CAP_SPISRAM
Are you saying buffers in micropython heap are not used for filesystem transactions?

@negativekelvin
Yes, I've meant MALLOC_CAP_SPISRAM.
File system transactions are done via low level driver  (esp_spiffs.c for spiffs, wear leveling driver for FatFS), so yes, micropython heap is never used directly in fs transactions.
Even if malloc() can also allocate in SPI SRAM is enabled, I always set the option that memory smaller than 32767 bytes is allocated in DRAM and, as far as I'm aware, nothing ever allocates the larger buffer.
I still think that the problem is on the lower level. Concurrent reads from spi flash & spi sram occurs all the time, instruction codes, if not cached are read from flash, micropython bytecode or/and tata are read from spi sram ... and somewhere, sometimes Cache disabled but cached memory region accessed error occurs.

Hi all,
I am also getting this error though in esp_ota_begin() function. My flash size is around 1.2MB and includes ble, wifi both.
My partition file info: (make partition_table)

Espressif ESP32 Partition Table
Name, Type, SubType, Offset, Size, Flags
nvs,data,nvs,0x9000,16K,
otadata,data,ota,0xd000,8K,
phy_init,data,phy,0xf000,4K,
ota_0,app,ota_0,0x10000,1536K,
ota_1,app,ota_1,0x190000,1536K,

With ota example, it is working fine. With my project it is giving this error. I have used malloc throughout my project and when i see api, it is also using malloc only.
I am using esp-idf master branch to this date: commit:9a26296

@ikawaljeet: Do you have SPI RAM enabled?

If you mean "Support for external, SPI-connected RAM" then it is not enabled.
Though when i unloaded bluetooth stack, it got working. I think it was more of RAM availability problem on my side.

I seem to be having this same problem in ESP-IDF v3.1.3:
`Guru Meditation Error: Core  0 panic'ed (Cache disabled but cached memory region accessed)
Core 0 register dump:
PC      : 0x400995d8  PS      : 0x00060434  A0      : 0x800860bc  A1      : 0x3ffbd4f0
0x400995d8: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:342
A2      : 0x3f801020  A3      : 0x3ffbd538  A4      : 0x0000000b  A5      : 0x3f801028
A6      : 0x9f3886a8  A7      : 0xa8bbfaba  A8      : 0x9f3886a8  A9      : 0x3ffbd4c0
A10     : 0x00000000  A11     : 0x00000001  A12     : 0x3ffbd53c  A13     : 0x00000000
A14     : 0xf0000040  A15     : 0x00000006  SAR     : 0x00000008  EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000  LBEG    : 0x40099585  LEND    : 0x400995b9  LCOUNT  : 0xffffffff
0x40099585: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:291
0x400995b9: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:324
Backtrace: 0x400995d8:0x3ffbd4f0 0x400860b9:0x3ffbd500 0x40115a9f:0x3ffbd570
0x40117803:0x3ffbd5a0 0x401eb911:0x3ffbd5d0 0x4011ae29:0x3ffbd5f0 0x40116ad8:0x3ffbd640 0x40117105:0x3ffbd670 0x401167a5:0x3ffbd690 0x4011f6b6:0x3ffbd6b0
0x4000bdbb:0x3ffbd6d0 0x40099f2e:0x3ffbd6f0 0x40121dc6:0x3ffbd710 0x401231d6:0x3ffbd730 0x401ec7c1:0x3ffbd750 0x40126732:0x3ffbd770 0x400f29f5:0x3ffbd7a0
0x400995d8: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:342
0x400860b9: spi_flash_read at /home/han/esp/esp-idf-v3.1.3/components/spi_flash/flash_ops.c:498
0x40115a9f: esp_partition_read at /home/han/esp/esp-idf-v3.1.3/components/spi_flash/partition.c:240
0x40117803: spiffs_api_read at /home/han/esp/esp-idf-v3.1.3/components/spiffs/spiffs_api.c:36
0x401eb911: spiffs_phys_rd at /home/han/esp/esp-idf-v3.1.3/components/spiffs/spiffs/src/spiffs_nucleus.c:70
0x4011ae29: spiffs_object_read at /home/han/esp/esp-idf-v3.1.3/components/spiffs/spiffs/src/spiffs_nucleus.c:2043
0x40116ad8: spiffs_hydro_read at /home/han/esp/esp-idf-v3.1.3/components/spiffs/spiffs/src/spiffs_hydrogen.c:1121
0x40117105: SPIFFS_read at /home/han/esp/esp-idf-v3.1.3/components/spiffs/spiffs/src/spiffs_hydrogen.c:1121
0x401167a5: vfs_spiffs_read at /home/han/esp/esp-idf-v3.1.3/components/spiffs/esp_spiffs.c:324
0x4011f6b6: esp_vfs_read at /home/han/esp/esp-idf-v3.1.3/components/vfs/vfs.c:962
0x40099f2e: read at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/syscalls/../../../.././newlib/libc/syscalls/sysread.c:12
0x40121dc6: std::__basic_file::xsgetn(char*, int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/src/c++98/basic_file.cc:211
0x401231d6: std::basic_filebuf<char, std::char_traits >::xsgetn(char*,
int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/fstream:758
0x401ec7c1: std::basic_streambuf<char, std::char_traits >::sgetn(char*, int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/streambuf:436
0x40126732: std::istream::read(char*, int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/streambuf_iterator.h:113
0x400f29f5: FileHelper::ReadFileTask(void*) at /mnt/c/Users/han/Documents/Projects/esp32base/components/network/fileHelper.cpp:146`
This happens whenever I try to copy a file from a spiffs filesystem in flash, into a buffer allocated in PSRAM.


Provide a way to use router links from models

In order to be able to use router links they have to be added from within the binding. The process should be made as simple as possible.

Fixed in https://github.com/thoughtsunificator/domodel/commit/459cb523081faafc16c6c4eb322cfd7645201071


Fixing origin when wrapping Bristol (fixes #29)

Fix from issue #29.
The solution proposed in the issue did not work out because of cases where there are multiple callsites in the logger itself, meaning that index + 1 would sometimes still reference the Bristol logger file.
For example, the stack from one of the mocha tests:
0:"/Users/Mark/projects/Bristol/src/Bristol.js"
1:"/Users/Mark/projects/Bristol/src/Bristol.js"
2:"/Users/Mark/projects/Bristol/src/Bristol.js"
3:"/Users/Mark/projects/Bristol/test/src/Bristol.js"
4:"/Users/Mark/projects/Bristol/node_modules/mocha/lib/runnable.js"
5:"/Users/Mark/projects/Bristol/node_modules/mocha/lib/runnable.js"
6:"/Users/Mark/projects/Bristol/node_modules/mocha/lib/runner.js"
7:"/Users/Mark/projects/Bristol/node_modules/mocha/lib/runner.js"
8:"/Users/Mark/projects/Bristol/node_modules/mocha/lib/runner.js"
9:"/Users/Mark/projects/Bristol/node_modules/mocha/lib/runner.js"
10:"/Users/Mark/projects/Bristol/node_modules/mocha/lib/runner.js"
11:"/Users/Mark/projects/Bristol/node_modules/mocha/lib/runner.js"
12:"timers.js"
13:"timers.js"
14:"timers.js"

The fix was just to look for the last occurrence of the Bristol logger file.

Nice! I love the brevity of this. My only concern is that this solution is O(2n) rather than O(n) -- but that may be entirely moot benchmark-wise because of how well-optimized map and lastIndexOf are. Will merge when I confirm!

Annoyingly enough, the verbose loop measurably outperforms map & lastIndexOf (at least on Node 7). Bringing it back to O(n), here's what I have -- what do you think?
_getOrigin() {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  for (let i = 1; i < stack.length; i++) {
    if (stack[i].getFileName() === __filename && stack[i + 1]) {
      origin = {
        file: stack[i + 1].getFileName(),
        line: stack[i + 1].getLineNumber().toString()
      }
    }
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

@TomFrost This won't work for the case I have above where multiple callsites are from Bristol.js itself. I can make adjustments to mine to be more performant though. I was on the fence on messing with the code to gain O(1n) better perf.

That doesn't give you the record after the final Bristol entry? Would you mind throwing a test script together that'll let me play with your use case?

@TomFrost I apologize, your code will work as intended. I didn't notice that you removed the break statement when reading it.
Regardless, I believe that my new code will be slightly more performant than the above code because I traverse the stack backwards and create an a new origin object (which also incurs multiple function calls) only once as opposed to every time with the above code.

I actually tried the same method, and strangely enough it was slower than the code above. I also added an else if (origin) break at the end of the conditional to exit early, and THAT was slower too -- though that may have only been slower because I was testing with a shallow stack trace. I'll post my benchmark script with everything I tried when I get back to my computer.

Ok, well if you have something that works and are happy with it, let's just get that committed to master and I will close this PR. That would work for both of us. 👍

Here's what I was playing with last night-- Old is current, New is the solution in this PR, New2 is what I have above, and the successive ones are my failed attempts at further optimization. Right now, New2 is the winner, but I'd like to test this with a larger stack trace before we pull the trigger.
'use strict'

const originalPrepareStackTrace = Error.prepareStackTrace
const arrayPrepareStackTrace = (err, stack) => { return stack }

const getOriginNew = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  const lastIndex = stack.map(s => s.getFileName()).lastIndexOf(__filename)
  const line = stack[lastIndex + 1]
  const origin = {
    file: line.getFileName(),
    line: line.getLineNumber().toString()
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginNew2 = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  for (let i = 1; i < stack.length; i++) {
    if (stack[i].getFileName() === __filename && stack[i + 1]) {
      origin = {
        file: stack[i + 1].getFileName(),
        line: stack[i + 1].getLineNumber().toString()
      }
    }
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginNew3 = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  for (let i = stack.length - 1; i > 0; i--) {
    if (stack[i].getFileName() === __filename && stack[i + 1]) {
      origin = {
        file: stack[i + 1].getFileName(),
        line: stack[i + 1].getLineNumber().toString()
      }
      break
    }
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginNew4 = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  stack.forEach((entry, idx) => {
    if (entry.getFileName() === __filename && stack[idx + 1]) {
      origin = {
        file: stack[idx + 1].getFileName(),
        line: stack[idx + 1].getLineNumber().toString()
      }
    }
  })
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginNew5 = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  for (let i = 1; i < stack.length; i++) {
    if (stack[i].getFileName() === __filename && stack[i + 1]) {
      origin = {
        file: stack[i + 1].getFileName(),
        line: stack[i + 1].getLineNumber().toString()
      }
    } else if (origin) break
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginOld = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  for (let i = 1; i < stack.length; i++) {
    const file = stack[i].getFileName()
    if (file !== __filename) {
      origin = {
        file,
        line: stack[i].getLineNumber().toString()
      }
      break
    }
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const ITERS = 100000

console.log('Testing old...')
let start = Date.now()
for (let i = 0; i < ITERS; i++) getOriginOld()
console.log('Old: ' + (Date.now() - start))

console.log('Testing new...')
start = Date.now()
for (let i = 0; i < ITERS; i++) getOriginNew()
console.log('New: ' + (Date.now() - start))

console.log('Testing new2...')
start = Date.now()
for (let i = 0; i < ITERS; i++) getOriginNew2()
console.log('New2: ' + (Date.now() - start))

console.log('Testing new3...')
start = Date.now()
for (let i = 0; i < ITERS; i++) getOriginNew3()
console.log('New3: ' + (Date.now() - start))

console.log('Testing new4...')
start = Date.now()
for (let i = 0; i < ITERS; i++) getOriginNew4()
console.log('New4: ' + (Date.now() - start))

console.log('Testing new5...')
start = Date.now()
for (let i = 0; i < ITERS; i++) getOriginNew5()
console.log('New5: ' + (Date.now() - start))

Output:
╭─<tom@tom-ta>-<~/Projects/test>-<1:38PM>-◇
╰─➤ node bench.js
Testing old...
Old: 1840
Testing new...
New: 2155
Testing new2...
New2: 2045
Testing new3...
New3: 2089
Testing new4...
New4: 2212
Testing new5...
New5: 2086

Neat! I think we should utilize benchmark to do this comparison if we are really interested in perf.
 ~/c/stack-perf  node index.js
getOriginNew x 56,743 ops/sec ±0.99% (88 runs sampled)
getOriginNew2 x 62,641 ops/sec ±1.30% (92 runs sampled)
getOriginNew3 x 62,477 ops/sec ±1.38% (88 runs sampled)
getOriginNew4 x 59,580 ops/sec ±1.22% (92 runs sampled)
getOriginNew5 x 65,890 ops/sec ±1.24% (89 runs sampled)
getOriginOld x 66,595 ops/sec ±1.30% (87 runs sampled)
Fastest is getOriginOld

Run npm i benchmark to install.
'use strict'

const Benchmark = require('benchmark');
const suite = new Benchmark.Suite;

// add tests
suite.add('getOriginNew', function() {
  getOriginNew()
})
.add('getOriginNew2', function() {
  getOriginNew2()
})
.add('getOriginNew3', function() {
  getOriginNew3()
})
.add('getOriginNew4', function() {
  getOriginNew4()
})
.add('getOriginNew5', function() {
  getOriginNew5()
})
.add('getOriginOld', function() {
  getOriginOld()
})
// add listeners
.on('cycle', function(event) {
  console.log(String(event.target));
})
.on('complete', function() {
  console.log('Fastest is ' + this.filter('fastest').map('name'));
})
// run async
.run({ 'async': true });

const originalPrepareStackTrace = Error.prepareStackTrace
const arrayPrepareStackTrace = (err, stack) => { return stack }

const getOriginNew = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  const lastIndex = stack.map(s => s.getFileName()).lastIndexOf(__filename)
  const line = stack[lastIndex + 1]
  const origin = {
    file: line.getFileName(),
    line: line.getLineNumber().toString()
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginNew2 = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  for (let i = 1; i < stack.length; i++) {
    if (stack[i].getFileName() === __filename && stack[i + 1]) {
      origin = {
        file: stack[i + 1].getFileName(),
        line: stack[i + 1].getLineNumber().toString()
      }
    }
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginNew3 = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  for (let i = stack.length - 1; i > 0; i--) {
    if (stack[i].getFileName() === __filename && stack[i + 1]) {
      origin = {
        file: stack[i + 1].getFileName(),
        line: stack[i + 1].getLineNumber().toString()
      }
      break
    }
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginNew4 = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  stack.forEach((entry, idx) => {
    if (entry.getFileName() === __filename && stack[idx + 1]) {
      origin = {
        file: stack[idx + 1].getFileName(),
        line: stack[idx + 1].getLineNumber().toString()
      }
    }
  })
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginNew5 = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  for (let i = 1; i < stack.length; i++) {
    if (stack[i].getFileName() === __filename && stack[i + 1]) {
      origin = {
        file: stack[i + 1].getFileName(),
        line: stack[i + 1].getLineNumber().toString()
      }
    } else if (origin) break
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

const getOriginOld = () => {
  Error.prepareStackTrace = arrayPrepareStackTrace
  const stack = (new Error()).stack
  let origin = null
  for (let i = 1; i < stack.length; i++) {
    const file = stack[i].getFileName()
    if (file !== __filename) {
      origin = {
        file,
        line: stack[i].getLineNumber().toString()
      }
      break
    }
  }
  Error.prepareStackTrace = originalPrepareStackTrace
  return origin
}

Oh, that's handy! It also proves that #5, the version with the break, is most certainly faster with a more realistic stack trace.

@TomFrost ok, so are we decided on #5 then?

Looks like the winner, unless you have any other ideas or optimizations :)
(Though it still boggles the mind why the reverse traversal that you suggested isn't faster... that's got to be some V8 optimization magic right there)

I tested approach #5 in my application and unfortunately it still logs the wrapper line. I'll have to take a look at why it doesn't work and will also add a test to the PR to replicate my scenario.
I'll have time to do this tomorrow.

@TomFrost I isolated out the stack processing logic for testability and optimized it a bit further. I think it's about as good as it's going to get, having even pulled a variable out of the for-loop. Please take a look when you get a chance.

Excellent!


Ideas on the project structure

*analysing
    tightness

command_line

convenience
    apply
    unbox

formatting      -> Format structs
    asp
        default
    fol
        default
        tptp

parsing         -> Parser trait
    asp
        pest
    fol
        pest

*verifying
    task        -> Task trait
    problem     -> Problem struct
    proof

simplifiying
    fol
        ht
        *classic

syntax_tree     -> Node trait
    asp
    fol

translating
    gamma
    tau_star
    *completion

Modules marked with an * do not yet exist.
The module problem_building should be renamed into verifying/problem.

The proposed project structure was completely implemented.


disable nightly build on forks?

I updated my fork, and the nightly builds are running (and failing, but that's separate)
I'm not sure most folks want their forks to run a nightly build? I'm not heart-set on turning this off by default, but it does seem like a lot of compute that most folks don't want.
( instructions from here: https://github.community/t/do-not-run-cron-workflows-in-forks/17636 ) - not sure I got it right though

Disabling nightly builds on forks sounds good to me! Just as long as we document the change somewhere in the CONTRIBUTING.md document

@epaulson if you merge master into this branch and the tests start passing, I can merge this soon as well

Let's not worry about this one


Unknown directive Encryption on line XXX of /etc/cups/cupsd.conf.

Hello,
Tested with cups 2.3.3 & cups 2.2.6, I have this message when cups is starting.

E [10/May/2021:17:37:19 +0200] Unknown directive Encryption on line 5 of /etc/cups/cupsd.conf.

Here is my conf :

LogLevel debug
PageLogFormat
# Force https
DefaultEncryption Required
Encryption Required
Port 631
ServerAlias *
Browsing On
BrowseLocalProtocols none
DefaultAuthType Basic
WebInterface Yes
ErrorPolicy retry-current-job

@michelsaumon OK, so the "Encryption" directive can only appear inside a "Location" section, e.g.:
<Location />
Encryption Required
</Location>

You can find out more by looking at https://openprinting.github.io/cups/doc/man-cupsd.conf.html.


TypeError: global.getNativeSupport is not a function

Tried on a Webpack2 project, a project without webpack, tried using 'layer-websdk' and 'layer-websdk/index-es6', tried installing react-native, tried versions 5.0.0, 6.10.2, and 7.8.0 of node, and I get this error when I require this sdk. I've installed v3.3.1 from npm.
I've tried modifying the source as well to guard against the undefined function and I get the same error: global.addEventListener not defined issue that was previously reported to you.
https://github.com/layerhq/layer-websdk/issues/151
Really not sure what to try next.
Regards,
Adam

Able to reproduce in a brand new express generated app, appears to be React Native related, but I'm not using it. I have a sample project if you need it.

A sample project would be very helpful.

Figured it out! Had to add the client into the main.js which had the express app defined, and React defined. Then it started working. In order to funnel it back to proper MVC, I had to pull in the middleware concept from your react example.

Anything you can suggest for documentation to make it clearer how to make this work?  A sample project replicating the issue might still be handy for us to take a look at.

Here is a sample project where the problem happens!
[Uploading layer-exp.zip…](Layer Experiment Project)
I think something in the docs about the sdk needing access to Global or Window would be good, since these are not accessible in my Handlers.

Here is a sanitized sample project that demonstrates the issue. I think something in the docs about the requirement for Global or Window would be good, since those are not defined in my handler classes.
layer-exp.zip

Re: #151 - I upgraded to the new layer-websdk and think my previous issue has evolved to this issue.
https://github.com/layerhq/layer-websdk/issues/151#issuecomment-307249489
I upgraded layer-websdk to v3.3.2, then I tried to build my project and got an error on global.getNativeSupport('atob') is undefined https://github.com/layerhq/layer-websdk/blob/master/src/client-utils.js#L9
In node the library atob does not exist so it was returning "undefined", which in turn tried to call global.getNativeSupport and that function was not part of the global scope.  I then noticed that you added this to your react-native build in the global scope. So I dug into node_modules folder for layer-websdk and did the same for the index.js file and it all works :tada:.
here's what that (index.js) looks like now:
/* istanbul ignore next */
if (global.layer && global.layer.Client) {
  console.error('ERROR: It appears that you have multiple copies of the Layer WebSDK in your build!');
} else {
  global.getNativeSupport = function(module) {
      switch(module) {
        case 'atob':
          return function(b64Str) {
            let byteArray = base64JS.toByteArray(b64Str);
            let strArray = [];
            for (let i=0, l=byteArray.length; i<l; i++) {
              strArray[i] = String.fromCharCode(byteArray[i]);
            }
            return strArray.join('');
          }
        case 'btoa':
          return function(str) {
            let arr = str.split("").map((val) => {
              return val.charCodeAt(0);
            });
            return base64JS.fromByteArray(arr);
          }
        case 'setImmediate':
          // Globally defined by RN environment
          return setImmediate;
        case 'OnlineEvents':
          return NetInfo;
      }
  };
  global.layer = require('./lib/layer');
}
module.exports = global.layer;

Taking a look at your project... but don't see any build configurations, build commands, README, webpack config files, etc...
Some pointers would be appreciated.
My overall impression of what your problem is involves running the websdk in a nodejs environment rather than using a browserify/webpack build process to assemble a build file that executes in a browser; is that correct?  Or is it simply that your build process is close enough to running it that we're hitting this snag?

The problem was initially noticed in a generated project based on this one  if you copy the server folder from the one I provided into this one, and add necessary dependencies to the package.json, I believe you should see this problem with Webpack2 as well.
Again, I was able to fix it in future iterations, but I had to place the layerClient in the main.js app inside the src folder, which includes the React and React-DOM libraries. I was unable to pass the client to any of my Model handler classes on the server side, so I had to inject it (like your sample app) into a managed middleware layer that Redux automatically manages.
Let me know if you have any questions or want to give you a sanitized version of my working project this weekend.


Getting 'Upsert not allowed in a restricted collection' when attaching schema to collection

Hi,
Sorry I'm learning how to use your library. I'm coming across some behaviour that I'm finding strange.
I'm using the Upsert command to insert or update a documnent in a collection. However, when I attach it to a collection2 schema, it seems to be giving me the error
update failed: Access denied. Upserts not allowed in a restricted collection.
I created a sample solution here
https://github.com/waiholiu/collection2Upsert/tree/master
the Master branch I have a collection that's attached to a schema. If you run the solution, you'll see that it returns this error.
However, I also created a withoutCollection2 branch where I've commented out the line where I attach the schema and the error no longer appears.
I'm aware that I can just insert or update the document, but I'm just curious why Upsert does not seem to work here.

Hi, I think the problem is that in Meteor, upsert's automatically get denied on the client side whenever there are Allow rules defined.
See https://github.com/meteor/meteor/issues/1587
According to the meteor team, this is intentional.
Your collection2 library must be defining allow rules which is why when I attach the schema, it displays that message.

Yes, collection2 works by defining deny rules. Meteor does not currently allow upserts from untrusted code (and it would be difficult if not impossible to do so).

So GOD DAMN document it!!!


Fix optimize scripts loading

@Sean1572 please pull changes to workflow from main to bypass HDSI website checks

@Sean1572 @ccrutchf were there outstanding comments for this?  Or can we get this closed out?

@Sean1572 @ccrutchf were there outstanding comments for this? Or can we get this closed out?

ready to close for me


Fix issue 471

It fixes a problem with SRIOV/vDPA configuration:
https://github.com/k8snetworkplumbingwg/sriov-network-operator/issues/471

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.01%) to 24.535%

Files with Coverage Reduction
New Missed Lines
%

controllers/sriovibnetwork_controller.go
2
64.15%

api/v1/helper.go
3
41.67%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
2084

Relevant Lines:
8494

💛  - Coveralls

Commit message updated. Thanks


Implemented code for #92

This code is for issue #92 and #73

Please star this repository to show your support, in the meantime I am reviewing your code.

@amritansh22 Yes done :)

Hi @amritansh22, you haven't given any feedback about my PR.


Move the agents and recipes to the active_recipe folder as per the specs laid out in the architecture

Refer the architecture ticket for details.

Fixed by #146


Sensor sharing keyboard layout is not correct

The keyboard is not for email input. Meaning, there are no @ and .com keys to help with typing email addresses faster. Check also other keyboard layout styles on the app if they are correct.

QA passed


error on lsp_finder

Describe the bug
Error executing vim.schedule lua callback: Vim:E325: ATTENTION
stack traceback:
        [C]: in function 'bufload'
        ...ocal/share/nvim/lazy/lspsaga.nvim/lua/lspsaga/finder.lua:256: in function 'create_finder_data'
        ...ocal/share/nvim/lazy/lspsaga.nvim/lua/lspsaga/finder.lua:205: in function 'callback'
        /usr/local/share/nvim/runtime/lua/vim/lsp.lua:2053: in function 'handler'
        /usr/local/share/nvim/runtime/lua/vim/lsp.lua:1411: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

Steps to reproduce
executing command: Lspsaga lsp_finder
Expected behavior
no errors
Neovim version (nvim -v)
NVIM v0.10.0-dev-b3d5138
lspsaga commit
4f07545
Terminal name/version
alacritty

how do you trigger this error provide a step

I also got similar error.

Terminal - Powershell
NVIM v0.9.0-dev

error not same .for your issue your build with a too old commit. please try use the latest stable 0.9 or build with last commit is 0.10

Thanks. It's working fine now after update.


.github/workflows: add auto-merge action

When a "autocommit" label is applied to a PR, this action will wait for CI to pass
and then merge the PR using rebase method (preserving individual commits).
Similarly, "autosquash" label will result in merging using squash method
(commit the whole PR as a single commit).
The action respects github branch protection rules, in particular this is where
"wait for CI" part is configured:
https://github.com/google/syzkaller/settings/branches
Action reference:
https://github.com/marketplace/actions/merge-pull-requests

Tried to restart again, same error. No updates on https://github.com/pascalgn/automerge-action/issues/115

Tried to update to the latest version, still failing with:
2022-09-01T12:05:35.590Z ERROR command failed with code 128: git push --quiet --force-with-lease origin dvyukov-automerge

For some reason it tried to push to my fork.


Is this project using Firebase Auth?

I wondered if the project is completely separate, or can use Firebase Auth package?

It can be used with FirebaseAuth package.


Handle incomplete destinations in PDF documents where the viewport starts at non-zero coordinates (bug 1913617)

Hopefully this makes sense, since it doesn't appear to break "proper" PDF documents in my quick testing.

/botio-linux preview

Could you add an integration test ?

@Snuffleupagus would you be able to provide a basic test case and I'll write the test if you don't have the time to do it ?


Support Predicting Unseen Entities

Background and Context
GNN in Knowledge Transfer for Out-of-Knowledge-Base Entities: A graph Neural Network Approach supports predicting unseen entities. We should have this model.
Description

Here at Thales, we are currently trying to use this upcoming feature directly from the branch. We were previously using 1.0.2 and are facing some problems. We saw that loss function multiclass_nll that we were using in our ComplEx saved model does not seem to be supported anymore, is it correct? This may impact our current work, so would be great to get clarification on this.
Also, we tried the unseen entity example which seems to work if you use the model right after using the fit function. In our workflow we prefer to save the model on disk and then restore for later use. Unfortunately the feature branch code will fail with the following error: AttributeError: 'ComplEx' object has no attribute 'ent_emb'. Any plan to fix this?
The sample code use is attached.
unseen_test.zip
Thanks

multiclass_nll would be supported in our releases.
The problem is that this feature branch(feature/#82) was branched out from an older version of AmpliGraph (which didn't not have the multiclass_nll loss) and doesn't contain the later changes that have been done on the master branch.  As you rightly pointed out, it would be great if we integrate the changes on master branch into this branch (to keep it up to date).
This feature is not complete, so you may notice some issues, but once complete it would be merged to develop.

Thanks for the clarification. What would be the ETA for completing this feature. From what I understand it is expected to be in milestone 1.2 (due august 8th?).

Hi @mmercierTh
I have pushed some changes to feature/82. The restored model can predict unseen entities and  multiclass-loss is also supported. Because there is some changes from the multiclass_nll version, your example code should now look like:

from ampligraph.latent_features import ComplEx
from ampligraph.utils.model_utils import save_model as ampligraph_save_model
from ampligraph.utils.model_utils import restore_model as ampligraph_restore_model
import os

model = ComplEx(batches_count=2, seed=555, epochs=20, k=10, loss="multiclass_nll")

X = np.array([["a", "y", "b"],
            ["b", "y", "a"],
            ["a", "y", "c"],
            ["c", "y", "a"],
            ["a", "y", "d"],
            ["c", "y", "d"],
            ["b", "y", "c"],
            ["f", "y", "e"]])

model.fit(X)

saved_name = "./model.pkl"

ampligraph_save_model(model, model_name_path=saved_name)
restored_model = ampligraph_restore_model(model_name_path=saved_name)

print(model.predict(np.array(["z", "y", "f"]), approximate_unseen={
        "pool": "avg",
        "neighbour_triples": [["z", "y", "c"],["z", "y", "d"]]
}))

print(restored_model.predict(np.array(["z", "y", "f"]), approximate_unseen={
        "pool": "avg",
        "neighbour_triples": [["z", "y", "c"],["z", "y", "d"]]
}))```

What we have done in this moment is the baseline in the paper which the unseen vector is approximated from its neighbors using average, max or sum metric. We are expecting to have the Hamaguchi model implemented in version 1.2 with full intergrated tests and documentation.

Great thanks, we tested the update and it is only working for a single prediction. but not for 2 or more consecutive prediction from a model that is loaded once. Is there any method we should call to reset the model before each prediction? The error is below with a sample code
Traceback (most recent call last):
  File "/home/user/src/NER/graph_embeddings/unseen_test.py", line 29, in <module>
    "neighbour_triples": [["z", "y", "c"],["z", "y", "d"]]
  File "/home/user/.local/share/virtualenvs/graph_embeddings-RjobSHoH/lib/python3.6/site-packages/ampligraph/latent_features/models.py", line 2079, in predict
    approximate_unseen={**approximate_unseen, "k_size": 2 * self.k})
  File "/home/user/.local/share/virtualenvs/graph_embeddings-RjobSHoH/lib/python3.6/site-packages/ampligraph/latent_features/models.py", line 1088, in predict
    X, e, app_embs = self._assign_unseen_idx(approximate_unseen)(to_idx)(X, ent_to_idx=self.ent_to_idx, rel_to_idx=self.rel_to_idx)
  File "/home/user/.local/share/virtualenvs/graph_embeddings-RjobSHoH/lib/python3.6/site-packages/ampligraph/latent_features/models.py", line 949, in inner_dec
    k_size=approximate_unseen["k_size"])
  File "/home/user/.local/share/virtualenvs/graph_embeddings-RjobSHoH/lib/python3.6/site-packages/ampligraph/latent_features/models.py", line 1015, in _approximate_embeddings
    neighbour_vectors = self.get_embeddings(N_ent, embedding_type='entity')
  File "/home/user/.local/share/virtualenvs/graph_embeddings-RjobSHoH/lib/python3.6/site-packages/ampligraph/latent_features/models.py", line 395, in get_embeddings
    return emb_list[idxs]
IndexError: index 6 is out of bounds for axis 0 with size 6

sample code:
for i in range(2):
    print(model.predict(np.array(["z", "y", "f"]), approximate_unseen={
            "pool": "avg",
            "neighbour_triples": [["z", "y", "c"],["z", "y", "d"]]
    }))

for i in range(2):
    print(restored_model.predict(np.array(["z", "y", "f"]), approximate_unseen={
            "pool": "avg",
            "neighbour_triples": [["z", "y", "c"],["z", "y", "d"]]
    }))```

The bug has been fixed and new code has been updated to feature/82

Great it is now working fine now . Thanks for your responsiveness on this issue it is greatly appreciated. Quick question related to the implementation. How exactly do you calculate the embedding of the unseen entity. Thanks

We collect all the neighbour entities of that unseen entity, get their corresponding trained vectors, average, take the max or sum those. You can find the details of the implementation in line 997 of file ampligraph/latent_features/models.py, function def _approximate_embeddings. Hope this helps.

Hi,
That is what we figure out when we looked at the code. We wanted to be sure that we could use this code to get the approximate embedding of the unknown entity
neighbour_vectors = model.get_embeddings(["c", "d"])
approximate_embedding_of_z = numpy.np.mean(neighbour_vectors)

So the embedding of z is calculated from the average of its neighbors c and d.
I find this way of approximating z a little bit odd since it is an average of all its connected entities(neighbors) instead of being a average of all entities that have the same neighbors than z.
Is there something I'm not understanding ? Could you enlighten me on that ?

We were targeting implement the model in the paper Knowledge Transfer for Out-of-Knowledge-Base Entities: A graph Neural Network Approach. But at the moment the implementation is not done yet, so we just support the baseline. In the page number 6 of this paper, it describes the baseline of how to approximate the unseen entity, and we used this approach.

Thank you for the explanation and your responsiveness
We will continue to follow the development of this feature

Seems to break when filter_unseen_entities is set to True as no approximate_unseen is given and the var unseen is used before declaration in the line:
                self._add_app_embs(unseen, app_embs)(self._load_model_from_trained_params)()

Thanks for try out this feature. This issue is under development, so it may be unstable. As described here only the baselines have been implemented but the Hamaguchi model is not yet implemented.

I meant even without using a method, it seems to break because of conflicts with code structure further down. Before using any method, I wanted to get a baseline when removing unseen entities, using the same feature branch (i.e. make sure all entities are seen, and do not pass anything as approximate_unseen). Will submit a PR if I re-structure it and fix this.

This will be addressed in long-term release 2.1.


Fix Visual Inconsistencies in Item Collection

Summary
This PR addresses https://github.com/cerner/terra-clinical/issues/169.
Additionally, it updates then nightwatch tests to use expect syntax instead of assert.

I think this looks good to fix the inconsistencies. I just think that it's kinda weird that we're just using the first row to determine if accessories should be displayed. But maybe a separate issue needs to be logged for that.

@jmsv6d The use of the first row to determine the layout was something @mjhenkes and I discussed during the design of this component to determine the number of table columns dynamically. I agree its a bit weird though

@PaulSolDev @tm4027 This is ready for functional verification.

Appears correct in IE 10, 11, and Edge.

Checks out in Safari.

@PaulSolDev @tm4027 @mikertr @leemurdock  what validations are left on this?

@PaulSolDev @mikertr I restarted the heroku deployment. Here is the link: https://terra-clinical-deployed-pr-190.herokuapp.com/static/#/site

Looks good in macOS Chrome and Firefox.


fix: Broken keyboard nav with BorderRadius & BoxShadow

Description
Fixes #13634
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Manaully

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

/ok-to-test sha=67e7679

Tried using Tab key in keyboard and also used on screen keyboard for a clear look, seems the issue still persists
https://user-images.githubusercontent.com/104895602/167347055-bf6b624a-2156-4b6a-a371-c2c318b496dd.mp4
.

@Sripriya93 There was an issue with the deployment. This is working in release now.


[VS2017] 'Start page' entry doesn't exist in Package.appxmanifet

Package.appxmanifet made by 'C# Windows Application Packaging Project' template does not have 'Start Page'.
on the document:

what actually happens:

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

ID: c306f3b9-d287-beba-eb3b-513e58df2440
Version Independent ID: 787855c5-24d2-b772-e4c3-ce43118e5adb
Content: Tailor your PWA (EdgeHTML) for Windows - Microsoft Edge Development
Content Source: microsoft-edge/progressive-web-apps-edgehtml/windows-features.md
Product: microsoft-edge
Technology: pwa
GitHub Login: @MSEdgeTeam
Microsoft Alias: msedgedevrel

@sprout2000 the issue was that the article had the incorrect template name. You should instead use the Javascript Progressive Web App (Universal Windows) template. I've submitted a PR to fix the article. 👍
@Reezaali can you close this issue when the PR has been merged?

@sprout2000 - Thanks for opening the issue. We've updated the doc.


http://localhost:undefined on Windows 10 when using --open flag

Just getting into Solid Start for the first time. I bootstrapped an app and when I followed the docs to start the dev server with the --open flag, Windows gave me this error.
However the app works fine and the terminal shows the port properly, it just can't open it directly

Yeah probably when I removed hardcoding the default port. We probably need to make a decision here as Vite can set the port.

Yeah this should be fixed in the latest


Merge WatchOS support into latest head code

Opps, I was trying to pull your changes into my fork.