DSCNN accuracy reported by test.py

Hi,
If I am not mistaken, test.py, tests the data-set on the checkpoint, and reports the results by forming  confusion matrix.
when I use test.py for DNN with my Data-set which is just an older version of google dataset I see better test accuracy for DNN comparing to DSCNN, ~80% and ~60% respectively, which is not compatible with accuracies reported in the article, it is expected that DSCNN perform better.
I use the same small model size info and other parameters provided here both for train.py and test.py.  Do you see the same accuracies? @navsuda

I did some more experiments as I got last step validation accuracy reported by train.py is different from the accuracy reported by test.py using last available checkpoint. I also tried all other available checkpoints, sometimes I got better results but not the same shown in tensorboard or training reports.
It seems that train.py for DSCNN does not save the best checkpoint, so that the actual best checkpoint is missing at the end.
Is it possible to make train.py  save more checkpoints between steps, or any chance to review the code to get the actual best checkpoint? @navsuda

I changed the train code to get other checkpoints, but still could not see the same validation accuracy both in tensorboard and test.py for the same checkpoint.
      # Save the model checkpoint periodically.
      if (training_step % FLAGS.save_step_interval == 0 or
          train_step == training_steps_max):
        checkpoint_path = os.path.join(FLAGS.train_dir, 'all',
                                       FLAGS.model_architecture + '.ckpt')
        tf.logging.info('Saving to "%s-%d"', checkpoint_path, training_step)
        saver.save(sess, checkpoint_path, global_step=training_step)

        # Save the model checkpoint when validation accuracy improves
        if total_accuracy > best_accuracy:
            best_accuracy = total_accuracy
            checkpoint_path = os.path.join(FLAGS.train_dir, 'best',
                                        FLAGS.model_architecture + '_'+ str(int(best_accuracy*10000)) + '.ckpt')
            tf.logging.info('Saving best model to "%s-%d"', checkpoint_path, training_step)
            saver.save(sess, checkpoint_path, global_step=training_step)

      tf.logging.info('So far the best validation accuracy is %.2f%%' % (best_accuracy*100))

@pooyaww,
The only possible explanation for this discrepancy I can think of is that you have used different parameters for --window_size_ms and --window_stride_ms during training vs. testing. Please make sure you use the same parameters for train.py and test.py.

@navsuda @pooyaww
I met the same problem, in ds_cnn, the quant_test accuracy is lower than the same situation in dnn, and i checked the code, all parameters for --window_size_ms and --window_stride_ms during training vs. testing are same, I wonder if you know what's wrong?
The confusion Matrix as follow:
[[  0   0   0   0   0   0   0   0   0   0 371   0]
[  0 194   0   0   0  47   0   5  17   0 108   0]
[  0 131  30   0   0 128   2   0  11   0  95   0]
[  0 146   0   0   0 152   0   5  17   0  85   1]
[  0  68   0   0   1  19   0   1  30   0 231   0]
[  0  79   0   0   0 176   0   4  13   0 105   0]
[  0 163   1   0   0  58  13  10  12   0  95   0]
[  0 156   0   0   0  31   0 137   3   0  36   0]
[  0 103   0   0   0  33   0   0 141   0  86   0]
[  0  59   0   0   0  12   0   1 105   0 196   0]
[  0  26   0   0   0  11   0   0   5   0 308   0]
[  0 129   0   0   0  73   0   3  20   0 146   1]]
and I want to know,what cause this condition?

@xingdonw,
One thing to check is: did the accuracy degrade after fusing the batch-norm layers to the preceding convolution layers as mentioned in the guide?

@navsuda
A issue I found in source code of quant_models.py:
According the guide, I was trying to quantize ds-cnn model by command:
python quant_test.py  --act_max 0 0 0 0 0 0 0 0 0 0 0 0
which should output a accuracy equal to "test.py ....." because we use floating point for all activation parameters, but it is not the case and I found the reason. In file quant_models.py
A
if(act_max[2layer_no]>0):
depthwise_conv = tf.fake_quant_with_min_max_vars(depthwise_conv,
min=-act_max[2layer_no],
max=act_max[2layer_no]-(act_max[2layer_no]/128.0),
num_bits=8, name='quant_ds_conv'+str(layer_no))
bn = tf.nn.relu(depthwise_conv)
# we need a else branch to handle case when act_max[2*layer_no] == 0

# batch-norm weights folded into depthwise conv
# bn = slim.batch_norm(depthwise_conv, scope=sc+'/dw_conv/batch_norm')

B
if(act_max[2layer_no+1]>0):
pointwise_conv = tf.fake_quant_with_min_max_vars(pointwise_conv,
min=-act_max[2layer_no+1],
max=act_max[2layer_no+1]-(act_max[2layer_no+1]/128.0),
num_bits=8, name='quant_pw_conv'+str(layer_no+1))
bn = tf.nn.relu(pointwise_conv)
we need a else branch to handle case when act_max[2*layer_no+1] == 0
C
       if act_max[1]>0:
          net = tf.fake_quant_with_min_max_vars(net, min=-act_max[1],
              max=act_max[1]-(act_max[1]/128.0), num_bits=8, name='quant_conv1')
        net = tf.nn.relu(net)
         # we need a else branch to handle case when act_max[1] == 0
        #net = slim.batch_norm(net, scope='conv_1/batch_norm')

can you provide a patch for this issue? thanks

@navsuda
another issue is,  when I run python quant_test.py --act_max 64 0 0 0 0 0 0 0 0 0 0 0 .... for ds-cnn model,
I can get a training accuracy which is very close to the training accuracy output by test.py.
but when I try to quantizing the second parameter by command:
python quant_test.py --act_max 64 x 0 0 0 0 0 0 0 0 0 0
I tried replace x with 128,64,32,16,8,4,2,1
all output training accuracy is much lower than when x==0
could you please give some idea for this case? thanks

@leiming0225  @xingdonw
how to get the value of the quantization ranges -- act_max when run quant_test.py? try  128,64,32,16,8,4,2,1 one by one  ?


trouble using stream mode

I've trouble using stream mode. Could you please provide an example client that demonstrates how to use Stream mode effectively?

@Lanny2020, thank you for reaching out. I've added a docker-compose file to simplify testing the streaming feature. Please follow the steps in the README and let me know if it helps.


Fixing broken links on tags page

<a> is not allowed inside <button>, this does not work in modern browsers and is not allowed in HTML5. See http://stackoverflow.com/questions/17253410/link-inside-a-button-not-working-in-firefox

I'm handing in a larger pull request with other files fixed as well.


Optimzied CPU implementation

Modern CPUs have many cores which have fast 64-bit integer multipliers, so it might be worthwhile to target modern x86-64 CPUs.

Use SHA extensions? (Available since Ryzen, not sure about the Intel side)
Hashing  using SIMD instructions (SSEx, AVX, etc)

LBC is using AVX2 and LBC really sucks speed wise!
Vanitygen fork from NDV moved everything to GPU and it became faster.
You have old card and it will speed proggie a bit, but it is a wrong decision, because such card is virtually useless, for puzzles 57 and up you need rigs. And they very often doesn't have modern CPU.

Vanitygen fork from NDV moved everything to GPU and it became faster.
You have old card and it will speed proggie a bit, but it is a wrong decision, because such card is virtually useless, for puzzles 57 and up you need rigs. And they very often doesn't have modern CPU.

I am a fan of Vanitygen (vanitygen plus and vanity from nvd) but I have to say Bitcrack is much faster.

Vanitygen fork from NDV moved everything to GPU and it became faster.
You have old card and it will speed proggie a bit, but it is a wrong decision, because such card is virtually useless, for puzzles 57 and up you need rigs. And they very often doesn't have modern CPU.

I'd still like to give it a shot. AMD is coming out with 32 and 64 core chips, those should be at least over 100 millions keys per second I think.


Equip Page Meta resolvers with more standard functionality

Currently, individual page meta resolvers aggregate the metadata by implementing the resolve() method. This method is responsible for calling different resolvers with the required data. This makes it cumbersome to extend, since whenever you like to extend the list of resolvers, you must override (and reimplement) the resolve method. Moreover, the data required by different resolvers might differ, which leads also to reimplementing the resolve method.
We like to allow for easy implementation of those meta resolvers. This means that

the PageMetaService should call the individual resolvers (if available) on the resolver class
the individual resolvers must gather the data themselves; we no longer will pass in data through arguments

This change will lead to a breaking changes in the API, which we cannot before 2.0. We must either postpone this until 2.0 or have a temporary backwards compatible feature in place.
Stretch goals:

make the list of resolvers configurable for the PageMetaService, so that custom/future resolvers can be added without touching the implementation cross all resolvers
execute some resolvers only for SSR or dev mode, to further optimise the runtime

QA steps:

Ensure that you can implement any resolver interface with featureLevel > 1.3, without overriding the resolve() method of a specific resolver

After consultation with @tobi-or-not-tobi, QA done and implemented resolvers works as expected.


Masternodes and IPv6

https://github.com/dashpay/dash/blob/v0.12.1.x/src/activemasternode.cpp#L159
Shouldn't this line have && pnode->addr.IsIPv6() as well?
if (pnode->fSuccessfullyConnected && pnode->addr.IsIPv4() && pnode->addr.IsIPv6())
Or is there a  reason to not run Masternodes on IPv6?

remember also about TOR...

Masternodes on IPv6 are disabled/deprecated for Dash 12.1 due to connectivity issues, see https://github.com/dashpay/dash/pull/1065

deprecated? whaaat? ;-) IPv6??

Read the discussion on #1065 ... The masternode network is supposed to provide SERVICE to the network, and 12.0 has a lot of issues with mixing due to heterogenous IPv4/IPv6 landscape. Therefore we decided to disable IPv6 MASTERNODES for now.
Normal wallet functionality is not affected.

Ok because I did some testing and you can actually force all the Masternodes on a network to WATCHDOG_EXPIRED with some IPv6 tinkering. Dangerous.
I have implemented this change to DarkSilk:
enum Network ParseNetwork(std::string net) {
if (fStormNode){
boost::to_lower(net);
if (net == "ipv4") return NET_IPV4;
if (net == "ipv6") return NET_UNROUTABLE;
if (net == "tor" || net == "onion")  return NET_UNROUTABLE;
return NET_UNROUTABLE;
} else if (!fStormNode) {
boost::to_lower(net);
if (net == "ipv4") return NET_IPV4;
if (net == "ipv6") return NET_IPV6;
if (net == "tor" || net == "onion")  return NET_TOR;
return NET_UNROUTABLE;
}
}

Looking through now to further enforce ipv6 being disabled/unavailable when running a Masternode.

By the way even though they go to WATCHDOG_EXPIRED they still receive payments, however, they cannot provide services such as InstantSend signing, mixing etc. They just get their payments....

Oh and the Masternode running in IPv6 stays ENABLED lol

but what with countries where IPv6 is more popular? And if somebody have only access to publich IP6? strange decision. at least for now.
When Dash will fully support IPv6?

Once these security issues are sorted....

We are running tests on our "Stormnodes" under all situations. Hot/Cold/ipv4/ipv6/controller wallets/public ip/bindip etc. etc.

host = ipv4 only
host = ipv4 + ipv6 + MN limited to ipv4 only
host = ipv4 + ipv6 and check MN or not

I'd appreciate if you don't use the ticket system as chat. You have just triggered 30+mails in 10 minutes to members subscribed here.
Thanks.


cdituri/feature/hyperv packer builder

Overview
This pull request adds hyperv-iso builder support to nix-community/nixbox:

add hyperv packer builder
add hyperv-iso.nix builder
regenerate iso_urls.json, nixos-i686.json, and nixos-x86_64.json

!!! Important: the last commit in the series brings iso_urls.json, nixos-i686.json, and nixos-x86_64.json to current. This is note-worthy because it looks like NixOS upstream is now using a 'latest' .iso release, and we leverage that new approach here as well.

Steps
Run packer build:
packer build -force -var "memory=2048" -var "disk_size=10280" -on-error=ask -only=hyperv-iso .\nixos-x86_64.json

Import resultant vagrant .box image:
vagrant box add --force --name hyperv/nixos-x86_64 .\nixos-19.09-hyperv-x86_64.box

Run vagrant:
vagrant init hyperv/nixos-x86_64
vagrant up --provider=hyperv

Final note: many individuals on Windows have git config --global core.autocrlf true set, myself included. Having autocrlf set caused the following error during packer build, after a fresh clone:
==> hyperv-iso: Installation finished. No error reported.
    hyperv-iso: installation finished!
==> hyperv-iso:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
==> hyperv-iso:                                  Dload  Upload   Total   Spent    Left  Speed
==> hyperv-iso: 100   524  100   524    0     0  32750      0 --:--:-- --:--:-- --:--:-- 34933
==> hyperv-iso: setting up /etc...
==> hyperv-iso: /nix/var/nix/profiles/system/sw/bin/bash: line 2: $'\r': command not found
==> hyperv-iso: /nix/var/nix/profiles/system/sw/bin/bash: line 4: $'\r': command not found
==> hyperv-iso: /nix/var/nix/profiles/system/sw/bin/bash: line 7: $'\r': command not found
==> hyperv-iso: /nix/var/nix/profiles/system/sw/bin/bash: line 8: syntax error near unexpected token `$'do\r''
==> hyperv-iso: '
    hyperv-iso: Start postinstall ...
==> hyperv-iso: Script exited with non-zero exit status: 2.Allowed exit codes are: [0]
==> hyperv-iso: Step "StepProvision" failed
==> hyperv-iso: [c] Clean up and exit, [a] abort without cleanup, or [r] retry step (build may fail even if retry succeeds)?

If you see this error, its because scripts/{install, post-install}.sh need to be LF; and git on Windows has presumably checked them out with CRLF line-endings on clone/checkout.

Thanks for the review @zimbatm, much appreciated :+1: crazy at work atm so aiming to circle back here sometime over the weekend to incorporate your feedback.

This is going to be hard to maintain as it requires the user to have HyperV installed. But there isn't much we can do, this is the current packer design.

Totally understand, re: maintainence and packer design. I just want more NixOS! and, as long as Windows is the preference at my employer, more than happy to help maintain this native Hyper-V builder :smiley:

Sounds good. Let me know when it's ready to be merged :)

@zimbatm pull request is ready to merge at the moment. Some things worth nothing below first however:

In the last 2 weeks the NixOS website has changed the way they publish the .iso links, breaking the regex in iso_urls_update.rb. @shajra-simspace left a comment in #59 switching the implementation from regex parsing to XML parsing. It's a more robust implementation, and I've included an attributed commit 1201013e103228f80683efd5e224fff78b7e8a22.

@shajra-simspace hope you're ok with the above approach. Any thoughts, or would you like things attributed differently, etc? see the commit link.

NixOS 20.03 has changed users.group and users.users and are depreciating the current form. For nix-community/nixbox I've left things as-is, as it;s the most graceful approach (ie backwards compatible when building <= NixOS 20.03), and warns adequately while building. See NixOS/nikpkgs/pull/63103 and the below.

Click to expand and show warnings generated
==> hyperv-iso: mke2fs 1.45.5 (07-Jan-2020)
    hyperv-iso: Discarding device blocks: done
    hyperv-iso: Creating filesystem with 2631424 4k blocks and 658368 inodes
    hyperv-iso: Filesystem UUID: ed750ed0-be48-4875-9572-ae69f994de08
    hyperv-iso: Superblock backups stored on blocks:
    hyperv-iso:         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
    hyperv-iso:
    hyperv-iso: Allocating group tables: done
    hyperv-iso: Writing inode tables: done
    hyperv-iso: Creating journal (16384 blocks): done
    hyperv-iso: Writing superblocks and filesystem accounting information: done
    hyperv-iso:
==> hyperv-iso: writing /mnt/etc/nixos/hardware-configuration.nix...
==> hyperv-iso: writing /mnt/etc/nixos/configuration.nix...
    hyperv-iso: building the configuration in /mnt/etc/nixos/configuration.nix...
==> hyperv-iso: trace: warning: In file /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/config/users-groups.nix
==> hyperv-iso: a list is being assigned to the option config.users.users.
==> hyperv-iso: This will soon be an error as type loaOf is deprecated.
==> hyperv-iso: See https://github.com/NixOS/nixpkgs/pull/63103 for more information.
==> hyperv-iso: Do
==> hyperv-iso:   users.users =
==> hyperv-iso:     { root = {...}; vagrant = {...}; }
==> hyperv-iso: instead of
==> hyperv-iso:   users.users =
==> hyperv-iso:     [ { name = "root"; ...} { name = "vagrant"; ...} ]
==> hyperv-iso:
==> hyperv-iso: trace: warning: In file /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/config/users-groups.nix
==> hyperv-iso: a list is being assigned to the option config.users.groups.
==> hyperv-iso: This will soon be an error as type loaOf is deprecated.
==> hyperv-iso: See https://github.com/NixOS/nixpkgs/pull/63103 for more information.
==> hyperv-iso: Do
==> hyperv-iso:   users.groups =
==> hyperv-iso:     { vagrant = {...}; }
==> hyperv-iso: instead of
==> hyperv-iso:   users.groups =
==> hyperv-iso:     [ { name = "vagrant"; ...} ]
==> hyperv-iso:
    hyperv-iso: copying channel...
    hyperv-iso: installing the boot loader...
==> hyperv-iso: setting up /etc...
==> hyperv-iso: updating GRUB 2 menu...
==> hyperv-iso: installing the GRUB 2 boot loader on /dev/sda...
==> hyperv-iso: Installing for i386-pc platform.
==> hyperv-iso: Installation finished. No error reported.
    hyperv-iso: installation finished!

thanks!


authData not set upon new user signin and password reset

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Background: I am using Authenticator component with child components, including RequireNewPassword.  Users can't sign up on their own for my application; they are pre-created in the AWS Cognito console.
Steps:

I create a new Cognito user in the AWS Cognito console, and require that user to change their password on first login.
That new user signs in for the first time and changes their password.
The authData state in the Authenticator component never gets set (even though its state.auth and its child component's state.authState is signedIn.

As a result, my wrapped custom components, which rely on authData and authState, don't render until the user reloads or signs out and in again.
I have an onStateChange={this.handleAuthStateChange} handler on the Authenticator component, and that handler sees the state change and can read the new credentials via Auth.currentUserPoolUser()—they just don't make their way into the components' state until reload or re-login.
What is the expected behavior?
The authData state should properly flow through the Authenticator component and its children.
Which versions of Amplify, and which browser / OS are affected by this issue? Did this work in previous versions?
You can turn on the debug mode to provide more info for us by setting window.LOG_LEVEL = 'DEBUG'; in your app.

@powerful23 @richardzcode Thanks for the fix. Per https://github.com/richardzcode/aws-amplify/blob/master/packages/aws-amplify-react/src/Auth/AuthPiece.jsx#L60-L61, is the changeState method expected to work with an undefined data argument?
If not, maybe the handleStateChange at https://github.com/aws/aws-amplify/blob/master/packages/aws-amplify-react/src/Auth/Authenticator.jsx#L51-L58 could be updated to throw an error on, or otherwise handle, that case? Or perhaps we could use an object literal for handleStateChange to avoid similar issues in the future (e.g. give the starting state.authData an explicit value, rather than implicitly initializing it as undefined).


Inav opt flow lidar

Nice! Test flown?

@LorenzMeier I will do that.

I flew - at least in ALTCTL mode - with it. XY position estimation works quite well. One thing I noticed was, that XY position was drifting significantly at very low altitude. This seems to be the result of the limitation of the flow estimation at 0.2m.

Does this PR should solve the issue with altitude estimation for the LidarLite2 only, without px4flow connected? I tried to compile from your https://github.com/ChristophTobler/Firmware/tree/inav_opt_flow_lidar branch and it didn't work in my case (LidarLite2 connected via i2c, the data of which is being send properly over the mavlink). I will try to recompile and test it out again. Will send you the log if you are interested.

@ilia-sheremet The altitude estimation with the LidarLite has nothing to do with the PX4Flow. Have you enabled the lidar messages (SENS_EN_LL40LS = 1)? And have you enabled lidar altitude estimation in the qgc params (I think the name is inav_lidar_est or something similar)?

@ecmnet Thank you for testing. What firmware have you got on the PX4Flow? This is the good one: https://github.com/PX4/Flow/commit/4a314cfdb099aed9795b825e7518203771207fbb
What is the flow quality when you fly at 0.2m? How did you focus your lens? If you often fly at that height, maybe I would adjust it.

@ChristophTobler Aren't they use the same topic within the INAV? Hehe:

@ilia-sheremet No they are separated. The optical flow calculation is dependent on the distance but not vice versa.

@ChristophTobler I have the latest Firmware installed. The issue seems more related to the case pixflow does not provide sufficient data. In that case, is acc integrated to estimate position? This might explain the effect.

By the way. Drift at that height is Bad for accurate landings

@ecmnet Ok. Not sure which is the latest version. Just make sure it's the camfix and not KLT. No, acc alone does never estimate the position. Yes, that's right...

As far as I remember, the drift occurred also, when the copter did not move at all.

Just to let you know, what I mean by drift: XY plot:

@ChristophTobler @LorenzMeier Tested this today, will upload logs and give feedback tomorrow.
Pretty nice!

@tumbili cool, thanks! @ecmnet Ok so this happened while hovering (pos hold)? What's the time period?  What do you mean with invalid? Is the flow quality low? I mean a small drift can happen... How did you attach the PX4Flow? Because the biggest error comes from the PX4Flow gyroscope during position hold and you can minimize this by attaching the PX4Flow in a shielded spot. Another thing is the firmware (KLT has more drift/noise) but I already mentioned that.

@ChristophTobler: No, this was not pos-hold. It started during landing (manually) and continued after being landed. My PX4Flow is mounted centrally between the landing gear (about 8 cm over ground), connected with twisted I2C cables and shielded. As soon I find any spare time, I will look for any correlations between flow raw data and estimation (speed) and let you know.

@ecmnet Ok, thanks! Ah I just saw that it will actually predict position with just acc data for a short time if sensor data is not available (I'm no fan of it). Will have a look at it and discuss it with Lorenz.

XY Flow and XY Speed (not flying - holding vehicle at about 20cm):

I gave this a quick test flight today in ALTCTL only as the Lidar Lite we have kills GPS. Worked nicely.
The only two things I've noticed so far are:

The INAV_LIDAR_EST doesn't show up in QGC even though I flashed using it (I don't have the most recent QGC version though).
At one point when flying over a large rock it didn't pick the rise but did get the fall and ended up closer to the ground after the rock than it was before.

Will test some more but this is looking good.

@SimonWilks thanks for testing! Have you looked for INAV_LIDAR_EST in the default category? Maybe it's in there.
The altitude change might be because the drop/edge of the rock was not clear enough. Probably the correction threshold can be lowered (currently its 0.5m)

Actually I didn't have a default category at all which is odd. So I suspect I need to update QGC (will do tomorrow).

@ChristophTobler : Here a plot of Flow (lower graph) vs. NED XY-speed (upper graph). Seems not to correlate.

@ecmnet I shouldn't be hijacking this thread, but could you try a flight with LPE (#3209) and see how flow performance compares directly to inav?

@mhkabir I would like to. Does LPE support altitude estimation by Laser rangefinders?

Yes, it does just fine. You just need to use that PR of mine.
You'll probably find the altitude estimation performance to be on par with
or better than that with INAV.
On 28 Jan 2016 8:53 am, "Eike"<EMAIL_ADDRESS>wrote:

@mhkabir https://github.com/mhkabir I would like to. Does LPE support
altitude estimation by Laser rangefinders?
—
Reply to this email directly or view it on GitHub
https://github.com/PX4/Firmware/pull/3532#issuecomment-175939265.

@ecmnet Ok, yes. If I look a the flow graph I presume the quad already landed (or not flying), right? So what is the height at that moment?

@ChristophTobler Yes it was going down from about 0.7m.

@ecmnet Could you please upload your log on http://logs.uaventure.com/ so that I can have a detailed look at it? Thanks

with the new additions position hold is now very stable (video: https://www.youtube.com/watch?v=Ih8FVXKHRFQ)

[image: Screenshot from 2016-02-04 08-18-03.png]
On Thu, Feb 4, 2016 at 1:53 AM ChristophTobler<EMAIL_ADDRESS>wrote:

with the new additions position hold is now very stable (video:
https://www.youtube.com/watch?v=Ih8FVXKHRFQ)
—
Reply to this email directly or view it on GitHub
https://github.com/PX4/Firmware/pull/3532#issuecomment-179713896.

Closing this in favour of #3693.


[SPARK-26812][SQL] Report correct nullability for complex datatypes in Union

What changes were proposed in this pull request?
When there is a Union, the reported output datatypes are the ones of the first plan and the nullability is updated according to all the plans. For complex types, though, the nullability of their elements is not updated using the types from the other plans. This means that the nullability of the inner elements is the one of the first plan. If this is not compatible with the one of other plans, errors can happen (as reported in the JIRA).
The PR proposes to update the nullability of the inner elements of complex datatypes according to most permissive value of all the plans.
How was this patch tested?
added UT

Test build #102014 has started for PR 23726 at commit dd8f1d2.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/7688/
Test PASSed.

Test build #102014 has finished for PR 23726 at commit dd8f1d2.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/102014/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/7694/
Test PASSed.

Test build #102022 has started for PR 23726 at commit 0f903ab.

Test build #102022 has finished for PR 23726 at commit 0f903ab.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/102022/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/7706/
Test PASSed.

Test build #102035 has started for PR 23726 at commit 6e686ed.

Test build #102035 has finished for PR 23726 at commit 6e686ed.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/102035/
Test PASSed.

Hi, @cloud-fan and @gatorsmile .
It depends on the perspective, can we consider this as a new feature (or improvement)?

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/7787/
Test PASSed.

Test build #102146 has started for PR 23726 at commit bc57f88.

Test build #102146 has finished for PR 23726 at commit bc57f88.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/102146/
Test PASSed.

shall we fix Intersect as well?

I think it's a bug fix, as we may hit problems if a struct field is nullable but we report it as not. But I'm not sure how serious the bug is, sounds like it's hard to hit the bug.

@cloud-fan I don't think we should fix Intersect since in that case the data must be present in both sides so there cannot be items with null if in the first plan (actually either of them) there is none.
I agree with this being a bug fix for a case which is probably not common.

For Intersect, it's an improvement not bug fix?

@cloud-fan what we might want to do as an improvement is the exact opposite of what we are doing here IMHO, ie. marking as not nullable datatypes which are nullable in the first plan and not nullable in the second. But this would mean create a new method for doing this and I am not sure that the little gain we have for the optimization is worth the burden of maintaining it (it would be only for complex datatypes with different nullabilities...).

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/7816/
Test PASSed.

Test build #102202 has started for PR 23726 at commit 4921719.

Test build #102202 has finished for PR 23726 at commit 4921719.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/102202/
Test PASSed.

since we are touching Union, I'm wondering if we should just create new output attribubutes for Union, instead of reusing the first child's output. cc @gatorsmile

@cloud-fan that is an interesting point indeed. I wondered about that too, but I wanted to keep the scope of this fix as limited as possible. What about trying and do that in a followup?

any thoughts on the above point @cloud-fan @gatorsmile ? Thanks.

any more comments on this? Thanks.

So this patch does fix the problem, but my concern is, picking the first child's output as output is pretty tricky. Before adding more tricks to it, I'm thinking about if there is a way to fix the problem entirely, by always using a new seq of attr IDs as the output.

@cloud-fan I am not I 100% get your comment. I don't see the relationship between creating new attribute IDs and reporting the correct nullabilty for nested fields. I think just creating new IDs/attributes doesn't solve/is not related to this issue, but maybe I am missing something...

so the data type resolving logic is still needed, but if we use new attributes, the withDataType API is not needed. How about we remove withDataType from this PR and move forward? We can explore the new attributes idea later.

ok, let me do that, thanks @cloud-fan

Test build #104087 has started for PR 23726 at commit ea6cccc.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/9435/
Test PASSed.

Test build #104087 has finished for PR 23726 at commit ea6cccc.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104087/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/9455/
Test PASSed.

Test build #104109 has started for PR 23726 at commit 3031cee.

Test build #104109 has finished for PR 23726 at commit 3031cee.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104109/
Test PASSed.

Retest this please.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/9495/
Test PASSed.

Test build #104152 has started for PR 23726 at commit 3031cee.

Test build #104152 has finished for PR 23726 at commit 3031cee.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104152/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/9502/
Test PASSed.

Test build #104159 has started for PR 23726 at commit 874ad6f.

Test build #104159 has finished for PR 23726 at commit 874ad6f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104159/
Test PASSed.

thanks, merging to master!


JobFinished Event Not Fired when Level Up

Hello,
I have found a bug where the job data is not reset after a profile upgrade/level up. The OnJob stays true and the JobFinished stays false and everything indicates that the hob is still in progress, even the trailerattached is still true. This testing was done in the quick job/not owning my own truck on a new profile. Can you fix this?

The onJob flag is reset once the trailerAttached value goes low. See https://github.com/nlhans/ets2-sdk-plugin/blob/master/ets2-telemetry/src/ets2-telemetry.cpp#L95
The trailer attached flag, as you indicated stuck high, is directly from ETS2 SDK: https://github.com/nlhans/ets2-sdk-plugin/blob/master/ets2-telemetry/src/ets2-telemetry.cpp#L382
This indicates a minor bug in ETS2 causing the failure of the "onJob" flag. Either because of indeed the level-up screen, or because of the quick job (I haven't done a quick job in ages).
Unfortunately I don't have got any other information to go by that the job has been completed, so I can't easily think of a fix.


Update chang user stories coverage file

Hey hey, the file to update is src_docs/chang_user_stories_template.rst. The one you modified is generated from the template.

Hey hey, the file to update is src_docs/chang_user_stories_template.rst. The one you modified is generated from the template.

fixed :)


Assignment 18 swift vs obj c

Hey @vcashk, looks like you accidentally opened a pull request into the main Bloc exercises repo, instead of your fork.


fix(clerk-js): Set box-sizing to border-box by default

Description
This PR applies box-sizing: border-box; as default for inputs and the Box primitive instead of box-sizing: inherit;.
This is useful as it tells the browser to contain any padding or border to the elements size and will prevent any unnecessary behaviour.

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Packages affected

[ ] @clerk/backend
[ ] @clerk/chrome-extension
[ ] @clerk/clerk-js
[ ] @clerk/clerk-expo
[ ] @clerk/fastify
[ ] gatsby-plugin-clerk
[ ] @clerk/localizations
[ ] @clerk/nextjs
[ ] @clerk/clerk-react
[ ] @clerk/remix
[ ] @clerk/clerk-sdk-node
[ ] @clerk/shared
[ ] @clerk/themes
[ ] @clerk/types
[ ] build/tooling/chore

@panteliselef there is one for the Input but not for the Box, but the Box is just a primitive to create any element so it's easy to change it on any element you want.


Added tutorial for Memorize activity (works within editor mode as well)

Good start.
Few remarks:

You must not do a PR on the master branch, it should be on the dev branch
Will be nice to add a popup to explain the the user should click on tile
Will be nice to add popup in Edit mode for elements: Add, Update, Remove, Input field and Insert Image button

Nice.
Few remarks:

Depending of the type of the game, there is no always a set of "1" cards and a set of "2" cards. Select for example the sound game in the palette.

It will be better to do steps to explain toolbar button before steps to explain the board
The step "End of tutorial" is useless
In Edit mode, it will be nice to add a step to explain the button to go back to the Play mode.

That's better.
By the way, could you refresh your branch because on my side the fullscreen button (coming from another PR) appears twice when I merge your branch.

Please update also the [es] part of the locale.ini to integrate new strings. You could just copy the [en] values.


Unsloth vs Torch.Compile

Has anyone done a benchmark to compare against torch.compile()d HF models?
Since the premise of torch.compile is kernel fusion and this project's premise is the same. Have you guys tested how much faster your handwritten kernels are against torch.compile?

I exactly used torch.compile before I even started writing kernels - you will get speedups if I remember clearly - if you use HF's trainer like below with gradient_checkpointing ON:
torch_compile = True,
torch_compile_mode = "max-autotune-no-cudagraphs",

you will find it will not compile at all due to GC with errors of RuntimeError: element 0 of tensors does not require grad and does not have a grad_fn.
The trick is to compile each kernel separately, and bypass the bitsandbytes and GC parts. I found it to be 1.5x faster. However, the VRAM usage of torch.compile does not decrease at all, since our optimizations aren't just kernel fusion!
Our blog post https://unsloth.ai/blog/mistral-benchmark specifically showcases our other optimizations - specifically our manual autograd engine which specifically reduces FLOPs - ie not kernel fusion, but actual FLOP reduction.
You are more than happy to check if HF's torch_compile flag works. If you set GC to False, it most likely will work, but VRAM usage will literally explode.
TLDR: torch.compile makes training 1.5x faster but VRAM usage explodes. Likewise HF's torch_compile flag fails on gradient_checkpointing = True, which explodes VRAM usage again. Unsloth's OSS is 2.2x faster, and uses 62% less VRAM.


cant drop pop on enemy planets (ground invasion)

Order by hand or with order dont work

order by hand is already an issue: https://github.com/sirgwain/craig-stars/issues/102
I believe the other issue is the quick drop order: https://github.com/sirgwain/craig-stars/issues/185


TST/CLN: remove assert_isinstance

testing.py has assert_isinstance and assertIsInstance duplicately, and each test case uses either of them by choice.
Changed to use assertIsInstance in all cases, and make assert_isinstance show warning.

thanks!


Lookout UI Job Cancellation

Allows users to cancel jobs from the Lookout UI.
Note that this requires CORS to be enabled on the Armada API.

I think that this cancellation popup contains too much the word "cancel"
Cancel Jobs
Cancel the following jobs
CANCEL JOBS


gcc12 build fails because std:shared_ptr requires explicit declation of

Build fails on opensuse tumbleweed
Steps to reproduce
    ##Tested on commit 6b8b6e864a35a43ee71fe652fc95013aacf6904f
    $git clone https://github.com/KomputeProject/kompute.git
    $cmake -Bbuild
    $cd build
    $make

    $gcc (SUSE Linux) 12.2.1 20221020 [revision 0aaef83351473e8f4eb774f8f999bbe87a4866d7]
    Copyright (C) 2022 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

     $lsb_release -a
    LSB Version:    n/a
    Distributor ID: openSUSE
    Description:    openSUSE Tumbleweed
    Release:        20221124
    Codename:       n/a

   Error log
gitrepo/kompute/build> make
[ 16%] Built target fmt
[ 27%] Built target kp_shader
[ 38%] Built target kp_logger
[ 44%] Building CXX object src/CMakeFiles/kompute.dir/OpTensorCopy.cpp.o
    In file included from /home/doof/gitrepo/kompute/src/include/kompute/operations/OpTensorCopy.hpp:6,
                     from /home/doof/gitrepo/kompute/src/OpTensorCopy.cpp:3:
    /home/doof/gitrepo/kompute/src/include/kompute/Tensor.hpp:55:27: error: expected ‘)’ before ‘<’ token
       55 |     Tensor(std::shared_ptr<vk::PhysicalDevice> physicalDevice,
          |           ~               ^
          |                           )
    /home/doof/gitrepo/kompute/src/include/kompute/Tensor.hpp:108:30: error: ‘std::shared_ptr’ has not been declared
      108 |                         std::shared_ptr<Tensor> copyFromTensor);
          |                              ^~~~~~~~~~
    /home/doof/gitrepo/kompute/src/include/kompute/Tensor.hpp:108:40: error: expected ‘,’ or ‘...’ before ‘<’ token
      108 |                         std::shared_ptr<Tensor> copyFromTensor);
          |                                        ^
    /home/doof/gitrepo/kompute/src/include/kompute/Tensor.hpp:256:10: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
      256 |     std::shared_ptr<vk::PhysicalDevice> mPhysicalDevice;
          |          ^~~~~~~~~~
    /home/doof/gitrepo/kompute/src/include/kompute/Tensor.hpp:6:1: note: ‘std::shared_ptr’ is defined in header ‘<memory>’; did you forget to ‘#include <memory>’?
        5 | #include "logger/Logger.hpp"
      +++ |+#include <memory>
        6 | #include <string>
    /home/doof/gitrepo/kompute/src/include/kompute/Tensor.hpp:257:10: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
      257 |     std::shared_ptr<vk::Device> mDevice;
          |          ^~~~~~~~~~
    /home/doof/gitrepo/kompute/src/include/kompute/Tensor.hpp:257:5: note: ‘std::shared_ptr’ is defined in header ‘<memory>’; did you forget to ‘#include <memory>’?
      257 |     std::shared_ptr<vk::Device> mDevice;
          |     ^~~
    /home/doof/gitrepo/kompute/src/include/kompute/Tensor.hpp:260:10: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
      260 |     std::shared_ptr<vk::Buffer> mPrimaryBuffer;

https://gcc.gnu.org/gcc-12/porting_to.html
There may be more issues related to gcc 12

Porting to GCC 12
The GCC 12 release series differs from previous GCC releases in a number of ways. Some of these are a result of bug fixing, and some old behaviors have been intentionally changed to support new standards, or relaxed in standards-conforming ways to facilitate compilation or run-time performance.
Some of these changes are user visible and can cause grief when porting to GCC 12. This document is an effort to identify common issues and provide solutions. Let us know if you have suggestions for improvements!
C language issues
Computed goto now requires a pointer type
In GCC 12, a computed goto requires a pointer type. An example which was accepted before:
void f(void)
{
goto *10;
}
is no longer accepted and you need to add a cast to it like:
void f(void)
{
goto (void)10;
}
C++ language issues
Header dependency changes
Some C++ Standard Library headers have been changed to no longer include other headers that were being used internally by the library. As such, C++ programs that used standard library components without including the right headers will no longer compile.
The following headers are used less widely in libstdc++ and may need to be included explicitly when compiled with GCC 12:
<memory> (for std::shared_ptr, std::unique_ptr etc.)
<iterator> (for std::begin, std::end, std::size, std::istream_iterator, std::istreambuf_iterator)
<algorithm> (for std::for_each, std::copy etc.)
<utility> (for std::pair)
<array> (for std::array)
<atomic> (for std::atomic)
<ctime> (for std::time, std::mktime etc.)
<pthread.h> (for pthread_create, pthread_mutex_t etc.)

C++ Standard Library deprecations
Warnings have been added for use of C++ standard library features that are deprecated (or no longer present at all) in recent C++ standards. Where possible, the warning suggests a modern replacement for the deprecated feature.
The std::iterator base class can usually be replaced by defining the same necessary typedefs directly in your iterator class. The std::unary_function and std::binary_function base classes can often be completely removed, or the typedefs for result_type and argument types can be defined directly in your class.
Fortran language issues
Argument name for CO_REDUCE
GCC 12 now uses OPERATION as the name of the function to the CO_REDUCE intrinsic for the pairwise reduction, thus conforming to the Fortran 2018 standard.
-- Found Vulkan Header version: 1.2.231
-- Running vulkaninfo was successful. Parsing the output...
-- GPU0 supports Vulkan API version '1.3.224'.
Valid GPU (GPU0) for Vulkan header version 1.2.231 found. GPU0 supports up to Vulkan 1.3.224.
-- Module support is disabled.
-- Version: 8.1.1
-- Build type: Release
-- CXX_STANDARD: 14
-- Required features: cxx_variadic_templates
-- Setting KOMPUTE_OPT_LOG_LEVEL to according to the build type
-- Configuring done
-- Generating done
-- Build files have been written to: /home/doof/gitrepo/kompute/examples/array_multiplication/build
I could not build the example code
make
[ 13%] Built target fmt
[ 22%] Built target kp_shader
[ 31%] Built target kp_logger
[ 36%] Building CXX object _deps/kompute-build/src/CMakeFiles/kompute.dir/OpTensorCopy.cpp.o
In file included from /home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/operations/OpTensorCopy.hpp:6,
                 from /home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/OpTensorCopy.cpp:3:
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:55:27: error: expected ‘)’ before ‘<’ token
   55 |     Tensor(std::shared_ptr<vk::PhysicalDevice> physicalDevice,
      |           ~               ^
      |                           )
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:108:30: error: ‘std::shared_ptr’ has not been declared
  108 |                         std::shared_ptr<Tensor> copyFromTensor);
      |                              ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:108:40: error: expected ‘,’ or ‘...’ before ‘<’ token
  108 |                         std::shared_ptr<Tensor> copyFromTensor);
      |                                        ^
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:256:10: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
  256 |     std::shared_ptr<vk::PhysicalDevice> mPhysicalDevice;
      |          ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:6:1: note: ‘std::shared_ptr’ is defined in header ‘<memory>’; did you forget to ‘#include <memory>’?
    5 | #include "logger/Logger.hpp"
  +++ |+#include <memory>
    6 | #include <string>
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:257:10: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
  257 |     std::shared_ptr<vk::Device> mDevice;
      |          ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:257:5: note: ‘std::shared_ptr’ is defined in header ‘<memory>’; did you forget to ‘#include <memory>’?
  257 |     std::shared_ptr<vk::Device> mDevice;
      |     ^~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:260:10: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
  260 |     std::shared_ptr<vk::Buffer> mPrimaryBuffer;
      |          ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:260:5: note: ‘std::shared_ptr’ is defined in header ‘<memory>’; did you forget to ‘#include <memory>’?
  260 |     std::shared_ptr<vk::Buffer> mPrimaryBuffer;
      |     ^~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:262:10: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
  262 |     std::shared_ptr<vk::Buffer> mStagingBuffer;
      |          ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:262:5: note: ‘std::shared_ptr’ is defined in header ‘<memory>’; did you forget to ‘#include <memory>’?
  262 |     std::shared_ptr<vk::Buffer> mStagingBuffer;
      |     ^~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:264:10: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
  264 |     std::shared_ptr<vk::DeviceMemory> mPrimaryMemory;
      |          ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:264:5: note: ‘std::shared_ptr’ is defined in header ‘<memory>’; did you forget to ‘#include <memory>’?
  264 |     std::shared_ptr<vk::DeviceMemory> mPrimaryMemory;
      |     ^~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:266:10: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
  266 |     std::shared_ptr<vk::DeviceMemory> mStagingMemory;
      |          ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:266:5: note: ‘std::shared_ptr’ is defined in header ‘<memory>’; did you forget to ‘#include <memory>’?
  266 |     std::shared_ptr<vk::DeviceMemory> mStagingMemory;
      |     ^~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:270:28: error: ‘std::shared_ptr’ has not been declared
  270 |     void createBuffer(std::shared_ptr<vk::Buffer> buffer,
      |                            ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:270:38: error: expected ‘,’ or ‘...’ before ‘<’ token
  270 |     void createBuffer(std::shared_ptr<vk::Buffer> buffer,
      |                                      ^
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:272:34: error: ‘std::shared_ptr’ has not been declared
  272 |     void allocateBindMemory(std::shared_ptr<vk::Buffer> buffer,
      |                                  ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:272:44: error: expected ‘,’ or ‘...’ before ‘<’ token
  272 |     void allocateBindMemory(std::shared_ptr<vk::Buffer> buffer,
      |                                            ^
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:276:32: error: ‘std::shared_ptr’ has not been declared
  276 |                           std::shared_ptr<vk::Buffer> bufferFrom,
      |                                ^~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:276:42: error: expected ‘,’ or ‘...’ before ‘<’ token
  276 |                           std::shared_ptr<vk::Buffer> bufferFrom,
      |                                          ^
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:302:28: error: expected ‘)’ before ‘<’ token
  302 |     TensorT(std::shared_ptr<vk::PhysicalDevice> physicalDevice,
      |            ~               ^
      |                            )
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/OpTensorCopy.cpp: In member function ‘virtual void kp::OpTensorCopy::record(const vk::CommandBuffer&)’:
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/OpTensorCopy.cpp:49:42: error: cannot convert ‘__gnu_cxx::__alloc_traits<std::allocator<std::shared_ptr<kp::Tensor> >, std::shared_ptr<kp::Tensor> >::value_type’ {aka ‘std::shared_ptr<kp::Tensor>’} to ‘int’
   49 |         this->mTensors[i]->recordCopyFrom(commandBuffer, this->mTensors[0]);
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Tensor.hpp:108:25: note:   initializing argument 2 of ‘void kp::Tensor::recordCopyFrom(const vk::CommandBuffer&, int)’
  108 |                         std::shared_ptr<Tensor> copyFromTensor);
      |                         ^~~~~~~~~~~~~~~
make[2]: *** [_deps/kompute-build/src/CMakeFiles/kompute.dir/build.make:132: _deps/kompute-build/src/CMakeFiles/kompute.dir/OpTensorCopy.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:263: _deps/kompute-build/src/CMakeFiles/kompute.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

ahh, Cmake fetches the old version
I made a quick and dirty change and it compiles. I guess I will not include this change in my commit and let the maintainer deal with Cmake.
diff --git a/examples/array_multiplication/CMakeLists.txt b/examples/array_multiplication/CMakeLists.txt
index 6e0c907..b17cb65 100644
--- a/examples/array_multiplication/CMakeLists.txt
+++ b/examples/array_multiplication/CMakeLists.txt
@@ -25,8 +25,8 @@ if(WIN32) # Install dlls in the same directory as the executable on Windows
 endif()

 include(FetchContent)
-FetchContent_Declare(kompute GIT_REPOSITORY https://github.com/KomputeProject/kompute.git
-    GIT_TAG 1344ece4ac278f9b3be3b4555ffaace7a032b91f) # The commit hash for a dev version before v0.9.0. Replace with the latest from: https://github.com/KomputeProject/kompute/releases
+FetchContent_Declare(kompute GIT_REPOSITORY https://github.com/hungrymonkey/kompute.git
+    GIT_TAG 9eac80f048fb24594ef7d0f2005aed2bf4c6f897) # The commit hash for a dev version before v0.9.0. Replace with the latest from: https://github.com/KomputeProject/kompute/releases
 FetchContent_MakeAvailable(kompute)
 include_directories(${kompute_SOURCE_DIR}/src/include)

src> ls
CMakeFiles  cmake_install.cmake  kompute_array_mult  Makefile
doof@steamdeck:~/gitrepo/kompute/examples/array_multiplication/build/src> ./kompute_array_mult
[Nov 25 2022 20:15:14] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/Manager.cpp:339] Using physical device index 0 found AMD Custom GPU 0405 (RADV VANGOGH)
[Nov 25 2022 20:15:39] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/include/kompute/Algorithm.hpp:50] Kompute Algorithm initialising with tensor size: 3 and spirv size: 319
[Nov 25 2022 20:15:11] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/Algorithm.cpp:371] Kompute OpAlgoCreate setting dispatch size
[Nov 25 2022 20:15:11] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/Algorithm.cpp:385] Kompute OpAlgoCreate set dispatch size X: 3, Y: 1, Z: 1
[Nov 25 2022 20:15:30] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/Sequence.cpp:51] Kompute Sequence command now started recording
[Nov 25 2022 20:15:30] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/Sequence.cpp:77] Kompute Sequence command recording END
[Nov 25 2022 20:15:30] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/Sequence.cpp:218] Freeing CommandBuffer
[Nov 25 2022 20:15:30] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/Sequence.cpp:234] Destroying CommandPool
[Nov 25 2022 20:15:30] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/Sequence.cpp:251] Kompute Sequence clearing operations buffer
Output: {  0  4  12  }
[Nov 25 2022 20:15:14] [info] [/home/doof/gitrepo/kompute/examples/array_multiplication/build/_deps/kompute-src/src/Manager.cpp:123] Destroying device

@hungrymonkey not sure I understand your last few comments - are you saying that you managed to get it to work with the fixes in the PR or without the fixes in the PR?

I've reproduced and fixed - thanks for the update

@axsaucedo
I am saying there are two separate issues. The way you manage cmake seems like a build and release issue, so I will not handle it.

I don't understand what you mean, what do you mean by build and release issue? Or what do you mean by handling it?

https://github.com/KomputeProject/kompute/blob/637bfb1bc044d5e9a639a5ef975ae4ce4b82a71c/examples/array_multiplication/CMakeLists.txt#L29
cmake_minimum_required(VERSION 3.20)
project(kompute_array_mult)

set(CMAKE_CXX_STANDARD 14)

# Set a default build type if none was specified
# Based on: https://github.com/openchemistry/tomviz/blob/master/cmake/BuildType.cmake
set(DEFAULT_BUILD_TYPE "Release")

if(EXISTS "${CMAKE_SOURCE_DIR}/.git")
    set(DEFAULT_BUILD_TYPE "Debug")
endif()

if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
    message(STATUS "Setting build type to '${DEFAULT_BUILD_TYPE}' as none was specified.")
    set(CMAKE_BUILD_TYPE "${DEFAULT_BUILD_TYPE}" CACHE STRING "Choose the type of build." FORCE)

    # Set the possible values of build type for cmake-gui
    set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
endif()

if(WIN32) # Install dlls in the same directory as the executable on Windows
    set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
    set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
endif()

include(FetchContent)
FetchContent_Declare(kompute GIT_REPOSITORY https://github.com/KomputeProject/kompute.git
    GIT_TAG 1344ece4ac278f9b3be3b4555ffaace7a032b91f) # The commit hash for a dev version before v0.9.0. Replace with the latest from:
## This commit needs to be changed to be compatible with gcc12
https://github.com/KomputeProject/kompute/releases
FetchContent_MakeAvailable(kompute)
include_directories(${kompute_SOURCE_DIR}/src/include)

# Add to the list, so CMake can later find the code to compile shaders to header files
list(APPEND CMAKE_PREFIX_PATH "${kompute_SOURCE_DIR}/cmake")

add_subdirectory(shader)
add_subdirectory(src)

The array_multiplication example code will fail to compile because the cmake fetches an old version of kompute on github instead of my local machine.

I will write a separate bug report.

https://github.com/KomputeProject/kompute/issues/313

@hungrymonkey got it, thanks for the context, I'll have a look at adding an option to allow this built from local repo


fix(breakpoints): add unit to theme and use theme.breakpointsUnit in …

Addresses https://github.com/pricelinelabs/design-system/issues/338

Codecov Report

Merging #339 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #339   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          41     41
  Lines         475    478    +3
=====================================
+ Hits          475    478    +3

Impacted Files
Coverage Δ

src/theme.js
100% <100%> (ø)
:arrow_up:

src/Hide.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Fix link to VirtualAlloc2 in MapViewOfFile3 documentaiton.

Fix link to VirtualAlloc2

@neerajksingh : Thanks for your contribution! The author(s) have been notified to review your proposed change.


STYLE: Rename remote module maintenance script

Rename remote module maintenance script to better reflect its purpose.

PR Checklist

[ ] Makes breaking changes
[ ] Makes design changes
[ ] Adds the License notice to new files.
[ ] Adds Python wrapping.
[ ] Adds tests and baseline comparison (quantitative).
[ ] Adds test data.
[ ] Adds Examples to ITKExamples
[ ] Adds Documentation.

Refer to the ITK Software Guide for
further development details if necessary.

As requested in https://github.com/InsightSoftwareConsortium/ITK/pull/658#discussion_r270646355.
@thewtex I added a trailing s at the end of the filename. As said in a previous PR, at some point in time, the script will go over all remote modules and make the changes without requiring the paths as input parameters. Please let me know if you still think the singular name is more appropriate.

Awesome, thanks @jhlegarreta ! Looks good -- the more specific Remote over Files should help new contributors apply the script :-)


Author change doesn't seem justified

@energynumbers I've noticed that the info about the author of this App has changed. I do not find the change reasonable.

Hi Olex.
Right now, I'm the person that people should be contacting for support & questions about this.
This package isn't going onto npmjs, the "author" field doesn't mean anything about copyright, and is useful to us as a field where EPMG folk can look to find out who they need to talk to about managing this software.
I'm happy to add a contributor field and list you there. I'm hugely grateful for all the work you did in setting these things up.

Thanks @energynumbers. Well, maybe you can add a current maintainer field and put the contact info and your name there? Indicating yourself as author is at minimum misleading.


Display Windows timezone

Currently the Local zone entry shows the TZDB zone id. Use a converter to show both the TZDB id and the corresponding Windows id, when available.

The logic should be as follows:

if the zone is TZDB, find the mapped Bcl zone and display both ids
if the zone is Bcl, try to find the mapped Tzdb zone and display

The resultant string should display the primary zone first, then the secondary zone.


Global Code Refactoring/Clean-up

Make code easier to use/reuse especially for new contributors.

Cleanup code
Use/create utility methods where possible

(Part has been done in #3175 and #3263)

Please resolve merging conflict.


Make default sequence increment 1 when sequence created explicitly

A sequence created by UseSqlServerSequenceHiLo will still have an increment (block size) of 10. If a sequence is created explicitly and then used for HiLo, then whatever the increment value set in the explicitly created sequence will be used.

:shipit:

Merged


 Are you able to repro it consistently?

I was yesterday, but can't today. Maybe it's related to https://github.com/microsoft/vscode/issues/94221, which I got consistently yesterday but this morning seems fine.

ok. Closing this.


Format Document not using tab size of 3

Issue:
When formatting my C# file, it does not appear to properly get the indentation level I configured. It properly uses spaces instead of tabs, however it puts 4 spaces when all languages have 3 specified.
System information:

OS: Windows 10 Pro 1709 (16299.248)
Notepad++ installer used (latest from downloads page at time of posting): https://notepad-plus-plus.org/repository/7.x/7.7/npp.7.7.Installer.x64.exe
CS-Script version (latest from this repository at time of posting), acquired via Plugins Admin: 1.7.24

Reproduction steps: https://www.screencast.com/t/2MnRTThoRigJ

Minimalist install, with Plugins Admin
Once installed: Settings -> Preferences -> Language -> [Default]

Tab size: 3
Replace by space: Checked

Ensure every language has "Use default value" checked (I only needed to fix this for python and yaml)
Close and reopen notepad++
Ensure the indent settings were preserved
Plugins -> Plugins Admin

Check "CS-Script - C# Intellisense" version "1.7.24"
Click Install, and let it restart notepad++

Notice the warning about auto-complete (https://github.com/oleg-shilo/cs-script.npp/wiki/Dealing-with-Notepad††-native-auto-complete)
Settings -> Preferences -> Auto-Completion

Uncheck "Enable auto-completion on each input"
Uncheck "Function parameters hint on input"

Close and reopen notepad++
Ensure the indent settings were preserved
Type the following into a new file, and save to C:\temp\Test.cs

using System;

namespace Foo
{
class Bar
{
public static void main(String[] args)
{
Console.WriteLine("Press Enter to continue...");
Console.ReadLine();
}
}
}

Edit -> Select All
Plugins -> CS-Script -> Format Document
Notice it uses four spaces for indentation

Hi Antony,
This is a tricky issue to solve.The problem is that C# formatting is done by the external component based on Roslyn C# syntax engine, which has nothing to do with N++. Thus the there is no way for the formatter to discover the current N++ setting. Thus the formatting is done according default Roslyn settings that reflect styling preferences commonly accepted in C# community. Which are... "4 spaces instead of tabs".
Nevertheless it is a valid feature request and I will try to integrate Roslyn settings with N++ ones.

Hi Antony,
This is a tricky issue to solve.The problem is that C# formatting is done by the external component based on Roslyn C# syntax engine, which has nothing to do with N++. Thus the there is no way for the formatter to discover the current N++ setting. Thus the formatting is done according default Roslyn settings that reflect styling preferences commonly accepted in C# community. Which are... "4 spaces instead of tabs".
Nevertheless it is a valid feature request and I will try to integrate Roslyn settings with N++ ones.


can you share link to  Agent Dingo

can you share link to  Agent Dingo

https://github.com/BeastByteAI/agent_dingo/tree/pipelines


Camera flow

A user should be able to take photos with the AR Camera on supported devices (probably iOS 13+ in case we decide to include the latest model, tbd on minimum Android OS). Users with older devices should have a fallback to a regular camera where they can still take photos within the iNat mobile app.

[ ] AR camera
[ ] Only show vision camera option for iOS 13+ and Android 12+ (for now)
[x] Regular camera as fallback (probably this library)

Vision camera is going to be a whole collection of issues, I suspect, so I'm going to close this.


Paella 7 custom themes

This PR adds the new paella feature (skins) to Opencast.
With this, each tenant can configure the paella skin/theme (use other colors, or other icon set)
Your pull request should…

[x] have a concise title
[ ] close an accompanying issue if one exists
[x] be against the correct branch
[x] include migration scripts and documentation, if appropriate
[x] pass automated tests
[x] have a clean commit history
[x] have proper commit messages (title and body) for all commits

Should this go into r/14.x?

I agree with Greg! This should go to 14.x

I agree with Greg! This should go to 14.x

Done!

@mliradelc, @karendolan Can you review it?

@miesgre  do you have time today to check for @mliradelc  comments? We are going to release Opencast 14.x in about 6 hours.

I tried the skin PR, and I don't know why, but I changed several colors from the theme, and nothing changed. I tried with custom_theme_example/theme.css and custom_theme.css, but no one affects the colors from the player.
I tried also disabling the browser cache without avail.

@stefanosgeo, @mliradelc, I updated the documentation.
To test it you need a to create a custom theme. As an example there is a basic theme called custom_theme_example.
Rename the folder to custom_example or change the config.json file the opencast.theme property to the folder name.
You can change the colors or icons to test it.

Thanks for the changes.
I'm Testing right now :)

@mliradelc You can find the default opencast theme here: https://github.com/opencast/opencast/tree/9294dbb6cf966695d5e4cb7a9dbb406347b83a20/modules/engage-paella-player-7/public/default_theme
but it is embedded in the paella7 bundle. It is used when no custom theme is defined or there is an error loading the resources.

@mliradelc You can find the default opencast theme here: https://github.com/opencast/opencast/tree/9294dbb6cf966695d5e4cb7a9dbb406347b83a20/modules/engage-paella-player-7/public/default_theme but it is embedded in the paella7 bundle. It is used when no custom theme is defined or there is an error loading the resources.

I supposed that the default theme was in the etc files, but is inside the jar bundle!


Is the current docker image able to get the data from FRITZ!OS 7.81?

My Container log is giving me a lot of error messages.
For example:
time="2024-07-11T21:52:25Z" level=error msg="Can not load data.lua for data.ramusage.series.2.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:25Z" level=error msg="Can not load data.lua for data.usbOverview.devices.*.partitions.0.totalStorageInBytes: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:26Z" level=error msg="Can not load data.lua for data.usbOverview.devices.*.partitions.0.usedStorageInBytes: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:31Z" level=error msg="Can not load data.lua for data.drain.*.actPerc: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:31Z" level=error msg="Can not load data.lua for data.drain.*.lan.*.class: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:32Z" level=error msg="Can not load data.lua for data.cputemp.series.0.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:32Z" level=error msg="Can not load data.lua for data.cpuutil.series.0.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:32Z" level=error msg="Can not load data.lua for data.ramusage.series.0.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:32Z" level=error msg="Can not load data.lua for data.ramusage.series.1.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:33Z" level=error msg="Can not load data.lua for data.ramusage.series.2.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:33Z" level=error msg="Can not load data.lua for data.usbOverview.devices.*.partitions.0.totalStorageInBytes: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:33Z" level=error msg="Can not load data.lua for data.usbOverview.devices.*.partitions.0.usedStorageInBytes: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:34Z" level=error msg="Can not load data.lua for data.drain.*.actPerc: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:34Z" level=error msg="Can not load data.lua for data.drain.*.lan.*.class: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:34Z" level=error msg="Can not load data.lua for data.cputemp.series.0.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:34Z" level=error msg="Can not load data.lua for data.cpuutil.series.0.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:34Z" level=error msg="Can not load data.lua for data.ramusage.series.0.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:35Z" level=error msg="Can not load data.lua for data.ramusage.series.1.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:35Z" level=error msg="Can not load data.lua for data.ramusage.series.2.-1: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

time="2024-07-11T21:52:35Z" level=error msg="Can not load data.lua for data.usbOverview.devices.*.partitions.0.totalStorageInBytes: error decoding SessionInfo: XML syntax error on line 73: element <meta> closed by </head>"

I've the same error message.
FritzBox 7490
FritzOS 7.59

Same issue on the new FRITZ!Box 7690.
Would love to continue using this awesome exporter :)
Praying for support getting added.
Cheers


App randomly freezing and closing

Describe the bug
App randomly closes after running for a couple of hours. Usually takes a long time to freeze, but sometimes freezes and closes after a few minutes running. I executed it in the terminal for logs and accused Segmentation Fault when it closed.
Screenshots
This is the messages shown in the terminal when I executed it, including the Segmentation Fault error:
$ pomatez -v
10:02:04.991 › Checking for update
10:02:05.077 › Error: Error: ENOENT: no such file or directory, open '/snap/pomatez/2/resources/app-update.yml'
(node:19980) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/snap/pomatez/2/resources/app-update.yml'
(node:19980) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:19980) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Segmentation fault

Desktop:

OS: Linux Mint 18
App Version: 1.1.0
Installer Used: Snap

Thanks for this @joao18araujo .
I will try to investigate why this happened as soon as I can.


Here we go again

Ensure we don't try to build a plot if we don't have data
Update package-lock.json and binary files
WIP

Codecov Report
Patch coverage has no change and project coverage change: -0.06 :warning:

Comparison is base (ae1fdde) 85.00% compared to head (e961828) 84.94%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #401      +/-   ##
==========================================
- Coverage   85.00%   84.94%   -0.06%
==========================================
  Files          29       29
  Lines        3621     3621
==========================================
- Hits         3078     3076       -2
- Misses        543      545       +2

Flag
Coverage Δ

cpp
84.94% <ø> (-0.06%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 4 files with indirect coverage changes

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


correct some translation

Correct some translation & added missing translation
fix #286

Note: this PR introduced a bug (typo in locale resource key):
https://github.com/readium/readium-desktop/issues/431


"Checkout" should be "check out"

The git docs use "check out" except when referring to the command itself: https://git-scm.com/docs/git-checkout

We use Checkout in VSCode core, GitHub for Visual Studio is using Checkout as well.
@shana may I have your opinion on this?

https://writingexplained.org/checkout-or-check-out I think it's a pretty minor thing but I think "Git: Checkout to..." in vscode is also technically wrong.

Hmmmm, let me see what our style guide says on this...

So on GitHub we use "check out" as a verb, and only use "checkout" when talking about the command or if talking about a specific feature with that name (like if we named a feature "the checkout button"). I don't know if the VS docs team has different guidelines for that usage tbh.


ISPN-11284 Make the containerized server timeout configurable

https://issues.redhat.com/browse/ISPN-11284

Thanks @tristantarrant


Parse special characters

Hi, I don't read special characters like ampersand; i.e. "http://domain.com?param1=aaa&param2=two

"

Looking at it now. I'll let you know once I figure out the bug.

The issue looks to be caused by the xml parsing library I'm using. It's parsing the URL string into two separate strings at the ampersand and my code is only picking up the first one. I'll work on a fix but it may take me a couple of days, depending on my work schedule. Thanks for pointing out this bug.

I published a new version (0.0.3) to account for this issue. Please update your dependencies and try again. Let me know if you have any further issues.

Thank you :)


Added ipad/left click support

Minor alteration to allow left-click and ipad support.

@glaidler changes look good. Can you check the notes I put and revert the unnecessary format changes before we merge this in?

No problem will do.  Was my ide being "helpful".
G
http://accelerata.co.uk http://accelerata.co.uk
tel: 01392 580154
mob: 07968 472239
skype: glaidler
On Fri, Apr 22, 2016 at 9:16 AM, Jose Taira<EMAIL_ADDRESS>wrote:

@glaidler https://github.com/glaidler changes look good. Can you check
the notes I put and revert the unnecessary format changes before we merge
this in?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Templarian/ui.bootstrap.contextMenu/pull/57#issuecomment-213318242

Hi - formatting undone.

Found some issues while testing this out. ReferenceError: $ is not defined seems to be problematic not just in this case. I'll push a fix for this issue later, but for now the more pressing issue is the click.
I think in general, we should be able to specify custom events that openMenus triggers to as requested in https://github.com/Templarian/ui.bootstrap.contextMenu/issues/43
Seems like it'd be easy to update the implementation to be more customizable.
Property name should be context-menu-custom-trigger

Yes - this makes total sense i will adjust.
G
http://accelerata.co.uk http://accelerata.co.uk
tel: 01392 580154
mob: 07968 472239
skype: glaidler
On Fri, Apr 22, 2016 at 9:44 AM, Jose Taira<EMAIL_ADDRESS>wrote:

Found some issues while testing this out. ReferenceError: $ is not defined
seems to be problematic not just in this case. I'll push a fix for this
issue later, but for now the more pressing issue is the click.
I think in general, we should be able to specify custom events that
openMenus triggers to as requested in #43
https://github.com/Templarian/ui.bootstrap.contextMenu/issues/43
Seems like it'd be easy to update the implementation to be more
customizable.
Property name should be context-menu-custom-trigger
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Templarian/ui.bootstrap.contextMenu/pull/57#issuecomment-213331799

Already fixed in https://github.com/Templarian/ui.bootstrap.contextMenu/pull/66
The PR seems to have become unnecessary.


Subnet broadcast

We wish to be able to send packets to all nodes on a particular subnet. For this purpose, we are going to reserve the highest address within each subnet to broadcast, just like IP does. This would work for any BUS where it's possible to listen for multiple addresses. That means CAN and ZMQhub currently.

[x] Put nodeid on each interface
[x] Put netmask on each interface
[ ] Make router respond (incoming) to multiple addresses
[ ] Add additional CAN filter for the broadcast address
[ ] Automatically add link local routes to the routing table
[ ] Limit smallest subnet size to 4 nodes (network, node 1, node 2 and broadcast)

We should figure out, how we respond to broadcast messages. I just made the router respond to broadcast traffic and that works, however when i send out a ping message to the broadcast address. Their response comes back from the actual node addresses. Which the PING client doesn't expect. I guess it's already doing the correct by using the address of the incoming interface as the outgoing id. So maybe it's a question of writing the services that work with broadcast, to accept from any node on that port number. However that is not something CSP was ever setup to be able to do... Another option would be to respond from the broadcast address too. That would work. But pretty useless as the pinging the bradcast address would just result in a lot of useless replies all coming from the same address...
When i come to think about it. We might add a flag to the connection to only match on the incoming port number, since outgoing connetions use ephemeral ports, nobody else should be responding to that. Today both the port number and source adddress needs to match outgoing in order to get a connection match. Let me try that out.


Always preserve const enums in the Jakefile

It's part of our base tsconfig, but was optional in the Jakefile. The discrepancy actually causes jake release runtests to fail (as we require preserved const enums to run correctly), as preserveConstEnums was only locked to true for debug builds.
TBQH, I'd like to remove the useDebugMode flag entirely (meaning every build is the same as a release build), but that necessitates fixing up soucemaps after concatenating the copyright.

@mhegazy They are preserved in tsserver.js right now.

@mhegazy They are preserved in tsserver.js right now.

then we should remove them :)

@mhegazy tsserver.js could load language server plugins... and those plugins could access the global ts provided by tsserver... and those plugins could expect the enums to be available (like the .d.ts says they will be), right?

good point. did not think of the plugins scenario.

@mhegazy So then we can preserve const enums in all builds all the time to remove any debug/release build distinction? 🐱 (It's what our tsconfig already says, so it is how gulp behaves - jake is just overriding that)

We really wanna keep it this way for tsc.js. we added the const enum feature to make tsc.js smaller in size.


PWA – workbox swDest options should be reflected in the app.js

Version
3.0.1
Reproduction link
https://github.com/Hiswe/test-vue-cli-pwa
Node and OS info
Node 8.11.4  / yarn 1.7.0 / MacOS 10.13.5
Steps to reproduce

clone the repo
yarn install
yarn start

go to https://<IP_ADDRESS>:8080
What is expected?
The application should load the service worker named pouic-service-worker.js
What is actually happening?
The application  load the service worker named service-worker.js

The purpose is to be able to have multiple service-worker running on the same domain.
It's very useful while developing & testing on a localhost.
I haven't tried it yet, but I think it's also the case when running a vue-cli dev server. the service worker name is hardcoded here

My bad…
Just need to update registerServiceWorker.js…


HighDPI issues

Windows 11 again -> When using a 200% display scale, the window dimensions api breaks. Basically SetSize does not take the scale into account, and my mouse cursor coordinates are also not taking that into account. I end up having a window which is too small, and a resize behavior which resizes only half the resolution. If SetSize would take the scale into account and multiply the values, this problem would be gone.

Looks like PhotinoNET.Monitor structure should have Scale property.
In theory this should work:

GetScaleFactorForMonitor  function for Windows
scale-factor property for Gdk
backingScaleFactor property for Mac

Thanks for this suggestion. We will add this to our backlog, but haven't determined its position in our priority queue yet.

It should also somehow address a window being moved from one screen to another with a different DPI setting.

Here is some usage code with some comment about whats going wrong:
    private async Task ObserveScale(CancellationToken token)
    {
        double initialRatio = await JsRuntime.InvokeAsync<double>("eval", token, "devicePixelRatio");
        double initialDpi = App.MainWindow.ScreenDpi;
        double baseDpi = initialDpi / initialRatio;
        double currentDpi = baseDpi;

        while (!token.IsCancellationRequested)
        {
            // TODO The library does not expose yet whether we are still resizing or moving the window.
            // TODO 1. If the dpi change is triggered by resizing across monitors, this logic will glitch.
            // TODO    The solution would be to add an event to the library to inform when resizing starts and ends.
            // TODO    And while a resize is in progress, we should skip this logic.
            // TODO 2. If the dpi change is triggered by moving the window across monitors, this logic will also glitch.
            // TODO    This is mainly because the library seems to cache the old window size while moving.
            // TODO    This causes the library overwriting the new size with the old size.
            if (Math.Abs(App.MainWindow.ScreenDpi - currentDpi) != 0)
            {
                double currentRatio = currentDpi / baseDpi;
                double targetRatio = App.MainWindow.ScreenDpi / baseDpi;
                double factor = targetRatio / currentRatio;

                Point minSize = App.MainWindow.MinSize;
                Size currentSize = App.MainWindow.Size;

                // TODO MinSize appears to be always 0,0. That is a library bug, remove when fixed in library!
                if (minSize is { X: 0, Y: 0 })
                    minSize = new Point((int)(Program.MinWidth * currentRatio), (int)(Program.MinHeight * currentRatio));

                App.MainWindow.MinSize = new Point((int)(minSize.X * factor), (int)(minSize.Y * factor));
                App.MainWindow.Size = new Size((int)(currentSize.Width * factor), (int)(currentSize.Height * factor));

                currentDpi = App.MainWindow.ScreenDpi;
            }

            await Task.Delay(TimeSpan.FromMilliseconds(100), token);
        }
    }

@IceReaper @Andersen27 do we have enough information to cobble together a PR? I'm working to get up to speed on this code base, definitely not my area of expertise, but I may also be able to contribute. I think this is a critical defect, undermining lots of important use cases.
May I ask if this is this just a matter of putting in the time? Or are there unknowns here that still need to be solved? @Andersen27 proposes a pretty compelling roadmap to having a Scale property on PhotinoNET.Monitor, this would seem to give us a decent running start..

PR 1: https://github.com/tryphotino/photino.Native/pull/128
PR 2: https://github.com/tryphotino/photino.NET/pull/175

Pull request was merged into debug branch.


Windows compatibility

The bot does not build on Windows due to termion.

Another problem is openssl, used only to generate RSA keys... Maybe one day ring will support RSA generation.


Help me bikeshed the gauge look

You can see a demo of the current theme for various levels of OS/unicode/color support here:
https://twitter.com/ReBeccaOrg/status/701336143686578176
Or try running demo.js from the repo.  2.0, which has this is in beta. Right now changing this up is easy and cheap, so help me paint this bikeshed.

Mentioned elsewhere:
https://github.com/sindresorhus/elegant-spinner
https://github.com/helloIAmPau/node-spinner/blob/master/index.js#L13-L32

Hmmm, maybe there could also be some sort of percentage display?
Being able to define spinner animations could definitely be cool. I quite like elegant-spinner. Could even be configurable in some npm config?
--
I'm quite wondering how it might be best to deal with sub-jobs, or concurrency. pnpm has a pretty cool display of concurrency, for example. Perhaps that is out of scope though.
I suppose to some degree, sub-jobs is up to the implementing application to handle correctly?

Probably out of scope for this module yeah, since this is just about drawing bars on the screen. npm has a pretty good handle on what's going on via are-we-there-yet trees, but we aren't exposing that currently. TBH, I'm not actually convinced how valuable that is.  npm side the main thing I'd like to see is real network-layer support. That is, I'd like it to be using are-we-there-yet stream objects to track download completion instead of just starting a timed spinner.

If we end up really wanting to track concurrent jobs we might also look at supporting multi-line statuses.
The advantage of single line status areas is that you can update them without using any ansi codes– just CR and go.

I'd like to report on Win 7 (CJK code page) the new gauge seems to work on default cmd.  Though there is no color. I do not know if this is intentional.
On sidenote I also tested the new gauge on a console emulator (i.e. ConEmu). Here new gauge lines keep printing one after another unless the current theme is 'nocolor'.

By the way, running demo.js requires a dependency which is not in package.json: signal-exit.

I'm a big fan of the elegant spinner for terminals that support unicode (using braille characters), I don't have a strong preference for the ascii spinner.
Are we permanently moving the bar to the left? If so :+1: since that was a pain point with v1 where the text would get obfuscated by the progress bar.
The new spinner seems to work fine with the ambiguous width option, I'll give the demo a spin on some of my VMs when I get to it :)

@gillesdemey Yeah, the braile spinners are keen, but mac only. But we can actually do that now.

@ongtw123 Thanks for the report! I'll do some testing in ConEmu. Also you're totally right about ░ not belonging in a non-unicode theme.

Last time I tested, the braille characters worked fine on Ubuntu. Not too sure about other distros.

It was Ubuntu I last tested on, but it was over a year ago so it may be getting better.

I'm not opposed to using braille spinners on unicode-aware Linux distros if the support is there (I just want to avoid too many people seeing � in the installer =p).

Ok, to update the "can we use fancy braille on Linux distros" thread:
I've tested on the latest Ubuntu and Fedora. They're quite lovely on the former and super ugly on the latter (due to font selection).
But there's a further wrinkle which will means that this theme can't be the default for Ubuntu:
If I'm sshed into an Ubuntu box, there's no way to know what unicode my terminal will support.
Overriding themes w/ the new gauge is easy (and they're named now, so you can say you want the colorBrailleSpinner theme and get that). Access to theming will be exposed all the way up the chain with it, so expect that to show up in npmlog and npm when we integrate this version.

@yongtw123 I can't reproduce your issue with ConEmu– can you try again with the latest updates?

@iarna Awesome! The ASCII themes seem to work correctly on my system and ConEmu. Thanks for the update.
ConEmu

Default CMD

Ok, this all landed and is looking good. I'm going to close this and we can open something new if we want to iterate further.


 So I'm currently doing this to make it very long which kind of disables the automatic completions:
(setq copilot-idle-delay (* 60 60 10))
I propose it could be
(setq copilot-idle-delay -1)
which turns the automatic completions completely off.

In your case, you may not want to enable copilot-mode.
Also see "Option 2: Manually provide completions" section in README for reference.

I see. Thanks!

It seems to me copilot-complete doesn't work when copilot-mode is disabled. What I have done is enable copilot-mode and add a fn to disable predicates that always return true:
(add-to-list 'copilot-disable-predicates #'(lambda () t))

Experiencing same as @xmatos-so here. Should we reopen the issue?


refactor: restructure unime/src-tauri/tests/fixtures folder for scalability

Description
Divide the folder up in subfolders respective to their relevant test files in the unime/src-tauri/tests/tests folder.
Motivation
Currently the fixture folder is not set up in a scalable way and it is bound to get cluttered.
Resources
No response
To-do List

[ ] Divide the folder up in subfolders respective to their relevant test files in the unime/src-tauri/tests/tests folder.
[ ] Fix old, incorrect paths in the test files.

 refactor: restructure unime/src-tauri/tests/fixtures folder for scalability


No published analyzer available for language version 2.13.0"

[WARNING] json_serializable:json_serializable on lib/http/rest_client.dart:
Your current analyzer version may not fully support your current SDK version.
Please try upgrading to the latest analyzer by running flutter packages upgrade.
Analyzer language version: 2.12.0
SDK language version: 2.13.0

@wenbo-ya can you please update the bug description (which currently is 100% template text)?

@bwilkerson have we published an analyzer compatible with Dart 2.13.x?

@mit-mit - these messages are automatically kicked out by package build, are super noisy, and are not de-duped. I've been triaging them to the area-build area.

Analyzer 1.0.0 understands the current language version to be 2.13.0:
$ grep -rn " _currentVersion = '2" ~/.pub-cache/hosted/pub.dartlang.org/analyzer-1.0.0
/Users/srawlins/.pub-cache/hosted/pub.dartlang.org/analyzer-1.0.0/lib/src/dart/analysis/experiments.g.dart:11:const _currentVersion = '2.13.0';


Show seconds and just now

Hi,
The showing of seconds (30 seconds ago, N seconds ago and etc.) and just now is lacking in this module.

Sorry, _"X seconds ago" is not a goal of this library. It's fuzzy timestamps for a reason, and per-second granularity doesn't match that goal.


Review the grammar and punctuation guidance

Summary
Content style
Final version of the guidance with images written, reviewed and approved

This work will be undertaken in the wider content style review.


Ability to open sheet on mount

Right now there is no real way to mount the sheet in opened state. We have to open it programmatically.
A prop like openOnMount would be nice so the sheet opens automatically when mounted to. I personally want to use this so I can have a route that just have the TrueSheet and it opens when navigating to that screen.
Right now I can do a slight workaround like:
 const hasMounted = useRef(false);

  useEffect(() => {
    setTimeout(() => {
      if (hasMounted.current) return;
      hasMounted.current = true;
      handleOpen();
    }, 1000);
  }, []);

Which works but does not feel very good

I agree, timeout there is kinda weird.
As an alternative, if you're using react-navigation, you can subscribe to transitionEnd event so the sheet will show after the screen is shown.

Or if you want to open it without waiting for the screen to be shown, use useFocusEffect instead.

Using useFocusEffect does not work:

Hence why I had to use timeout :S
Subscribing to navigation.addListener('focus') gives the same error

Ah I see.. Yeah, you'll have to use transitionEnd  then. The sheet needs to be under a ViewController for it to present. I don't know about your use case but why not just present the sheet without having to use a screen?

I mean, I could of course do it as you say. Just using it regularly, mount on button press. What Im trying to accomplish though is to make it available via deepLinking. So in my case I would like the router: /partner/[id]/contact lead to this sheet. Which then is on its on route. In my prefered world react-navigation and this sheet would work together and  Screen in react-navigation would be able to render a TrueSheet.
But I think I will just have to present it without the use a of a screen

Ah.. What I would potentially do with that scenario is to use a route param instead of a dedicated empty screen. I think it's more "natural" and you don't have to navigate just to show a sheet.
Something like:
useEffect(() => {
  ;(async () =>  {
    if (id) {
      await sheet.current?.present()
      navigation.setParams({ id: undefined })
    }
  })()
}, [id])

Yes that is a good solution as well.
TransitionEnd works though, but there is a bit a of delay when mounting and dismounting the screen so a param is probably best :)
Thanks for the help, and great lib you got here! Really like it!

No problem. This got me thinking of adding a param on the present method to disable animation. Or something like an initialIndex so the sheet is shown by default. I'll add it when I get a chance :)

initialIndex would be really great, so that it mounts as soon as possible without having to invoke the present function