Most recent stable version is not selected when using "*" in queries

Describe the bug
opam-nix selects ocaml 5.0.0~rc1 over ocaml 5.0.0 when using ocaml-base-compiler = "*"
To Reproduce

Clone https://github.com/brendanzab/language-garden.git and checkout https://github.com/brendanzab/language-garden/commit/97f9f2d460a5894b4b2adf0a1612aec902b7d4e0
Check the ocaml version:$ nix develop --command ocaml --version
The OCaml toplevel, version 5.0.0

Apply the following diff:diff --git a/flake.nix b/flake.nix
index 012f4aa..2134b1d 100644
--- a/flake.nix
+++ b/flake.nix
@@ -72,7 +72,7 @@
       # when building the opam project with `opam-nix`.
       query = devPackagesQuery // {
         # Force the ocaml compiler to be taken from opam-repository:
-        ocaml-base-compiler = "5.0.0"; # Fix for opam-nix choosing 5.0.0~rc1 over 5.0.0
+        ocaml-base-compiler = "*";
       };

       # Package-specific derivation overrides.

Check the ocaml version:$ nix develop --command ocaml --version
The OCaml toplevel, version 5.0.0~rc1

Expected behavior
opam-nix would select the most recent stable version when "*" is specified. Alternatively it would select the most recent unstable version (there are more recent versions of ocaml-base-compiler now).
Environment

OS name + version: macOS 13.4.1
Version of the code: e83bd1d949c5e330a49f89d394b51b744248e3ca

ocaml-base-compiler = "*" just gets passed along to opam as --packages ocaml-base-compiler, which should select the latest version (to some definition of "latest"). I believe 5.0.0 is a release, and thus should be "stable"?

Ahh, wonder why it is not selecting it 😕 – the docs on version ordering are here.

The ~ character is special as it sorts even before the end of sequence (i.e. before anything shorter: "~" sorts before "", "a~b" before "a"). It's most convenient for pre-releases, allowing 1.0~beta to be before 1.0.

Not sure what else you are expecting? It seems to be behaving according to the documentation.

You might to be looking at the wrong version of opam-repository; mind that by default opam-nix uses the version pinned in flake.lock (at this point, it's 786c55fa77c37f07eceea7d6a9bec04d2225e302)

Not sure what else you are expecting? It seems to be behaving according to the documentation.

I would have expected it to select the most recent non-prerelease version (i.e. nothing after the tilde), based on what is on the pinned version of opam-repository. But perhaps I don’t understand opam versioning that well (I’m used to how it works with Cargo).
Maybe I should just set the compiler version explicitly to avoid this in the future, as opposed to relying on *? Is there a good way to query what versions of a package in the local opam-repository? At the moment I have just been going into the github repository to check what is at the current commit pinned in my flake, but that seems a little round-about. I assume there’s probably some OCaml tool that can help?

You might to be looking at the wrong version of opam-repository; mind that by default opam-nix uses the version pinned in flake.lock (at this point, it's 786c55fa77c37f07eceea7d6a9bec04d2225e302)

I was looking at the commit of opam-repository that I pinned on my flake. I probably should have mentioned that – I was planning to, but I must have forgot. In the commit I linked to (https://github.com/brendanzab/language-garden/commit/97f9f2d460a5894b4b2adf0a1612aec902b7d4e0) it was https://github.com/ocaml/opam-repository/commit/8241abf97ddbcb63f614372f31abeb306312f33c. I guess I’m wondering if this is exposing an issue that is not obvious in the currently pinned version of opam-repository?


Optional cbindgen dependency

FIXES #20

Absolutely no problem.
bors r+

(Does this repo have bors?)

Released as 2.4.1!


Strange artifacts showing on right side of preview image

I just converted the vehicle-detection-adas-002 to the blob format and tried running it through a similar pipeline as the second tutorial. It partially works and it does manage to recognize vehicles quite accurately but seems to show some weird green and pink bars on the right hand side of the preview image:

I did re-compile the depthai-api module to run on my board which is a 64 bit version of linux: Linux NanoPi-Fire3 4.4.172-s5p6818 #1 SMP PREEMPT Mon Nov 11 11:24:09 CST 2019 aarch64 aarch64 aarch64 GNU/Linux
I am also using python 3.7 and opencv 3.4.9 if that makes any difference?
Here is the output from depthai after running the python script:
python3 vehicle_detection.py
Using Custom Calibration File: depthai.calib
XLink initialized.
Sending device firmware "cmd_file": /home/pi/depthai-python-extras/depthai.cmd
Successfully connected to device.
Loading config file
watchdog started Attempting to open stream config_d2h
1000
Successfully opened stream config_d2h with ID #0!
Closing stream config_d2h: ...
Closing stream config_d2h: DONE.
WARNING: Version (dev) does not match (unknown & 8c6328c8acd1086542b47d09b4b192ec1143914c)
CNN configurations read: vehicle-detection-adas-0002.json
depthai: Calibration file is not specified, will use default setting;
config_h2d json:
{"_board":{"_homography_right_to_left":[0.988068163394928,0.0029474012553691864,5.067617416381836,-0.008765067905187607,0.9921473264694214,-8.795275688171387,-8.449587767245248e-06,-3.603489403758431e-06,1.0]},"_load_inBlob":true,"_pipeline":{"_streams":[{"name":"metaout"},{"name":"previewout"},{"name":"meta_d2h"}]},"ai":{"calc_dist_to_bb":false},"board":{"clear-eeprom":false,"left_fov_deg":69.0,"left_to_rgb_distance_m":0.0,"left_to_right_distance_m":0.03500000014901161,"override-eeprom":false,"store-to-eeprom":false,"swap-left-and-right-cameras":false},"depth":{"padding_factor":0.30000001192092896}}
Attempting to open stream config_h2d
Successfully opened stream config_h2d with ID #1!
Writing 1000 bytes to config_h2d
!!! XLink write successful: config_h2d (1000)
Closing stream config_h2d: ...
Closing stream config_h2d: DONE.
Read: 4248000
Attempting to open stream inBlob
Successfully opened stream inBlob with ID #2!
Writing 4248000 bytes to inBlob
!!! XLink write successful: inBlob (4248000)
Closing stream inBlob: ...
Closing stream inBlob: DONE.
depthai: done sending Blob file vehicle-detection-adas-0002.blob
Attempting to open stream outBlob
Successfully opened stream outBlob with ID #0!
Closing stream outBlob: ...
Closing stream outBlob: DONE.
CNN input width: 672
CNN input height: 384
CNN input num channels: 3
Host stream start:meta_d2h
Opening stream for read: meta_d2h
Attempting to open stream meta_d2h
Successfully opened stream meta_d2h with ID #4!
Starting thread for stream: meta_d2h
Started thread for stream: meta_d2h
Host stream start:metaout
Opening stream for read: metaout
Attempting to open stream metaout
Successfully opened stream metaout with ID #5!
Starting thread for stream: metaout
Started thread for stream: metaout
Host stream start:previewout
Opening stream for read: previewout
Attempting to open stream previewout
Successfully opened stream previewout with ID #0!
Starting thread for stream: previewout
Started thread for stream: previewout
depthai: INIT OK!

Hi @ConnorChristie ,
Yes we have seen that too on some models like at the bottom here:
https://docs.luxonis.com/tutorials/openvino_model_zoo_pretrained_model/#trying-other-models
There’s some alias occurring and we’re working to figure out why.  If you notice those pixels are a strange remapping from the left side of the image where red and green come over but not blue.
Sorry we should have had this up as a known issue.

For documentation purposes another model that does this is face-detection-adas-0001.

Hi @ConnorChristie ,
Just wanted to update that this is on our shortlist, but we're cranking through some necessary improvements first.  https://github.com/luxonis/depthai/issues/74 https://github.com/luxonis/depthai/pull/77 https://github.com/luxonis/depthai/pull/76 https://github.com/luxonis/depthai/pull/66 https://github.com/luxonis/depthai/pull/62 in addition to updating our tensor-output processing so that it can be dynamic for support of other tensor formats.
And we have h.264 1080p video output support and 12MP still image support output to go to PR tomorrow.
Thoughts?
Thanks,
Brandon

Hi @ConnorChristie ,
So the fix for this is in this PR (with some other fixes and related functionalities):
https://github.com/luxonis/depthai/pull/85

@Luxonis-Brandon After updating to the latest version (more specifically, updating depthai.cmd) I am now getting this error after starting:
Using Custom Calibration File: depthai.calib
Using Arguments= {'config_overwrite': None, 'board': None, 'field_of_view': 71.86, 'rgb_field_of_view': 68.7938, 'baseline': 9.0, 'rgb_baseline': 2.0, 'swap_lr': True, 'store_eeprom': False, 'clear_eeprom': False, 'override_eeprom': False, 'device_id': '', 'dev_debug': None, 'force_usb2': None, 'cnn_model': 'mobilenet-ssd', 'disable_depth': False, 'draw_bb_depth': False, 'full_fov_nn': False, 'streams': ['metaout', 'previewout'], 'video': None}
depthai.__version__ == 0.0.10a
depthai.__dev_version__ == 3b41050fe9c2453408e24c49e15f5ac561595cf6
XLink initialized.
Sending device firmware "cmd_file": /home/pi/depthai/depthai.cmd
Successfully connected to device.
Loading config file
watchdog started Attempting to open stream config_d2h
3000
Successfully opened stream config_d2h with ID #0!
Closing stream config_d2h: ...
Closing stream config_d2h: DONE.
WARNING: Version (dev) does not match (30295b558351cd030408e12a220cdd55b5fb450e & 3b41050fe9c2453408e24c49e15f5ac561595cf6)
EEPROM data: invalid / unprogrammed
Available streams: ['meta_d2h', 'left', 'right', 'disparity', 'depth_sipp', 'metaout', 'previewout', 'jpegout', 'video']
CNN configurations read: /home/pi/depthai/resources/nn/mobilenet-ssd/mobilenet-ssd_depth.json
config_h2d json:
{"_board":{"_homography_right_to_left":[1.0012089014053345,0.006868398282676935,-5.654909610748291,-0.003709208220243454,1.0076549053192139,-8.794636726379395,-4.944150077790255e-06,8.152581358444877e-06,1.0]},"_load_inBlob":true,"_pipeline":{"_streams":[{"name":"metaout"},{"name":"previewout"}]},"ai":{"calc_dist_to_bb":true},"board":{"clear-eeprom":false,"left_fov_deg":71.86000061035156,"left_to_rgb_distance_m":0.019999999552965164,"left_to_right_distance_m":0.09000000357627869,"name":"","override-eeprom":false,"revision":"","rgb_fov_deg":68.7938003540039,"stereo_center_crop":false,"store-to-eeprom":false,"swap-left-and-right-cameras":true},"depth":{"padding_factor":0.30000001192092896}}
Attempting to open stream config_h2d
Successfully opened stream config_h2d with ID #1!
Writing 1000 bytes to config_h2d
!!! XLink write successful: config_h2d (1000)
Closing stream config_h2d: ...
Closing stream config_h2d: DONE.
Creating observer stream host_capture: ...
Attempting to open stream host_capture
Successfully opened stream host_capture with ID #0!
Creating observer stream host_capture: DONE.
Read: 14514560
Attempting to open stream inBlob
E: [global] [    991829] [python3] XLinkOpenStream:95   Cannot find stream id by the "inBlob" name
E: [global] [    991830] [python3] XLinkOpenStream:96   Max streamId reached!
Failed to open stream inBlob ! Retrying ...
E: [global] [    991885] [python3] XLinkOpenStream:95   Cannot find stream id by the "inBlob" name
E: [global] [    991885] [python3] XLinkOpenStream:96   Max streamId reached!
Failed to open stream inBlob ! Retrying ...
E: [global] [    991885] [Scheduler00Thr] dispatcherEventSend:53        Write failed (header) (err -1) | event XLINK_CREATE_STREAM_REQ

E: [xLink] [    991885] [Scheduler00Thr] sendEvents:1036        Event sending failed
E: [global] [    991940] [python3] XLinkOpenStream:95   Cannot find stream id by the "inBlob" name
E: [global] [    991940] [python3] XLinkOpenStream:96   Max streamId reached!
Failed to open stream inBlob ! Retrying ...
E: [global] [    991941] [Scheduler00Thr] dispatcherEventSend:53        Write failed (header) (err -1) | event XLINK_CREATE_STREAM_REQ

E: [xLink] [    991942] [Scheduler00Thr] sendEvents:1036        Event sending failed
E: [global] [    991996] [python3] XLinkOpenStream:95   Cannot find stream id by the "inBlob" name
E: [global] [    991996] [python3] XLinkOpenStream:96   Max streamId reached!
Failed to open stream inBlob ! Retrying ...
E: [global] [    991997] [Scheduler00Thr] dispatcherEventSend:53        Write failed (header) (err -1) | event XLINK_CREATE_STREAM_REQ

E: [xLink] [    991997] [Scheduler00Thr] sendEvents:1036        Event sending failed
E: [global] [    992051] [python3] XLinkOpenStream:95   Cannot find stream id by the "inBlob" name
E: [global] [    992051] [python3] XLinkOpenStream:96   Max streamId reached!
Failed to open stream inBlob ! Retrying ...
E: [global] [    992053] [Scheduler00Thr] dispatcherEventSend:53        Write failed (header) (err -1) | event XLINK_CREATE_STREAM_REQ

E: [xLink] [    992054] [Scheduler00Thr] sendEvents:1036        Event sending failed
Stream not opened: inBlob
depthai: pipelineConfig write error;
Pipeline is not created.
Stopping threads: ...
Stopping threads: DONE 0.000s.
Closing all observer streams: ...
Closing stream host_capture: ...
Closing stream host_capture: DONE.
E: [global] [    992245] [Scheduler00Thr] dispatcherEventSend:53        Write failed (header) (err -4) | event XLINK_CLOSE_STREAM_REQ

Closing all observer streams: DONE.
Reseting device: 0.
E: [xLink] [    992245] [Scheduler00Thr] sendEvents:1036        Event sending failed
E: [global] [    992245] [Scheduler00Thr] dispatcherEventSend:53        Write failed (header) (err -4) | event XLINK_RESET_REQ

E: [xLink] [    992245] [Scheduler00Thr] sendEvents:1036        Event sending failed
Reseting: DONE.
Return code:3

Hi @ConnorChristie
Please update the python lib (.so) as well, or rebuild it from sources.
The device firmware (.cmd) and python lib are interdependent, we will add some better checks and error messages if they are incompatible (different versions).
You can use the current master branch, the above PR was merged.

@alex-luxonis Yup, figured it out. Thought I was building latest but it turns out I was not. Everything works as expected now, thanks!

This has been fixed by https://github.com/luxonis/depthai/pull/85


Add speed limit indicator

Made a new service speedlimitd that uses gps long/lat from gpsLocationExternal, looks up the recent road segments in Mapbox's map matching API, and publishes liveMapData, which is previously unused as far as I can tell.
Here's a showcase of it from a drive earlier this evening: https://youtube.com/watch?v=GkIRIIrR5ik
The biggest downside of the feature is that right now, it needs a Mapbox access token to work (located at a new path /persist/mapbox/access_token). So either each person wanting to use the feature needs to get their own Mapbox account and access token, or it could be a comma prime feature where y'all could expose a new endpoint backed by Mapbox.
This branch also includes a couple other minor fixes/improvements
Looking forward to the feedback!

Nice feature and thanks for the PR! We used to have something similar to this called mapd, but it was too unreliable. We won't merge this for the same reasons, but it might be nice to put this on the wiki for others to use.

Gotcha, I guess this feature will need to wait until there's more navigation capability built into openpilot. I'll open another PR with the minor unrelated changes from this PR in the meantime.


New color schemes (openHAB, Kodi, ProFTPD, MQTT)

I finally created a PR for some new color schemes.

openHAB #8
ProFTPD #16
Kodi #17
MQTT (mosquitto_sub)

Please let me know if I should change anything.
Should I create separate PRs for each color scheme?
(I am unsure how git would handle this if each scheme would be added in the same place relative to the master file)
Are line comments like https://github.com/CWempe/multitail/blob/new_color_schemes/multitail.conf#L1078 ok or should I remove them?

btw: I only tested this with multitail 6.4.2

Thanks!
I can't test these myself unfortunately.


needed to add data-videohub-base

hey @spra85 @collin @MelizzaP does this look correct to you? Still trying to figure out how to test it, but I'm pretty sure this'll fix this bug.
  if (typeof this.$videohubBaseUrl === 'undefined') {
    throw Error('CurrentEpisode requires bulbs-video to have a videohub base url.');
  }

☝ i think this is what is causing the problem

I think the the script causing this bug shouldn't even be running on the home page.
And if it is going to run on the homepage, it shouldn't be selecting $('bulbs-video') so generally.

Coverage decreased (-0.2%) to 85.988% when pulling 480c822684bc88f1566bc9e9de42c91677425bf8 on urlfix into 0532a3b617512020751d7e63fa8257a943e10888 on master.

You're right. I made a new PR on onion here: https://github.com/theonion/onion/pull/535


[help] v4 Drag + Zoom + Force directed layout

Hi, can somebody please help me, I'm not very experienced with JS and I'm not sure if the way I try to use the D3 is right.
Here is example of what I have now (nodes are on each other, you can drag them around)
http://1oglop1.github.io/d3/HTML/graph_test.html
I'm trying to apply the force on  is it possible? Can someone please give me an example?
Thanks a lot.
structure of my svg:
<svg>
  <g id="zoom_box">
    <g id="nodesGroup">
      <g class="node Person">
         <circle id="Peter" r="50"></circle>
         <text>Peter</text>
      </g node>
    </g nodesGroup>
  <g id="linksGroup">
    <g class="link">
      <line class="link"></line>
      <text>TextOnLine</line>
     </g link>
   </g linksGroup>
</g zoomBox>
</svg>

Please use Stack Overflow tag d3.js to ask for help. Although I make an effort to assist everyone that asks, I am not always available to provide help promptly or directly. Stack Overflow provides a better collaborative forum for self-help: tens of thousands of D3-related questions have already been asked there, and some answered questions may be relevant to you.
If you have a question about D3’s behavior and want to discuss it with other users, also consider the d3-js Google Group or joining the d3-js Slack.
Thank you! 🤗

Okay thank you, I'll try, I found the slack link few hours after I posted this.
I will also try the stack owerflow


AcquireNextImageKHR issue

Today I have come back to working on graphics applications (after 3 weeks away from it) and I find that I cannot get my program to work with the vulkan debug layer turned on (it works with it off).  When on, I get:
"vkAcquireNextImageKHR: Application has already acquired the maximum number of images (0x2)"

(I requested 3 images, so the 0x2 is a bit odd).  This happens right after the swapchain rebuild.
I found your post about this in January here:
http://stackoverflow.com/questions/41502123/vkacquirenextimagekhr-application-has-already-acquired-the-maximum-number-of-im
However, I'm not using Intel / Mesa, I'm using Nvidia proprietary driver 375.39 on Ubuntu 16.04, and I've tried VulkanSDKs <IP_ADDRESS>, <IP_ADDRESS>, and <IP_ADDRESS>.   The first 2 render blank (black) screens with validation on, the newest one gives the error.  (With validation off, it works fine on all of them).
If I force vk::PresentInfoKHR.p_results to ptr::null_mut() it no longer gives the error, but continues to render only a blank (black) screen.
Oddly, both ash examples work fine.  So does SaschaWillems stuff.  It's not your bug, I'm just posting here because maybe you know something that can help me out (I've spent about 5 hours today pulling out my remaining hair).

Ok I've conflated 2 issues. Luckily I have a second development machine.  Turns out the "black screen" is caused by ash, something about the commits on Apr 6 or thereafter, or the way I have updated my code to use them.  They seem so simple and I just haven't worked out why.
The newest VulkanSDKs (1.0.46) is giving me this other issue, and I'll just punt on that for a while and keep using <IP_ADDRESS> for now... hopefully it's their bug.

I am still on an older sdk, I am currently pretty busy until the 18th so I can't test it. Sounds really strange that it works when the validation layers are off.
Not much has changed just how you update the vertex buffer binding. But I am also now on AMD. I'll investigate when I find some time.

I'm pretty sure now that this "black screen" issue has nothing to do with ash.
In fact, I'm pretty sure by now that this has nothing to do with incorrect source code.   I have gotten it failing even when I roll back and depend on rolled-back dependencies.
I don't think it's a system condition causing the failures, because once a binary is compiled, it either always works or always fails.   So I'm leaning towards a rust or llvm bug.

I'm not sure of anything anymore. Now it always works with validation off and always is black with validation on (and validation always succeeds with ptr::null_mut for p_results).  This is true regardless of which SDK, which commits I choose, etc.   I can no longer get the "draws with validation layer on" state (and I didn't save any of those binaries). I'm completely flummoxed.
I'm going to shelf this project for another few weeks, work on something else.
In case your curious of the conditions:  Ubuntu 16.04, nvidia-375(.39), GTX650 (similar results on GTX 1050 Ti on my work machine)

FYI
I've dug further into this.  The "blank screen" is caused by some objects failing to render -- the clear color renders, so isn't not entirely blank.  With certain combinations of validation layers, i can actually get one pipeline to fail to render while the other renders fine (half my objects show up).  I'm heavily leaning towards the nvidia driver >=375.  I'll get my AMD R7 360 installed tomorrow to get another data point.
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/1682


should not use seek() for skipping very small column chunks. better to read and ignore data.

Describe the enhancement requested
When reading some column chunks but not all, parquet is building a list of "ConsecutivePartList", then trying to call the Hadoop api for vectorized reader of FSDataInputStream#readVectored(List ...)
Unfortunatly, many implementations of "FSDataInputStream" do not override the readVectored() method, which trigger many distinct calls to read.
For example on hadoop-azure, the Azure Datalake Storage is much slower at establishing a new Https connection (using infamous calls HttpURLConnection for jdk 1.0, then doing TLS hand-shake), that to get only few more megas of data on an existing socket !!
The case with small wholes to avoid reading is very frequent when having columns in parquet files that are not read, and are highly compressed because of RLE encoding. Typically, a very sparse column with only few values, or even always null within a page. Such a column could be encoded in only few hundred of bytes by parquet, so it is NOT a problem of reading 100 bytes more.
Parquet should at least honor the following method from hadoop class FileSystem, that says that a seek of less than 4096 bytes is NOT reasonable.
  /**
   * What is the smallest reasonable seek?
   * @return the minimum number of bytes
   */
  default int minSeekForVectorReads() {
    return 4 * 1024;
  }

The logic for building this List for a list of column chunks is here:
org.apache.parquet.hadoop.ParquetFileReader#internalReadRowGroup
  private ColumnChunkPageReadStore internalReadRowGroup(int blockIndex) throws IOException {
    ...
    for (ColumnChunkMetaData mc : block.getColumns()) {
        ...
        // first part or not consecutive => new list
        if (currentParts == null || currentParts.endPos() != startingPos) {  // <===== SHOULD honor minSeekForVectorReads()
          currentParts = new ConsecutivePartList(startingPos);
          allParts.add(currentParts);
        }
        currentParts.addChunk(new ChunkDescriptor(columnDescriptor, mc, startingPos, mc.getTotalSize()));
      }
    }
    // actually read all the chunks
    ChunkListBuilder builder = new ChunkListBuilder(block.getRowCount());
    readAllPartsVectoredOrNormal(allParts, builder);
    rowGroup.setReleaser(builder.releaser);
    for (Chunk chunk : builder.build()) {
      readChunkPages(chunk, block, rowGroup);
    }

    return rowGroup;
}

maybe a possible implementation could be to add fictive "ConsecutivePartList" that are to be ignored while receiving the data, but that would avoid having some wholes in the ranges to read.
Component(s)
No response

see also related issue:  https://github.com/apache/parquet-java/issues/3077 : AzureBlobFileSystem.open() should return a sub-class fsDataInputStream that override readVectored() much more efficiently for small reads

@mukund-thakur

I think we should revisit that min seek range, at least add a good default for ABFS, and make it configurable. File a HADOOP- JIRA, ideally with a patch.
We do always have hopes for a full implementation for abfs; though it has yet to surface.
On hadoop 3.4.1 the abfs connector also support the httpclient connection pool for better performance, though that is stabilising.

Anyway, I agree with you about read and discard is better for cloud stores, what I don't know is what is a good value here
What do you think, at least in your deployments?
The velox paper actually set the value as 500K
IO reads for nearby columns are typically coalesced (merged) if the gap between them is small enough (currently about 20K for SSD and 500K for disaggregated storage)

Maybe in hadoop we should

change the default size to 20k
s3a and abfs set to 500K
review the gcs settings too, though that's in google's code.

Yes we wanted to do more performance TPCDS tests using different min seek values and then decide a good default but those are expensive and time consuming to run and that's why we haven't done it yet. It would be good to know if you have any performance benchmark numbers.

I think we could do some micro benchmarking here as well.
What we wantis have a skip size such that it is faster to discard the data it is to wait for/acquire an http connection and download the data across multiple threads.
Acquisition time is trouble given the http connection pool size and wait times which may be imposed by the actions of other threads. Same for that thread pool scheduling overhead.
Download time is a function of bandwidth alone.
We could ignore the https and thread delays and focus on the time from GET to "first byte" -which would be entirely that imposed by the cloud store itself. Then all we care about is that the time to download skip the data is less than the GET-to-first-byte latency.
which is will be when
bytes-to-skip/bandwidth < t(GET-to-first-byte)

We could benchmark this: something to preheat the pool with a few head calls, then a set of single byte read() calls to different parts of a large file, with time to return being considered time to first byte.
then work out download bandwidth and so how many bytes match that time-to-first-byte
I will take a small PR to cloudstore for this; it'd be interesting to see what the local fs values are as well as the different cloud stores, local and remote. Even: do different VM types matter?
@Arnaud-Nauwynck
try setting http.maxConnections a number like 100, this will improve the cacheing of the http connections.


updated package.json devDependency

updated package rimraf from 2.5.2 to 2.6.1
Npm link :  https://www.npmjs.com/package/rimraf
Repository link : https://github.com/isaacs/rimraf/releases

Is there a particular reason this needs to be upgraded? 2.6.1 is included in the semver range ^2.5.2.


GC9A01 display issue on Raspberry Pi 3 - no text is displayed

Hello,
So, I bought one of GC9A01 chip based SPI displays off AliExpress (not a link to AliExpress), and I started testing it. I use CircuitPython with latest adafruit-blinka installed on my Raspberry Pi 3B.
So, I installed all necessary libraries:

CircuitPython GC9A01
Blinka DisplayIO

I'm using following code:
import time
import board
import math
import busio
import terminalio
import displayio
from adafruit_display_text import label
import gc9a01

# Release any resources currently in use for the displays
displayio.release_displays()

spi = board.SPI()

# Make the displayio SPI bus and the GC9A01 display
display_bus = displayio.FourWire(spi, command=board.D25, chip_select=board.D18, reset=board.D27)
display = gc9a01.GC9A01(display_bus, width=240, height=240)

# Make the main display context
main = displayio.Group()
display.show(main)

# Draw a text label
text = "Hello\nWorld!"
text_area = label.Label(terminalio.FONT, text=text, color=0xFFFF00,
                        anchor_point=(0.5,0.5), anchored_position=(0,0))
text_group = displayio.Group(scale=2)
text_group.append(text_area)
main.append(text_group)

# Animate the text
theta = math.pi
r = 75
while True:
    print(time.monotonic(),"hello")
    text_group.x = 120 + int(r * math.sin(theta))
    text_group.y = 120 + int(r * math.cos(theta))
    theta -= 0.05
    time.sleep(0.01)

The problem is, that this code gives me following output (sorry my hands are shaking):
https://user-images.githubusercontent.com/52399966/159176742-e46b4213-cb56-451e-b720-9df9ec32a981.mp4
So, I decided to use Pi Pico to test if display is faulty. So I flashed it with latest CircuitPython firmware, installed everything, modified my code to Pico's pins, and here is the result:
https://user-images.githubusercontent.com/52399966/159176873-305b582f-8b98-4b3d-857b-c8994b6e4a94.mp4
I really don't think it's the CircuitPython GC9A01's fault. I also checked wiring on my Raspberry Pi 3 like a million times. So, my guess is that it's blinka-displayio's fault, as Pico uses CircuitPython's displayio, meanwhile Pi 3 uses blinka-displayio, which is a port to Unix & Unix-like operating systems.
I'm also not using integrated (hardware) Chip-Select pin, as it's not recommended.
Let me know what you think is the issue.
Awaiting your response and thank you for everything upfront :pray:

Code source

Currently the Blinka Displayio implementation is not complete and is only a subset of CircuitPython's Displayio. It has not been tested with this display. It's likely using part of the codebase that is missing.

#114 should get it working if you still have the display and are interested. Otherwise, I will likely just close this issue after it's merged.

Closing as this should be fixed.


Module & Component plugins

There has been a lot of discussion about adding more modules to SUI core, @jlukic has mentioned that he wants to keep the number of modules/components quite low so that the framework doesn't get too bloated. I have been thinking what if we add some sort of way to download community built modules and components but have the ability to build them into the framework just like how the current theme is built.
I was thinking of maybe making a section in the semantic.json file for plugins which is an array of plugins which are maybe downloaded via npm. Then when the project builds it also adds these to the framework so it's not necessarily in the core framework but its an easy way to add additional components/modules for users needs. This also makes it easier for users to include them in their project because they aren't including lots of different files.
Let me know your thoughts about this! 😄

Its a great idea, sort of marketplace of all available plugins would be nice too.


Fix UI reviewapp

Description

ui用のサービスがなくなっていたので追加
dreamkast本体はuiのReviewAppから消したのでConditionから削除

Type of change

[ ] Document update or simple typo fix
[ ] Maintenance/update components
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?

[ ] I have checked backward/forward compatibility that may cause regarding this change.

template-uiのkustomizationに、service.yamlの追加が必要そうです！


Add .internal to internal-only hostnames

ICANN is in the progress of reserving .internal for private use (see this closed consultation). As such I believe that this TLD would be a suitable addition to the list of internal addresses used in SubjectIsInternal.
I based this PR on 6668587 which added .home.arpa to the list.

Interesting. I guess I'm OK with this, but will wait for another team member to approve as well. @francislavoie or @mohammed90 ?

Last time we made a change here (adding .home.arpa) it caught out some users which were already using that domain with their own ACME server or something like that. But I don't have a strong opinion about it.

That's true; but if this motion is finalized then I imagine this'll be the right thing to do long-term, despite potential complications one-time.
I might leave this open until it becomes more finalized though. It looks like it goes to "further consideration" at this point, not something that is actually enacted yet.
@nickubels  Maybe ping me to remind me about this later after it is finished. :reminder_ribbon:

Very good point about possibly breaking workflows and I agree that waiting on finalisation by the ICANN Board would be a smart move.
That prompted me to check if this was already scheduled to be discussed in a board meeting, and to my surprise the board discussed this on 2024/07/29 and approved it as resolution 2<IP_ADDRESS>:

Resolved (2<IP_ADDRESS>), the Board reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications. The Board recommends that efforts be undertaken to raise awareness of its reservation for this purpose through the organization's technical outreach.

Theres currently a draft for a RFC: https://datatracker.ietf.org/doc/draft-davies-internal-tld/
While looking around for more information I also stumbled upon RFC 2606 and RFC 6761 which mention the reserved TLDs .test, .example, .invalid and .localhost. The latter is currently already included, but the first three not yet.
I believe that it would be a good idea to add those missing three to create a consistent experience for all four TLDs mentioned in RFC 2606.
For .internal the following question arises from my side: Is the approval of the ICANN Board enough for inclusion, or do we wait until a/the RFC is formalised?

This was discussed previously, I think it was https://github.com/caddyserver/caddy/issues/2006 -- the main reason we were conservative with what domains/TLDs we make internal is because it's an implicit default that's difficult/annoying to override in configuration.
For example, some people have locally-deployed ACME CAs that may issue certs for .test or even .internal, and using Caddy's self-managed CA for that might be a frustration.


Cloudwash needs more detailed logging.

Hi,
I have been using Cloudwash for couple of months.
And till now I have observed that it needs a detailed logging structure.
because as I was writing the Tekton pipeline for cleanup of Azure, AWS and GCP it always showed me this line at first and then it went on with the actual error.
(app-root) bash-5.2$ swach -d azure --all
<<<<<<< Running the cleanup script in DRY RUN mode >>>>>>>
The AZURE providers settings are initialized and validated !

and even if it wasn't able to fetch the secrets still it was saying "The AZURE providers settings are initialized and validated !"  which i think is confusing.
So, now that I am testing my cron job locally with the help of minikube kubectl and everything is setup, resolved all of the error,
but now it just gives me above pasted LOC. and not the expected deletable resources.
So, I expect it to show me the full log.
Thanks !

cc: @mshriver

Looks like some overlap with the intent of #4, though I think its good for this to focus on the logging approach in general.
The types of improvements I would like to see include:

More debug level logging statements during provider query and resource filtering
log level control from the CLI
log level control via envvar (nice to have)
Removal of "settings validated" message, replace with confirmation of authenticated connection

@mayurilahane @mshriver After debugging, looks like the regions setting value was not been seeded well to the tool. I agree though that the tool should have inform the same about this situation and inform that regions are must to proceed.
@mayurilahane You can contribute to log is the regions are missing either through info or through settings validation.


Allow circular preview

Add an extra handle cb and option to provide developers with the possibility to provide a circular preview.
This is much used to preview avatar images ( as they are shown in a circular form most of the time.

Nice script thank you @peterver! Are there any news on the circular preview?

going to look into it somewhere tomorrow evening :]

don't wanna hurry you, but would love to use your extremely small cropper :)

damn, i completely forgot about this issue, my bad. I've got some time on my hand this weekend. will look into it !

great :)

started working on it, not yet finished though
will release asap ^.^

Sounds good :D
Just let me know by commenting here ;-)

closing this issue as added in 1.1, tell me what you think about it :] ?

yeah think that does the job :) thank you!
now I just need to switch from croppie to your nice work, which is about a quarter of the size (spoiler^^)
unfortunately it's a closed community so I won't be able to show you in action :/

i know what you're talking about, i built this component for the webapp that we're developping at Skedify. We were originally using ngImgCrop, but it just didn't do the job well enough, and its about 5x the size of this one. Oh well :').
Should you have any more feature requests or issues that you encounter, be sure to create an issue for them :], always happy to improve this little package


Ledger should be able to sign arbitrary params on method 0 messages

There's a wrapped FIL project that requires the Glif wallet to enable the user to encode base64 params in Method 0 transactions (with expert mode enabled is fine). When I try to do this with current Ledger Filecoin app, I get a "Data is invalid : unexpected number of items" message.
I'm hoping this is something that's relatively straight forward to enable on the Ledger since it already exists in wasm and multisig.

At the moment, the Ledger app enforces that transfer (txs with method=0) to have zero parameters as per the transfers spec.
The code to change is here:
https://github.com/Zondax/ledger-filecoin/blob/44666b651039acae975d72dc46c8d0c9fd5e3106/app/src/parser_impl.c#L210-L212
We could make this flexible in the case of expert mode, however, we would need Protocol Labs to formally request and review this and get Ledger to release a new app version.
As txs with method=0 are actually references to the constructor methods of all actor types, we see the use case. However, be warn that we will not be able to format these parameter correctly.

moving to the ledger app repo


This extension may have been corrupted.

Hi,
I need a new custom theme, and go to
./Library/Application Support/Google/Chrome/Default/Extensions/gbmdgpbipfallnflgajpaliibnhdgobh/0.12.0_0/themes/dark
when i add a new theme such as other themes i don't see this theme in Extension option and when i changed other existed i give this error:
This extension may have been corrupted.

Hi @mehdibahraami, it's not that simple to add a new theme, there are some internals that need to be configured. What do you think about the following options?

Switch to the default theme and use the "Custom Style" field to apply your theme, it's possible to override everything through this option. Check the Options page.

If the theme is free you can post the style here and I can add to the extension for everybody.

Thanks.

Yes, this is my theme.

Yes, this is my theme.
.cm-s-mehdi.CodeMirror {
background:#2c3e50!important;
color:#ecf0f1!important;
}

.cm-s-mehdi div.CodeMirror-selected {
background:#16a085!important;
}

.cm-s-mehdi .CodeMirror-gutters {
background:0 0!important;
border:none;
}

.cm-s-mehdi .CodeMirror-guttermarker {
color:#3498db!important;
}

.cm-s-mehdi .CodeMirror-guttermarker-subtle,.cm-s-mehdi .CodeMirror-linenumber {
color:#7f8c8d!important;
}

.cm-s-mehdi .CodeMirror-cursor {
border-color:#ccc!important;
}

.cm-s-mehdi span.cm-comment {
color:#7f8c8d!important;
}

.cm-s-mehdi span.cm-atom,.cm-s-mehdi span.cm-number {
color:#f1c40f!important;
}

.cm-s-mehdi span.cm-tag {
color:#e2777a!important;
}

.cm-s-mehdi span.cm-error {
background:0 0!important;
color:#7f8c8d!important;
}

.cm-s-mehdi .CodeMirror-matchingbracket {
color:#27ae60!important;
}

.theme-mehdi-css-check:before {
content:'loaded';
display:none;
}

.extras .icon svg {
fill:#fff;
}

.extras .icon:hover {
background-color:#333;
}

.cm-s-mehdi.CodeMirror ::selection,.cm-s-mehdi.CodeMirror ::-moz-selection {
background:rgba(73,72,62,.99);
}

.cm-s-mehdi span.cm-attribute,.cm-s-mehdi span.cm-keyword,.cm-s-mehdi span.cm-property,.cm-s-mehdi span.cm-variable,.cm-s-mehdi span.cm-variable-2 {
color:#ecf0f1!important;
}

.cm-s-mehdi span.cm-string,.cm-s-mehdi span.cm-string-2,.cm-s-mehdi span.cm-link {
color:#1abc9c!important;
}

.cm-s-mehdi span.cm-bracket,.cm-s-mehdi span.cm-def,.cm-s-mehdi .CodeMirror-activeline-background {
color:#2e383c!important;
}

Released in version 0.13.0

@tulios Thanks Man.


NCO function will not append

Reported by ansley b manke on 31 May 2013 22:29 UTC
The ncks operator can be used to append the variables in a dataset into another dataset.  To append file1 onto file2,

ncks -A -h file2.nc file1.nc

Ferret's NCO function should be able to be called to send that command to the system,
yes? let status = NCO("ncks", "-A -h file2.nc file1.nc")
yes? load status

but the call results in:
ncks: ERROR FORCE_OVERWRITE and FORCE_APPEND are both set

For convenience we automatically add -O for override and -h for history onto NCO command calls.  We should check for -A and if the user specifies it, don't add -O.
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/2074

Comment by ansley.b.manke on 6 Jun 2013 20:57 UTC
Done.  A benchmark script bn_nco_append.jnl tests this.


Stream file from HTTPS with untrusted or missing certificate

Hi,
I want to stream a file from HTTP or HTTPs but I don't know how to set these options:

(Solved) - Problem was blank spaces in URL.
Ignore Certificate Warning or Errors on HTTPS Connections (if possible).

I tried to use Windows.Web.Http.HttpClient but that won't work very well.

I want to stream a file that is from and HTTP address, however it requires an Authentication Header in order to receive it. Is this possible or needed to be added? I can't seem to get it to be fetched in stream form for FFmpeg.


Add ability to see the logs of the model server

It would be nice in the model service page, to be able to let the user access to the log of the server - which can be helpful for debugging.

It would be nice in the model service page, to be able to let the user access to the log of the server - which can be helpful for debugging.

You can click on the container icon, and it will redirect to the container logs in podman-desktop
https://github.com/projectatomic/ai-studio/assets/42176370/071c6bf6-70c4-4703-aa57-fb37193ba3ba


Feature request: Retrieve model name from model

E.g. in below example can I recover “m4_2” from m4_2t?
@model m4_2(x, y) = begin
    #priors
    alpha ~ Normal(178.0, 100.0)
    beta ~ Normal(0.0, 10.0)
    s ~ Uniform(0, 50)
    #model
    mu = alpha .+ beta*x
    y .~ Normal.(mu, s)
end
# Draw the samples
m4_2t = m4_2(x, y)
chns = sample(m4_2t, NUTS(0.65), 1000)

No, AFAIK this is not possible. However, you can, e.g., retrieve a model with modified arguments, so I'm wondering what your use case is. Do you actually need the name m4_2 here? Or is the main objective to call m4_2? BTW (since it changed recently) m4_2 is just a regular Julia function (that creates the model) with the same function signature as defined by the user (the Turing @model doesn't modify it in any way).

Hi David, thanks for your response. I am really looking for the name (string) "m4_2" in my use case when plotting the parameters of several models, e.g. as in https://github.com/StatisticalRethinkingJulia/StatisticalRethinking.jl/blob/master/scripts/05/Fig-12b.png.

I see. I implemented this feature in https://github.com/TuringLang/DynamicPPL.jl/pull/175.

Thanks David, super!
On the 2nd part of your response ("regular Julia function"), is there a difference if I use (added the word function):
@model function m4_2(x, y) = begin
    #priors
    alpha ~ Normal(178.0, 100.0)
    beta ~ Normal(0.0, 10.0)
    s ~ Uniform(0, 50)
    #model
    mu = alpha .+ beta*x
    y .~ Normal.(mu, s)
end

or is the old way equivalent?

If you add function, then you need to remove = begin. In julia you can either write a function as
function f(x)
end

or
f(x) = begin
end

And the @model macro simply wraps a function, hence you can use either of the above:)

Though
function f(x) = begin
end

is not valid.

They are both equivalent, in the same way as
f(x, y) = begin
    x + y
end

and
function f(x, y)
    x + y
end

are equivalent.
But note that you have to remove the = begin part, i.e., you should write
@model function m4_2(x, y)
    #priors
    alpha ~ Normal(178.0, 100.0)
    beta ~ Normal(0.0, 10.0)
    s ~ Uniform(0, 50)
    #model
    mu = alpha .+ beta*x
    y .~ Normal.(mu, s)
end

However, it gets a bit more interesting with keyword arguments. In previous Turing (or rather DynamicPPL) versions the function signature was parsed in a special way by @model, and hence, e.g., it was not possible to use keyword arguments (and type annotations were also modified in some cases). This is not the case anymore, you can just use the regular Julia syntax now (and e.g. use keyword arguments and default positional arguments in the standard way).

Of course, that makes sense! Thanks a lot!

I'll close this issue since the feature was added to DynamicPPL. As soon as https://github.com/JuliaRegistries/General/pull/22539 is merged into the registry, an update with Pkg should give you the latest version which supports to retrieve the "name" of a model with nameof. E.g., in the initial example you should be able to get the name :m4_2 with
nameof(m4_2t)


Resolve auto inertia based on input mass

🎉 New feature
Closes https://github.com/gazebosim/sdformat/issues/1482
Summary
Support auto-inertia computation using mass and density. Implemented based on the suggestions in https://github.com/gazebosim/sdformat/issues/1482#issuecomment-2353689699 and https://github.com/gazebosim/sdformat/issues/1482#issuecomment-2397585273
inertia is first auto resolved from all collisions as usual. If mass is specified, we normalize the inertia to get unit inertia, then scaling is applied to match the desired mass.
Marked as draft to get feedback on implementation and correctness of math
Checklist

[x] Signed all commits for DCO
[x] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

this looks good! I've added some tests in https://github.com/gazebosim/sdformat/pull/1514 targeting this branch that you can merge into this branch if they seem reasonable

this looks good! I've added some tests in #1514 targeting this branch that you can merge into this branch if they seem reasonable

nice, test looks good, thanks!

Merged tests from #1514 and updated Link's ResolveAutoInertials API doc on how auto inertia computation works if mass is specified. This PR is now ready for review.

I think we should also update the auto_inertial_params_proposal proposal as well, and at some point write a tutorial / documentation since the proposal has now been implemented, but I won't block this PR on either of those tasks

I think we should also update the auto_inertial_params_proposal proposal as well

Updated the proposal in https://github.com/gazebosim/sdf_tutorials/pull/100

I think we don't have a test involving multiple collisions with different density values attached to a link with auto-inertial and explicit mass. I think that would be ideal, but I won't block on it

I think we don't have a test involving multiple collisions with different density values attached to a link with auto-inertial and explicit mass. I think that would be ideal, but I won't block on it

added tests for auto inertial with link mass and multiple collisions in c072a17 and 410d4e6

I think we don't have a test involving multiple collisions with different density values attached to a link with auto-inertial and explicit mass. I think that would be ideal, but I won't block on it

added tests for auto inertial with link mass and multiple collisions in c072a17 and 410d4e6

thanks; I'm did the math to verify the inertia values for that test case, and it looks right but a bit complex. I'd like to have our test expectations documented, so I'll propose a slight variation of the test geometry that places the lumped center of mass at the origin to simplify the math and then document that. I can do that in a follow-up PR if other concerns are resolved before I have a chance to write it up

Looks great overall. One of the goals for calculating the inertia based on mass was to make it possible to calculate the inertia even when density values are not set. Do we know if that works? Maybe we can add a test?

If density is not explicitly set by the user, the default value should be used. Yes I can add or change a test in a follow-up PR after @scpeters updates the test for computing auto inertia involving multiple collisions

This also means we can stop emitting a warning if a Collision is missing its  if mass is provided:

removed warning ca94a22

I'd like to have our test expectations documented, so I'll propose a slight variation of the test geometry that places the lumped center of mass at the origin to simplify the math and then document that. I can do that in a follow-up PR if other concerns are resolved before I have a chance to write it up

thanks! I've addessed remaining comments except the one about adding a test with no <density> specified. Let's do that in follow-up PR(s).

One last thing I thought of is whether this would break existing SDF files. If you have a link with the mass specified as well as densities in the collisions, previously, the mass was completely ignored. Now, the mass will override the densities which will likely result in different MOI values. Am I correct?

One last thing I thought of is whether this would break existing SDF files. If you have a link with the mass specified as well as densities in the collisions, previously, the mass was completely ignored. Now, the mass will override the densities which will likely result in different MOI values. Am I correct?

yes this will be a behavior change so we would likely need to retarget this to main. Alternatively we could add another attribute to toggle whether to use mass or density for auto-inertia, e.g. .

One last thing I thought of is whether this would break existing SDF files. If you have a link with the mass specified as well as densities in the collisions, previously, the mass was completely ignored. Now, the mass will override the densities which will likely result in different MOI values. Am I correct?

Currently there is a warning when specifying mass with //inertial@auto == true saying that the mass will be ignored. This PR definitely introduces a behavior change for files like that since the mass will rescale the MOI values (though with multiple collisions the relative density still has an effect on the MOI). As to whether this is a "breaking change", this fixes a warning and honors the intent of the mass value.
We can certainly merge this to main. If we want to backport it to Ionic or Harmonic, we would need to clearly communicate the behavior change. Since it fixes an existing warning, I think there's a case to be made that it could be backported.

I'd like to have our test expectations documented, so I'll propose a slight variation of the test geometry that places the lumped center of mass at the origin to simplify the math and then document that. I can do that in a follow-up PR if other concerns are resolved before I have a chance to write it up

thanks! I've addessed remaining comments except the one about adding a test with no <density> specified. Let's do that in follow-up PR(s).

here's my update to the multi-collision / multi-density test: https://github.com/gazebosim/sdformat/pull/1515

rebased changes to main and forced pushed

This also means we can stop emitting a warning if a Collision is missing its  if mass is provided:

removed warning ca94a22

It looks like the warning is unconditionally removed, regardless of whether //inertial/mass is set or not. It's tricky to conditionally remove the warning since Collision::CalculateInertial doesn't know whether the Link inertial has an explicit mass value set. I think we would need to either add a _warnIfDensityIsUnset flag to Collision::CalculateInertial method, or we could try to delete the ELEMENT_MISSING errors in this loop in Link.cc

I think we would need to either add a _warnIfDensityIsUnset flag to Collision::CalculateInertial method, or we could try to delete the ELEMENT_MISSING errors in this loop in Link.cc

I went with the option to add a _warnIfDensityIsUnset arg to Collision::CalculateInertial in 2509d55. I think it implements what you're suggestion, please take another look, thanks.

I went with the option to add a _warnIfDensityIsUnset arg to Collision::CalculateInertial in 2509d55. I think it implements what you're suggestion, please take another look, thanks.

@scpeters do the changes in 2509d55 look good to you?

I went with the option to add a _warnIfDensityIsUnset arg to Collision::CalculateInertial in 2509d55. I think it implements what you're suggestion, please take another look, thanks.

@scpeters do the changes in 2509d55 look good to you?

Yes, that looks good; I want to see if we can add a test that verifies the presence / absence of the errors / warnings depending on that new flag

I went with the option to add a _warnIfDensityIsUnset arg to Collision::CalculateInertial in 2509d55. I think it implements what you're suggestion, please take another look, thanks.

@scpeters do the changes in 2509d55 look good to you?

Yes, that looks good; I want to see if we can add a test that verifies the presence / absence of the errors / warnings depending on that new flag

see #1520

see https://github.com/gazebosim/sdformat/pull/1520

merged!


Fix for NameError: uninitialized constant Sinatra::Sprockets::Manifest

Solves #70. I was also experiencing this issue. Adding the :: fixed this. Same fix as per another older issue.

Looks great. Thanks!


options to limit max memory uaage

I saw in docs many options to limit memory per partition, broker, fetch and other.
But in microservices we need to limit upper memory size not ,  and number of brokers and partitions does not matter because it can change over time.
Can you suggest how to limit?

As a consumer or as a producer?
As a producer, you can limit MaxBufferedMessages, and then application side, limit the size of what you're producing, so that you know there's an upper bound of messages*record_size.
As a consumer, you can limit AllowedConcurrentFetches, and then limit FetchMaxBytes, so that you know at most n_concurrent_fetches*fetch_max_bytes will be buffered internally (minus the one caveat that if a single record exceeds FetchMaxBytes, kafka will return it).

(I may change AllowedConcurrentFetches to MaxConcurrentFetches for the 1.0 release--allowed is odd naming considering the rest of the API)

One last note: inflation from decompression cannot really be controlled. If a small fetch inflates to 1G when decompressed, the client can't know that going into the decompression. It's best to limit this on the producer side by setting BatchMaxBytes, which is the maximum uncompressed size when producing before compression is involved.

no i'm not use compression =) yes question about consumer

@twmb strange...  i'm set FetchMaxBytes to 10Mb and
{"level":"debug","@timestamp":"2021-08-25T10:15:55.308+0300","caller":"kgo/logger.go:122","msg":"read Fetch v12","bytes_read":52429152,"read_wait":0.000123409,"broker":"2"}

as you see bytes_read contains 50mb

all fine thanks


How to keep the number of mesh vertices during training in each epoch?

When training in multiview reconstruction tasks, we found that you provided 3 different method to initialize points. We tried 'sample' init_method and sample 3000 points on GT mesh. However, it seems that at the end of epoch_0 the number of mesh vertices decrease to less than 1500 in most cases. Even if we decrease the hyperparameter weight_regularizer_coef to 1e-9, the number of vertices at the end of epoch_0 phase_0 is still small.
Here is the curve of mesh vertices during multiview reconstruction of 252119 data in thingi32 dataset during epoch_0 phase_0. How to reduce the number of points lost during optimization?

A more extreme case is that if we sample 30000 points to initialize, the number of points left after optimization is less than 3000 for the case metioned above.

Hi, thanks for pointing this out and sorry for the late reply.
As you pointed out, currently we can observe this kind of undesirable phenomenon when it comes to the multi-view reconstruction task. We believe this is because of the false gradients generated by merging two different renderers in the first phase of the optimization. As described in the paper, we use two different kinds of renderers in the first phase of the optimization, because one of the renderers does not generate visibility gradients. We use nvdiffrast's implementation to get those gradients, but there is possibility that naively merging these two renderers could end up in this kind of phenomenon.
One possible way to overcome is developing a genuine renderer that supports efficient rendering of transparent triangles and generates visibility gradients at the same time seamlessly, but we found out that it is too massive task to do it in this work and out of scope.

Hmm, it's interesting. Can you please check if the number of soft faces is exactly reason why that the out of memory error occurs? Because I think it is hardly possible for the number of soft faces causes that kind of error (even if there is 1 million faces, the memory is not so large). And in our current implementation, the number of soft faces increase monotonically because we keep appending the new possible face combinations to the already existing list. How about using the smaller number of seed points to avoid this issue?

Hmm, it's interesting. Can you please check if the number of soft faces is exactly reason why that the out of memory error occurs? Because I think it is hardly possible for the number of soft faces causes that kind of error (even if there is 1 million faces, the memory is not so large). And in our current implementation, the number of soft faces increase monotonically because we keep appending the new possible face combinations to the already existing list. How about using the smaller number of seed points to avoid this issue?

Thanks for your answer！


Can't start the app.

When I try to start the client the SmartScreen says "This app can't run on your PC" "To find a version for your PC, check with the software publisher. I disabled SmartScreen in Windows Defender Center. PLS HELP

Add an exception to your Antivirus.

Thnx. That solved it!


size parameter for parse()

to save one call to strlen(), I think such a parse() function should be provided. A similar parse for char array, with size deduced is already provided.

When would you use this when you couldn't use the two iterator version?

There are many convenience parse()s already, why not this one as well?

If you have char *s, and its size, you can already do parse(s, s+size).  Are you looking for something different?

just a convenience function, what you describe is exactly what I want.

Well, it's up to @nlohmann but I don't see that the convenience benefit for parse(s, size) compared to parse(s, s+size) outweighs the cost, as additional overloads increase complexity and the possibility of ambiguity.

The parse(s, s+size) constructor is much more versatile, because it allows to take any iterator range. An additional iterator parse(s, size) would just copy a subset of the features of the former.
Personally, I think the former feels more C++ like, whereas the latter feels more like C. But ymmv.

good C is also C++

There is a precedent for my suggestion:
http://en.cppreference.com/w/cpp/string/basic_string/basic_string
std::basic_string<> has such a constructor, that's about as C++ as anything.

STL is not a pinnacle of modern c++ design - it has some ugly warts here and there, which is mostly due to legacy baggage (compatibility with C, pre-c++11). I think new/modern APIs that are not burdened with backward-compatibility promises should avoid/discourage legacy-style usage.

Then we agree to disagree.

I have a rival json library I wrote, I'll just publish it, with the said overload, of course.


Not prompted to save file after removing customUI

After removing a customUI element and trying to close the file / the entire program, the "Unsaved Changes" dialog is not shown.
Related to #10.

Fixed in f85a38b


Retain order if these or make_class are passed an ordered dict

Fixes #339

Also fixes #300
cc @pombredanne @leezu @Julian

Woohoo! Nice!

@hynek LGTM! thanks++

So I tested this alright on my side. Thanks ++ to both of you for the quick handling! attr rocks. you rock!
Reviewed-by: Philippe Ombredanne<EMAIL_ADDRESS>

@Tinche Thanks!


Allow configuration of date formats

I'd prefer to use ISO 8601 date formats (YYYY-MM-DD) in the prolog elements, but I don't see any way to configure that in the preferences or plug-in code.

Hi, @infotexture!
Thanks for the feedback.
We will add a field for configure the date format in the next version of this plugin.

The new release version(1.0.9) contains a new configure option for the date format.

Excellent, thanks! 🙏


FileUriExposedException:

I have this error..
Caused by: android.os.FileUriExposedException: file:///storage/emulated/0/Android/data/com.soin.TSA/cache/pickImageResult.jpeg exposed beyond app through ClipData.Item.getUri()
Looks like this happens on Android N
if (Build.VERSION.SDK_INT >=  Build.VERSION_CODES.N) {
          imageUri = Uri.parse(filepath);
    } else{
           imageUri = Uri.fromFile(new File(filepath));
    }

The method getCaptureImageOutputUri() use Uri.fromFile

Hi @ArthurHub @mradzinski @unverbraucht @Vantablack @gazialankus  any chance we can get a fix for this?  This is crashing expo apps and bare apps on any Android device running API 24 or later and we can't use the camera there.  See the attached expo issue.  Any way I can help?  I can test on device or I'd be willing to provide a $ cash bug bounty to fix this if that helps.  :-)
I'd offer a PR myself but my Android skills are weak.

I'm experiencing this crash using the sample app on Android Q Beta 4

@ArthurHub I also hit this crash on the Android Q beta 4.  Is it possible for you to merge the PR from @annatindall and issue a 2.9.0 release of imagecropper.  Thanks.

Hi @ArthurHub any news on when you might be able to release an update including this fix, thanks.


Templates used twice in another template substitute the wrong data

Assume we have a template  When I set  year
If we:

put it into another template, say When I set all dates
call When I set  year twice with  and  values
then only first value will be putted inside a both calls

<year1> = 2019
<year2> = 2020
...
When I set <year1> year // will set 2019
...
When I set <year2> year => will set 2019 again instead of 2020

Problem in code might be in here inside of reduce

Fixed in 0.0.5


"Healthcheck" for image config

In https://github.com/opencontainers/image-spec/blob/master/config.md#properties
There is a healthcheck property carrying over from docker's HEALTHCHECK.
It is commonly seen and I've now been asked at a couple of conferences howcome OCI image spec does not account for it.

Hm, not sure about an issue discussing health checks, but I can see this being application-specific, so not part of the specs for that reason. Possibly @stevvooe knows more about that

To play devil's advocate - how is Healthcheck application-specific, but ExposedPorts not application-specific?
What does "application-specific" mean in this context?

To play devil's advocate - how is Healthcheck application-specific, but ExposedPorts not application-specific?

the thing was: let's not add another application-specific thing to the spec, no one said exposedports is not application specific :)

@runcom ah - a nuance that was unclear 😉

It seems like a generally useful check. Liveness is just that the pid is up, but a health check could be applied across most container runtime use-cases.

+1 for healthcheck. An image provides enough information to derive a runnable bundle from it - with additional defaults of the runtime. I like this approach because it follows the convention over configuration principle. A healthcheck in an OCI image would be a useful optional default value for a bundle.
At least for services the requirement to configure a healthcheck is pretty common. A healthcheck is indeed application-specific but if you don't support it users have to provide the same healthcheck in another configuration again and again when they cannot provide it with the image.

While healthcheck is a part of docker images, I don't think the design has proven to be very effective. We've had a number of bugs in docker due to the design of healthcheck. Also, since healthchecks are executed so close to the running container, the actual utility is very low.
If we are looking for terminology to divide this, the port is specific to the running service (a bound port on a process), while the behavior of the healthcheck is going to be dependent on the infrastructure (network, disks, etc.). In general, we can guarantee that a port gets exposed with much higher certainty than disks or network are available to run a service. Even with that argument, there could be an argument that ports shouldn't live in the image, either.
In practice, the methodology used by Kubernetes has proven that healthchecks belongs with the orchestration or infrastructure environment. In the case of kubernetes, they integrate with the load balancing system to ensure liveness/readiness when serving traffic. The healthchecks there are designed with the semantics of that system and work well in that context.
However, if we want to adopt healthchecks from Docker images, the impact is minimal. It can be done in a backwards compatible way and doesn't require a major version change to OCI. Hence, we don't have to rev the mediatype. While I am not a huge fan of the Docker image healthchecks, I don't see harm in importing the design if that is what people want to use.

I agree with @stevvooe on both points -- that the utility of healthchek information in an image is quite low, but that importing it is acceptable if that's what people want. However, I would like that any language that includes a healthcheck annotation or section in Config explain the problems with it (to ensure implementors decide whether they want to support it and whether they should look at better solutions to the problem).

I'm not sure about Docker's implementation of "healtch checks"; I would agree that they are less useful than it might seem.
What I miss most often is some form of "ready" flag. Take your average microservice: between the container being "up" and the application running and being able to serve requests -- let's call this state "ready" -- significant amounts of time can pass. I'm usually interested in waiting for "ready", be it manually, in docker-compose settings (depends_on), or provisioning containers with Ansible and such.
While "health checks" as implemented in Docker can be used to do that (if implemented with consistent semantics), none of the tools I've used include using it, which may just have to do with it being a non-standard feature.

Nice to have when use ECS

I'm closing this as the discussions properly capture the backstory on why healthchecks we're not carried forward

I agree with @reitzig that an application readiness command instruction or similar would be very useful and sometimes is necessary to guarantee the correct order of orchestration. Not knowing the history nor the intent of the Docker HEALTHCHECK instruction myself, I still can say that it is often necessary to know whether the application inside a container is (still) ready to service requests. A container is relatively quick up and running but as @reitzig says, between that and the actual application inside the container being ready to service requests, a lot of time can pass.
I am the author of images that provide a free Oracle Database XE inside containers: https://hub.docker.com/r/gvenzl/oracle-xe
I can tell you that I do get the question of how somebody can tell whether the database is already up and running or still up and running all the time, especially in the CI/CD environment where the container is used for regression testing and those tests cannot be kicked off before the database is ready.
Even GitHub Actions are leveraging Docker health checks to determine whether a container is ready to service requests before executing the rest of the actions pipeline, see for example the Postgres Service Container:
 # Set health checks to wait until postgres has started
  options: >-
    --health-cmd pg_isready
    --health-interval 10s
    --health-timeout 5s
    --health-retries 5

Perhaps health checks were never intended to be used for such a purpose but they certainly are abused for that. However, right now, there is no way to accomplish something like that with OCI based images. It would be great if an image provider (like myself) could also provide a way to tell the user (and orchestration layer) whether the software inside the container is (still) ready to service requests.

In practice, the methodology used by Kubernetes has proven that healthchecks belongs with the orchestration or infrastructure environment.

I don't know about you, but I find that liveness/readiness checks require knowledge about what's running in the container, to the point of very tight coupling. So while the semantics and use of the checks is rightfully defined by Kubernetes, I usually find the requests to parrot something the containered application exposes. A standardized interface, if there is a feasible one, in between would make things simpler (as in, less coupled).

I'd like to add my point of view as a maintainer of the testcontainers-java library (https://github.com/testcontainers/testcontainers-java/), a library for instrumenting containers as part of integration tests and in which we support the usage of HEALTHCHECK to wait for a container to be in a usable state. Please note that this is my personal opinion and it should not be considered the official opinion of the Testcontainers projects.
While a lot of the argumentation in this issue is very reasonable, I have a feeling this is mostly informed by considering the operation of containers, specifically by orchestrators such as k8s. However, the use case that has also been outlined by @gvenzl, e.g. using it to start dependent applications for development, testing, and CI/CD pipelines, is a widespread use case in the developer community.
With Testcontainers, we provide a feature, that allows users to define the healthcheck that indicates the readiness of the application inside the container as part of our API (we call them WaitStrategies). While this is easily possible if you are the developer of the used image and have knowledge about the implementation of the application and stable indicators of readiness, this becomes very hard if you are simple a user of a readily available image, e.g. any of the official database images out there (like Oracle or PostgreSQL, as mentioned by @gvenzl). In my opinion, the developers of those images are in a much better position to formulate and implement a healthcheck, as compared to the user.
Also note, that while Testcontainers supports user-defined WaitStrategies, we also support the usage of the Docker HEALTHCHECK as the wait strategy. This means, that this might work for users using Docker for testing, while it will fail for users that use different container engines, thereby reducing interoperability and in general making it much harder for other vendors to develop "drop-in replacements" for Docker.
I will completely respect the decision of the specification authors, but I hope I could add some additional context for the usefulness of HEALTHCHECK in non-ops use cases.

Hey @vbatts, with the additional context given, could we get this issue reopened again and continue the discussion?

fair!
I'm personally not against it. I dislike the format that the one from docker ended up with, being that the healthcheck effective must exist as a CMD or CMD-SHELL inside the container, rather that being say an ["HTTP", "<port>", "/healthcheck", 200] or similar that the inspector/runtime/orchestrator can call at the container to see it it running, but that might could evolve.
Please consider opening a PR.
@thaJeztah @justincormack might we work from the definition in https://github.com/moby/moby/blob/master/image/spec/v1.2.md ?

Yeah, tend to agree that shell was not a great idea as it requires an exec into the container. We could add an http method into Docker. Interop is clearly an issue as nothing right now except Docker supports this now.

TL;DR: Yes, HEALTHCHECK is inelegant, but it helps in situations were doing things "properly" and "elegantly" is not possible or simple.
So in practical terms, and I'm probably "doing it wrong", it is helpful when I have something that wants to run as a systemd process. It is simple to have something that runs periodically to make sure that thing is still up and going.
While this isn't an optimal situation, it's also a good tool to throw something into a container that wasn't specifically designed to be in a container. It lets me know that everything is working properly in an un-opinionated way. I can write a shell script that checks exactly what I need it to check from the confines of the container. I can search logs, run a loopback request to the service, whatever the specific application calls for.
It's not an elegant solution, but it's a solution that allows me to deal with inelegant situations.

I'll add another weak argument in favor: it would be nice to have a minimal dependency implementation of the healthcheck parser for things like https://github.com/bazelbuild/rules_docker/pull/1742

Hey @vbatts et al,
It has been pretty much exactly a year since the last update on this issue, so I wanted to bounce it up again.
I would still love to have such a healtcheck functionality that I can use to signal when my containers are ready to use.
Hopefully, such a feature will make it into the spec and downstream container runtimes soon! :)
Thanks,

Question: Should we first talk about extending the runtime-spec?
Meaning that, maybe the actual problem is that status: running is not really fine-grained enough to represent application state.
That said, I would understand if the answer was: "that would muddle layers".
Still, it seems to me that container states and health/readiness checks are linked on a conceptual level.

I'm fine either way, as long as this issue starts to be looked at. I still think that just providing an infrastructure-like check of "the container is up" is pretty useless to the ones wanting to consume the container. It's like having a website and saying the server is up, but not checking whether the webserver itself is servicing HTTP requests.
How do you propose to proceed?

Hey @reitzig, @vbatts, et al,
Just wanted to check in on this again.
I still think it would be great to have some way of registering and running a healthcheck that reports the state of the software inside the container.

I am unopposed. As mentioned by others that are supportive albeit
acknowledging the use of shell is not as "ideal" as maybe an HTTP
endpoint.
Perfect is the enemy of good.
However, that kind of improved endpoint would be a future development.
As for getting current behavior into the spec: would you like to try
your hand at a pull-request for this? 🙏

In other words: I'm (soft, not blocking) opposed both because it's not been implemented by anything but Docker after all these years and because I think it's probably not been specifically because it was found not to be sufficient for the use case of checking container state (hence k8s having several related concepts to track this intent more granularly instead of using this one).

Hey @vbatts,
Thanks a lot for your response!
I'm happy to try but I am a total beginner in this space, just a consumer of the tech not really anything like an expert when it comes to the internals. So I'd have to kindly ask for your guidance in that matter, right now I don't even know where to start with the PR.
As to the @tianon comments, I dug around for K8s specifically, and yes, K8s uses liveness probes to accomplish the same but there was also a discussion to support specifically the Docker HEALTHCHECK features (see https://github.com/kubernetes/kubernetes/issues/25829) which seems to have just gotten stale and was eventually closed. From what I'm reading in between the lines, K8s had liveness probes before Docker introduced HEALTHCHECK, if that was the other way around, they may have settled just for that, but that's just pure speculation at this point.
There is one more issue (https://github.com/kubernetes/kubernetes/issues/50703) where they actively deactivated the Docker HEALTHCHECK not to interfere with the liveness probes but note their comment for the desire to support it eventually:
https://github.com/kubernetes/kubernetes/issues/50703#issuecomment-322851488
However, I couldn't find any issue where they actually state the desire for adding the support, so I guess for K8s folks this use case is solved with liveness probes.
Perhaps HEALTHCHECK isn't the right solution here but there still seems to be a desire for container runtimes to provide some sort of mechanism to verify the health of a container, whether that's k8s via liveness probes or Docker with HEALTHCHECK.
One could argue that having such a mechanism also defined for opencontainers may be worthwhile and valuable to the end users even if it ends up being different than to what Docker did.

As a container image author, I find useful to be able to inform users about the default health check method as I'm able to provide it the default command to run the service of the container.
This meaning is especially visible when I define the health check with the HEALTHCHECK CMD ["myapp", "run", "some", "test"] just aside the CMD ["myapp", "run"].

Yeah, tend to agree that shell was not a great idea as it requires an exec into the container. We could add an http method into Docker. Interop is clearly an issue as nothing right now except Docker supports this now.

Perhaps a good compromise could be to allow other methods than CMD to be passed on as a parameter as @vbatts outlined above (["HTTP", "<port>", "/healthcheck", 200]) but still default to CMD for interoperability purposes with Docker?

I like this idea as it will help to inform about how to check the application state without having to integrate the tools inside the container itself. For the "HTTP" idea above, it would be better to be able to define the "<http method>", to send for example a HEAD request and close when the HTTP headers are received.

With startup, readiness and liveness probes being much more fine-grained and granular, HEALTHCHECK seems like a relic of the past.
Users could be informed of potential probes with a simple README that most popular registries support.
Helm and other solutions also support adding the probes out of the box.
Also, the documentation label can be used to inform users where to find documentation for the image and how to write probes/healthchecks.
Finally, since even Docker builds OCI images by default, it is literally obsolete and IMO should be marked as such.

With startup, readiness and liveness probes being much more fine-grained and granular, HEALTHCHECK seems like a relic of the past.

Docker still supports the healthcheck, and the other Kubernetes specific probes are not part of the image config today.

Users could be informed of potential probes with a simple README that most popular registries support.
Helm and other solutions also support adding the probes out of the box.

That's necessary because Kubernetes doesn't have a way to read the values from the image today.

Also, the documentation label can be used to inform users where to find documentation for the image and how to write probes/healthchecks.
Finally, since even Docker builds OCI images by default, it is literally obsolete and IMO should be marked as such.

Docker's OCI images will include the healthcheck if defined. Reserving a documenting a field that is in active use by a popular implementation avoids having it treated as an undefined field that other implementations could use in an incompatible way.
Note that since the original issue was opened, #817 added this as a reserved field.
In the long run, I think it would be useful to define these sorts of checks in the OCI image-spec rather than having competing implementation specific approaches.

Slightly off-topic, but definitely related, and to expand on @sudo-bmitch comment above. (apologies upfront for lengthy comment)
As some here know, the OCI image specification was based on Docker's image "specification" and most parts were adopted by the OCI specs.
Some parts were either too specific for Docker, or not necessary for interoperability, and for that reason not included in the OCI specification. Backward (and forward) compatibility was essential for the OCI specs to succeed, so
instead of including those parts in the OCI specification, the spec allows for implementations to have extensions; healthchecks being one of those.
I know that historically there's been confusion around "docker images are not OCI images", which I would consider both "correct" and "incorrect"; the Docker image specification defines a superset of OCI images; docker images are OCI images, making use of the OCI's option to use extension fields (those that the OCI chose not to adopt).
Most of those extensions are not essential, which means that for implementations that decided not to implement them, Docker images are OCI images (in some cases with a different mediatype).
However, for implementations that do want to implement the extension fields, Docker's image "specification" was hard to find; it was captured in a subdirectory of the docker repository (https://github.com/moby/moby/tree/v20.10.8/image/spec), and the (Golang) implementation was integral part of the code base without a canonical definition (fun fact; at some point the actual implementation lived in the BuildKit repository).
I also not unintentionally put "specification" in quotes; while there were attempts to define the specification (linked above), those documents being part of the Docker code base itself meant that things evolved organically. Large parts were ill-defined other than "the implementation IS the specification", and tracing back history not all changes having found their way into the specs itself.
As specifications go; all credits to the OCI maintainers (past and current) for transforming the above into an actual specification.
To cut a long story short; we recently published Docker's image spec as a separate repository (and Go module); https://github.com/moby/docker-image-spec
The repository was extracted from the Docker code base; we tried to preserve history where possible; some trickery was needed to amend / backfill omissions (implementation changes not reflected in the specs).
In addition to the specs markdown, we also added a Go implementation, mirroring the same structure as the OCI image specs (which could (potentially) be used as a drop-in replacement); https://github.com/moby/docker-image-spec/tree/v1.3.1/specs-go
The module is implemented using the OCI types; it uses Go's ability to compose types, using wrapper structs to compose the OCI types and the extension fields; https://github.com/moby/docker-image-spec/blob/v1.3.1/specs-go/v1/image.go#L12
It's not perfect (far from), but a best effort to make the content discoverable, and in a more consumable way, and I hope it helps those looking to implement parts that were not included in the OCI specs itself.


With many people in the roster, uProxy gets QUOTA_BYTES exceeded.

My primary gmail.com account has many, many G+ friends/followers/whatever.  As a result, the roster load-up at start is very slow, taking minutes.  During the load-up, uProxy just shows "None of your friends on Google are signed into uProxy at this time" which is misleading and makes me think that uProxy is broken.
Perhaps we can put up a "please wait, loading" message?

OK but ... why is it so slow?

Indeed!  I figured that even if we made it relatively fast, we'd still have some slow cases (e.g., a slow XMPP server), and some UX for that would help!
Looking into why it's slow...

What is the state of vcard retrieval? Do we retrieve vcards (and images)
for all contacts or just ones that are currently online? Do we pace
retrieval of images?
On Tue, Jan 20, 2015 at 11:09 AM, Molly Ling<EMAIL_ADDRESS>wrote:

Indeed! I figured that even if we made it relatively fast, we'd still have
some slow cases (e.g., a slow XMPP server), and some UX for that would help!
Looking into why it's slow...
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/788#issuecomment-70712626.

Well, here's the result:
extensions::sendRequest:82 Unchecked runtime.lastError while running storage.set: QUOTA_BYTES quota exceeded
at chrome-extension://fmdppkkepalnkeommjadgbhiohihdhii/lib/freedom-for-chrome.js:7319:26
at Object. (chrome-extension://fmdppkkepalnkeommjadgbhiohihdhii/lib/freedom-for-chrome.js:7299:16)extensions::sendRequest:82 handleResponse
This repeats with every "Running monitor" message.
Adding "unlimitedStorage" as a permission makes this error go away.
It's still taking forever to load up.  But there aren't any more errors that repeat.

Here's what I get:

Perhaps those "Dropped unknown XMPP message" messages are really the problem?

How long do we show "please wait, loading", what if "non of your friends on
Google are signed into uProxy at this time", really?
On Tue, Jan 20, 2015 at 2:09 PM, Molly Ling<EMAIL_ADDRESS>wrote:

Indeed! I figured that even if we made it relatively fast, we'd still have
some slow cases (e.g., a slow XMPP server), and some UX for that would help!
Looking into why it's slow...
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/788#issuecomment-70712626.

When we've checked the entire roster?
Unless the loading problem (note -- I've been running an attempt to log-in
from a many-linked @gmail.com account for some time, without it ever
finishing) is due to one of the "dropped unknown xmpp message" messages I'm
seeing in my console.
Cheers,
$ ls
Lally Singh | Google Ideas http://www.google.com/ideas/ | Engineering |
<EMAIL_ADDRESS>On Tue, Jan 20, 2015 at 2:33 PM, salomegeo<EMAIL_ADDRESS>wrote:

How long do we show "please wait, loading", what if "non of your friends
on
Google are signed into uProxy at this time", really?
On Tue, Jan 20, 2015 at 2:09 PM, Molly Ling<EMAIL_ADDRESS>wrote:

Indeed! I figured that even if we made it relatively fast, we'd still
have
some slow cases (e.g., a slow XMPP server), and some UX for that would
help!
Looking into why it's slow...
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/788#issuecomment-70712626.

—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/788#issuecomment-70716904.

Currently I don't think uProxy (or freedom-social-xmpp code) knows when it
has reached the end of the roster.  I do believe that we retrieve vcard
info for all contacts, when really in uProxy's case we only want it for
clients also online with uproxy (not "ONLINE_WITH_OTHER_APP") - changing
the vcard fetching to skip ONLINE_WITH_OTHER_APP might speed things up a bit
On Tue Jan 20 2015 at 2:42:45 PM Molly Ling<EMAIL_ADDRESS>wrote:

When we've checked the entire roster?
Unless the loading problem (note -- I've been running an attempt to log-in
from a many-linked @gmail.com account for some time, without it ever
finishing) is due to one of the "dropped unknown xmpp message" messages
I'm
seeing in my console.
Cheers,
$ ls
Lally Singh | Google Ideas http://www.google.com/ideas/ | Engineering |
<EMAIL_ADDRESS>On Tue, Jan 20, 2015 at 2:33 PM, salomegeo<EMAIL_ADDRESS>wrote:

How long do we show "please wait, loading", what if "non of your friends
on
Google are signed into uProxy at this time", really?
On Tue, Jan 20, 2015 at 2:09 PM, Molly Ling<EMAIL_ADDRESS>wrote:

Indeed! I figured that even if we made it relatively fast, we'd still
have
some slow cases (e.g., a slow XMPP server), and some UX for that would
help!
Looking into why it's slow...
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/788#issuecomment-70712626.

—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/788#issuecomment-70716904.

—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/788#issuecomment-70718723.

Setting milestone to 0.9 (webstore launch) so we are sure to address this before public launch

freedom-social-xmpp had been storing images for each client, rather than each user, so there were duplicate images saved to storage.  Also now we are only getting images for ONLINE (uProxy) contacts, rather than ONLINE_WITH_OTHER_APP or OFFLINE contacts - this should greatly reduce the amount of data we store.  This was all done by Ray in https://github.com/freedomjs/freedom-social-xmpp/pull/98
I'll close this issue now - we can reopen if we see the error again.


The lastest wechat agent require to add trusted ip to the

What did you do?
I  can't figure out why the Alertmanager  doesn't send notifications to my Wechat agent with the same configuration but with a new agent, until I turned on the --log.level=debug:
level=debug ts=2022-08-07T10:02:28.742Z caller=wechat.go:190 integration=wechat response="{"errcode":60020,"errmsg":"not allow to access from your ip, hint: [1659866548640290968093754], from ip: 120.235.x.x, more info at https://open.work.weixin.qq.com/devtool/query?e=60020"}" incident="{}:{alertname="InstanceDown"}"
level=debug ts=2022-08-07T10:02:28.742Z caller=notify.go:735 component=dispatcher receiver=teams-ops-wechat integration=wechat[0] msg="Notify success" attempts=1
I found that wechat's newest agent has a new trusted_ips attribute, so this bug only affects the new created agents. It doesn't affect the exist ones.
I think this is a big bug, because it actually doesn't send any notifications to Wechat agent and took much time to figure out what happen.
What did you expect to see?
I expect this relative log should show in Error or Warn level to tell users how to fix it.
I’am a gopher beginner and here is my code trying to fix it:
type weChatResponse struct {
Code  int    json:"errcode"
Error string json:"errmsg"
}
func New(){
...
// The IP is not trusted by the agent
if weResp.Code == 60020 {
return true, errors.New(weResp.Error)
}
...
}
What did you see instead? Under which circumstances?
Environment

System information:
insert output of uname -srm here

Alertmanager version:
insert output of alertmanager --version here (repeat for each alertmanager
version in your cluster, if relevant to the issue)
0.23

Prometheus version:
insert output of prometheus --version here (repeat for each prometheus
version in your cluster, if relevant to the issue)

Alertmanager configuration file:

insert configuration here

Prometheus configuration file:

insert configuration here (if relevant to the issue)

Logs:

Alertmanager:

level=debug ts=2022-08-07T10:02:28.742Z caller=wechat.go:190 integration=wechat response="{\"errcode\":60020,\"errmsg\":\"not allow to access from your ip, hint: [1659866548640290968093754], from ip: 120.235.x.x, more info at https://open.work.weixin.qq.com/devtool/query?e=60020\"}" incident="{}:{alertname=\"InstanceDown\"}"
level=debug ts=2022-08-07T10:02:28.742Z caller=notify.go:735 component=dispatcher receiver=teams-ops-wechat integration=wechat[0] msg="Notify success" attempts=1

IIUC the Wechat endpoint responded with a 200 OK HTTP status code which Alertmanager considers to be a success. To change this, it would really help to find good API documentation for Wechat.


My game crashes only in the HTML5 release version

Godot version:
3.2.3.rc1.official
OS/device including version:
GLES2 / Linux (KDE Neon)
Issue description:
Hello, everybody! (Sorry for my english)
I wanted to report a bug related to a crash that happens only in the release version of HTML5 and it seems that other export releases also happen (so we were watching with my group).
I don't know the bugs, I didn't know how to see the bugs in a release version of html5, sorry about that.
In the debug version I didn't make the bug happen.
Steps to reproduce:
Play the release version (Sometimes crashing)
Here a video:
https://youtu.be/th9VveK1gUU
Minimal reproduction project:
Crazy Crabs - HTML5 - v1.1.2 (release).zip
Crazy Crabs - HTML5 - v1.1.2 (debug).zip
Code.zip

@MatiasVME Does the project crash when exported to Linux in release mode?

Duplicate of https://github.com/godotengine/godot/issues/28922. Check your code for possibly dangling Variants, as these are only fixed in debug builds as of 3.2.2. (Godot 4.0 has been refactored to include a dangling Variant fix that also works in projects exported in release mode.)


Error

dalfox: error while loading shared libraries: libgo.so.21: cannot open shared object file: No such file or directory

I'll respond with the same issue as #406  in the thread


is there android licode client?

I don't know about a "real" java app client, but licode works in chrome for android

Is there any sample code that works in android?


add modal form

Add modal input form for the fields

Not needed as of now as the parameters are taken through the query string. A different feature may be planned for allowing user input for the parameters


Missing flags for rhoas service-registry artifact metadata

rhoas service-registry artifact metadata
Need a way to update meta-data (name, description, labels, properties)
Need a way to specify a version (optional)

We need to get this done before release

CC @craicoverflow @rkpattnaik780 looking for your stance on commands layout
Requirements is to be able to edit metadata and fetch it. This is typically done by two commands

Model without group

rhoas service-registry artifact get-metadata
rhoas service-registry artifact set-metadata

Metadata as group

rhoas service-registry artifact metadata get
rhoas service-registry artifact metadata set

Metadata flags (terrible idea)

I personally like 1.2)

2 looks good to me.

I personally like 1.
Why get/set instead of describe/update?

 get/set were just operation names. Can do describe/update no problem

Is the main reason for joining the words to reduce the number of subcommands?

Generally for dataplane commands we might need to be less strict about crud command names as context might be different.

Actually that is 100% true.

Is the main reason for joining the words to reduce the number of subcommand?

Yes. Not sure if you like it. The reason for it is that it reduces number of tab in autocompletion and minimizes number of chars to type when autocompletion is not enabled.


perf(manger): use RefCell instead of roundtrip with BTreeMap

Previously I was trying to be pure during the mangler visit, where we save the new symbol ids in a lookup table. This obviously kills performance due to the huge amount of memory inefficiency.
This PR changes the symbol id to a RefCell, where we can safely mutate the symbol id. I don't know what other impact this may introduce ... but it works.

The rest of the performance lies within the semantic building algorithm, there should be some rooms for improvement.


Ubuntu and PostgreSQL 9.1 9.2 path to Unix socket problem

unable to connect to database: could not connect to server:
No such file or directory. Is the server running locally and accepting
connections on Unix domain socket /var/run/postgresql/.s.PGSQL.5432

Ubuntu 16.04 PostgreSQL 9.1
Ubuntu 16.04 PostgreSQL 9.2
Ubuntu 14.04 PostgreSQL 9.1
Ubuntu 14.04 PostgreSQL 9.2

Set path to Unix socket in tasks/users.yml.