feat: Add auto save support when working on an existing file

For #2733
Auto save will be saving changes as they happen. The debounce will put these changes in order so they don't override each other.

Maybe instead of a timer.. when the scene is changed?

@lipis are you referring to the debounce function? it rather serves as a queue in this instance to avoid doing multiple calls at the same time. Although in this case, I'm not 100% sure how much better it is.

Thanks for working on @kbariotis.

lipis are you referring to the debounce function? it rather serves as a queue in this instance to avoid doing multiple calls at the same time. Although in this case, I'm not 100% sure how much better it is.

Let's keep the debounce.
We should also only attempt to save if there's an active file handle, and even in that case we should listen for errors and not attempt to autosave multiple times if the previous few tries failed. This can happen either due to some error, or when the user decides to cancel the "save changes" dialog.
I've gotten into a bad cycle when it tried save to a file without having a file handle, which was opening the save-file dialog ad infinitum.
As for where to put the toggle, maybe the export dialog is a better place? Because we'll also want some tooltip with more information detailing in which cases the autosave will apply to.

OK, I think its looking much better now. :)
@dwelle

Given that, let's only display the autosave option if the browser supports it (the new Filesystem API).

The browser-fs-access is a "ponyfill" so should always work, am I thinking right?

This should indeed only be done with the new File System Access API, else, we litter the Downloads folder of the user.
Is there a way to only save when there’s a change? A naive implementation could be to MD5 the stringified Excalidraw elements array and only save when there’s a difference.

Is there a way to only save when there’s a change? A naive implementation could be to MD5 the stringified Excalidraw elements array and only save when there’s a difference.

IMO this optimization isn't needed at this point (and it's also not easy, see https://github.com/excalidraw/excalidraw/issues/3185). The save is debounced so it shouldn't cause perf issues.
But yes, to answer @kbariotis question — the fs-browser-access cannot polyfill the FS API's file handle (and saving back to the same file), so we can't use autosave for legacy FS.

My brain is in weekend mode and I may miss things, but if all we need to know if things have changed since the last save, hashing the array should work, no? It could happen in line 916 in App.tsx. Again in weekend mode and on mobile, but is this autosaving every 500ms? If so, is this what apps like Word do? It seems wasteful at first sight, but I have to be honest no idea what’s a usual value here.

hehe no worries @tomayac, no it doesn't save every X time, it saves when the component updates, so when there is a change. The timeout is for debouncing subsequent updates so they don't override each other. :)

@tomayac is it worth exporting this helper function to use with this PR?

The timeout is for debouncing subsequent updates so they don't override each other. :)

Phew, seeing it now. Sorry for the noise.

@tomayac is it worth exporting this helper function to use with this PR? I'm happy to do a PR. :)

Might be worth it, indeed. We have another “supported” check somewhere, so yes!

Yea, we have several of these checks hardcoded across the app already so we may as well factor them into a single API.

Awesome, if we do merge the PR in browser-fs-access we can replace these checks.

Awesome, if we do merge the PR in browser-fs-access we can replace these checks.

I’ll have a look on Monday (since this is a work project) and merge this. Thanks already for the PR!

these checks

This has happened in https://github.com/excalidraw/excalidraw/pull/3303.

(#3303 has been merged now.)
I'm not sure the export dialog is the right place for the autosave checkbox. It's not very discoverable.
Is it time for a proper settings dialog? What else could go in there would be the dark mode toggle and the language selector. It could be a cog icon in the lower right corner, where currently the language selection is.

@ad1992 thoughts on how to make it obvious this doesn't relate to server persistence (not just, but mainly for host apps that autosave to server)?

@ad1992 thoughts on how to make it obvious this doesn't relate to server persistence (not just, but mainly for host apps that autosave to server)?

May be instead of just saying Autosave we can say something like Autosave to the existing file to make it explicit that its only for file system autosave ? Though we are adding a tooltip but if the label is itself more explicit then it won't cause any confusion I think

After discussion, here's current status:

There's a problem where the autosave is triggered on any change to app state, even one that's unrelated to the file. This results in saving too early and unnecessarily prompting the user for permissions. Most notably, the users are prompted immediately after importing a file. This needs to be solved — a naive fix would be to diff last saved state to the current one. If no change, don't attempt to save.
There's a lack of consensus on where the setting should be displayed, how automated it should be, what the default should be. One thing we agree on is that we shouldn't compromise on Excalidraw's simplicity principle.
Regardless, I think we need to track two states: currentFileAutosaveStatus & autosavePreference. This is so that users don't have to re-enable the setting every time there's a problem and we disable autosave for that session/file.

That said, first we need to reevaluate whether the benefit of this feature outweighs the costs — something we should have done at the beginning, but lots of the specs weren't clear from the start.
For example, the fact you need to separately give permissions to each file (and in each session) adds a lot of friction (this could in theory be partly alleviated by caching file handles into IDB so that you don't have to give permissions to the same file across sessions — provided the IDB flow would work like this).

There's a problem where the autosave is triggered on any change to app state, even one that's unrelated to the file. This results in saving too early and unnecessarily prompting the user for permissions. Most notably, the users are prompted immediately after importing a file. This needs to be solved — a naive fix would be to diff last saved state to the current one. If no change, don't attempt to save.

The naive fix sounds workable. Else a flag that tells if the actual (future) file contents have changed.

There's a lack of consensus on where the setting should be displayed, how automated it should be, what the default should be. One thing we agree on is that we shouldn't compromise on Excalidraw's simplicity principle.

It could also just be auto-on, Glitch style or Google Docs style (which, to be fair, work in the cloud, not the local file system).

Regardless, I think we need to track two states: currentFileAutosaveStatus & autosavePreference. This is so that users don't have to re-enable the setting every time there's a problem and we disable autosave for that session/file.

The goal of course would be to make it so that there are no problems… :-)

For example, the fact you need to separately give permissions to each file (and in each session) adds a lot of friction (this could in theory be partly alleviated by caching file handles into IDB so that you don't have to give permissions to the same file across sessions — provided the IDB flow would work like this).

File handles can be serialized, so this would work. Also, some of the permission friction may go away in the future, we're still experimenting with what the right threshold is. For example, see https://github.com/WICG/file-system-access/issues/288 or https://github.com/WICG/file-system-access/issues/89.

It could also just be auto-on, Glitch style or Google Docs style (which, to be fair, work in the cloud, not the local file system).

I still think it should be opt-in, user initiated. Otherwise every time users will import a file and edit it'll prompt them for write perms and they'll have no idea what's going on.
AFAIK only cloud-based apps do it. No desktop graphics editor I know has autosave enabled by default.

The goal of course would be to make it so that there are no problems… :-)

The "problems" here include user rejecting the permission prompt :).

Ok I'm using a very shitty hack. Open a file from fs and do a normal save using the button. Then paste this to js console
(() => {
  const elements = document.getElementsByClassName(
    'ToolIcon_type_button ToolIcon_size_medium ToolIcon_type_button--show ToolIcon ToolIcon--plain',
  );

  if (elements === null || elements.length == 0) return;

  setInterval(() => {
    elements[1].click();
  }, 60000);
})();

I know, I know this is bad. But I'm doing this as a hack for some help.

Hey guys, what ist the status of this PR? I would be very helpful to have an auto save option. I lost a lot of my work yesterday, because I opened a other board for quick check... :cry:

Would also love to see this implemented soon, because loosing your work due to an unsaved file is no fun.


Can't create new Laravel project - [RuntimeException] Could not delete /var/www/html/.

Hello,
Just got this installed on our remote server and trying to install my laravel project, but when I cd into src and run docker-compose run --rm composer create-project laravel/laravel . I get the following error:
Install of laravel/laravel failed
[RuntimeException]
Could not delete /var/www/html/.:
Any idea what could be happening here?

Hey all! Try pulling down the latest version of this repo and running docker-compose build --no-cache in your project. I just did a ton of work with the permissions issues, and this hopefully should solve your problem.
There's some more info in the README as well!

I'm having this same issue all of a sudden.. :/

Anyone found any solution to this? Tried everything mentioned in the README but issue remains same

Try going through #49 for any issues related to permissions issues, or check out the section in the README!


Added 42.cpp file

Fixes #42

My code sample is in :

[x] CPP
[ ] Java

Screenshot of working code sample  :

Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My code sample is formatted and works correctly

@Adityajha0808 format the file


[feature] Network down-/up-speed

Would be nice to be able to configure the network module to display the down- and up-speed of the interface.
I don't know how you get the network information (I can't read C++) but according to this post we can calculate it with information from /proc/net/dev for example.

Done in #328


[Bug] Grafting can skip copying data sources

Bug report
The following sequence of steps will lead to a grafted (or copied) subgraph with missing dynamic data sources:

Start a graft
Interrupt it and rewind the subgraph
Resume the graft

If at step (2), the graft had already copied data sources, and the rewind doesn't remove all of them, upon resuming, we will skip copying data sources because of this code
The result will be a graft that seems to be ok, but is missing dynamic data sources.

The fix might be simple: the whole of copying private data sources runs outside of a transaction. We should just wrap all of it in a txn.

@lutter those transactions could run for days, couldn't they?

Copying private data sources should be very quick; at the very worst, it's a table with 100k rows, but usually much less. The actual data copying, which can take days, is already broken into txns that should take about 3 minutes

Ah, understood,  thanks!

We've seen subgraphs up to 1.9 million data sources. Not sure if that matters at all for how this should be handled.

True; I just looked through the code again, and it does one insert statement per row, which will be very slow for these numbers of data sources. We'll also need to improve the code to do the copying with one query, or break it up into multiple txns but that requires more bookkeeping.


Header needs to be responsive #74

@kapilG0  instead of putting them in column make appbar responsive by adding burger many on top that opens specific links and pages

Something like this

on click

can even take reference from here https://superdry-kappa.vercel.app/

fixed already


Creates release even if failed pipeline

If/When one of the platform matrix targets fail, all others continue to upload their asset(s) to the release.
Expected the failed pipeline to not create a release until all matrix targets were successful.

We'll double check this but I don't think this is possible. Since each matrix job is ran separately, it's a little tricky to do it, probably needs another job that runs on finish. You can mark the release as a draft release though.

It's possible – I only have partially-failed Release pipelines (darn Windows), yet I have a GH release for each attempt.

You can mark the release as a draft release though.

See #6  – I have draft: true set and it's ignored


Masternode-Counter does'nt decrease

it seems like the masternodecount shows always the ath of nodes .. and not the current situation. also the masternode list shows a list ... that doesn't change.

Fixed in newest wallet


Automated Nightly Release to Production

This change is

It looks like the web driver tests did not get triggered due to the bracket [ ] format around expressions. I think I need double brackets instead and possibly parenthesis. Going to reject this one.


Update compats and dependencies

I thought that #3432 updated ClimaCore, but it turned out that we were held back by our BlockArrays dependency/compat, which was added ages ago. We don't actually need it, so this PR removes BlockArrays and Colors as direct dependencies, and updates the manifest files.

Oh, I didn't know this has behavior changes - any idea why?

I'm not 100% sure. I think it's possible that the FieldVector optimization could have changed the order of operations. I did compare some of the results of the jobs that caught behavior changes:

Diagnostic EDMFX AquaPlanet with TKE
aquaplanet (ρe_tot) equil allsky monin_obukhov varying insol gravity wave (raw_topo) high top zonally asymmetric
no lim held suarez (ρe) equilmoist hightop sponge

and it looks like it may just be precision changes.

FWIW, the other reproducibility tests passed, so I think precision changes is consistent with observing some tests pass and others fail like this.

Sounds good, thanks!


Add configuration files for coverage.py.

Coverage.py is a tool for measuring code coverage of Python programs.
https://coverage.readthedocs.io/en/coverage-4.3.4/

Right now BiblioPixel is at 57% coverage.  The script I checked in will
error if the coverage falls below that level.

I am managing to keep expressy at 100% coverage, though it's tricky.

The annotation # pragma: no cover omits a line or block out from this.

Nice, so this will run on travis? +1

Sorry for the delay on this!
Well, it could run on travis, but I don't really know how that works.
I think I'm going to push this, and then move all that code into setup.py
which will probably make it trivial to travis-ize.  Stay tuned!
On 26 January 2017 at 19:02, Dread<EMAIL_ADDRESS>wrote:

Nice, so this will run on travis? +1
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/pull/95#issuecomment-275462400,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPdsg5dA_wFo_40OIpcEYZRwUj_9UHqks5rWN-fgaJpZM4Lu1IG
.

--
/t
http://radio.swirly.com - art music radio 24/7 366/1000


Segmentation fault crash on OBS Studio 26.0.0

Adding 'Audio Writer' filter on a Mic/Aux device causes segmentation fault which leads to OBS exitting immediately after the crash message popup.
Reproduced using OBS Studio 26.0 x64 Portable:

Install Audio Writer Filter
Launch OBS with --portable or -p argument
In audio settings select the appropriate Desktop and Mic/Aux devices
Add 'Audio Writer' filter to the Desktop Audio device - No issues
Add 'Audio Writer' filter to the Mix/Aux device - Crash

System:
Windows 10 2004 19041.450 x64
Realtek Audio Driver <IP_ADDRESS>73
Built-in audio on Asus Prime Z270-A

Crash report
Log

Should be fixed in https://github.com/ujifgc/obs-audio-writer-filter/releases/tag/1.4


Command line is inconsistent:  --rpcport vs. --p2p-port

I'm thinking of writing a patch to accept the following hyphenated command line options in addition to their non-hyphenated counterparts:

--rpc-user
--rpc-password
--rpc-port
--httpd-endpoint
--http-port

I think we should prefer the hyphenated versions (e.g. not showing non-hyphenated versions in help).  I'm also thinking of printing a deprecation warning if non-hyphenated versions are used, but I think we need to continue to support non-hyphenated usage for backward compatibility with existing scripts at least until the next major upgrade.

Too low priority.


cannot import calc_crowding_distance

Hi.
Thanks for this great library.
I tried to run the multi-objective demo and I've encoutered this error:
cannot import "calc_crowding_distance" from "pymoo.algorithms.moo.nsga2"
I've installed pymoode using the instructions: pip install pymoode. I have pymoode==0.2.6 and pymoo==<IP_ADDRESS>.
Any ideas and tips on how to solve this issue?
Thank you for your time and help!

Thanks for pointing out this issue @bakachan19! Can you try it with pymoo==0.6.0? Recently pymoode RankAndCrowding was fully incorporated into pymoo and changed that import path.

@bakachan19 I just released a candidate version intended to be compatible with pymoo==<IP_ADDRESS>. Can you check if you can run it with pymoode==0.3.0.rc2 ?

Hi @bruscalia,
I apologize for the late reply. I was offline for holiday break.
I will try it and let you know.
Thank you!

Hi @bruscalia.
I installed pymoode==0.3.0.rc2 and I run the ZDT1 problem from the multi-objective tutorial. It runs.
For the previous version that I have installed (pymoode=0.2.6) I had to an import in order to make it run. In pymoode/survival/metrics.py I changed the import from this:
from pymoo.algorithms.moo.nsga2 import calc_crowding_distance as _calc_crowding_distance
to this:
from pymoo.operators.survival.rankd_and_crowding.metrics import calc_crowding_distance as _calc_crowding_distance
Thanks!
Have a nice day.

@bakachan19 I'm sorry my response to your comment wasn't sent! I had closed this with a comment last week but there might have been some connection error and the message never left.
Thank you very much for your contribution and for testing the new release!


Migrate from JUnit 4 to JUnit5

Spring Boot 2.4 brings JUnit5 only support. Our JUnit4 simply don't run anymore.
Blocks #259
Migration advisor https://yals.eu/fUquAt

Fixed by 1c8208e

Fixed by 1c8208e


Document device recommendation

The documentation currently states that there are "supported" and "not officially supported" GPUs for ROCm:
https://github.com/RadeonOpenCompute/ROCm#supported-gpus
As recently stated, there are a set of devices which are recommended for use with ROCm:

As complete support of ROCm works with gfx9 devices like Vega64, MI50(Vega 20), Radeon 7, recommend to use this type of card only.

Originally posted by @ROCmSupport in https://github.com/RadeonOpenCompute/ROCm/issues/1148#issuecomment-747849233
I suggest using this wording in the documentation, as it more closely conveys the distinction between such hardware, that might work ("supported") and such hardware, that should to work ("recommended").

Thanks @Bengt for reaching us.
Will reach Documentation team and marketing team for changes as you suggested.
Thank you.

Thanks @Bengt for reaching us.
Will reach Documentation team and marketing team for changes as you suggested.
Thank you.

Maybe you could add it to rocm-smi. Poor reporting, e.g. for Instinct Mi100
torel@n004:~$ /opt/rocm-4.0.0/bin/rocm-smi --showproductname
======================= ROCm System Management Interface =======================
================================= Product Info =================================
GPU[0]		: Card series: 		0x738c
GPU[0]		: Card model: 		0xc34
GPU[0]		: Card vendor: 		Advanced Micro Devices, Inc. [AMD/ATI]
GPU[0]		: Card SKU: 		D34314
============================= End of ROCm SMI Log ==============================
while on Radeon Pro VII
torel@n003:~$  /opt/rocm-4.0.0/bin/rocm-smi --showproductname
======================= ROCm System Management Interface =======================
================================= Product Info =================================
GPU[0]		: Card series: 		Vega 20
GPU[0]		: Card model: 		0x81e
GPU[0]		: Card vendor: 		Advanced Micro Devices, Inc. [AMD/ATI]
GPU[0]		: Card SKU: 		D16406
============================= End of ROCm SMI Log =============================
Maybe you could add here and to clinfo -v

Maybe you could add it to rocm-smi. Poor reporting, e.g. for Instinct Mi100
torel@n004:~$ /opt/rocm-4.0.0/bin/rocm-smi --showproductname
======================= ROCm System Management Interface =======================
================================= Product Info =================================
GPU[0]		: Card series: 		0x738c
GPU[0]		: Card model: 		0xc34
GPU[0]		: Card vendor: 		Advanced Micro Devices, Inc. [AMD/ATI]
GPU[0]		: Card SKU: 		D34314
============================= End of ROCm SMI Log ==============================
while on Radeon Pro VII
torel@n003:~$  /opt/rocm-4.0.0/bin/rocm-smi --showproductname
======================= ROCm System Management Interface =======================
================================= Product Info =================================
GPU[0]		: Card series: 		Vega 20
GPU[0]		: Card model: 		0x81e
GPU[0]		: Card vendor: 		Advanced Micro Devices, Inc. [AMD/ATI]
GPU[0]		: Card SKU: 		D16406
============================= End of ROCm SMI Log =============================
Maybe you could add here and to clinfo -v

@ROCmSupport I did the legwork and made it a pull request: https://github.com/RadeonOpenCompute/ROCm/pull/1352

@ROCmSupport I did the legwork and made it a pull request: https://github.com/RadeonOpenCompute/ROCm/pull/1352

@torehl I am no sure I get what you are suggesting. Do you want to see the marketing product name in the command line tools' output?

@torehl I am no sure I get what you are suggesting. Do you want to see the marketing product name in the command line tools' output?

Regarding the product information, we have an internal change coming to 4.1 or 4.2 to expose the proper Product Name for MI100 and other server cards. The issue is that we're currently using pci.ids and that's notoriously slow to update. For server cards, we'll be using the product information from the card itself, so we can get a bit more clarity for server cards. Unfortunately for consumer cards (like Radeon VII), we'll be stuck with whatever pci.ids has for us. Or we can try to integrate libdrm into the thunk and try to refer to that to get the information too.

Regarding the product information, we have an internal change coming to 4.1 or 4.2 to expose the proper Product Name for MI100 and other server cards. The issue is that we're currently using pci.ids and that's notoriously slow to update. For server cards, we'll be using the product information from the card itself, so we can get a bit more clarity for server cards. Unfortunately for consumer cards (like Radeon VII), we'll be stuck with whatever pci.ids has for us. Or we can try to integrate libdrm into the thunk and try to refer to that to get the information too.

There are two use cases to distinguish, here:

As a user in the market for a (new) GPU, I want to know which GPU to buy (next) for best ROCm support. For that use case, one needs to get the marketing names of recommended GPUs from the documentation.
As a user like @torehl, who already has a card, I want to know if it is supported by ROCm. For that use case, one needs a mention of the "card model"/"PCI-ID" in the documentation.

Note that the card SKU does not help at all. Currently, this is the only mention of "D34314" and "D16406" dramatic pause on the web:
https://www.google.com/search?q="D16406"+Radeon+OR+AMD
https://www.google.com/search?q="D34314"+Radeon+OR+AMD
So would the best solution to these problems be naming both the marketing and PCI-IDs in the documentation?
For my cards, ROCm-SMI displays the correct code name ("Vega 10 XL/XT"), marketing name ("Radeon RX Vega 56/64") and also a card SKU ("D05005"):
$ /opt/rocm-4.0.0/bin/rocm-smi --device 0 --showproductname

======================= ROCm System Management Interface =======================
================================= Product Info =================================
GPU[0]		: Card series: 		Vega 10 XL/XT [Radeon RX Vega 56/64]
GPU[0]		: Card model: 		RX Vega64
GPU[0]		: Card vendor: 		Advanced Micro Devices, Inc. [AMD/ATI]
GPU[0]		: Card SKU: 		D05005
================================================================================
============================= End of ROCm SMI Log ==============================

The card SKU can be googled with some sensible results like it's VBIOS entry at TechPowerUp:
https://www.google.com/search?q=D05005+radeon+OR+AMD

There are two use cases to distinguish, here:

As a user in the market for a (new) GPU, I want to know which GPU to buy (next) for best ROCm support. For that use case, one needs to get the marketing names of recommended GPUs from the documentation.
As a user like @torehl, who already has a card, I want to know if it is supported by ROCm. For that use case, one needs a mention of the "card model"/"PCI-ID" in the documentation.

Note that the card SKU does not help at all. Currently, this is the only mention of "D34314" and "D16406" dramatic pause on the web:
https://www.google.com/search?q="D16406"+Radeon+OR+AMD
https://www.google.com/search?q="D34314"+Radeon+OR+AMD
So would the best solution to these problems be naming both the marketing and PCI-IDs in the documentation?
For my cards, ROCm-SMI displays the correct code name ("Vega 10 XL/XT"), marketing name ("Radeon RX Vega 56/64") and also a card SKU ("D05005"):
$ /opt/rocm-4.0.0/bin/rocm-smi --device 0 --showproductname

======================= ROCm System Management Interface =======================
================================= Product Info =================================
GPU[0]		: Card series: 		Vega 10 XL/XT [Radeon RX Vega 56/64]
GPU[0]		: Card model: 		RX Vega64
GPU[0]		: Card vendor: 		Advanced Micro Devices, Inc. [AMD/ATI]
GPU[0]		: Card SKU: 		D05005
================================================================================
============================= End of ROCm SMI Log ==============================

The card SKU can be googled with some sensible results like it's VBIOS entry at TechPowerUp:
https://www.google.com/search?q=D05005+radeon+OR+AMD

@ROCmSupport I did the legwork and made it a pull request: #1352

Thanks @Bengt
Please modify the PR as suggested and update asap.

You are welcome, @ROCmSupport
I modified the PR as suggested.

Thanks @Bengt
Let me talk to Documentation team for merging this PR.

Thanks for carrying my changes further though the process.

Hi @Bengt, do you still need this ticket to be opened?  Please close it if the work has been completed.  Thanks.

Closing this ticket for now as no updates after PR https://github.com/ROCm/ROCm/pull/1352 has been closed.


change dynamic schedule set_schedule default persist

To improve the incompatible problem #633

@ceshihao Totally agree with this.  I believe this would be a breaking change with semantic versioning, so it would have to be included in v5.
There is some test failures from the default change, probably just simply need to set persist: false for this cases.


Locked at Nova 1.x, can't upgrade to Laravel 5.8, and Nova 2.0

As the title says, I need to upgrade to Laravel 5.8, which also means I have to move to Nova 2.0. Can we get an update here to allow installation of Nova 2.0?

Yes we can. Will take care of it tomorrow 👍

Please try again. I just created a new release.

@christophrumpel
I can't upgrade to Nova 2.0 after upgrade Laravel 5.8
this is a part of my composer

Laravel composer:
{
"require" : {
"laravel/nova": "*",
},
"minimum-stability": "dev",
"prefer-stable": true
}

Nova composer:
{
"extra": {
"branch-alias": {
"dev-master": "2.0.x-dev"
},
},
"minimum-stability": "dev",
"prefer-stable": true
}

Is this problem connected to my package?


Unicode address fields

Added new unicode enum formats for

street-address-unicode
street-address2-unicode
state-province-territory-unicode
city-name-unicode

Change not needed.  Using pattern in ShopperAddress instead


The process exit after profiling the CPU

I am using node 1.8.4
Is this normal?

It happens when I call profile.delete()

More info, this works:
  profile.export()
    .pipe(fs.createWriteStream(file_name))
    .on('finish', function () {
      profile.delete();
    })

while this exit the process:
  profile.export()
    .pipe(fs.createWriteStream(file_name))
    .on('finish', profile.delete)

@jfromaniello , thank you for info. I'll inspect this issue ASAP

My misstake in readme. Calling .on('finish', profile.delete) is incorrect.
I fix readme.


When will a web version of the designer come out?

Is your feature request related to a problem? Please describe.
When will a web version of the designer come out?
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here. For example, provide the execution platform you're operating on (Camunda Platform, Camunda Cloud, ...).

You can give camunda cloud a try, it is the web version of our tool.


flat-square broken for a long badge

Today I noticed that one of my badges on my repository is broken.
I get the following message:
This XML file does not appear to have any style information associated with it. The document tree is shown below.

Broken badge:
![Compatibility](https://img.shields.io/badge/Compatibility-Carthage%20%7C%20Swift%20Package%20Manager-0099ff.svg?style=flat-square)

VS. standard badge:
![Compatibility](https://img.shields.io/badge/Compatibility-Carthage%20%7C%20Swift%20Package%20Manager-0099ff.svg)

Any idea?

I just found a temporary workaround, but this is definitely bugged.
![Compatibility](https://img.shields.io/badge/Compatibility-Carthage%20%7C%20Swift%20Package%20Manager-0099ff.svg?maxAge=3600&style=flat-square)

It appears this has been fixed. If the problem is still observed, could you ping or reopen this thread?


add fixed point precision for printk functions

If a '.' is specified in the format string, then the argument is a fixed point number that should be printed with a radix character '.'
Add the ability to specify for example %.6lld as a long long expressed in micro units (e.g. micro seconds). The value of 1234567 would be printed as "123456.7"

This is quite different from the behavior of the standard printf function, where the . is used to add leading zeroes to integers.
printf("%.6lld", 1234567); results in 1234567 and
printf("%.8lld", 1234567); results in 01234567
When reading fixed-point numbers, I would also assume base 2 fractional format (sometimes call Q number format). This is also used in the CMSIS DSP library supported by Zephyr.
I would appreciate to be able to print fractional numbers with printk in general, but I guess this formatting could be confusing for some people (including me).

This is quite different from the behavior of the standard printf function, where the . is used to add leading zeroes to integers.
printf("%.6lld", 1234567); results in 1234567 and
printf("%.8lld", 1234567); results in 01234567
When reading fixed-point numbers, I would also assume base 2 fractional format (sometimes call Q number format). This is also used in the CMSIS DSP library supported by Zephyr.
I would appreciate to be able to print fractional numbers with printk in general, but I guess this formatting could be confusing for some people (including me).

@martinjaeger are you sure about this? I'm looking at https://pubs.opengroup.org/onlinepubs/009695399/functions/fprintf.html and it reads:

All forms of the fprintf() functions allow for the insertion of a language-dependent radix character in the output string. The radix character is defined in the program's locale (category LC_NUMERIC ). In the POSIX locale, or in a locale where the radix character is not defined, the radix character shall default to a period ( '.' ).

Are you using a locale where the radix character is something else? In any event I'm reviewing the spec and I don't see where it states the . is used to add leading zeroes to integers, maybe I missed it?

@andrewboie your output is exactly what I would expect from the spec, which states:

An optional precision that gives the minimum number of digits to appear for the d, i, o, u, x, and X conversion specifiers; the number of digits to appear after the radix character for the a, A, e, E, f, and F conversion specifiers; the maximum number of significant digits for the g and G conversion specifiers; or the maximum number of bytes to be printed from a string in the s [XSI] [Option Start]  and S [Option End]  conversion specifiers. The precision takes the form of a period ( '.' ) followed either by an asterisk ( '*' ), described below, or an optional decimal digit string, where a null digit string is treated as zero. If a precision appears with any other conversion specifier, the behavior is undefined.

Don't think the period used as a precision specifier in the format string is different depending on the locale setting. It's (hopefully) only the radix character in the output of the printf function.

I think most of this is stemming from making some code work that has our own non-standard printf extensions...
I will work with Jett to deprecate our printf extensions instead, I think.

Sorry for the delayed response. I shouldn't have uploaded this and then left on vacation.
It appears that I was indeed trying to replicate some non-standard behavior from another codebase. This definitely does not belong here. I am retracting this PR.
Thank you for looking at this, and sorry to waste your time.


Failed generator installs should not finish with confirmative log

Hey,
when you try install a generator and yo fails to install the generator (in my case because it needs to run the npm installs with sudo) it still gives you a confirmative log, which is contradictory.
npm ERR! Please try running this command again as root/Administrator.
...
npm ERR! ...
npm ERR! ...
npm ERR! not ok code 0

I just installed a generator by running:

    npm install -g generator-angular

This is happening on yo 1.3.3 Mac OS X.

@SBoudrias Looks like we need to improve post-close behavior in https://github.com/yeoman/yo/blob/master/lib/routes/install.js#L130 to correct this. I agree we should only display the installation success message when we 100% know there hasn't been a failure somewhere else in the pipeline.

@SBoudrias Looks like we need to improve post-close behavior in https://github.com/yeoman/yo/blob/master/lib/routes/install.js#L130 to correct this. I agree we should only display the installation success message when we 100% know there hasn't been a failure somewhere else in the pipeline.

Yeah. Also, maybe this should actually be fixed in yeoman-generator with a help/troubleshoot message if npmInstall fails.

Yeah. Also, maybe this should actually be fixed in yeoman-generator with a help/troubleshoot message if npmInstall fails.

Also, maybe this should actually be fixed in yeoman-generator with a help/troubleshoot message if npmInstall fails.

:+1:

:+1:


Add RPC support to linux lighting app

Problem
TE2 is planning to demo using RPCs for automated tests. This change adds some improvements to the lighting app to make that possible.
Summary of Changes

Cleanup the RPC proto files: cleanup naming, and break apart into multiple files so they can be reused in other applications.
Add RPCs required for TE2 test demo.
Add support for RPC in linux using a socket.
Add a lighting-app python tool which pre-bundles the proto files, but otherwise is identical to hdlc console example from Pigweed. It provides an interactive terminal for interacting with the device.

Currently this is just implemented for linux and EFR32 in the lighting app, I will work to update NRF platform next.
Fixes #5341

@rgoliver esp32 build fail?

@rgoliver Sorry, there appear to be conflicts now :(


onboardings: georeference

re: https://github.com/CartoDB/cartodb/issues/11316

acceptance

when builder onboarding is enabled AND georeference onboarding is enabled both will appear consequtively
when just georeference is enabled then it will appear
if none is enabled none will appear
if style onboarding is enabled it will suggest to style the map and georeference FROM the style panel
if layer has analyses OR has no rows it will suggest to style the map (if style onboarding is enabled) but the georeference button won't appear in the style panel
show the onboarding after import layer from map view
if there are any non georeferenced layer an infobox must appear in the layers list with the option to georeference and the name of the non georeferenced layer

try these, and the trickier cases you might think of

first draft, this needs some refactor and tests, but looking good so far

when builder onboarding is enabled AND georeference onboarding is enabled both will appear consequtively
when just georeference is enabled then it will appear
if none is enabled none will appear
if style onboarding is enabled it will suggest to style the map and georeference FROM the style panel

some pending stuff:

show the onboarding after import layer from map view
show the georeference style panel when adding an analysis (i.e. sample of 100%)

(I'm adding these instructions for acceptance in the PR description)

moved to a single use of queryRowsCollection with a statusModel, to check if it should be fetched, the problem now is the requests collide, so we'd better move the table view to the new queryRowsCollection
I'm moving on having the tableView initialize commented, but this is something to eventually tackle.
@xavijam has more info

Before anything, a 💯  job. I agree the constructor is a bit overkilled, these tests belong to requiredopts, and should be considered "duplicated". Nevertheless tests are always welcome :)

Let's not forget ⚠  button @matallo  💋 .

So, pending things before passing to acceptance:

[ ] Add ⚠  icon when a layer is not georeferenced or it doesn't have any data (cc @noguerol @saleiva).
[ ] Fix broken tests after new changes (ongoing).
[ ] Fix small things with the georeferencing onboarding template.

[ ] It appears in the whole page, but it should appear only on top of the map.
[ ] Title should be bold.

[ ] Check that georeference onboarding appears after adding a new row (moved note from surface @matallo 😛 ).

missing tests added, this can be tested in ded04 @noguerol

So, some things I found so far:

Infowindow doesn't make a direct reference to layer name

The style walkthrough should not pop up if layer is not georeferenced

When two non-georeferenced layers are added, only the top one in the list seems to trigger the walkthrough. The infowindow refers to "layer", in singular. We should list the non-georeferenced layer names both on a single walkthrough and infowindow notification.

<3

Infowindow doesn't make a direct reference to layer name

there seems to be something wrong, let me take a look at this, and come back to you for further info if I don't spot this

The style walkthrough should not pop up if layer is not georeferenced

in my opinion, out of the scope of this PR, also I suggested adding an "add geometry onboarding" instead

When two non-georeferenced layers are added, only the top one in the list seems to trigger the walkthrough.

I suppose you refer to infobox, "only the top one in the list seems to trigger the walkthrough" comes directly from the requirements and designs, once we work out the layer name issue I'd stick to it, but I would really reconsider listing all the layers

Hey @noguerol, if you don't mind, let's call that box as infobox 💋 .

Agree, let's make reference, no prob.
Uhm... I agree with @noguerol, @matallo. We should review that.
Yes, that's a design requirement as @matallo has pointed.

🙇 looking into it

and 2. addressed (and deployed to ded04 again for acceptance)

Ok, so after reviewing this with @CartoDB/design seems some behavior criteria was not clear enough, sorry for that.

Walkthroughs and infoboxes were designed for coming up only for the first non-georeferenced layer, as is the one preventing the user for visualizing data as a map. Other non-geo layers could be added afterwards for analysis purposes and there is no need to warn the user repeatedly, except for the layer icon and the buttons inside. In other words: Walkthrough and infobox should only pop-up for the first non georeferenced layer added in the map, and when dismissed they don't appear ever again. Layer warning icon and georeference buttons inside the layer still appear on every non-geo layer.

Infobox seems to not pop-up when opening a map with a non georeferenced layer that has not been dismissed before. They appear tho if you get inside the layer and back to the layers view.

Currently you cannot permanently dismiss infoboxes, as you close them and they pop-up again when returning to the layer view. User should be able to dismiss infoboxes permanently, same way that with the notification

Walkthroughs and infoboxes could only be dismissed per map, not as a general rule. Currently if you dismiss one of this walkthroughs in one map and create another map with a non-geo layer, the walkthrough will not appear. In other words, this onboarding is dismissable per map and not in a general basis as the rest of the onboardings.

So, forget everything about my last comment. In order to support every use case and in the sake of simplicity, this is what we're going to do:

Infoboxes will not pop-up in the layers view but inside the layer pane. Doing this we give support to analysis with non geo layers without bothering the users.

We get rid of the semitransparent onboarding layer. As radical as this may sound, showing a warning as an onboarding layer was both redundant with the infobox and counterproductive, as conflicts with the other parts of the onboarding in timing and behavior.

Thank you for your effort, buds!

It is :+1: @noguerol, but about 1, have you considered that there are other infoboxes inside the layer panels. For example, the visibility one.

What should be display before? Should we display both?

It doesn't make any point to show the invisible layer notification with a non-geo layer, right?

Agree, but you can hide it in any case 💃 . So, layer without geometry infobox has preference over rest 👍 .

What im saying is we should never show the invisible layer warning in non-geo layers? I better open a ticket for this?

But the option is there, that's another thing. But my question is about more related with the possibility to have several infoboxes in the same context. Is it possible show more than one?

Not imo. We'll solve that if we meet a use case that needs it.

reverted the points above as to the new specifications, but I think this needs some proper thought:

warning in style, popups, and legends is redundant: two georeference actions and almost the same content.
warning in analysis makes no sense at all, if I click on the georeference action elsewhere, as it detects it can be georeferenced the warnign appears even if I'm at the georeference step

find the captures below

You're completely right, my friend. While the infobox is redundant in the geo tabs: style, pop-up and legends, is still needed in the non-necessarily-geo ones: data and analysis. On the analysis one I would make the infobox disappear when adding an analysis: if its the geocoder, the warning is no longer needed and if its a non-geo one, its most probable that the layer is about to be used for different purposes.

working as expected, and fixed tests, stumbled upon a bug that is currently occuring https://github.com/CartoDB/cartodb/issues/11759

sorry to raise this again, but I really really think we should consider hidden infobox taking preference over georeference infobox
(I know it makes no sense to show hidden layer notification with a non-geo layer, but let me explain my point)
I tried showing the georeference infobox, indeed. And then when trying edge cases you still can make the layer hidden through the context menu, so you end up with a non-georeference, hidden layer.
If you go to the analyses tab, and click the georeference action you end up in the next screen (see attached).

functionally it can be correct (it will work), but in terms of form I don't see it is correct, because we are showing the infobox below the actions, as opposed to other panels (see attached) where the infobox is on top of the actions.

this is due to how the analyses panel is coded in the panelswithoptionsview, with the controlview inside the contentview https://github.com/CartoDB/cartodb/blob/master/lib/assets/core/javascripts/cartodb3/editor/layers/layer-content-views/analyses/analyses-view.js#L77-L97 as opposed to the controlview outside the contentview https://github.com/CartoDB/cartodb/blob/master/lib/assets/core/javascripts/cartodb3/editor/layers/layer-content-views/data/data-view.js#L344-L366
furthermore this brought some further points to take into account, that infobox which lives in the analyses actions menu has its own infobox that deals with quotas, so we can end up with quotas infobox properly on top of the analyses actions, and a hidden layer infobox below the actions, weird.
thus my proposal: in any case, show hidden layer infobox and discard it to be able to unlock further steps. This is working in ded01.
let's get together and discuss this for 5 minutes before making any further decisions

@noguerol ^^^

+1 @matallo

Two things:

we should show the georeference message and button in the geo-tabs (style, popup and legends) regardless there is an analysis node or not in the chain (not including georreference, of course)
Style onboarding pop-ups even when a non-geo analysis is chained in a non-geo layer and you go to the geo-tabs

Easy change 💋