Remove unused golang.org/x/tools subpackages. [phab:D528]

Created by fromberger at 2015-09-28 21:18:50:
As of Go 1.5, the type-checker packages are now back in the standard library.

schroederc accepted this revision at 2015-09-28 21:19:21

schroederc required changes at 2015-09-28 21:19:32

schroederc wrote at 2015-09-28 21:19:50:
We still support Go 1.3.

fromberger wrote at 2015-09-28 21:21:33:

! In (earlier comment), schroederc wrote:
We still support Go 1.3.

None of the code currently in the repo is using this version. The indexer code that will be using the type-checker will still work on Go 1.3 source.

schroederc wrote at 2015-09-28 21:26:20:
I meant that our build environment supports Go 1.3 explicitly in http://www.kythe.io/contributing#dependencies and our Bazel rules.

fromberger wrote at 2015-09-28 21:31:27:

! In (earlier comment), schroederc wrote:
I meant that our build environment supports Go 1.3 explicitly in http://www.kythe.io/contributing#dependencies and our Bazel rules.

We'll have to consider how important that is, at some point. In any case, for the moment, this change does not introduce any conflicts with that assertion.

schroederc accepted this revision at 2015-09-28 21:31:49

fromberger closed via commit 25466e07e42edd77fdfb98c2f5b602fe190fd10d at 2015-09-28 21:34:13


add java BatchSynthesis

Purpose

...

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

[Feature]

@microsoft-github-policy-service agree

@tomj2ee thanks for contribute this! we are reviewing

/azp run

/azp run

/azp run


Project still uses prometheus_multiproc_dir environment variable in lower-case

To remain consistent with the Prometheus Python client it would be great if the uppercase version of this environment variable is used, as this is likely what people (like myself) would be trying to use based on the Prometheus documentation.
As per https://github.com/prometheus/client_python/releases/tag/v0.10.0

[CHANGE] The prometheus_multiproc_dir environment variable is deprecated in favor of PROMETHEUS_MULTIPROC_DIR. #624 - https://github.com/prometheus/client_python/pull/624

The lowercase version is still used in https://github.com/trallnag/prometheus-fastapi-instrumentator/blob/45d0ba1d03c565f2caca807b7df813e434c90ec8/prometheus_fastapi_instrumentator/instrumentation.py#L257

Fixed in #42 / #217


Is ASP.NET Core Identity a requirement?

Related to #79, I found while refactoring that ASP.NET Core Identity is pretty coupled with the admin services and controllers. I'm wondering, is Identity a hard requirement for the Admin UI, or could it be imaginable, from a design point of view, to have an Admin UI app without Identity. If so, what would it look like? Would there be fewer features, unavailable pages, etc?

I will create a flag in dotnet new template for excluding Identity, but currently it is a requirement.

During instalation will be exluding all projects related to Identity, views and controllers. It will be necessary to create new instance of STS without Identity as well - with in-memory users?

Any update on this feature

Do you need remove asp.net core identity from project?

Yes, I need to remove Asp.net core Identity from the project. I want to use my own User store bt still able to manage the clients


Registry doesn't work when scenes start later

Version

Phaser Version: v3.50.0-beta.1-FB

Operating system: Windows 10 Pro

Browser: Chrome, Mozilla,

Description
So on the example on Scenes/Registry Data Exchange we have the registry that we can send data through scenes. The way i use to add scenes is following:
game.scene.add('PreloadScene', PreloadScene, true);
game.scene.add('PlayScene', PlayScene);

So in my example code i've removed active: true from scenes and started SceneB from SceneA. When we use scenes like this, registry and events doesn't work proparly.

Example Test Code
var SceneA = new Phaser.Class({
    Extends: Phaser.Scene,
    initialize: function SceneA() {
        Phaser.Scene.call(this, { key: 'SceneA' });
        this.score = 0;
    },
    create: function() {
        this.scene.start('SceneB');
        this.registry.set('score', this.score);
        this.time.addEvent({
            delay: 500,
            callback: this.onEvent,
            callbackScope: this,
            loop: true,
        });
    },
    onEvent: function() {
        this.score++;
        this.registry.set('score', this.score);
    },
});
var SceneB = new Phaser.Class({
    Extends: Phaser.Scene,
    initialize: function SceneB() {
        Phaser.Scene.call(this, { key: 'SceneB' });
        this.text;
    },
    create: function() {
        this.text = this.add.text(100, 100, 'Monitoring Registry');
        this.registry.events.on('changedata', this.updateScore, this);
    },
    updateScore: function(parent, key, data) {
        this.text.setText('Score: ' + data);
    },
});
var config = {
    type: Phaser.AUTO,
    width: 800,
    height: 600,
    backgroundColor: '#2d2d2d',
    parent: 'phaser-example',
    //scene: [SceneA, SceneB]
};
const game = new Phaser.Game(config);
game.scene.add('SceneA', SceneA, true);
game.scene.add('SceneB', SceneB);

This issue has been mentioned on Phaser. There might be relevant details there:
https://phaser.discourse.group/t/registry-doesnt-work-when-scenes-start-later/7172/1

Hi @photonstorm yea i've also created that and ask about community ideas =)


HIBP API V3

There will be an API change.

My read, including the comments, was that there was no change for password checking, just for email checking.

Based upon the description at https://haveibeenpwned.com/API/v3#PwnedPasswords , and that the API v1 and v2 end date of August 18, 2019 has now passed and pass-pwned still works for me, I think the API change doesn't affect pass-pwned at this time.
Please let me know if you are having any problems with pass-pwned now the date has passed.


fix minor issues

Like the title

Thanks for your PR, I'm not in favor of adding .idea to .gitignore, what's your opinion?

Thanks for your contribution!


Build agent incorrectly selects Build Tools folder for vstest tasks when Build Tools is on the same or greater version than VS Pro

Hi,
I'm using TFS 2017 U3 with Build Agent 2.112.1. I have installed VS Professional 15.7.4 on build servers, also I have Build Tools installed (I had to go for VS Pro due to the VsTest for 2017 was not supported in Build Tools). Lately I have updated the Build Tools to the same 15.7.4 version and since my VsTest tasks started to fail with the message:

VisualStudio version selected for test execution : 15.0
[command]powershell -NonInteractive -ExecutionPolicy Unrestricted -file
D:\TfsBuildAgent_work_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.0.55\vs15Helper.ps1
Objs Version="<IP_ADDRESS>" xmlns="http://schemas.microsoft.com/powershell/2004/04"
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools
Objs
[command]wmic datafile where "name='C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe'" get Version /Value
No Instance(s) Available.

After some troubleshooting it turned out that the vswhere.exe gives back the correct location of VS, selecting the Professional one but the vs15Helper.ps1 takes the first one when found more for the same version and due to the path the Build Tools is preferred but that doesn't have the vstest.console.exe.

I think this should somehow considered, for now I have excluded that from the PS file as it won't support it:

return $instances |

            Where-Object { $_.Version.Major -eq 15 -and $_.Path -notlike "*BuildTools"} |

            Sort-Object -Descending -Property Version |

            Select-Object -First 1

Thanks,
Tibor Tompa

@tompatib thanks for reporting this, i think this is task not a agent problem, can you log an issue at https://github.com/microsoft/vsts-tasks?

Sure, thanks.


Adding addiontal Buttons before the preview button

Is it possible to add addional Buttons group before the preview button and not after the button?

Unfortunately, it is not possible for now. I'll keep this one open if someone want to tackle it as enchancement.

I made a commit which would do what i need. (Adding buttons to existing groups that are before the preview button)

@ckosmowski Thanks, i'll try to review it these week.

@yopbot The related PR is merged. The functionality is part of the plugin already.


Change variable name  not take effect in checkpoints

I want to load into one session different checkpoints of the same model. Like take step 10 and step 100
In order to avoid conflict name, I try to modify the variable name first, like change from
show_and_tell/model_init/emb:0 to show_and_tell_1/model_init/emb:0,
my input checkpoint with all varaibles starts with show_and_tell, and I want to modify it to show_and_tell_1
so I can load the two models at once.
Code like below, but the savec checkpoint.meta shows still show_and_tell/model_init/emb:0, what's wrong?
def reset_model_top_scope():
sess = tf.InteractiveSession()
meta_filename = ".".join([input_checkpoint, "meta"])
saver = tf.train.import_meta_graph(meta_filename)
saver.restore(sess, input_checkpoint)
scope = FLAGS.scope
out_scope = FLAGS.out_scope if FLAGS.out_scope else '%s_%d'%(scope, FLAGS.out_index)
output_checkpoint = FLAGS.output_checkpoint
with tf.variable_scope(scope) as topscope:
src_vars =[v for v in tf.all_variables() if v.name.startswith(topscope.name)]
out_vars = {out_scope + v.name[len(scope):v.name.rfind(':')]:v for v in src_vars}
tf.train.Saver(var_list=out_vars).save(sess, output_checkpoint)
sess.close()

well close it , since I find the name scope is not a problem, I can load step1 and step2 checkpoint in same session without having to change scope name.

To load model rename scope and save. Right now tensorflow 10.0 has problem with Saver. I see in the master, has commeted the assertion.
tensorflow/tensorflow/python/training/saver.py
In the following use case, it's possible to have restore_ops be called
# something else:
# - Build inference graph and export a meta_graph.
# - Import the inference meta_graph
# - Extend the inference graph to a train graph.
# - Export a new meta_graph.
# Now the second restore_op will be called "restore_all_1".
# As such, comment out the assert for now until we know whether supporting
# such usage model makes sense.
#
# assert restore_op.name.endswith("restore_all"), restore_op.name


About GainSelector class and gain_channel thresholds

Hello,
I've been trying to use the GainSelectorThresholds class from ctapipe.camera.calib and I found a couple of troubles that can make it a little inconvenient to use(or maybe I'm doing something worng, in that case I will be thankful to learn the proper way).
The first thing is that as it is defined, it searches for samples in the waveforms over a certain threshold in PHE, but waveforms are given in dc counts, so if  you use the waveforms directly from the events (in simtel files, for example), it will give a wrong result.
The default values  of the thresholds are read from ctapipe-extra/ctapipe_resources/gain_channel_thresholds.ecsv (and are in phe), and perhaps it would be better to have them in dc counts (or add a conversion factor for each camera definition). For example, for LSTCam 100 phe --> 4095 dc counts.
The other issue is that the function pick_gain_channel searches for high gain waveform values purely larger than the threshold (>), but this will never happen, since samples will saturate at that exact value. The condition should be substitued by >=.
Thank you very much!

I think this issue is fixed since a long time, please reopen if this still needs to be addressed.


Shiva aocc fix

creating PR to officially close it

fixed an alternate way
test case added to aomp smoke tests


Make geerlingguy/drupal-vm Docker image easy to use for single-site installations

Issue Type

Feature Idea

Summary
In #1356, I built a base drupal-vm Docker image, and so far it does a lot of things nicely, but there are a few issues that prevent me from saying "yes, this is a good start". I want to fix those issues before I start actually advertising the base image / Docker image build functionality from #1356. Namely:

[x] The php7.1-fpm service is dead when you docker-compose up. (Workaround for now is to run: docker exec drupal-vm service php7.1-fpm restart)
[ ] The default vhost (drupalvm.dev) is embedded in the image and isn't able to be changed unless you do an ansible-provision (really heavyweight), or log in and manually swap it out yourself.
[ ] Ditto for the location inside the VM where Drupal VM expects a Drupal codebase (currently it's /var/www/drupalvm/drupal/web—kinda verbose).
[ ] I need to document a real-world example use case (e.g. I have a Drupal codebase, and I put the docker-compose.yml file inside, then I ran commands X, Y, and Z and it was working...). I have it working with a couple of my small D8 sites right now, but it's a little janky.

All in all, it performs pretty well so far. Maybe I could wrap a few shell scripts inside the container so users could use like docker exec drupal-vm drush cr or something like that (and then power users could alias the docker exec drupal-vm part for ease of use).

For the first issue, with FPM not running on container start:
root@128d94d20d15:/var/log/mysql# service php7.1-fpm status
● php7.1-fpm.service - The PHP 7.1 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.1-fpm.service; disabled)
   Active: inactive (dead)
     Docs: man:php-fpm7.1(8)

For some reason it's not set as enabled. Going to boot up a fresh Drupal VM instance on Ubuntu to confirm whether it's enabled or disabled by default there... maybe it's a Debian issue?

Same thing inside a Vagrant/VirtualBox VM with the Debian 8 base box:
$ systemctl status php7.1-fpm
● php7.1-fpm.service - The PHP 7.1 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.1-fpm.service; disabled)
   Active: active (running) since Mon 2017-05-15 03:20:00 UTC; 26min ago
     Docs: man:php-fpm7.1(8)
 Main PID: 6170 (php-fpm7.1)
   Status: "Processes active: 0, idle: 5, Requests: 0, slow: 0, Traffic: 0req/sec"
   CGroup: /system.slice/php7.1-fpm.service
           ├─6170 php-fpm: master process (/etc/php/7.1/fpm/php-fpm.conf)
           ├─6171 php-fpm: pool www
           ├─6172 php-fpm: pool www
           ├─6173 php-fpm: pool www
           ├─6174 php-fpm: pool www
           └─6175 php-fpm: pool www

Testing on Ubuntu 16.04 now.

Not sure if you're still looking at this but I was curious to see what was done. In case you haven't seen it it looks to be that there's no entrypoint and the cmd is just bash. The systemd service isn't running since there's no entrypoint and the cmd is bash so you're just pretty much starting the process manually.

@derimagia - In this image's case, the docker-compose.yml example would set the entrypoint to launch systemd, which inside the container manages the starting of any configured services (which are enabled), and in the case of php7.1-fpm on Debian 8, it's not enabled for some reason—all the other enabled services come up fine.
I'm working on that issue (which seems to not be exclusive to Drupal VM) over in https://github.com/geerlingguy/ansible-role-php/issues/191 — Ansible's service module seems to work fine on Fedora, Ubuntu, and CentOS with systemd... but something is failing silently on Debian 8, at least with PHP-FPM from Ondrej's apt repository.

I see, I'm not used to those being flipped (shell being default, having to overwrite the process) but that's my fault for finding the compose. I know you're trying to do MVP now and if there's anything that needs to be done there let me know. Is running using systemd a permanent solution or was there a thought to eventually separate it out?

Also making a note since I didn't see it above, there were logs in the docker file for when it was created, we should probably clean those up (php-fpm said it started 2-3 days before I started the container)

@derimagia - Yeah, the intention right now is just to get Drupal VM 'tricked' into thinking a Docker container is a normal VM, using systemd or sysvinit to manage processes.
At some point in the future, components of Drupal VM will be parceled out and put in separate containers—however, I am not planning on doing all of that until the point where the end-to-end UX of Docker gets nearer the UX of a tool like Vagrant—and without me building (and having to maintain) layers upon layers of all the shims needed to do it today.
For an example of one of the images I've started playing around with separately, see docker-image-solr. But note that I am still not following what I believe is the mainline/conventional container approach there, as I'm working to make the transitional state from full VMs to containers more sustainable (e.g. I don't want people building ugly-as-all-get-out shell scripts inside Dockerfiles inside other shell scripts to do basic configuration management). Hopefully ansible-container bridges that gap... it's improved a lot in the last year, though I'm still not using it anywhere publicly.

Makes sense, a little disappointing but I understand not having time for it. I'll need to mess around with this. I know a lot of it is a bit different from what I've seen ansible being used for. One thing that would need to be done would be to move a lot of the configuration into the entrypoint as opposed to baked in, so the ansible scripts would essentially need to separate out the "installation" part and the "configuration" part.
Although I'm not sure if docker will ever evolve into what you're looking for exactly. For better or worse Docker doesn't really have any tools to help provision / create docker images, it just gives you lower level tools for it. docker-compose helps if you already have the images provisioned obviously but that's about it. They leave it out to third parties to make these (Which makes sense from their perspective I think) but makes it harder for people to learn how to actually do things like this. I do agree docker's UX is to be desired.
If you didn't see yet, https://github.com/moby/moby/releases/tag/v17.05.0-ce adds multi-build support which will definitely help with what you want. It's actually pretty neat.

One way to solve the virtualhost issue could be to integrate with https://github.com/jwilder/nginx-proxy — it's still hackier than I'd like, though. Throwing an additional proxy in front of Apache (or potentially Nginx) is a recipe for pain, in terms of little things that could go wrong with the request routing from host to nginx to container (for things like bigpipe, varnish, streaming requests, etc.).

Another possibility could be adding something like gotpl, which seems to follow Jinja2/Twig syntax in some ways, and would allow environment variable substitution similar to what Wodby does: https://github.com/wodby/nginx/blob/master/1.10/Dockerfile#L45
I just don't want to go too far down that route and diverge the Docker configuration setup from the Drupal VM proper configuration setup.

Grr... that first issue might not yet be solved...
root@5d04d77b57ce:/# service php7.1-fpm status
● php7.1-fpm.service - The PHP 7.1 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.1-fpm.service; disabled)
   Active: inactive (dead)
     Docs: man:php-fpm7.1(8)

Not sure if this is a problem but to help simplify config the ansible provision for building the container there could be 2 (mental) types of configuration - the ones that are configurable by drupalvm and the ones which are not. It changes some of the values and the other ones are left alone (or slightly modified if need be). Then on the entrypoint it just runs the templater (e.g. gotpl) to replace the remaining values.

Strangely, using the new composer docker-bake command, then saving the image (composer docker-save) results in an image that does, indeed, have php7.1-fpm running and enabled inside Debian 8. So there's some difference between the Dockerfile and the bake.sh script.

Yeah, there's a big difference between docker build & docker run.
build will not retain any state, even between commands whereas run will.
So for example you can't set an environment var in build -- export VAR1=test then use it in the next command, but you can with run.
Same goes for running services.

I think I might be hitting https://github.com/moby/moby/issues/1916 :/

Hmm, honestly you shouldn't ever really need privilege in build, what's the reasoning it needs it?

@derimagia a lot of things, like iptables configuration, requires certain privileges... if you're looking at Docker from the perspective of a crazy person who wants to make Docker work like a VM, then it's nice to be able to have privileged access :)
I'm not saying that's a good thing, mind you (though I don't consider it as bad and evil as Docker purists would paint it)... just that it makes things work identically between a full fledged VM and a Docker container. There's a reason why that issue has been open for 4+ years and has ~300 comments—it's a #dockerWTF imo that you can do more with docker run than docker build.

Having that would mess with portability, like you're doing right now. Running iptables goes past userspace and you're messing with things that expand it. Even if docker build supported the flag you would need to run it on each invocation of the container when running it, otherwise it wouldn't persist anyway.

Having that would mess with portability, like you're doing right now.

Somewhat... right now my solution is to disable the security/networking modifications Drupal VM would normally make, since it's assumed Docker will handle things like container networking.

I just got my local test site running and happy during a Drupal meetup tonight, so at least there's that—just pushed a commit which gets FPM to actually be running on container start, yay!
But this is definitely going to be 'experimental' for some time. It's a little clunky... but it's nice enough that I've already switched one of my other local sites from using Drupal VM with Vagrant to using a Dockerfile and docker-compose.yml, and not having any Drupal VM integration besides :)

Also reading through https://www.vagrantup.com/docs/docker/configuration.html ... could be possible to make the bridge to native Docker easier with Vagrant to layer itself between things. I'll see if it could be simpler/easier to go that route (even though one would need both Docker and Vagrant in this scenario).

I might want to split out into a separate issue the work of trying to use Docker + Vagrant, though... @thom8 what do you think? Since we're in the 'experimental' phase, I'm happy to work on a few different angles (but want to get it working with just Docker first, as a POC).

Yeah probably a good idea to split that out, I'd like to get to a stage where Docker was a drop in replacement for vbox in the current stack so it can be enabled in existing config.
But still think it would be best to get a Docker only solution stable then look at adding Vagrant support for backwards compatibility.
It's also important for advanced use cases to make sure it all works standalone.

@thom8 - Opened https://github.com/geerlingguy/drupal-vm/issues/1381 as a follow-up issue.

For the last two items:

The Apache vhosts configuration for Docker
How to get the MySQL data dir to persist

I'll leave them off for now, in order to get the already-working stuff 'shipped' in 4.5.0.
I've been using the Docker setups described in the updated docs for a few of my sites locally the past couple weeks, and those two issues haven't been as big of annoyances as I thought they'd be, so I figure we can wait for others to highlight things that aren't working great or could be low-hanging fruit.


[EPIC] Provide SDK support for new V2 UI

Problem/Concern
This is an epic that will be used to collect all tasks that need to be completed in order to enable the completion of the new V2 UI.  All of this is part of #820.

[ ] Default color in palette (first added), can’t be deleted (#979)
[ ] Figure out how to store and retrieve default colors, as a color palette, from the SDK (#1051)
[ ] Need to figure out dependencies tree when values changed (#1052)
[ ] Need to allow the UI to tell the SDK whether it is updating a AA or AAA value (e.g. a shade) (#1053)
[ ] Need to be able to save multiple themes (#1054)

Any new requirement for the UI should be added here after their respective issues are created.

Discussed with @evangk6 today.  We are thinking that a good approach would be:

divvy up these issues

Evan, @omesh-omg  and I will try to figure out #979 together

should be a good, isolated issue to get our feet wet with the SDK code

Evan and I will split the remaining 4, taking 2 each

Prepare each issue.  For each issue we need to:
i. investigate the issue
ii. resolve all questions, requesting input from Lise, others as needed
iii. come up with a design, identifying any dependencies that may need to be modified or created
iv. size the effort
Assign the development work
Implement the designs

Suggested order of code implementation once investigation and design phase is complete.  This is just a suggestion, but the idea is to unblock Omesh on the UI and to show progress.  To make the largest impact in the shortest amount of time.  But, of course, want to do things in the correct order.

Default color in palette (first added), can’t be deleted (#979)
Need to be able to save multiple themes (#1054)
Need to figure out dependencies tree when values changed (#1052)
Need to allow the UI to tell the SDK whether it is updating a AA or AAA value (e.g. a shade) (#1053)
Figure out how to store and retrieve default colors, as a color palette, from the SDK (#1051)

Please weigh in if you would like to suggest changes to this path.


Allow ivy-prescient to remember directories used in navigation

Currently, Ivy-prescient only remembers directories when they are part of an explicit action. However this means it provides no help when navigating a directory structure. This change makes it remember all directories even when they don't exit the ivy session and makes it more consistent. Let me know what you think.

Looks good to me; we just need to update stub/ivy.el for the byte-compiler. Thanks!

🎉


CPA attack key rank not converging to 0

Thanks a lot for open-sourcing the verilog source code and corresponding bitstreams. I followed the instructions for the basys3 board trace collection and performed the CPA using the provided scripts. However, I observed that the key rank after the CPA attack is more or less constant -- I should see a decreasing trend of key rank when number of traces are increased. I'm not sure what could be the issue for this behavior? can you please suggest some pointers to debug this.
Sequence of the steps I followed and my observations for each step:

program the basys3 board with the provided bitstream (temperature_experiments.bit)
(able to program the board, and made sure that SW15 is set to correct position).
start the trace collection. I used the following instruction to collect 40,000 traces: ./interface -k 0 -pt 1 -t 40000 -s -d traces_40k/
(trace collection process started after the sensor calibration. I see the following prompt suggesting sensor is calibrated and trace collection is about to start. 09C528D4FFFD1DB73BAB93DF5821B9F5max 109  best idc found 1 62 Trace : 0)
( trace collection took about 4hours without any errors. snapshot of the generated files. )

launch the attack with following command: python3 launch_attack.py -k e07f16bdb9e50346a2277cd382774270 -t ../basys3/sw/bin/traces_40k/sensor_traces_40k.csv -c ../basys3/sw/bin/traces_40k/ciphertexts.bin -nt 40000 -ns 256 -ss 1000 -o /home/ext/fpga-sensors/results-rds-40k
(attack was quite fast. Thanks to your scripts leveraging the GPU).
observations on the files generated post-attack:
keyrank_results.csv (I noticed that key rank is not improving with more traces. Attaching the results file and log files for reference.)

keyrank_results.csv
log.txt
log_errors.txt
What do you think could be the issue? any pointers are helpful.
Thanks.

Hello!
Thank you very much for looking into our code and opening that issue.
We suggest the following actions to pinpoint the exact error:

Visualize one (or a few) traces that you have recorded (this would be one row in the CSV file). Have a look at Figure 8 in our paper, where we show how traces recording AES encryptions look. When you visualize your traces, you should see a similar pattern: spikes in the negative direction of the y-axis. If the sensor output stays constant all the time and does not change, we know that the issue lies in the acquisition of the traces. One potential issue could be that the sensor is not correctly calibrated.

Each run of the main-CPA program appends the data to the final_kr/xxx.txt files (it does not delete the content of the previous runs but adds the content of the new run on top of it). Therefore, if the final_kr folder is not purged before every run (and the xxx.txt files deleted), the subsequent runs might process incorrect data.

A typical mistake is to confuse the master key with the last round key. For trace acquisition, key K1 from our paper is used. For the attack on the GPU, one needs the corresponding last round key (because the correlation is done with the last round key). However, it seems that you used the correct keys when executing the commands.

Please try the points above and get back to us so that we can guide you further!

I just thought of another possible issue that you might want to check first. In your case, the TRACE_FILE argument is set to a CSV file, but according to our README, it should be a binary file. It seems you may need to convert the .csv file into a .bin file first.
Please let us know so we can improve our README!

Hello!
Thank you very much for looking into our code and opening that issue.
We suggest the following actions to pinpoint the exact error:
1. Visualize one (or a few) traces that you have recorded (this would be one row in the CSV file). Have a look at Figure 8 in our paper, where we show how traces recording AES encryptions look. When you visualize your traces, you should see a similar pattern: spikes in the negative direction of the y-axis. If the sensor output stays constant all the time and does not change, we know that the issue lies in the acquisition of the traces. One potential issue could be that the sensor is not correctly calibrated.

2. Each run of the main-CPA program appends the data to the final_kr/xxx.txt files (it does not delete the content of the previous runs but adds the content of the new run on top of it). Therefore, if the final_kr folder is not purged before every run (and the xxx.txt files deleted), the subsequent runs might process incorrect data.

3. A typical mistake is to confuse the master key with the last round key. For trace acquisition, key K1 from our paper is used. For the attack on the GPU, one needs the corresponding last round key (because the correlation is done with the last round key). However, it seems that you used the correct keys when executing the commands.

Please try the points above and get back to us so that we can guide you further!

Thank you for the pointers. You're right about the TRACE_FILE format. I somehow missed it. launch_attack.py expects the format to be .bin. I will try these pointers and get back to you.
Also, I did a quick check in Sakura-X folder. SW scripts there implicitly handle creating traces in bin format. That is missing in SW scripts of Basys3.

I apologize for the inconsistencies in the README. I will update it once we have fully identified and resolved all your issues.
One potential solution is to implement a Python script that handles the conversion from CSV to binary in the case of Basys. If you develop this script, I would greatly appreciate a pull request so that I can add it to the repository for the benefit of future users.
Looking forward to your feedback.

Using the binary format fixed the issue. I could now see the key rank progressing, eventually converging to zero. Attaching the key rank results and the updated Python script that can handle both CSV and BIN formatted files. Regarding the pull request, please commit from your side, as these are minor changes.
keyrank_results.csv
convert_traces.py.zip
Can you keep the issue open for a few more days? Next week, I will try with Sakura-X board.

Great to hear that using the binary format resolved the issue! By the way, it is great to see that your keyrank results in the CSV align perfectly with our results in Figure 18 of the paper.
Thank you for sharing your Python script. I will add it to the repository soon and will update the ReadMe accordingly.
I will keep the issue open. Please do keep us updated on your experiments with the Sakura-X board next week. Your feedback is really valuable. I am looking forward to hearing from you again.

Hi,
I tired to collect the traces from Sakura-X board using one of the provided bitstream (RDS128_M2_AES_M1.bit) with RDS sensor. I see  Calibration command failed! in terminal after executing ./FTDexampleAES -k 2 -uk 7d266aecb153b4d5d6b171a58136605b -pm 1 -t 100000 -d traces/experiment_6_1 -c 4 -s 128 -r 128. Attaching more details in the log.txt
log.txt
Sequence of steps I followed:

power the board using USB on the host PC. I use Digilent JTAG-HS3 to program the board (connected to another USB port on host PC).
First, program control FPGA with the provided bitstream. Then, program main FPGA with RDS128_M2_AES_M1.bit (so skipping step 6 from Github instructions)
Skipping step 7 from Github instructions because I use Digilent JTAG-HS3.
Made sure I have (liblibftd2xx.so) at /usr/local/lib to meet the dependency. make is successful.
Executed two .sh in Debug directory: first setupFTD.sh , then unload_sio.sh.
created traces directory
collect the traces with ./FTDexampleAES -k 2 -uk 7d266aecb153b4d5d6b171a58136605b -pm 1 -t 100000 -d traces -c 4 -s 128 -r 128  (here I repeatedly see calibration command failed)

Can you please check if I'm missing any of steps in setting up the board? For example, is it OK to program main FPGA  with RDS128_M2_AES_M1.bit  instead of locally generating the bitstream?
Thanks.

Overall, your sequence of steps makes sense. It is perfectly fine to program the main FPGA with a provided bitstream (e.g., the RDS128_M2_AES_M1.bit). Therefore, I do not see any obvious mistake you made. Here are some general thoughts that may help:

Please ensure you reprogram the main FPGA before each experiment. In case anything goes wrong (as in you log.txt), the FPGA might be in an unwanted state. Thus, it is a good practice to reprogram the main FPGA before each experiment.
Please ensure that only the main FPGA cable is connected with the Xilinx JTAG-HS3 cable, and that the control FPGA cable is completely disconnected from the PC from the USB-A side (if both FPGAs are connected, or even if the control FPGA cable is connected to the PC but not to the board, it sometimes creates a USB device contention in the system, preventing the running of experiments).
I am not sure about this one: maybe it is a good idea to check if the Xilinx cable drivers are installed.

I hope the points above help you in solving the issue. Please get back to us once you have tried them, so we can provide further assistance if needed.

Thank you for the pointers. I tried them --  issue persists.  Then, it occurred to me that setup_device() in Sasebogii.c might not be handling the device selection correctly? Because, I see JTAG-HS3 (210299AD0897) as Device 3 in the terminal output, but Sasebogii.c defines B as 1? instead it has to be 2 right?
//terminal output
Available devices 3
Device 0 Serial Number - FT6AQDBPA
Device 1 Serial Number - FT6AQDBPB
Device 2 Serial Number - 210299AD0897

/// from Sasebogii.c, lines 14 to 25.
#define A 0
#define B 1

FT_HANDLE* sasebo_init() {
  FT_HANDLE* handle = calloc(1, sizeof(FT_HANDLE));

  if(setup_device(B, handle) == EXIT_FAILURE) {
    return NULL;
  }

  return handle;
}

I changed to following:
/// from Sasebogii.c, line 15

#define B **2**

with above update, ./FTDexampleAES -k 2 -uk 7d266aecb153b4d5d6b171a58136605b -pm 1 -t 100000 -d traces -c 4 -s 128 -r 128 exits with write partially done! message.
Program configuration:
	- key mode: 2
	- key used: 0x7d266aecb153b4d5d6b171a58136605b
	- plaintext mode: 1
	- number of traces: 100000
	- osciloscope enabled: 0
	- calibration mode: 4
	- sensor enabled: 1
	- starting sensor sample: 0
	- number of sensor samples: 128
	- idc_idf array used: 0xffffffffffffc000000fc0000
	- output path: traces

Available devices 3
Device 0 Serial Number - FT6AQDBPA
Device 1 Serial Number - FT6AQDBPB
Device 2 Serial Number - 210299AD0897

Type: 6
ID: 67330064
LocId: 4161
Flags: 2
Serial Number: FT6AQDBPA
Description: USB <-> Serial Converter A
Handle: (nil)
Type: 6
ID: 67330064
LocId: 4162
Flags: 2
Serial Number: FT6AQDBPB
Description: USB <-> Serial Converter B
Handle: (nil)
Type: 8
ID: 67330068
LocId: 262
Flags: 2
Serial Number: 210299AD0897
Description: Digilent USB Device
Handle: (nil)
succesfully opened device 2, handle is 0x555e400794c0
Encryption mode set to 0
write partially done!

Can you please confirm if B is supposed to be ID 2?
Thanks.

I doubt that the change solves the issue, because I have never seen "write partially done" during a successful run. While I am not entirely certain, I do not recall seeing three devices when I ran the experiments. Is there any other device connected? Maybe it is worth trying to remove all devices except the main FPGA.
Another thing that comes to my mind: maybe you need to change something in the setup files (unload_sio.sh & setupFTD.sh) to reflect the B you changed in the source code?

You're right, I should not be seeing  "write partially done". I made a couple changes to the flow and managed to get sakura-x working. As a trail run I collected 100 traces (attached below).
log100traces.txt
Following are the steps:

changed value of B to 0.

//line 15, Sasebogii.c
#define B 0

make sure FTDI drivers are correctly installed. HS3 usb-config is idVendor=0403, idProduct=6014. Sakura-X usb-config is idVendor=0403, idProduct=6010.  After installing the drivers, I noticed that rules /etc/udev/rules.d/ got updated with correct permissions.
I followed steps 1 to 6 same as your Github instructions.
close hw_sever of Vivado (just as precaution so that no ports are occupied after programming control and main FPGAs)
Then, I disconnected JTAG-HS3 from the main FPGA. So, at this point only connection between host pc and Sakura-x board is the power cable.
execute (1) setupFTD.sh (2) unload_sio.sh
I think step 7 in your instructions has to be updated. Either use setup_device(A, handle)  or update #define B 0 when HS3 is used as a programming cable.
create traces directory and run ./FTDexampleAES -k 2 -uk 7d266aecb153b4d5d6b171a58136605b -pm 1 -t 100000 -d traces -c 4 -s 128 -r 128

Based on this, I presume that JTAG-HS3 is used only for programming control and main FPGAs while Sakura-X's onboard FTDI chip (channel A) is being used for transferring sensor values to host pc. What do you think?
If approach is correct, I will collect more traces and try CPA attack.

Great to hear that you managed to collect traces! I had a look at the file you attached, and it is exactly the same output I saw during a successful run. So, I suggest you go ahead and collect more traces and perform a CPA attack.
I will have a look at point 7, thanks. I think you are right, the JTAG-HS3 is used for programming the control/main FPGA, while the FTDI chip is used for transferring sensor values.

Hi David,
Last few days I was working on Alevo board. Unfortunately, at my university we do not have U200, but only U250. I was trying to generate the .xclbin for U250, but my build fails at impl stage with ERROR: No valid objects found.  Please check the following error when I run make impl_rds.  I updated the platform in Makefile to xilinx_u250_gen3x16_xdma_4_1_202210_1:
WARNING: [Timing 38-3] User defined clock exists on pin level0_i/level1/level1_i/ulp/ss_ucs/inst/aclk_kernel_00_hierarchy/clkwiz_aclk_kernel_00/inst/CLK_CORE_DRP_I/clk_inst/mmcme4_adv_inst/CLKOUT0 [See /home/yaswanth/RDS/alveo/tcl/_x/link/vivado/vpl/output/_user_impl_clk.xdc:3] and will prevent any subsequent automatic derivation of generated clocks on that pin. If the user defined clock specifies '-add', any existing auto-derived clocks on that pin are retained.
WARNING: [Vivado 12-508] No pins matched 'level0_i/ulp/AES_SCA_kernel_1/U0/sensors/sensor_gen[*].sensor/tdc0/sensor_o_regs[*].obs_regs/D'.
ERROR: [VPL_TCL 101-2] ERROR: [Vivado 12-4739] set_false_path:No valid object(s) found for '-to [get_pins {level0_i/ulp/AES_SCA_kernel_1/U0/sensors/sensor_gen[*].sensor/tdc0/sensor_o_regs[*].obs_regs/D}]'.
Resolution: Check if the specified object(s) exists in the current design. If it does, ensure that the correct design hierarchy was specified for the object. If you are working with clocks, make sure create_clock was used to create the clock object before it is referenced.
ERROR: [VPL_TCL 101-3] sourcing script /home/yaswanth/RDS/alveo/tcl/_x/link/vivado/vpl/scripts/impl_1/_full_opt_pre.tcl failed
INFO: [Common 17-206] Exiting Vivado at Mon Jul  1 23:00:12 2024...

Have you seen this error with U200? At first I thought this could be due to xdc file (mismatch in pin mappings b/w U200 and U250) but then I realised that there is no user specified xdc here. I checked the logs for synthesis, no critical warnings or errors. There are a few warnings though -- I think this is typical with the tool, so ignoring them temporarily. There are also few nets that the tool removes (I'm not sure if this is OK? can you please check the attached warnings from implementation and synthesis) . I'm using Vitis 2022.2 with XRT 2.14.384. There are a couple of things I want to try but before that I want to take your input on this error. (e.g, constraints on pblocks with X and Y coordinates. These are set for U200, but I don't know they would be valid still for U250.)
impl_warning.txt
synth_warnings.txt
Thanks.

Given that we used a different board and vitis version, this might be the reason why there are incorrect constraint paths.
First of all, please note that in the case of the Alveo board, we did not use xdc files for the constraints (in contrast to Sakura and Basys). Instead, we add constraints by sourcing tcl scripts, see https://github.com/mirjanastojilovic/RDS/tree/main/alveo/constraints. In that case, if the constraint fails, the entire flow stops (that means, the entire implementation process).
One idea would be the following: comment the failing constraint, run the implementation and get the new path, change it in the constraint tcl, and re-run the implementation.
As I said, it is difficult to provide support for boards we did not use, but I hope my answer still gives you ideas where to start debugging.

I am closing this issue due to inactivity. If you have any further questions or need assistance, please feel free to open a new issue!


Automated cherry pick of #6511: fix: 避免忽略本地allow any云上deny any安全组规则同步

Cherry pick of #6511 on release/3.1.
#6511: fix: 避免忽略本地allow any云上deny any安全组规则同步

Codecov Report

Merging #6513 into release/3.1 will increase coverage by 0.01%.
The diff coverage is 0.00%.

@@              Coverage Diff               @@
##           release/3.1   #6513      +/-   ##
==============================================
+ Coverage         7.47%   7.48%   +0.01%
==============================================
  Files              585     585
  Lines            98936   98953      +17
==============================================
+ Hits              7396    7409      +13
- Misses           90967   90971       +4
  Partials           573     573

Flag
Coverage Δ

#aFlag
7.48% <0.00%> (+0.01%)
:arrow_up:

Impacted Files
Coverage Δ

pkg/monitor/alerting/engine.go
1.80% <ø> (ø)

pkg/multicloud/esxi/host.go
0.94% <0.00%> (-0.01%)
:arrow_down:

pkg/multicloud/esxi/storage.go
0.00% <0.00%> (ø)

pkg/multicloud/esxi/vdisk.go
0.00% <0.00%> (ø)

pkg/multicloud/esxi/virtualmachine.go
0.00% <0.00%> (ø)

pkg/appsrv/response.go
69.11% <0.00%> (+2.94%)
:arrow_up:

pkg/cloudcommon/cronman/cronman.go
54.85% <0.00%> (+5.33%)
: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 18e98f5...215f9c4. Read the comment docs.


[SPARK-31431][SQL] Add CalendarInterval encoder support

What changes were proposed in this pull request?
CalenderInterval is available to be converted to/from internal Spark SQL representation when it is a member of a Scala's product type e.g tuples/ case class etc but not as a primitive type
In this PR, we add a new seder rules to map CalenderInterval to CalenderIntervalType directly.
Why are the changes needed?
improve CalenderInterval
Does this PR introduce any user-facing change?

yes, CalenderInterval are now can be implicitly converted to Dataset/DataFame without being wrapped as scala Products
How was this patch tested?

add new tests

Test build #121166 has started for PR 28197 at commit 0bab743.

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

Merged build finished. Test PASSed.

Test build #121166 has finished for PR 28197 at commit 0bab743.

This patch fails to generate documentation.
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/121166/
Test FAILed.

Test build #121174 has started for PR 28197 at commit 9afea4b.

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-K8s/25862/
Test PASSed.

Test build #121174 has finished for PR 28197 at commit 9afea4b.

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/121174/
Test PASSed.

cc @dongjoon-hyun @cloud-fan thanks for reviewing

Test build #121267 has started for PR 28197 at commit 1bba227.

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-K8s/25954/
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/SparkPullRequestBuilder-K8s/25956/
Test PASSed.

Test build #121269 has started for PR 28197 at commit 3ea619a.

Test build #121267 has finished for PR 28197 at commit 1bba227.

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/121267/
Test PASSed.

Test build #121269 has finished for PR 28197 at commit 3ea619a.

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/121269/
Test PASSed.

Test build #121389 has started for PR 28197 at commit 793bd8b.

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-K8s/26072/
Test PASSed.

Test build #121394 has started for PR 28197 at commit 0801b8e.

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-K8s/26077/
Test PASSed.

Test build #121394 has finished for PR 28197 at commit 0801b8e.

This patch fails Java style 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/121394/
Test FAILed.

Test build #121397 has started for PR 28197 at commit 042cd83.

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-K8s/26080/
Test PASSed.

Test build #121397 has finished for PR 28197 at commit 042cd83.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Test build #121389 has finished for PR 28197 at commit 793bd8b.

This patch fails due to an unknown error code, -9.
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/121397/
Test FAILed.

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/121389/
Test FAILed.

retest this please

Test build #121399 has started for PR 28197 at commit 042cd83.

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-K8s/26082/
Test PASSed.

Test build #121399 has finished for PR 28197 at commit 042cd83.

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/121399/
Test PASSed.

Test build #121417 has started for PR 28197 at commit c4d4ef2.

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-K8s/26102/
Test PASSed.

Test build #121417 has finished for PR 28197 at commit c4d4ef2.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
 public static class SimpleIntervalBean implements Serializable
 public static class ComplexIntervalBean implements Serializable

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/121417/
Test PASSed.

It will be public after 3.0.0 release @viirya

That is not what I meant. My point is adding encoder support is for domain objects users frequently use to encode/decode to/from Spark internals. Do we expect users to use CalendarInterval in their domain objects?

Hi, take your commit as an example https://github.com/apache/spark/commit/48e44b24a7663142176102ac4c6bf4242f103804, Seq(Set(interval)).toDF(), do intervals work as domain objects already?

Do we expect users to read data and represent as CalendarInterval in Dataset? Seems to me CalendarInterval is only for usage in Spark row. Although not the same, it sounds similar to me to make UTF8String in Dataset.
For domain objects we provide encoders in Dataset, I think they shall be frequently used domain objects which users will use in their business logic.
This sounds a strange encoder when I looked at it at first. It seems not to be a problem, however I wonder we should be careful in adding encoder. If others also agree to add, I'm fine for this.

I'd say CalendarInterval should be treated the same as Decimal. They are semi-public, and are already supported partially (inside case class). It's arguable if we want to support more.

For timestamp and date type, we already add Instant and LocalDate from java8 time API. In that case, we are very likely to add Duration and Period later for CalendarIntervalType too, then it seems more reasonable to add CalendarInterval encoder support as the encoder has half-implemented already.


Blur on Waybar

Hyprland Version
0.28.0-1
Bug or Regression?
Bug
Description
I added this line to my hyprland.conf

blurls = waybar

It starts blurred, but after 1s, blur turns off.
How to reproduce

blurls = waybar
on hyprland.conf

Crash reports, logs, images, videos

just started:

after 1s:

Try layerrule = blur,waybar instead, I think blurls was deprecated considering layerrule is more recent and has more options.

Try layerrule = blur,waybar instead, I think blurls was deprecated considering layerrule is more recent and has more options.

I did this too, but still turning off :cry:

layerrule = blur,waybar works perfectly for me, with hyprland 0.28.0 and waybar 0.9.22

I'm currently running hyprland-git and waybar-hyprland-git  without issues,but if i want to run the version hyprland 0.29.1-1  and still use waybar-hyprland-git  with the correct blur rule enabled layerrule = blur,waybar and i switch my wallpaper with swww then for some reason a part of the old wallpaper stays behind waybar, if i turn of blur for waybar the problem is gone if i switch out waybar-hyprland-git for waybar-hyprland 0.9.22-1 it all works fine only when i reboot it take almost 2 to 3 minutes for waybar to load. so what could be the problem here ?

I have been having this issue since I started using hyprland months ago. It was annoying, but I was too lazy to make an issue about it. Thanks for shedding some light on it.

the problem is caused by xdg-desktop-portal, i did mask it even when that service was not running, xdg-desktop-portal-hyprland is not masked.
sudo systemctl mask xdg-desktop-portal.service
Did the trick so the porblem is caused by xdg-desktop-portal !

Did found out that also the slow loading of waybar, is caused by xdg-desktop-portal-hyprland, removing the portal solves the issue.

Hey, I just found that the property opacity: 0.5 in my Waybar config was the issue. I removed it, and it's working perfectly now.
Life is good.

I know this issue is closed but I'm not sure where else I could get help with it. I have the exact same issue as op (The bar blur persists for a moment before disappearing), however removing the opacity option in the style.css file just makes the bar opaque. I have set my background color using rgba( r, g, b, a ), and still the bar remains opaque. I have tried layerrule = blur,waybar and blurls = waybar both to no avail. Again I know this issue is closed but I don't see a better place to get help with this.

I had two problems, including one with blurring. I'm using NixOS. I'll leave a note here in case it helps someone.
version waybar: 0.10.3 ; version hyprland: 0.41.2

When launching "waybar," I encountered an error: "Unable to receive desktop appearance: GDBus.Error.freedesktop.DBus.Error.UnknownMethod:..."
The cause was the absence of xdg.portal (gtk) on my system, which I resolved by adding xdg.portal to the Nix configuration:

{ pkgs, ... }:
{
	xdg.portal = {
		enable = true;
		extraPortals = [ pkgs.xdg-desktop-portal-gtk ];
		xdgOpenUsePortal = true;
	};
}

Just like you, the blurring would disable itself after a second. I don't know the cause. I fixed it by removing the opacity setting in waybar.css and replacing background-color with transparent, it worked for me. The result is:

window#waybar {
	background-color: transparent;
	transition-property: background-color;
	transition-duration: .5s;
	border-radius: 5px;
}

This might solve your issue.
window#waybar {
      background: rgba(17, 17, 27, 0.7); /* Semi-transparent */
 }


GH-1237: RCFB Close key/trust store input streams

Resolves https://github.com/spring-projects/spring-amqp/issues/1237
cherry-pick to 2.2.x, 2.1.x, 1.7.x

... and cherry-picked to 2.2.x & 2.1.x.
Back-ported to 1.7.x as https://github.com/spring-projects/spring-amqp/commit/efcba3a83af50b458e3561ce8af3e0b0a87c6b59 after fixing conflicts.


ARROW-2409: [Rust] Deny warnings in CI.

ARROW-2409 asks that
we prevent warnings from entering the codebase in order to maintain a
more strict level of hygine.
There are a couple ways to cause rustc to bail when warnings are
encountered, the most straightforward of which might be to put
#![deny(warnings)] in each crate root. Still, it struck me as doing
this would cause undue friction on contributors and maintainers.
An alternative, noted by the rust patterns guide, is to use
RUSTFLAGS to opt-in to this behavior at build time.
For example, with an extraneous import added to a module:
$ RUSTFLAGS="-D warnings" cargo build
   Compiling arrow v0.13.0-SNAPSHOT (/home/owen/projects/arrow/rust/arrow)
error: unused import: `std::io`
  --> arrow/src/datatypes.rs:36:5
   |
36 | use std::io;
   |     ^^^^^^^
   |
   = note: `-D unused-imports` implied by `-D warnings`

error: aborting due to previous error

error: Could not compile `arrow`.

To learn more, run the command again with --verbose.

Adding this env var to the coverage collection should allow travis to
report warnings as failures in CI while letting developers continue to
work as normal.
This approach is also sort of nice since it will enforce the rule across
all crates in the workspace as new sub-crates are added without having
to remember to annotate the crate root each time.

Codecov Report

Merging #3852 into master will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3852      +/-   ##
==========================================
- Coverage   87.88%   87.82%   -0.07%
==========================================
  Files         723      723
  Lines       87500    87500
  Branches     1252     1252
==========================================
- Hits        76899    76846      -53
- Misses      10486    10541      +55
+ Partials      115      113       -2

Impacted Files
Coverage Δ

go/arrow/math/uint64_sse4_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/math/float64_sse4_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/memory/memory_sse4_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/math/int64_sse4_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/math/float64_amd64.go
33.33% <0%> (-33.34%)
:arrow_down:

go/arrow/math/int64_amd64.go
33.33% <0%> (-33.34%)
:arrow_down:

go/arrow/math/uint64_amd64.go
33.33% <0%> (-33.34%)
:arrow_down:

go/arrow/math/math_amd64.go
36.84% <0%> (-26.32%)
:arrow_down:

go/arrow/memory/memory_amd64.go
42.85% <0%> (-14.29%)
:arrow_down:

js/src/ipc/metadata/json.ts
92.39% <0%> (-4.35%)
:arrow_down:

... and 3 more

Continue to review full report at Codecov.

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


Script to build the nmslib and drop in the java library path.

nmslib C library should be build locally to the host machine to avoid compatibility issues with respect to cpu optimization instructions, c compiler etc.
We need to have a script that can build the library local to the host machine to support development/usage of knn plugin for various plugin distributions like deb, tar, zip etc

Addressed by #83. Closing issue


chore: another test for linear_combination

We already have the ℚ test (see below).  But the ℤ test had a less helpful error message before the core commit https://github.com/leanprover/lean4/pull/5167.

We already have the ℚ test (see below). But the ℤ test would have had a less helpful error message before the core commit leanprover/lean4#5167. This PR guards against regressions in the error message.

Yes, I saw the test over Q. Thanks for explaining, this clear things up.


Dragging the bottom sheet does not work on iOS 12

A bug found by someone with an old phone who hasn't been able to update past iOS 12.4 - there seems to be no response to dragging at all in iOS 12. Similarly, tapping the overlay background will also not close the bottom sheet.
I've checked the useGesture website and gestures seem to be fine there, so it must be something to do with the library. If I can provide any more details to help, I will.

Any update?


[AutoPR] cognitiveservices/data-plane/ComputerVision

Created to accumulate context: cognitiveservices/data-plane/ComputerVision

(message created by the CI based on PR content)

Codecov Report

Merging #2614 into master will increase coverage by 0.06%.
The diff coverage is n/a.

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

@AutorestCI rebase

Rebase done and pushed to the branch


Add spaces on save php file

VSCode Version: Code 1.13.1 (379d2efb5539b09112c793d3d9a413017d736f89, 2017-06-14T18:21:47.485Z)
OS Version: Windows_NT ia32 6.1.7601
Extensions:

Extension
Author
Version

vscode-intelephense-client
bmewburn
0.7.2

volt
hunter-dev
0.0.1

hopscotch
idleberg
0.1.4

theme-material-darker
jantto
0.0.1

vscode-apache
mrmlnc
1.1.1

Theme-MaterialKit
ms-vscode
0.1.4

java
redhat
0.7.0

dark-plus-material
vangware
1.0.4

Steps to Reproduce:

Create a PHP file
Add a block (some text inside { and }
Before the close bracket "}" add a coment like this: // comment
Press Ctrl + S (to save)
A blank line is added before the close bracket "}" each time "Ctrl + S" is pressed.

Does this reproduce if you disable the vscode-intelephense-client extension?

Yes, the behavior happens only when vscode-intelephense is enabled :/

Then, I ask you to please file this in the appropriate extension repository: https://github.com/bmewburn/vscode-intelephense


ENYO-6177: Fixed to scroll properly on page key down when scrollable components are nested

Checklist

[x] I have read and understand the contribution guide
[x] A CHANGELOG entry is included
[ ] At least one test case is included for this feature or bug fix
[x] Documentation was added or is not needed
[ ] This is an API breaking change

Issue Resolved / Feature Added
When page key is pressed on a horizontal list/scroller which is nested inside a vertical list/scroller, the outer vertical one needs to scroll but not the inner horizontal one. Currently, nothing scrolls.
Resolution
The cause is propagation blocking of keydown event between the inner and the outer scrollable components. In #2418, we added stopPropagation in the handler to avoid incorrect scroll distance after applying a new UX concept for page key inputs and it is the direct cause of this issue. #2429 is merged after the original cause and also related to event propagation. So we must resolve the original issues of #2418 and #2429 at the same time.
This issue requires not to block propagation when the inner component does not scroll by page. The issue of #2418 is about duplicated scroll by page for 5-way key mode and pointer mode, and it requires to block propagation for scroll by page on 5-way key mode.
The issue of #2429 is to allow propagation for page key input on scrollbar buttons.
So, I rolled back related code to the status before #2418 and implemented to stop propagation only when a component actually scrolls in 5-way key mode by page key input which is not from scrollbar area.
Additional Considerations
Links
ENYO-6177
#2418, #2429
Comments

I see inconsistent results with this. If an item doesn't have focus then the page up/down doesn't propagate properly so sometimes you can page down and then you can't page up again. The sample indicates that the key code is being forwarded to onKeyDown, it's just not properly bubbling out to the scroller, I guess?

Thank you for catching missing conditions! The case you pointed out is pressing page key on a scrollable area without focus in pointer mode. In this case, scrollable components can not catch keydown event directly since key events only delivered to a focused element. We are catching keydown event on document (using so-called global handler) for this case and it means that there is no actual bubbling between nested scrollable components.
So, I updated logic to check whether keydown is consumed or not in a scrollable component in mounting order. I think this approach is able to cover missing cases.

If the onkeyDown is coming from the document, why is it being caught by the action logger?  Is it forwarded out because it's theoretically consumed by that component?  Will the 'fixed' logic show it firing on the outer scroller now?  I guess I can test and see!

If the onkeyDown is coming from the document

To be clear, we are using a handler on document only for the case of non-focused in pointer mode. (Please see pageKeyHandler in Scrollable) If something is focused inside scrollable components, we catch the event in normal way. (onKeyDown in Scrollable)

why is it being caught by the action logger? Is it forwarded out because it's theoretically consumed by that component?

From #1913, we are forwarding onKeyDown to the outer React element. And it looks that the same code is copied into the code for pointer mode.
I have a little concern about when we need to forward.

Will the 'fixed' logic show it firing on the outer scroller now?

If press page keys on an inner scroller, there will be two logs in the action logger; the first one from the inner scroller and the second one from the outer scroller.


Can you add a "back to top" button at the bottom of the post?

Can you add a "back to top" button at the bottom of a post's reply, so that you can click back to the top after browsing all the replies.
As shown in the figure:

@bnulhf fixed in: https://github.com/casbin/casbin-forum/commit/00cabc27df80a68e8865ed55a0e03551a3ee0520

@bnulhf fixed in: https://github.com/casbin/casbin-forum/commit/00cabc27df80a68e8865ed55a0e03551a3ee0520


do not append sandbox is to kernel parameters

CreateSandbox() is the point we know which sandbox id will use
this guest. If we rely on the kernel command line for it, we have
to put sandbox id in qemu args and it breaks vm factory.
Also fix a typo in create.go that fails to assign the factory pointer.
The vendor commit will be re-vendored once kata-containers/agent/pull/309 is merged.

lgtm

openstack/third-party-check is still not required for now, so we can move forward with this!


Allow user to customize apollo json parser options

In particular, the functionality is currently scoped to the maximum request body size (limit), which helps avoid errors like PayloadTooLargeError: request entity too large
Keys defined here:
https://www.npmjs.com/package/body-parser#bodyparserjsonoptions

Tagging #2081 because this should be included in the Apollo2 branch too

Thanks!

Btw, shouldn't we set a default here? or would a default automatically be applied if limit is undefined?

Default gets automatically applied.
https://github.com/expressjs/body-parser/blob/e6ccf98015fece0851c0c673fc2776c30ad79e5d/lib/types/json.js#L53-L55
I waffled on this. I can see it both ways. On the one hand, it’s probably good to just use the defaults specified in bodyParser. On the other hand, it probably won’t change and may be useful for clarity.
Sent from my Rotary Phone

From: Sacha Greif<EMAIL_ADDRESS>Sent: Tuesday, December 11, 2018 10:42 PM
To: VulcanJS/Vulcan
Cc: Sara Itani; Author
Subject: Re: [VulcanJS/Vulcan] Allow user to customize apollo json parser options (#2147)
Btw, shouldn't we set a default here? or would a default automatically be applied if limit is undefined?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FVulcanJS%2FVulcan%2Fpull%2F2147%23issuecomment-446480013&data=02|01||ab2b939070284d27a11108d65ffd05fe|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636801937654825648&sdata=NgwkF9n%2B9uAC6fhgi6XuaB7uuLT3a0NcXrl12dEHK1I%3D&reserved=0, or mute the threadhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAuj4B0yOwT7ImPGPAbu2UKXAckBdXa1ks5u4KVkgaJpZM4ZL_4C&data=02|01||ab2b939070284d27a11108d65ffd05fe|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636801937654825648&sdata=innpFEkS%2FuOPMq4hLUDV5f6dDfGzjVmHTW2xaDsABuo%3D&reserved=0.


Catalog: support mapping of allowed entity kinds per location type

Feature Suggestion
Add support for limiting the allowed location types for each kind of entity. A configuration could look something like this:
entity-restrictions:
- kind: [User, Group]
  locations:
  - type: ldap
  - type: github-org

We'd also probably want to allow exceptions for some targets, maybe something like
entity-restrictions:
- kind: [User, Group]
  locations:
  - type: github
    target: github.com/acme-co/org-data/users.yaml
  - type: github
    target: github.com/acme-co/org-data/groups.yaml

Possible Implementation
Most likely implemented as a Processor in the catalog, preferable as a standalone thing that doesn't depend on other processors.
Context
The primary purpose of this is to enable https://github.com/spotify/backstage/issues/1401 in a secure way. If we don't add any restrictions to how entities can be defined, it would be possible for anyone to create a User entity with any kind of metadata. That in turn could be used to gain access to other users' accounts, and wreak havoc in general.

If I interpret the above correctly, it would suffice to whitelist only for example Component from any source. Then User and Group would be added only through a config based route, which never has any restrictions on it (because it's added by infra teams so should not need to pass through these same rulesets). Does that make sense? In a default-deny scenario.

@freben I figured it makes sense to do default-allow. Since most entities will be completely fine to allow, and there's less overhead for defining new entities. It does come with the risk of people accidentally removing the User and Group restriction though. If we want to protect against that we could make those a bit special and default to them being completely denied.
Regarding implicit allow from config-based locations I was thinking that too, but not sure we can do that. It kind of removes the possiblity of using config-based routes for other types, as you'd be able to sneak in Users in a configured API repo for example. I think we can work with that to possibly make it a bit simpler though, instead of having to list the location twice. Something like
locations:
- type: github
  target: github.com/acme-co/org-data/users.yaml
  allow: [User]

or as a full allow/deny chain, that gets iterated from top to bottom looking for matches, and comes preinstalled with only one allow-all or deny-all rule :)
rules:
  - type: github
    target: github.com/acme-co/org-data/users.yaml
    allow: [User]
  - type: github
    deny: [User]
  - allow: [*]

or whatever


Attention slicing as a potential way to lower memory requirement?

Feature request is related to a problem
Yes, I wanted to run on 8 GB GPU (a 3070), but couldn't do it without some adjustments.
A clear and concise description of what the problem is:
CUDA out of memory.
The solution I'd like
To make it work, I changed lines 55 onwards in sd.py into
        # Create model
        self.vae = AutoencoderKL.from_pretrained(model_key, subfolder="vae", torch_dtype=torch.float16).to(self.device)
        self.tokenizer = CLIPTokenizer.from_pretrained(model_key, subfolder="tokenizer", torch_dtype=torch.float16)
        self.text_encoder = CLIPTextModel.from_pretrained(model_key, subfolder="text_encoder", torch_dtype=torch.float16).to(self.device)
        self.unet = UNet2DConditionModel.from_pretrained(model_key, subfolder="unet", torch_dtype=torch.float16).to(self.device)

        self.unet.set_attention_slice("auto")

        if is_xformers_available():
            self.unet.enable_xformers_memory_efficient_attention()

Alternatives I've considered
I looked up huggingface docs for memory savnig config alternatives.
https://huggingface.co/docs/diffusers/v0.14.0/en/optimization/fp16
To be honest I just implemented each optimization suggestion from the top and downwards until it worked.
After adding `self.unet.set_attention_slice("auto"), I got total GPU memory usage of 7132MiB, which was low enough for my GPU. That number was gotten from a test run like this:
$ python main.py --text "a hamburger" --workspace trial -O

This works as expected and creates a hamburger in ~39 minutes.
A clear and concise description of what I want to happen.
I mostly want current and future users with CUDA out of memory problems to see this potential solution to their problem.
If maintainers adds a flag for enabling attention slicing from the top level, that'd be great.
If maintainers want me to make a PR, I'd be happy to.
Additional context
I saw there were a few other issues related to CUDA running out of memory. Pinging them here.
#41 #63 #70 #82

Here's "Cat sitting on a cloud eating cheese doodles" generated on the 8G GPU, so it seems to work.

@tobbelobb Hi, this looks really great! A PR will be appreciated!

:ok_hand: Made a PR here: https://github.com/ashawkey/stable-dreamfusion/pull/174

I have an even smaller / less powerful gpu (6GB). If you already have found the knob so to speak, I would appreciate an option to push things even further into the "time needed" and "less detail" directions.


Reactive + Octo causes preview windows to not display data

Using reactive.nvim and octo.nvim together causes the preview windows on hover to show no data as seen in the screenshot below.

Removing reactive.nvim causes the problem to go away and data is seen in the hover window. You can trigger the hover window by putting your cursor over a reference in octo.nvim, like I have in the screenshot (my cursor is over the # in #1 which is an issue reference).

Hi @milogert
I was able to reproduce this without using reactive:

disable reactive completely
paste this autocmd somewhere in your config (it should be active when you enter neovim)

vim.api.nvim_create_autocmd('BufWinEnter', {
  callback = function()
    vim.cmd.redraw()
  end,
})

try to reproduce the issue you described

reactive uses BufWinEnter autocmd together with redraw to always show a real current state for windows/buffers and highlights that are applied to them. As well as WinEnter and WinLeave autocmds. That said, this can be either a Neovim bug, or a Octo bug. I checked their (octo) source code and it seems like they open a popup using method create_popup located in lua/octo/ui/window.lua file, in case you wanna reference it there as well. I'm not really familiar with the codebase, but it seems like there're no errors in their code, but that's my opinion just looking at it really quickly so I'm not sure.
The error is happening only when using redraw command, so this can be a Neovim bug as well. I already faced really weird behaviour that is similar to this one, you can check #7 for that. Still haven't found time to create an issue in the Neovim's repo.

closing this as not related
feel free to open other issues when having troubles


Allow override init to make custom class fixes #19

Installed through Cocoapod
My podfile:
pod 'fluid-slider'

I Could not subClass Slider Class
class MySliderView: Slider {
    init(frame: CGRect) {
        super.init(frame: frame) // make superview public
    }
}

The error is
Incorrect argument label in call (have 'frame:', expected 'coder:')
Replace 'frame' with 'coder'

Inside Slider class
init(coder:) is public
In this commit I made init(frame:) public also
This'll fix issue number 19
override init to make custom reusable Slider #19

thanks


Strip 'v' from version number in conda recipe

Description of work:
Check all that apply:

[ ] added release notes
(if not, provide an explanation in the work description)
[ ] updated documentation
[ ] Source added/refactored
[ ] Added unit tests
[ ] Added integration tests
[ ] Verified that tests requiring the /SNS and /HFIR filesystems pass without fail

References:

Links to IBM EWM items:
Links to related issues or pull requests:

Manual test for the reviewer
(instructions to set up the environment)
Check list for the reviewer

[ ] release notes updated,
or an explanation is provided as to why release notes are unnecessary
[ ] best software practices

[ ] clearly named variables (better to be verbose in variable names)
[ ] code comments explaining the intent of code blocks

[ ] All the tests are passing
[ ] The documentation is up to date
[ ] code comments added when explaining intent

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (next@39ae208). Learn more about missing BASE report.

Additional details and impacted files
@@           Coverage Diff           @@
##             next     #103   +/-   ##
=======================================
  Coverage        ?   44.98%
=======================================
  Files           ?       33
  Lines           ?     6307
  Branches        ?        0
=======================================
  Hits            ?     2837
  Misses          ?     3470
  Partials        ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


subversion_1_10: 1.10.3 -> 1.10.4

Motivation for this change
bugfix release for CVE-2018-11803 [0].
[0] https://subversion.apache.org/security/CVE-2018-11803-advisory.txt
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

backported to 19.03: 2d78754c7ed


Markdown table formater with unicode characters

What is the problem?
Columns should be alighned properly with all characters.
How can I reproduce it?
Example table (formated with table formater):
| App name **(Scoop name)**                   | Tested | Checkver | Auto (Hash) |
| ------------------------------------------- | :----: | :------: | :---------: |
| [X3 Bold Red Cursor **(X3)**](./X3.json)    | ❌      | ⭕        | ⭕ (⭕)       |
| [Easy2Boot **(E2B)**](./E2B.json)           | ❌      | ✔        | ✔ (⛔)       |
| [Spybot 2 **(Spybot)**](./TODO/Spybot.json) | ❌      | ✔        | ✔ (✔)       |
| [VMware **(VMware)**](./TODO/VMware.json)   | ❌      | ✔🔶      | ✔ (✔)       |

Expected:
| App name **(Scoop name)**                   | Tested | Checkver | Auto (Hash) |
| ------------------------------------------- | :----: | :------: | :---------: |
| [X3 Bold Red Cursor **(X3)**](./X3.json)    | ❌     | ⭕      | ⭕ (⭕)    |
| [Easy2Boot **(E2B)**](./E2B.json)           | ❌     | ✔       | ✔ (⛔)     |
| [Spybot 2 **(Spybot)**](./TODO/Spybot.json) | ❌     | ✔       | ✔ (✔)      |
| [VMware **(VMware)**](./TODO/VMware.json)   | ❌     | ✔🔶    | ✔ (✔)      |

There is no good solution for now (and possibly for a long time).
The columns can be aligned because of the monospace font which makes all characters the same width.
Then we can add extra spaces to align the columns. Unfortunately, that doesn't hold for emoji characters.
You can find more information in #151.


check results should be defined by proto

Fixes #974

Hmm. Seeing some extra and undesirable stuff now in output:
$ registry check projects/theganyo-1
id: ""
kind: ""
createtime:
    seconds:<PHONE_NUMBER>
    nanos: 840945000
problems:
    - id: ""
    - severity: 3


MarathonSchedulerService.onDefeated not called on leader change

During leader change the losing contestants shall be notified with a call to MarathonSchedulerService.onDefeated. The winner is called via onElected correctly, but the losers are not.
This leads to problems described in #356 and probably #896.

False alarm. But instead the whole SchedulerActor + leadership change logic is broken / missing, leading to the symptoms.


Added Feature : Transformer Update

Task Description:

Classifier, NER & QA encoder model update
QA vs NER based extraction comparison
Pretrained and on the spot training model options

Small transformer classifier (global task model) has been added into nlpm, loaded model ~45 mb
Option to train the model also added
Training models method train has been renamed to setup to take into account loading of models, not just training.

References:

Testing notebook added: github colab
Overall, BERT mini performs quite well on longer inputs in which no filtration is made to exclude parameters and data inputs, at least in comparison to RF + TF-IDF.
No advantage is visible when using the full encoder variant at the present function count
Full request corpus may be advantageous to implement and use over current corpus


Anchor link with complete URL

Hi,
thanks for this neat script. Using a CMS I need to add the URL to the anchor name in the link, so I changed line 70 from
.attr('href', '#' + anchorName)
to
.attr('href', window.location + '#' + anchorName).
EDIT:
The above change of code seemed to be working well at first, but now I realise that something isn't working well. Clicking on another link now, the anchor is being added to the URL - http://mydomain.com/mypage.html#toc38#toc19. Refreshing the page adds yet another anchor to the URL etc.
Did I trigger this behavior by adding window.location? Is there a solution for this?
I'd very much appreciate your help,
Anke

Hi @Anke, did you solve this issue in any way?

Uh, thank you for your reply, but honestly - I don't know. I might have, but might just as well have implemented another script. Sorry.


Have a zoom feature

In the webpage version, I can zoom it. The font size is easier to read than ever. I have tried to look at the devtool, but I can't find where the font-size tag locates. I'm still novice.
Normal font-size

Larger font-size

@ooker777 How do you usually zoom on the browser, I need an idea for the implementation

I just zoom it as usual: ctrl++. You can also enlarge the font size.
Ooker.
On Tue, Jun 28, 2016 at 8:03 AM +0700, "Émile Fugulin"<EMAIL_ADDRESS>wrote:
@ooker777 How do you usually zoom on the browser, I need an idea for the implementation
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Good thank you!

Also one might use Ctrl+Mouse wheel to zoom. When we are talkin about zoom in the browser everything on the page get's bigger proportionally, not just the text. However in this case a simple bigger+smaller chat text option would suffice.


Provide alternative for flat project structure

In Gradle 7.1 Gradle deprecated the includeFlat statements in the settings file: https://github.com/gradle/gradle/issues/13891. When the decision was made, the team did not consider how widespread is the usage of these features. There are several reports on the deprecation issue explaining the usefulness when working with a large codebase, especially when the Eclipse IDE is being used.
The intended replacement for includeFlat is composite builds. We should revisit why composite builds don't work for those users and whether we can improve that feature to cover the missing use-cases.

the source of the problem is that project C is not an independent build, but rather a common submodule of project A and B, and that's why you need to be able to configure it via the Project API.

@donat Yes, that is entirely correct.

I need some advice on how to prepare for Gradle 8 with these changes.. Our project structure looks something like this:
/code
/code/libs/libA/build.gradle
/code/libs/libB/build.gradle
/code/services
/code/services/group1/settings.gradle
/code/services/group1/serviceA/build.gradle
/code/services/group1/serviceB/build.gradle
/code/services/group2/settings.gradle
/code/services/group2/serviceA/build.gradle
/code/services/group2/serviceB/build.gradle
Right now I use a reference in our settings.gradle for something in group1 or group2 to access the libs in /libs/, like:
.projectDir = new File('../../libs/libA')
and this works fine and imports great into Eclipse/VSCode. How exactly do I get this working with a composite build? Do I need to do something with symlinks (is that even possible?). The group1 and group2 of code is a separate group of services from each other, but they use code in our shared libraries and we use local references. Some help would be appreciated since this is a bad enough issue we won't be able to move to Gradle 8.

I've done some testing and indeed, the de-duplication is now available in Eclipse. You can filter duplicated resources with a new option in the open resource dialog:

Quick Search however still has the duplicated resource problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=559340

Please do NOT remove the flat project structures.
We are using only flat project structures since several years and have a lot of processes that rely on this. Losing the flat layout might also force us to stay at Gradle 7.

At least, not so fast!!!! Please reconsider doing that in a further version!!!

tl;dr -- this breaks multiple repository support.
I became aware of this today.  Sorry for the long post.
We have a couple of large projects that revolve around this functionality.  Removing this would be a nightmare for us and require a re-architecture of our project build structure.  We're using gradle 6 currently.
Let me try and describe our setup.  Our build system and developers are using the same gradle files.  We use individual gradle projects for the CI build system and then "umbrella" gradle projects set up as multi-project builds for development, using dependency substitution for source replacement.  We also have a common standard set of custom utility jars and 3rd party things that both of these segments use as dependencies.  Importantly, our source code is in multiple repositories, which I think is the biggest miss here.
My concerns...  First, as of last summer IntelliJ didn't yet have good enough support for composite builds -- we couldn't get our projects to compile properly this way due to I think the way IntelliJ imported gradle.  While a bit of a tangent, it is ominous that current functionality is already deprecated in 7.x and slated for removal in 8.0 before we've been able to get composite builds even working in our more advanced setup.  It's on our list to revisit because this seems to be the way things are progressing.
Second, multiple repository support.  Using a project with multiple repositories all under a single root means you are forced to integrate your version control system into your gradle project setup.  For example, something like this is an issue:

ProjectA
ProjectB
ProjectC
Umbrella root build
If the umbrella folder contains the above 3 projects from 3 separate repositories, how would you do that with the new setup without also using something like git submodules within the separate umbrella repo?  Assuming your VCS solution even had something like that, I suspect not all do...  This seems more tightly coupled than it should be.

Another multi-repo example (that we also do) is an independent, but also in-house, set of libraries.  These are versioned and maintained independently, yet may be needed for debugging or need related source changes within the same project for new features or fixes.  Our current developer builds can optionally include source or artifacts for these depending on their local setup.  This change breaks that ability as the file hierarchy is now forced.
Finally, let me try and give you an overview of the folder hierarchy we are pulling all together in our core project.  It's not an ideal setup but it's been fine.  Here is the basic directory structure:
// dev/group/mainGroup/*
// dev/group/services/*
// dev/applications/*
// dev/common-libs/*
our "umbrella" root project is in the mainGroup folder.  It looks for source in the other folders, each of these having one or more repositories which themselves possibly have multiple projects in them.  Some of the root build dependencies are within it's own repository, as subfolders, which is great.  However it also reaches into the other folders in many cases, replacing artifact dependencies as source when configured to do so.  Depending on the job of a developer, using artifacts can greatly increase compilation and build times.  Without the common libraries included, I count 19 sub-projects in that main project as of today.
This change seems to lean away from more complex enterprise-like setups and towards small projects.  It seems unnecessarily restrictive.
I don't understand why sub-project roots can't be watched via the FS watchers in the same way the root project gets watched.  I don't see an immediate reason this needs to be forced into a hierarchy other than it's easier to write that way for gradle's internals.  What am I missing?

Thanks to everyone for proving us feedback and explaining all the use-cases how the flat project is used. We decided to roll back and remove the deprecation from the flat project structure.

@donat Thank you listening for feedback and rolling back the flat project depreciation! Huge relief.

@donat It seems it's still removed from Gradle 8, so what's the recommended solution for future proofing?
Currently we use a monorepo set-up and there's lots of shared code between domains so this is used heavily by us, for example testing frameworks which are used by all tests in a domain within the repo.

FYI the latest version of the upgrade guide contains up-to-date information: https://docs.gradle.org/current/userguide/upgrading_version_7.html#non_hierarchical_project_structures

I understand, but the general policy is that we don't modify any resources - binaries or documentation - for previous releases.

Hi @donat on our company, we have a structure like this for mobile apps:
roor-repository
   /apps
        /app1
        /app2
        /app3
   /modules
        /lib1
        /lib2

Where lib1 lib2, etc are submodules shared by many apps.
Then, within /apps/app1/settings.gradle.kts we have for example:
    project(":lib1").projectDir = file("../../modules/lib1/")

This is not exactly the same case as the includeFlat but quite similar.
We are still seeing a warning:
Subproject lib1 has location ‘....’ which is outside of the project root.
This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0.

We are still on gradle 7.3.3, is this deprecation also being removed on gradle 7.4?
I would also like to know if this structure makes compilation time slower, and if there is any hierarchical structure that you would recommend to improve performance on compilation time of app1 app2 etc
thanks in advance 🙏

The deprecation message should disappear after you upgrade to Gradle 7.4.
There can be performance implications of using a flat project structure. If not all files are located under the project root, the  filesystem watching module needs to monitor more folders.


Add digest authentication option to openURL

It will be good to have the possibility to add an auth_type field with possible values like 'basic', 'digest', ...
to allow  http://docs.python-requests.org/en/master/user/authentication/#digest-authentication

Maybe it will  be a better idea to built a complete connector class around requests. In our old mapbender application we have such a class for all connections and it works good (https://trac.osgeo.org/mapbender/browser/trunk/mapbender/http/classes/class_connector.php). The the service exception handling should be realized in the different ows classes (IMHO).
I will do some further tests ;-)


Compiling with musl?

Hi there, with a up-to-date stable and x86-86-unknown-linux-musl target, I seem unable to compile this library (as a dependency of curl and isahc). With:
cargo build --release --target x86_64-unknown-linux-musl

I get many messages of the form:
cargo:warning=In file included from /usr/include/bits/endian.h:35,
cargo:warning=                 from /usr/include/endian.h:24,
cargo:warning=                 from /usr/include/sys/types.h:176,
cargo:warning=                 from curl/include/curl/system.h:430,
cargo:warning=                 from curl/include/curl/curl.h:38,
cargo:warning=                 from curl/lib/curl_setup.h:157,
cargo:warning=                 from curl/lib/asyn-thread.c:23:
cargo:warning=/usr/include/bits/endianness.h:9: warning: "__BYTE_ORDER" redefined
cargo:warning=    9 | #define __BYTE_ORDER __LITTLE_ENDIAN
cargo:warning=      |

Followed by a complaint about musl-gcc exiting with an error code. I have the latest curl system packages installed on my machine, so I'm not sure what the issue is. Any thoughts? Thank you.

This looks like your C compiler may not be configured correctly? The error there is in a system header?

Here's the full text of the error: https://pastebin.com/KaSCNje8
Hard to say if anything is misconfigured, since I certainly haven't touched any such settings myself. I have gcc, clang, glibc, and musl all installed in harmony (i.e. their package definitions don't explicitly reject the others).

Sorry I don't really know myself. I'm not familiar with how you're installing your musl compiler and what could possibly go wrong.

They're all just system packages installed through the package manager :( Oh well, thanks for your help.

I'm not able to reproduce this error. It might help to know what Linux distribution you are using. I can build for musl just fine in my Linux environments (with the caveat of picking an SSL backend). Or, I don't get the error you are seeing anyway. I also verified that curl-rust can be built with musl in a totally clean Docker build environment like this:
$ docker run -it --rm rust
$ apt update
$ apt install -y musl-tools
$ rustup target add x86_64-unknown-linux-musl
$ git clone https://github.com/alexcrichton/curl-rust
$ cd curl-rust
$ cargo build --release --target x86_64-unknown-linux-musl --no-default-features
# -> builds successfully with no SSL
$ cargo build --release --target x86_64-unknown-linux-musl --features static-ssl
# -> builds successfully with a bundled OpenSSL provided by openssl-sys crate

Building curl for musl shouldn't be hard, its building OpenSSL for musl that can be tricky. I'm curious where you're getting a musl-compatible OpenSSL build from, though your error message isn't even coming from there so I'm not sure what's wrong.


Converting optional Collections.

Description
While converting .avsc files to .avdl file, optional collections are written as
array}? examples = null;
If we convert .avdl file to .avsc file, these fields give error ParseException: Encountered " "}".
To Reproduce
Steps to reproduce the behaviour:

Create a .avsc file with optional collection variable.
Convert this to .avdl file.
Again try converting this .avdl file to .avsc

Expected behaviour
The conversion from one format to other should work seemlessly.
Versions:

JetBrains Product: [e.g. IntelliJ Ultimate Edition]
Version [e.g. 2023.2.2]
Plugin: [e.g. 213.5.2]

Additional context
Also add support to optionally select the syntax for union types.

Thank you for reporting this. The cause was, as suspected, a missing check.
The next release will include the fix (available when JetBrains approves it).


August HASS Integration Unlatch/Open

Hi, I'm trying to get the unlatch action working for home assistant (https://github.com/m10x/August-HA-Integration)
However, I have no experience programming for HASS.
In order for the "Service lock: Open" to work a feature flag has to be set: https://developers.home-assistant.io/docs/core/entity/lock/#open
I've done some changes and placed the august folder under /config/custom_components and restarted, however my yale lock is still not shown as a target. I don't know what's the easiest way to quickly check if HASS is even using the modified version or whether it's still using the original one. Further, I'm quite unsure on how to set the open feature flag properly.
Changes I've made:
manifest.json: bumped yalexs to 3.0.0
lock.py: added def async_open
init.py: added def async_unlock and def async_unlock_async + tried to set the feature flag

Its a lot easier to make the changes in a dev env, and than open a PR than to try to do it as a CC.
Once you have a PR open , you can use this script to pull down the PR as a custom component
cd /config
curl -o- -sSL https://gist.githubusercontent.com/bdraco/43f8043cb04b9838383fd71353e99b18/raw/core_integration_pr | bash /dev/stdin -d august -p `HASS PR # HERE`

You need to set the open feature for locks that support it
https://developers.home-assistant.io/docs/core/entity/lock/#supported-features

I did that and get the error message
2024-03-19 08:57:16.265 ERROR (MainThread) [homeassistant.config_entries] Error importing platform config_flow from integration august to set up august configuration entry: cannot import name 'ConfigFlowResult' from 'homeassistant.config_entries' (/usr/src/homeassistant/homeassistant/config_entries.py)
Do you have any idea how to fix that?

It seems that I have to use the dev docker container and cannot use the hass os

Worked.
https://github.com/home-assistant/core/pull/113795