Recipes for building packages using both PyInstaller and fpm.

Two different recipes for building packages on Linux: using PyInstaller, and using fpm.
Haven't tried on Windows yet, and I don't have access to MacOS.

Codecov Report

Merging #102 (10ec1a0) into master (3630ec9) will increase coverage by 0.14%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #102      +/-   ##
==========================================
+ Coverage   70.33%   70.48%   +0.14%
==========================================
  Files          40       40
  Lines        2043     2043
==========================================
+ Hits         1437     1440       +3
+ Misses        606      603       -3

Impacted Files
Coverage Δ

benten/cwl/expressiontype.py
87.20% <0.00%> (+2.40%)
: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 3630ec9...10ec1a0. Read the comment docs.

@tetron this is fabulous. Thank you!

Is the distribution the zipped folder that this produces? Where should the user place this folder?
When I tried this on macOS I got an error message about dukPy. Did you get anything like this on Linux?

  Confusingly, most (all?) of the actual benten code is included directly in the benten-ls execution.  I'm pretty sure we'll want to distribute the entire build/benten-ls folder.
However, on Linux, I think building distribution packages with fpm are going to be much preferred over PyInstaller.  So we should focus on MacOS and Windows.
Could you paste the dukPy error?

(rabix) c02cr2e3ml85@MacBook-Pro benten % ./dist/benten-ls/benten-ls
Traceback (most recent call last):
  File "benten-ls.py", line 1, in <module>
    import benten.__main__
  File "/Users/c02cr2e3ml85/.venvs/rabix/lib/python3.9/site-packages/PyInstaller/loader/pyimod03_importers.py", line 493, in exec_module
    exec(bytecode, module.__dict__)
  File "benten/__main__.py", line 7, in <module>
    from .configuration import Configuration
  File "/Users/c02cr2e3ml85/.venvs/rabix/lib/python3.9/site-packages/PyInstaller/loader/pyimod03_importers.py", line 493, in exec_module
    exec(bytecode, module.__dict__)
  File "benten/configuration.py", line 8, in <module>
    from .cwl.specification import parse_schema
  File "/Users/c02cr2e3ml85/.venvs/rabix/lib/python3.9/site-packages/PyInstaller/loader/pyimod03_importers.py", line 493, in exec_module
    exec(bytecode, module.__dict__)
  File "benten/cwl/specification.py", line 8, in <module>
    from .alltypes import *
  File "/Users/c02cr2e3ml85/.venvs/rabix/lib/python3.9/site-packages/PyInstaller/loader/pyimod03_importers.py", line 493, in exec_module
    exec(bytecode, module.__dict__)
  File "benten/cwl/alltypes.py", line 12, in <module>
    from .expressiontype import CWLExpressionType
  File "/Users/c02cr2e3ml85/.venvs/rabix/lib/python3.9/site-packages/PyInstaller/loader/pyimod03_importers.py", line 493, in exec_module
    exec(bytecode, module.__dict__)
  File "benten/cwl/expressiontype.py", line 6, in <module>
    import dukpy
ModuleNotFoundError: No module named 'dukpy'
[86658] Failed to execute script benten-ls

Ok I got dist/ and build/ confused.  There are some useful log files in build/ but dist/ is where it puts thing that is supposed to be runnable.
Hm, maybe it didn't include 'dukpy' in the package?
Maybe there's useful information in build/benten-ls/warn-benten-ls.txt
What version of Python and PyInstaller are you using?

I set up a Windows 2016 VM and connected with remote desktop
I managed to install python, git, vscode etc
PyInstaller successfully created a working benten-ls.exe
My idea is for the Windows (and MacOS?) installer to place the benten package in $HOME/.local/lib/benten/bin
Then the vsCode extension can add $HOME/.local/lib/benten/bin to its search path for benten-ls

The even more clever thing to do would be to sniff the OS and download the appropriate binary from within the language client so there is no extra step

Superceded by #103


Remove use of tp_new

This is a placeholder for removing the deprecated tp_new to comply with Python 3.14.   This PR won't work yet for a few reasons.

Exceptions currently don't properly inherit the base so everything on the exception path does not work currently.  This should be a special case in the MetaClass creation process.
The allocator are not sticky in some places for mysterious reasons, regarding the removal of tp_new.   It was the only central location that we could guarantee that all the fields were set properly on new types.   I got a fair number of them in this PR but the strays all need to be chased down and resolved.
We have to go back through every version of Python to find out where the patterns work and fail.   This is a time consuming task.

I am debating whether I can just override the tp_call method and add our type checks at that point rather than tp_new.

@marscher I think that this one should solve the issues on Python 3.14 with deprecated tp_new on meta classes.
The following was done in the PR.

Switch call to use tp_call rather than tp_new.  As it turned out we were actually skipping the init method which may have been problematic.
Change the create with Meta to work with the Python provided.   It was a problem before because it contained checks for the tp_new
Moved all of the logic from tp_new to tp_init for JClass.
Implemented __init_subclass__ the default version installed by the heap dies on kwargs which prevents the special tokens that we use during class initialization to fail.  This was the main reason we needed to use the tp_new slot is that we had to get the kwargs before it reached the misbehaving __init_subclass__.   This sort of seems like a bug in Python as making the default eat kwargs is disabling.

If we ever need to add precheck logic on the class (such as allowing classes to be overwritten in Python, then we will need to implement a tp_call on JClassMeta or add a __init_subclass__ in there someplace such that the we can interrogate the methods being installed on the class to create a overload stub.

Will do…. Not sure how it came into existence.

@marscher October is soon upon us and I will need to make our yearly maintence release.   Please tag/approve PRs so I can start the release process.

@Thrameos do you want to include this for the next release? After reading your comments I got the impression that it is not yet stable - am I wrong?

The instability appeared to be been tied directly to Python 3.13 and the different attempts to fix the allocator problem.  The first was "stable" but extremely dangerous as it was altering active types.  The second used approved but unstable methods, but failed because those methods don't work.  The third was built on a variation of the Python 3.12 hack which created a dummy type purely to be manipulated.  That option proved to be the most stable of the options.   Using that as a foundation the tp_new deprecation fix appears completely stable.  So I believe it ready to be applied.


paramsd: remove unnecessary if statement

the event is already updated.

sm.updated is a dict with all the sockets, so this check isn’t redundant.

hmmm.my bad


[NVIDIA - STABLE] Getting kicket back to SDDM Greeter after login

Describe the bug
After login, i get kicked back to the Greeter/Lockscreen located on TTY1.
If i try to login again, the Desktop won't load / the screen stays black.
What did you expect to happen?
I expected to have a desktop, that doesn't kick me out after a Minute
Output of rpm-ostree status
State: idle
Deployments:
● ostree-unverified-registry:ghcr.io/ublue-os/bazzite-nvidia:stable
                   Digest: sha256:158bbced9de484d9e6a3acca9534be77d0becab8e7d4d828a75880024ef53340
                  Version: 40.20240922.0 (2024-09-23T05:05:17Z)
                Initramfs: regenerate

  ostree-unverified-registry:ghcr.io/ublue-os/bazzite-nvidia:stable
                   Digest: sha256:e447992949d4508d573ddce67fd2669aef87cc98efe2fe44312db54d052b5aeb
                  Version: 40.20240914.0 (2024-09-15T21:06:47Z)
                Initramfs: regenerate

Hardware
No response
Extra information or context
After getting kicked back to the Greeter, i either have to reboot using a shell on TTY3 or higher, or kill the Desktop Session on TTY2 manually using loginctl kill-session {ID}
I've noticed, that the SDDM Session usually gets destroyed, after a sucessfull login (if this issue doesn't happen).
This is not the case in the instances, I get bootet out of my Session.
In this case, the greeter Session persists and has the Status "online", while the Desktop Session on TTY2 has the State "closing".
After killing the "defective" session, another login attempt will result in a working Desktop without any interuptions/unexpected lockscreens.
Attached are 2 Photos.
One (quite blurry butr readable) image of the output from loginctl list-sessions after a failed login and one with the output after a working login.

I have the exact same issue. Same Bazzite version too (same rpm-ostree status output). The strange thing about it is that the desktop might not crash if Steam is running! If Steam is not running then it will certainly crash sooner than later. Discovery app might also contribute to the crashing.
Other weird behaviors include the inability to update certain "freedesktop platform" parts. Discovery didn't want to update certain parts, but when running system update it did something to them, but still outputs weird warnings that I don't know what to do about.

Okay, the Steam thing might be a coincidence. I did not do any if those things that you did, but I am succesfully running Bazzite right now and my loginctl output is the same:

I'm not knowledgeable enough to understand this. I have no idea why it's working now but not at other times.

Same problem
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-nvidia-open:stable
                   Digest: sha256:7714620ce66e84806949720204c07da491b6b31bc6304a27ca620893bf1508b9
                  Version: 40.20240922.0 (2024-09-23T05:09:18Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-nvidia-open:stable
                   Digest: sha256:0038d9bf78189ecf1505eeeaa22b7bf47fc39a8bdd2527c6b9a043ba4f99e14c
                  Version: 40.20240921.1 (2024-09-22T12:39:50Z)

For some inexplicable reason my recent logins have been without issues.

I am experiencing the same issue, though I've had mixed success in killing the tty2 session, returning to the sddm greeter and logging in again. Not sure if this is relevant, as this appears to happen even on a successful load, but I see this in plasmashell logs immediately following boot:
Sep 30 23:02:35 bazzite plasmashell[6040]: KPackageStructure of KPluginMetaData(pluginId:"dev.jhyub.supergfxctl", fileName: "/usr/share/plasma/plasmoids/dev.jhyub.supergfxctl/metadata.json") does not match requested format "Plasma/Applet"
Sep 30 23:02:35 bazzite plasmashell[6040]: kde.plasmashell: Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running.
Sep 30 23:02:35 bazzite plasmashell[6040]: kde.plasmashell: If this Plasma has been installed into a custom prefix, verify that its D-Bus services dir is known to the system for the daemon to be activatable.
Sep 30 23:02:36 bazzite plasmashell[6040]: kde.plasmashell: Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running.
Sep 30 23:02:36 bazzite plasmashell[6040]: kde.plasmashell: If this Plasma has been installed into a custom prefix, verify that its D-Bus services dir is known to the system for the daemon to be activatable.

Also possibly relevant, it seems that so far for me, a boot immediately following an update / new rpm-ostree deploy will tend to work correctly, and this bug occurs on following boots on the same deploy. I've noticed this offhand over the past couple weeks of this issue popping up. Haven't tested this theory extensively yet, but last night I started rebooting from tty3 as mentioned in the initial report to see if it it would boot correctly. I got this crash-to-sddm bug about six or seven times in a row, then out of curiosity I did an rpm-ostree update of an irrelevant package (the spotify client) to trigger a new deploy, and the next reboot was successful.

Also possibly relevant, it seems that so far for me, a boot immediately following an update / new rpm-ostree deploy will tend to work correctly

I've notuiced something simmilar, although it seems like a regular reboot will do the trick too.
I also noticed - from this and this reddit posts, that the issue might be related to the combination of Ryzen and Nvidia.
If all that are affecvted use and AMD CPU wirth an nVidia GPU, we might be on to something - maybe an incompatibility, maybe a red herring, but certainly something

It happened to me again, totally randomly. Immediately after boot I checked loginctl list-sessions and at first tty2 looked normal. Then I updated some flatpaks on Discovery and watched some show on Netflix with Chrome for a little while. Then it just suddenly threw me to the greeter. I immediately opened tty4 and checked loginctl list-sessions which gave me this:

I was able to do a new login that worked following NekroSomnias directions.

Also possibly relevant, it seems that so far for me, a boot immediately following an update / new rpm-ostree deploy will tend to work correctly

I've notuiced something simmilar, although it seems like a regular reboot will do the trick too.
I also noticed - from this and this reddit posts, that the issue might be related to the combination of Ryzen and Nvidia.
If all that are affecvted use and AMD CPU wirth an nVidia GPU, we might be on to something - maybe an incompatibility, maybe a red herring, but certainly something

I also do have a Ryzen 5 3600 CPU and a GeForce RTX 3070 GPU. Thanks for those posts! I hope this issue gets noticed by the devs.

I was able to do a new login that worked following NekroSomnias directions.

Glad that helped :D
I've exported my journalctl via journalctl --since today > ~/Desktop/journalctl-export.log and will disassemble that one once i got the time for it.
Its a long log file, so that is gonna take some time but might shine some light on the issue

I also do have a Ryzen 5 3600 CPU and a GeForce RTX 3070 GPU.

That's good to know, i hope we are onto something here.

Little Update :
I've had a quick look at the log this morning and found the following lines, right before i get disconnected from the active Session :
Oct 02 10:35:04 COMPUTER.DOMAIN.NAME setroubleshoot[8761]: SELinux is preventing kwin_wayland from 'read, write' accesses on the chr_file nvidia-modeset.

and
Oct 02 10:35:05 COMPUTER.DOMAIN.NAME sddm-helper-start-wayland[8342]: "kwin_wayland_drm: Presentation failed! Invalid argument\n"
Oct 02 10:35:05 COMPUTER.DOMAIN.NAME sddm-helper-start-wayland[8342]: "kwin_core: Applying output config failed!\n"
Oct 02 10:35:05 COMPUTER.DOMAIN.NAME sddm-helper-start-wayland[8342]: "kwin_wayland_drm: Presentation failed! Permission denied\n"

Note that there is teh hint to run sealert -l fced9120-1a43-4615-b5c3-66eae81adbc2 for more information.
So i did.
This is the output :
SELinux is preventing kwin_wayland from 'read, write' accesses on the chr_file nvidia-modeset.

*****  Plugin device (91.4 confidence) suggests   ****************************

If you want to allow kwin_wayland to have read write access on the nvidia-modeset chr_file
Then you need to change the label on nvidia-modeset to a type of a similar device.
Do
# semanage fcontext -a -t SIMILAR_TYPE 'nvidia-modeset'
# restorecon -v 'nvidia-modeset'

*****  Plugin catchall (9.59 confidence) suggests   **************************

If you believe that kwin_wayland should be allowed read write access on the nvidia-modeset chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'kwin_wayland' --raw | audit2allow -M my-kwinwayland
# semodule -X 300 -i my-kwinwayland.pp

Additional Information:
Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context                system_u:object_r:device_t:s0
Target Objects                nvidia-modeset [ chr_file ]
Source                        kwin_wayland
Source Path                   kwin_wayland
Port                          <Unknown>
Host                          COMPUTER.DOMAIN.NAME
Source RPM Packages
Target RPM Packages
SELinux Policy RPM            <Unknown>
Local Policy RPM              <Unknown>
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     COMPUTER.DOMAIN.NAME
Platform                      Linux COMPUTER.DOMAIN.NAME
                              6.9.12-205.fsync.fc40.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Thu Aug 22 20:33:26 UTC 2024
                              x86_64
Alert Count                   326
First Seen                    2024-08-05 23:46:34 CEST
Last Seen                     2024-10-02 10:43:14 CEST
Local ID                      fced9120-1a43-4615-b5c3-66eae81adbc2

Raw Audit Messages
type=AVC msg=audit(1727858594.192:9961): avc:  denied  { read write } for  pid=6984 comm="maliit-keyboard" name="nvidia-modeset" dev="devtmpfs" ino=1458 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0

Hash: kwin_wayland,xdm_t,device_t,chr_file,read,write

I have never had to troubleshoot anything to do with SELinux, but (as far as i understand this), it seems like SELinux is blocking Wayland to read the DRM Cache (DRM = Direct Render Manager, not Digital Rights Management).
I'll try to figure out, how to allow that, without setting SELinux to permissive mode after i've pulled a Backup of my drive.

It seems like i accidentally fixed my issue.
Had to reset my CMOS yesterday after installing more RAM, since i got some weird post issues (too many Sticks, too high of a frequency, Memory controller wasn't having it). Now the issue seems to be gone.
I replicated the BIOS Settings i had before, just to see, if the issue would pop up again. But no, it seems like my problems just vanished.
I should be happy about that, but the fact, that I don't know what caused the problems just annoys me to no end.

It seems like i accidentally fixed my issue.
Had to reset my CMOS yesterday after installing more RAM, since i got some weird post issues (too many Sticks, too high of a frequency, Memory controller wasn't having it). Now the issue seems to be gone. I replicated the BIOS Settings i had before, just to see, if the issue would pop up again. But no, it seems like my problems just vanished.
I should be happy about that, but the fact, that I don't know what caused the problems just annoys me to no end.

Aha!! So it might be some kind of an issue related to CMOS? You know what, I've recently had this problem that the clock time has been wrong every time I've booted up Windows 10! The clock on Linux has been right from bootup, but I guess it just updates it immediately via online unlike Windows where I had to manually choose to sync the clock . I've suspected that there's something wrong with the CMOS battery but haven't got around to doing anything about it yet. So if the CMOS battery dying is causing the wrong time on Windows, then maybe it's causing this issue on Bazzite?
BTW, thank you very much for doing all this work on this issue!

I’d like to add to this conversation. I have NVIDIA 4060 and i5 13400 and experiencing this same issue. It’s completely random and only shutting down and restarting the machine resolves the issue.

I get this issue a lot actually 🥲 Any news about this ?

I get this issue a lot actually 🥲 Any news about this ?

Yes and no.
The Discussion on Discord died down.
Hikari thinks it might be an Issue on nVidias End and they don't see a solution for it.
The Issue was gone for almost 2 weeks on my end, but came back a few days ago. Even worse than before.
My original workaround (killing the dying session from a TTY) does not work for me anymore.
I have to log out before the session self terminates. After that, i can log in again.
I'm seriously contemplating to rip the m.2 with bazzite out of my system and reinstalling a fresh copy on a spare drive i've got collecting dust.
Just to see, if that's something that happens on the most recent iso.
Was kinda hoping to avoid that, since it's a hassle to get to that specific Drive.

I've been having this issue for a quite some weeks not sure when it started precisely. When you get kicked back to SDDM the issues start when logging in again.
Current solution for me is when login screen shows to just switch sessions to another tty not login and then switch back immediately with ctrl+alt+f2. Then it just drops me back to the desktop and no further issues occur for me until next reboot.
For me this works of course no guarantee for anyone else but maybe worth a try.

I've been having this issue for a quite some weeks not sure when it started precisely. When you get kicked back to SDDM the issues start when logging in again.
Current solution for me is when login screen shows to just switch sessions to another tty not login and then switch back immediately with ctrl+alt+f2. Then it just drops me back to the desktop and no further issues occur for me until next reboot.
For me this works of course no guarantee for anyone else but maybe worth a try.

Yes I made that but after switch, I can't connect Bluetooth device or listen music on Bluetooth device

Current solution for me is when login screen shows to just switch sessions to another tty not login and then switch back immediately with ctrl+alt+f2. Then it just drops me back to the desktop and no further issues occur for me until next reboot.
For me this works of course no guarantee for anyone else but maybe worth a try.

I'd advice against doing that. Your Session will be in a "closing" state, in which many essential Services are either shut down or in the process of being shut down.
That includes - as far as i know - some PAM Services. Those are requiered to do stuff like log on to wifi, connect to network shares and many more.
I don't know, if security might be compromised in that state, but i'd not risk it tbh.
You can verify your session state by running loginctl list-sessions from a terminal.
If your session has the state "closing", just logout and log back in. This currently solves the issue for me.
if it doesn't solve the issue, you can always switch to tty3, run loginctl list-sessions, note the Session that has the "closing" state (usually Session 2) and kill it using loginctl kill-session $number. After that switch to TTY1 (this is where the Greeter/Login Window is spawned) and login normally again.
This was the first workaround i've came up with, which worked for me (and some others) for a while. For some reason, it refuses to work for me at this point.
If i try this, i'll get no display out at all and the system seems to completely freeze. CTRL+ALT+DEL to enforce a reboot works. Just keep that in mind, if you try this yourself.
The workaround from the Bazzite Discord is entierly different. They are somewhat certain, that the issue relates to Nvidia GPUs and Freesync Displays and they recommend unplugging your freesync Display before boot to circumvent this issue entirely.
I haven't tested that one myself, so I can't judge how well that works.

Yes I made that but after switch, I can't connect Bluetooth device or listen music on Bluetooth device

This is expected, because the pam service which handles the Authentification is usually shut down at that point. If you want to connect to a wifi network, you should get an error stating that.
Found that out the hard way too.

I have this too and disabling SELinux is the only reliable (albeit undesirable) solution.
I haven't had a chance to dig into the labeling yet but hopefully someone on the team is actually looking at this rather than saying "nvidia broke it", not being able to login or use the system is a pretty big issue and most users probably wont realize or know hpw to disable selinix...

I had this issue, but rebasing from bazzite-nvidia to bazzite-nvidia-open fixed it. It might be worth trying if you're using a newer (GTX 16 / RTX) card.

Hello again! I thought I should report that I haven't encountered this issue at all anymore as of the last couple of system updates. I don't have anything else useful to say about it, but I would like to know if anyone else has had the issue stop after updating to version 41.20241030 or version 41.20241104 ?

Hello again! I thought I should report that I haven't encountered this issue at all anymore as of the last couple of system updates. I don't have anything else useful to say about it, but I would like to know if anyone else has had the issue stop after updating to version 41.20241030 or version 41.20241104 ?

Finally had the time to update my system.
Can confirm, issue seems to be gone after the latest rounds of updates.
Will close the issue :)


in branch dev-0.3 , use DateFilter plug have err in Dashboard

1.use the DateFilter plug-in in dashboard.
2.choose Date

Please provide detailed operating descriptions for each step.

创建看板（create dashboard)
添加全局过滤器(add global filters）
选择时间类型过滤器（select Date filter)
4.在看板中使用时间过滤控件，选择一个时间 (select any Date )

Looks like a build problem. Please use Node10 LTS version and npm to build frontend project.


Get player stats for lastweek or lastmonth

Adds two additional options for the date argument when calling yf.player.stats(   player_key,   date // optional )
The new options are 'lastweek' and 'lastmonth'. When these options are called the API will return the player's stats for the last week and last month, respectively.
e.g. yf.player.stats( 'nhl.p.7626', 'lastmonth') will return Jeremy Swayman's stats for the last month.

I've been slammed at work and totally missed this! Thanks for doing it! I will merge this in this week and get it published!!


Update dependencies

What problem does this PR solve?
Updating dependencies. This is to get security updates for golang.org/x/text etc.
Done with go get -u
Check List
Tests

No code

/lgtm

/merge


We should prettify numbers

My eyes are bleeding from reading numbers like 80589138 all day. This would free space too.

Sorry, there is a pull request for this but I haven't merged it in.

https://github.com/wchill/steamSummerMinigame/commit/f3d7a67af7a50805aa3788620b55d5a652437bed right?


Feature Request: Add IntelliCode like autocompletion in vscode

Visual Studio has just launched IntelliCode.
It would be great to have same kind of functionality in vscode.

This would be absolutely huge, as a long time Visual Studio + ReSharper user, the ONLY thing holding me back from moving to VS Code is the lack of an exhaustive intellisense extension. JetBrains said in a recent forum post that they have no plans to port ReSharper to VS Code and instead are building a competing IDE with Rider. The community is already turning on them saying that Rider is exactly what they are trying to move away from and moving to VS Code.
There is a massive opportunity here for the IntelliCode & VS Code people to fill a gap and complete the migration for all the VS people who want a lighter cross platform IDE.

There are extensions both for Visual Studio and for VSCode.
Currently the former only supports C# and the latter Python.
However in the announcement blog post on MSDN and the comments @AmandaSilver and @markw-t wote things like

[W]e want to expand to other languages later

We’re looking at support for other languages as we make progress on the IntelliCode features, although we can’t make any commitments at this point.

[W]e definitely see the potential for IntelliCode’s capabilities across many languages

[W]e’ll take feedback from users on which languages we should look to support next as we expand the experiment

By the way the IntelliCode exension for Visual Studio Code now supports TypeScript, JavaScript, Java and Python - hope you find it useful.

@markw-t how does this extend to other languages? Is the IntelliCode extension intending to cover more languages, or is it up to other languages to implement themselves in their own language extensions?

Hey @DanTup
Thanks for the question. Each language has its own "base model" which our data scientists have to train on a large corpus of repos to get typical usages of each type for a given coding context. Then work is done in the relevant IntelliCode client (VS or VS Code) to plumb that model into the completion system.
We don't yet have a public extensibility model that would allow languages to add their own coverage, although that's something we can consider - feel free to raise it as a suggestion on our issues list for others to weigh in and vote on.  There are clear challenges in making the process of model training scale to extenders too, so this is not a trivial problem to solve.
We are taking customer feedback on demand for support for other languages - you'll see several suggestions on the issues page we are tracking for other languages there.  However the team's energies are also focused on broadening IntelliCode's capabilities, for example the new refactorings detection, so there are trade-offs in what gets done first.
Hope that helps clarify the situation - do drop me a line at mwthomas at microsoft dot com if you want to discuss further or have any feedback (good or bad) about IntelliCode.
Cheers
Mark

@markw-t Thanks - I wasn't specifically asking for extensibility support, mostly just interested whether it was already on the cards (and if so what form it would take). I work on the Dart/Flutter extensions, though I suspect other language extension authors probably have the same interest - is there value here that we can provide to our users (it's not clear whether MS are building some specific functionality for some specific languages, or a framework for any language to provide this functionality to their users).
I can open an issue about this, though it might not be much different to https://github.com/MicrosoftDocs/intellicode/issues/2. It's more of a question about what the plans are than a request for something.

Thanks for the clarification @DanTup . Extensibility is not on the immediate backlog and does have a fair bit of work associated as I mentioned, so for now we are closer to your description of making specific functionality for some specific languages.
No harm in opening a language-specific issue for Dart/Flutter to gauge interest in the feature.

for now we are closer to your description of making specific functionality for some specific languages.

Got it, thanks for the clarification! I opened https://github.com/MicrosoftDocs/intellicode/issues/133 about Dart support for people to put 👍 's on.


fix: facade converter on Windows

A fix so that the facade converter in correctly executed on Windows.

The build failure seems to be a flake, but I can't restart.
@mprobst PTAL, this is needed to have a proper dev environment for Angular2 on Windows

Closing in favor of #224


[Model request] DETR / OWLVIT

Normal VIT seems to struggle in my test, maybe these are better for object-detection?

DETR https://huggingface.co/docs/transformers/model_doc/detr
OWL-VIT https://huggingface.co/docs/transformers/model_doc/owlvit

Hi! Thanks for the suggestion. This definitely sounds do-able!
My only concern at the moment would be execution speed, since, the library only supports WASM/CPU backends. WebGPU backend is coming soon though, so, it probably would be a good idea to get started! :)
Could you perhaps provide code snippets / examples for how you intend to use the model? Also, could you explain in more detail what is wrong with the normal VIT? (Perhaps it is too large, and hence, slow?)

Good news! We added support for object detection w/ DETR in v1.3.3 🎉
Demo:
https://user-images.githubusercontent.com/26504141/227374871-51df198d-daab-40bb-8ac5-e1afebacc296.mp4

Example usage:
// npm i @xenova/transformers
import { pipeline } from '@xenova/transformers';

// Allocate object detection pipeline
// (uses 'facebook/detr-resnet-50' by default)
let detector = await pipeline('object-detection');

// Specify image
let img = 'https://xenova.github.io/transformers.js/assets/images/cats.jpg';

let predictions = await detector(img, {
    threshold: 0.9 // default is 0.5
});

which will output:
{
  "boxes": [
    [30.09, 68.47, 187.94, 118.53],
    [329.51, 66.39, 370.07, 192.87],
    [-2.80, 0.13, 636.90, 472.21],
    [6.57, 53.89, 321.98, 468.69],
    [331.87, 21.79, 648.55, 369.94]
  ],
  "classes": [75, 75, 63, 17, 17],
  "scores": [0.998, 0.996, 0.995, 0.998, 0.999],
  "labels": ["remote", "remote", "couch", "cat", "cat"]
}

I will close the issue for now, but we may add owlvit in future.


Fatel error when interpolation in scss

I am using latest version of sass-lint in my project. When I tried to interpolate two variables in the scss file, it throws the fatel error in the sass-lint linter.

Example:
@mixin border($area){
  @each $pos in top, left, bottom, right {
   .#{$area}-#{$pos}-border{
      border-#{$pos}: 1px solid;
    }
  }
}
@include border(header);

.#{$area}-#{$pos}-border{ this line throws the exact error.

Hey @ajithr - Thanks for the report.
It appears to be a duplicate of #644 where the AST has an issue with hyphens and interpolate values.
Please follow #644, and I'll close this one.


Add section on terraform workspaces

It would be great to have a section on terraform workspaces

Thanks for raising this pull request, I'll add this as soon as possible @kishaningithub ! :)


PowerShell Copy-UserInternationalSettingsToSystem cmdlet missing from International module

Hi Team, this documentation shows a cmdlet called Copy-UserInternationalSettingsToSystem which appears to do something I am after for some automation. However this cmdlet is not in the International module (<IP_ADDRESS>) on Windows 10 1909. I have posted about the issue here https://docs.microsoft.com/en-us/answers/questions/230112/powershell-copy-userinternationalsettingstosystem.html.
So either this documentation is ahead of its time and doesn't match what is in Windows or PowerShell is not keeping up with itself. Please review and let me know what you have found.
In spending some hours looking around on this today, I only found 1 other post in uservoice area (1 vote) for someone saying the cmdlet was missing (sorry can't find that link now, but I think that is in the wrong place potentially).
Thanks heaps.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7004729a-2d93-6c6f-6b80-6411bc97aabb
Version Independent ID: 98f3eb92-4777-ef78-aa79-35b40b964631
Content: Copy-UserInternationalSettingsToSystem (International)
Content Source: docset/windows/international/Copy-UserInternationalSettingsToSystem.md
Product: w10
Technology: ****
GitHub Login: @erik0686
Microsoft Alias: ertorres

The link again which didn't work in original post:
https://docs.microsoft.com/en-us/answers/questions/230112/powershell-copy-userinternationalsettingstosystem.html
What's news here after near 3 weeks?
Considering calling Premier support next so I can carry on with my work.
Thanks.

I second this issue ... The command is documented by appears to be missing, and I could certainly use it.
In the mean time do we know of an alternative to this command that might do the same thing?

So it appears Microsoft has now removed the web page (sub page to International module) where this command would be.
https://docs.microsoft.com/en-us/powershell/module/international/?view=win10-ps
So that means we have no command and no documentation any longer. Aligned yes, good start. Why was the page removed?
More importantly, when will this command be available?

I'm trying to set a number of "international" settings for machines being deployed via Autopilot. The OOBE options are limited, so some other means must be used. Technically it appears the International PowerShell commands could work, if that copy command existed and worked. Since it doesn't, I've reverted to using control.exe intl.cpl,,/f:somexmlfile.xml ... it works, but is an outdated approach that may eventually die once the control panel fully disappears, so hopefully it'll be sorted out before then!

Hello, It seems that the documentation too has been removed from the repository along with the command itself.
Since the article does not exist in the repository, the best course of action might be to consult Feedback Hub for this problem.
Thanks.


  A pr contains all changes in a folder.

This change is

@nashasha1 Under tutorials/stateless-application/, these files are no longer used in the docs. Please use this PR to delete them:
deployment-scale.yaml
deployment-update.yaml
This file is still used. So go ahead with the version bump:
deployment.yaml

/hold

@steveperry-53  Done. Thanks for help.

/assign @steveperry-53

/hold remove

/approve
/lgtm

/hold cancel


WIP: Add command-line interfaces

This is WIP, but pushing up to get feedback early.
I've added 3 new crates: tabasco-cli, sinaloa-cli, and durango-cli. These are thin layers over their respective crates that provide a command line interface, making it a bit easier to experiment with Veracruz as a whole.
TODO:

[x] Add GETTING_STARTED_CLI.md
[ ] Add tests, run in CI
[ ] Cleanup TODOs (either via fixes or issues)
[x] Rebase onto master
[ ] Update docs (quite a bit changed)

Should resolve https://github.com/veracruz-project/veracruz/issues/63

$ ./bin/tabasco --help
tabasco-cli 0.1.0

USAGE:
    tabasco [OPTIONS] <policy-path>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
        --database-url <database-url>
            URL or path to database, may also be provided through the
            DATABASE_URL environment variable

ARGS:
    <policy-path>    Path to policy file

$ ./bin/sinaloa --help
sinaloa-cli 0.1.0

USAGE:
    sinaloa <policy-path>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

ARGS:
    <policy-path>    Path to policy file

$ ./bin/durango --help
durango-cli 0.1.0

USAGE:
    durango [FLAGS] [OPTIONS] <policy-path> --identity <identity> --key <key>

FLAGS:
    -h, --help
            Prints help information

    -n, --no-shutdown
            Do not request a shutdown of the Sinaloa server after recieving the
            results. This can be useful if you have multiple result readers
    -s, --shutdown
            Request shutdown without requesting data.

            Note: This requires "ResultReader" permissions in the policy file.
    -V, --version
            Prints version information

OPTIONS:
    -d, --data <data>...
            Specify optional data file to upload

            Accepts "-" to read from stdin

            Note: This requires "DataProvider" permissions in the policy file.
    -i, --identity <identity>
            Path to client certificate file

    -k, --key <key>
            Path to client key file

    -o, --output <output>
            Specify optional output file to store results. If not provided the
            results will not be fetched.

            If --no-shutdown is not provided, Durango will request a shutdown
            from the Sinaloa server after recieving the results.

            Accepts "-" to write to stdout

            Note: This requires "ResultReader" permissions in the policy file.
            [aliases: result]
    -p, --program <program>
            Specify optional program file to upload

            Accepts "-" to read from stdin

            Note: This requires "PiProvider" permissions in the policy file.

ARGS:
    <policy-path>
            Path to policy file

And here's what the flow currently looks like:
$ ./bin/tabasco test-collateral/one_data_source_policy.json --database-url=tabasco-cli/tabasco.db  &
[2021-02-04T11:03:05Z INFO  tabasco] Loaded policy 7b52a497558ed4c0b82d86a32c793fb2280b89baf29ea57e7d12bd643b22bd2e
[2021-02-04T11:03:05Z INFO  tabasco] Using database "tabasco-cli/tabasco.db"
[2021-02-04T11:03:05Z INFO  actix_server::builder] Starting 12 workers
[2021-02-04T11:03:05Z INFO  actix_server::builder] Starting "actix-web-service-<IP_ADDRESS>:3010" service on <IP_ADDRESS>:3010
[2021-02-04T11:03:05Z INFO  tabasco] Tabasco running on <IP_ADDRESS>:3010

$ ./bin/sinaloa test-collateral/triple_parties_two_data_sources_string_edit_distance_policy.json &
[2021-02-04T16:13:40Z INFO  sinaloa] Loading policy "test-collateral/triple_parties_two_data_sources_string_edit_distance_policy.json"
[2021-02-04T16:13:40Z INFO  sinaloa] Loaded policy 540ceaa99e4d68013b00b91d518f8a5eb2a67bcfb1150a1c44202ff1a894a9da
[2021-02-04T16:13:44Z INFO  actix_web::middleware::logger] <IP_ADDRESS>:33552 "POST /Start HTTP/1.1" 200 96 "-" "-" 0.000378
[2021-02-04T16:13:45Z INFO  actix_web::middleware::logger] <IP_ADDRESS>:33554 "POST /SGX/Msg1 HTTP/1.1" 200 308 "-" "-" 0.470692
[2021-02-04T16:13:46Z INFO  actix_web::middleware::logger] <IP_ADDRESS>:33558 "POST /SGX/Msg3 HTTP/1.1" 200 25 "-" "-" 0.696021
[2021-02-04T16:13:46Z INFO  actix_server::builder] Starting 12 workers
[2021-02-04T16:13:46Z INFO  actix_server::builder] Starting "actix-web-service-<IP_ADDRESS>:3019" service on <IP_ADDRESS>:3019
[2021-02-04T16:13:46Z INFO  sinaloa] Sinaloa running on <IP_ADDRESS>:3019

$ ./bin/durango test-collateral/triple_parties_two_data_sources_string_edit_distance_policy.json --identity test-collateral/program_client_cert.pem --key test-collateral/program_client_key.pem --program test-collateral/string-edit-distance.wasm
[2021-02-04T16:16:32Z INFO  durango] Loading policy "test-collateral/triple_parties_two_data_sources_string_edit_distance_policy.json"
[2021-02-04T16:16:32Z INFO  durango] Loaded policy 540ceaa99e4d68013b00b91d518f8a5eb2a67bcfb1150a1c44202ff1a894a9da
[2021-02-04T16:16:32Z INFO  durango] Connected to <IP_ADDRESS>:3019
[2021-02-04T16:16:33Z INFO  durango] Submitted program "test-collateral/string-edit-distance.wasm"

$ ./bin/durango test-collateral/triple_parties_two_data_sources_string_edit_distance_policy.json --identity test-collateral/data_client_cert.pem --key test-collateral/data_client_key.pem --data test-collateral/hello-world-1.dat
[2021-02-04T16:17:19Z INFO  durango] Loading policy "test-collateral/triple_parties_two_data_sources_string_edit_distance_policy.json"
[2021-02-04T16:17:19Z INFO  durango] Loaded policy 540ceaa99e4d68013b00b91d518f8a5eb2a67bcfb1150a1c44202ff1a894a9da
[2021-02-04T16:17:19Z INFO  durango] Connected to <IP_ADDRESS>:3019
[2021-02-04T16:17:19Z INFO  durango] Submitted data "test-collateral/hello-world-1.dat"

$ ./bin/durango test-collateral/triple_parties_two_data_sources_string_edit_distance_policy.json --identity test-collateral/result_client_cert.pem --key test-collateral/result_client_key.pem --data test-collateral/hello-world-2.dat -o result.out
[2021-02-04T16:18:49Z INFO  durango] Loading policy "test-collateral/triple_parties_two_data_sources_string_edit_distance_policy.json"
[2021-02-04T16:18:49Z INFO  durango] Loaded policy 540ceaa99e4d68013b00b91d518f8a5eb2a67bcfb1150a1c44202ff1a894a9da
[2021-02-04T16:18:49Z INFO  durango] Connected to <IP_ADDRESS>:3019
[2021-02-04T16:18:49Z INFO  durango] Submitted data "test-collateral/hello-world-2.dat"
[2021-02-04T16:18:49Z INFO  durango] Read results into "result.out"
[2021-02-04T16:18:49Z INFO  durango] Shutdown server

$ xxd -g1 result.out
00000000: 00 00 00 00 00 00 f0 3f                          .......?

Though need to add a sort of GETTING_STARTED_CLI.md to capture this a bit better.

https://github.com/veracruz-project/veracruz/discussions/66 is also related, since whether or not use use logging vs println greatly affects the CLI interaction.

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 5d11a6a10afb635d8a51eb7f623e9a8849164b54
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 6ab42c694f235e88c8602df6b5c95ffa295467b3
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: e693d5d56af6b55cc0550e0f1941216919253f36
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: d3273827eb012b2448f2a2b1f6184c5799234437
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 87ef5a9a478ccc9b0a9514a54fe92fdc2695ca17
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: e4569821193cf6b5e1fa66976627aa2d73ef912e
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: b13ccdda7713634f23a30ca53a29601419a4e679
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: eb0de5b85bcc7b710bb7131452206c5ba793ddbe
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: aa9c110400d354cf9cdba427d1106bfdd5ae70fe
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 7eef3f6de3edccb67c3385a12a793ca7e2fd4ff3
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 639cfb7fcb33c0aaeb79565ccbf220cbe4f94850
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 881eaa9a2ee46e8117c62b723cc1a53bbcce1b30
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 3b180c3157707659123dc94bab899a0f48a3a5dd
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: d41c27c8a812c059c2485cf276ca46ba79bd1fa8
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 239d7b7a93fe6e0d1cbe22a6d44ecd90ec603d84
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 754b48222108d9a0af84711cb4e4283cc80a7047
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 3dbf875fa9970dd84fb66c30d5d488aac6254b50
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 784e9391f040667af143736638fd326b7b6bfff4
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: e5c8aa3bfb1329b1071bd16d62eba85c06bcadc6
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: de943baf84931833ec7b9c491983052883eb16f0
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: d25bf81a28929b4a4ad190d3b56a17d2a1f517d0
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

I'm still waiting on CI (it works on my machine, shakes fist), but in the meantime I've updated this PR to finish the other tasks.
It should be good to review now, at the time of writing this I believe I've responded to all of the existing review comments.
I broke a couple TODOs out into separate PRs to handle after this PR is complete:

https://github.com/veracruz-project/veracruz/issues/173
-https://github.com/veracruz-project/veracruz/issues/174

Once CI is passing I will clean up the commit history and then this should be good to go.
cc @dominic-mulligan-arm

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 9b3d07e33357c4eb07101c43f80775e4572d5306
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

If there's new reviewers, the bulk of what's new in this PR is documented in GETTING_STARTED_CLI.md:
https://github.com/veracruz-project/veracruz/blob/9b3d07e33357c4eb07101c43f80775e4572d5306/GETTING_STARTED_CLI.markdown
This PR adds several command-line wrappers, as a part of this I've shortened the names to be more CLI friendly, though note the long-form names are still available:

veracruz-client -> vc-client
veracruz-server -> vc-server
proxy-attestation-server -> vc-pas
generate-policy/pgen -> vc-pgen
freestanding-execution-environment -> vc-fee
wasm-checker -> vc-wc

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 7420b7927394b2f320f0af9c819268663bdc27d0
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: bafb5c9095e9c80ed5a3dc29f08e58d6473cc801
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 035ed70f4962f8d2b1cd5aaecdfb1ecd7c143e42
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 9aaf889349a60213449f1489bd6aef2a5d9693a2
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 7b5d14a758b085b5b6d75c95e3ca238e49fe5d5b
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: e6eb331da63c54d5a922247c509216c46397c4ab
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 7fae534c08445a312bddd3dedfdc6dc1a229e0aa
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 4787c72c0f3f6f856ab17c8bba11ce69dab49daf
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 9b476266b9153efd41069bc0d364fb9c80cb2774
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: b1654cb8441730ad180b3b1b7ba9651e0804dc77
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID:<PHONE_NUMBER>7532a0733fa60eb1fd9305e357bcca
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

More related issues created:

https://github.com/veracruz-project/veracruz/issues/173
https://github.com/veracruz-project/veracruz/issues/174
https://github.com/veracruz-project/veracruz/issues/175
https://github.com/veracruz-project/veracruz/issues/176

And I believe the last batch of review comments have been answered unless I missed any

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: abffe65bc4b5e8f492d19b20394826adf4633d12
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

Great work, @geky.  Do you want this merged now?  There was some discussion on Slack about the ordering of merges.

May be good to give @dreemkiller a chance to review, the last patch touches attestation.rs


ur-move-1@0-0

Press Submit! You don't need to edit this text or do anything else.
Be aware that your move can take a minute or two to process.

oops bad timing we're on the same team haha @1ethanhansen


I a withdrawal, display is invalid.Who can tell me how to solve?THX.

I withdraw from the Liqui.
After 24 hours, the query Txid is invalid.
There is no order, no back to my original account.
Who knows how to solve this kind of "invalid" situation?

Hey @495880776, can you please post a transaction id?

Please feel free to reopen this issue or create a new one, if you have new input.


Connectivity issues on Openstack clusters due to proxy protocol

Description
There is an issue with connectivity on Openstack clusters. This issue is related to the X-Forwarded-For header, more precisely the proxy protocol that is used to forward the client IP. The Istio module applies an EnvoyFilter to handle the proxy protocol.
This filter should be only applied on AWS instances. To determine if running on AWS, the Istio module queries the AWS instance metadata service (IMDS).
The problem is that Openstack supports two APIs for its IMDS, an Openstack metadata API and the EC2 metadata API.
For this reason the Istio module will create an EnvoyFilter proxy protocol. If the proxy protocol EnvoyFilter is applied and the request does not contain the proxy protocol the requests will be discarded.
Expected result

Connection to exposed workloads is working.
Actual result

Connection to exposed workloads results in Connection reset by peer.
Steps to reproduce

Enable istio module
Deploy httpbin app
Create VirtualService to expose httpbin
Call exposed domain

Troubleshooting
Apply the following EnvoyFilter to remove the proxy_protocol filter from the listener chain.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: remove-proxy-protocol
  namespace: istio-system
spec:
  configPatches:
  - applyTo: LISTENER_FILTER
    match:
      listener:
        listenerFilter: "proxy_protocol"
    patch:
      operation: REMOVE
  workloadSelector:
    labels:
      istio: ingressgateway

please repeat perf tests on openstack test cluster once this is fixed

/assign

Okay, so basically since it's all over Gardener and other weird functionality we somehow need to know on which provider the k8s cluster is running. I can actually get that information from the node configuration under spec.providerID the id contains a prefix that basically describes the hyperscaler.
Initial idea is to replace current EC2 endpoind probing with parsing this providerID from 1st node on the list. It's hacky and I don't like it, but should be more precise about which provider is used:
Mapping:
AWS = "aws://"
OpenStack = "openstack://"
GCE = "gce://"
and so on...


Log file is empty after logrotate

Hi,
After logrotate execution, my log file is empty :
root@clagra-pn20:/var/log/influxdb# ll
total 224
-rw-r--r-- 1 influxdb influxdb      0 Oct 31 06:25 influxd.log
-rw-r--r-- 1 influxdb influxdb 225433 Oct 31 06:25 influxd.log.1.gz

A restart of influxdb daemon fixes the problem (influxd.log is filled again).
My release is :
2015/10/30 12:09:43 InfluxDB starting, version 0.9.5-nightly-4e2a16c, branch master, commit 4e2a16c459183e0adc5946b242d014b2090de206, built '2015-10-29T04:00:42+0000'
2015/10/30 12:09:43 Go version go1.5.1, GOMAXPROCS set to 16

Thanks

@Issif What Linux distribution and version are you using?

Sorry :
OS ................... Debian 7.8 "wheezy"
Kernel ............... 3.2.0-4-amd64

Logrotate release
3.8.1-4

InfluxDB :
version 0.9.5-nightly-4e2a16c, branch master, commit 4e2a16c459183e0adc5946b242d014b2090de206, built '2015-10-29T04:00:42+0000'

Go version :
go1.5.1, GOMAXPROCS set to 16

Thanks

@rossmcdonald -- perhaps we should confirm that the distros we do run on actually work? Force a rotate to take place and check if influxd writes to the new file?

@Issif are you using the logrotate file that shipped with the package or one you write yourself?
@rossmcdonald does our logrotate file have copytruncate set?

copytruncate is set.
https://github.com/influxdb/influxdb/blob/master/scripts/logrotate
Nothing has changed in this file since you wrote it.
On Tuesday, November 3, 2015, Sean Beckett<EMAIL_ADDRESS>wrote:

@Issif https://github.com/Issif are you using the logrotate file that
shipped with the package or one you write yourself?
@rossmcdonald https://github.com/rossmcdonald does our logrotate file
have copytruncate set?
—
Reply to this email directly or view it on GitHub
https://github.com/influxdb/influxdb/issues/4635#issuecomment-153429003.

The behavior strongly suggests that copytruncate is not working. This is the exact issue that flag is meant to prevent.
@Issif when the log file rolls over, does the inode of influxdb.log stay the same? It should, if copytruncate is working as expected.

I think I found why copytruncate  doesn't work.
I still have a relic of a previous install :
root@clagra-pn20:/etc/logrotate.d# ll influx*
-rw-rw-r-- 1 root root 113 Sep 29 19:51 influxd
-rw-r--r-- 1 root root 110 Jul  3 16:43 influxdb

with :
root@clagra-pn20:/etc/logrotate.d# cat influxd
/var/log/influxdb/influxd.log {
    daily
    rotate 7
    missingok
    dateext
    copytruncate
    compress
}

and
root@clagra-pn20:/etc/logrotate.d# cat influxdb
/var/log/influxdb/*.log {
    daily
    maxsize 512M
    rotate 7
    compress
    missingok
    notifempty
}

So, with ABC order, influxd has been played and  influxdb just after. The first one keeps  inode and the second doesn't.
I'll remove /etc/logrotate.d/influxdb  and restart the daemon, I'll see tomorrow if it works.
Thanks.

@Issif Thank you for the update. That would make sense if there were conflicting logrotate files. We will be adding a check for legacy logrotate files in the post-installation step of the next release, so hopefully this problem will be avoided in the future.
Let us know what you find out.

Hi,
It works fine, you can close this issue.
-rw-r--r-- 1 influxdb influxdb 978216 Nov  9 09:45 influxd.log
-rw-r--r-- 1 influxdb influxdb 483636 Nov  6 06:24 influxd.log-20151106.gz
-rw-r--r-- 1 influxdb influxdb 249525 Nov  7 06:24 influxd.log-20151107.gz
-rw-r--r-- 1 influxdb influxdb 249833 Nov  8 06:22 influxd.log-20151108.gz
-rw-r--r-- 1 influxdb influxdb 277320 Nov  9 06:24 influxd.log-20151109.gz

Thanks again.


Add option to expand tabs to fill tab bar

Closes #44.
I added an option to Style and added a checkbox to the hello example to demonstrate its use.
For #43, the calculation of expanded_width in lib.rs will need tweaking to subtract the width of the add-tab button from the available width, which should be painless. If that gets merged first I can update this PR as appropriate.

Just fix the CI errors and I'm going to merge this

Thanks! Looks like one error is from clippy on Style::tab_title() now having too many arguments (7 -> 8). I can't see any obvious ways to combine arguments though, except maybe grouping the focussed/active/is_being_dragged bools together. Do you have any ideas, or shall I just add an exception for this method?

Add an exception for now, we're gonna need to refactor tab_title at some point.

:+1:, done


[Help] How can I do to add emoji to toolbar?

Please help me, how can I do to add emoji to toolbar?
Thanks!

Unfortunately we currently do not support emoji toolbar or custom commands.

@volmer Could you suggest a custom approach that would allow customization of the toolbar, in any case? Even if it's a bit of a hack...


make not working

Hi,
I run macports, so I had to install libimobiledevice to /opt/local/ to avoid conflicts. Nothing should be installed to /usr/local/bin.
I have MP set to use clang 4 (mp-clang-4.0) and set the CC environmental variable to clang-mp-4.0, which is located in opt/local/bin (I'm aware of the syntax mismatch). CFLAGS is set to '-O2 -arch x86_64 -arch ppc64 -arch i386 -arch ppc'.
I am pretty sure this version of clang supports blocks.
When I try to compile afcclient, as root, I get the following:
sh-3.2# pwd
/users/<login_account>/afcclient-master
sh-3.2# make
clang    -c -o afcclient.o afcclient.c
In file included from afcclient.c:30:
./libidev.h:17:10: fatal error: 'libimobiledevice/libimobiledevice.h' file not found
#include <libimobiledevice/libimobiledevice.h>
	`^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`

1 error generated.
make: *** [afcclient.o] Error 1
sh-3.2# ls -fs /opt/local/include/libimobiledevice reveals that the header file libimobiledevice.h is installed as expected.
Where did I go wrong?
Thank you for any help you can provide.
Best,

There is a flaw in the code.

Try specifying LDFLAGS and CFLAGS when you run make, as follows:
$ LDFLAGS="-L/opt/local/lib" CFLAGS="-I/opt/local/include" make


[0.5pt] Preserve data (Game & Author)

All data should be preserved by saving collections in .json files.

Hi @iankiema
Your project is complete! There is nothing else to say other than it's time to merge it :shipit:
Congratulations! 🎉
You can now move to next project.


Demo Build Error

I'm getting the following error when running npm run build:
error[E0599]: no variant named `concat` found for type `syntax::tokenstream::TokenStream` in the current scope

   --> /Users/igagen/.cargo/registry/src/github.com-1ecc6299db9ec823/pear_codegen-0.0.20/src/lib.rs:330:54
    |
330 |                 mac.node.tts = ThinTokenStream::from(TokenStream::concat(streams));
    |                                                      ^^^^^^^^^^^^^^^^^^^ variant not found in `syntax::tokenstream::TokenStream`

I've updated everything to the latest (running on Mojave):
rustc 1.33.0-nightly (e40548bc4 2018-12-21)
node v11.5.0
I've also done a brew update/upgrade and cargo update as well.
Any ideas how to get past this?

Hi there.
I got the same error few minutes ago and just fixed it by rolling my rust toolchain for the project to a few days back more precisely on the latest commit date: december 5th. Seems like pear-codegen didn't like rust 1.33.0-nightly.
To roll back the toolchain for the current project folder:
rustup toolchain install nightly-2018-12-05
rustup override set nightly-2018-12-05

I just tried that but I'm still getting the same error. Any other steps to that I might have missed? Do I need to clean out any build artifacts?

Ah never mind, I was in the /demo/client/ folder. Did the override from the root project folder and it worked like a charm. Thanks @marschr !


1.14.3 (fabric) light indicator Showing on mushroom Biome

Seems well in a mushroom Biome, it is showing the yellow x's that, mobs could possibly spawn there. Could be detection isn't picking it up as something that spawn-able, also since the biome name should have changed from mushroom island -> mushroom fields, & the shore lines -> mushroom field shore.

Could also need to factor that fix in for forge version.

Please test on the new update:
Fabric: v1.2.1
Forge: v1.1

Closing this issue, please create another issue if this continues to occur.


Update how-to-test-private-endpoint.md

Dropping the note on regional availability as private endpoint support is now available in all the regions where Azure Load Testing is available.

#sign-off

#sign-off


Namecheap API returns HTML encoded characters

I know this script is a little old but one problem I ran into is I had a record that looked like this:
CAA 0 issue "letsencrypt.org"
The problem is the Namecheap API returns this records address/value as 0 issue "letsencrypt.org".
Then we get an error <Error Number="2050900">The CAA record is invalid.</Error> from the API.
To fix this I had to add replace:
ADDRESS=$(echo $line|sed 's/^.* Address="\([^"]*\)".*$/\1/g')
With:
ADDRESS=$(echo $line|sed 's/^.* Address="\([^"]*\)".*$/\1/g'|recode html..ascii)
Using record third party tool to reencode the html entities.
Not the best solution but a quick hack to get it working.

EDIT: I used this script for many years, it worked for me but it was always terrible slow with DNS verification (and it would often fail).
I am now using https://github.com/acmesh-official/acme.sh with their Namecheap DNS method and it works very well and quickly too (~20 seconds to verify DNS for each domain).


VertexArray# should not return a copy of the Vertex

It seems VertexArray#[](index) returns a copy of Vertex at index instead of the original instance.
Look:
vertex_array = SF::VertexArray.new(SF::Quads, 4)

puts vertex_array[0].position.inspect
# SF::Vector2(Float32)(@x=0, @y=0)

vertex_array[0].position = SF.vector2(64, 128)

puts vertex_array[0].position.inspect
# SF::Vector2(Float32)(@x=0, @y=0)

The workaround is creating a new vertex and overwriting it:
vertex_array = SF::VertexArray.new(SF::Quads, 4)

puts vertex_array[0].position.inspect
# SF::Vector2(Float32)(@x=0, @y=0)

vertex = SF::Vertex.new
vertex.position = SF.vector2(64, 128)
vertex_array[0] = vertex

puts vertex_array[0].position.inspect
# SF::Vector2(Float32)(@x=64, @y=128)

This is true. This is how structs work. This is not the only place where this problem is present.
I gave this a lot of thought today, and there is nothing I can do to change this. Making a class-based wrapper is a huge performance hit.
The only way to not copy a struct is to use pointers, and that's just not an option.
C++ code relies a lot on the mutability of these structs. The mindset here should be different to avoid the need to edit structs.
Compare: original (broken), remade examples


idris2: 0.3.0 → 0.4.0

Things done

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

[x] 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 nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

On macos 10.15:
builder for '/nix/store/fnf5r8wb5dyamszhhfyvszj28vhg0v4s-idris2-0.4.0.drv' failed with exit code 2; last 10 log lines:
  make[1]: Entering directory '/private/tmp/nix-build-idris2-0.4.0.drv-0/source'
  make -C libs/prelude IDRIS2=/private/tmp/nix-build-idris2-0.4.0.drv-0/source/build/exec/idris2 IDRIS2_PATH="/private/tmp/nix-build-idris2-0.4.0.drv-0/source/libs/prelude/build/ttc:/private/tmp/nix-build-idris2-0.4.0.drv-0/source/libs/base/build/ttc:/private/tmp/nix-build-idris2-0.4.0.drv-0/source/libs/contrib/build/ttc:/private/tmp/nix-build-idris2-0.4.0.drv-0/source/libs/network/build/ttc:/private/tmp/nix-build-idris2-0.4.0.drv-0/source/libs/test/build/ttc"
  make[2]: Entering directory '/private/tmp/nix-build-idris2-0.4.0.drv-0/source/libs/prelude'
  /private/tmp/nix-build-idris2-0.4.0.drv-0/source/build/exec/idris2 --build prelude.ipkg
  /private/tmp/nix-build-idris2-0.4.0.drv-0/source/build/exec/idris2: line 11: zsh: command not found
  make[2]: *** [Makefile:2: all] Error 127
  make[2]: Leaving directory '/private/tmp/nix-build-idris2-0.4.0.drv-0/source/libs/prelude'
  make[1]: *** [Makefile:71: prelude] Error 2
  make[1]: Leaving directory '/private/tmp/nix-build-idris2-0.4.0.drv-0/source'
  make: *** [Makefile:200: bootstrap] Error 2

Thanks for the help testing @risicle. I am a bit confused by the error, do you use zsh?

Hi! Thanks for digging into this and working on upgrading to the newest version so quickly :).
I just saw that Idris2 now has its own nix derivation (which started out as essentially a copy of our derivation). It would make way more sense for the package owners to maintain their own derivative, so we should probably convert ours to a stub, which will make upgrading (probably) way easier. Something like:
{ lib, stdenv, fetchFromGitHub, callPackage }:

let
  pname = "idris2";
  idris2-version = "0.4.0";

  gitSource = fetchFromGitHub {
    owner = "idris-lang";
    repo = "Idris2";
    rev = "v${idris2-version}";
    sha256 = "105jybjf5s0k6003qzfxchzsfcpsxip180bh3mdmi74d464d0h8g";
  };
in
  callPackage (gitSource + "/nix/package.nix") { inherit idris2-version; }

(plus some overrides to get meta correct)
I'll give it a go sometime this week, but if you want to give it a whirl before that, you'd be more than welcome.

Hey @wchresta, I would advise against that since there is an open issue that might end up in the removal of upstream nix support.

Added notes to commit message as requested @wchresta:

Added notes to commit message as requested @wchresta:

Great, many thanks. Lgtm; all we need to figure out now is what's the deal with macos

Maybe a @NixOS/darwin-maintainers could help out, I don't have access to a MacOS computer unu

The issue is the way default Idris2 wrappers get the local directory.
sed 's/Darwin/FakeSystem/' -i bootstrap.sh in the patchPhase would let you build the compiler, but I can't confirm that we can run any scheme executable produced by it. In idris2-pkgs, I also needed to patch output binaries to make them run in Nix.

Result of nixpkgs-review pr 127948 run on x86_64-darwin 1

1 package failed to build:

idris2

Tested on NixOS, seems fine.
One thing that caught my eye is that the created output program when compiling an idris2 application contains the Darwin-check, too:
$ idris2 hello.idr -o hello
$ vi ./build/exec/hello

#!/bin/sh

set -e # exit on any error

if [ "$(uname)" = Darwin ]; then
  DIR=$(zsh -c 'printf %s "$0:A:h"' "$0")
else
  DIR=$(dirname "$(readlink -f -- "$0")")
fi
export LD_LIBRARY_PATH="$DIR/hello_app":$LD_LIBRARY_PATH
"$DIR/hello_app/hello.so" "$@"

So the check is part of the produced output, and not just the idris2 compiler. I strongly suspect that the proposed fix above will fix the compiler, but will not fix the produced binaries for MacOS.

or we can try to get this fixed upstream (which might be better)

Yeah seems like an upstream bug :?

Opened an issue upstream: https://github.com/idris-lang/Idris2/issues/1612

Well, seems like zsh is now a dependency for macOS, going to add it then.

Added zsh as a nativeBuildInput for macOS

After thinking about it some more (and realizing I'm an idiot), the scheme executable that idris2 produces should not (and do not) depend the nix-store. Instead, they depend on whatever is linked in the current environment. So, executables that idris2 produces depend on the environments sh, scheme, zsh, etc, and not on the one that we build idris2 with. This is because the produced executables should run independently of what is in the nix store (otherwise the behaviour would be really weird).
As such, we have made the decision to not propagate dependencies, since it doesn't make sense (and I just forgot that I thought this through in the past already). So as long as idris2 builds in macOS, it's ok that the resulting executables depend on zsh (that is in PATH, not in nix-store). Likewise, the executables on linux and nixos depend on the path's scheme and racket and not the one in path. It's the users responsibility to make sure there's always a scheme.
As such, we don't need the propagations and macOS should be fixed with the addition of zsh as a build dependendy. Sorry about the confusion I caused.

No worries, commiting your suggestion

/cc @Mic92


MEMBERSHIP: @jastang

GitHub Username
@jastang
Requirements

[x] I have reviewed the community membership guidelines
[x] I have enabled 2FA on my GitHub account
[x] I have joined the Crossplane slack channel
[x] I am actively contributing to the Crossplane project
[x] I have two sponsors that are current Crossplane Org members
[x] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application

Sponsors

@negz
@jbw976

List of contributions to the Crossplane project

Working with awesome folks @ Upbound!
Occasional engagement in Crossplane Slack helping answer questions

+1 - Jason is leading a team building product around Crossplane at Upbound. Thanks @jastang!

+1 from me as well, excited for @jastang to have more impact on the project!

Invite has been sent to @jastang!


feat: update ResultDisplay to ResultPanel

Update ResultDisplay to ResultPanel
ResultPanel has more space for future command output, including support for lists and images. This Version of ResultPanel is only a foundation and supports Text Based outputs

@NatLeong I decided to only make the results box flex with resize since the person list doesnt display any info anyways. You can change the width of the Person Card if its too small also


Fix error message for bad input in GEARS.predict()

An error message, gears.py L220, previously read "Please select from GEARS.gene_list", but the code checks GEARS.pert_list, not GEARS.gene_list. I updated the error message to point users to GEARS.pert_list.

Thanks!


Fake delegates with AutoFakeItEasy

Fixes #984.

I took the suggested approach, augmenting the MethodQuery and adding an additional customization.
I couldn't find precedent for some of the test implementation choices I made.
The 3rd commit, extracting a base class so we could run all tests against all fixtures, could be dropped entirely, at your option.
And I used a compile constant to avoid trying to fake delegates when we're testing with the oldest of the FakeItEasy versions.
I'm happy to change absolutely anything, and/or squash before merge, if you'd like. No comment is too small!

@blairconrad Thanks a lot for your contribution. Let me think a bit about this feature and get back to you with feedback when I finish.

A pleasure, @zvirja. Take your time.
While you're thinking, I didn't want to push my agenda earlier, since I'm not an AutoFixture user, but I've always thought that once someone decides to use one of the mocking plugins such as AutoFakeItEasy, they might want to use the mocker to create all objects that it can, so all the delegates and interfaces (including the collections that are built into AutoFixture's core) and so on. If you think that would be a better way to go, I could adapt this solution. Or not!
Happy pondering. 🤔

I've finally reviewed the PR and would like to share my thoughts.
The introduced implementation contributes a couple of drawbacks to API:

Now we have EnableAutoFakeItEasyForDelegatesCustomization that enables redirection of the delegate requests to Fake<TDelegate>. However, the issue is that this customization doesn't work properly if you don't apply AutoFakeItEasyCustomization before. It's very unclear from the user's perspective and it's really confusing.

If we look e.g. at NSubstitute, we'll see that we currently have two customizations: AutoNSubstituteCustomization and AutoConfiguredNSubstituteCustomization. The difference is that the former customization simply redirects interface and abstract classes to the mocks, while the latter one additionally configures all the fields/properties/methods to return automatically configured value. It could happen that we decide to have the similar customization for the FakeItEasy in future and we'll start to observe inconveniences (in fact, we already have them if we decide to follow the same approach with Moq). The major issue is that delegate generation feature adds a dimension, so number of customizations (like AutoFakeItEasyWithDelegatesCustomization) should be doubled (i.e. abstract, delegates + abstract, configured abstract, configured  delegates + abstract). I don't like that at all 😢

I see a few ways how to we could work with that keeping the consistency of our API across all the glue libraries.
Way 1 - Simpler
Given that delegates produced by AutoFixture are not that special, we can unconditionally redirect delegate generation to the FakeItEasy. Meaning, that it's a part of the AutoFakeItEasyCustomization now.
I'm not sure whether it's a breaking change or not. In fact, it changes the behavior, as currently delegates return the automatically generated value, while faked delegates will return the default value. In theory it could break the existing tests, however it shouldn't be a big problem as the risk is small.
Way 2 - Make customization customizable :)
This way is a bit more generic and allows to specify how exactly you would like to customize the fixture. In fact, the AutoFakeItEasyCustomization (and similar customizations we have in other glue libraries) is a facades around the bricks shipped with the glue library. Therefore, this class already contains multiple responsibilities. I don't see it a big problem if we add some flags, allowing to specify how exactly this customization behaves.
API might be like following:
fixture.Customize(new AutoFakeItEasyCustomization
                  {
                      GenerateDelegates = true
                  });

It means that we should align our other glue libraries as well and obsolete the AutoConfigured... customizations in favor of the flags:
fixture.Customize(new AutoMoqCustomization
                  {
                      ConfigureMembers = true
                  });

It's a larger change, but it's a positive one, as it provides much better extensibility model. Also now we have the single "entry point" for the glue library.
Given all the stuff around, it's a preferable way to me (I really like idea of having the single entry point for glue libraries).

they might want to use the mocker to create all objects that it can, so all the delegates and interfaces (including the collections that are built into AutoFixture's core) and so on.

While this behavior looks aligned and logical, I have a bit different vision about it. For me, the top priority is the convenience during the test creation. When you have collection interfaces, in most cases you expect them to behave like collections (i.e. they could be enumerated; the added element is returned later). If we switch to the mocks, we'll need to configure all that behavior manually each time we write the test. It might be really annoying (and it will be, given my experience of test writing).
Therefore, I'd prefer to keep that as is. Kernel intercepts the basic collections only, all other interfaces redirected, so behavior is still pretty obvious.

The 3rd commit, extracting a base class so we could run all tests against all fixtures, could be dropped entirely, at your option.

At the first glance I'd prefer to remove that commit as it makes it harder to read the tests. However, it seems that we'll not need that reorganization at all after we solve the concerns mentioned above.

What I've shared is only my vision. @moodmosaic @blairconrad Would be happy to know how you see the situation and which way you prefer.
P.S. @blairconrad Thanks for raising the PR and triggering this discussion - sooner or later we must have had to decide 😄

Thanks for the response, @zvirja. There's a lot to take in. For now

Now we have EnableAutoFakeItEasyForDelegatesCustomization …

Yeah, I didn't care for that either. I had thought that you were suggesting I emulate the implementation in #742, so I attempted to do so. I'm happy to throw all that away.
And your point about behaviour of generated collection classes is excellent.

as currently delegates return the automatically generated value, while faked delegates will return the default value

A faked delegate would actually return a Dummy, but your point that the behaviour would be different is still valid. However, I believe we could return a faked delegate that by default returns the automatically generated value. Then users would never know that anything changed, unless they were examining the type of returned delegate (which seems silly), or they attempted to configure it as a Fake, in which case I'd think they'd be pleased with the result.
Me, I think this would be a good change. I wish I'd thought of it earlier. As a bonus, it shouldn't require any of the configuration changes you discussed above, not that I'm against a  consistent API over the glue libraries; implementing such a thing sounds like a good step, just not one that's needed here.
I may run off and try to implement my "faked delegate that acts like an AutoFixture delegate" idea, just to see if it will actually work. But I'm keen to hear what you think of it.

For me the top priority is the API consistency across our glue libraries. Currently we suggest two types of customizations (e.g. for Moq and NSubstitute):

Simple (without using AutoFixture for the result)
Configured (properties/fields/method results are generated by AutoFixture).

The FakeItEasy integration provides a simple customization only - the one which doesn't generate the property/field/method result value using the AutoFixture. And we should keep that customization to behave so for the sake of consistency.

I believe we could return a faked delegate that by default returns the automatically generated value.

I may run off and try to implement my "faked delegate that acts like an AutoFixture delegate" idea

That's exactly what I don't want to do. We should not make "simple" customization to behave like "configured" one for the delegates. Rather, this customization is expected to return delegates, for which we don't handle the result type (so it's up to the Mock library). However, the issue is that applying this change in minor release might be considered as a breaking change (because it can really break the existing tests).
Therefore, we have the following options:

Tune the customization to fake the delegates by default. While the change is potentially breaking, we can cross our fingers and hope that nothing is broken 😅 That's the Way 1 mentioned above.
Add a way to enable that behavior optionally:

Use the way you follow in this PR (have one yet customization). I don't like it, because it's unclear that customization works only if you apply another customization (see more info above).
Follow the Way 2 described earlier.

For me it seems that actually Way 1 or Way 2 are the only choices we have. Do you see some other paths?
@blairconrad So do I see that clear that you in fact suggest the Way 1, which is potentially breaking?
@moodmosaic Could you please also share you thoughts regarding my concerns above and your way to solve the issue? Personally, I feel that Way 2 is win-win.

Currently we suggest two types of customizations

Simple (without using AutoFixture for the result)
Configured (properties/fields/method results are generated by AutoFixture).

Ah. I didn't understand the categorization there. That's helpful.

The FakeItEasy integration provides a simple customization only - the one which doesn't generate the property/field/method result value using the AutoFixture. And we should keep that customization to behave so for the sake of consistency.

I don't want to quibble, but the FakeItEasy customization currently, when a naked delegate (not a Fake<Delegate>) is requested, is bypassed, so a delegate is constructed whose return value (if any) is produced by AutoFixture. For example, I just requested a delegate that returns an int, and that delegate gave me 64 when I Invoked it.
My suggestion, returning a Faked delegate whose default behaviour would be to return the same value that would be provided by AutoFixture, had been intended to preserve the behaviour users would see today, while still giving those, such as @OnurGumus, who wanted to configure their delegate, the ability to do so. This is effectively what I think you are calling Way 1 above, "Tune the customization to fake the delegates by default.", just with the added specification that the delegates will be fakes, but fakes that act as the AutoFixture-produced delegates do today, unless configured otherwise.
I had not considered the two types of customizations that you mentioned above. Still, in this situation, my proposal would be transparent to consumers who request a naked delegate and don't try to further configure it using FakeItEasy's Fake configuration mechanisms. The only possible breakage that I can see here would be if consumers are requesting delegates from AutoFakeItEasy and then performing a GetType on them or similar: the types would be different than before, even though the objects would behave in the same manner when Invoked.
I hope I've clarified my idea and position. Then again, maybe all this was clear before and it's just not compatible with the goals of AutoFixture. I'm not trying to be fractious, and ultimately I'll comply with whatever you want. I just thought this was a way forward that would satisfy @OnurGumus without breaking existing usages of AutoFixture.

@moodmosaic Could you please also share you thoughts regarding my concerns above and your way to solve the issue? Personally, I feel that Way 2 is win-win.

I'm not sure I can follow this issue (I've also gone through #984).

Why would we want FakeItEasy, Moq, etc., to handle delegates automatically? What is the scenario? Are we, for example, trying to pass delegates in the constructor(s)?
I haven't followed the AutoConfiguredXyzCustomizations work, which I see being mentioned above.

Happy to provide feedback, but most likely I don't have much to say regarding this issue and the linked one (#984).

Why would we want FakeItEasy, Moq, etc., to handle delegates automatically? What is the scenario? Are we, for example, trying to pass delegates in the constructor(s)?

That would be my guess. The behaviour would be useful if the system under test took a delegate as a constructor parameter, and the client wished to configure the delegate's behaviour or verify the SUT's interaction with the delegate.

@zvirja, I think, if we should go forward with this, we should add a way to enable that behavior optionally. I don't think it's common to pass delegates as constructor arguments in languages like C# and VB.NET (and even F#).
(We may turn this into a non-optional feature, say, in AutoFixture 5.)

@moodmosaic, this is anecdotal, but I often see Funcs or Lazys passed around. Imagine if, in the AutoFixture codebase, a Predicate<object> were used instead of a IRequestSpecification. (I know, that doesn't provide the same level of information to the reader, but it is done.)
I'd proposed providing fake delegates that wrapped the AutoFixture-generated ones, so they'd perform exactly as today's AutoFixture-generated delegates do until the client configured them.
@zvirja preferred optional activation of the feature, as you suggest, via a property GenerateDelegates. I accidentally pushed some work-in-progress a few minutes ago, but my implementation of his suggestion will be coming in very soon.

Pushed. I think this matches what @zvirja had asked for. I'm sure there will be plenty of comments, and I'm happy to make whatever changes are requested.
I'd like to point out one slightly dodgy area. In AutoFakeItEasyCustomization, if GenerateDelegatesistrue`, we check the version of the FakeItEasy library to see if delegates are supported. I generally prefer to detect the presence of features rather than rely on version numbers, but there were no API-level changes when FIE gained the ability to fake delegates.
Also, there are currently no tests to ensure that we can fake a delegate when the FIE version is at least 1.7.4257.42—the tests currently bind to 1.7.4109.1, which cannot fake delegates, or 2.0,0, 3.0.0, or 4.0.0, which all can. Options, I think:

leave the tests and production code as they are; it'll probably be fine (and it's fine, I did manually check with 1.7.4257.42. I'd take this option)
add yet another test project targeting 1.7.4257.42, or
artificially raise the minimum FIE required for AutoFakeItEasy to fake a delegate. We could require, for example, 2.0.0 (or 3.0.0 or 4.0.0), and then the production code is aligned with the tests. It does deny the feature to those who keep a very old FakeItEasy version, but it also helps us move them along to more modern FIE implementations, reducing the ongoing burden of maintaining AutoFakeItEasy's integration with so many versions of FIE.

Oh, another thought. I added the GenerateDelegates property to turn on delegate generation, but this is not so discoverable. If you wanted another option, and envision just feature toggles, a Flags enum as a parameter to the customization is a possibility. Then users would see the extra constructor.

Oh, another thought. I added the GenerateDelegates property to turn on delegate generation, but this is not so discoverable.

I'm two hands up for this approach as it's scalable. If later we decide to add more features, we could easily introduce one yet property and handle it's value. Also properties are not limited to bool value (as flags imposes), but could have different types.
@blairconrad Huge thanks for the work you are doing here and please take my apologies for taking so much time to review the PR.

I'm two hands up for this approach as it's scalable. If later we decide to add more features, we could easily introduce one yet property and handle its value. Also properties are not limited to bool value (as flags impose), but could have different types.

Fair enough. Will continue with the properties. Another option, just while we're making the change, would be to add a new type as constructor argument: the customization options. This type could have all the properties you describe. It's an extra level of indirection, and slightly more work than just providing properties on the customization, but would better highlight the fact that there are options. Not pushing for it, but if you decide you like it, I can do.

Huge thanks for the work you are doing here and please take my apologies for taking so much time to review the PR.

I'm happy to help. Please do not apologize. This is a hobby for us all, and sometimes we just want/need to spend our time doing other things! :wink:

Another option, just while we're making the change, would be to add a new type as constructor argument: the customization options.

Well, let's see. If we follow the current approach, the API usage will look like following:
var fixture = new Fixture();
fixture.Customize(new AutoFakeItEasyCustomization
{
    GenerateDelegates = true,
    Relay = new CustomRelay()
});

If we have yet another level of indirection:
var fixture = new Fixture();
fixture.Customize(new AutoFakeItEasyCustomization(new CustomizationOptions
{
    GenerateDelegates = true,
    Relay = new CustomRelay()
}));

While the second way is not too much verbose, I still prefer the first way as it's simply much easier to support it and it looks more concise.
To fix the issue that users might not know about the possibility to configure features, we need to update the xml doc for the class and for the default constructor:
///
/// Enables auto-mocking with FakeItEasy.
///
/// <remarks>
/// NOTICE! You can assign the customization properties to tweak the features you would like to enable. Example:
///

/// new AutoFakeItEasyCustomization { GenerateDelegates = true }
/// </remarks>
public class AutoFakeItEasyCustomization: ICustomization
{
    ///
    /// Initializes a new instance of the <see cref="AutoFakeItEasyCustomization"/> class.
    /// <para>
    /// NOTICE! You can assign the customization properties to tweak the features you would like to enable. Example:
    ///

    /// new AutoFakeItEasyCustomization { GenerateDelegates = true }
    /// </para>
    ///
    public AutoFakeItEasyCustomization() { }
}

Now when you type, as always see a hint in XML documentation:

or

Of course, people could still overlook it, however the chances are much less 😉 Additionally, after we create a doc site, we'll mention about this way there as well.
I do understand that documentation is a workaround here, however for me it looks like a reasonable trade-off (it's actually not that easy to make a decision) 😕.

Thanks for the response, @zvirja. I'd for sure add pretty documentation anyhow. I agree that it's a tough choice.

Pushed 2 commits to (I think) address your requested changes, @zvirja. If you're unhappy, I'll keep pushing. If you're happy, I can squash.

Everything looks awesome to me, thanks! 👍 I have a few minor notes , see this PR.

If you're happy, I can squash.

I'd prefer to keep all 3 commits - changes are quite nicely distributed across the commits.

@zvirja, I incorporated your changes. Sadly, I'm not git-savvy enough to have done it in a way that allowed you to keep credit. I'm happy to reassign some of the commits to you, if you like.

@zvirja, I incorporated your changes. Sadly, I'm not git-savvy enough to have done it in a way that allowed you to keep credit

Thanks a lot for the spent time! Me neither know. No worries about the credit - I'll be present in the PR history forever, so it's enough 😅

PR looks completely fine for me!
@moodmosaic Do you want to take a look? If not - I'm happy to merge it as is.

@blairconrad Thanks a lot for your contribution and for all the changes you applied during the review 👍 It's an ideal example of PR collaboration for me 😊
I will release this change soon in a new version of AutoFixture product 😉

Thank you, @zvirja. I also had a good time. I'm glad my "but what if?"s were not too annoying!

I'm glad my "but what if?"s were not too annoying!

They definitely were not, rather they provoked a very good discussion! It's always cool to ensure you take into account the multiple views! Therefore, do not hesitate to ask all the questions you have in future 😉


Create recurrent mutations track

We really like the ability to create mutation tracks
If it could show, the recurrence across all the GDC, that would be great
If it could also show recurrence specifically across the samples in your query, that would also be good
In our call we looked at how the mutations tab had for example 560/10000 patients in the GDC portal all shared the BRAF mutation
I think another use case would show that after filtering on brain cancer patients, that for example 50/400 brain cancer patients have some mutation

Looking at the GDC exploration portal network request (see SsmsTable request), there is a score attribute for a mutation that is equal to the number of occurrences of a mutation in a cohort.
This score field is currently being used by the plugin, such that it fetches mutations, sorted by the score (highest score first).
This request also shows how to count the filtered and total number of occurrences, along with the total number of cases in the query and total number of cases across the GDC. These can then be used to highlight by mutation recurrence across GDC or cohort, either as a raw score or percentage. We can also show these values within a feature detail so that users can understand the importance of a mutation.


Key to the species of Chinavia of Rio Grande do Sul, Brazil

https://doi.org/10.3897/zookeys.319.4310

B1563


Histogram support in Range picker

The range picker needs to show a histogram for searching for each of integer, float, date, and timestamp.

For integer and date, we want the bin width to be a whole integer so when we label the bin, it is easy to understand...
Let's assume that
min: the current min
max: the current max
#bin: number of bins
Then
bin width = round up ((max - min/#bin))
requested max = min + (bid width * #bin)
The new (min, requested max, #bin) will create a whole number bin size


chore: add eslint

Closes #6
Changes proposed

add eslint

Looks like this doesn't account for the recently merged typescript PR, and it also has merge conflicts because it actually lints the files.

Oh, my bad, yeah, TS requires some extra packages apparently.
I marked it with the accepted label and gave it a positive review, so if Hacktober is important to you, it still counts.
You did exactly as requested, but I'm gonna close it due to not matching up with the repo's current state.
If you want, you can make another PR with changes that are compatible with the current state and I'll promise to merge it on the spot if it checks out. But I totally understand if you don't.
I'm very sorry!

Oh, my bad, yeah, TS requires some extra packages apparently.
I marked it with the accepted label and gave it a positive review, so if Hacktober is important to you, it still counts.
You did exactly as requested, but I'm gonna close it due to not matching up with the repo's current state.
If you want, you can make another PR with changes that are compatible with the current state and I'll promise to merge it on the spot if it checks out. But I totally understand if you don't.
I'm very sorry!

I have enough points for Hacktoberfest, I was doing this because I normally contribute to open source before Hacktober.
Can you explain what you really need?