deleted from disk.....

Issue Type: Bug
when I open an file from winscp(ftp) sometimes vs code is saying deleted from disk. but with notepad++ not like this something happening.
VS Code version: Code 1.30.1 (dea8705087adb1b5e5ae1d9123278e178656186a, 2018-12-18T18:12:07.165Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz (12 x 3192)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
15.93GB (8.99GB free)

Process Argv
C:\Users\MyMeMo\AppData\Local\Temp\scp12521\public_html\inc\pages\profile.php

Screen Reader
no

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

php-intellisense
fel
2.3.10

vscode-apache
mrm
1.1.1

@mymem0 how does your setup look like for opening remote resources? is it through an extension?

https://winscp.net/eng/download.php I am using it.

@mymem0 yeah so I assume from that tool you right click to open with editor rigth?


Avoid TypeError due to NoneType comparison

In python3, comparing None with other types is no longer possible. This leads to a TypeError in https://github.com/ros-visualization/rqt_reconfigure/blob/master/src/rqt_reconfigure/param_updater.py#L70. The python2 behavior can be reproduced by changing the line as suggested in this PR.

retest this please


Add deletecontroller field to Permissions

See this description in the RFC

Should be very similar in spirit to this PR


Clean up the MappedMetricData data schema

There are several issues:

The metric definition appears twice
Detector UUID appears twice.
Detector UUID appears as detectorUuid one time and detectorUUID the other time.
The schema includes the investigationResults field, which we no longer use in AA
We reference prediction/threshold related fields that don't make sense for many of the detectors

Whoever takes this issue, let's discuss more carefully what the target data schema should be.
Expedia-specific: We will need to roll this out in a way that minimizes client impact. Some potential coordination areas:

Aquila is posting anomalies, so we will need to update it
Seyren will be posting anomalies, so we will need to update that
Vector is reading anomalies
Armor is reading anomalies
I don't think Haystack is reading anomalies directly, but double-check

Here's an example:
  {
    "metricData": {
      "metricDefinition": {
        "tags": {
          "kv": {
            "mtype": "gauge",
            "unit": "metric",
            "what": "[redacted]",
            "m_application": "[redacted]",
            "org_id": "1",
            "name": "[redacted]",
            "interval": "60",
            "m_account": "[redacted]",
            "m_region": "us-west-2"
          },
          "v": []
        },
        "meta": {
          "kv": {},
          "v": []
        },
        "key": "[redacted]"
      },
      "value": 0,
      "timestamp":<PHONE_NUMBER>
    },
    "detectorUuid": "37ef6be4-dd86-11e8-956a-061bc4b8b7e4",
    "detectorType": "constant-detector",
    "anomalyResult": {
      "detectorUUID": "37ef6be4-dd86-11e8-956a-061bc4b8b7e4",
      "metricData": {
        "metricDefinition": {
          "tags": {
            "kv": {
              "mtype": "gauge",
              "unit": "metric",
              "what": "[redacted]",
              "m_application": "[redacted]",
              "org_id": "1",
              "name": "[redacted]",
              "interval": "60",
              "m_account": "[redacted]",
              "m_region": "us-west-2"
            },
            "v": []
          },
          "meta": {
            "kv": {},
            "v": []
          },
          "key": "[redacted]"
        },
        "value": 0,
        "timestamp":<PHONE_NUMBER>
      },
      "anomalyLevel": "NORMAL",
      "predicted": null,
      "thresholds": null,
      "investigationResults": null
    }
  }

Also, this issue gives us a good opportunity to document an approach to schema migration.
Updates

Probably MappedMetricData shouldn't have an AnomalyResult at all.
Probably we should push AnomalyResult onto the anomaly topic instead of pushing a MappedMetricData onto that topic.

I removed the investigationResults field.

Done: 047291534d4cab5c79281029784b85af87cd749a


RDoc for converters

This PR had to be this big because of cross-referencing (links) and to avoid redundancy.

Thanks.

@kou, does this eventually get merged into ruby/ruby?

Yes.
But we need to consider where we should put separated documents in ruby/ruby before we put our changes to ruby/ruby.


Puppeteer using "Microsoft Print to PDF" instead of "Save as PDF"

We've had some issues with weird printing bugs, that we couldn't reproduce in any chromium instance.
Then we've tried the headless configuration, and we found out that the PDF method actually prints it with "Microsoft Print to PDF" option, which produces the exact document with the bugs that we've seen, and not the Chromium bulit-in "Save as PDF" which works well.
This happened in both Puppeteer, and PuppeteerSharp(A .NET port).
Steps to reproduce
Tell us about your environment:

Puppeteer version: v1.19.0
Platform / OS version: Windows 10
Node.js version: v10.15.1

What steps will reproduce the problem?

Create an HTML file that looks bad on "Microsoft Print to PDF" option
Print to pdf with puppeteer

What is the expected result?
The output of "Save as PDF", chromium's embedded PDF renderer.
What happens instead?
The output of "Microsoft Print to PDF" buggy renderer.

Removing the Microsoft printer from the Windows installation fixed the problem.


Slugify filename

Slugify filename uploaded with BREAD when detail is set with "preserveFileUploadName": true
If "preserveFileUploadName": true is set without slugify, uploaded files can causes W3C errors (spaces, non autorised caracters...)
And is good for SEO :p

Don't mind StyleCI. It will merge all fixes once we merge this in!

Don't mind StyleCI. It will merge all fixes once we merge this in!

Thank you, I'll know for the next time


CRB-215 do not schedule blocks for validation on error

Also, upon an invalid blocks, unschedule descendants.

Merged as part of https://github.com/gluwa/Sawtooth-Core/pull/61


Load CompactIndexClient upfront during specs

What was the end-user problem that led to this PR?
The problem was failing CI:  https://github.com/rubygems/bundler/runs/386607433.
What was your diagnosis of the problem?
My diagnosis was that it could be caused by autoloading not being thread safe. The CompactIndexClient constant is autoloaded. If two parallel threads try to autoload the constant at the same time, it could happen that one of them sees the constant in an incomplete state (no initialize method defined yet).
What is your fix for the problem, implemented in this PR?
My fix is to load the constant upfront.
Why did you choose this fix out of the possible options?
I chose this fix because even if I could stop autoloading the constant, I don't want to touch code in lib at the moment just to fix a testing issue.

Seems to fix the issue #7554 is running into for me, so merging!
@bundlerbot merge

Wow! Thanks!


Add simple progress option

Add an options to disable the progress bar.
Simple progress reporting is already implemented when the output is piped to a file but there is currently no option to enable it manually.

Added in v0.6.1


custom emotes in event name

https://stackoverflow.com/questions/62844658/discord-bot-embedding-custom-emote-js
can be accomplished with
<:EmoteName:ID> or <a:EmoteName:ID>

YMMV
Follow instructions in stackoverflow
type out emoji and add \ to the start, copy <:emoji_name:ID>
only works with embed style without location URL.
Append emoji character string to the calendar event


[OUTPUT] Flatten SNS alert for better PagerDuty formatting

This PR aims to resolve issue: #24
What:

Information about each matched rule now a top-level key
Total number of matches are displayed

Why:

Formatting change should make the output in PagerDuty easier to read.

Researching the CI failure

Resolves #24

Sounds good!

@fusionrace - for future PR's please include before and after examples in the PR description to help solidify understanding in the changes.


Bot to retrieve voice message

Please point me to the right direction on implementing this.
I have the snippet so far:

onMessage{ implicit msg =>
request(GetFile(msg.voice.map(_.fileId).getOrElse(""))
.onComplete{
case Success(file) => ??? //what to do next to get the actual file (when i try file.filePath it gives me something like this --> voice/file_1)
}
}

Thanks,

Please check the GetFile documentation
Here's my working attempt, when you send a voice recording it replies with the file size, hope it helps:
class FileBot(token: String) extends ExampleBot(token) // just for testing
  with Polling
  with Commands {

  onMessage { implicit msg =>

    using(_.voice) { voice =>
      request(GetFile(voice.fileId)).onComplete {
        case Success(file) =>
          file.filePath match {

            case Some(filePath) =>
              // See https://core.telegram.org/bots/api#getfile
              val url = s"https://api.telegram.org/file/bot${token}/${filePath}"

              for {
                res <- Http().singleRequest(HttpRequest(uri = Uri(url)))
                if res.status.isSuccess()
                bytes <- Unmarshal(res).to[ByteString]
              } /* do */ {
                reply(s"File with ${bytes.size} bytes received.")
              }

            case None =>
              println("No file_path was returned")
          }

        case Failure(e) =>
          println("Exception: " + e) // poor's man logging
      }
    }
  }
}

thanks for this. :)


Update dockerhub extension

Description

Added ability to Pull Images from Docker Hub
Screencast
https://github.com/raycast/extensions/assets/14165223/61b88f62-85ce-4428-b073-7cba84ff9961

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

@k8scat Can you check in this?

LGTM


is tf.signal.stft same as librosa.stft ?

hi,
Dear, if I use the tf.signal.stft instead of librosa.stft, will have any difference ?
and tf.signal.inverse_stft could be librosa.istft ?
thanks a lot

This is not Build/Installation or Bug/Performance issue. Please post this kind of support questions at Stackoverflow. There is a big community to support and learn from your questions. GitHub is mainly for addressing bugs in installation and performance. Thanks!

Are you satisfied with the resolution of your issue?
Yes
No

NO
Can't open the link

They're different and you cannot just replace one with the other. This is pretty easy to test.
import librosa as lr
import tensorflow as tf

waveform, samplerate = lr.load(lr.util.example_audio_file(), None, duration=10.0)

z1 = lr.stft(waveform)
z2 = tf.signal.stft(waveform, 2048, 512).numpy()
print(z1.shape, z1.min(), z1.max(), z1.mean())
print(z2.shape, z2.min(), z2.max(), z2.mean())

Aside from the transpose, librosa does reflect padding to center analysis frames (np.pad(waveform, 2048//2, 'reflect')). That seems to be the major difference, but even after matching that you'd still get some slightly different values (perhaps the underlying FFT isn't identical). They're different enough that you cannot just drop-in replace one for the other with a pretrained model so beware.


poly1305: Properly copy the whole context on dup

Also reset the updated flag when Poly1305_Init is called.
This improves the fix from PR #18100

This pull request is ready to merge

Merged.


Stealth key registry

Closes #226
See commit messages for details

When we show the user a toast about the receiver not having their account set up, it overflows the toast:

A similar thing happens when the user enters an address with a bad checksum:

When the user enters something that is too short to be an address, we show the error inline immediately after

I'm guessing we don't do this with stealth key resolution or with checksumming because those are async checks? Still, I wonder how hard it would be to run the async checks after the user stops input for (say) 250 ms, then show the error message inline like we do in the third case?
If that's not a quick fix, we can consider it as a future enhancement. For now, at a minimum, we should make the toast error readable.

Ok @mds1, re-reviewed and resolved issues that looked fixed. Responded to your questions. Shared on additional bug I discovered. We're getting there! Thanks :)

Notification alerts now are wider + dynamically check whether or not you're in dark mode, as of 61e1eeb069d7ac73b096fd70fb778d1429580c7b

d5466b595935a94fb3a37df29c4b024fe3d87b78 should add support for async validation of recipient ID before submitting the form, but could use a bit more testing, cc @apbendi


Another "quests top" error

(Required) What is your Quests version / build number (do not say "latest")?
3.3.0
(Required) Please describe the problem and how to replicate it. Any console errors?
[22:48:37] [Server thread/WARN]: java.io.FileNotFoundException: plugins/Quests/data/old (Is a directory)
[22:48:37] [Server thread/WARN]: 	at java.io.FileInputStream.open0(Native Method)
[22:48:37] [Server thread/WARN]: 	at java.io.FileInputStream.open(FileInputStream.java:195)
[22:48:37] [Server thread/WARN]: 	at java.io.FileInputStream.<init>(FileInputStream.java:138)
[22:48:37] [Server thread/WARN]: 	at org.bukkit.configuration.file.FileConfiguration.load(FileConfiguration.java:128)
[22:48:37] [Server thread/WARN]: 	at me.blackvein.quests.Quests.questsTop(Quests.java:1434)
[22:48:37] [Server thread/WARN]: 	at me.blackvein.quests.Quests.questActionsCommandHandler(Quests.java:1355)
[22:48:37] [Server thread/WARN]: 	at me.blackvein.quests.Quests.onCommand(Quests.java:712)
[22:48:37] [Server thread/WARN]: 	at org.bukkit.command.PluginCommand.execute(PluginCommand.java:44)
[22:48:37] [Server thread/WARN]: 	at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:141)
[22:48:37] [Server thread/WARN]: 	at org.bukkit.craftbukkit.v1_12_R1.CraftServer.dispatchCommand(CraftServer.java:648)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.PlayerConnection.handleCommand(PlayerConnection.java:1397)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.PlayerConnection.a(PlayerConnection.java:1232)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.PacketPlayInChat.a(PacketPlayInChat.java:45)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.PacketPlayInChat.a(PacketPlayInChat.java:1)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.PlayerConnectionUtils$1.run(SourceFile:13)
[22:48:37] [Server thread/WARN]: 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[22:48:37] [Server thread/WARN]: 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.SystemUtils.a(SourceFile:46)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.MinecraftServer.D(MinecraftServer.java:748)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.DedicatedServer.D(DedicatedServer.java:406)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.MinecraftServer.C(MinecraftServer.java:679)
[22:48:37] [Server thread/WARN]: 	at net.minecraft.server.v1_12_R1.MinecraftServer.run(MinecraftServer.java:577)
[22:48:37] [Server thread/WARN]: 	at java.lang.Thread.run(Thread.java:748)
[22:48:37] [Server thread/ERROR]: null
org.bukkit.command.CommandException: Unhandled exception executing command 'quests' in plugin Quests v3.3.0-b300
	at org.bukkit.command.PluginCommand.execute(PluginCommand.java:46) ~[Spigot.jar:git-Spigot-eadd615-4509a14]
	at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:141) ~[Spigot.jar:git-Spigot-eadd615-4509a14]
	at org.bukkit.craftbukkit.v1_12_R1.CraftServer.dispatchCommand(CraftServer.java:648) ~[Spigot.jar:git-Spigot-eadd615-4509a14]
	at net.minecraft.server.v1_12_R1.PlayerConnection.handleCommand(PlayerConnection.java:1397) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at net.minecraft.server.v1_12_R1.PlayerConnection.a(PlayerConnection.java:1232) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at net.minecraft.server.v1_12_R1.PacketPlayInChat.a(PacketPlayInChat.java:45) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at net.minecraft.server.v1_12_R1.PacketPlayInChat.a(PacketPlayInChat.java:1) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at net.minecraft.server.v1_12_R1.PlayerConnectionUtils$1.run(SourceFile:13) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_162]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_162]
	at net.minecraft.server.v1_12_R1.SystemUtils.a(SourceFile:46) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at net.minecraft.server.v1_12_R1.MinecraftServer.D(MinecraftServer.java:748) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at net.minecraft.server.v1_12_R1.DedicatedServer.D(DedicatedServer.java:406) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at net.minecraft.server.v1_12_R1.MinecraftServer.C(MinecraftServer.java:679) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at net.minecraft.server.v1_12_R1.MinecraftServer.run(MinecraftServer.java:577) [Spigot.jar:git-Spigot-eadd615-4509a14]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.lang.String.substring(String.java:1967) ~[?:1.8.0_162]
	at me.blackvein.quests.Quests.questsTop(Quests.java:1440) ~[?:?]
	at me.blackvein.quests.Quests.questActionsCommandHandler(Quests.java:1355) ~[?:?]
	at me.blackvein.quests.Quests.onCommand(Quests.java:712) ~[?:?]
	at org.bukkit.command.PluginCommand.execute(PluginCommand.java:44) ~[Spigot.jar:git-Spigot-eadd615-4509a14]
	... 15 more

(Optional) Can you provide an example quest from quests.yml using Pastebin.com?
N/A

I could be mistaken, but do you have a folder named "old" in your Quests/data directory? Might be interfering with the way Quests cycles through files.

Looks like that was doing it, thanks!


MATS 2.0 Needed Non-CPMS Crosscheck and Lookup Changes

Needed Crosscheck Changes
Formula Parameter and Component Type and Basis to Formula Code (Cross_Chk_Catalog_Id 16):

Change Parameter Code to "PM" for rows where Parameter Code equals "PMRE" and Formula Code  equals "11-3", "11-16", "11-34", "11-37" or "11-46".
Remove rows where Parameter Code equals "PMRH" and Formula Code  equals "11-3", "11-16", "11-34", "11-37" or "11-46".

Method Parameter Equivalent (Cross_Chk_Catalog_Id 97):

Add row for Parameter Code "PMRE", Equivalent Code: "PMRH"
Add row for Parameter Code "PMRH", Equivalent Code: "PMRE"

Confirm that this cross check is actually missing.

Method Parameter to Method to System Type (Cross_Chk_Catalog_Id 8):

Add row for Parameter Code equal to "OP", Component Type And Basis equal to "COM", and Formula Code equal to "PM"

Parameter Code to Control Code for Unit Control (Cross_Chk_Catalog_Id 114):

Add row for Parameter Code equal to "PM" and Control Code equal to "B"
Add row for Parameter Code equal to "PM" and Control Code equal to "ESP"
Add row for Parameter Code equal to "PM" and Control Code equal to "HESP"
Add row for Parameter Code equal to "PM" and Control Code equal to "WESP"

Confirm that this cross check is actually missing.

Parameter Method to Formula (Actual Table):

Change Formula List to "F-28" row where Parameter Code equals to "NOX" and Method Code equals "CALC"

Parameter to Category (Cross_Chk_Catalog_Id 11):

Add row for Parameter Code equal to "PM" and Category Code equal to "FORMULA"

Program Parameter to Method Parameter (Cross_Chk_Catalog_Id 85):

Update row with Program Parameter Code equal to "PM" changing Method Parameter List to "PMRE,PMRH,PM" (Confirm that PMPMA and PMPMC should be removed.)
Determine whether the "MATSSUP" should be included in the Method Parameter List for pre January 1, 2024.

Needed Lookup Changes
Control Equipment Parameter Code

Add row for Control Equipment Parameter Code "PM" with Description of "Particulate Matter"

Equation Code

Remove row for Equation Code "F-29" and "K-5". (Not actually a MATS 2.0 change)

Parameter UOM

Add row with Param Id of "142", Parameter Code of "PMRE", UOM Code of "LBMWH", and null for all other columns.
Add row with Param Id of "143", Parameter Code of "PMRH", UOM Code of "LBMMBTU", and null for all other columns.

Acceptance Criteria

link to existing JIRA tickets for acceptance tests

Notes
Created from https://github.com/US-EPA-CAMD/easey-ui/issues/6119 research.

@djw4erg @esaber76 This needs acceptance criteria, but otherwise looks to be ready for development.

@lgiannini1 please find and link the correct JIRA tickets in the Acceptance Criteria section.  When you are done, please reassign to Dwayne and update the sprint to Sprint 12.


removal code is executed when removing an none-existent container

removing an already deleted container results in this error message:
root@status /e/nixos# nixcloud-container destroy test4
Container is not defined
rm: cannot remove '/nix/var/nix/profiles/nixcloud-container/test4/profile': No such file or directory
/nix/store/bfdk82qwrzly47h1a50nn4mak8jykr2y-nixcloud-container-0.0.1/bin/.nixcloud-container-wrapped: line 140: unset: `ips[]': not a valid identifier

fixed in https://github.com/nixcloud/nixcloud-container/commit/6c3d330560e52e7508f439cb7556ba2b62cb0cb4


Missing dependencies in docker image causing netclient to conclude there is no iptables/firewall support

In https://github.com/gravitl/netclient/issues/307 we found missing packages can cause netclient to conclude there is no iptables/firewall support
Initially with versions v0.18.0/19.0 the error was triggered by the missing 'wg' binary for which package wireguard-tools is needed.  (it's used in the endpoint startup script too on cleanup)
With v0.20.0 adding the wireguard-tools package was not enough anymore. Now it seems missing the ip6tables package causes netclient to conclude there is no iptables/firewall support.
For now it seems to work with this workaround in the docker compose file
entrypoint: bash -c "apk add wireguard-tools ip6tables; /bin/bash netclient.sh"

So two requests here:

Add these packages in the docker image or remove the dependency if possible.
Make netclient more verbose about the reason it concludes there is no iptables/firewall support

netclient docker images include iptables and iptables56


Add module anvil-recyclerview-v7 to support RecyclerView

Example

            recyclerView(() -> {
                size(MATCH, MATCH);
                hasFixedSize(true);
                linearLayoutManager();
                defaultItemAnimator();
                adapter(adapter);
            });

Thanks for the contribution! Looks pretty good to me but just a heads up that such a module already exists (https://github.com/trikita/anvil-recyclerview) and was going to be brought into the fold but I guess this is good too.
Also I'm not quite convinced about the naming of the base DSL for RecyclerView - I was envisaging something like BaseRecyclerViewDSL and then making RecyclerViewDSL inherit from it as this is how the SDK is implemented as well. That may require some changes to the code generator though.

Sorry, I didn't know that such a module already exists. But I think this module should be in the main repository it's more clear.
You are right about BaseRecyclerViewDSL and I have done it. PR is updated. Check please.

@dirong Do you mind if I merge this and then replace the adapter with something closer to anvil-recyclerview implementation? I personally would replace the Item interface with an existing (and semantically identical RenderableAdapter.Item) to make these adapters compatible. Also, I'd make abstract view method take ViewHolder as an argument instead of an index (in RecyclerViews it seems that ViewHolders are more meaningful  and natural than indices).


[scripts-audit] Make buildsystem (port)

Comply with the regulations in https://github.com/microsoft/vcpkg/blob/master/docs/maintainers/cmake-guidelines.md

[x] Convert functions and variables
[x] remove/deprecate ENABLE_INSTALL (depending on whether it's used) (see also INSTALL_TARGET)
No because some port's makefile doesn't contains install command.
[x] look and see if MAKEFILE is used usefully vs SUBPATH; if not, deprecate/remove depending on whether it's used
Yes, will do this job after https://github.com/microsoft/vcpkg/pull/20090 merge.
[x] Modify docs
[x] Improve code
[x] Test
[x] Depends on PR https://github.com/microsoft/vcpkg/pull/20165

Related: #16188.

Could you please do the script audit of the vcpkg_*_make commands first? The vcpkg_make_* commands are also necessary, but we should do the scripts in the scripts/cmake folder first.

@strega-nil-ms  Yeah going to do that.

Will continue this after https://github.com/microsoft/vcpkg/pull/20165 merge.

This PR hasn't seen team feedback in three weeks. What is the time frame for getting this finished? How to deal with improvements to the existing maintainer functions which still have dead code, redundant code, underused parallelization, and other deficencies?
Either this PR is finished quickly (with existing maintainer function behaviour as a starting point) so that changes can focus on the new port alone, or we will have to waste extra time on duplicating and merging changes.

@dg0yt  Sorry, I don't have much time, and I will handle this PR this week.

Okay, thanks.
For future maintainability:
vcpkg_configure_make and vcpkg_build_make cooperate by side effects and convention. Example: the name of the build directories.
Does it make sense to turn everything into explicit parameter passing?
Are any (environment) variables which are modified in the configure function allowed to have an effect on the build function?

@dg0yt

Does it make sense to turn everything into explicit parameter passing?

For example?

Are any (environment) variables which are modified in the configure function allowed to have an effect on the build function?

For this one, I think we should follow vcpkg_*_make.

Does it make sense to turn everything into explicit parameter passing?

For example?

In the first place: the name of the build directory?

Are any (environment) variables which are modified in the configure function allowed to have an effect on the build function?

For this one, I think we should follow vcpkg_*_make.

ATM it is not obvious if vcpkg_configure_make resets all environment variables that it modifies, due to "code diversity". I need to know if not resetting some variables is intentional or a bug.
To combine both points, the make function duplicates some of the code of the configure function because things are not passed from one to another.

Close this PR temporary.


Minimum loss algo in cpp

Solved issue #(your issue number)
In Language- C++

[x] Updated README Link
[x] Added code with comments

Thanks for contributing!

At First, specify your issue number.


Add software regression tests

Summary:
We don't have software regression tests in place. We should introduce them and test them.
Description:
More accurately, we could use some characterization tests.
Here are a few things that we should test:

[ ] reproducibility between runs with the same seed for some models (tbd)
[ ] reproducibility across different commits with some models (tbd)

It's ok that things change over time. We just don't ever want the changes to happen unintentionally.
(There's no reason we can't characterize Stan's behavior before we agree on how to test correctness in light of stochastic algorithms. Once a random seed is set [with a particular set of hardware, environment, etc], it should run the same.)
Current Version:
v2.15.0

I've worked with these kinds of tests before (we called them "golden tests" or something like that) and they were a huge pain until we developed automated tools to update the golden records.

Have any suggestions on how to update golden records?
I'd rather have difficult tests over breaking things inadvertently. This comes from having things being broken multiple times through the history of our project from something that wasn't caught in unit tests.

On Jun 17, 2017, at 11:00 AM, seantalts<EMAIL_ADDRESS>wrote:
I've worked with these kinds of tests before (we called them "golden tests" or something like that) and they were a huge pain until we developed automated tools to update the golden records.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

 Each test file had a corresponding output file, I think. When running a test, record its output to a temporary file, check it against the golden record, and fail if there's a diff and display the diff. We added a flag to the test binaries (ours could be in runTests.py instead) that would not do asserts or checks but would just replace the golden records with whatever the tests were currently outputting. This was kind of nice because these records were stored in git with the same code that produced them, so when you updated code you could see in the same commit how the output had changed, or if it hadn't.

That sounds great! We just need to deal with the platform dependence, but maybe we can work through that by storing different outputs.

 Each test file had a corresponding output file, I think. When running a test, record its output to a temporary file, check it against the golden record, and fail if there's a diff and display the diff. We added a flag to the test binaries (ours could be in runTests.py instead) that would not do asserts or checks but would just replace the golden records with whatever the tests were currently outputting. This was kind of nice because these records were stored in git with the same code that produced them, so when you updated code you could see in the same commit how the output had changed, or if it hadn't.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

When sampling algorithms broke in the past, it was because algorithms changed.  Those changes intentionally break any regressions that are trying to measure reproducibility at the floating point/seed level.  So I don't see how this kind of test could have caught the sampler bugs.  I think what we want to focus on for this is the kind of testing Michael has up in the testing repo.
We may also want regression tests for efficiency.  Again, those are challenging in the face of stochastic algorithms with intentionally changing behavior.
Regressions would be able to catch the bugs introduced into interfaces, such as losing warning messages during initialization or in the parser when a model becomes unparseable (though the latter is easy to test within Stan).

This would be in addition to the statistical correctness tests. If we are serious about having more contributors, we have to make sure things don't inadvertently change.
For example, if we changed a warning message, I would not expect any draws to be different. When we added file includes, I also expect nothing to change for the draws. If they do, then at the very least we should know about it. These are things that are going to be harder to catch at the unit level.
Most changes shouldn't cause different behavior. I see things like algorithmic changes, some updates to libraries, and bug fixes causing differences between a run with the previous hash. Refactoring, changes to autodiff memory handling, new functions, and most language updates shouldn't. When they do, it'd be nice to know that it does and the developer should think about whether it makes sense that it does.

On Jun 17, 2017, at 3:08 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:
When sampling algorithms broke in the past, it was because algorithms changed. Those changes intentionally break any regressions that are trying to measure reproducibility at the floating point/seed level. So I don't see how this kind of test could have caught the sampler bugs. I think what we want to focus on for this is the kind of testing Michael has up in the testing repo.
We may also want regression tests for efficiency. Again, those are challenging in the face of stochastic algorithms with intentionally changing behavior.
Regressions would be able to catch the bugs introduced into interfaces, such as losing warning messages during initialization or in the parser when a model becomes unparseable (though the latter is easy to test within Stan).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

My main concern is with the stability of our code base. If I can't trust that code runs the same merging with develop, then it gets harder and harder to have distributed development.

If there's any other / easier way of accomplishing it, please suggest it. I don't think golden tests are ideal, but if there isn't a viable alternative, I'd rather have it than not have it.

@syclik  I'm not arguing that these "golden tests" aren't necessary, I'm arguing they aren't sufficient.  They wouldn't have caught the problem with output disappearing. They won't catch performance regressions for time or memory.
I do see two problems with these golden tests.  The first is that it becomes massively painful to make minor updates like fixing typos in messages.  When those are recorded all over the place, all the gold tests need to be regenerated. I think that's what @seantalts was getting at.  The second problem is that if it's easy to generate new tests, it'll be easy to miss things by regenerating the tests too frequently.  If you and he manage to get them going, we'll have to see how that goes.
Testing is a delicate balance when it comes to distributed development. I don't think more is always better, at least insofar as recruiting more developers is concerned.  There are many obstacles in the way of contributors:  the complexity of the C++, the relative lack of documentation, the constantly changing underlying organization of the code base, our rather scattershot and inconsistent approach to code review (particularly getting conflicting feedback), the fact that code to do one thing can be spread over a half dozen files, and the extensive testing we require before merging.
And no, I don't have good alternatives to propose.

I think if @syclik wants to add tooling such that regenerating golds is just an extra flag to runTests.py, it could become minimally invasive? We also probably wouldn't just gold all existing tests; rather it seems like we'd make some new tests specifically for this purpose. But Bob is also right in that every thing like this just adds additional hurdles to contributions. It'd be great if we could replace some of our existing tests or process with this new kind as a tradeoff to try to keep developer burden low.

Having golden tests or regression tests is all well and good, but
as Bob and Sean have noted they can be a massive burden on
new developers.  Not only do they stale easily and require constant
updates, it’s not even clear to the developer what changes might
cause those tests to break.  So not only would we need code to
autogenerate new tests (I ended up writing a bunch of scripts to
do that for the stan_read_csv function with has such tests) we
would need some kind of hook that sees if any files changed
correspond to a given golden test and warn the submitter that
the test might need to be updated (ideally as easily as running an
existing script and if the golden test changed then adding it to the
PR).

On Jun 18, 2017, at 12:28 PM, seantalts<EMAIL_ADDRESS>wrote:
I think if @syclik https://github.com/syclik wants to add tooling such that regenerating golds is just an extra flag to runTests.py, it could become minimally invasive? We also probably wouldn't just gold all existing tests; rather it seems like we'd make some new tests specifically for this purpose. But Bob is also right in that every thing like this just adds additional hurdles to contributions. It'd be great if we could replace some of our existing tests or process with this new kind as a tradeoff to try to keep developer burden low.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/2331#issuecomment-309287881, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdNllyB4D_a_GdEwBtZwKdQdlz2nXHaks5sFVBIgaJpZM4N9G3c.

I hear the arguments for it being a burden. But I think we're framing it the wrong way.
It should be seen as something to make sure the rest of Stan isn't broken. It's more objective in what is and isn't included for code. And it keeps the code base moving forward. For new developers, it should be a relief that the first thing they're trying to contribute isn't going to tank the code base.
Yes, we need to design it so it's not a burden. We can take that as a requirement. We should also cap the run time somehow.
The old tests weren't designed with this in mind. It was just something quick that I threw up to make sure we didn't introduce things that tanked the speed. Then after having behavior change and introducing major bugs where we scrambled and backtracked on releases, I tacked on checking consistency across different runs. I'm still glad it's been checked pretty regularly. It's stopped at least a handful of subtle bugs from going out since it's been in. Most of the time, this hasn't been a burden on the developer because it runs with our contiuous integration and we didn't ask devs to run it locally. For most pull requests, it isn't even something we have to think about. It's really helped to identify pull requests that needed further review beyond just inspecting code. Once again, intentionally changing behavior is ok to me. Accidentally changing how Stan works and letting that slide isn't. (Michael, sorry it's slowed down some of your work. That wasn't the intent.)

On Jun 18, 2017, at 11:53 PM, Michael Betancourt<EMAIL_ADDRESS>wrote:
Having golden tests or regression tests is all well and good, but
as Bob and Sean have noted they can be a massive burden on
new developers. Not only do they stale easily and require constant
updates, it’s not even clear to the developer what changes might
cause those tests to break. So not only would we need code to
autogenerate new tests (I ended up writing a bunch of scripts to
do that for the stan_read_csv function with has such tests) we
would need some kind of hook that sees if any files changed
correspond to a given golden test and warn the submitter that
the test might need to be updated (ideally as easily as running an
existing script and if the golden test changed then adding it to the
PR).

On Jun 18, 2017, at 12:28 PM, seantalts<EMAIL_ADDRESS>wrote:
I think if @syclik https://github.com/syclik wants to add tooling such that regenerating golds is just an extra flag to runTests.py, it could become minimally invasive? We also probably wouldn't just gold all existing tests; rather it seems like we'd make some new tests specifically for this purpose. But Bob is also right in that every thing like this just adds additional hurdles to contributions. It'd be great if we could replace some of our existing tests or process with this new kind as a tradeoff to try to keep developer burden low.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/2331#issuecomment-309287881, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdNllyB4D_a_GdEwBtZwKdQdlz2nXHaks5sFVBIgaJpZM4N9G3c.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Your description is far too subjective and illustrates the asymmetric
nature of the burden of these tests.    And I
was expecting it!  Especially bad was at one point the tests were being
run on a machine that gave different bitwise behavior than a Mac and
I had to wait for the test to run on Jenkins to see which new values I
needed to put into the tests for the CI to pass.
The point is that our testing is littered with fragile tests like this that
were put in as overreactions to bugs.  It was one thing when you were
around full time to escort each PR through those tests, but they evolve
from annoyance to dangerous burden when you cannot commit your
full time to watching them.
So, again, while some golden/regression tests are welcome the burden
is on you to put together a manageable system with hooks to identify
when tests might need to be updated and scripts to automatically do
that updating before anything new is added to the test framework.

On Jun 19, 2017, at 12:36 AM, Daniel Lee<EMAIL_ADDRESS>wrote:
I hear the arguments for it being a burden. But I think we're framing it the wrong way.
It should be seen as something to make sure the rest of Stan isn't broken. It's more objective in what is and isn't included for code. And it keeps the code base moving forward. For new developers, it should be a relief that the first thing they're trying to contribute isn't going to tank the code base.
Yes, we need to design it so it's not a burden. We can take that as a requirement. We should also cap the run time somehow.
The old tests weren't designed with this in mind. It was just something quick that I threw up to make sure we didn't introduce things that tanked the speed. Then after having behavior change and introducing major bugs where we scrambled and backtracked on releases, I tacked on checking consistency across different runs. I'm still glad it's been checked pretty regularly. It's stopped at least a handful of subtle bugs from going out since it's been in. Most of the time, this hasn't been a burden on the developer because it runs with our contiuous integration and we didn't ask devs to run it locally. For most pull requests, it isn't even something we have to think about. It's really helped to identify pull requests that needed further review beyond just inspecting code. Once again, intentionally changing behavior is ok to me. Accidentally changing how Stan works and letting that slide isn't. (Michael, sorry it's slowed down some of your work. That wasn't the intent.)

On Jun 18, 2017, at 11:53 PM, Michael Betancourt<EMAIL_ADDRESS>wrote:
Having golden tests or regression tests is all well and good, but
as Bob and Sean have noted they can be a massive burden on
new developers. Not only do they stale easily and require constant
updates, it’s not even clear to the developer what changes might
cause those tests to break. So not only would we need code to
autogenerate new tests (I ended up writing a bunch of scripts to
do that for the stan_read_csv function with has such tests) we
would need some kind of hook that sees if any files changed
correspond to a given golden test and warn the submitter that
the test might need to be updated (ideally as easily as running an
existing script and if the golden test changed then adding it to the
PR).

On Jun 18, 2017, at 12:28 PM, seantalts<EMAIL_ADDRESS>wrote:
I think if @syclik https://github.com/syclik wants to add tooling such that regenerating golds is just an extra flag to runTests.py, it could become minimally invasive? We also probably wouldn't just gold all existing tests; rather it seems like we'd make some new tests specifically for this purpose. But Bob is also right in that every thing like this just adds additional hurdles to contributions. It'd be great if we could replace some of our existing tests or process with this new kind as a tradeoff to try to keep developer burden low.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/2331#issuecomment-309287881, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdNllyB4D_a_GdEwBtZwKdQdlz2nXHaks5sFVBIgaJpZM4N9G3c.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/2331#issuecomment-309336704, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdNln-EckFm64D2205HXM8NMpxZdW3Sks5sFfrrgaJpZM4N9G3c.

On Jun 19, 2017, at 8:43 AM, Michael Betancourt<EMAIL_ADDRESS>wrote:
Your description is far too subjective and illustrates the asymmetric
nature of the burden of these tests.  And I
was expecting it! Especially bad was at one point the tests were being
run on a machine that gave different bitwise behavior than a Mac and
I had to wait for the test to run on Jenkins to see which new values I
needed to put into the tests for the CI to pass.

Those tests could have been replaced by better ones and if you asked for help, I would have gladly helped you get that off the ground. Once again, sorry it was a pain, but the usefulness of those tests in preventing gross errors outweigh your particular pain.
So, instead of just complaining, want to help describe what would be useful and what would be unwieldy?

The point is that our testing is littered with fragile tests like this that
were put in as overreactions to bugs. It was one thing when you were
around full time to escort each PR through those tests, but they evolve
from annoyance to dangerous burden when you cannot commit your
full time to watching them.

I don't know where to start here. My job was never to escort bad pull requests. I did it as someone that cares about the community and the project. It was necessary at the time. Since I'm no longer at Columbia full time, it's even more important that the devs (the collection of all of us) maintain confidence in the project. This isn't and hasn't been a sandbox for Columbia / Andrew's research group for quite some time now.

So, again, while some golden/regression tests are welcome the burden
is on you to put together a manageable system with hooks to identify
when tests might need to be updated and scripts to automatically do
that updating before anything new is added to the test framework.

Yup. That's what I agreed to a few comments ago.

On Jun 19, 2017, at 12:36 AM, Daniel Lee<EMAIL_ADDRESS>wrote:
I hear the arguments for it being a burden. But I think we're framing it the wrong way.
It should be seen as something to make sure the rest of Stan isn't broken. It's more objective in what is and isn't included for code. And it keeps the code base moving forward. For new developers, it should be a relief that the first thing they're trying to contribute isn't going to tank the code base.
Yes, we need to design it so it's not a burden. We can take that as a requirement. We should also cap the run time somehow.
The old tests weren't designed with this in mind. It was just something quick that I threw up to make sure we didn't introduce things that tanked the speed. Then after having behavior change and introducing major bugs where we scrambled and backtracked on releases, I tacked on checking consistency across different runs. I'm still glad it's been checked pretty regularly. It's stopped at least a handful of subtle bugs from going out since it's been in. Most of the time, this hasn't been a burden on the developer because it runs with our contiuous integration and we didn't ask devs to run it locally. For most pull requests, it isn't even something we have to think about. It's really helped to identify pull requests that needed further review beyond just inspecting code. Once again, intentionally changing behavior is ok to me. Accidentally changing how Stan works and letting that slide isn't. (Michael, sorry it's slowed down some of your work. That wasn't the intent.)

On Jun 18, 2017, at 11:53 PM, Michael Betancourt<EMAIL_ADDRESS>wrote:
Having golden tests or regression tests is all well and good, but
as Bob and Sean have noted they can be a massive burden on
new developers. Not only do they stale easily and require constant
updates, it’s not even clear to the developer what changes might
cause those tests to break. So not only would we need code to
autogenerate new tests (I ended up writing a bunch of scripts to
do that for the stan_read_csv function with has such tests) we
would need some kind of hook that sees if any files changed
correspond to a given golden test and warn the submitter that
the test might need to be updated (ideally as easily as running an
existing script and if the golden test changed then adding it to the
PR).

On Jun 18, 2017, at 12:28 PM, seantalts<EMAIL_ADDRESS>wrote:
I think if @syclik https://github.com/syclik wants to add tooling such that regenerating golds is just an extra flag to runTests.py, it could become minimally invasive? We also probably wouldn't just gold all existing tests; rather it seems like we'd make some new tests specifically for this purpose. But Bob is also right in that every thing like this just adds additional hurdles to contributions. It'd be great if we could replace some of our existing tests or process with this new kind as a tradeoff to try to keep developer burden low.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/2331#issuecomment-309287881, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdNllyB4D_a_GdEwBtZwKdQdlz2nXHaks5sFVBIgaJpZM4N9G3c.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/2331#issuecomment-309336704, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdNln-EckFm64D2205HXM8NMpxZdW3Sks5sFfrrgaJpZM4N9G3c.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I think we can all agree that we released broken code that might have been caught with the right tests.  Just to remind everyone, two relevant cases are:

breaking changes to the samplers

losing error output when the sampler catches an exception

Gold tests would catch the latter, but not the former.
I also think we can all agree that the current brittle tests are a pain point for developers.
The decision on how to move forward spans repos.  We are not being consistent about testing practices across repos.

There's one more relevant test case:

changes to the code base that pass unit tests, but change behavior in the
samplers due to some side-effects.

Gold tests would also catch that even in light of weak unit tests. We've
already stopped a handful of those accidentally getting into the code base.
On Mon, Jun 19, 2017 at 12:37 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

I think we can all agree that we released broken code that might have been
caught with the right tests. Just to remind everyone, two relevant cases
are:

breaking changes to the samplers
losing error output when the sampler catches an exception
Gold tests would catch the latter, but not the former.
I also think we can all agree that the current brittle tests are a pain
point for developers.
The decision on how to move forward spans repos. We are not being
consistent about testing practices across repos.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/stan/issues/2331#issuecomment-309496003, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_FyOymqn6lOJiC0F5xcNUUP2q63DJks5sFqOtgaJpZM4N9G3c
.

In reading this I see a few meta-issues floating to the top and have some questions and observations.

Have you all mind-melded with the proposal? Everyone that has commented so far is totally up to date on characterization tests that were helpfully linked right? I didn't have a clue what they were. I went and reviewed the regression test page just because I wanted to be better mind-melded with Daniel's proposal--lord knows what those Wikipedia jerks have come up with and apparently Daniel believes it so better check it out.

Characterization tests are not about correctness but about comparing what happened before with what happened with a different/new branch. Crude, perhaps useful, very automatable and more about diff scanning than anything else.

Existential risk dimension: What is the ordering, preordering fine, of risks to Stan if we do/don't adopt some form of characterization tests? Here are a few that got mentioned and this is my ordering:
Release crap version that has to be backed out which undermines the project and in the end trust >
Make life hard for external contributors > Make life hard for core contributors ?<>?  {insert your worry here}. The ordering is independent of issue and I just invented the confused spaceship operator.

The back and forth got a little snippy there.

Overall we need a process that makes decisions in some sane fashion. In open source it seems like the preferred ordering is consensus > consensus with individual grumbling > vote > fork. I don't see any benevolent dictators at this point. A separate discussion but one we need to have.
Breck
PS What do I think makes the most sense? Do dumb, automated characterization testing on verbose system output just to catch what units tests don't and make Sean do it since he is too nice to say no. We can't release broken software folks.

On Jun 19, 2017, at 1:24 PM, Daniel Lee<EMAIL_ADDRESS>wrote:
There's one more relevant test case:

changes to the code base that pass unit tests, but change behavior in the
samplers due to some side-effects.

Gold tests would also catch that even in light of weak unit tests. We've
already stopped a handful of those accidentally getting into the code base.

Thanks---that's a good case that the gold tests would catch.
Change to something other than samplers that aren't intended to
change sampling behavior, but in fact break sampling behavior.
I don't recall that happening, but I can see how it could.

On Jun 19, 2017, at 6:46 PM, breckbaldwin<EMAIL_ADDRESS>wrote:
In reading this I see a few meta-issues floating to the top and have some questions and observations.
• Have you all mind-melded with the proposal? Everyone that has commented so far is totally up to date on characterization tests that were helpfully linked right?

I think we're all on the same page.  The discussion is around what it
would look like in practice, specifically:

how easily it could be automated

whether it would catch any errors

• The back and forth got a little snippy there.

Agree with the sentiment if not its expression.

Overall we need a process that makes decisions in some sane fashion. In open source it seems like the preferred ordering is consensus > consensus with individual grumbling > vote > fork. I don't see any benevolent dictators at this point. A separate discussion but one we need to have.

I think we may be at the consensus with grumbling stage here,
but I'm not sure.  I'm willing to give it a try.
I also agree that broken software is worse than grumbling developers,
but it's a matter of degree.  If it gets too hard to work on
Stan, people will just quit.  I've felt near that point myself on
several occasions, because it's gotten very time consuming to
produce even the simplest code change.  Major changes, like the refactor
Daniel took on, took years.  The reason it took so long is that
he insisted on having these tests (though apparently, they weren't
thorough enough, because we still broke the software).
This isn't magic.  Unless we have the right programs to run that
tickle the right output, they won't be testing everything.  Now
we know to include cases where initialization can't get off the
ground.  But what else are we missing?  Do we include a test for
all N^K possible combinations of arguments to each interface function?
The other issue is where to test these things at.  We're on the
Stan repo now, but Stan itself doesn't do any of this.  We need
an interface to plug into the callbacks before we even have output
to test again.

PS What do I think makes the most sense? Do dumb, automated characterization testing on verbose system output just to catch what units tests don't and make Sean do it since he is too nice to say no. We can't release broken software folks.

The question isn't whether we'll release broken software. Bugs happen.
The question is what's the cost of bugs vs. the cost of slowing down
development.  I don't think there's a simple answer and I think I'm
between Michael and Daniel on this, closer to Daniel's opinion.

Bob

If we go down this golden test route it would be helpful to also put future
math tests in that sort of format.  So far changing special functions I've
had to update a lot of very specific calculations that should just live in
a table with doc on the source.  Weirdly enough it seems like a lot of the
old implementations wouldn't pass tests with the new test values even
though I got the new test values from outside sources (mostly
Mathematica).  It's a little disconcerting but with no sourcing on the old
values I can't figure out why reference implementations might have
different answers.
On Mon, Jun 19, 2017 at 8:23 PM Bob Carpenter<EMAIL_ADDRESS>wrote:

On Jun 19, 2017, at 6:46 PM, breckbaldwin<EMAIL_ADDRESS>wrote:
In reading this I see a few meta-issues floating to the top and have
some questions and observations.
• Have you all mind-melded with the proposal? Everyone that has
commented so far is totally up to date on characterization tests that were
helpfully linked right?

I think we're all on the same page. The discussion is around what it
would look like in practice, specifically:

how easily it could be automated

whether it would catch any errors

• The back and forth got a little snippy there.

Agree with the sentiment if not its expression.

Overall we need a process that makes decisions in some sane fashion. In
open source it seems like the preferred ordering is consensus > consensus
with individual grumbling > vote > fork. I don't see any benevolent
dictators at this point. A separate discussion but one we need to have.

I think we may be at the consensus with grumbling stage here,
but I'm not sure. I'm willing to give it a try.
I also agree that broken software is worse than grumbling developers,
but it's a matter of degree. If it gets too hard to work on
Stan, people will just quit. I've felt near that point myself on
several occasions, because it's gotten very time consuming to
produce even the simplest code change. Major changes, like the refactor
Daniel took on, took years. The reason it took so long is that
he insisted on having these tests (though apparently, they weren't
thorough enough, because we still broke the software).
This isn't magic. Unless we have the right programs to run that
tickle the right output, they won't be testing everything. Now
we know to include cases where initialization can't get off the
ground. But what else are we missing? Do we include a test for
all N^K possible combinations of arguments to each interface function?
The other issue is where to test these things at. We're on the
Stan repo now, but Stan itself doesn't do any of this. We need
an interface to plug into the callbacks before we even have output
to test again.

PS What do I think makes the most sense? Do dumb, automated
characterization testing on verbose system output just to catch what units
tests don't and make Sean do it since he is too nice to say no. We can't
release broken software folks.

The question isn't whether we'll release broken software. Bugs happen.
The question is what's the cost of bugs vs. the cost of slowing down
development. I don't think there's a simple answer and I think I'm
between Michael and Daniel on this, closer to Daniel's opinion.

Bob

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/stan/issues/2331#issuecomment-309609178, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfA6YObPFNp8B2YV3T39a1vHhM-LiQAks5sFxD0gaJpZM4N9G3c
.

Sorry for the tone of my post, cold medicine was not helping but seriously sorry.
From what I can see characterization tests should be low effort on the contributor's part. If they are not it is a nightmare and no one is advocating for anything but an automatic process. It would most likely run from a test script that setup git commits etc if the contributor has usefully changed system output.
I think there is consensus that the tests will catch useful errors.
I think there is consensus that similar previous testing systems had problems.
I suggest that we keep the interfaces and more difficult regression tests out of the discussion for now.
A new developer facing a failed characterization test is deep water most likely since failed code will be remote to what they just tested.
The issue is cost of implementation. If Stan could have characterization tests for free and no hassle then we would do it right?
There is a Java JUnit charcterization test system that may have useful guidance if we rolled our own.
A potentially lower overhead characterization test system would be to just use the existing unit testing frame work but with developer added values that are known to be from a successful runs rather than known to be correct values. Could turn nightmarish quickly if tests are dependent on Stan program values.
I'll look into some possible implementations and report back.

I'd rather not literally annotate the source, but I am going to switch all the tests so that they basically look like this:
https://github.com/stan-dev/math/blob/fca2a772f75e2bbc10c76380b0c5e33bf31e6fcc/test/unit/math/mix/core/operator_addition_test.cpp

W.r.t. https://github.com/stan-dev/stan/issues/2331#issuecomment-309797184, the problem with not having interface tests is that we need them for the characterization tests that @syclik is suggesting because stan-dev/stan doesn't have any output without implementing all the callbacks.  Or is there some way to do these I'm not seeing?
Upstream tests for stan-dev/stan should get kicked off, so we could plumb in interface tests that way.
The piece of the puzzle we're missing is autogenerating new characterization tests when things change on purpose.   I don't see how to test that only the intended changes are made.  So we'll still need unit-like tests for individual parts of the output.

@bob-carpenter: good points.
Fortunately, we should be able to test with just the Stan library using callbacks. We could also test with the interfaces.
Agrees that it's going to be hard making sure only parts of the output change. But I think whenever that happens, we should go and walk through those cases by hand anyway; if a change to the code base is changing the behavior for everything, it's probably a good thing that we observe the output for all the places it's changed.
I'll need a little more time to come up with a spec. I'll try to have it done next week.


feat: support CSI u sequence

Comprehensive keyboard handling in terminals
feat(tui): query terminal for CSI u support
Fix Keyboard Input on Terminals - Please
xterm modified-keys

An application can query the terminal for support of this protocol by sending the escape code querying for the [current progressive enhancement](https://sw.kovidgoyal.net/kitty/keyboard-protocol/#progressive-enhancement) status followed by request for the [primary device attributes](https://vt100.net/docs/vt510-rm/DA1.html). If an answer for the device attributes is received without getting back an answer for the progressive enhancement the terminal does not support this protocol.

refer foot for implementation

support CSI u query, set, push, pop. need to verify it's working for terminal.


Clean up managed reconciler tests

Description of your changes

No functional updates to the code here, just:

Tidying up the tests a bit to ensure they all mock out their various moving parts via options.
Adding a "reason" that explains each cases's purpose (and is printed when tests fail). Some of our test case names were getting super long, so I wanted to encode their purpose in a distinct string.

Checklist

I have:

[x] Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.
[ ] Updated any relevant documentation, examples, or release notes.
[ ] Updated the RBAC permissions in clusterrole.yaml to include any new types.

Thanks for the quick review @hasheddan!


Documentation

Could you add some user documentation to the wiki? I built Mundus from the Git repo, downloaded the MundusDemo project from the other Github project, but all I could figure out how to do was move the camera XYZ with the QWEASD keys. I installed (and tested) fbx-conv and pointed to it in Mundus settings, but still all OBJ imports failed, advising to pick the right file and set the right fbx-conv. Clicking Add Component didn't seem to add a component, etc. How to exercise these features (and whatever else, like procedural terrain generation, etc)?

Look at this issue ... it may help a little.  https://github.com/mbrlabs/Mundus/issues/46

Hello. I'm currently working on other projects, so i'm afraid this won't happen any time soon.
Ragarding your fbx-conv problem: it sounds like you did not save the settings after setting the fbx-conv binary. Try setting it, then save, then restart the editor and check if the fbx-conv is still set in the settings dialog. If that's the case, importing should work. Otherwise you found a bug ;)


animation is lagging on windows chrome only

i have created a website [Srijan'15] 1 which runs smoothly on IE and Firefox but is lagging very much on chrome.
What can i do to reduce the laggyness?

it's laggy on firefox too. (at least on my core i7 mac book pro)... A quick look at the code suggests you probably should use a spritesheet to load all your images, it optimises animation performance, and reduces http requests.
I suspect the real cause of slow animation is caused by the vector drawn clouds... try removing them and see if speed improves.... if you want to use them you can build a spritesheet at runtime using SpriteSheetBuilder.

Closing this, as it isn't an issue with the library. I recommend posting to StackOverflow if you have specific questions about how to get better performance.


Consider using Zstandard compression for cache artifacts

Facebook has a compression algorithm called Zstandard: https://facebook.github.io/zstd/
It seems to be much faster across the board than zlib, and it offers significant customizability wrt speed vs compression ratio.
The official implementation is native, but there are both JNI bindings for it  and a pure Java implementation available.
We could use the JNI-based variant for platforms that are supported (Windows, macOS and various architectures on Linux), and fall back to the Java-only variant for unsupported ones.

The above graph seems to suggest that different environments could benefit from different compression ratios, i.e. local builds could use something that compresses faster, while CI builds could use something that takes longer to compress to a smaller size, so downloads become faster. See also https://github.com/gradle/gradle/issues/12810.

cc: @gradle/build-cache

Note that the Java-only variant in Aircompressor 0.16 doesn't support JVMs using big-endian byte order. Not sure if this has any significant impact for us.

some thoughts:

zstd support streaming so you could start decompression while bytes are streaming in from the remote cache.

https://raw.githack.com/facebook/zstd/release/doc/zstd_manual.html#Chapter7

consider LZ4, which maybe a better tradeoff for some cases. https://lz4.github.io/lz4/
both LZ4 and zstd support a "training mode" where you can create dictionaries for certain files types (.class, .json, .xml, etc ). The custom dictionaries can provide much better ratio and faster compress/decompress speeds.

All of these are good points, though compression speed is only a small part of caching speed. We know of lower hanging fruit for a number of typical use cases that would improve caching performance more than switching compression. (One example is clean builds in a non-ephemeral CI environment, where we currently delete everything first, then unpack exactly the same outputs byte-for-byte again, which is completely useless.)
This will become more interesting if we switch to a CAS-based cache protocol, where each output file will have to be stored individually. In that scenario training modes will likely have a significant advantage.

zstd support streaming so you could start decompression while bytes are streaming in from the remote cache.

FTR, this could also work with our current TAR+GZip-based protocol.

FYI: latest release of zstd brought quite nice performance improvements: https://github.com/facebook/zstd/releases/tag/v1.5.4

Nice, we might be in the for some new compression algorithms soon!


Improve "Real Time" text visibility in Dark Mode

fixed #192
please add label level 3 if possible
This PR addresses a readability issue on the home page in Dark Mode, where the "Real Time" text was difficult to see due to low contrast with the background. The color has been adjusted to ensure sufficient contrast, improving text visibility and enhancing user experience across display modes.

@MastanSayyad

@vanshchauhan21 remove the levels


fix: expose error message directly if the request is wrong

Summary
fix MVAD error message
Tests
Add test cases
Dependency chances
None

/azp run

Codecov Report

Merging #1448 (fa9fcc4) into master (435e99c) will decrease coverage by 84.06%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master   #1448       +/-   ##
==========================================
- Coverage   84.58%   0.52%   -84.07%
==========================================
  Files         288     259       -29
  Lines       14335   13077     -1258
  Branches      701     712       +11
==========================================
- Hits        12125      68    -12057
- Misses       2210   13009    +10799

Impacted Files
Coverage Δ

...se/ml/cognitive/MultivariateAnomalyDetection.scala
0.00% <0.00%> (-88.84%)
:arrow_down:

...m/src/main/scala/com/microsoft/lightgbm/SWIG.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...ain/scala/org/apache/spark/ml/param/MapParam.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/scala/org/apache/spark/ml/param/UDPyFParam.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...cala/org/apache/spark/ml/NamespaceInjections.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...cala/org/apache/spark/ml/param/DataTypeParam.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...ala/org/apache/spark/ml/param/ByteArrayParam.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...ala/org/apache/spark/ml/param/EvaluatorParam.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...la/org/apache/spark/ml/param/ParamSpaceParam.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...la/org/apache/spark/ml/param/TypedArrayParam.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 272 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 435e99c...fa9fcc4. Read the comment docs.


fix: removing html tags from scheduleFragment

Fixes #1231
Changes:
Removal of html tags.
Screenshots for the change:

looks good to me


Authoritative Networking & Input Controllers

networking

[x] split networking.game.ts into more files
[x] added ringbuffers for network IO
[x] send input commands to host
[x] apply inbound network commands to peer input controllers
[x] create peer avatars as host
[x] create peer avatars as client
[x] host re-election

input

[x] refactored input to support multiple controllers

open issues to solve in future PRs:

occasionally in authoritative mode:

only the host correctly associates peerId with entityId
clients of the host do not correctly associate peerId with entityId
results in broken voip and nametags

setup/teardown of network module in order to swap between authoritative and p2p models during runtime

The network buffer isn't being processed when you aren't focused on the page. This is likely due to requestAnimationFrame not firing.


Add urbe.edu/urbe.edu.ve

@fguille94 First stage of verification passed, official domain is urbe.edu as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision. Proof of domain ownership: https://www.urbe.edu/portal-estudiantes/

@fguille94 Thank you for your patience while waiting for a review and processing your request. Pull request merged.


make set_trainable return its argument

This would allow it to clean up some model setup code, e.g.
model = VGP((X, Y), set_trainable(kernel, False), likelihood)

Can we close this - I hadnt seen @awav 's review but I agree


Restarting mysql causes docker container to exit

Started container with docker run -v /tmp/:/tmp --name percona -p 3344:3306 -e MYSQL_ROOT_PASSWORD=123 -d percona:5.7
and then docker exec -i -t percona bash
once inside the container every time i try to restart or to stop mysql /etc/init.d/mysql stop  causes docker container to stop and exit

That is the expected behavior of the container because there is no init system running within the container; mysqld is pid 1.
The initd script is killing pid 1 of the container and the kernel kills the rest of the container (and thus the init script itself is killed by the kernel before the script can continue).  To manage mysql lifecycle, use docker start, docker stop, or docker restart.  You could also use docker kill to send a specific signal as needed.


Bash doesn't pass SIGTERM to java process

This is from HS-514243459:

After doing some more digging, I believe the issue is that tini passes on SIGTERM to its child bash process (executing docker-entry.point.sh), but SIGTERM doesn’t get passed down to the Java process it invokes. Based upon https://github.com/krallin/tini/issues/72 and https://github.com/krallin/tini/issues/78 I created a lightly-modified “/docker-entrypoint.sh” that just prefixes the Java command with “exec”, making the Java process the direct child of tini. After implementing that on GRAYLOGSBSRV3 I verified Graylog shut down cleanly (respecting “GRAYLOG_LB_RECOGNITION_PERIOD_SECONDS” and gracefully stopping everything with accompanying log messages).

@juju2112 do you only release the docker image when there's a new version, or is it possible to cut a new image with this fix?

@juju2112 do you only release the docker image when there's a new version, or is it possible to cut a new image with this fix?

We have a scheduled bugfix release coming up pretty soon. I normally wait to build new images then. If the issue is critical and I get the product manager's blessing, then I do an unscheduled release.
I wasn't able to login to Hubspot, so I am not really able to guage the seriousness of it. I was pretty surprised to see this kind of issue though, and equally happy that the fix was so simple.

@coffee-squirrel We do a bug fix release once a month, on the first Wednesday of each month or the first business day following that day. If it's something critical, we'll normally just release it as soon as possible, provided it's been properly tested and is ready. Normally @kroepke or @boosty are "the deciders" there.

We had some issues with the 4.1.4 release, but I re-released 4.1.3. Use the tag graylog/graylog:4.1.3-3, and you should get the fix.


detect.py ERROR

python detect.py --weights ./checkpoints/yolov3-tiny.tf --tiny --image ./data/girl.png
W0706 03:01:45.838256<PHONE_NUMBER>93184 deprecation.py:506] From /usr/local/lib/python3.6/dist-packages/tensorflow/python/ops/init_ops.py:1251: calling VarianceScaling.init (from tensorflow.python.ops.init_ops) with dtype is deprecated and will be removed in a future version.
Instructions for updating:
Call initializer instance with the dtype argument instead of passing it to the constructor
2019-07-06 03:01:47.077830: I tensorflow/core/platform/profile_utils/cpu_utils.cc:94] CPU Frequency:<PHONE_NUMBER> Hz
2019-07-06 03:01:47.078112: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x16d4a00 executing computations on platform Host. Devices:
2019-07-06 03:01:47.078146: I tensorflow/compiler/xla/service/service.cc:175]   StreamExecutor device (0): ,
2019-07-06 03:01:47.158210: W tensorflow/compiler/jit/mark_for_compilation_pass.cc:1412] (One-time warning): Not using XLA:CPU for cluster because envvar TF_XLA_FLAGS=--tf_xla_cpu_global_jit was not set.  If you want XLA:CPU, either set that envvar, or use experimental_jit_scope to enable XLA:CPU.  To confirm that XLA is active, pass --vmodule=xla_compilation_cache=1 (as a proper command-line flag, not via TF_XLA_FLAGS) or set the envvar XLA_FLAGS=--xla_hlo_profile.
I0706 03:01:47.481413<PHONE_NUMBER>93184 detect.py:29] weights loaded
I0706 03:01:47.481828<PHONE_NUMBER>93184 detect.py:32] classes loaded
I0706 03:01:47.794163<PHONE_NUMBER>93184 detect.py:41] time: 0.30501627922058105
I0706 03:01:47.794389<PHONE_NUMBER>93184 detect.py:43] detections:
Traceback (most recent call last):
File "detect.py", line 56, in
app.run(main)
File "/usr/local/lib/python3.6/dist-packages/absl/app.py", line 300, in run
_run_main(main, args)
File "/usr/local/lib/python3.6/dist-packages/absl/app.py", line 251, in _run_main
sys.exit(main(argv))
File "detect.py", line 44, in main
for i in range(nums[0]):
TypeError: 'Tensor' object cannot be interpreted as an integer

I am getting this error as well. Did you find any solution @CnybTseng

I had this issue as well but then I realized it was because somewhere in the code I had used tf.compat.v1 to get the function from the version 1. Have a look if you are purely using TF v2.


Couple of comments on creating operator using an existing Helm chart

Open issue with:
The existing_helm_chart_operator.md works great, but couple of observations/nits?
1)
In order to keep the flow intact, may want to make small changes below:
a Kustomization.yaml for customizing manifests  - this file is not in the root dir like other files. May be better to say - “ a config directory containing kustomization.yaml"> ?
Same for the Patch files.
2)
export USERNAME=<docker-registry>

something like <docker-registry-userID>  (instead of <docker-registry>) ?

"Let's stops your WordPress web server wordpress-demo" - good idea to point to how to stop (something like Let's stop running following command...) Also stop instead of stops.

/cc @hickeyma

Thanks for the review comments @spzala.

In order to keep the flow intact, may want to make small changes below:
a Kustomization.yaml for customizing manifests - this file is not in the root dir like other files. May be better to say - “ a config directory containing kustomization.yaml"> ?
Same for the Patch files.

That's a good point. However, as it is just a listing off of what is provided from the scaffold and it is not an actual file list then I am going to leave it as is.

export USERNAME= - something like  (instead of ) ?

Done

"Let's stops your WordPress web server wordpress-demo" - good idea to point to how to stop (something like Let's stop running following command...) Also stop instead of stops.

The steps are part of the bullet points underneath. Maybe take a look again and see if you can find way to better improve it?
FYI, PR #6 has updates and some more imrpovements.

Thanks for the review comments @spzala.

In order to keep the flow intact, may want to make small changes below:
a Kustomization.yaml for customizing manifests - this file is not in the root dir like other files. May be better to say - “ a config directory containing kustomization.yaml"> ?
Same for the Patch files.

That's a good point. However, as it is just a listing off of what is provided from the scaffold and it is not an actual file list then I am going to leave it as is.

export USERNAME= - something like  (instead of ) ?

Done

"Let's stops your WordPress web server wordpress-demo" - good idea to point to how to stop (something like Let's stop running following command...) Also stop instead of stops.

The steps are part of the bullet points underneath. Maybe take a look again and see if you can find way to better improve it?
FYI, PR #6 has updates and some more imrpovements.

Awesome, thanks for the PR @hickeyma I have couple of questions but will ping for a quick discussion.


Add shared product cloud docs

Summary of the changes / Why this is an improvement
Checklist

[ ] Link to issue this PR refers to (if applicable):
[x] CLA is signed

Hi @matkuliak
Wasn't aware, that you are working on this. With the restructuring of the docs I think it is worth to have a top-level service offerings page, which I started here: https://github.com/crate/cloud-docs/pull/35
Let's bring this two pages together.

Hi @matkuliak
With the restructuring of the docs I think it is worth to have a top-level service offerings page, which I started here: #35 Let's bring this two pages together.

Hi @proddata. Sure, that makes sense. Should https://github.com/crate/cloud-docs/pull/36 replace the current subscription plans page?
I can verify that all the info is there and then remove the https://cratedb.com/docs/cloud/en/latest/reference/subscription-plans.html

Hi @matkuliak
With the restructuring of the docs I think it is worth to have a top-level service offerings page, which I started here: #35 Let's bring this two pages together.

Hi @proddata. Sure, that makes sense. Should https://github.com/crate/cloud-docs/pull/36 replace the current subscription plans page?
I can verify that all the info is there and then remove the https://cratedb.com/docs/cloud/en/latest/reference/subscription-plans.html


Allow bare match inside a match to reduce rightward drift

I'm doing tree-rewriting which requires a lot of nested matching, so I have code that looks like
match *sexp {
    Sexp::List(ref xs) => match xs.first() {
        Some(x) => match *x {
            Sexp::Sym(ref s) if s == "if" => unimplemented!(),
            ...
        },
        None => Ok(Ast::Nil),
    },
    ...
}

Rustfmt decides that this should be written as
match *sexp {
    Sexp::List(ref xs) => {
        match xs.first() {
            Some(x) => {
                match *x {
                    Sexp::Sym(ref s) if s == "if" => unimplemented!(),
                    ...
                }
            }
            None => Ok(Ast::Nil),
        }
    }
    ...
}

which then starts overflowing inside the innermost match blocks.

Closed via #1782.


why use "optionalDependencies" in packageJson? project is rely on it .

when i ignored "optionalDependencies" on my install packages.  errors came out.....

They are optional because only some functions require them. E.g. the html function requires html2canvas (and, optionally, dompurify), while the rest of jsPDF does not need it. What exact errors are you encountering?

They are optional because only some functions require them. E.g. the html function requires html2canvas (and, optionally, dompurify), while the rest of jsPDF does not need it. What exact errors are you encountering?


shared-library builds failing

see also: https://github.com/LLNL/serac/issues/786
when configuring serac with -DBUILD_SHARED_LIBS=TRUE, I'm getting the following error message:
[build] [ 19%] Linking CXX shared library ../../../lib/libserac_infrastructure.so
[build] /usr/bin/ld: /home/sam/code/serac_libs/gcc-9.3.0/mfem-<IP_ADDRESS>-5ymc6zfbt4jj75oqwbq3ozavxf7c7ttf/lib/libmfem.a(mem_manager.o): relocation R_X86_64_PC32 against symbol `_ZTVN4mfem8internal18StdHostMemorySpaceE' can not be used when making a shared object; recompile with -fPIC

It's unclear to me if there's an option in spack to turn on -fPIC in mfem. Another solution might be to pass that flag to the submodule version of mfem, once we fix the issues with the "codevelop" build.

looking into this one again, the error is still there. I tried adding -fPIC to a build with mfem as a submodule (since it's harder to add flags to our uberenv build), but that didn't fix the problem:
/usr/bin/ld: /path/to/libHYPRE.a(HYPRE_IJMatrix.o): relocation R_X86_64_PC32 against symbol `hypre__global_error' can not be used when making a shared object; recompile with -fPIC

But hypre can only be built through spack/uberenv


Session cookie fix

Constructor parameter for persisting session cookies for the SessionCookieJar and the FileCookieJar.
Ref: https://github.com/guzzle/guzzle/issues/1153

Nice work!
Can you make sure to limit lines to 80 characters, ensure that braces are surrounded by spaces, and add tests? After that, I'll merge.

I've added the tests and fixed the formatting. Do you have an Eclipse formatter? I've made the changes manually, but it would be easier if Eclipse did it for me :)

Sweet! Thanks!


Ability to use msvc2022 for Qt 6.7.3

I propose a small change so that Qt 6.7.3 can use msvc2022. This will not prevent Qt 6.8.0 from using msvc2022.

Links:

https://github.com/jurplel/install-qt-action/pull/251#issuecomment-2376239741

I propose a small change so that Qt 6.7.3 can use msvc2022. This will not prevent Qt 6.8.0 from using msvc2022.

Did you test this? aqt doesn't provide a win64_msvc2022_64 arch for 6.7.3. Currently, builds fail when using this action with 6.7.3. There has to be an aqt update before using msvc2022 here.

I agree with @Nerixyz. We at least have to update the default version number of aqtisntall as well.

... aqt doesn't provide a win64_msvc2022_64 arch for 6.7.3...

We at least have to update the default version number of aqtisntall as well.

The aqt fetches the information of downloadable Qt from the Internet, so I think we should "fix" aqtinstall first, then update the default minimal version number.
Directly reverting the commit is OK, but we still have the choice to wait for aqt's update.

Directly reverting the commit is OK, but we still have the choice to wait for aqt's update.

Yes. It's just a bit unfortunate that installing Qt 6.7.3 is currently broken on Windows with any 4.x version of this action (even 4.0.0). So I'd vote for reverting, adjusting aqt, and then updating aqt and the arch here.


[Question] Add custom component into StackLayout

Hi, I'm trying to add a child component into StackLayout in a parent component.
Tested on: iOS Simulator 9.3
The parent's code:
import {Component, ElementRef, ViewChild} from "@angular/core";
import {Router} from "@angular/router";
import {StackLayout} from "ui/layouts/stack-layout";
import {Page} from "ui/page";

import {NestedComponentChild} from "./NestedComponentChild"
import * as builder from "ui/builder";

@Component({
  selector: "NestedComponentParent",
  template: `
    <StackLayout #contentStack>

        <Button (tap)="addChild()" text="Add child"></Button>
        <NestedComponentChild></NestedComponentChild>
    </StackLayout>
  `,
    directives: [NestedComponentChild]
})

export class NestedComponentParent {
     @ViewChild("contentStack") contentStackRef: ElementRef;
    constructor(private _router: Router, private page: Page) {
    }
    counter = 0;
    addChild() {
        this.counter++;
        let stack = <StackLayout>this.contentStackRef.nativeElement;
        let childInstance = <NestedComponentChild> builder.load({
            path: "Pages/NestedComponent/NestedComponentChild",
            name: "NestedComponentChild",
            attributes: {
                counter : this.counter
            }
        });
        stack.addChild(childInstance); //Nothing new appeared
        console.log(childInstance.counter); // correct
        console.log("#children in stack: " + stack.getChildrenCount()); // does increase
    }
}

The children (NestedComponentChild.ts)
import {Component, Injector, Provider} from "@angular/core";
import {View} from "ui/core/view"
@Component({
  selector: "NestedComponentChild",
  template: `

  `
})

export class NestedComponentChild extends View {
    counter: number = 0;
}

In short, if I use the selector "NestedComponentChild" in NestedComponentParent's template, the child component (with label) appears. However, if I add it by code, the number of children of stack increases, but it (the added child component) isn't shown on screen.

Hello @fleuverouge,
There are several things to consider from your code sample.
You are trying to use NativeScript core concepts with Angular-2 which won't provide the expected results. For example, you are building a childInstance with NS builder and using stackLayout.addChild() which ae both NativeScript core concepts for which basically Angular-2 does not know how to handle.
In your NestedComponentChild you are extending View which is also unnecessary.
What you need to do is to create your project the Angular-2 way and use the Angular concepts for initializing and handling components.
For example here is how to add a child component to your stack with an angular structural directive *ngFor and ViewContainerRef (Represents a container where one or more Views can be attached).
your parent page code
import {Component, ViewContainerRef} from "@angular/core";
import {Page} from "ui/page";

import {NestedComponentChild} from "./NestedComponentChild"

@Component({
    selector: "NestedComponentParent",
    template: `
    <StackLayout #contentStack>

        <Button (tap)="addChild()" text="Add child"></Button>
        <NestedComponentChild *ngFor="let idx of items" [counter]="idx"></NestedComponentChild>
    </StackLayout>
  `,
    directives: [NestedComponentChild]
})

export class NestedComponentParent {
    items = [];
    counter = 0;

    constructor(private page: Page, vcRef:ViewContainerRef) {
    }

    addChild() {
        this.counter++;
        this.items.push(this.counter);
    }
}

your nested component code (notice the usage of Input to export the variable counter)
import {Component, Input} from "@angular/core";
import {View} from "ui/core/view"

@Component({
  selector: "NestedComponentChild",
  template: `

  `
})

export class NestedComponentChild {
    @Input() counter: number = 0;
}

Hi @NickIliev,
Thank you so much for your guidance!
I had to make NestedComponentChild extend View to use the ui builder.
My idea is to add different components dynamically basing on the data fetched by the parent component (ie: if data contain properties of Type1 & Type2, components Child1 & Child2 will be added, if data contain Type3, only Child3 will be added). I won't know which components/classes will be added and their order beforehand. That's the reason why I wanted to use StackLayout.addChild() instead of html template.
I'm an iOS developer with Obj-C & Swift. Nativescript & angular2 is really new to me. So thank you so much for any advice.
(Pls excuse me for my English)

Hey @fleuverouge
There are several approaches for your scenario with Angular-2 directives.
You can use ngSwitch directive and load components based on the switch case.
Or you can create your own custom directive with its own extended logic.
For better understanding, I recommend that you take a look at this sample application which we created with NativeScript + Angular-2
In this section you can find a basic example of how to use angular directives and how to create your own custom one.

Thanks, @NickIliev. I wonder why I hadn't found that repo before. I'll dig in it.


CRASH: Unable to delete SharedPreferences: prefs_name

I can see crashes in firebase caused by this, mostly on devices with android 8 and more (mostly Samsung devices).
App crashes during migration from shared preferences when trying to delete shared prefs.
Can somebody explain me why are you throwing IOException if deleteSharedPreferences() returns false on api >= 24, but you are silently continuing when prefs aren't able to delete on api < 24? Why can't you silently continue also for api >= 24?
Thank you for your answer.

Hi, can you please file a bug against the library here:
https://issuetracker.google.com/issues/new?component=907884&template=1466542
This does seem like an inconsistency that we may want to fix.
It'd be helpful if you can include how often you are seeing the crash. Also, it is probably worth catching and handling IOExceptions at call sites.

Sure, I will. I am not very satisfied with catching and handling this exception from the call site, because I don't know if I can consider this running migration as successful then..I guess that this 'cleanup' is some of the last steps of migration, but I think I am not the one who should decide this.

https://issuetracker.google.com/issues/195553816

We are actually facing the same issue, with most of samsung users as well, any other way to handle this or to have a patch soon ?
Thank you in advance

@HedyHidouRy I am not seeing this crash anymore, but it is because this is migration problem and almost all my users have already been migrated....but this is definitely not a solution, issue tracker is still without any response, I dont have any advice


Integrating AJAX and Dropdown module

Hi,
I'm using Dropdown module and it works well until I apply it to select element that has AJAX behaviour.
Here is a short description in Drupal context: after the page was loaded I initialize Dropdown on each select element. After the user selected some value Drupal sends a request to the backed, backend answers with updated form. The response includes select element with some pre-selected value.
After that we initialize Dropdown on the select element and Semantic UI sets value to the Dropdown and triggers ".change" JavaScript event. This event causes AJAX request to the backend. This produces infinite AJAX calls.
Also I noticed that Semantic UI will set value and trigger ".change" event if select element has pre-selected value.
It happened after updating framework to the latest version (1.8.1). I guess that initialize method was updated to use module.set.selected() which calls module.set.value() and triggers ".change" event.
I'm just curious are there any ways to not trigger ".change" event when the select element already has this value? (I guess it will not cause AJAX call to the backend). Theoretical solution may be updating module.set.value() to something like this:
value: function(value) {
  module.debug('Adding selected value to hidden input', value, $input);
  if($input.length > 0 && value != $input.val()) {
    $input
      .val(value)
      .trigger('change')
    ;
  }
  else {
    $module.data(metadata.value, value);
  }
},

But I'm not sure will it work in case if user selected some value and refreshed the page.
Thanks in advance

I appreciate the thorough description but a test case would really help me understand.

Hi Jack,
thanks for paying attention to this issue.
I prepared a little test case that shows the problem: http://jsfiddle.net/jaev39pL/9/.
Let me describe the algorithm in few words:

after the page was loaded I initialize Dropdown module
after the user selected some value I send the form to the backend and get updated form with pre-selected value. By default select element is hidden, so we need to initialize Dropdown module on it
during initialization Semantic UI triggers change event that causes AJAX request to the backend
things repeat from step 2 (you may notice infinite AJAX requests in the Firebug/Development tools console)

Please let me know if you need more information.

Here's an example of how you can update options
http://jsfiddle.net/2avsd0en/

If you for some reason really had to replace the <select> itself and not just options. You will have to refresh the menu. This is because the observers are attached to the select element, and removing from the DOM will not allow the changes to be observed.
Here's an example of that:
http://jsfiddle.net/2v3ktaLr/

Thanks for examples.
They are helpful for case when a developer is creating a form from scratch. In my case I have already written system that provides AJAX integration for forms. For example, system automatically returns and updates entire element. Or in some cases backend may return entire form. But anyway thank you for the suggestions.
I noticed that this task was added to the 1.9.0 milestone, does it mean that you are going to continue work on this task?


fixes not keyword handling

Resolves #97

@tlivings could you weigh in on the PRs I've opened when you get a chance?

@tlivings could you weigh in on the PRs I've opened when you get a chance?


Multi-file scripts workflow?

Hey,
How do you recommend working with multiple jsx script files?
I'd love to import/require stuff, but of course it is not possible because of the limitations that exists with the environment. What workaround could maybe do the work?

The ReadMe goes into detail about using includes and global declarations within
After Effects.
I use this package in a couple of server programs in my company, and what I do
is I run my includes and all of my global declarations when after effects start
up, and then construct my commands clean. Something like so:
ae.execute(()=> {   $.global.foo = () => alert('bar') }) .then(() => {   console.log('After Effects includes ran.') }) ae.options.includes = [] //none of my future commands will be created with a bunch of bundled code that already exists in the AE namespace, anyway
I think of the After Effects environment the same way I think about the browser;
I try not to worry about the global namespace, because it's already extremely
polluted with a whole bunch of Adobe functions anyway.
Instead, I keep things organized on the node side and give each of my commands
their own module:
`
/* /src/commands/clear-all-items.js */
import { Command } from 'after-effects'
const clearAllItems = new Command(() => {
while (app.project.numItems > 0)
app.project.items(0).remove()
})
export default function () {
return clearAllItems.execute()
}
export function sync() {
return clearAllItems.executeSync()
}
`
Then I import the commands as I need them, elsewhere:
`import clearAllItems from './commands/clear-all-items'
import doSomethingElse from './commands/do-something-else'
clearAllItems()
.then(doSomethingElse)`
As for actually having requires and imports INSIDE of After Effects, I had at one
point written a framework that could do this, so I know it's possible. It was
really only useful to me as a proof of concept, as it depended on global eval
and number of other restrictions. The file system access within After Effects,
for example, is syncronous and very slow.
Hope this helps! Don't hesitate with other questions/suggestions.

thanks :)