Kerbal Space Program 2 (KSP2) has few fps and consumes all VRAM (8 GB)

Problem description
I got just around 7 fps when launching a minimal rocket (pod, fuel tank and engine) with low graphics settings. Changing the graphics settings doesn't influence the fps at all (also 7 fps with high settings).
radeon-profile shows 100 % GPU and 100 % GPU RAM (8 GB) usage. Minimum requirement is 6 GB.
Other people seem to have similar issues running Kerbal Space Program 2.
https://www.reddit.com/r/KerbalSpaceProgram/comments/10sq0qv/comment/j9va7pe/
https://github.com/ValveSoftware/Proton/issues/6565#issuecomment-1444281791
When using WINED3D (when using Proton by setting PROTON_USE_WINED3D=1 I easily get > 25 fps. And with WINED3D the GPU VRAM is between 70% and 90% usage (8 GB).
VRAM usage measured with radeon-profile
Minimum requirement is 6 GB
Unfortunately WINED3D has some graphic bugs. The rocket and buildings look fine. But far away terrain is not rendered (see here and wine bugreport).

Software information
Game: (Kerbal Space Program 2 (KSP2) via Steam](https://store.steampowered.com/app/954850/Kerbal_Space_Program_2/)
Early Access / Beta 2023-02-24, Steam Build ID 10624168
Downloaded the game via Steam, tested it with Proton but also with standalone Wine.

System information

GPU: Radeon RX 590 (8GB VRAM)
Driver: amdgpu
Wine version: wine-devel-8.2 (also tested wine-7.0 and Proton-Experimental 2023-02-24)
DXVK version: 2.1 (also tested 1.9.1)
CPU: Ryzen 7 5800X (32 GB memory)
OS: Debian GNU/Linux 11 (bullseye, standard Debian 11 Kernel 5.10)

Debian-11 has only vulkan-1.2. So I compiled vulkan-1.3.238 and mesa-22.2.4 myself.

Apitrace file(s)
Did not work. Game crashed immediatly.

backtrace.txt
KSP2_x64.trace.zip

Bye the way:
The instructions in https://github.com/doitsujin/dxvk/wiki/Using-Apitrace have issues. There is no folder apitrace-msvc in the 64 bit 7z archive.

Log files

d3d11.log: KSP2_x64_d3d11.log
dxgi.log: KSP2_x64_dxgi.log

Additional info
See also:

https://github.com/ValveSoftware/Proton/issues/6565

Trace
https://mega.nz/file/cgATUZCL#bGgc95nd2b3pq0YUt5ie-yYqabE43Aw_WKBw5vMuxNs

There's nothing we can do if the game just uses a ridiculous amount of VRAM. Windows has better memory management for discrete GPUs so that might save the day there.

Does it help to set dxgi.maxDeviceMemory in dxvk.conf just around 2-3 GB below your actual VRAM? Or in other words, subtract the amount of VRAM already allocated by the desktop (plus some extra buffer) from the amount of VRAM offered to the game...

Shouldn't change anything

Does it help to set dxgi.maxDeviceMemory in dxvk.conf just around 2-3 GB below your actual VRAM? [...]

@kakra
No. Actually cat /sys/class/drm/card0/device/gpu_busy_percent, radeon-profile and DXVK_HUD=memory still show my full 8 GB of VRAM being used.
Or maybe I'm doing something wrong using dxvk.conf?
I am running wine with DXVK_CONFIG_FILE=/path/to/dxvk.conf and dxvk.conf contains a single line dxgi.maxDeviceMemory = 6144.

DXVK_HUD=memory output:

Vidmem heap 0: 9141 MB (115%)  8749 MB used
Sysmem heap 1:  384 MB (4%)  16 MB used
Vidmem heap 2:   48 MB (18%)  20 MB used
glxinfo shows exactly Video memory: 8192MB.

Or maybe I'm doing something wrong using dxvk.conf?

Since Proton runs inside of bwrap, put the dxvk.conf inside the folder of the game exe without setting an environment variable. Games are isolated from your system by running inside bwrap and can only access the graphics driver, your wine prefix, and the Steam library.
At least this works for me using NVIDIA (and other games). It looks like some games rely on Windows behavior of swapping GPU memory out which DXVK cannot do instead of limiting themselves to what is actually available, so reducing the VRAM offered by the amount occupied by your desktop can help, I'd add a few 100 extra MB to account for chunk slack generated by the DXVK memory allocator.

It doesn't change how much the application can use. Only the reported amount.

It doesn't change how much the application can use. Only the reported amount.

Then we should find out why it reproducible fixes performance problems for me in Elite Dangerous and Jedi Fallen Order (and maybe some other games I do not remember currently) when otherwise the fps falls below 10fps after extended playing or going to menu screens - which usually happens when the game VRAM allocation exceeds the actual available VRAM.

Then we should find out why it reproducible fixes performance problems for me in Elite Dangerous and Jedi Fallen Order

The games probably base their texture streaming pool size upon what D3D11 reports.

There's nothing we can do if the game just uses a ridiculous amount of VRAM. Windows has better memory management for discrete GPUs so that might save the day there.

I understand this would be a big lift, but are there other efforts or ideas in this project to make the memory management system more on par with directx?

The games probably base their texture streaming pool size upon what D3D11 reports.

Yes, probably, and that works for the games in Windows - but it doesn't in Linux with DXVK. Some games usually over-allocate VRAM by around the amount of VRAM allocated to the desktop. So they rely on behavior in Windows that's not available in Windows, and DXVK probably needs to account for that. Either by a per-game quirk or some heuristics.
That said, my work-around isn't 100% bullet proof. Games can still over-allocate VRAM, with allocations ending up in sysmem, and then I'm seeing PCI bus utilization spike while at the same time fps drops. So we'd probably need something better directly integrated into DXVK other then artificially telling the game that my GPU has less memory. As far as I know, Windows reserves up to 512MB to the desktop compositor, and is able to swap out or somehow otherwise remove allocations from VRAM that are not currently in use (the NVIDIA Linux driver does something similar to idle OpenGL allocation by simply invalidating them after some 30 or 60 minutes, which helps a lot with web browser rending surface idling in the background). This probably needs deep driver/kernel/user-space integration and thus cannot be done in Linux. So what are the alternatives, even with DirectX "emulation" not being 100% correct in its implementation when reporting memory?

Then we should find out why it reproducible fixes performance problems for me in Elite Dangerous and Jedi Fallen Order

Interesting :eyes:

I'm guess basically there are no memory location side effects in DXVK after a draw call if assets are residing in system memory? Something like the asset gets copied over, processed, and then thrown away; and then that repeats the next frame, and the next. No eviction policy for unused assets?
We could probably be doing something a bit smarter here, no?

Does it help to set dxgi.maxDeviceMemory in dxvk.conf just around 2-3 GB below your actual VRAM? Or in other words, subtract the amount of VRAM already allocated by the desktop (plus some extra buffer) from the amount of VRAM offered to the game...

Most games seem to completely ignore these settings, for example if I set it to 4096 some games would still see 10240.

Most games seem to completely ignore these settings, for example if I set it to 4096 some games would still see 10240.

I've never seen that... Are you sure that DXVK was able to read the config file? Pointing DXVK to a location via environment variable may not work due to bwrap isolation, placing the config side by side with the exe file should work. Also, external tools may not be able to properly monitor DXVK memory usage because the DXVK chunk allocator tends to keep allocations in memory and re-purpose them for the game, thus only DXVK itself can properly show the real memory usage, for outside tools it always looks like almost 100% is used (since some versions, DXVK can actually free chunks again, so also external view of allocations may decrease again).

@kakra @sfjuocekr
I verified dxvk.conf is being loaded by additionally setting dxvk.hud. Just putting the file into the game's EXE directory didn't work. But specifying via DXVK_CONFIG_FILE worked. See updated https://github.com/doitsujin/dxvk/issues/3268#issuecomment-1445124749 for details.

@kakra @sfjuocekr I verified dxvk.conf is being loaded by additionally setting dxvk.hud. Just putting the file into the game's EXE directory didn't work. But specifying via DXVK_CONFIG_FILE worked. See updated #3268 (comment) for details.

I had to DLLOVERRIDE nvapi and nvapi64 for it to accept the max memory set, I guess games can query nvapi for memory? I set maxDeviceMemory to 4096 to have a playable 30ish FPS experience on a 3080FE (10Gb).
The game simply seems to NEED to allocate 8Gb of VRAM, but if I let it do that it crushes the frame rate because in-fact VRAM is completely filled up.
I assume this is because DXVK reports only the size of the maximum memory available and not the VRAM already claimed by other applications(browser, discord, you name it)?
For Star Citizen I also set it to 6144 to keep it playable for an extended amount of time, but eventually the magical 9,8Gb barrier is reached and bam... 1FPS. While the game itself states it only used up 5,5Gb so there was no reason to free anything from the game's point of view?

I had to DLLOVERRIDE nvapi and nvapi64 for it to accept the max memory set

@sfjuocekr Interesting!
Here someone else with a NVidia GPU is also reporting, that PROTON_HIDE_NVIDIA_GPU=1 (additional with PROTON_NO_ESYNC=1) makes the game run smooth if he uses PROTON_USE_WINED3D=1. And I guess  PROTON_HIDE_NVIDIA_GPU=1 is similar to using WINEDLLOVERRIDES=nvapi,nvapi64=b.
Sadly that doesn't seem to help my with my AMD GPU (Radeon RX 590 8 GB). Which is strange, because games running on NVidia GPUs with PROTON_HIDE_NVIDIA_GPU=1 set should behave like running on AMD GPUs. On the other hand at least you (@sfjuocekr) have 10 GB VRAM which is +2 GB more VRAM than my 8 GB VRAM.

@kakra @sfjuocekr I verified dxvk.conf is being loaded by additionally setting dxvk.hud. Just putting the file into the game's EXE directory didn't work. But specifying via DXVK_CONFIG_FILE worked. See updated #3268 (comment) for details.

I had to DLLOVERRIDE nvapi and nvapi64 for it to accept the max memory set, I guess games can query nvapi for memory? I set maxDeviceMemory to 4096 to have a playable 30ish FPS experience on a 3080FE (10Gb).
The game simply seems to NEED to allocate 8Gb of VRAM, but if I let it do that it crushes the frame rate because in-fact VRAM is completely filled up.
I assume this is because DXVK reports only the size of the maximum memory available and not the VRAM already claimed by other applications(browser, discord, you name it)?
For Star Citizen I also set it to 6144 to keep it playable for an extended amount of time, but eventually the magical 9,8Gb barrier is reached and bam... 1FPS. While the game itself states it only used up 5,5Gb so there was no reason to free anything from the game's point of view?

Hi @sfjuocekr I think you are correct with your analyzes. VRAM size can indeed be queried from nvapi and DXVK-NVAPI does not looks at DXVK memory configuration, thus the full VRAM size is reported. I have a branch here https://github.com/jp7677/dxvk-nvapi/pull/110 that just reports the same memory size that DXVK reports, thus it now honors DXVK memory overrides. Does this fixes your issue even with nvapi being enabled?

Hi @sfjuocekr I think you are correct with your analyzes. VRAM size can indeed be queried from nvapi and DXVK-NVAPI does not look at DXVK memory configuration, thus the full VRAM size is reported. I have a branch here jp7677/dxvk-nvapi#110 that just reports the same memory size that DXVK reports, thus it now honors DXVK memory overrides. Does this fixes your issue even with nvapi being enabled? You can pick binaries from GitHub actions.

I have tried your nvapi.dll from your branch and it doesn't change anything :( KSP2 still consumes all VRAM.

I have tried your nvapi.dll from your branch and it doesn't change anything :( KSP2 still consumes all VRAM.

Same here, do you know how to be sure that nvapi is loaded ?

@JavaSaBr  / @Idix  Did you both tried it together with the memory override setting that @ kakra  described (dxgi.maxDeviceMemory in dxvk.conf)?  You can set DXVK_NVAPI_LOG_LEVEL  to info to get console output from dxvk-nvapi.

Hi @Idix no worries. Unfortunately I cannot help much with Lutris since I'm not that familiar with it. What I know is:

DXVK and friends (VKD3D-Proton, DXVK-NVAPI) are out of date in Lutris, so you need to update those components manually, I think by manually copying new versions into a separate folder in the component directory and selecting the new folder names as version.
NVAPI needs to be enabled separately
Wine-GE sounds fine
Unfortunately no idea how to pass environment variable in Lutris nor how to see console logs.

Thanks alot @jp7677.
I've updated DXVK, KD3D-Proton and DXVK-NVAPI and I've got good news and bad news.
The good news is that KSP2 is now at 60fps and actually playable!
The bad news is your branch has nothing to do with it and the parameter dxgi.maxDeviceMemory = 6144 has no impact.

I assume this is because DXVK reports only the size of the maximum memory available and not the VRAM already claimed by other applications(browser, discord, you name it)?

I'm not sure... I think, DXVK sees what is already in use, and can also report that to games. But the chunk allocator leaves some unused slack space behind, allocated to the GPU driver, but reported as free to the game.

@sfjuocekr did you found a minute to try this with the dxvk-nvapi branch (https://github.com/jp7677/dxvk-nvapi/pull/110)?

@jp7677 I think I have configured it correctly :) but I will test your new branch as well today...

@sfjuocekr did you found a minute to try this with the dxvk-nvapi branch (jp7677/dxvk-nvapi#110)?

Yes, with nvapi enabled dxvk-nvapi now honors dxgi.maxDeviceMemory.

@sfjuocekr how have you configured it? It didn't work for me :(

@sfjuocekr how have you configured it? It didn't work for me :(

Working as in nvapi now reports whatever is set in dxgi.maxDeviceMemory, this does not mean anything on the KSP side is automagically fixed.
There is simply no way around the game allocating 8Gb of VRAM, it just does that regardless of what dxgi.maxDeviceMemory is set to. Strangely enough setting it to 6Gb results in a slightly more playable experience, but the game has more issues than just its VRAM usage. For example loading between scenes changes the performance of the game, sometimes when you load the VAB it sits at 60FPS no problem and other times when you load the VAB it sits at 10FPS.
So there is no magical fix we as the end-user can apply to fix this, the game is also build without Vulkan support in Unity. So you can't even try to -force-vulkan to run it that way.

@sfjuocekr did you found a minute to try this with the dxvk-nvapi branch (jp7677/dxvk-nvapi#110)?

Yes, with nvapi enabled dxvk-nvapi now honors dxgi.maxDeviceMemory.

Thanks for the confirmation. I've merged the PR. Regardless the state of KSP2, it is a good idea anyway to keep memory reporting synchronized with DXVK.

@jp7677
So why is this not working with AMD Radeon GPUs? (amdgpu driver)
There's nothing like an nvapi.dll for Radeon, correct?
I tried this without any effect in KSP2 (Radeon RX 590 8GB):
dxgi.maxDeviceMemory = 6144
dxgi.maxSharedMemory = 1024

I use the command in Steam:
PROTON_ENABLE_NVAPI=1 PROTON_LOG=1 PROTON_HIDE_NVIDIA_GPU=0 DXVK_NVAPI_LOG_LEVEL=info DXVK_NVAPI_LOG_PATH=/home/javasabr/dxvk-nvapi.log DXVK_CONFIG_FILE=/home/javasabr/dxvk.conf %command%
And I don't see any log file from nvapi :(

I use the command in Steam: PROTON_ENABLE_NVAPI=1 PROTON_LOG=1 PROTON_HIDE_NVIDIA_GPU=0 DXVK_NVAPI_LOG_LEVEL=info DXVK_NVAPI_LOG_PATH=/home/javasabr/dxvk-nvapi.log DXVK_CONFIG_FILE=/home/javasabr/dxvk.conf %command%
And I don't see any log file from nvapi :(
DXVK: v2.1
Proton:<PHONE_NUMBER> GE-Proton7-49
SteamGameId:<PHONE_NUMBER>3638396928
Command: ['/home/javasabr/Soft/SteamLibrary/steamapps/common/Kerbal Space Program 2/KSP2_x64.exe']
Options: {'enablenvapi', 'forcelgadd'}

DXVK_NVAPI_LOG_PATH is a path (see https://github.com/jp7677/dxvk-nvapi#tweaks-debugging-and-troubleshooting), what happens if set it to /home/javasabr/?

@jp7677 So why is this not working with AMD Radeon GPUs? (amdgpu driver) There's nothing like an nvapi.dll for Radeon, correct?
I tried this without any effect in KSP2 (Radeon RX 590 8GB):
dxgi.maxDeviceMemory = 6144
dxgi.maxSharedMemory = 1024

Yes, correct, nvapi64.dll is NVIDIA's vendor library. Game usually don't try to load nvapi when seeing a non-NVIDIA GPU. Sorry, no idea whats actually going on with KSP2.

I took me a lot of time but now I'm pretty sure KSP2 doesn't load nvapi and I have a Nvidia graphic card.
I've run it with WINEDEBUG=+loaddll and I can't see any reference to nvapi.dll. I see dxgi.dll and d3d11.dll alright but nothing else related to dxvk

@jp7677 So why is this not working with AMD Radeon GPUs? (amdgpu driver) There's nothing like an nvapi.dll for Radeon, correct?
I tried this without any effect in KSP2 (Radeon RX 590 8GB):
dxgi.maxDeviceMemory = 6144
dxgi.maxSharedMemory = 1024

Yes, correct, nvapi64.dll is NVIDIA's vendor library. Games usually don't try to load nvapi when seeing a non-NVIDIA GPU. Sorry, no idea whats actually going on with KSP2.

There is nothing going on with KSP2, this was just an observation I made because I have experience with a whole scala of other games.
KSP2 currently even runs potato on Windows machines, just checking the Steam Discussions will tell you exactly this. There is nothing we can do to "solve" the unsolvable.
I tested the dxvk-nvapi in other games where I knew they reported more VRAM than I had dictated through dxgi.maxDeviceMemory, so again this was just an observation I had made from my experiences with other titles.

Some user found that the game has an argument -screen-quality Fastest that helps a ton. The launch options eval $(echo "mangohud %command%" | sed "s/PDLauncher\/LauncherPatcher.exe'.*/KSP2_x64.exe'/" ) -screen-quality Fastest help incredibly on my machine, plenty playable on 8GB of VRAM.

Some user found that the game has an argument -screen-quality Fastest that helps a ton. The launch options eval $(echo "mangohud %command%" | sed "s/PDLauncher\/LauncherPatcher.exe'.*/KSP2_x64.exe'/" ) -screen-quality Fastest help incredibly on my machine, plenty playable on 8GB of VRAM.

I tried with "Very Low" and "Low" without any impact: https://docs.unity3d.com/Manual/class-QualitySettings.html
But maybe they changed the names, I'll give it a swirl!

Yea it appears to be a custom quality preset. The finder compiled this list of present options.
https://docs.google.com/spreadsheets/d/1bwuYTLDYO_zizYgmRXmF_YxHlxFHNQGlNzCBpfMeYxw/edit?usp=sharing

It seems to help to some extend, as soon as I launch my rocket the frame rate is once more crushed to unplayable :D

It still required me dropping the resolution to 540p, and graphics to low. But before the flag even that was unplayable for me.

One trick I found is to save and exit to main menu then load back the game. I suppose it unloads everything and load back only the textures that are necessary.

This can't be just a linux vs. Windows optimisation thing. On Windows, people get KSP 2 running with 4GB graphics cards, even being able to improve performance further e.g. https://steamcommunity.com/app/954850/discussions/0/3772365358794512131/

All those steps are of no consequence to the game, the game is never GPU bound.
There are a few reasons the game runs the way it does and none of those are at fault of the GPU or the OS.

I've put in about 130 hours in KSP on Linux and the experience on Windows is exactly the same... until VRAM is exhausted. KSP really likes to crumble over delta V calculations (that should be yielded) if you use fuel lines or multiple engines.

One trick I found is to save and exit to main menu then load back the save. I suppose it unloads everything and load back only the textures that are necessary.

Sorry to jump in with a different game, but "Pharaoh: A New Era" (Steam ID 1351080) behaves the same. I don not want to sidetrack this discussion. I only want to add additional information.
Loading a mission yields very bad performance, about 16 fps. Zooming out means more terrain is shown and fps drop down to 6. Reloading the mission fixes performance: 100+ fps. Interestingly enough, moving the viewport over water increases performance, while solid ground decreases performance (maybe water is one big underground layer and ground is handled as dozens of single tiles on top of it?). My GPU has 4 GB of VRAM and according to DXVK HUD the game  allocates 2.7 GB VRAM in main menu and 4.4+ GB during a mission (even after hitting reload). Changing dxgi.maxDeviceMemory does not help. Game runs better with PROTON_USE_WINED3D=1, but it's not as smooth as DXVK after reloading (WINED3D has slight stuttering).
System Information

CPU: Intel Core i7-4770
RAM: 16 GB DDR3-1600
GPU: Radeon R9 290X (4GB VRAM)
OS: Arch Linux (updated March 3rd, 2023)
Driver: amdgpu with radv (amdvlk won't run)
Mesa version: 22.3.6
Proton version: Proton 7.0-6, Proton Experimental, Proton-GE-Custom
DXVK version: 2.1.0/1.3.230, 1.10.3/1.3.230

Every game that runs out of vram will behave the same.

Every game that runs out of vram will behave the same.

Unqualified comment is unqualified. How come both (well, at least Pharaoh) run fine for hours after hitting reload? Anyways, I wanted to add additional information. I can't tell if it's helpful or not, as I'm not a DXVK developer. Only  involved developers and testers can confirm. Maybe it's something with those games engines, maybe it's DXVK, dunno.
Please keep in mind, that 1 GB of VRAM is the minimum requirement for Pharaoh. I'm pretty sure it doesn't run out of VRAM with 4 GB available. Except there is a HUGE leak somewhere.

Mbriar is right. Please open a new issue for that game instead of hijacking an existing one.

How come both (well, at least Pharaoh) run fine for hours after hitting reload?

The game probably recreates performance critical resources like render targets and they end up in VRAM when you reload.

Please keep in mind that 1 GB of VRAM is the minimum requirement for Pharaoh

System requirements are notoriously unreliable and they are for running the game on Windows. Windows has much better GPU memory management and will work hard to avoid the performance cliff that DXVK hits.

Except there is a HUGE leak somewhere.

There isn't.

VRAM management have now received some big improvements in dxvk 2.5+


Ensure consistent date width and sortability.

This changes the canonical date format from ~2019.1.1 to ~2019.01.01, in order to benefit alignment, sorting, and my personal sanity.
(Should've done this earlier, but rather late than never!)
To accomplish this, we make a couple of adjacent changes/additions to parsers:

stun is updated to support ranges without upper bound. [2 0] parses two or more times.
This kind of makes me want to rewrite star (and plus) as cury'd calls to stun, but star is jetted while stun isn't, and there might be other performance concerns there too.
diz is added to parse between [min max] digits and turn them into an atom.
fit is added to parse only atoms between [min max] value.
Should either or both of these go into the ag core instead?
Finally, dip and mot are updated to parse [1 2] digits with leading zeroes, and the @da printer always prints two digits for months and days.

Note that this still supports parsing the old ~2019.1.1 format, to ensure backwards compatibility with existing code. I think we'll want to phase that out, but please advise.
It also maintains the peculiar behavior that ~2019.01.32 is counted as valid notation to mean ~2019.02.01. Even ~2019.01.366 is valid for ~2020.01.01. What's the reason this is parsed as valid? I'm thinking we should maybe take that out, and accept only [1 31] for days (which would still exhibit similar behavior on months with less than 31 days, but at least feels more sane).
Explicitly tagging @benjamin-tlon and @pilfer-pandex for review, since I'm pretty sure those are the people to ask about language-level changes these days. Of course, any passer-by is welcome to leave a comment or review on this!

Huh. So ~1993.09.9295 currently parses correctly. Didn't know that.

Probably a good idea to pad the year out to 4 digits, remove the BC syntax,
and disallow years >9999? I think this even lets you drop the timestamp
under 64 bits, which makes jets a lot easier to write
On Sunday, 10 February 2019, Fang<EMAIL_ADDRESS>wrote:

This changes the canonical date format from ~2019.1.1 to ~2019.01.01, in
order to benefit alignment, sorting, and my personal sanity.
(Should've done this earlier, but rather late than never!)
To accomplish this, we make a couple of adjacent changes/additions to
parsers:

stun is updated to support ranges without upper bound. [2 0] parses
two or more times.
This kind of makes me want to rewrite star (and plus) as cury'd calls
to stun, but star is jetted while stun isn't, and there might be other
performance concerns there too.
diz is added to parse between [min max] digits and turn them into an
atom.
fit is added to parse only atoms between [min max] value.
Should either or both of these go into the ag core instead?
Finally, dip and mot are updated to parse [1 2] digits with
leading zeroes, and the @da printer always prints two digits for
months and days.

Note that this still supports parsing the old ~2019.1.1 format, to ensure
backwards compatibility with existing code. I think we'll want to phase
that out, but please advise.
It also maintains the peculiar behavior that ~2019.01.32 is counted as
valid notation to mean ~2019.02.01. Even ~2019.01.366 is valid for
~2020.01.01. What's the reason this is parsed as valid? I'm thinking we
should maybe take that out, and accept only [1 31] for days (which would
still exhibit similar behavior on months with less than 31 days, but at
least feels more sane).
Explicitly tagging @benjamin-tlon https://github.com/benjamin-tlon and
@klaperman https://github.com/klaperman(?) for review (though the
latter isn't in our Github team yet), since I'm pretty sure those are the
people to ask about language-level changes these days. Of course, any
passer-by is welcome to leave a comment or review on this!
You can view, comment on, or merge this pull request online at:
https://github.com/urbit/arvo/pull/1065
Commit Summary

Update ++stun to support "at least x times" case
Add ++diz and ++fit simple atom parsers
Ensure consistent printed date width
Make ford tests expect new date format

File Changes

M sys/hoon.hoon
https://github.com/urbit/arvo/pull/1065/files#diff-0 (29)
M tests/sys/vane/ford.hoon
https://github.com/urbit/arvo/pull/1065/files#diff-1 (894)

Patch Links:

https://github.com/urbit/arvo/pull/1065.patch
https://github.com/urbit/arvo/pull/1065.diff

—
You are receiving this because you are subscribed to this thread.
 But we've already seen the @da format being used in strings and names of many different kinds, even outside of Arvo, and atom values won't save you there.

I'm always ready to jump in an pontificate with Very Strong Feelings about things I'm unqualified to talk about so here I go.
I've spent a lot of time as a Basic Web Dev, having to fight with datetimes. Datetimes are a Hard Problem to deal with for a huge number of reasons, not limited to daylight savings, changing timezones, etc. Now much of this problem is eliminated when simply discussing dates  but it's helpful if the formats are consistent. So I'm firmly in @Fang- 's camp here and leading zeros simplify at least some of the horror that is dealing with dates.

even outside of Arvo

I think this is really the crux of the issue: People like to name their unix files starting with Urbit dates, which then doesn't sort by string well. Inside Arvo, this isn't really a problem because we can sort by number -- especially once we switch path to (list dime).
Frankly I don't like the convention of starting the filename with a date. MacOS tracks date of creation, last modified date, etc. So does google docs. Why are we replicating this piece of metadata manually? And why this particular piece of metadata? Why not, say, the author?
I suspect the answer is it's faux dogfooding and marginally useful for some kind of task tracking. It's not real dogfooding, though. Not to mention it makes tabs unreadable. I have three Google docs tabs open right now, and all I can see of their titles is ~2019.
But more importantly, Urbit atom printing formats should be designed to provide a clean, smooth user experience for our fledgling computing world. Using an Urbit date serialization scheme to pave over idiosyncrasies in legacy filesystem metadata management systems is wrong and not Martian and we shouldn't do it. Let Unix solve Unix's problems. We have plenty of our own.
Even sorting by stringified date is un-Martian, wherever we're doing it. Structured data, man! We have a type system.

Since you asked for my .02, here goes:

Honestly, I think ~2019.1.1 looks better on the eye than ~2019.01.01. Even if we make the latter canonical, I'd push for still accepting the former. It would be cool if we could have a sorting function for strings that sorted numbers contained within properly, such that "foobar 21 baz" < "foobar 100 baz". Alignment remains an issue though.
~2019.1.297 should not be admitted. On the other hand, perhaps we want a syntax for day-of-year? If we do, that syntax could be ~2019..297.
Timezones are atrocious. Urbit should not support timezones except at the most superficial UI level.
Strongly disagree with @ohAitch's proposal to bar dates >9999. Don't know what the syntax for BC years is, but we should support representing them (feel less strongly about this than >9999), using negative numbers and the proleptic gregorian calendar. So for example 2 BC is ~-1. (The morons who designed the calendar system did not include a year zero.)

 :D
Why does Urbit need a format for date? From a OS perspective a counter like unix time (num of seconds, maybe with higher precision) is simple and beautiful. Any formatting of it belongs to UX, where it might get timezoned, localized, etc anyway.
If some rudimentary formatting is necessary for human operators, maybe it just ... shouldn't really be calendar date. Maybe it could be just something like "2.23y" or "705.23d" or "23848324.23s"  (implied: from Urbit epoch which is the time when the current network was bootstrapped or some arbitary point of time: Unix epoch, or Urbit epoch). The aura (or whatever it is called) would decide what is the requested precision of the date when printing for human to see (years, months, weeks, days, hours, minutes, seconds), etc.
Calendar dates ... are just a lot of problems, introduced in a layer that potentially doesn't really need it.
Anyway, just my 2sat.

All fair points @belisarius222, and I strongly agree we shouldn't try to fix Unix-level junk that isn't in Arvo in any way.
Of course, nothing is stopping anybody from still using dates in filenames, titles, etc. Not necessarily on their own, but interpolated into some string. You're right that there are many better ways to attach dates to whatever it is that's being named.
Even then though, the current format is still aesthetically unpleasant.  The aesthetics are really the biggest issue I'm hoping to fix here. Changing days and months to consistently be two digits wide is a massive boon to visual consistency. Not just with themselves and each other, but with the time notation also.

Timezones are atrocious. Urbit should not support timezones

UTC Maximalism. +1!
And I, too, agree that ~2019.12.3456 is weird and unreasonable and probably needs to go. "Day of year" sounds vaguely nice, but I don't see a compelling reason to actually put that in.

Why does Urbit need a format for date?

@dpc Getting people to learn a new programming language is one thing. Getting people to adopt a new calendar (if even something that useful) is... harder.
Detailed time rendering (read: timezones) should indeed be implemented on the UI level (though I bet some madman is gonna write a hoon library for it), but sticking to a well-known format for the basics helps usability so much. If I look at the details of a chat message, I want to easily determine roughly when it was sent, without having to convert through completely foreign and non-standard formats. Just going with Gregorian + UTC is the right cut-off point for datetime complexity imo.

@Fang-, let's bikeshed! :) As stated, I find ~2019.1.1 more aesthetic than 2019.01.01. To me, the 0s are extra line noise with no semantic content. In much the way that lowercase text is easier to read than uppercase because the ascenders and descenders break up the shapes of the letters to make them more distinguishable (while capital letters all have the same bounding box, for the most part), the difference in shape between ~2019.1 and ~2019.12 makes it easier to distinguish between them. (For this reason, I also prefer https://www.fonts.com/content/learning/fontology/level-3/numbers/oldstyle-figures and wish we could get them in a fixed-width typeface.) Using 0 as the padding character is especially problematic. Its blocky nature distracts the eye, interfering with visual parsing, decreasing the salience of the digit following, and making ~2019.3.2 harder to distinguish from ~2019.2.3 than ~2019.02.03 from ~2019.03.02.

@dpc I agree. Urbit's aura printing is already basically what you're suggesting. It's pretty simple and low-level. In fact, it's even simpler than C's printf formatting, which clearly inspired auras. Sometimes I envy printf's ability to set the padding for numeric values, but it's not too hard to use a padding function and string interpolation to replicate that, and it means our auras don't need to support an arbitrarily complex sub-language of formatting options.
I believe at the moment we can say "Hoon's atom printing has no leading zeros." That statement is much more valuable than "Hoon's atom printing has no leading zeros. Well, except for dates. But not the year, just the month and days. No, the seconds don't have a leading zero either..."
There should be full timezone support, firmly in userspace. We have a responsibility to preserve purity of essence in atom printing from the kernel.
Atom printing should really be a bijection. That's harder for dates than for other datatypes, but sticking to it 100% would be much better than 98%. Aside from dates, I'm not aware of any deviation from this.
~2000.1.32 gets parsed to ~2000.2.1. ~2000.2.29 parses unchanged, while ~2001.2.29 becomes ~2001.3.1. Apparently the parser already knows what the rules are. Let's enforce them. ~2000.1.32 should be a syntax error.

@Fang-, can you give us examples of lists of dates arising in the system, such that this is painful?

I believe at the moment we can say "Hoon's atom printing has no leading zeros."

One could argue that since they're within the value, not at the head of it, they're not leading zeroes. Maybe that's getting a bit pedantic. I do definitely agree with you that being able to say that is really nice, but dates are way different from plain numeric values. It's not a base, it's a format. Can we really treat those the same way?
Currently, we're not even consistent about the "no leading zeroes" thing. It's accepted for time also, but printed with consistent double-digits. And for the micro-time at the end, it always demands exactly four hex digits.
::  as observed on master:
> ~2019.1.1..0.0.0..0001
~2019.1.1..00.00.00..0001

That should be stricter, parsing exclusively whatever print format we end up settling on. And that should be either of:
~2019.1.1..0.0.0..1
~2019.01.01..00.00.00..0001

(Aside, turns out trying to type ~00 into dojo causes it to crash and burn. Probably date parsing related, but will have to investigate.)
@pilfer-pandex that's just, like, your opinion man! (; Your typographical reasons seem sane, I suppose I can feel you about the noise. But there's always a clear indicator of it, right? When you see ~1234., you know what to expect, you know how to parse what you read next.
I wouldn't call any case painful per se, but they range from "eye-sore" to "annoying". Lists of @das are visually difficult to parse when the alignment of their components jump all over the place. This problem would be worse if we applied the same rules to date-times.
And also it conflicts with my sense of what a year-month-day timestamp should look like. I think most standards that put datetimes in a largest-to-smallest-unit order adhere to consistent amounts of digits, but I'd have to look that up. At least ISO 8601 does.

I don't think the atom thing is relevant @ "atom printing has no leading
zeros". This is not a leading zero.
On Mon, Feb 11, 2019 at 3:58 PM Fang<EMAIL_ADDRESS>wrote:

I believe at the moment we can say "Hoon's atom printing has no leading
zeros."

One could argue that since they're within the value, not at the head of
it, they're not leading zeroes. Maybe that's getting a bit pedantic. I do
definitely agree with you that being able to say that is really nice, but
dates are way different from plain numeric values. It's not a base, it's a
format. Can we really treat those the same way?
Currently, we're not even consistent about the "no leading zeroes" thing.
It's accepted for time also, but printed with consistent double-digits. And
for the micro-time at the end, it always demands exactly four hex digits.
::  as observed on master:

~2019.1.1..0.0.0..0001
~2019.1.1..00.00.00..0001

That should be stricter, parsing exclusively whatever print format we end
up settling on. And that should be either of:
~2019.1.1..0.0.0..1
~2019.01.01..00.00.00..0001
(Aside, turns out trying to type ~00 into dojo causes it to crash and
burn. Probably date parsing related, but will have to investigate.)
@pilfer-pandex https://github.com/pilfer-pandex that's just, like, your
opinion man! (; Your typographical reasons seem sane, I suppose I can feel
you about the noise. But there's always a clear indicator of it, right?
When you see ~1234., you know what to expect, you know how to parse what
you read next.
I wouldn't call any case painful per se, but they range from "eye-sore" to
"annoying". Lists of @das are visually difficult to parse when the
alignment of their components jump all over the place. This problem would
be worse if we applied the same rules to date-times.
And also it conflicts with my sense of what a year-month-day timestamp
should look like. I think most standards that put datetimes in a
largest-to-smallest-unit order adhere to consistent amounts of digits, but
I'd have to look that up. At least ISO 8601 does.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/1065#issuecomment-462544793, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AoZXkn2IEzH62M-oY79Uen9wvoz3dG6Xks5vMgPAgaJpZM4azElZ
.

--
~pitmug-roptec
https://urbit.org

Everyone uses 2019-01-01, even with pen and paper. It just looks way better.
I don't really care one way or the other, but yeah the two-character days
and months are nice.
On Mon, Feb 11, 2019 at 6:18 PM Benjamin Summers<EMAIL_ADDRESS>wrote:

I don't think the atom thing is relevant @ "atom printing has no leading
zeros". This is not a leading zero.
On Mon, Feb 11, 2019 at 3:58 PM Fang<EMAIL_ADDRESS>wrote:

I believe at the moment we can say "Hoon's atom printing has no leading
zeros."

One could argue that since they're within the value, not at the head of
it, they're not leading zeroes. Maybe that's getting a bit pedantic. I do
definitely agree with you that being able to say that is really nice, but
dates are way different from plain numeric values. It's not a base, it's a
format. Can we really treat those the same way?
Currently, we're not even consistent about the "no leading zeroes" thing.
It's accepted for time also, but printed with consistent double-digits. And
for the micro-time at the end, it always demands exactly four hex digits.
::  as observed on master:

~2019.1.1..0.0.0..0001
~2019.1.1..00.00.00..0001

That should be stricter, parsing exclusively whatever print format we end
up settling on. And that should be either of:
~2019.1.1..0.0.0..1
~2019.01.01..00.00.00..0001
(Aside, turns out trying to type ~00 into dojo causes it to crash and
burn. Probably date parsing related, but will have to investigate.)
@pilfer-pandex https://github.com/pilfer-pandex that's just, like,
your opinion man! (; Your typographical reasons seem sane, I suppose I can
feel you about the noise. But there's always a clear indicator of it,
right? When you see ~1234., you know what to expect, you know how to
parse what you read next.
I wouldn't call any case painful per se, but they range from "eye-sore"
to "annoying". Lists of @das are visually difficult to parse when the
alignment of their components jump all over the place. This problem would
be worse if we applied the same rules to date-times.
And also it conflicts with my sense of what a year-month-day timestamp
should look like. I think most standards that put datetimes in a
largest-to-smallest-unit order adhere to consistent amounts of digits, but
I'd have to look that up. At least ISO 8601 does.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/1065#issuecomment-462544793, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AoZXkn2IEzH62M-oY79Uen9wvoz3dG6Xks5vMgPAgaJpZM4azElZ
.

--
~pitmug-roptec
https://urbit.org

--
~pitmug-roptec
https://urbit.org

strongly disagree with @ohAitch's proposal

Toning down the snark some since me 👎ing the OP was less clear than I
hoped:

this should not be merged
my position is basically what Fang quoted as "compare numbers as numbers,
not text"
especially since the proposed scheme only works for ordering 4-digit years
~1970.1.1..0.0.1549946013 is kind of cool but shouldn't actually be
allowed by the parser, bijection is important
I have definitely never written a month leading zero with pen and paper,
day maybe
the ~00 syntax is a jam literal, and unrelated to dates. It should still
use a non-crashing cue to produce an actual parse error, though; I think
there's an issue about it unlinking dojo?

On Monday, 11 February 2019, benjamin-tlon<EMAIL_ADDRESS>wrote:

Everyone uses 2019-01-01, even with pen and paper. It just looks way
better.
I don't really care one way or the other, but yeah the two-character days
and months are nice.
On Mon, Feb 11, 2019 at 6:18 PM Benjamin Summers<EMAIL_ADDRESS>wrote:

I don't think the atom thing is relevant @ "atom printing has no leading
zeros". This is not a leading zero.
On Mon, Feb 11, 2019 at 3:58 PM Fang<EMAIL_ADDRESS>wrote:

I believe at the moment we can say "Hoon's atom printing has no leading
zeros."

One could argue that since they're within the value, not at the head of
it, they're not leading zeroes. Maybe that's getting a bit pedantic. I
do
definitely agree with you that being able to say that is really nice,
but
dates are way different from plain numeric values. It's not a base,
it's a
format. Can we really treat those the same way?
Currently, we're not even consistent about the "no leading zeroes"
thing.
It's accepted for time also, but printed with consistent double-digits.
And
for the micro-time at the end, it always demands exactly four hex
digits.
:: as observed on master:

~2019.1.1..0.0.0..0001
~2019.1.1..00.00.00..0001

That should be stricter, parsing exclusively whatever print format we
end
up settling on. And that should be either of:
~2019.1.1..0.0.0..1
~2019.01.01..00.00.00..0001
(Aside, turns out trying to type ~00 into dojo causes it to crash and
burn. Probably date parsing related, but will have to investigate.)
@pilfer-pandex https://github.com/pilfer-pandex that's just, like,
your opinion man! (; Your typographical reasons seem sane, I suppose I
can
feel you about the noise. But there's always a clear indicator of it,
right? When you see ~1234., you know what to expect, you know how to
parse what you read next.
I wouldn't call any case painful per se, but they range from "eye-sore"
to "annoying". Lists of @das are visually difficult to parse when the
alignment of their components jump all over the place. This problem
would
be worse if we applied the same rules to date-times.
And also it conflicts with my sense of what a year-month-day timestamp
should look like. I think most standards that put datetimes in a
largest-to-smallest-unit order adhere to consistent amounts of digits,
but
I'd have to look that up. At least ISO 8601 does.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/1065#issuecomment-462544793, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AoZXkn2IE
zH62M-oY79Uen9wvoz3dG6Xks5vMgPAgaJpZM4azElZ>
.

--
~pitmug-roptec
https://urbit.org

--
~pitmug-roptec
https://urbit.org
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/1065#issuecomment-462588543, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhlDG9Qcj8FwH2txkdW1R0QpzkkdXks5vMiangaJpZM4azElZ
.

@pilfer-pandex want to compile an Official™ list of actions-items here, or punt on this for a bit longer?
At the very least, it seems everyone agrees "overflow dates" (ie ~2018.12.99) should be made illegal. Whatever format dates end up in, they should be 100% bijective.
We seem to have a roughly equal amount of support for either date format (~2019.1.1 vs ~2019.01.01).
While Urbit should be free to unshackle itself from the assumptions of the real world, I thought it might nonetheless be useful to see what format is more common in the wild. It's not a particularly scientific method, but I took some dates, exact-string-match searched for them with Google, and noted the amount of results they turned up with and without leading zeroes. (This method is a bit dubious, and there's cherry-picking potential here. If we really care, we could write a script for this, maybe.)

date
leading 0's
no leading 0's

1776-07-04
16.6k
11.4k

1970-01-01
11.3m
10.2m

2009-01-03
7.8m
17.3m

2018-03-15
55.8m
12.1m

It has been a month since my last comment, so I'm going to close this one for the time being because I just don't think any particularly clear consensus has developed on whether it's appropriate or not.  It might be a good idea to pick the conversation up on the mailing list, or to go straight to a more formal proposal.


Remove unnecessary check

Check is causing problems in RandomWalk test
even though job is configured correctly

I think this should probably hold off until #804 is wrapped up. It may obsolete this. As far as randomwalk goes, it's probably useful to start migrating it to use the code in the new MR module.

I updated this PR to make the check actually work and removed an unused method.


Update network_timezones.txt

Added Talpa, RTL4:Europe/Amsterdam for Dutch network

Thanks for the pull request! Before a real human comes by, please make sure your PR has all of the below criteria checked

[x] Give a description on what the PR is for.
[ ] Make sure your PR is based on the DEVELOP branch
[x] Don't send big changes all at once. Split up big PRs into multiple smaller PRs that are easier to manage and review

Please make sure you also read contribution guide and followed all of the steps.
Thanks!


[bugfix] Derive correct "signmessage" address

Prior implementation used the full address derivation path instead of the wallet address when deriving the xpub.

Slightly enhances embit_utils parsing
Tightens up rejection of custom derivation paths
Expanded test scenarios

ACK tested
tested before and indeed was not displaying the correct address but was signing for the correct one.
tested after that still produces a valid signature and displayed the correct address before signing.

ACK and Tested


Error with Data Access Sampling

Data Access Sampling seems to not be working on Expanse. After compiling with
gfortran -march=znver2 -g -O3 -o dmadd_good dmadd_good.f
and running uProf to collect information with
AMDuProfCLI-bin collect --config data_access -o dmadd_good-da ./dmadd_good
there is an error:
ERROR : For non root users with perf_event_paranoid value greater than -1,
the maximum number of events supported together is : 6

Were you running this on nodes that were available through the Summer Institute reservation? And by chance do you happen to remember which node? If not, we might be able to track that down if you give me your user name.
We needed to make some modifications at the root level to allow users to access performance counters and run uProf and can check to make sure that paranoid level was set appropriately.

Hi Robert, thanks for your quick reply!
I am XSEDE-ECSS staff, so I have an account attached to project sds164, username is babreu. I was running this from the debug partition with
srun --partition=debug --pty --account=sds164 --ntasks-per-node=4 --mem=8G -t 00:30:00 --wait=0 --export=ALL /bin/bash
Let me know if there is any other information that may be helpful (this was also sent as a ticket via the XSEDE portal, ID 153559).

Hi Bruno - you're not doing anything wrong. We just don't have all the nodes configured correctly yet to run uProf. In fact, we just rebooted the nodes that were reserved for the Summer Institute yesterday morning. I guess the best I can say for now is sit tight and wait until changes have been pushed and all nodes rebooted.

Hi Robert, thank you again for your answer! I will try these commands again in the future.


[Service Bus] MaxListenersExceededWarning during the test runs - both node and browser

Warning occurring in both node and browser.
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 sender_error listeners added to [Sender]. Use emitter.setMaxListeners() to increase limit

Pipeline https://dev.azure.com/azure-sdk/internal/_build/results?buildId=530232&view=logs&j=34d05327-3286-5fd0-44d3-76aebff5d924&t=d726e143-6308-5465-2a45-ec34d6ea866c

While this is fixed with the changes in #11175, the long term fix as described in https://github.com/Azure/azure-sdk-for-js/pull/11175#discussion_r486536436 is still desriable

Looks like @HarshaNalluru already fixed this in https://github.com/Azure/azure-sdk-for-js/pull/11738. The error event handlers are passed in the receiver/sender options now rather than attached later.


Clear doc about HOW TO USE pyros

It seems people are confused between ROS workflow and Python workflow.
We should write a simple README tested with doctest. like https://github.com/ionelmc/python-tblib

docs on readthedocs.io


v1.11.0

Removed transpiled code and build on npm start
Add travis-ci and slack integration

Pull Request Test Coverage Report for Build 575

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 66.655%

Totals

Change from base Build 550:
0.0%

Covered Lines:
1369

Relevant Lines:
1953

💛  - Coveralls

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


Configuration data no longer being read

Working with the master branch my app config data is no longer being read.  I'm guessing [38a50ac7cea9ce66b62c35b8a3137cd2789f5e2d] is the reason, but I haven't messed with addon configuration enough to be sure of the fix.

I think I am seeing this too

yup. this basically means that the README doesn't work

My bad, that's not needed at all in our setup.  Fixing it right now.

🎉🎊🎉🎊 many thanks

On Jul 10, 2015, at 21:32, José Padilla<EMAIL_ADDRESS>wrote:
My bad, that's not needed at all in our setup. Fixing it right now.
—
Reply to this email directly or view it on GitHub.

Agreed.  Thanks!

Hmmm, so I figured I should try this, so I switched to HEAD
-    "ember-cli-simple-auth-token": "^0.7.2",
+    "ember-cli-simple-auth-token": "jpadilla/ember-cli-simple-auth-token",

I have this in my environment.js:
 var ENV = {
    // snip!
    'simple-auth': {
      authorizer: 'simple-auth-authorizer:token',
      serverTokenEndpoint: '/shops'
    }

yet, it's still trying to hit http://localhost:4200/api-token-auth/ instead of /shops. Am I doing something dumb? Maybe this issue didn't affect me, and I'm just missing something.

serverTokenEndpoint has to be set in ENV['simple-auth-token']
On Sat, Jul 11, 2015 at 1:32 PM Steve Klabnik<EMAIL_ADDRESS>wrote:

Hmmm, so I figured I should try this, so I switched to HEAD

"ember-cli-simple-auth-token": "^0.7.2",+    "ember-cli-simple-auth-token": "jpadilla/ember-cli-simple-auth-token",

I have this in my environment.js:
var ENV = {
// snip!
'simple-auth': {
authorizer: 'simple-auth-authorizer:token',
serverTokenEndpoint: '/shops'
}
yet, it's still trying to hit http://localhost:4200/api-token-auth/
instead of /shops. Am I doing something dumb? Maybe this issue didn't
affect me, and I'm just missing something.
—
Reply to this email directly or view it on GitHub
https://github.com/jpadilla/ember-cli-simple-auth-token/issues/76#issuecomment-120646746
.

Ah! Thanks. Let me send you a PR...

Ahh, no PR needed, I just mis-read the readme :sweat:
Thanks again!

@jpadilla can you tag a release with this fix?


Unhandled exception in spawn(name: Signal Loop)

When running the specs for this project:
https://github.com/tbrand/tokoroten/blob/master/spec/tokoroten_spec.cr#L110
The following error is thrown many times. I'm unable to catch it and it seems that Signal Loop is crystal internal fibre which is having an issue.
crystal version: 0.33.0 (this problem is not there in previous crystal versions)
os: macos catalina
Unhandled exception in spawn(name: Signal Loop): End of file reached (IO::EOFError)
  from /Users/kings/.ball/install/c-0.33.0/src/io.cr:513:27 in 'read_fully'
  from /Users/kings/.ball/install/c-0.33.0/src/io/byte_format.cr:123:3 in 'decode'
  from /Users/kings/.ball/install/c-0.33.0/src/int.cr:613:5 in 'from_io'
  from /Users/kings/.ball/install/c-0.33.0/src/io.cr:889:5 in 'read_bytes'
  from /Users/kings/.ball/install/c-0.33.0/src/signal.cr:197:17 in '->'
  from /Users/kings/.ball/install/c-0.33.0/src/fiber.cr:255:3 in 'run'
  from /Users/kings/.ball/install/c-0.33.0/src/fiber.cr:92:34 in '->'

Reduced:
msg = "a" * 70000

20.times do
  main_reader, main_writer = IO.pipe
  worker_reader, worker_writer = IO.pipe

  Process.fork do
    worker_reader.gets(msg.size)
    main_writer.print msg
  end

  spawn do
    worker_writer.print msg
  end

  main_reader.gets(msg.size)
end

In case anyone wants to debug any further (I won't because I'm not familiar with that part of the codebase).
Also, tokoroten seems to be doing spawn { loop { ... } } without an end to those loops, so kill isn't correctly implemented and the app will leak fibers.

Hi - do you have any idea of the timeline for this bug getting fixed? If it's not going to be in the next release then I will implement a different solution. Or if it's likely to be fixed in the next release I will hold fire for that.

Since nobody replied, there's no expected time when this will be fixed.

Process.fork is likely to be removed before 1.0. Unless this can be reproduced without fork then it might be closed?
We should probably deprecate the method already....

Ok thanks - if the future is to remove Process.fork then I will implement an alternative solution for my project

In crystal 0.34 this seems to work fine!


Add a license file

An interesting concept and nice work. I would like to reuse your code but without a license I am not sure if you agree and to what extent.
Could you add a licence to the repository?
A comprehensive info about licenses can be found here, this one is often used for this kind of projects. It is enough to copy the text and put in LICENSE file in the main dir.

@mjmikulski Thanks for pointing out. I added MIT license. Feel free to use the code for your projects and distribute.

Perfect, thank you! :)


Misleading title - there is no formContext.ui.sections

The title and TOC entry seem to imply that sections on the form can be accessed via formContext.ui.sections - but there is no such collection - as the page shows in the code example you first need to access a tab and then you get the tab's sections.  While it makes sense for this to still be TOC'd as formContext.ui it really should probably be TOC'd and titled something more like "formContext.ui Tab Sections".

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

ID: 006a1fa1-4229-036d-c756-78ce341ae39d
Version Independent ID: 324740b1-606b-7481-1568-fc2c577ace30
Content: formContext.ui.sections (Client API reference) in model-driven apps - Power Apps
Content Source: powerapps-docs/developer/model-driven-apps/clientapi/reference/formContext-ui-sections.md
Service: powerapps
Sub-service: mda-developer
GitHub Login: @adrianorth
Microsoft Alias: jdaly

Thanks for your comment, @JamesHorsley. This issue has been assigned to the doc author for review.

@JamesHorsley
Thanks for your feedback. The feature team is reviewing.

Proposed changes:

Rename/Retitle: /clientapi/reference/formContext-ui-sections.md

Filename: formContext-ui-sections.md => formContext-ui-tab-sections.md
Title: formContext.ui.sections (Client API reference) => formContext.ui Tab Sections (Client API reference)
Also change author to : HemantGaur

Rename the folder of the child topics below it:
formcontext-ui-sections => formcontext-ui-tab-sections
Change /model-driven-apps/TOC.yml lines 629 – 643

    - name: formContext.ui tab sections
      href: clientapi/reference/formcontext-ui-tab-sections.md
      items:
      - name: getLabel
        href: clientapi/reference/formcontext-ui-tab-sections/getLabel.md
      - name: getName
        href: clientapi/reference/formcontext-ui-tab-sections/getName.md
      - name: getParent
        href: clientapi/reference/formcontext-ui-tab-sections/getParent.md
      - name: getVisible
        href: clientapi/reference/formcontext-ui-tab-sections/getVisible.md
      - name: setLabel
        href: clientapi/reference/formcontext-ui-tab-sections/setLabel.md
      - name: setVisible
        href: clientapi/reference/formcontext-ui-tab-sections/setVisible.md

Add re-directs to .openpublishing.redirection.json to account for the changes:

   {
      "source_path": "powerapps-docs/developer/model-driven-apps/clientapi/reference/formContext-ui-sections.md",
      "redirect_url": "/power-apps/developer/model-driven-apps/clientapi/reference/formContext-ui-tab-sections",
      "redirect_document_id": "false"
    },
    {
      "source_path": "powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-sections/getLabel.md",
      "redirect_url": "/powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-tab-sections/getLabel",
      "redirect_document_id": "false"
    },
    {
      "source_path": "powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-sections/getName.md",
      "redirect_url": "/powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-tab-sections/getName",
      "redirect_document_id": "false"
    },
    {
      "source_path": "powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-sections/getParent.md",
      "redirect_url": "/powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-tab-sections/getParent",
      "redirect_document_id": "false"
    },
    {
      "source_path": "powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-sections/getVisible.md",
      "redirect_url": "/powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-tab-sections/getVisible",
      "redirect_document_id": "false"
    },
    {
      "source_path": "powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-sections/setLabel.md",
      "redirect_url": "/powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-tab-sections/setLabel",
      "redirect_document_id": "false"
    },
    {
      "source_path": "powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-sections/setVisible.md",
      "redirect_url": "/powerapps-docs/developer/model-driven-apps/clientapi/reference/formcontext-ui-tab-sections/setVisible",
      "redirect_document_id": "false"
    }

Fixed


the training time of this project

hello, could you tell me the training time of this project, thanks!

Hi, thank you for your interest! The instruction on how to train our baselines on the proposed dataset is detailed in the readme.


Import: Modify existing POST /api/inspect/remote import processing to create configuration file

Will need to map fields from connect API results into the configuration file
Will need to create a unique configuration name
w/ Go unit tests
Testable via curl command

Closing, as we have moved to a simpler initial implementation: #2285


Lgtm fixes

This PR changes (delete as applicable)

Nothing, it's a bug fix

This is a new version of #3022 with changes restricted to v3/src. There are a few additional changes here in response to a few other things I found flagged up.
22237d8..7d09434 are small maintainability related changes. d522461 fixes what appears to be a minor bug - < has higher precedence than |, so the right hand operands of these && expressed ({colors,alphas}.length < (vertices.length / 2)) | 0 rather than truncating vertices.length / 2, causing an error to be skipped when vertices.length === {colors,alphas}.length * 2 + 1.
Results taken from https://lgtm.com/projects/g/photonstorm/phaser/alerts/.

Thanks for the review - I've removed the two mentioned commits.

Thanks, happily merged now.


Successfully ran FlightCapture_AS app on Samsung Galaxy S4

Not sure where the pictures that were snapped while the application was running were saved, but I did manage to grab a screenshot.

Wonder what the picture on the top left of the phone is?
App will ask you if you want to turn on GPS when you first start.

Does replying to these do anything?

Good to see it runs for somebody.  Maybe with your changes, it will run for me.
Branodn

On Jul 16, 2015, at 3:11 PM, TexMex657<EMAIL_ADDRESS>wrote:
Not sure where the pictures that were snapped while the application was running were saved, but I did manage to grab a screenshot.
https://cloud.githubusercontent.com/assets/13320920/8735282/821601bc-2bc4-11e5-84c5-cf5d970065d2.png
Wonder what the picture on the top left of the phone is?
App will ask you if you want to turn on GPS when you first start.
You can view, comment on, or merge this pull request online at:
https://github.com/Juicebox47/ftl-smartphone/pull/2 https://github.com/Juicebox47/ftl-smartphone/pull/2
Commit Summary
think the only changes that occurred here were auto due to compiler opening files
changed compiler encoding settings for project to windows-1252
compiled changed sdk directory path to match my local machine for the flightcapture_AS project. Previous commits where for the FTL_flightcapture project.
think these changes are from running the AVD simulator on my compiler. App actually ran but froze when I tried pressing the app buttons so going to try on my actual phone
changed all encodings to utf-8
probably just auto compiler changes from running application on phone. FlightCapture_AS successfully ran on samsung galaxy S4 samsung-sm-g900A android version 5.0
File Changes
A .idea/.name https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-0 (1)
A .idea/compiler.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-1 (22)
A .idea/copyright/profiles_settings.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-2 (3)
A .idea/ftl-smartphone__idc.iml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-3 (24)
A .idea/misc.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-4 (14)
A .idea/modules.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-5 (8)
A .idea/vcs.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-6 (6)
A .idea/workspace.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-7 (218)
M FTL_FlightCapture/.idea/compiler.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-8 (2)
A FTL_FlightCapture/.idea/encodings.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-9 (6)
M FTL_FlightCapture/.idea/gradle.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-10 (4)
M FTL_FlightCapture/.idea/misc.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-11 (18)
M FlightCapture_AS/.gradle/2.2.1/taskArtifacts/cache.properties.lock https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-12 (0)
M FlightCapture_AS/.gradle/2.2.1/taskArtifacts/fileHashes.bin https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-13 (0)
M FlightCapture_AS/.gradle/2.2.1/taskArtifacts/fileSnapshots.bin https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-14 (0)
M FlightCapture_AS/.gradle/2.2.1/taskArtifacts/outputFileStates.bin https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-15 (0)
M FlightCapture_AS/.gradle/2.2.1/taskArtifacts/taskArtifacts.bin https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-16 (0)
M FlightCapture_AS/.idea/.name https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-17 (2)
M FlightCapture_AS/.idea/compiler.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-18 (2)
A FlightCapture_AS/.idea/encodings.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-19 (6)
M FlightCapture_AS/.idea/gradle.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-20 (4)
M FlightCapture_AS/.idea/misc.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-21 (21)
M FlightCapture_AS/.idea/vcs.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-22 (2)
M FlightCapture_AS/.idea/workspace.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-23 (333)
M FlightCapture_AS/app/app.iml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-24 (1)
A FlightCapture_AS/app/build/intermediates/dex/debug/classes.dex https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-25 (0)
M FlightCapture_AS/app/build/intermediates/incremental/mergeAssets/androidTest/debug/merger.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-26 (2)
M FlightCapture_AS/app/build/intermediates/incremental/mergeAssets/debug/merger.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-27 (2)
M FlightCapture_AS/app/build/intermediates/incremental/mergeResources/androidTest/debug/merger.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-28 (2)
M FlightCapture_AS/app/build/intermediates/incremental/mergeResources/debug/merger.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-29 (12)
M FlightCapture_AS/app/build/intermediates/res/debug/layout/activity_main.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-30 (145)
M FlightCapture_AS/app/build/intermediates/res/debug/menu/activity_main.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-31 (2)
M FlightCapture_AS/app/build/intermediates/res/debug/values-v11/values-v11.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-32 (2)
M FlightCapture_AS/app/build/intermediates/res/debug/values-v14/values-v14.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-33 (2)
M FlightCapture_AS/app/build/intermediates/res/debug/values/values.xml https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-34 (4)
M FlightCapture_AS/app/build/intermediates/resources/resources-debug-androidTest.ap_ https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-35 (0)
M FlightCapture_AS/app/build/intermediates/resources/resources-debug.ap_ https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-36 (0)
A FlightCapture_AS/app/build/outputs/apk/app-debug-unaligned.apk https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-37 (0)
A FlightCapture_AS/app/build/outputs/apk/app-debug.apk https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-38 (0)
M FlightCapture_AS/app/build/outputs/logs/manifest-merger-debug-report.txt https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-39 (4)
M FlightCapture_AS/build/intermediates/gradle_project_sync_data.bin https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-40 (0)
M FlightCapture_AS/local.properties https://github.com/Juicebox47/ftl-smartphone/pull/2/files#diff-41 (12)
Patch Links:
https://github.com/Juicebox47/ftl-smartphone/pull/2.patch https://github.com/Juicebox47/ftl-smartphone/pull/2.patch
https://github.com/Juicebox47/ftl-smartphone/pull/2.diff https://github.com/Juicebox47/ftl-smartphone/pull/2.diff
—
Reply to this email directly or view it on GitHub https://github.com/Juicebox47/ftl-smartphone/pull/2.

It sent me an email.
Ideally at this point someone would review my commits / file changes and possibly even run over and clone my repository to test the app before merging, but since the only other person (Brandon) that currently has Android studio can't get the app to run on their phone, I'm going to merge myself (after saving a local copy just in case).
Also, found the photos being saved on my phone. They get saved into a "TimePics_" followed by a time stamp directory. Guessing this directory might slightly change to "DistPics_" if you selected that option when running. The very first photo didn't seem to have any location data in the EXIF data, but the following pictures DID, which is great news!
Screenshot showing GPS data

Actual photo with GPS data


Adding OpenMP to multi expression assign and other var loops?

Description
When doing loops in the fwd/reverse pass could we just put an OpenMP pragma in front of loops? Like for instance here in result() we could do
    #pragma omp parallel for
    for (size_t i = 0; i < rows * cols; i++) {
      index_apply<sizeof...(T_results)>([&](auto... Is) {
        static_cast<void>(
            std::initializer_list<int>{(std::get<Is>(res_evals).coeffRef(i)
                                        = std::get<Is>(expr_evals).coeff(i),
                                        0)...});
      });
    }

Though we'd probably want to do something clever at what size of rows * cols it's worth turning on OpenMP. The OpenMP stuff is pretty lightweight, though we could also just the TBB here as well
Current Version:
v3.4.0

We could also do this in the stan repo for rvalue(var<Matrix>) like in the below
https://github.com/stan-dev/stan/blob/develop/src/stan/model/indexing/rvalue_varmat.hpp#L77

We could also do this in the stan repo for rvalue(var<Matrix>) like in the below
https://github.com/stan-dev/stan/blob/develop/src/stan/model/indexing/rvalue_varmat.hpp#L77

I did not know we are using OpenMP. Some benchmarks would be required to demonstrate the speedups, but I like the idea.

I did not know we are using OpenMP. Some benchmarks would be required to demonstrate the speedups, but I like the idea.

I would definitely prefer using TBB since we already have that and if there is not a huge advantage of using OpenMP over TBB for this case.
Adding OpenMP would require a bunch of makefile changes and user-facing docs for installation and so on.

Though we'd probably want to do something clever at what size of rows * cols it's worth turning on OpenMP

Definitely, which is why this stuff is never as easy as it looks on first glance :)

I would definitely prefer using TBB since we already have that and if there is not a huge advantage of using OpenMP over TBB for this case.
Adding OpenMP would require a bunch of makefile changes and user-facing docs for installation and so on.

Though we'd probably want to do something clever at what size of rows * cols it's worth turning on OpenMP

Definitely, which is why this stuff is never as easy as it looks on first glance :)

I did not know we are using OpenMP.

We don't, I was just staring at some OpenMP docs a while back and thought it looked easy. Then forgot to make an issue about it

Some benchmarks would be required to demonstrate the speedups, but I like the idea.

Yeah tbh I think you would need a pretty large N to make the fixed cost of starting up threads etc. worth it.

I would definitely prefer using TBB since we already have that and if there is not a huge advantage of using OpenMP over TBB for this case.

Yeah that's a good point, I could see OpenMP being a bit more performant since it's built into the compiler but having OpenCL/TBB/OpenMP would just be a slug of a maintenance burden. I also don't think OpenMP would play nicely with nested parallelism like tbb does

I did not know we are using OpenMP.

We don't, I was just staring at some OpenMP docs a while back and thought it looked easy. Then forgot to make an issue about it

Some benchmarks would be required to demonstrate the speedups, but I like the idea.

Yeah tbh I think you would need a pretty large N to make the fixed cost of starting up threads etc. worth it.

I would definitely prefer using TBB since we already have that and if there is not a huge advantage of using OpenMP over TBB for this case.

Yeah that's a good point, I could see OpenMP being a bit more performant since it's built into the compiler but having OpenCL/TBB/OpenMP would just be a slug of a maintenance burden. I also don't think OpenMP would play nicely with nested parallelism like tbb does

I made an issue for this as I don't have time to do this rn but if someone else does then 100% go at it. A simple benchmark of elt_mulitply etc. would work here

I made an issue for this as I don't have time to do this rn but if someone else does then 100% go at it. A simple benchmark of elt_mulitply etc. would work here


Add profiling middleware to storage in master

What do these changes do?

Add profiling middleware to storage in master
Related implementation on osparc-simcore side: https://github.com/ITISFoundation/osparc-simcore/pull/5749

Related issue/s

https://github.com/ITISFoundation/osparc-simcore/issues/5729

Related PR/s
Checklist

[ ] I tested and it works

@mrnicegyu11 I am a bit in doubt if it is OK I change these env vars here and not here

Closing this one because I read the documentation on how to update env vars (better late than never 🤞🏻) and created this PR instead: https://git.speag.com/oSparc/osparc-ops-deployment-configuration/-/merge_requests/567


Add Swagger Documentation for API Endpoints

As a developer
I need to add Swagger annotations to document the REST API
So that the API is well-documented and easy to use for other developers or consumers
Details and Assumptions

Each endpoint should be annotated with Swagger documentation using Flask-RESTX decorators.
Swagger documentation should be available at /apidocs/.
All request and response data models should be properly defined using Flask-RESTX's api.model.

Acceptance Criteria
Given the API endpoints are annotated with Swagger documentation
When a user accesses the `/apidocs/` route
Then they should see a well-organized, accurate Swagger UI with details of each endpoint, including request/response data models

I am currently working on this now.