Reintroduce error handling for pipeline export

The error handling for the case of no runtimes when exporting a
pipeline was removed in #2320 this reintroduces it without reverting
the solution in that PR
Fixes #2332
Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

that for Generic in the error looks bad, I'll push a small fix for that in a sec

just pushed a fix for the previous comment if you could take a quick second look


Could not resolve "mux-embed" error when using Image component

After following the installation instructions and trying to use the image component
<script>
	import { Image } from '@datocms/svelte';
</script>

I am getting this error:
Error: Build failed with 1 error:
node_modules/@datocms/svelte/package/components/VideoPlayer/VideoPlayer.svelte:28:16: ERROR: Could not resolve "mux-embed"
    at failureErrorWithLog (/Users/username/Documents/projects/datocms-svelte-repro/node_modules/esbuild/lib/main.js:1651:15)
    at /Users/username/Documents/projects/datocms-svelte-repro/node_modules/esbuild/lib/main.js:1059:25
    at /Users/username/Documents/projects/datocms-svelte-repro/node_modules/esbuild/lib/main.js:1527:9
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Which looks to be because I don't have a dependency of the video player installed, even though I'm not using that component.
I've created a barebones repro here, but issue can be easily reproduced by installing @datacms/svelte and importing the image component.
Thanks!

Sorry about that, @RhyG, and thanks for the detailed notes and example repo! I'll let the devs know and we'll provide an update as soon as we can.

@RhyG I just released version 2.0.2 that fixes the problem.
Thanks for reporting the issue and for the clear reproduction.

Wow that was quick, thanks heaps!


Framework to handle images

Use Kingfisher to handle download of images from URL

Resolve in pull request: https://github.com/EstefaniaGuardado/gitAppSwift/pull/21


Change to allow a qubit to be released if it is measured

This PR is for a change I made to allow a qubit to be released if it has been measured and no operation has been made on it after the measurement. This involved adding an isMeasured field to Qubit, and setting its values appropriately. I also added 2 unit tests to confirm the desired behavior.

Releasing a Qubit measured in a different base, the qubit is still in super-position on the Z bases but it doesn't throw:     using (q = Qubit()) {
         H(q);
         let _ = Measure([PauliX], [q]);
     }

Quick comment, but this should be entirely OK, as the qubit is still in a deterministically known state at the point that it is released, such that appropriate instructions can be automatically added to reset it to the |0⟩ state.

For a bit of extra context, Aniket already found that the simulator handles release of qubits properly. See this code from the simulator.hpp elsewhere the repo:
    bool release(unsigned q)
    {
      recursive_lock_type l(mutex());
      bool allok = isclassical(q);
      if (allok)
      allok = (psi.getvalue(q)==false);
      else
      M(q);
      psi.release(q);
      return allok;
    }

When the qubit is released, the simulator will check if it's in a classical value (defined as |0> or |1> in the Z-basis), and if not, it performs a measure. That measure has code to explicitly collapses the state. Then it returns the boolean indicating whether the qubit was originally in a classical state and whether that classical state was |0>, then the higher level code in QubitManager would throw. So the simulator doesn't actually care and will handle the qubit no matter what state it is in, it's just a matter of what the QubitManager will allow, hence the fix that Aniket is building.

@swernli, yes, the simulator works correctly, and there is an option to disable this behavior (is just on by default).
The reason is on is because this is a common cause for invalid algorithms. You could question if there is a real value on doing this, since at the end users just get around this by calling Reset; I believe not having to call Reset but still throwing un-measured Qubits makes it more robust and makes the code cleaner.

The reason is on is because this is a common cause for invalid algorithms.

Agreed, but there's also value in that avoid reset by coherently unpreparing qubits is a common and useful optimization. For example, the target qubit in Deutsch–Jozsa is deterministically in |−⟩ after the query, such that an H and X operation call are sufficient to return the target qubit to |0⟩ for reuse, avoiding a potentially expensive measurement. Similarly, the same phase kickback trick is often used to perform common reflections, such that the state of a scratch qubit used in reflections can be efficiently unprepared without measurement or resetting.

Agreed on all points. I was just clarifying the simulator behavior because of some phrasing; as we are discussing this issue, we keep talking about what is "ok" or what "works" but any and all of these approaches can work, it's about what patterns we want to allow and encourage. So the question we should be asking ourselves is: what do we want the simulator to teach people about how to manage their qubits? What usage patterns do we want the simulator to reject so that it forces developers to adjust their programs?
The question of whether or not to clear the IsMeasured property when a qubit is used as a control is a very interesting one to me. Is using something as a control a "usage" in the sense that it invalidates the collapsing that occurred during the previous measure? Is that something that can vary between different kinds of qubits or hardware implementations? It's easy to ignore control qubits in the code, so either way can be quickly implemented. But I honestly don't know which way is correct given our goals of using this exception as instructive for algorithm correctness.

The question of whether or not to clear the IsMeasured property when a qubit is used as a control is a very interesting one to me. Is using something as a control a "usage" in the sense that it invalidates the collapsing that occurred during the previous measure? Is that something that can vary between different kinds of qubits or hardware implementations? It's easy to ignore control qubits in the code, so either way can be quickly implemented. But I honestly don't know which way is correct given our goals of using this exception as instructive for algorithm correctness.

Suppose after a measurement, the qubit left is left deterministically in the |+⟩ state, and then used as a control for a CNOT operation CNOT(left, right), where the initial state of right : Qubit is |0⟩. Immediately following that, the joint state of [left, right] is (|00⟩ + |11⟩) / √2.
Even worse, if you instead do a CNOT(left, right) with right starting in |−⟩, then the final state of the register is |−−⟩ not |+−⟩.
Put differently, the word "control" in the context of a controlled quantum operation is at most a mnemonic. A two-qubit operation can in general change the joint state of both qubits, even if one is only a "control." You can even reverse which qubit is a control and which is a target using H operations:
within {
    H(left); H(right);
} apply {
    CNOT(right, left);
}

// is equivalent to
CNOT(left, right);

From that perspective, I would strongly argue that IsMeasured has to be cleared when a qubit is used as a control in a quantum operation.

That's an excellent explanation, thanks @cgranade !

That's an excellent explanation, thanks @cgranade !

Thanks, happy to help!

I have to say, this is an exciting change from the libraries perspective! We've gotten feedback about the variety of different ways that measurement is used in the libraries, and in particular, that it's not clear when a reset is needed and not without looking at detailed API docs. This change would allow us to adopt the convention that measurements other than MReset* do not reset ever.

After looking at this thread, I am attempting to summarize the required changes:

The behavior for control qubits can stay as is, and thus the isMeasured should stay as false for the controls after a multi qubit operation
As far as properly releasing goes, the C++ side of the code handles it correctly
The only changes in behavior that would be required is around the DumpManager behavior which calls CheckQubit, but should be allowed to be Release if it has been previously Measured
@anpaz-msft @swernli @cgranade

That summary looks good to me (plus the renaming feedback which you already mentioned you'd be addressing).

After looking at this thread, I am attempting to summarize the required changes:

The behavior for control qubits can stay as is, and thus the isMeasured should stay as false for the controls after a multi qubit operation

That's correct; control qubits aren't special, such that the postcondition represented by isMeasured can be violated by passing qubits as controls. In particular, if I understand correctly, isMeasured represents the postcondition that the qubit is: (0) not entangled with any other qubits, and is (1) in a deterministically known state, such that it can be coherently returned to the |0⟩ state (that is, without further measurement).

@anpaz-msft Could you please take another look whether the changes you requested have been addressed?


preset versus favorite

First Thank you! for this awesome code...works great, really appreciate your effort!
I'm confused about presets vs favorites.  I have several "sonos favorites" that include Pandora stations, napster playlists or library playlists.  When I try "ask sonos to play favorite (Pandora station)  in ROOM" it does nothing.  I do have Pandora username and password in setting.json.  Looking at the utterances code it looks like favorites are actually "{presets}"...is that true?  so...should my preset.json match my "sonos favorites" list?  If so, how do I find the uri for Pandora and napster favorites?
Thanks again!
Kevin

@ksipp01 - "favorites" are Sonos-designated.  IIRC, they have a name that you give them when you create them in Sonos (as opposed to naming them in Pandora).
"Presets" are created in node-sonos-http-api.  They're a grouping that exists outside Sonos; a way to tell the API to do a bunch of things to Sonos all at once, including playing something.

FWIW: I do not have my pandora username and password in settings.json. I am able to add a Pandora station as a Sonos Favorite, and trigger it, in my case: "Alexa, ask Sonos to play Favorite Test". (neither here nor there, but it had some issues with the utterance "Arcade Fire Radio" or even just "Arcade Fire").

If the stations work from Sonos favourites then you could try adding them to the PRESETS custom slots TYPE in the skill  and see if that helps, it should help Alexa recognise their favourite name better. You can also try from the URL //yourserveraddress:5005/ROOMNAME/favourite/FAVOURITE_NAME and see if that works


Allow sorting category attributes

Allow sorting attributes in category settings.
Linked task: SALEOR-2234

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

Task linked: SALEOR-2234 Allow sorting category attributes


[BUG]

Bug Description

Steps to Reproduce

Expected Behavior

Actual Behavior

Screenshots

Device Information

Device Model:
Android Version:
App Version:

Additional Context

Error Log

Paste your logs here

Checklist

[ ] I have checked for similar issues
[ ] I am using the latest version of the app
[ ] I can consistently reproduce this issue
[ ] I have included all the required information above

Related Permissions

[x] Internet
[ ] Access Network State
[x] Install Packages
[x] Delete Packages
[x] Query Packages
[x] Notifications
[ ] Boot Completed

i agree


Add right click menu such as delete in F-Curve Editor (F-Curveエディタに削除といった右クリックのメニューの追加)

Add right click menu such as delete in F-Curve Editor
F-Curveエディタに削除といった右クリックのメニューの追加

Almost finished

Almost finished


Support Ember v5

Noticed that the ember try scenarios for beta and canary were failing -- this should fix it

I wanted to say this is still failing due to an outdated version of ember-qunit, but then I saw there was https://github.com/CrowdStrike/ember-headless-table/pull/148 already (made by the same author 😜), which covers both changes. I guess we can merge that instead?

@nicolechung and I went ahead and approved/merged https://github.com/CrowdStrike/ember-headless-table/pull/148 instead so closing this!


Add support for encoded characters in URLs

Thanks a lot @lionep. I'll add a test and release soon.


Object reference not set to an instance of an object.

Sometimes I am facing the following error:
** Message:
Object reference not set to an instance of an object.
-----------------------------------------------------------
** Source:
WVBrowser
-----------------------------------------------------------
** Stack Trace:
   at Aimco.WV2.WVScriptHost.Browser_DOMDocumentComplete(Object sender)
   at Aimco.WV2.WVBrowser.DOMDocumentCompleteEventHandler.Invoke(Object sender)
   at Aimco.WV2.WVBrowser.RaiseDOMEvent(String EventName)
   at Aimco.WV2.WVScriptHost._Closure$__47-0._Lambda$__0()
-----------------------------------------------------------

It's random, what's the reason?

@ukandrewc, Any feedback on this error?

What code do you have inside DOMDocumentComplete?

It still happening !!
Today I was browsing a site and when I clicked on Go Back button to move to the previous page, I got this error message.

If you can let me have a way to reproduce this, that would be good.
I've just spent 10 minutes navigating, going back, forward, stopping & refreshing without any issue.


Variable statistics plot report

Extension that plots mean, std, min, max and percentiles for given Variables (data, grad) and saves them as an image.
Example output image
TODO

[ ] Docs and PEP-8.

Example monitoring a Chain or Link
Average over all Variables in a model.
model = MLP()
write_trigger = (1, 'epoch')
extension = chainer.training.extensions.VariableStatisticsPlot(
    model,
    max_sample_size=1000,
    report_data=True,
    report_grad=True,
    trigger=write_trigger,
    file_name='stats.png')

collect_data_trigger = (1, 'iteration')
trainer.extend(extension,  trigger=collect_data_trigger)

Example monitoring a single Variable
Monitor a specific parameter.
model = MLP()
trainer.extend(chainer.training.extensions.VariableStatisticsPlot(model.fc1.W))

Use cases include quick debugging of you model, visually verifying parameter initializations, checking for exploding/vanishing gradients or data of Variables in general. This extension may slow down training if called too often but should be useful even when used conservatively. Also, it should be significantly faster when percentile is merged into CuPy https://github.com/cupy/cupy/pull/643.
This extension utilizes a fixed sized sample meaning that memory consumption/computational cost does not increase with training time.

Rebased on top of master.

Can you show me an example plot?

Thank you for the comments. I'll take a look. As for an example, here goes. https://drive.google.com/file/d/0B-p1cP56g6qOR0F1NVF3bmtwMFU/view

@unnonouno san, I went though your comments and answered. Could you please take another look? I also changed the API to allow users to specify which percentiles to plot.

The user might want to skip plotting percentiles completely (only plotting mean and std). Maybe that should be supported as well.

@unnonouno san, I changed the API to be a bit more flexible (thus allows the user to skip some computations in favor of not degrading training speed). The default behavior is unchanged. What do you think?
class VariableStatisticsPlot(extension.Extension):
    ..
   def __init__(self, targets, max_sample_size=1000,
                 report_data=True, report_grad=True,
                 plot_mean=True, plot_std=True, plot_percentile=True,
                 percentile_sigmas=(
                     0, 0.13, 2.28, 15.87, 50, 84.13, 97.72, 99.87, 100),
                 trigger=(1, 'epoch'), file_name='statistics.png',
                 figsize=None, marker=None, grid=True):

@unnonouno thank you for the additional comments. I fixed most of them could you take a look?
Regarding the error caused by arrays on different GPUs, do you have any ideas off your head how to tackle it? I think it really depends on how people use extension but we could either compute the statistics per Variable, or copy all data to one of the devices to do the computations. I am not sure which one is better. (The second is probably easier to implement)

Maybe the easier method is enough. Or add an argument to specify the behavior (but I feel it is enough to implement it after we get a request).

Actually, I think the current implementation works, as long as concatenate copies the arrays to the same/current device.

Fixed the docs also.


Fix typo in whats-new-windows-11-version-23h2.md

Sorry for the non-technical bikeshed - the docs are impeccable. Just doing this in the course of reading.
Description
Fix typo found on What's new in Windows 11, version 23H2.

Screenshot

Changes

Typo: manged -> managed

@tony thanks much for correcting this! I really messed up that sentance didn't I? 🤦♂


Remove SocialProfile extension?

The SocialProfile extension adds various social media-related features to a wiki, like avatars, friending, etc.:
https://www.mediawiki.org/wiki/Extension:SocialProfile
It's part of Canasta, though I was surprised to discover today that it still lacks an extension.json file, which of course means that cfLoadExtension() won't work on it:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/SocialProfile/+/refs/heads/master
As we've discussed about other extensions, we can either try to fix this extension up (presumably, adding an extension.json file would be enough) or remove it.
(I was worried, by the way, that SocialProfile not working means that the other SocialProfile-related extensions in Canasta (AJAXPoll, VoteNY, WikiForum) don't work either, but it looks like none of these are dependent on SocialProfile - they're just all in the same "family". And these all do have an extension.json file.)
I'm not sure which way I go on this, in part because I don't know how popular an extension SocialProfile is. It certainly seems useful, and well-established, but I'm not sure I know of any specific wikis that use it. I don't believe it's included in any other MediaWiki distributions or farms, for what it's worth - except for ShoutWiki, where it was developed, but my understanding is that ShoutWiki is kind of neglected at the moment. Perhaps the lack of an extension.json file indicates some bigger issue - I don't know.
Any thoughts?

Ooh... this is a tough one.
We have some wikis on MyWikis who use this. I would say that these wikis would cancel their service with us if they couldn't use this extension. I'm inclined to say that this extension is important enough that it checks off the popularity requirement.
However, the codebase is a different story. We have identified that it uses ancient code for its avatar and award image upload system (dating back to MediaWiki 1.10!) and it's apparently very messy to fix. Nobody has gotten around to it. My colleague contacted Jack Phoenix, who says it's a hairy issue to fix and they wouldn't be fixing it anytime soon.
I would hate to see this extension be removed, but its poor development support is cause for serious concern. I would vote for removal if a third person (someone other than Yaron and me) agrees.

That's good to know. Let me note that SocialProfile seems like an ideal example of the potential usefulness of a "Canasta Foundation" - a foundation that would pool resources to ensure that the necessary extensions and other utilities are maintained. SocialProfile has the right combination of being essential for some people and being poorly maintained. That doesn't really affect the current decision, though.

I think we should keep it. And I guess users can figure out how to include it using require_once(). My reasoning is that even though the code is outdated, it does mostly work, it's useful and it's a popular extension.
There is a Phab task for extension registration, with a patch waiting for merge.
To sweeten the deal :), if it stops being maintained WikiTeq will likely pick it up. That doesn't mean we'd improve the code or fix all of the bugs, but it means they won't get worse.

@tosfos - thanks for the response. Your first link is to WikiApiary, and that site usually times out for me but I was at one point able to view the page. SocialProfile is in use on around 200 wikis - which is maybe not hugely popular, but popular enough.
That Phabricator task you linked to is from December 2016, and the patch is from January 2021. So if the goal is to show that this task is in progress, you might have had the opposite effect. :) It seems like this is either a complex, hard-to-modify extension, or the people in charge of it are not that interested in maintaining it, or both. But basically, if you're willing to (and can) take over this extension, it seems like now would already be the time to do it...

I think for this particular patch, it's "both". But I'm not sure the extension is unmaintained right now. There is some action on commits. There are shortcomings, but as far as MediaWiki extensions go, it's not bad.

SocialProfile is still being maintained, but it is not undergoing active development/reworks, if that makes any sense.

@jeffw16 - I think you mean that the usual gang of maintainers are making sure that the extension stays up to date with MediaWiki, like they do with all extensions (they definitely do with mine, thankfully!), but that, beyond that, there's no attempt to improve the functionality.
So, now we have an extension with no extension.json file, because its authors lack the time and/or interest in adding it. This is both a problem on its own, and (in my opinion) a red flag about any future issues that could come up with the extension. That's why I say that, if there's a possibility of taking over this extension, the time for that has already come.

WikiTeq has its hands full with extension maintenance right now, especially with 1.39 around the corner. If the extension authors believe they're maintaining it, we're inclined to agree. Even if WikiTeq did pick up maintenance, I don't think we'd prioritize code improvement and resolving any bugs unless they're critical.

I can certainly understand a lack of development time. And maybe there is some maintenance going on; I don't know. All I know is that SocialProfile still lacks an extension.json file, and doesn't seem on track toward getting it. Given that, I think there's a strong case for removing SocialProfile from Canasta, and keeping it out until it has an extension.json file. As I said before, the lack of that file is both a problem in itself, and a flag that there may be other issues as well.

I don't have any objection to this, and we have experienced unusual bugs with the extension. On the other hand, the fact that we did originally include it and it is important where installed makes removing it not so consistent with our stability philosophy. @jeffw16 ?

I don't think it should be removed, but only because it is so important, not because it has good code or good maintenance. Maybe we can add a warning to it.

Well, MediaWiki 1.39 was released recently, which means that it's time to start getting ready to release our own new version of Canasta. SocialProfile still lacks an extension.json file, and doesn't seem any closer to getting it. One other interesting thing I discovered recently is that Canasta contains two large patches to SocialProfile:
https://github.com/CanastaWiki/Canasta/blob/master/_sources/patches/social-profile-REL1_35.44b4f89.diff
https://github.com/CanastaWiki/Canasta/blob/master/_sources/patches/SocialProfile-disable-fields.patch
The first one is just a security fix that was added to SocialProfile in 2021:
https://phabricator.wikimedia.org/rESPR58d2420c0f726cd469c638043ed66a4374b136f2
The second one, though, appears to be an entirely original patch to SocialProfile, created by @vedmaka for WikiTeq, that makes some pretty substantial changes to SocialProfile: it adds a new special page, Special:ManageFields; adds a new database table; and makes some other changes. So this patch would possibly have to be recreated, with the latest SocialProfile version - I don't know.
@tosfos - now I'm curious as to why you were so willing to get rid of this extension, given that WikiTeq created a patched, almost forked, version of it. Or do you no longer need this particular set of features? Or do you still need this alternate version, but now it can be placed "downstream" of Canasta?

We still need it, but we don't need it to be part of Canasta itself.
We really should try to get those patches merged, or at least put them into code review. Pinging @alexey.

Since there has been some sentiment in favor of keeping this extension (especially from @jeffw16), I think the best course of action for now is to keep this extension - with a warning on the website that wfLoadExtension() can't be used for SocialProfile, you have to use the old syntax. The patches for it should be removed, but that's really a separate issue. So, I'm closing this task.


Instead of emulating the whole parsing as stage 1 + stage 2, let us benchmark the real thing.

Amazingly, stage 2 alone can be slower than stage 1 and stage 2 together.
Look...
$ cd scripts/ruby
$ ruby kostya_large.rb
$ cd ..
$ cd ..
$ make parse
$ ./parse -n 10 scripts/1.json
number of iterations 10

scripts/1.json
==============
  1742429 blocks -  111515519 bytes - 15728645 structurals ( 14.1 %)
special blocks with: utf8         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals   1742430 (100.0 %) - 8+ structurals   1716436 ( 98.5 %) - 16+ structurals         0 (  0.0 %)
special block flips: utf8         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals         0 (  0.0 %) - 8+ structurals     51988 (  3.0 %) - 16+ structurals         0 (  0.0 %)

All Stages
|    Speed        :  44.6178 ns per block ( 99.92%) -   0.6972 ns per byte -   4.9428 ns per structural -    1.434 GB/s
|    Cycles       : 164.5315 per block    ( 99.92%) -   2.5708 per byte    -  18.2269 per structural    -    3.688 GHz est. frequency
|    Instructions : 503.0693 per block    (100.00%) -   7.8605 per byte    -  55.7304 per structural    -    3.058 per cycle
|    Misses       : 1523128 branch misses ( 99.76%) - 11916639 cache misses ( 99.96%) - 16328392.00 cache references
|- Stage 1
|    Speed        :  22.0270 ns per block ( 49.33%) -   0.3442 ns per byte -   2.4402 ns per structural -    2.906 GB/s
|    Cycles       :  55.4957 per block    ( 33.70%) -   0.8671 per byte    -   6.1478 per structural    -    2.519 GHz est. frequency
|    Instructions : 171.7575 per block    ( 34.14%) -   2.6837 per byte    -  19.0274 per structural    -    3.095 per cycle
|    Misses       :  273409 branch misses ( 17.91%) - 2838304 cache misses ( 23.81%) - 3834943.00 cache references
|- Stage 2
|    Speed        :  48.8195 ns per block (109.33%) -   0.7628 ns per byte -   5.4083 ns per structural -    1.311 GB/s
|    Cycles       : 129.9075 per block    ( 78.89%) -   2.0298 per byte    -  14.3912 per structural    -    2.661 GHz est. frequency
|    Instructions : 331.3379 per block    ( 65.86%) -   5.1772 per byte    -  36.7058 per structural    -    2.551 per cycle
|    Misses       : 1308343 branch misses ( 85.69%) - 4440152 cache misses ( 37.24%) - 7016519.00 cache references

A similar effect on AMD Rome:
$ ./parse -n 10 scripts/ruby/1.json
number of iterations 10

scripts/ruby/1.json
===================
  1742414 blocks -  111514524 bytes - 15728649 structurals ( 14.1 %)
special blocks with: utf8         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals   1742415 (100.0 %) - 8+ structurals   1716345 ( 98.5 %) - 16+ structurals         0 (  0.0 %)
special block flips: utf8         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals         0 (  0.0 %) - 8+ structurals     52139 (  3.0 %) - 16+ structurals         0 (  0.0 %)

All Stages
|    Speed        :  50.5433 ns per block ( 99.82%) -   0.7897 ns per byte -   5.5992 ns per structural -    1.266 GB/s
|    Cycles       : 171.1244 per block    ( 99.84%) -   2.6738 per byte    -  18.9571 per structural    -    3.386 GHz est. frequency
|    Instructions : 503.0836 per block    (100.00%) -   7.8607 per byte    -  55.7314 per structural    -    2.940 per cycle
|    Misses       : 1567348 branch misses ( 99.93%) - 0 cache misses (  -nan%) - 0.00 cache references
|- Stage 1
|    Speed        :  25.8704 ns per block ( 51.09%) -   0.4042 ns per byte -   2.8659 ns per structural -    2.474 GB/s
|    Cycles       :  63.6835 per block    ( 37.15%) -   0.9951 per byte    -   7.0548 per structural    -    2.462 GHz est. frequency
|    Instructions : 171.7688 per block    ( 34.14%) -   2.6839 per byte    -  19.0285 per structural    -    2.697 per cycle
|    Misses       :  292102 branch misses ( 18.62%) - 0 cache misses (  -nan%) - 0.00 cache references
|- Stage 2
|    Speed        :  48.1920 ns per block ( 95.18%) -   0.7530 ns per byte -   5.3387 ns per structural -    1.328 GB/s
|    Cycles       : 118.4666 per block    ( 69.12%) -   1.8510 per byte    -  13.1237 per structural    -    2.458 GHz est. frequency
|    Instructions : 331.3408 per block    ( 65.86%) -   5.1772 per byte    -  36.7058 per structural    -    2.797 per cycle
|    Misses       : 1372067 branch misses ( 87.48%) - 0 cache misses (  -nan%) - 0.00 cache references

This is insane. Processor lookahead just from running stage 1 right after stage 2 really accounts for 25% of the run performance? Or is this overhead from turning perf counters on/off somehow?
Instruction and branch count are basically identical, but on AMD Rome running the performance measurement code between stage 1 and stage 2 costs 2.5ms per file.

@lemire just out of curiosity, what happens if you run it without sudo--i.e. if you aren't measuring perf counters, just elapsed time? If the % difference drops, then that at least tells us this has to do with the measurement code ...

I wonder if a benchmark library like Celero or Google Benchmark would give us better results. Both support custom measurements, so instructions/branch miss measurement can still be measured.

just out of curiosity, what happens if you run it without sudo--i.e. if you aren't measuring perf counters, just elapsed time? If the % difference drops, then that at least tells us this has to do with the measurement code ...

No. It is not caused by the performance counters. I can disable them forcefully (commenting out the code) and it still does this.

I'm flabbergasted, again. I thought the processor only looked hundreds of instructions ahead, that shouldn't cover more than 1K of input!

I wonder if a benchmark library like Celero or Google Benchmark would give us better results. Both support custom measurements, so instructions/branch miss measurement can still be measured

I don't think it is a measurement issue. I think that the measures are correct. What we see are processor's frequencies fluctuating. I am not sure why.
Ultimately, once I disable the performance counters, this is just a timing (record the time before, record the time after) routine. It is not like Google benchmark will get different timings, magically.

I can make the issue happen on twitter.json:
$ ./parse -n 5 jsonexamples/twitter.json
number of iterations 5

jsonexamples/twitter.json
=========================
     9867 blocks -     631515 bytes - 55263 structurals (  8.8 %)
special blocks with: utf8      2284 ( 23.1 %) - 0 structurals      1287 ( 13.0 %) - 1+ structurals      8581 ( 87.0 %) - 8+ structurals      3272 ( 33.2 %) - 16+ structurals         0 (  0.0 %)
special block flips: utf8      1104 ( 11.2 %) - 0 structurals       940 (  9.5 %) - 1+ structurals       940 (  9.5 %) - 8+ structurals      2593 ( 26.3 %) - 16+ structurals         0 (  0.0 %)

All Stages
|    Speed        :  26.7297 ns per block ( 98.49%) -   0.4177 ns per byte -   4.7730 ns per structural -    2.394 GB/s
|    Cycles       :  98.6881 per block    ( 98.71%) -   1.5421 per byte    -  17.6222 per structural    -    3.692 GHz est. frequency
|    Instructions : 317.1882 per block    (100.00%) -   4.9564 per byte    -  56.6385 per structural    -    3.214 per cycle
|    Misses       :    2975 branch misses ( 86.35%) - 24 cache misses ( 15.40%) - 84050.00 cache references
|- Stage 1
|    Speed        :  12.7588 ns per block ( 47.01%) -   0.1994 ns per byte -   2.2783 ns per structural -    5.016 GB/s
|    Cycles       :  47.1235 per block    ( 47.13%) -   0.7363 per byte    -   8.4146 per structural    -    3.693 GHz est. frequency
|    Instructions : 164.5904 per block    ( 51.89%) -   2.5719 per byte    -  29.3900 per structural    -    3.493 per cycle
|    Misses       :    1347 branch misses ( 39.10%) - 0 cache misses (  0.00%) - 29172.00 cache references
|- Stage 2
|    Speed        :  14.0243 ns per block ( 51.67%) -   0.2191 ns per byte -   2.5042 ns per structural -    4.563 GB/s
|    Cycles       :  51.7933 per block    ( 51.80%) -   0.8093 per byte    -   9.2484 per structural    -    3.693 GHz est. frequency
|    Instructions : 152.6177 per block    ( 48.12%) -   2.3848 per byte    -  27.2521 per structural    -    2.947 per cycle
|    Misses       :    1688 branch misses ( 48.99%) - 8 cache misses (  5.13%) - 54720.00 cache references

Warning: The processor frequency fluctuates in an expected way!!!
Expect the overall speed not to match stage 1 and stage 2 speeds.
Range for stage 1 and stage2 : [2.734 GHz, 3.278 GHz], overall: 3.684 GHz

Yeah, if disabling the measurements doesn't help, I can't see how time measurement would.

twitter.json looks OK, honestly: stage 1 ns/block + stage 2 ns/block = total ns/block, as expected. Which is even weirder, because twitter.json is way smaller than the input file you're seeing weird results on. You'd expect a combined method to have less impact on larger files, not more. It must have to do with the contents of the file ;/
I wonder what happens if you have a file just as big as 1.json, but basically write [<twitter.json>,<twitter.json>,...] into the file. Let me see.
None of the theories I can think of match these results.

I am going to add a commit where you can bypass re-running both stages by -s allfast.
$ ./parse -s allfast -n 10 scripts/1.json
number of iterations 10

scripts/1.json
==============
  1742429 blocks -  111515519 bytes - 15728645 structurals ( 14.1 %)
special blocks with: utf8         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals   1742430 (100.0 %) - 8+ structurals   1716436 ( 98.5 %) - 16+ structurals         0 (  0.0 %)
special block flips: utf8         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals         0 (  0.0 %) - 8+ structurals     51988 (  3.0 %) - 16+ structurals         0 (  0.0 %)

All Stages
|    Speed        :  71.1007 ns per block ( 99.94%) -   1.1109 ns per byte -   7.8766 ns per structural -    0.900 GB/s
|    Cycles       : 186.0668 per block    ( 99.98%) -   2.9073 per byte    -  20.6126 per structural    -    2.617 GHz est. frequency
|    Instructions : 503.0954 per block    (100.00%) -   7.8609 per byte    -  55.7332 per structural    -    2.704 per cycle
|    Misses       : 1582507 branch misses ( 99.88%) - 7191046 cache misses (100.00%) - 10978603.00 cache references
|- Stage 1
|    Speed        :  22.0085 ns per block ( 30.93%) -   0.3439 ns per byte -   2.4381 ns per structural -    2.908 GB/s
|    Cycles       :  55.3466 per block    ( 29.74%) -   0.8648 per byte    -   6.1313 per structural    -    2.515 GHz est. frequency
|    Instructions : 171.7575 per block    ( 34.14%) -   2.6837 per byte    -  19.0274 per structural    -    3.103 per cycle
|    Misses       :  274979 branch misses ( 17.35%) - 2791130 cache misses ( 38.82%) - 3859498.00 cache references
|- Stage 2
|    Speed        :  49.0797 ns per block ( 68.99%) -   0.7669 ns per byte -   5.4371 ns per structural -    1.304 GB/s
|    Cycles       : 130.7321 per block    ( 70.24%) -   2.0427 per byte    -  14.4826 per structural    -    2.664 GHz est. frequency
|    Instructions : 331.3379 per block    ( 65.86%) -   5.1772 per byte    -  36.7058 per structural    -    2.534 per cycle
|    Misses       : 1308075 branch misses ( 82.56%) - 4400453 cache misses ( 61.20%) - 7082102.00 cache references
dlemire@skylake:~/CVS/github/simdjson$ ./parse -s all -n 10 scripts/1.json
number of iterations 10

scripts/1.json
==============
  1742429 blocks -  111515519 bytes - 15728645 structurals ( 14.1 %)
special blocks with: utf8         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals   1742430 (100.0 %) - 8+ structurals   1716436 ( 98.5 %) - 16+ structurals         0 (  0.0 %)
special block flips: utf8         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals         0 (  0.0 %) - 8+ structurals     51988 (  3.0 %) - 16+ structurals         0 (  0.0 %)

All Stages
|    Speed        :  44.7135 ns per block ( 99.96%) -   0.6986 ns per byte -   4.9534 ns per structural -    1.431 GB/s
|    Cycles       : 164.9093 per block    ( 99.98%) -   2.5767 per byte    -  18.2688 per structural    -    3.688 GHz est. frequency
|    Instructions : 503.0693 per block    (100.00%) -   7.8605 per byte    -  55.7304 per structural    -    3.051 per cycle
|    Misses       : 1526730 branch misses ( 99.90%) - 11868617 cache misses (100.06%) - 16264669.00 cache references
|- Stage 1
|    Speed        :  21.9594 ns per block ( 49.09%) -   0.3431 ns per byte -   2.4327 ns per structural -    2.914 GB/s
|    Cycles       :  55.3449 per block    ( 33.55%) -   0.8648 per byte    -   6.1311 per structural    -    2.520 GHz est. frequency
|    Instructions : 171.7575 per block    ( 34.14%) -   2.6837 per byte    -  19.0274 per structural    -    3.103 per cycle
|    Misses       :  274667 branch misses ( 17.97%) - 2801736 cache misses ( 23.62%) - 3788019.00 cache references
|- Stage 2
|    Speed        :  49.0300 ns per block (109.61%) -   0.7661 ns per byte -   5.4316 ns per structural -    1.305 GB/s
|    Cycles       : 130.7366 per block    ( 79.26%) -   2.0428 per byte    -  14.4831 per structural    -    2.666 GHz est. frequency
|    Instructions : 331.3379 per block    ( 65.86%) -   5.1772 per byte    -  36.7058 per structural    -    2.534 per cycle
|    Misses       : 1306615 branch misses ( 85.49%) - 4415244 cache misses ( 37.22%) - 6999656.00 cache references

Warning: The processor frequency fluctuates in an expected way!!!
Expect the overall speed not to match stage 1 and stage 2 speeds.
Range for stage 1 and stage 2 : [2.519 GHz, 2.666 GHz], overall: 3.688 GHz.

My commit is away...

Note above how large the speed difference is: 0.9 GB/s vs 1.4 GB/s.

twitter.json looks OK, honestly

Yeah. Something is off in my code.

Coming back to this soon. Something is off somewhere.

Note that the original code (in master) has this issue where the frequency fluctuate, so this PR is not the cause.

@lemire one quick question: why is the frequency reported in the Cycle line different from the one reported in the bottom line?

Oh, I bet the official # takes the best iteration's frequency and you're taking the mean, or something.

Cycle line different from the one reported in the bottom line?

I don't know yet.

Ok. Fixed by adding ".best" as you suggested.

This fixes the problem on twitter.json but leaves the issue on the large files.

"Google Benchmark" should be used, because:

Nobody wants to write the same lib (also G Benchmark has taken years to mature)
simdjson results are beyond any ones doubt
we use it for "testing" too, saving even more time

Using Google Benchmark saves a lot of man-years.

I have used Google Benchmark in the past. It is fine, but it won't help with the issue we are having here.

@jkeiser If you approve, I would merge this... Please note that I took into account your suggestion that we make full stage1-stage2 rerunning optional with the caveat that I actually made it the default, though the current behavior is just one flag away (-s fastall). My rationale is that there is a problem with the benchmarks and until we can resolve this (figure out why the processor's frequency sometimes tank), we are better off being extra careful.

Yep, I'm on board. I agree that running a combined run is the right default, even if it also runs them separately.

Yep, I'm on board. I agree that running a combined run is the right default, even if it also runs them separately.

Merging.

I have used Google Benchmark in the past. It is fine, but it won't help with the issue we are having here.

I think it is obvious I know that :)

I wasn't condescending. I was just commenting on the issue.

Of course, you were. NP.  Utilizing Google Benchmark for both testings and measurements seems to be a way to save a lot of man-years, improve the usefulness of measurements, and at the same time focus on pure simdjson developments.
In this particular thread, I can see that easily obtained measurement data will serve for faster outcomes of inevitable what-if scenarios.

@jkeiser I figured it out!!!
You can make the problem go away like so:
$ git diff
diff --git a/src/parsedjson.cpp b/src/parsedjson.cpp
index 79926b9..2ae521a 100644
--- a/src/parsedjson.cpp
+++ b/src/parsedjson.cpp
@@ -22,7 +22,7 @@ bool ParsedJson::allocate_capacity(size_t len, size_t max_depth) {
   byte_capacity = 0; // will only set it to len after allocations are a success
   n_structural_indexes = 0;
   uint32_t max_structures = ROUNDUP_N(len, 64) + 2 + 7;
-  structural_indexes.reset( new (std::nothrow) uint32_t[max_structures]);
+  structural_indexes.reset( new (std::nothrow) uint32_t[max_structures]{});

   // a pathological input like "[[[[..." would generate len tape elements, so
   // need a capacity of at least len + 1, but it is also possible to do
@@ -33,8 +33,8 @@ bool ParsedJson::allocate_capacity(size_t len, size_t max_depth) {
   // a document with only zero-length strings... could have len/3 string
   // and we would need len/3 * 5 bytes on the string buffer
   size_t local_string_capacity = ROUNDUP_N(5 * len / 3 + 32, 64);
-  string_buf.reset( new (std::nothrow) uint8_t[local_string_capacity]);
-  tape.reset(new (std::nothrow) uint64_t[local_tape_capacity]);
+  string_buf.reset( new (std::nothrow) uint8_t[local_string_capacity]{});
+  tape.reset(new (std::nothrow) uint64_t[local_tape_capacity]{});

So the processor is stalling because it has to allocate the pages.


Add DaskWorker to master (#452)

Backport of https://github.com/paris-saclay-cds/ramp-board/pull/452 to the master branch.
This worker type was used for an actual event with no major issues. The goal of having it in master is to reduce divergence between master and advanced branches, and avoid for instance that fixes to the aws worker inadvertently break the dask worker. Running DaskWorker tests (included in this PR) on master would prevent that.
This should have impact on other workers.

Hello @rth! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file ramp-database/ramp_database/testing.py:

Line 161:80: E501 line too long (97 > 79 characters)
Line 162:80: E501 line too long (89 > 79 characters)

OK, I'll take the responsibility of merging this. The original PR was reviewed by @albertcthomas in https://github.com/paris-saclay-cds/ramp-board/pull/452#pullrequestreview-523364899.
This should not affect existing workers, and I'll double check that this doesn't impact the public RAMP server. This accounts for a good amount of the diff from the advanced branch, and is a step forward for merging those branches together. The tiny decrease in coverage,

93.66% (-0.02%) compared to 68a5ec8

is explained by the few lines that cannot be tested without a remote dask cluster. The code coverage for the tests with a local dask cluster (done in CI) should be quite good otherwise, most of the tests from the conda worker are re-used. We have also used this dask worker for an actual event without much issues.

Good to merge for me, I trust you on this, thx @rth


Importing models doesn't work with Uris not in asset folder

[x ] Review the documentation: https://virocore.viromedia.com/
[x ] Search for existing issues: https://github.com/viromedia/virocore/issues
[x ] Use the latest ViroCore release: https://virocore.viromedia.com/docs/releases
[ x] Turn off Instant Run in Android Studio

Environment
Please provide the following information about your environment:

OS: Windows 8.1
Version: ViroCore 1.13
Device(s): Huawei p10 lite

Description
I am trying to load models with files not in assets folder. Problem seems similar to #244 but the proposed solution doesn't work for me. It says that I should use Uris with a 'file://' notation. I tried both file and content.
    public void chooseFile() {
        Intent intent = new Intent(Intent.ACTION_GET_CONTENT);
        intent.setType("*/*");
        intent.addCategory(Intent.CATEGORY_OPENABLE);
        try {
            startActivityForResult(
                    Intent.createChooser(intent, "Select a File to Upload"),
                    1);

        } catch (android.content.ActivityNotFoundException ex) {
            Toast.makeText(ViroActivity.getView().getContext(), "Please install a File Manager.",
                    Toast.LENGTH_SHORT).show();
        }
    }

    @Override
    public void onActivityResult(int requestCode, int resultCode, Intent data) {
        super.onActivityResult(requestCode, resultCode, data);
        final Uri uri = data.getData();

        Object3D model = new Object3D();
        File modelFile = new File("/storage/emulated/0/models/monkeyobj.obj");
        Uri fileUri = Uri.fromFile(modelFile);
        Log.i("modelLoading", fileUri.toString());
        Log.i("modelLoading", uri.toString());

        //fails with both uri and fileUri
        model.loadModel(ViroActivity.getView().getViroContext(), uri, Object3D.Type.OBJ, new AsyncObject3DListener() {
            public void onObject3DFailed(String error) {
                Log.w("modelLoading", "Failed to load the model");
            }
            public void onObject3DLoaded(Object3D object, Object3D.Type type){

            }
        });

The code above shows an Intent that lets me choose a file. After that I get the uri from data. fileUri is the one i manually construct with the path of a file. If I select the same file from the Intent I get these logs.
I/modelLoading: file:///storage/emulated/0/models/monkeyobj.obj
I/modelLoading: content://media/external/file/59863
W/Viro: No file found at URL [file:///storage/emulated/0/models/monkeyobj.obj], not copying to temporary file
W/modelLoading: Failed to load the model/external/file/59863

Do you have an extra / in your file path?

You are talking about fileUri.toString() I suppose. I have an extra one yes. You can see it on the second snippet.
file:///storage/emulated/0/models/monkeyobj.obj

Hey @toniuyt123, the above sounds more like an issue with saving / loading from the Android file system. Can you confirm that the created file actually exists at the uri location above, and that you have read/write access to it?
Instead of doing the above hack, I strongly recommend adhering to Android's recommendations of file access and storage. Do let us know if you are experiencing any issues even after then.

Sorry, but I am a little confused on how to use the link you provided. It shows how to save/open/delete files within the internal directory for my app or external directories. What I want is to be able to select any file and get it's Uri in such a way that I can use it in the loadModel function. So far I've been using the method provided here, also part of Android's dev guide.
Also I've confirmed that the file exists and I can read it using the Uri i get from Intent data.
As a side not, I tried changing the Intent from GET_CONTENT to OPEN_DOCUMENT but it didn't work. And it shouldn't be a problem with the model itself as  I've tried with ones I can load from assets.

Also I've confirmed that the file exists and I can read it using the Uri i get from Intent data
It looks like the uri returned from the intent is a "content type" - content://media/external/file/59863.

Thus, content uri doesn't necessarily represent the absolute file path of your 3d object on the device, and instead is handled by the content provided / resolver that you have used to persist the data.
As such, you'll need to resolve the data through content resolvers to a known local file location on the device. Looking at the link you've provided, you will have to probably see what resolvers Android's Storage Access Framework uses apply that here.
At the end of the day, the above doesn't sound like a Viro issue, but an Android issue with your application. Viro essentially needs a full uri / file path to the local file on your device, and it should work.

It turned out to be a problem with the permissions. I thought that everything is fine with them as I had declared them in the manifest file. What I did was enable storage access permissions from the app manager in settings and it worked with a "file:///" type uri.


feat: cyclical dialog tests

Ports relevant tests related to #3229 to ensure that cyclical components don't trigger stack overflows in a few specific scenarios.
Note: there is a single commit related to code formatting, I would suggest reviewing the first and third commits directly.
Fixes #3229

Glad to see all worked. Thanks @joshgummersall

Glad to see all worked. Thanks @joshgummersall

Pull Request Test Coverage Report for Build 516120796

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

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-dialogs/src/dialogSet.ts
1
94.03%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

Totals

Change from base Build 513626598:
0.6%

Covered Lines:
18069

Relevant Lines:
20364

💛  - Coveralls

Pull Request Test Coverage Report for Build 516120796

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

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-dialogs/src/dialogSet.ts
1
94.03%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

Totals

Change from base Build 513626598:
0.6%

Covered Lines:
18069

Relevant Lines:
20364

💛  - Coveralls


INTERNAL Error if types is not provided

Hi and thanks for sending the extension trough. I was curious and trying this out, but I bumped in this, and though of reporting it:
LOAD sheetreader;
FROM sheetreader('path/to/test.xlsx');

Returns for me:
INTERNAL Error: Failed to bind "sheetreader": Table function must return at least one column
This error signals an assertion failure within DuckDB. This usually occurs due to unexpected conditions or errors in the program's logic.
For more information, see https://duckdb.org/docs/dev/internal_errors

It seems that providing types is all it's needed to solve the problem:
LOAD sheetreader;
FROM sheetreader('path/to/test.xlsx', types=[BOOLEAN,VARCHAR]);

Unsure whether this needs actual solving or just forcing parameter to be provided.
File was generated like:
LOAD spatial;
COPY (SELECT 1337 as i, 'foobar' as f) TO '__TEST_DIR__/test.xlsx' WITH (FORMAT GDAL, DRIVER 'xlsx');

Hey @carlopi,
Thank you for the report.
I will look into this -- I think the issue is, that the normal logic for determining the column types needs at least two rows -- this heuristic is not used, when you provide the types.
I'll add a more graceful handling for these one row cases 👍


[hotfix][build] Remove Scala suffix from Hadoop1 shading project

It seems that the hadoop1 shaded artifact has a scala suffix, which is not needed anymore.

Duplicate of #2343?

True. Thank you, I'll close this one.


Resource temporarily unavailable - Timeout reading from the socket (Errno::EAGAIN)

My Gemfile:
gem 'rails', '3.1.1'
gem 'resque', :require => 'resque/server'
gem 'hiredis'
gem 'redis', :require => ["redis/connection/hiredis", "redis"]

I using daemon-spawn to start and stop the resque worker, It seems work fine, But the reque worker may sometimes exit with the error below uninterruptedly.(my redis server is running with a timeout 300.)

/myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis/client.rb:170:in `rescue in read': Resource temporarily unavailable - Timeout reading from the socket (Errno::EAGAIN)
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis/client.rb:161:in `read'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis/client.rb:46:in `block in call'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis/client.rb:142:in `block (2 levels) in process'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis/client.rb:250:in `ensure_connected'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis/client.rb:137:in `block in process'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis/client.rb:206:in `logging'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis/client.rb:136:in `process'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis/client.rb:46:in `call'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis.rb:414:in `block in lpop'
        from /usr/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-2.2.2/lib/redis.rb:413:in `lpop'
        from /myapp/shared/bundle/ruby/1.9.1/gems/redis-namespace-1.0.3/lib/redis/namespace.rb:213:in `method_missing'
        from /myapp/shared/bundle/ruby/1.9.1/gems/resque-1.19.0/lib/resque.rb:158:in `pop'
        from /myapp/shared/bundle/ruby/1.9.1/gems/resque-1.19.0/lib/resque/job.rb:97:in `reserve'
        from /myapp/shared/bundle/ruby/1.9.1/gems/resque-1.19.0/lib/resque/worker.rb:184:in `block in reserve'
        from /myapp/shared/bundle/ruby/1.9.1/gems/resque-1.19.0/lib/resque/worker.rb:182:in `each'
        from /myapp/shared/bundle/ruby/1.9.1/gems/resque-1.19.0/lib/resque/worker.rb:182:in `reserve'
        from /myapp/shared/bundle/ruby/1.9.1/gems/resque-1.19.0/lib/resque/worker.rb:119:in `block in work'
        from /myapp/shared/bundle/ruby/1.9.1/gems/resque-1.19.0/lib/resque/worker.rb:116:in `loop'
        from /myapp/shared/bundle/ruby/1.9.1/gems/resque-1.19.0/lib/resque/worker.rb:116:in `work'
        from script/resque:13:in `start'
        from /myapp/shared/bundle/ruby/1.9.1/gems/daemon-spawn-0.4.2/lib/daemon_spawn.rb:51:in `block in start'
        from /myapp/shared/bundle/ruby/1.9.1/gems/daemon-spawn-0.4.2/lib/daemon_spawn.rb:38:in `fork'
        from /myapp/shared/bundle/ruby/1.9.1/gems/daemon-spawn-0.4.2/lib/daemon_spawn.rb:38:in `start'
        from /myapp/shared/bundle/ruby/1.9.1/gems/daemon-spawn-0.4.2/lib/daemon_spawn.rb:181:in `block in start'
        from /myapp/shared/bundle/ruby/1.9.1/gems/daemon-spawn-0.4.2/lib/daemon_spawn.rb:181:in `map'
        from /myapp/shared/bundle/ruby/1.9.1/gems/daemon-spawn-0.4.2/lib/daemon_spawn.rb:181:in `start'
        from /myapp/shared/bundle/ruby/1.9.1/gems/daemon-spawn-0.4.2/lib/daemon_spawn.rb:165:in `spawn!'
        from script/resque:25:in `'

How can I solve the problem?
Thanks

Can you reproduce without using daemon-spawn?

@djanowski It occurs uninterruptedly in a rails application, the time interval is about 3~4 hours. So it is hard to reproduce. you can have a loot at the log file of the resque worker.

@zhengquan Which version of hiredis-rb are you using? Version 0.4.3 and up contain a fix for a known problem with socket timeouts.

@pietern Thanks,my hiredis-rb version is 0.4.1.It seems hiredis-rb fixed this bug in the 0.4.3.  changelog

Great!


Change translation of "Betaal"

Please select which platform you are using:-
Web Version
Feedback Type
Enhancements
What went wrong?
Suggested improvement of translating 'betaal' as vampire over demon, as this adds an extra layer of interpretation, in that manmukhs resemble betaal because they require external things to sustain themselves.
What should have happened instead?
How can the issue be recreated by our team?
Which web browser are using?
Operating System
Name
Balhar Singh

@tarunsingh5 can you take action on this in cp?

@pdvsingh what did you find here?


feat: Add a configuration param to set the maximum attempts before the conversation ends if it doesn't understand

I do not need this anymore, I implement it manually by setting silenceDetection: false.


Bumping Kafka Operator provisioning support to Kafka 3.6.0/AMQ Stream…

…s 2.6.z, Strinzi 0.38.0
Description

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change
[ ] Chore (non-breaking change which doesn't affect codebase;
test, version modification, documentation, etc.)

Checklist

[ ] Code contributed by me aligns with current project license: Apache 2.0
[ ] Pull Request contains a description of the changes
[ ] Pull Request does not include fixes for multiple issues/topics
[ ] Code is self-descriptive and/or documented
[ ] I have implemented unit tests to cover my changes
[ ] I tested my code in OpenShift

/retest


Scheduled publishing does not work for page aliases

Issue Summary
When an alias is created of a draft page it doesn't inherit the publication schedule of the page it's aliasing. In practice this means they are published before the actual page they are aliasing.
Steps to Reproduce

Create a page (save draft)
Copy the draft page as an alias
Set a schedule on the original page and publish it
The alias is now published (live)
Try to set a schedule on the alias (doesn't seem possible)

While reproducing I also encountered the following issue:

Create a page (save draft)
Set a schedule and publish the page
Copy the page as an alias
Try to edit the alias

This raises an error: 'NoneType' object has no attribute 'pk'
Any other relevant information

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: (yes / no)
In our setup aliases are created automatically (as placeholders for translations). This makes it easy to accidentally publish a page that shouldn't be published yet.

Technical details
Python 3.11.3

anyascii==0.3.2
asgiref==3.7.2
beautifulsoup4==4.11.2
certifi==2023.11.17
charset-normalizer==3.3.2
defusedxml==0.7.1
Django==5.0
django-filter==23.5
django-modelcluster==6.1
django-permissionedforms==0.1
django-taggit==4.0.0
django-treebeard==4.7
djangorestframework==3.14.0
draftjs-exporter==2.1.7
et-xmlfile==1.1.0
filetype==1.2.0
html5lib==1.1
idna==3.6
l18n==2021.3
openpyxl==3.1.2
Pillow==10.1.0
pillow-heif==0.14.0
pytz==2023.3.post1
requests==2.31.0
six==1.16.0
soupsieve==2.5
sqlparse==0.4.4
telepath==0.3.1
urllib3==2.1.0
wagtail==5.2.2
webencodings==0.5.1
Willow==1.6.3

Maybe related:

https://github.com/wagtail/wagtail/issues/10386
https://github.com/wagtail/wagtail/issues/6920


application hung after this line php -S <IP_ADDRESS>:8080 -t . index.php

Hi Brian,
I'm trying to install this but when I ran command "> composer server:start", it just returns this line "> php -S <IP_ADDRESS>:8080 -t . index.php" and then froze. Nothing happens. Did I miss anything?
Centos 7
Apache 2.4.10
PHP 7.1.16
Thanks,

Hi @lnguyen12
When you started the server with composer server:start from within one of the samples in the repo, did you try to go to <IP_ADDRESS>:8080 in your web browser?  If you did, what shows there?
-Brian

I got this below message
This page isn’t working
drupal8.sjlibrary.org http://drupal8.sjlibrary.org didn’t send any data.
ERR_EMPTY_RESPONSE
Thanks,
Lyna
On Mon, Apr 23, 2018 at 5:56 AM, Brian Retterer<EMAIL_ADDRESS>wrote:

Hi @lnguyen12 https://github.com/lnguyen12
When you started the server with composer server:start from within one of
the samples in the repo, did you try to go to <IP_ADDRESS>:8080 in your web
browser? If you did, what shows there?
-Brian
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/okta/samples-php/issues/4#issuecomment-383565381, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AgFYIRqafO9Zy2K6S2dmu4Y_j8T9zMmUks5trc-TgaJpZM4Td1og
.

It appears that there may be something not right with your local configuration.  The samples here would not produce any error messages regarding anything in drupal.  Make sure that you have no other servers running.
Thanks,
Lyna
On Mon, Apr 23, 2018 at 6:37 PM, Brian Retterer<EMAIL_ADDRESS>wrote:

It appears that there may be something not right with your local
configuration. The samples here would not produce any error messages
regarding anything in drupal. Make sure that you have no other servers
running. You can run the following command to kill anything that is
listening on port 8080 and 8000
kill $(lsof -t -i:8080; lsof -t -i:8000)
Give that a try and get back to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/okta/samples-php/issues/4#issuecomment-383775066, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AgFYIREsXuE378W26WK1i77GiljrghMHks5troHxgaJpZM4Td1og
.

here it is. I also changed <IP_ADDRESS> to our hostname in composer.json file,
but it still doesn't work.
Thanks,
Lyna
On Tue, Apr 24, 2018 at 12:20 PM, Brian Retterer<EMAIL_ADDRESS>wrote:

I am still stuck on why it is reporting drupal8 can you send a screenshot
of your full web browser when trying to visit the sample. If you can also
include a screen shot of your terminal after issuing the command, that may
help out.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/okta/samples-php/issues/4#issuecomment-384049318, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AgFYIdh9RRGtCkry666KkqrgtGK7Ju_cks5tr3sFgaJpZM4Td1og
.

Lyna,
Could you please send me your apache and php logs from the timeframe that you are experiencing this?

Hi Brian,
the apache and php doesn't generate any errors when this is run.
Thanks,
Lyna
On Wed, Apr 25, 2018 at 1:28 PM, Brian Retterer<EMAIL_ADDRESS>wrote:

Lyna,
Could you please send me your apache and php logs from the timeframe that
you are experiencing this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/okta/samples-php/issues/4#issuecomment-384423441, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AgFYIWs8WSZowvL-JGbi1FyxlFWviI05ks5tsNx8gaJpZM4Td1og
.


add human readable total time

[X] I've read the CONTRIBUTING guidelines

Not sure this requires change.md file, but let me know if it's needed
Motivation:
for big multimodule projects sbt often report Total time: 123456 s, ...
Which is not human friendly. So this PR adds some human friendly duration. Please see spec for examples

@eed3si9n not sure why, but headerCreate and headerCheck` do nothing
I've added the header manually, hopefully it's okay

looks like travis-ci failure is unrelated Error: Could not retrieve sbt 1.1.6: missing sbt.xMain
@eed3si9n do I need to do anything else here? thanks

thanks!


Dismissible widget would somehow cause keyboard close instantly after pop up

Steps to Reproduce

run app
open drawer click Subscription
click FAB add sub (need a little bit modify of code to bypass sub valid auth)
success, there'll be two TextFiled widget, Click either of those two, will pop up keyboard, but disappear instantly
remove Dismissible widget everything will be fine
source code

New way

run app
open drawer click Subscription
click FAB
click first TextField
source code 2

Logs

no special logs

[✓] Flutter (Channel stable, v1.9.1+hotfix.2, on Linux, locale en_US.UTF-8)
    • Flutter version 1.9.1+hotfix.2 at /home/jason/flutter
    • Framework revision 2d2a1ffec9 (10 days ago), 2019-09-06 18:39:49 -0700
    • Engine revision b863200c37
    • Dart version 2.5.0

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /home/jason/Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-29, build-tools 29.0.2
    • ANDROID_HOME = /home/jason/Android/Sdk
    • Java binary at: /usr/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_222-b10)
    • All Android licenses accepted.

[!] Android Studio (not installed)
    • Android Studio not found; download from
      https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/setup/#android-setup for detailed
      instructions).

[✓] IntelliJ IDEA Ultimate Edition (version 2019.3)
    • IntelliJ at
      /home/jason/.local/share/JetBrains/Toolbox/apps/IDEA-U/ch-0/193.2956.37
    • Flutter plugin version 39.0.5
    • Dart plugin version 193.2956.37

[✓] VS Code (version 1.38.1)
    • VS Code at /usr/share/code
    • Flutter extension version 3.4.1

Its happen even you wrap the webview around expanded /flexible widget.

Its happen even you wrap the webview around expanded /flexible widget.

so, It's perhaps not the Dismissible's problem

I found that every click(or TextField focused) will cause build method in Dismissible widget be called twice, first call keyboard pop up, second call keyboard will disappear.
normally click(or TextField focused) will not trigger widget to redraw even a single time

Had same problem when InputText was in Dismissible, but I fixed it after change Dismissible(key: UniqueKey()) to Dismissible(key: Key('some_key'))

Hi @unifyproxy
Not able reproduce this issue on latest dev channel

Code Sample
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Material App',
      home: Scaffold(
        appBar: AppBar(
          title: Text('Material App Bar'),
        ),
        body: Dismissible(
          key: UniqueKey(),
          onDismissed: (DismissDirection dismissDirection) {},
          child: Padding(
            padding: const EdgeInsets.all(18.0),
            child: Column(
              children: <Widget>[
                Padding(
                  padding: const EdgeInsets.all(8.0),
                  child: Row(
                    children: <Widget>[
                      SizedBox(width: 50, child: Text("Name: ")),
                      Expanded(
                        child: TextField(),
                      ),
                      Checkbox(
                        value: true,
                        onChanged: (bool checked) {},
                      )
                    ],
                  ),
                ),
                Padding(
                  padding: const EdgeInsets.all(8.0),
                  child: Row(
                    children: <Widget>[
                      SizedBox(width: 50, child: Text("URL: ")),
                      Expanded(
                        child: TextField(),
                      ),
                      IconButton(
                        icon: Icon(Icons.save),
                        onPressed: () async {},
                      ),
                    ],
                  ),
                ),
              ],
            ),
          ),
        ),
      ),
    );
  }
}

flutter doctor -v
[✓] Flutter (Channel dev, 1.18.0-10.0.pre, on Mac OS X 10.15.4 19E287, locale
    en-GB)
    • Flutter version 1.18.0-10.0.pre at /Users/tahatesser/Code/flutter_dev
    • Framework revision 9b7b9d795e (18 hours ago), 2020-05-05 12:09:51 -0700
    • Engine revision 33d2367950
    • Dart version 2.9.0 (build 2.9.0-5.0.dev 9c94f08410)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/tahatesser/Code/SDK
    • Platform android-29, build-tools 29.0.3
    • ANDROID_HOME = /Users/tahatesser/Code/SDK
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.4.1, Build version 11E503a
    • CocoaPods version 1.9.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 3.6)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 45.1.1
    • Dart plugin version 192.7761
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)

[✓] VS Code (version 1.44.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.10.1

[✓] Connected device (4 available)
    • SM M305F   • 32003c30dc19668f • android-arm64  • Android 10 (API 29)
    • macOS      • macOS            • darwin-x64     • Mac OS X 10.15.4 19E287
    • Web Server • web-server       • web-javascript • Flutter Tools
    • Chrome     • chrome           • web-javascript • Google Chrome
      81.0.4044.138

• No issues found!

If you're still experiencing this problem, please create a new issue and provide the information
required in the template.
Thank you


CUPS 2.1.3-4 driver for Brother HL2240 fails; Brother site has correct driver

This is not software supplied with CUPS...


[Feature request] Universal support.

As a AngularCli added support for Universal app angular-ngrx-material-starter should have option to be build with support for Angular Universal to achieve better seo.

That's definitely something I will look into in the future!

Angular Cli 1.3.0 supports SSR but it's still unfinished and doesn't support lazy routes so I'll will wait until that is supported. Check the SRR guide from Angular Cli.

As commented on the related PR

hi


Look for both AddressLen and AddressLength

Thanks for the additional check. I didn't know about it.
Cheers


don't update symbols on editor switching

fixes https://github.com/JunoLab/Juno.jl/issues/407
ref: https://github.com/JunoLab/Atom.jl/pull/205

good to go.


Keep main stable and PRs small

It seems to me that we have two goals which are currently at odds with each other:

Small PRs
Stable main branch

It is often the case that a change necessitates additional changes for it to be fully stable. For example, adding the Created timestamp to a new Function required that we have Function migrations to support old versions, to refactor Function initialization to allow for tests to work without the old implementation of .Initialized(), and for the inclusion of the required --language argument  to be logically consistent. This is a lot of change for one PR! But by breaking it into smaller pieces and merging them one at a time, the main branch is unstable (at least for a short time).
We can either ignore this issue and say that the only version of func which is expected to be stable is the last tagged release, or we can attempt to keep the main branch stable. I lean toward the latter, because if we assume main is unstable, we can not hotfix bugs and request users "update to the latest main to get the fix"... because main may be unstable.
Alternately, we can discard our goal of having PRs be small, targeted changes and instead expect them to include all changes necessary to make the catalyzing change stable. I'd prefer not to do this, however, because I agree that smaller PRs are best, for reasons discussed ad nauseam elsewhere.
Or finally, we can do a hybrid approach where we do assume main is unstable, but streamline the release process such that creating point releases is quite simple.  In the event of a bugfix, we would have to of course verify that main is not unstable and then issue a point release.  This is perhaps easiest, but it does present the problem that larger PRs (like the initial example) could perhaps need to be reverted in the event of a critical bug where then "stabilizing" PRs are still WIP.
The solution I would propose to these conflicting goals is to institute the concept of an "unstable" branch which includes changes from recent PRs which may not be entirely completed (read: stable). The library-level equivalent to integration testing, this also allows PRs to see if they also function along side any related PRs and PRs from development toward unrelated goals. This is often called the develop branch. PRs are merged to this branch first, and when the branch is proved stable, it is merged to main and tagged with a release version in the same commit. I believe this discussion is apropos considering our release process is currently a topic of discussion.
Of course this solution is not without its challenges. Chief among these is the tendency for the develop branch to grow without ever being merged to main (released). This should be addressed at a process level. Put simply: An issue is not completed until the fix is in main.
I would love to hear what others think about this situation, and especially if there are better ideas about how it can be solved.

the trunk-based/main approach isn't without downsides but has worked well elsewhere

Works for me; and barring other opinions is what I'll stick with supporting then.  Thanks for the input.

@julz @lkingland yes please.. let's use trunk-based development + small PRs which add enough unit and integration testing to keep main stable.


Area2D nodes do not register mouse events on the top or left edges

Godot version: 3.1 BETA 3 (also present in BETA 2)

OS/device including version: Windows 10

Issue description:
When arranging Area2D nodes into a perfect grid, there are sometimes gaps in coverage where two nodes meet. Clicking along certain edges sometimes results in a spot that doesn't trigger any events on either node. I would expect one of the nodes to detect the click since there is no gap between them.

Steps to reproduce:
Create a grid of Area2D nodes and click along the edges of nodes. This doesn't happen along every edge (although that may be due to mouse/DPI alignment), so it may take a moment to find one, but once you have, you'll notice that it runs the length (or width) of the grid.
Minimal reproduction project:

I've added a demo project that has this issue. The green buttons on the right are TextureButtons which work as expected. The blue buttons on the left are Area2D nodes that have dead spots. Using this project I have found 4 gaps at the following edges:
Vertical gaps:
X = 114 and X = 306
Horizontal gaps:
Y = 114 and Y= 306
I suspect there may be more edges that experience this, but due to mouse/DPI settings I cannot perfectly align the cursor with other edges. Although this seems like a rare issue, it pops up quite a lot when quickly clicking on buttons and you accidentally hit a boundary resulting in nothing happening.
Area2DTest.zip
If you need any other information, please let me know. Thanks!

I don't know if it is relevant, but it did occur to me that the positions I'm finding this bug in are the final pixel of an area, not the first of the next area.
It makes me wonder if this may be down to how the areas are calculated and are not inclusive of the final pixel. I don't know how Area2D works under the hood, but it has the hallmarks of a < where it needs to be <=? Or perhaps rounding problems if there are floats involved at some level.
I don't I know C++,  but I may dig around myself to try and see if anything obvious jumps out at me.

I tried replacing the RectangleShape2D with ConvexPolygonShape2D in the test project, and the dead spots have disappeared. However, now clicks along boundaries activate BOTH areas. This would seem to indicate some kind of overlap I guess?
For reference my polygon points are:
-32, -32
32, -32
32, 32
-32, 32

The dead spots also occur using the CircleShape2D with a radius of 32.

Just updated to Godot 3.1 BETA 4 and the issue is still present.
Also, I created a different type of test project that collides two of the buttons. The buttons seem to perfectly detect a collision with each other, just not with the mouse input. Maybe these are calculated differently? I have also tested overlapping Area2D nodes to check if  anything strange was happening there, but it seems fine, with both Area2D nodes registering the click.

Exploring the events more, it seems that mouse movement events are also ignored. This could be a deeper problem that goes beyond Area2D.

Issue still present in Godot 3.1 BETA 5.


Cannot run inference on multiple boxes for TensorRT Efficient VIT SAM

Hello, Thank you for the awesome work.
I was trying to get inference from the tensorrt SAM deployment when there are multiple bounding boxes in the prompt. However, I haven't been able to get this to work. Trying one sample with number of boxes=2 results in thee following error:
[03/05/2024-00:13:13] [TRT] [E] 3: [executionContext.cpp::validateInputBindings::2082] Error Code 3: API Usage Error (Parameter check failed at: runtime/api/executionContext.cpp::validateInputBindings::2082, condition: profileMaxDims.d[i] >= dimensions.d[i]. Supplied binding dimension [1,4,2] for bindings[1] exceed min ~ max range at index 1, maximum dimension in profile is 2, minimum dimension in profile is 1, but supplied dimension is 4.
)
[03/05/2024-00:13:13] [TRT] [E] 3: [executionContext.cpp::validateInputBindings::2082] Error Code 3: API Usage Error (Parameter check failed at: runtime/api/executionContext.cpp::validateInputBindings::2082, condition: profileMaxDims.d[i] >= dimensions.d[i]. Supplied binding dimension [1,4] for bindings[2] exceed min ~ max range at index 1, maximum dimension in profile is 2, minimum dimension in profile is 1, but supplied dimension is 4.
)
[03/05/2024-00:13:13] [TRT] [E] 3: [executionContext.cpp::resolveSlots::2791] Error Code 3: API Usage Error (Parameter check failed at: runtime/api/executionContext.cpp::resolveSlots::2791, condition: allInputDimensionsSpecified(routine)
)
[03/05/2024-00:13:13] [TRT] [E] 3: [executionContext.cpp::resolveSlots::2791] Error Code 3: API Usage Error (Parameter check failed at: runtime/api/executionContext.cpp::resolveSlots::2791, condition: allInputDimensionsSpecified(routine)
)
[03/05/2024-00:13:13] [TRT] [E] 3: [executionContext.cpp::resolveSlots::2791] Error Code 3: API Usage Error (Parameter check failed at: runtime/api/executionContext.cpp::resolveSlots::2791, condition: allInputDimensionsSpecified(routine)
)
[03/05/2024-00:13:13] [TRT] [E] 3: [executionContext.cpp::resolveSlots::2791] Error Code 3: API Usage Error (Parameter check failed at: runtime/api/executionContext.cpp::resolveSlots::2791, condition: allInputDimensionsSpecified(routine)
)
Traceback (most recent call last):
  File "/home/ubuntu/efficientvit/deployment/sam/tensorrt/inference.py", line 244, in <module>
    low_res_masks, _ = trt_decoder.infer(inputs)
  File "/home/ubuntu/efficientvit/deployment/sam/tensorrt/inferencer.py", line 303, in infer
    self.numpy_array[idx][:actual_batch_size] = inp.reshape(actual_batch_size, -1)
ValueError: could not broadcast input array from shape (2,4) into shape (1,8)

I am passing the bounding boxes as a string list in the following format
--boxes "[[127, 219, 592, 736], [235, 6, 431, 115]]"

Hi, I faced the same problem few days ago, and I solved it.
Basically the original Decoder input binding could not match for multiple boxes.
Here was how I did:
Step 1. Find the inferencer.py file
.../efficientvit/deployment/sam/tensorrt/inferencer.py

Step 2. Modify the binding code in SAMDecoderInferencer class
# Original code:
# Allocate memory for multiple usage [e.g. multiple batch inference]
self._input_shape = []
self.context = self.engine.create_execution_context()
for binding in range(self.engine.num_bindings):
    # set binding_shape for dynamic input
    if self.engine.binding_is_input(binding):
        _input_shape = list(self.engine.get_binding_shape(binding)[1:])
        if binding != 0:
            _input_shape[0] = num
        self._input_shape.append(_input_shape)
        self.context.set_binding_shape(binding, [batch_size] + _input_shape)

To:
# Modified code
# Allocate memory for multiple usage [e.g. multiple batch inference]
self._input_shape = []
self.context = self.engine.create_execution_context()
for binding in range(self.engine.num_bindings):
    # set binding_shape for dynamic input
    if self.engine.binding_is_input(binding):
        _input_shape = list(self.engine.get_binding_shape(binding)[1:])
        if binding != 0:
            _input_shape = list(self.engine.get_binding_shape(binding))
            _input_shape[0] = num
            _input_shape[1] = 2
        self._input_shape.append(_input_shape)
        if binding == 0:
            self.context.set_binding_shape(binding, [batch_size] + _input_shape)
        else:
            self.context.set_binding_shape(binding, _input_shape)

Step 3. Modify actual_batch_size in infer function (same in SAMDecoderInferencer class)
# Original code:
for idx, inp in enumerate(inputs):
    actual_batch_size = len(inp)
    self.numpy_array[idx][:actual_batch_size] = inp.reshape(actual_batch_size, -1)
    np.copyto(self.inputs[idx].host, self.numpy_array[idx].ravel())

To:
# Original code:
for idx, inp in enumerate(inputs):
    aactual_batch_size = 1
    self.numpy_array[idx][:actual_batch_size] = inp.reshape(actual_batch_size, -1)
    np.copyto(self.inputs[idx].host, self.numpy_array[idx].ravel())

Finally, I think this will be ok for running multiple boxes.

Hi @aniket03 and @asd841018,
Thank you for raising this issue and trying to solve it. I have made the necessary updates to the code to address the issue. You can try it out whether it works for you now. Should you have any further questions, please don't hesitate to reach out. Thank you!
Best,
Zhuoyang


Mod Patches

More Furniture
End Table (lamp) - Replace 5 steel with 5 copper
Royal End Table (lamp) - Replace 5 steel with 5 copper
RIMkea
BOLTASK Lamp - Replace 5 stuff with 5 copper
SHAINBRAIT Lamps - Replace 5 steel with 5 copper
Vegetable Garden
Outdoor Light - Replace 5-10 steel with 5-10 copper
Lastly, Vegetable Garden's new sun lamps pose a pricing issue with regards to quartz.. it adds small and mini sun lamps. Having them all take 2 quarts would be a bit of a ripoff. Perhaps get rid of the quartz cost on the normal sun lamp and have the costs be like this.
Sun Lamp - 12 steel, 12 copper
Small Sun Lamp - 9 steel, 9 copper
Mini Sun Lamp - 6 steel, 6 copper
Has to be divisible by 3 and mini has to be half the cost of the full size, since mini is half the coverage.

Edit: Apparently Vegetable Garden has 'heated sun lamps' as well available through research. Not sure how to price these, here's the info on those:
<ThingDef ParentName="BuildingBase">
    <defName>HeatedSunLamp</defName>
    heated sun lamp
        <thingClass>VGDrinks.Building_SunLampHeatController</thingClass>
    <tickerType>Rare</tickerType>
    <category>Building</category>
    <graphicData>
      <texPath>Things/Building/HeatedSunLamp</texPath>
      <graphicClass>Graphic_Single</graphicClass>
      <shadowData>
        <volume>(0.2, 0.4, 0.2)</volume>
        <offset>(0,0,-0.1)</offset>
      </shadowData>
      <damageData>
        <rect>(0.2,0.2,0.6,0.6)</rect>
      </damageData>
    </graphicData>
    <altitudeLayer>Building</altitudeLayer>
    <passability>PassThroughOnly</passability>
    <statBases>
      <MaxHitPoints>50</MaxHitPoints>
      <WorkToBuild>330</WorkToBuild>
      <Flammability>1.0</Flammability>
    </statBases>
    <selectable>true</selectable>
    <description>Lights an area brightly enough to grow crops. Also is a larger heater that will keep your room warm.</description>
    <costList>
      <Steel>130</Steel>
      <Component>1</Component>
    </costList>
    <soundImpactDefault>BulletImpactMetal</soundImpactDefault>
    <leaveResourcesWhenKilled>false</leaveResourcesWhenKilled>
    <comps>

        <overlightRadius>7.0</overlightRadius>
        <glowRadius>14</glowRadius>
        <glowColor>(370,370,370,0)</glowColor>

        <compClass>CompPowerTrader</compClass>
        <startElectricalFires>true</startElectricalFires>
        <basePowerConsumption>1300</basePowerConsumption>

      <energyPerSecond>40</energyPerSecond>

    </comps>

    <specialDisplayRadius>5.8</specialDisplayRadius>
    <designationCategory>GardenTools</designationCategory>
    <rotatable>false</rotatable>
    <researchPrerequisites>

HeatedSunlamps

    </researchPrerequisites>
  </ThingDef>

<ThingDef ParentName="BuildingBase">
		<defName>HeatedSmallSunLamp</defName>
		small heated sun lamp
        <thingClass>VGDrinks.Building_SunLampHeatController</thingClass>
    <tickerType>Rare</tickerType>
		<category>Building</category>

		<graphicData>
      <texPath>Things/Building/HeatedSunSmall</texPath>
      <graphicClass>Graphic_Single</graphicClass>
      <drawSize>(1,1)</drawSize>
       <shadowData>
        <volume>(0.2, 0.4, 0.2)</volume>
        <offset>(0,0,-0.1)</offset>
      </shadowData>
      <damageData>
        <rect>(0.2,0.2,0.6,0.6)</rect>
      </damageData>
   </graphicData>
		<altitudeLayer>Building</altitudeLayer>
		<passability>PassThroughOnly</passability>
		<statBases>
			<MaxHitPoints>40</MaxHitPoints>
			<WorkToBuild>220</WorkToBuild>
			<Flammability>1.0</Flammability>
		</statBases>
		<selectable>true</selectable>
		<description>Lights an area brightly enough to grow crops. Also acts as a medium sized heater.</description>
		<size>(1,1)</size>
		<costList>
			<Steel>120</Steel>
 		     <Component>1</Component>
		</costList>
		<soundImpactDefault>BulletImpactMetal</soundImpactDefault>
		<leaveResourcesWhenKilled>false</leaveResourcesWhenKilled>
    <comps>

        <overlightRadius>7.0</overlightRadius>
        <glowRadius>5.5</glowRadius>
        <glowColor>(370,370,370,0)</glowColor>

        <compClass>CompPowerTrader</compClass>
        <startElectricalFires>true</startElectricalFires>
        <basePowerConsumption>1050</basePowerConsumption>

        <energyPerSecond>30</energyPerSecond>

    </comps>

		<specialDisplayRadius>4.2</specialDisplayRadius>
		<designationCategory>GardenTools</designationCategory>
		<rotatable>false</rotatable>
    <researchPrerequisites>

HeatedSunlamps

    </researchPrerequisites>
	</ThingDef>

	<ThingDef ParentName="BuildingBase">
		<defName>HeatedMiniSunLamp</defName>
		mini heated sun lamp
        <thingClass>VGDrinks.Building_SunLampHeatController</thingClass>
    <tickerType>Rare</tickerType>
		<category>Building</category>

	<graphicData>
      <texPath>Things/Building/HeatedSunMini</texPath>
      <graphicClass>Graphic_Single</graphicClass>
      <drawSize>(1,1)</drawSize>
       <shadowData>
        <volume>(0.2, 0.4, 0.2)</volume>
        <offset>(0,0,-0.1)</offset>
      </shadowData>
      <damageData>
        <rect>(0.2,0.2,0.6,0.6)</rect>
      </damageData>
   </graphicData>
		<altitudeLayer>Building</altitudeLayer>
		<passability>PassThroughOnly</passability>
		<statBases>
			<MaxHitPoints>25</MaxHitPoints>
			<WorkToBuild>150</WorkToBuild>
			<Flammability>1.0</Flammability>
		</statBases>
		<selectable>true</selectable>
		<description>Lights an area brightly enough to grow crops.</description>
		<size>(1,1)</size>
		<costList>
			<Steel>100</Steel>
		      <Component>1</Component>
		</costList>
		<soundImpactDefault>BulletImpactMetal</soundImpactDefault>
		<leaveResourcesWhenKilled>false</leaveResourcesWhenKilled>
    <comps>

        <overlightRadius>7.0</overlightRadius>
        <glowRadius>4.5</glowRadius>
        <glowColor>(370,370,370,0)</glowColor>

        <compClass>CompPowerTrader</compClass>
        <startElectricalFires>true</startElectricalFires>
        <basePowerConsumption>725</basePowerConsumption>

        <energyPerSecond>20</energyPerSecond>

    </comps>

		<specialDisplayRadius>3.2</specialDisplayRadius>
		<designationCategory>GardenTools</designationCategory>
		<rotatable>false</rotatable>
    <researchPrerequisites>

HeatedSunlamps

    </researchPrerequisites>
	</ThingDef>

Added to TODO, too big to close (linking to issue)

BOLTASK Lamp: It's a fire, so no replacement needed

Priced recipes according to VG costs, copper not used as much since it is for power usage(cables, circuitry). Skipped SunLap since it overrides Core, which I already patch (no need for identical patch)

I don't entirely like the Sun Lamp costs... as I said before, 'Mini' is 50% of the coverage of the full size one, yet it costs far less than half of the materials of a full size sun lamp to make, and doesn't even require any quartz.

Glad to see you can still comment after I close the issue :)
The fused quartz acts as a clearer glass, allowing more light to be given off. If the coverage area is small, there's no need for a pure quartz glass, since regular (free) glass would be sufficient. This also allows players to at least get some kind of sunlamp if they haven't researched electric smelting yet, or don't have any quartz.


Cacti 1.x maplist doesn't interpolate variables

git version. PHP 5.6. Cacti 1.1.5.
"%s of your maps had warnings last time it ran. " at the bottom of the map list.

Actually, anywhere that uses % tokens with __n() doesn't work, because __n() doesn't pass its output through sprintf().


grid line disable

how can I remove all borders of the BarChart,
I see no options could do that, ...

Please consult the Chart.js documentation. If tis is not possible to configure then consider opening a feature request in the Chart.js repository


Update to Zenoh 1.0.0

Right now, rmw_zenoh points to zenoh version 0.11.0 which still has several bugs, for example https://github.com/eclipse-zenoh/zenoh/issues/1018, which is especially relevant for larger projects with lots of ROS nodes.
Are there any plans to bump to zenoh 1.0.0 here?

Yes, see #276


pytest options moved to pyproject.toml

Moved pytest options to pyproject.toml
Can you take a look and test @valearna?

Tested locally. Passing the options through the config file looks much better. Thanks @nuin


help about eth transaction issue

Hello, impul,  It's me again, Thanks for you patient.
here's another issue found when I send the transaction, I need to get the gas estimate first, but return error.
"Essentia🌏 curl https://b3.essentia.network/api/v1/ethereum/gas/estimate \\\n\t-X POST \\\n\t-H \'Content-Type: application/json\' \\\n\t-d \'{\n  \"data\" : \"\",\n  \"from\" : \"0x927244ea76dd2d7c42f85efb86a9333cd2f39a67\",\n  \"to\" : \"0xf3cb87c75f7b16c569154da1eec37e40b9aa3b1c\"\n}\'"

When I use the post man to do the direct visist.
https://b3.essentia.network/api/v1/ethereum/gas/estimate

POST

{"data":"","from":"0x927244ea76dd2d7c42f85efb86a9333cd2f39a67","to":"0xf3cb87c75f7b16c569154da1eec37e40b9aa3b1c"}

the response is 502, so how can I debug or fix this? thanks :)

@mousehaohao, if you do not have data, then send "0x"
   ethWallet?.getGasEstimate(from: address, to: destinationAddrss, data: "0x", result: { (result) in
            print(result)
            expectation.fulfill()
        })

But anyway i will fix this in next release.

got it, :) Thanks.


Update developer guide

Changes:

Update UI component details and diagrams
Update product scope
Standardise formatting

Codecov Report
Base: 75.67% // Head: 75.67% // No change to project coverage :thumbsup:

Coverage data is based on head (e65a1ef) compared to base (b7d138e).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #288   +/-   ##
=========================================
  Coverage     75.67%   75.67%
  Complexity      719      719
=========================================
  Files           108      108
  Lines          2064     2064
  Branches        255      255
=========================================
  Hits           1562     1562
  Misses          439      439
  Partials         63       63

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Notify Slack on successful release deploy

This sends a message in Slack on successful stable release deployment, with the following content:
Passwordless.NET new version released!
Version: 1.0.2
Details: https://github.com/passwordless/passwordless-dotnet/releases/tag/v1.0.2

@abergs mergeable on approval

@Tyrrrz I'm guessing the URL will be masked since it comes from secret? I noticed in the action we do log it as info.

Yes, secrets are automatically masked by GitHub Actions. Here's a screenshot from one of my own projects that uses this action for a similar purpose:


Bug: Comment Splits into Two When Typing in Vietnamese and Pressing Enter

Describe the bug
When using the comment feature in Liveblocks and typing in Vietnamese, if there are still underlined words (indicating that they are in the process of being composed), pressing Enter splits the comment into two. However, clicking the send button does not cause this issue.
To Reproduce

Open the comment feature in Liveblocks.
Start typing a comment in Vietnamese.
Ensure that there are still underlined words (indicating that the words are being composed).
Press Enter to submit the comment.

Expected behavior
The comment should be posted as a single comment regardless of whether the Enter key or the send button is used.
Actual Behavior:
When pressing Enter, the comment is split into two separate comments. When clicking the send button, the comment is posted as a single comment as expected.
Illustrations
https://github.com/liveblocks/liveblocks/assets/37234239/51ac76ab-c52e-4902-8697-3884b9415377

Hi @lamtuanamc, thanks for the detailed report!
We'll investigate, and in the meantime could you try Entering on https://www.slatejs.org/examples/richtext and tell us if there are any unexpected behaviors? This is the text editor used in the Comments composer.


Make it easier to use static assets that are part of a RCL project

A RCL project could have static assets like css, js and images. Currently these files don't get published to the referencing application's published wwwroot folder. They need to be included as embedded files in a RCL project and need to use ManifestEmbeddedFileProvider to serve their contents. Its a lot of work for users to set this up. To give an idea, this is what IdentityUI does currently:
https://github.com/aspnet/Identity/blob/dev/src/UI/IdentityDefaultUIConfigureOptions.cs#L50-L66

This is covered by the Static Web Assets feature.


[SaaS Connector] Zendesk - ERASURE (LIVE CHAT endpoints)

Is your feature request related to a specific problem?
A description of what the problem is.
Ex. I'm always frustrated when [...]
Describe the solution you'd like
A description of what you want to happen.
Describe alternatives you've considered, if any
A description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Aha! Link: https://ethyca.aha.io/features/OPS-19

Confirmed that this is not needed for Logitech


Using alt+X as mount hotkeys breaks the radial menu on alt-tab

So I was using Alt+1-4 for my mounts (don't have griffon yet), and every time I alt-tab it breaks the menu, it fixes itself when I open the options menu again with shift alt m.
Probably doesn't recognize that alt has been released afterwards.

See #12, should be fixed in the next release.