Templates for various Drupal VM use cases

DrupalVM can be used for various use cases.
The current make file and configuration YML appear to be focused on a core-contributing use case.
One other prominent use case is doing local sandboxes for a Drupal-based project. This has different needs, which include pinning of stable versions of Drupal, Drush, and dependencies (non bleeding edge so that projects can focus on their development without being burdened with potential other issues).
I'm proposing we provide at least one more example.make and example.config.yml optimized for projects. There are considerations like "working copy" of core that projects wouldn't benefit from because updating core becomes harder.
I would like to discuss the potential use cases and identify improvements to meet a broader set of needs.

Personally I always keep my development modules in the dev branch and then disable them on production.
As for drush, from a maintenance perspective it makes sense to keep it at master so we don't have to update it every time they release a new version. I agree that this can be an issue though. Nowadays I use drupal-composer/drupal-project as the base for my sites and there I pin down the latest stable version with composer. This way the the globally installed drush delegates to the project specific drush version.

Edit: I hadn't even noticed Drupal VM uses working copy of core. Maybe we should remove this for the common use case? I bet most people don't know what this is.

Yeah, that's one of the main things. We could just comment it out and let people uncomment if they're doing core dev work or using Drupal VM at a workshop.

The working copy is one thing. But, there are more settings ideal for initializing a Drupal project and having DrupalVM facilitate sandboxes, e.g.: pulling from a stable release of Drush, pulling stable release for Core, etc. I'm sure there is more and we need an approach that separates building a Drupal site from doing core development. This is less about the actual modules installed - I fully expect people to know and understand how to use a make file or Drush for getting what they want.
My gut tells me we should consider separate config.yml and/or make files for various use cases. At a minimum, a different set of configuration for core development and developing a website in Drupal.

@nerdstein Let me assure you that with the use of things you can code yourself, DrupalVM is far more powerful than it might look on its shell. I'm now developing node, python and bash as well as drupal and php comfortably without ever worrying about it dying or being restricted.
The latest release actually allow for different configuration files - though make files are rather set and are in fact inevitably going to become redundant...
I'm actually not a fan of the new implementation of Galaxy provisioning so I've reverted those lines, but should you need different 'implementations' of it, all you need to do now is to either keep them in isolated repositories, or keep a copy of all the config files and copy them as required.

I'm actually not a fan of the new implementation of Galaxy provisioning so I've reverted those lines, but should you need different 'implementations' of it, all you need to do now is to either keep them in isolated repositories, or keep a copy of all the config files and copy them as required.

You can disable it by adding this to a Vagrantfile.local
# Disable the galaxy role re-installation during provisions.
config.vm.provisioners[0].config.galaxy_role_file = nil

@oxyc That's actually rather interesting, thank you for the heads up... I will let you know how that goes :)

Also as the config/drupal-vm directory is now read from environment variables. It opens up the possibility for imaginative wrappers.
function vagrantsh() {
  local conf="$1"; shift
  DRUPALVM_CONFIG="vendor/oxyc/custom-vm-configs/$conf" vagrant "$@"
}

$ vagrantsh php5 up

@fubarhouse I am quite familiar with how the configuration layer of DrupalVM works. My recommendation was, instead of shipping with just one default example.config.yml/example.drupal.make is to explore the various other use cases that DrupalVM may be used for. My concern was not the usability or ease of copying or adjusting config (which I have found to be amazingly flexible), but more about having sane defaults per use case.
The use case DrupalVM ships with, by default, is for core development (talked with @geerlingguy about this at DrupalCon). One use case that I use DrupalVM for is a sandbox for Drupal-based projects. There are many settings I find to be ideal for this use case that vary from core development. As such, different config templates would limit the back and forth needed by developers to perform configuration for that use case.
Please note that this is issue is not about some limitation in DrupalVM, it's about the usability of it for additional scenarios in which someone might want to use DrupalVM. For me, personally, I'd love to see things like "--working-copy" be removed from a project-specific DrupalVM use case. That trips me up every time, along with pinned stable versions of Drush, Drupal, etc.
If no one cares about this, it's clear I have many options to work with. But, I would love to be able to pull down the most recent DrupalVM code, have example configuration for bootstrapping a Drupal project, and run with it. Precedence exists already with the 'examples' directory and the overrides concept. This may be a way to introduce the overrides needed for project-level configuration.

For me, personally, I'd love to see things like "--working-copy" be removed from a project-specific DrupalVM use case.

That's gone from 3.0.0 :) https://github.com/geerlingguy/drupal-vm/commit/a4e8225cffc350699ac5a294b8f17614eed9520a

pinned stable versions of Drush, Drupal, etc.

I definitely won't be pinning a version of Drupal in the config Drupal VM ships with—that's too much maintenance effort for me; but I do pin now to 'latest stable 8.1.x', and I think that's good enough for 99% of people building anything on top of Drupal VM. Most people just ignore the makefile entirely anyways :)
But we could maybe pin Drush to an 8.x release. Right now it's on master, and though it hasn't happened lately, there are times when bleeding edge is... bloody.

It seems like we're mostly there :)
And, +1 to the Drush comment. I often end up pinning Drush on 99% of my installs.

Nice @oxyc I've added a check for the roles directory too.
# Disable the galaxy role re-installation during provisions.
config.vm.provisioners[0].config.galaxy_role_file = nil unless ENV['GALAXY'] || !Dir.exist?("#{host_drupalvm_dir}/provisioning/roles")

@nerdstein drush site-install will inevitably be replaced by composer - though it wouldn't be tricky to continue to support both methods.
@joestewart I really like that, thanks :)

@nerdstein you could create a fork and manage a few install profiles (custom config.yml) as branches.
I do something similar here -- https://github.com/thom8/beetbox/branches/all
which has the added benefit of also separately testing each individual config.
*note many are failing as we've added some drupal specific tests.
Then each release I'll rebase these branches and can test if anything has broken.
eg. this branch builds out the Acquia lightning profile -- https://github.com/thom8/beetbox/tree/lightning
tests are passing -- https://circleci.com/gh/thom8/beetbox/1133
and only a small diff from master so it's often a clean rebase -- https://github.com/beetboxvm/beetbox/compare/master...thom8:lightning

@thom8 cool, that idea could work. I wanted to at least propose it upstream instead of maintaining my own fork.

I think with the three different supported 'from-scratch' install methods, in addition to the expansion of the docs and capabilities for including Drupal VM in projects as a composer dependency, and the community support around upstream wrapper projects that integrate with Drupal VM, we're pretty well covered.
I don't want Drupal VM to try to turn into a be-all/end-all "here's how you do everything with Drupal from end-to-end" tool, but just "the best Drupal local development environment that just so happens to do a bunch of other things well and has a lot of best practices as defaults". Therefore I'm happy with where we are, and this thread has a lot of good jumping-off points for those who want to go much deeper in the realm of Drupal VM customization and Drupal build/deployment process in general.

Also, we're no longer requiring galaxy roles to be installed on every provision by default, since they're included with Drupal VM (3.2.0 release with that feature coming soon!).


Postinstall script is not picking up the correct .babelrc

Version
2.0.0
Steps to reproduce

Create a project with a .babelrc file, without "loose" build enabled
Add react-router to project package.json as a github url

"react-router": "github:reactjs/react-router#master"

From project root npm install react-router

Expected Behavior
Should build react-router using ./node_modules/react-router/.babelrc with babel loose build enabled.
Actual Behavior
Builds react-router using ./.babelrc with "loose" build disabled, and thus react-router is not functional.

This actually can't work beyond a basic best-efforts thing. Given Babel 6, even that isn't really going to be an option. It's not worth our time to deal with this sort of issue, so I'm just going to drop GitHub install support entirely.


Changed editingWebhookIdx to editingWebhook

Literally I just forgot to put this in the last merge and it was bothering me so here it is

Looks good


add accelnet support on CNI

Reason for Change:

This PR is to add accelnet support on CNI;
Issue Fixed:

Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] relevant PR labels added

Notes:

/azp run Azure Container Networking PR

/azp run Azure Container Networking PR


Finalise vehicle code and lint

Finalises vehicle code and also provide a tool, vehicle_code.py, to prevent this from ever becoming an issue again.
closes #153
Provides a tool for linting to prevent the reoccurence of linting issues for those of us without VS.

I'll finish this tomorrow. The linter's not working and I can't figure out why.

im trying to make it pass with the weblinter

Closing due to merge conflicts, this will be easily re do-able again anyway.

Just had to rename some files and I think we will have conflicts I'll have to sort later

Everything in here is covered in #184.


Update node versions, drop v4/v6, add v10/v12

As noted on #89, this drops CI tests for Node versions 6 and 8, while adding versions 10 and 12 to the matrix

Meh, I'll see to remove this check. Cannot merge using the ui either.


SPI latency between transactions. Is there a faster way

The SPI for me works just fine, but the transaction to transaction time is terrible using esp-idf directly.
I ran 2 tests (one using esp-idf directly and the other using Arduino code).  Both tests send 2 transactions back to back.  With  esp-idf directly it was 112us until the next transaction, with Arduino code, it was a mere 1.2us.
using esp-idf directly: Calling this routine 2x
`
uint8_t temp[2];
esp_err_t ret;
spi_transaction_t t;
temp[0]=0xaa;

memset(&t, 0, sizeof(t));       //Zero out the transaction
t.length=8;                 //Len is in bytes, transaction length is in bits.
t.tx_buffer=&temp;               //Data

 ret=spi_device_transmit(lcd_spi, &t);  //Transmit!
 assert(ret==ESP_OK);            //Should have had no issues.

`
as can be seen here.

Yet doing the same thing with Arduino code, its magnitudes faster. only taking 1.2us.
    digitalWrite(chipSelectPin, LOW);     SPI.transfer(0x55);     digitalWrite(chipSelectPin, HIGH);
as can be seen here.

The problem is I do not want to use Arduino code, is there another solution that would dramatically shorten transaction time?   How is Arduino able to pull this off.

Closing for now. Please feel free to reopen it if this issue persists.


Notification_Service_started doesn't run

i just update my code from electron 1.8.8 to 3.0.5, when i update the NOTIFICATION_SERVICE_STARTED stop running

I think it's a duplicate of https://github.com/MatthieuLemoine/push-receiver/issues/23.
Feel free to reopen if not


Add public data API widget

Current coverage is 87.84% (diff: 100%)

Merging #588 into master will increase coverage by 0.03%

@@             master       #588   diff @@
==========================================
  Files           209        209
  Lines          8496       8522    +26
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           7460       7486    +26
  Misses         1036       1036
  Partials          0          0

Diff Coverage
File Path

•••••••••• 100%
open_humans/templates/pages/public-data-api.html

Powered by Codecov. Last update bbdfc6a...298dd4b


Add cupy.polyder API.

Hi,
The PR follows a part of #6078. It aims to:

Implement cupy.polyder API. Test added.
Use NumPy Style docstring in the file as suggested in #5437.

Looking forward to hearing from you. Thanks :)

@khushi-411 Any updates?

Hi, @asi1024!
Apologies for the delay. I'll update the PR soon (surely by today or tomorrow). Thanks for the ping. :)

Hi, @asi1024!
Could you please take a look at the following code snippet?
_polyder_kernel = _core.ElementwiseKernel(
    'T p, int64 m',
    'T z',
    '''
    int n = sizeof(p)/sizeof(p[0]) - 1;
    T y = p[:-1] * cupy.arange(n, 0, -1);
    if (m == 0) {
        z = p;
    } else {
        z = _polyder_kernel(y, m - 1);
    }
    ''',
    '_polyder_kernel')

The tests are failing if using the kernel. Here's the error link. Please let me know some tips to correct it. Thanks!

@khushi-411 ElementwiseKernel body string parameter is embedded as CUDA program in a CUDA global function, so cupy ufuncs cannot be used in this string.

@khushi-411 Any updates?

Closing the PR as it has been WIP for a long time.
Please feel free to reopen if you want to continue.


Allow template config merging

Feature Request
Feature Information:
In the current state, template config automap overwrites the entire config file if one exists. It would be better if the template config was able to merge the lines based on template variables. This would allow users to enter custom lines in the config files, or for some games to use the built in editing tools alongside AMP's UI.
For lines with a variable name the merge is easier, match it based on anything that isn't the variable (before and after on same line). If a match isn't found in the config for other lines (Default values that aren't a variable), it should write the lines in order. This can be used for setting up the layout for a file if the section does not follow the kvp format defined.
I confirm:

[x] that I have searched for an existing feature request matching the description.

Hmm... That might be an option. How would that work in instances where the user settings have to go under a specific heading?

@Greelan and I discussed perhaps a better solution. Would it be possible for regular automap (no template config, just the game's existing config, either as supplied by the server or by AMP), and if it doesn't find the key it creates a line using the automap config format?

Adding it to the end? Possible - clunky though.

That’s fine, as long “the end” can accommodate ini sections?

Well... I'm not sure that would be fine. How would that work for ini files? I thought headers could only appear once. And for things like JSON or XML... Not sure that would be beneficial either.
Would it not be possible to add some logic that if it's not found, break out into a function that adds it at the end of the current section? Sure, it would require some finessing, but seems doable.

Didn’t my comment address ini sections? Lol
Extending to JSON/XML might be stretching it

Yes, I'm in agreement with you, not disagreeing. I was just elaborating on the point that the end of the file isn't going to work in most cases.

ARK generic will require this if we want to allow users to manually add settings or use mods that edit the config file. It seems the server removes certain settings from the config file if they are default values.


Build instruction

Hello Jack,
I wouldn't mind to help but I am unable to build this project.
Could you please add minimalistic build instructions?
Thanks & regards,
Daniel.

Yeah! Added that to the README - it's just an Electron app :)

Thanks Jack!


Mass overhaul of ZMap CMake and documentation files.

This patch:

Markdownize the CHANGELOG, BUGFIX first in every release, others go after always.
CMake syntax cleanup, lowercase for set(), include().
Introduce CMP0048.
Refine check for configuration files() to not get overridden.

What can be done to do better:

Please check if @ZMAP_VERSION@ is needed elsewhere.
Haven't tested on Debian, not sure if it builds still?

@cicku, we want to maintain compatibility with CMake <IP_ADDRESS>, which is the latest CMake version available in the Ubuntu 14.04 LTS package repositories.
it looks like CMP0048 wasn't introduced until CMake 3.0. I'm not sure if that is a major issue or not, provided we set versions sanely. Unfortunately, the project() command looks to be different between 2.8.12 and 3.0, see http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:project. As a result, CMake is erroring out when I try to build on Ubuntu 14.04.
The @ZMAP_VERSION@ macro is awesome, especially since I'm so bad at finding all the version strings to update on release. I think we'll need @ZMAP_VERSION@ in all the man files (zmap.1, ztee.1, zblacklist.1) as well.
Once we get the final build kinks resolves, I'll backport them to 2.1.0 and release a 2.1.1. That should make all the packagers lives easier.
Thanks for the help!

I understand, that's why I asked if you can compile on Debian :hamster:
I need to build it on elder systems as well ( RHEL7 has 2.8.11 only but this version is buggy, even behind RHEL6 which has 2.8.12 already! See this bug if you want.)
So, I think my PR needs some rework:

Revert CMP0048, but set(ZMAP_VERSION) manually with 2.1.0, I think this is the compromise.

For those manpage, I'm not sure how did you generate them. Are they just the sources, or you used some other tools to build instead? Because I checked and found traces of ronn, I'm afraid not using that macro if it breaks more.

For the manpages, I write them using ronn and then manually run ronn to generate the roff, which I then tweak manually to have the correct header.
Other thing of note, by putting the @ZMAP_VERSION@ in the *.ggo files, they always show up as modified in git. We might be able to get around this by having CMake copy the .ggo file to some other file that is .gitignore'd before running configure_file. Thoughts?

I just confirmed this PR now works with Ubuntu 14.04.

@dadrian,

Other thing of note, by putting the @ZMAP_VERSION@ in the *.ggo files, they always show up as
modified in git. We might be able to get around this by having CMake copy the .ggo file to some
other file that is .gitignore'd before running configure_file. Thoughts?

I think you were building it in source, right? Now we have:
configure_file(topt.ggo ${CMAKE_BINARY_DIR}/src/topt.ggo @ONLY), my experience is:

Append .in suffix to gengetopt file, and possibly other sources which you'd like to use the macro. (Just do like autoconf oldschool)

Change
configure_file(topt.ggo ${CMAKE_BINARY_DIR}/src/topt.ggo @ONLY)
to
configure_file(topt.ggo.in ${CMAKE_BINARY_DIR}/src/topt.ggo @ONLY)

Add *.ggo to .gitignore file

Done :100:

Sounds good to me

Pushed as 4d0d3ac4083dba39481cbacc360b8047b1dc1dbc, I have to sleep now(UTC+8). Any questions please leave here, I will rpely tomorrow(oops, 5 hrs later probably :laughing: )

I'm thinking about using cmake to build manpages as well. It should be easier for version bump.
Feasible?

I don't want to require everyone who builds zmap to have to have ronn installed.

I know, solutions:

You generate manpage via ronn, replace zmap v2.1.0 with zmap<EMAIL_ADDRESS>or just<EMAIL_ADDRESS>in ronn command. Then include generated .1 file in src/.
Use asciidoc (python required, and most of systems have it).
Use sphinx manpage builder (python required).
Use doxygen (python required, might has timestamp issue).
No version in manpage

I think we should probably generate a .1.in file with ronn, use @ZMAP_VERSION@ in that file, and then have CMake generate the .1 file from the .1.in. We'll add .1 file to the .gitignore, and commit the .1.in file to the repository.
Last time I checked ronn didn't set version in output, so we have to manually edit the ronn output. This workflow is pretty close to what I do now, but should help my general inability to bump version numbers correctly.

I used to set version by --organization option of ronn.

Well, if that works, I guess we can just pass @ZMAP_VERSION@ to ronn then. The general workflow should still apply though, with the ronn output being source controlled.

Yes, but I haven't had tested this, since ronn is not installed on my system.

OK, I think we're good to merge then. I'll do one last test of this later tonight, then merge to the 2.1.0 branch, bump the version to 2.1.1, release that, then merge this commit into master. We can skip releasing 2.1.0 to package repositories.

Good to hear this.
Appreciated!

@cicku, I just merged this to the 2.1.0 branch, and then bumped the revno. See https://github.com/zmap/zmap/commit/c1f7959b90735f5bb4d473bd8958c8106785484b. Can you confirm that commit looks good on your end? If so, I'll tag it as 2.1.1 and we can pretend the packaging disaster that was 2.1.0 never happened. :grin:

I will test this later. It should be fine, but give me some time. (4hrs probably since I'm outside)

Test passed. :+1: for 2.1.1.
#287 should be included before release as well.

v2.1.1 is now tagged.

Thanks for all the help, if we're ever in the same city I owe you a beer. :beers:

Sure, I will remember that :+1:


Compilation error for comparision of optional/nullable types

Acton Version
<IP_ADDRESS>30<IP_ADDRESS>
Reproduction code
actor main(env):
    a: ?int = None
    b: ?int = None
    print(a == b)

Error output
$ actonc mod1.act
Building project in /home/ddjoh/workspaces/act-test-1
  Compiling mod1.act for release
   Finished compilation in   0.080 s
Building executable out/rel/bin/mod1
ERROR: internal compiler error: compilation of generated C code of the root actor failed
NOTE: this is likely a bug in actonc, please report this at:
NOTE: https://github.com/actonlang/acton/issues/new?template=ice.yaml
NOTE: acton <IP_ADDRESS>30<IP_ADDRESS> compiled by ghc 8.10 on linux x86_64
NOTE: cc: 0.10.1
cc stdout:

cc stderr:
ld.lld: error: undefined symbol: $EqOptG_new
>>> referenced by mod1.c:122 (act-test-1/out/types/mod1.c:122)
>>>               mod1.o:(mod1Q___init__) in archive /home/ddjoh/workspaces/act-test-1/out/rel/lib/libActonProject.a

@nordlander have you looked at this? I have a vague recollection of talking about these but I can't remember exactly. It's rather annoying, so if there's a quick fix, it'd be really nice... :)


Map more UTF-8 key events

At the moment we are only handling the space " " and keys in a nice way, but it'd be nice to be able to match on KeyDown Enter or KeyDown "<enter>".
Using a variant for all the keys may be a stretch, since we're parsing UTF-8 grapheme clusters, so at least some common ones we want to handle in a way that lets you match over KeyDown easily.
This is currently happening in the minttea/io_loop.ml in the translate function:
https://github.com/leostera/minttea/blob/main/minttea/io_loop.ml#L18

Currently implemented keys:

[x] Enter
[x] Space
[x] Backspace
[x] Left / Down / Up / Right
[x] Escape
[x] Key (includes a string with the contents of the matched UTF-8 character)

Missing keys:

[ ] Shift-modifier
[ ] Ctrl-modifier
[ ] Alt-modifier
[ ] ???

As an update, we now have a key variant that we're mapping around the same place in the code, so when you match on a KeyDown event you can discover quickly what the available keys are, and also have some guarantees that your app won't break.

Hey! I would love to contribute by adding support for modifier keys.
so far, the Key variation is only a string
type key =
  | Up
  | Down
  | Left
  | Right
  | Space
  | Escape
  | Backspace
  | Enter
  | Key of string

which means its not straight forward to just add a modifier to the key pressed without breaking the interface unless I add a new variation. But I think its a bad API to have both Key and other event for Key with modifier.
I thought about making it be Key of key_event in which key_event would be something like:
type key_modifier =
  | Ctrl
  | Alt
  | Shift

type key_event = {
  key : string;
  modifier : key_modifier;
}

This would allow for telling which modifier was pressed with a key. But again, this would be a breaking change to the interface, which also requires to change all the examples.
What do you think?

As discussed in #45 we chose to use a pair of key * modifier and make the modifier a variant that includes a No_modifier constructor, so matching on a key event looks like:
| KeyDown (Key "j" | Left, No_mofidier | Shift) -> ...


feat: upgrading to PyPI reinvent models 0.0.14 version

This PR contains all the changes related to upgrading the package to the latest version of reinvent models in PyPI ( 0.0.14 ).

Looks good, but I would make sure we do not apply typing and styling to make more straightforward an eventual contribution to Reinvent.

Yes, I have basically replaced the whole package with the latest version and applied the changes we did last time.


wrong pixel size in Pixel simulations after loading model

Describe the bug
When a model is imported and a Pixel sim is set up, it always uses a pixel size of 1 when calculating the diffusion constant in pixel units.
If the user sets the pixel size via the Set Image Size dialog box then Pixel gets the correct value, but saving the model and loading it again runs into the same issue.
Example
Creating a simple model, with pixel size = 0.01 & simulating gives similar results for Dune/Pixel:

Saving the model and loading it again, the pixel results are different (since the pixel size is 100x larger than it should be, diffusion rate in the simulation is now 1000x smaller than it should be)

Thanks @BaronvonderHeyden for the bug report!

This means all pixel simulations are using an effective diffusion constant a^2 D, where a is the pixel width in model units of length, and D is the diffusion constant.
How was this not caught by our tests? We do have tests that change the pixel size in the model and then simulate, but this bug only occurs when we load a model with a != 1 and simulate without first changing the pixel size, and unfortunately all our test models have a = 1 initially so they give the correct results.


[cryptolib] Add Ibex drivers for P-384 ECDH and ECDSA on OTBN

This PR

adds Ibex driver code for P-384 ECC on OTBN.
-> In case of ECDSA the code is split up into individual files for keygen, sign, and verify. This is because each function is a separate OTBN application. But still, everything is put together in a single ecdsa_p384 file, which then is used by the top level ecc driver file.
-> Similar, curve point validation is put into an own driver file, as it also is a separate OTBN application. It is executed before ECDH shared key generation and ECDSA signature verification, to check if the public key is valid (= is a curve point).

adds the corresponding functests for P-384 ECDH and ECDSA.

fixes some memory issues in the P-384 top level OTBN binaries, which we discovered during development.

Thanks Jade for the detailed review!
Sorry for not splitting it up into more commits, my bad. You're absolutely right. Noted for the next PR!

Since there are quite a few point that are also relevant beyond this PR, I would suggest that, for now, I only address everything which is directly relevant to this PR. For everything else, that for example affects p256 code, I would open a follow-up PR to add these changes. What do you think @jadephilipoom ?

Since there are quite a few point that are also relevant beyond this PR, I would suggest that, for now, I only address everything which is directly relevant to this PR. For everything else, that for example affects p256 code, I would open a follow-up PR to add these changes. What do you think @jadephilipoom ?

I'm not certain which of these you mean, but my stance is: it's fine with me to not fix the corresponding errors in P-256 code here and do those in a follow-up PR. However, I would like to see the issues fixed for the new P-384 code in this PR before it's merged, even if the issues exist in P-256 as well -- follow-up PRs aren't guaranteed to happen, and even when the existing codebase isn't perfect I think it's good practice to try not to merge new flaws.

I updated the code. Now everything pointed out in the comments above should be taken care of. If you maybe could do a quick double check again @jadephilipoom, that would be nice 🙂.
For points which also affect files that are not relevant for this PR, I will open an additional PR. (comment about OT_WARN_UNUSED_RESULT and anonymous enum)

Looks good to me, thanks! Happy to merge once it's passing CI.


Suggestion: Make the MC version tab collapse like the OS/Java pie chart

The readablity of the version chart is currently not great if the plugin is pretty old.
Especially with the addition of newer versions, it can be hard to making conclusions from the tab in quick manner.

Generally developers and users only care about the major version digits (1.8, 1.12, 1.18...) and not the minor versions (1.12.1).
It would be great if the version chart could be of the same type of the Java and OS charts.
This would mean for example that 1.18 would be a slice that expands to 1.18, 1.18.1, 1.18.2 etc.
As a benefit this would also reduce the amount of smaller slices that might be there due to a single server staying on a old minor version.
If this is a reasonable request, I could look into making a PR for this.

Wrong repository, oops!


[Model] Add classification Task with Qwen2ForSequenceClassification

FILL IN THE PR DESCRIPTION HERE
FIX #8700 (link existing issues this PR will resolve)
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Adding or changing kernels
Each custom kernel needs a schema and one or more implementations to be registered with PyTorch.

Make sure custom ops are registered following PyTorch guidelines: Custom C++ and CUDA Operators and The Custom Operators Manual
Custom operations that return Tensors require meta-functions. Meta-functions should be implemented and registered in python so that dynamic dims can be handled automatically. See above documents for a description of meta-functions.
Use torch.libary.opcheck() to test the function registration and meta-function for any registered ops.  See tests/kernels for examples.
When changing the C++ signature of an existing op, the schema must be updated to reflect the changes.
If a new custom type is needed, see the following document: Custom Class Support in PT2.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

Key changes:

Implement Qwen2ForSequenceClassification model architecture
Add model registration for sequence classification variant
Include integration tests for the new model variant
Update documentation to reflect new sequence classification capability
Usecase is similar like #8896

python -m vllm.entrypoints.openai.api_server \
	--model jason9693/Qwen2.5-1.5B-apeach \
	--trust-remote-code \
	--served-model-name Qwen2.5-1.5B-APEACH \
	--port 8080 \
	--tensor-parallel-size 8 \
	--enforce-eager

@DarkLight1337  All of issues you commented was resolved.

To improve visibility, I also suggest adding a new entry to the Supported Models page of the docs.

To improve visibility, I also suggest adding a new entry to the Supported Models page of the docs.

I just added docs

It looks like the model test failed. PTAL.

Please merge from main to fix the CI failures.

Please merge from main to fix the CI failures.

I just rebased on main.
Let's waiting for the test

Very cool!
Is this compatible with the LoRA adapters functionality in vLLM? I'd love to be able to deploy a base Qwen2ForSequenceClassification and then have many different reward-model variants. The variants would have different LoRA layers and then separate score layers as well.

Very cool!
Is this compatible with the LoRA adapters functionality in vLLM? I'd love to be able to deploy a base Qwen2ForSequenceClassification and then have many different reward-model variants. The variants would have different LoRA layers and then separate score layers as well.

It was tested on the CI, but not sure as I'm not tested on my local server.
If it is broken, you can merge the lora weight and run on the vLLM
https://huggingface.co/docs/diffusers/main/using-diffusers/merge_loras

Is this supported in Docker?
I am getting:
ValueError: Model architectures ['Qwen2ForSequenceClassification'] are not supported for now. Supported architectures: ['AquilaModel', 'AquilaForCausalLM', 'ArcticForCausalLM', 'BaiChuanForCausalLM', 'BaichuanForCausalLM', 'BloomForCausalLM', 'CohereForCausalLM', 'DbrxForCausalLM', 'DeciLMForCausalLM', 'DeepseekForCausalLM', 'DeepseekV2ForCausalLM', 'ExaoneForCausalLM', 'FalconForCausalLM', 'GemmaForCausalLM', 'Gemma2ForCausalLM', 'GPT2LMHeadModel', 'GPTBigCodeForCausalLM', 'GPTJForCausalLM', 'GPTNeoXForCausalLM', 'GraniteForCausalLM', 'GraniteMoeForCausalLM', 'InternLMForCausalLM', 'InternLM2ForCausalLM', 'JAISLMHeadModel', 'JambaForCausalLM', 'LlamaForCausalLM', 'LLaMAForCausalLM', 'MambaForCausalLM', 'MistralForCausalLM', 'MixtralForCausalLM', 'QuantMixtralForCausalLM', 'MptForCausalLM', 'MPTForCausalLM', 'MiniCPMForCausalLM', 'MiniCPM3ForCausalLM', 'NemotronForCausalLM', 'OlmoForCausalLM', 'OlmoeForCausalLM', 'OPTForCausalLM', 'OrionForCausalLM', 'PersimmonForCausalLM', 'PhiForCausalLM', 'Phi3ForCausalLM', 'Phi3SmallForCausalLM', 'PhiMoEForCausalLM', 'Qwen2ForCausalLM', 'Qwen2MoeForCausalLM', 'RWForCausalLM', 'StableLMEpochForCausalLM', 'StableLmForCausalLM', 'Starcoder2ForCausalLM', 'SolarForCausalLM', 'XverseForCausalLM', 'BartModel', 'BartForConditionalGeneration', 'Gemma2Model', 'MistralModel', 'Qwen2ForRewardModel', 'Phi3VForCausalLM', 'Blip2ForConditionalGeneration', 'ChameleonForConditionalGeneration', 'ChatGLMModel', 'ChatGLMForConditionalGeneration', 'FuyuForCausalLM', 'InternVLChatModel', 'LlavaForConditionalGeneration', 'LlavaNextForConditionalGeneration', 'LlavaNextVideoForConditionalGeneration', 'LlavaOnevisionForConditionalGeneration', 'MiniCPMV', 'MolmoForCausalLM', 'NVLM_D', 'PaliGemmaForConditionalGeneration', 'PixtralForConditionalGeneration', 'QWenLMHeadModel', 'Qwen2VLForConditionalGeneration', 'UltravoxModel', 'MllamaForConditionalGeneration', 'EAGLEModel', 'MedusaModel', 'MLPSpeculatorPreTrainedModel']

I don't see any SequenceClassification model support...

Which version are you using?


[lint] system-config.ts should use simple quotes

In 1.0.0-beta.10, c85b14f5f7d34ee22cfdc8bb94080e85757a5d07 introduced "use strict" in system-config.ts whereas it should be 'use strict' to keep the linter happy

Closed as this issue was made obsolete by https://github.com/angular/angular-cli/pull/1455.


Listing accessible by URL when disabled

If you have a URL to a certain listing, you can always open the listing even if the listing has been disabled by an admin.
Steps to reproduce:
Login as bigbrother
Open Air Mail 1 listing
Copy URL
Go to Administration tab and disable the listing
Open new browser in Incognito and login as bettafish
Paste the URL from step 3
Air Mail 1 should open back up

PR Submitted.

Merged.

Merged


WIP (run the tests) Missing file

Remove the OS helper module, use platform_family? instead.

This change is

          1 Error

:no_entry_sign:
Please add labels to this Pull Request

  Generated by :no_entry_sign: Danger

Appveyor was good one run, travis was good on another.


Bump production to 0.98.0

Release https://github.com/cds-snc/notification-terraform/pull/259

@jimleroyer Could you review this?


Scroll bars are not appearing on dialogs when dialog extends off screen

The OK/Cancel (etc.) buttons should always be visible.  The inner portion of the dialog should have a scroll bar present.

The is affecting numerous dialogs.

This is a combination of the directive for the window content not using replace: true, which adds an extra element that is not a flex container, and the root element in the template not having d-flex flex-column. Fixing all I can find.


4.x: Intercepting the chaining of operators

There is a plan to inline the IQueryLanguage interface and QueryLanguage class into the Observable static class (See #526 & #539) to save on an indirection and interface lookup. The IQueryLanguage has been always internal so in theory, nothing should depend on it or the original indirection.
In practice though, looks like there exist tools such as RxSpy that seem to latch onto this feature so that the original s_impl in every operator could be overridden via a proxy implementation of the IQueryLanguage interface. Obviously, if s_impl is no longer used, this and other similar tools will break.
I'm convinced that the performance benefit of the inlining is quite worth it, but supporting external diagnostic options is also considerable feature requirement.
I can think of two approaches that could re-enable the overriding of the standard implementations, but there are caveats.
1. Keep the IQueryLanguage interface
The IQueryLanguage interface is retained an implementation can be inserted globally that takes precedence. Example (via IQueryLanguageEx for brevity):
namespace System.Reactive.Linq
{
    /// <summary>
    /// Provides a set of static methods for writing in-memory queries over observable sequences.
    /// </summary>
    public static class ObservableEx
    {
        private static IQueryLanguageEx _override;

        /// <summary>
        /// Override the default implementation of operators.
        /// </summary>
        public static IQueryLanguageEx Override
        {
            get { return Volatile.Read(ref _override); }
            set { Interlocked.Exchange(ref _override, value);  }
        }

        [Experimental]
        public static IObservable<TResult> Create<TResult>(Func<IObserver<TResult>, IEnumerable<IObservable<object>>> iteratorMethod)
        {
            if (iteratorMethod == null)
                throw new ArgumentNullException(nameof(iteratorMethod));
// vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
            var ovr = Override;
            if (ovr != null)
            {
                return ovr.Create(iteratorMethod);
            }
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            return new AnonymousObservable<TResult>(observer =>
                iteratorMethod(observer).Concat().Subscribe(_ => { }, observer.OnError, observer.OnCompleted));
        }
    }
}

Concerns:

Will the property access be inlined, minimizing the overhead of this approach to a simple volatile read and an uncommon branch?
This requires a full implementation of the IQueryObservable interface and there is no way to delegate back to the standard implementation publicly.
Security concerns about who can hook override a chain.

2. Use type-specific operator-assembly hooks
The alternative, that RxJava also uses is to define function hooks that get called before an implementation is returned, allowing insertion of custom logic and/or complete replacement:
namespace System.Reactive.Linq
{
    /// <summary>
    /// Holds type specific assembly hooks to intercept
    /// the chaining of standard operators.
    /// </summary>
    /// <typeparam name="T">The element type of the observable returned.</typeparam>
    public static class QueryLanguageHooks<T>
    {
        private static Func<IObservable<T>, IObservable<T>> _onAssembly;

        public static Func<IObservable<T>, IObservable<T>> OnAssembly
        {
            get { return Volatile.Read(ref _onAssembly); }
            set { Interlocked.Exchange(ref _onAssembly, value); }
        }

        public static IObservable<T> Hook(IObservable<T> source)
        {
            var f = OnAssembly;
            if (f == null)
            {
                return source;
            }
            return f(source);
        }
    }

    /// <summary>
    /// Provides a set of static methods for writing in-memory queries over observable sequences.
    /// </summary>
    public static class ObservableEx
    {
        [Experimental]
        public static IObservable<TResult> Create<TResult>(Func<IObserver<TResult>, IEnumerable<IObservable<object>>> iteratorMethod)
        {
            if (iteratorMethod == null)
                throw new ArgumentNullException(nameof(iteratorMethod));
// vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
            return QueryLanguageHooks<TResult>.Hook(
                new AnonymousObservable<TResult>(observer =>
                iteratorMethod(observer).Concat().Subscribe(_ => { }, observer.OnError, observer.OnCompleted))
            );
        }
    }
}

Concerns:

As I understand the struct/class generics, this approach requires the programmer do explicitly define typed callbacks for all possible types used in the host program: QueryLanguageHooks<int>.Hook = intobs -> intobs;
Using any standard method call on Observable inside the Func may lead to an infinite recursion.
Security concerns about who can hook into a chain.

(None of these is an issue with RxJava because Java currently only supports class-based generics so one can define an Observable<Object> hook only, the default implementations are semi-publicly available and finally there is a Java security manager infrastructure that can limit accesses so we don't have to deal with that at all.)
3. Keep both IQueryLanguage & QueryLanguage but do the override approach
Establish a static path via QueryLanguage.SomeMethod() instead of s_impl.Create:
namespace System.Reactive.Linq
{
    /// <summary>
    /// Provides a set of static methods for writing in-memory queries over observable sequences.
    /// </summary>
    public static class ObservableEx
    {
        private static IQueryLanguageEx _override;

        /// <summary>
        /// Override the default implementation of operators.
        /// </summary>
        public static IQueryLanguageEx Override
        {
            get { return Volatile.Read(ref _override); }
            set { Interlocked.Exchange(ref _override, value);  }
        }

        [Experimental]
        public static IObservable<TResult> Create<TResult>(Func<IObserver<TResult>, IEnumerable<IObservable<object>>> iteratorMethod)
        {
            if (iteratorMethod == null)
                throw new ArgumentNullException(nameof(iteratorMethod));
// vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
            var ovr = Override;
            if (ovr != null)
            {
                return ovr.Create(iteratorMethod);
            }
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            return QueryLanguage.Create(iteratorMethod);
        }
    }
}

My only real points would be:

You mention that there are performance benefits, if so what sort of measured gain can be seen?
Would workarounds not involving a replacement IQueryLanguage work on all platforms e.g. iOS & Android as well as the more commonplace ones?
From my own perspective, I found being able to 'proxy' the IQueryLanguage very helpful indeed when working Android for diagnostics and debugging. It would be a shame to loose the capability and moreover it would be desirable to retain an official approach as to how to achieve this without the kludges.
Perhaps with more official support the approach of getting to the internals and seeing what is being passed through could become one of the tools that people reach for when adding diagnostics to their applications during development.

Background
The design of IQueryLanguage came from an early effort to support a debugger for Rx. The source history may reveal an [InternalsVisibleTo("System.Reactive.Debugger")] somewhere. Unfortunately, this effort was put on halt after shipping Rx v2.0 when the project was transferred to OSS and the prototype of the debugger wasn't moved over due to a plethora of external dependencies, but I can recover the design from memory more or less.
Essentially, it worked by decorating each operator in each reactive query expression using an Observable.Create wrapper providing hooks for Subscribe, Dispose, and each On* method on the observer, akin to this:
static IObservable<T> Intercept<T>(this IObservable<T> source, DebuggerHooks hooks)
{
  return Observable.Create<T>(observer =>
  {
    var d = hooks.Subscribe(source, observer); // internals calls observer.Intercept(hooks) to decorate the observer
    return hooks.Dispose(d);
  });
}

where hooks.* methods wrap the action provided in a try...catch...finally... statement to invoke BeforeX, AfterX, and FailX calls on the hook. In here X is any of the following: Subscribe, Dispose, OnNext, OnError, OnCompleted (so 5 lifecycle events, each having 3 phases).
The DebuggerHooks object has events for each of these, which can get set by a debugger, e.g.

to "break on exception", a callback is attached for all FailX events,
to set a "breakpoint" on a . between two operators (really a pipe through which events flow), a callback is attached to all BeforeOn* events,
etc.

The operator topology was inferred for visualization purposes by means of handling the Subscribe and Dispose events on the hooks, correlating the observers to operators. E.g. when xs.Foo().Bar() is being subscribed to, the hooks around Bar see the observer that's being passed to Foo, thus establishing the relationship between both operators. That provided a similar visualization as the task debugger in Visual Studio (see Tasks Window).
Usage
I know of a few places where this functionality has been used. RxSpy was mentioned before on this thread and seems to be the right approach for a reactive debugger going forward. Internally over here, I can think of two efforts that have directly depended on this functionality for diagnostics and throttling (detecting hot nodes in query operator graphs and providing alerts or taking actions), but I'm not sure about these state of those and will try to find out.
Also, in earlier days, IQbservable<T> supported binding to IQueryLanguage instances when compiling queries, bypassing the whole static extension methods dance, while enabling to bind to different in-memory query processor implementations that share the same Rx language surface.
So, I think it'd be unfortunate to get rid of this functionality altogether, and IQueryLanguage has provided for the most fine-grained means to intercept operators, which is a useful property to retain (rather than having a single "intercept anything" mechanism).
Advice
I think it'd be worth for motivated community members to revamp this effort :-). I'm not sure if @niik would still be interested in his work, possibly bringing this project to the .NET Foundation as a tool that goes right with Rx. In fact, in a bigger scope for tooling-related projects, it wouldn't be a bad thing for Rx to include Roslyn analyzers to provide refactorings (e.g. on an event, provide a Create FromEvent wrapper, etc.) and analyzers (e.g. detect common mistakes).
Though I'm biased towards the original design, I do believe that IQueryLanguage as it exists today has the right granularity and the right place in the layer map, right in between the language projection (i.e. extension methods) and the query operator implementations. The removal of the System.Reactive.PlatformServices stuff has led to all functionality being flattened in one assembly, making it hard to appreciate this original placement as a means to separate one particular System.Reactive.Linq implementation from alternatives, with an interceptor in the middle (also supporting dynamic assembly loading of various "enlightenment modules", initially to deal with the differences between target .NET versions while keeping all System.Reactive.* assemblies other than System.Reactive.PlatformServices platform-agnostic and portable).
I'm also not sure I buy in to the performance argument, given that these are high-level control plane operations that only run during composition of query operators. That is, they don't run for Subscribe/Dispose lifecycle operations, nor for event flow in the data plane. The only place where they end up in the data plane is when queries are being composed within a selector such as SelectMany and it's unclear to me this would really move the needle on performance (compared to all the heavy lifting inside operators such as IDisposable allocations), so I wouldn't kill functionality without hard performance numbers. (In fact, work in CoreCLR's JIT to provide more effective call devirtualization may even be effective here, but I'd have to spend some time to do a thorough analysis.) In Rx, we've always tried to reduce cost in the data flow plane by pushing cost to the control plane when possible.

I'm not sure if @niik would still be interested in his work, possibly bringing this project to the .NET Foundation as a tool that goes right with Rx.

I'd be delighted to see RxSpy evolve alongside with the ecosystem. I firmly believe that visualisation, debugging, and intelligent analysis of reactive flows is indispensable when working with large scale reactive applications and I think it would be a bummer if the ability to innovate in that space would diminish.
I wrote RxSpy to explore what reactive analysis tooling could look like. In hindsight it was clear that live analysis, while being an excellent tool for teaching Rx, and one I used several times to explain the concepts, was likely not going to be as powerful as sampling, replaying and analysing flows after the fact. I started toying with that in https://github.com/niik/RxSpy/pull/25 but never completed it.
That said I'm afraid my work has lead me down other paths and I haven't been able to keep up with Rx for quite some time now. While I'd be glad to help I'm afraid my bandwidth is quite constrained these days.

I took the work @niik had done and adjusted it to work on Android, not for visualization per se, but to get better diagnostics when things didn't work. See https://github.com/VistianOpenSource/Vistian.Reactive.Proxy  .

Cool, thanks for chiming in @niik and @VistianOpenSource. I think it's pretty clear that this mechanism is something we should keep and build on going forward. The main difference for implementation techniques on newer .NET platforms may be the lack of transparent proxy stuff, but it'd be fairly trivial to auto-generate an interceptor IQueryLanguage implementation at compile-time by reflecting on the interface and generating code using some T4 file.
We'll keep this issue as a coat hanger for future discussions.

Looks like the current setup is here to stay ever since. Closing.


Use Go implementation of libpcre

Might this implementation of libpcre be a suitable replacement for the one mentioned in the readme?
https://github.com/Jemmic/libpcre

After a lot of research, it turns out most uses of PHP's preg_* methods are compatible with re2/golang's own regexp engine.
Conclusion: creating a "re2" ext that exposes golang's regexp engine and also weak (ie. overridable) preg_* methods should allow most PHP apps to work, and might even result in a security improvement as re2's linear time execution isn't subject to the class of attacks abusing pcre features.

+1 for avoiding cgo whenever possible. Most apps dont rely heavily on regex so even if the pure go implementations is slower, it shouldnt matter.
I glanced over my old PHP projects and all of them use regex that's compatible or can be translated to  go's regex.
I think this is great!


Power Attack Bug

Power Attack results in null reference.
Just use the bugged hero and turn on power attack. The game freezes when a combat starts.
Characters.zip

cannot repro at all using mentioned hero.


Fix typo in JSDoc

Just fix a typo in JSDoc by swap letter g and n. Not introduce any new features, no breaking changes, and fully backward compatible.

Coverage remained the same at 96.499% when pulling 751f910ac3292984101a85974d3395633ef874b3 on mul14:patch-1 into 98c14e6a20a7ad8e095cbf733b191ec35a5e6925 on adonisjs:develop.

Thanks 👍


Istio, Linkerd, Tekton policies

Related Issue(s)

Closes #398
Description

This PR adds 7 new Istio policies based upon security best practice guidance and 3+ for Linkerd. It also adds one new policy for 1.8.0 on how to get the version of the Kubernetes API server. Adds Tekton policies.
Checklist

[x] I have read the policy contribution guidelines.
[x] I have added test manifests and resources covering both positive and negative tests that prove this policy works as intended.

@eddycharly would you mind?

Looking for review please, @JimBugwadia and @eddycharly


Creation of a Slack

Hello,
Do you think a Slack channel can help to collaborate on your script?
When compiling the mac version, I had few questions on the mac-deploy.sh and create-dmg.sh.
This discussion could be easily be done on a Slack to avoid spamming you with "Issues".
What do you think?

Created openskystacker.slack.com. For now the invite link is: https://join.slack.com/t/openskystacker/shared_invite/enQtMzcyMzk1MjM2NjQ3LThjMWZkM2VmM2RjNDhjMThhYzI3MjM2NmY1OWY2NWQzOGI3MjNjNWMwYzczNWIyZTY3M2NiYmI2Y2QyZmQ5Zjg
Unfortunately there's no permanent invite link so it will have to be rotated when it expires. There is also no way to make it open to everyone, only to add accepted email domains.

Invites can be obtained through Slackin here: https://slackin-wcxghxpnim.now.sh. Added the badge to the readme.


disabled dataLIFs are picked up by controller during ControllerPublishVolume

Describe the bug
We have a situation where the 2/4 dataLIFs have been disabled. Trident continues to use all 4 of them during ControllerPublish which in turns gets passed to NodeStage and is used for initiating iscsi connections. The connections fail (as expected) and we end up in a bad state.
Environment
Provide accurate information about the environment to help us reproduce the issue.

Trident version: 20.10, 21.01
Trident installation flags used: nothing special
Container runtime: 19.03, 18.09
Kubernetes version: 1.19
Kubernetes orchestrator: Rancher v2.x
Kubernetes enabled feature gates: none
OS: CentOS7 with elrepo kernel
NetApp backend types: ontap-san, ontap-nas
Other:

To Reproduce
Disable a dataLIF, attach a volume after disabling.
Expected behavior
The disable LIF doesn't get picked up and used.
Additional context

time="2021-02-07T20:32:01Z" level=debug msg="Data LIFs with reporting nodes" reportedDataLIFs="[<IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS>]" requestID=e7bb2fc9-d680-469e-8e34-6cb186987531 requestSource=CSI
time="2021-02-07T20:32:01Z" level=debug msg="Attempting volume publish." backend=ontapsan_<IP_ADDRESS> backendUUID=c9e1539e-b4d2-43f2-9444-7c518f1f9d54 requestID=a335277c-a53d-4c90-a1ed-ec5ac1a45548 requestSource=CSI volume=pvc-734edbb5-c733-4297-aa75-a910509d797d volumeInternal=trident_dev_pvc_734edbb5_c733_4297_aa75_a910509d797d
time="2021-02-07T20:32:01Z" level=debug msg="<<<< ControllerPublishVolume" Method=ControllerPublishVolume Type=CSI_Controller requestID=e7bb2fc9-d680-469e-8e34-6cb186987531 requestSource=CSI

After completely deleting the dataLIFs we get this in the logs:
time="2021-02-08T17:44:32Z" level=debug msg="Data LIFs" dataLIFs="[<IP_ADDRESS> <IP_ADDRESS>]" requestID=d0c9ef3f-e1b7-4090-91e0-70c315fd900d requestSource=Internal
time="2021-02-08T17:44:32Z" level=debug msg="Found iSCSI LIFs." dataLIFs="[<IP_ADDRESS> <IP_ADDRESS>]" requestID=d0c9ef3f-e1b7-4090-91e0-70c315fd900d requestSource=Internal
time="2021-02-08T17:44:32Z" level=debug msg="Read storage pools assigned to SVM." pools="[SSD_7600_01 SSD_7600_02 SSD_3800_03 SSD_3800_04]" requestID=d0c9ef3f-e1b7-4090-91e0-70c315fd900d requestSource=Internal svm=hq00nvsp07

One way to address this for all ontap drivers is to use ONTAP's on-box DNS load balancing (or a round-robin DNS for that matter) and explicitly set the dataLIF in the backend.json. The good thing with the on-box DNS load balancing is that I would assume it would handle LIFs that are down and can avoid this issue altogether.

@balaramesh I believe if you explicitly set dataLIF you lose multipath support.

Yep you are right

This is fixed with commit abefaa and will be included in the Trident 21.04 release.


NextJS support added.

NextJS support added. Readme Updated.
If there is anything you would like me to fix to merge it, please let me know.

thanks!


institutions: add ui tests

INSPIR-3443

I'll just merge it like this and enable them all in the release instittutions PR


Add "element":"self" to compose as default element value for waitFor action types

The waitFor action type was tied to an element while only the predicate was the relevant. The changes

move the waitFor to BasePageObject
generate a this.wait instead of a this.element.wait
allows for compose actions to be defined without elements (only for waitFor)
if an element is specified for the compose action, it is ignored.
PO creators can explicit specify 'self' to denote a self reference
isPresent is also now applicable for self references with the same rules as waitFor.

@kartikperumal I don't quite understand some parts of the code to be honest, let me check how it's done in JS and try to align, will probably create new PR

commits were moved here https://github.com/salesforce/utam-java/pull/36


Navigating scroller up/down requires a double tap

@oittinen i think ive managed to fix this, please test!


Improvements on discovery map-view interface

The succinct summary of these changes is as follows:

[ ] - Don’t list the resource titles of coverages on the right. If possible, expand the map into that area. Instead, we will list them in a different way. See below.
[ ] -  Don’t display centers of coverages. See below.

Then, implement a new mechanism for coverages as follows:

[ ] -  Allow users to choose a specific rectangle to bound the search, independent of the zoom level. This could be a button “limit search to visible region” along with another button “remove search region limits” and “zoom to search llimit” that only appears when the search region is selected. These should be above the top of the map.
[ ] - Make pan and zoom of the map independent of this function. If a search bound is selected, it appears as an unshaded rectangle (if possible, with a dotted edge) when users pan and zoom around it. Users can pan and zoom anywhere on the map and unless they “limit search to visible region” the search will be unchanged and unlimited.
[ ] - List spatial boxes as icons above the map without titles, horizontally and possibly scrolling onto multiple lines. Each icon represents a specific coverage that is visible. These icons mean different things than before:
Combine resources with exactly the same spatial coverage into one icon.
Clicking on an icon pops up a (potentially scrollable) list of resources with that coverage. This should include “zoom to” and “show resource” clickable links for each resource. Only one of these lists pops up at a time.
The icons shown are limited to those coverages that match search criteria and overlap with the current view area. There are no icons shown for regions with no search matches.
The icons themselves are squares that are shaded to represent the shape of the coverage in the view area.

A totally black rectangle if the coverage covers the whole view area.
Otherwise, a rectangle with a black border, white fill, and black embedded rectangle depicting the coverage and its relative position on the current view.

Sort these in order of decreasing area.
Do not categorize by area – no area labels.
You might need a new javascript library to create these small images. See if you can create them clientside in the browser.

Also, start thinking about how we might implement the following:

[ ] - Allowing a user to draw an arbitrary polygon as a search bound.
[ ] - Allowing import of the USGS watershed deliniations as search bounds.

There is another approach being discussed here.

Get rid of the right box and extend the map there.

In the map view, replace the facets box with a coverage list with abbreviated resource titles in alphabetical order.
a. eliminate articles: "a", "the", etc.
b. truncate the title to a few words.
c. alphabetize after that elimination.

Split coverage resources into two types:
a. coverages that overlap but do not cover the current area.
b. coverages that completely cover the current area.

Treat these two types differently:  Put them in different lists, and then:
a. hovering over an overlapping coverage shows the coverage on the map. Clicking on it gives information on the resource.
b. hovering over a covering resource (whose coverage is more than the current area) does not show the coverage on the map. Clicking on it works similarly. See below for one mockup from @danames .
@martinseul contributed to this. @dtarb: we continue to refine this idea.

figure.pdf
Let's try this first before getting fancier......
A first step would be to modify the right-hand list to conform to this, and then move it to the left in a later step.

@alvacouch

Do we have to show anything when we firstly initialize the map?
If we initialize the map with markers clusters, when hover over a resource title, do we want to zoom in the cluster to show the corresponding symbol? Or do we just stay on current map view to show the symbol?
Do we automatically update the titles list as the map's bound changed?

Initialization stays the same.

Clusters indicate point resources.
Lists of coverages are all coverages matching the extent (globally)
we don't want to zoom when hover. We do want to be able to click on a coverage title and get a popup that allows us to zoom or visit the resource.

We do automatically update the titles as the map changes.

@xuezhaokun This modification still assumes that we add buttons for limiting the search. Zooming does not change the search. It does change the coverages that are included, excluding the ones that don't overlap the current view region.

For example, if hover over resource "random point" which is a point resource inside this cluster, do we want to show a marker above the cluster symbol?

@xuezhaokun We should do what we always did with point resources:
a) no listing in the master directory above.
b) a popup that describes the resources that is exposed when we get to a single resource.
c) zooming to resolve clusters.

@alvacouch OK. That's clear. Since in the mockup figure, the instruction says we want to list all resources including point resources, it makes me feel some confused on how to deal with point resources.

@xuezhaokun I think it's a bit of overkill to do point resources in the list. We might do it eventually, but for now, let's do the point resources the way we always did. The open problem is how to deal with the coverages.

@alvacouch Got it!

I'm experimenting with the current release on playground. Nice work implementing this, Zhaokun. This is very much what Alva and I discussed at the CUAHSI meeting. I do have a fairly large workflow modification request and a couple of smaller suggestions:

The workflow needs to be updated to be a bit more natural for the user. I've explained the updated workflow together with what it would look like in this figure:

Capture the "Enter" button click on the location search box and perform the zoom in search based on that click. Also change the name of the button "Zoom in" to "Go"

Update the legend to include clusters and polygons, and also make the legend more compact (using less space):

@danames Thanks for your suggestions, Dan! There are two things I am worried about this design.

If we show all the boxes on the map, there might be a lot overlapping rectangles. It might make the map look messy.
For resources coverage the same area, we will have two exactly overlapping boxes in that area. When users click the box, it would be confused to decide which popup window should be shown. If we just show one box for such resources, and when users click it, we show a list of resources in this area, we would have the problem we had before. Users would have no idea about how many resources in this area, until they click the box to see the list.

Do you have any advice on these two issues?

Here is an idea that may help.  If there are overlapping boxes (be they exactly overlapping or not) in the display and a user clicks in the overlap area, rather than show just the top one (as Dan suggested) pop up a box that shows up to 5 that overlap at the click point with a more option to open a window that shows all similar to the windows used for selecting resources for some of our apps (HydroShare GIS app specifically).
I agree that with many resources the maps may get messy.  This can be an issue for point resources too.  Users will need to learn to filter on other facets as well as the map to resolve some of this.

Zoom controls need adjusting.  If I go to playground and select discover and then my name in the Filter by owner facet, I get one red dot in the middle of a blue area.  It looks like the middle of the ocean.  However after zooming out a few levels I find I am in the middle of a small reservoir.  It should not have zoomed in so much.
Also when using drag zoom mode, keep it turned on until the user clicks on another tool or clicks to turn it off.  It is natural to zoom a bit, then want to drag zoom a bit more, and a nuisance to have to click the tool again.
Also, drag zoom mode does not appear to zoom to the area dragged.  It goes to an area somewhat bigger.

@dtarb

For the overlapping concern, for example, if we have 3 exactly overlapping resources, there would be only "one box" (three overlapping boxes) shown on the map. I think this might be confused for users. Users might see 3 resources from the list view, but on the map, they just see 1 box. They may think the display on map is wrong. The number of boxes on map does not match the number of results from list view. If they do not click the box to show the resource list, they will have no idea how many resources in this box. Do we have to take any care about this issue? Or we always want our users to click the box to find out what resources in the box.
For the zoom control problem, I made a function for calculating the zoom level based on the bound provided by markers. As we add a marker, we extend the map bound based on the marker's position. And finally based the map bound we get, we calculate a proper zoom level for it. For you case, since you just have one marker on the map, the bound generated by the marker is very small, and we will have a really high zoom level. That's why it zooms in so much.
As for drag zoom, I think it tries to center the drag area, then scale and zoom to a proper level. I don't think it is going to set the map bound to be exactly the same as the drag area.

For exactly overlapping resources, I think that having one box that you can click on to see the 3 resources listed is better than having no box and having to find the resource in a list at the top.
For zoom control, I understand your explanation.  I just think that the level to which it automatically zooms in should not be so small.

@dtarb Yes. I agree with the suggestion on overlapping problem. I will take a look at the zoom control issue to see if there is any proper modification I can make on it.

@dtarb @danames I am not sure whether we still want to keep working on the new design. Based on my implementation so far, it looks really messy. This is the view when we initialize the map:

If we zoom to the United States, it looks awful. I think the overlapping boxes just make the map-view even more confused.

As the number of box resources increases, it will look worse. I do not think people would like this idea. I am wondering if there is any improvement we could do based on our last design. I think that one looks better than this.

I think that a softer color, like light blue, light green or light orange would be better than the glaring red.  Dont make it darker and darker as you get more overlaps.
Also I think that one of Dan's suggestions was to only show boxes that fit completely within the view.  This could be extended to boxes that have their center within the view.
And I would consider showing clustered point resources in the same color as point coverages, and box centers and clustered box center resources within the view as the same color, but different from point coverages.

I am not sure whether we could find a way to avoid the boxes get darker and darker as they overlap. I will try to see what I can do here. For now, we are not showing the centers of boxes. I am not quite sure whether people want to get the centers back.

On Aug 22, 2016, at 16:17, David Tarboton<EMAIL_ADDRESS>wrote:
I think that a softer color, like light blue, light green or light orange would be better than the glaring red. Dont make it darker and darker as you get more overlaps.
Also I think that one of Dan's suggestions was to only show boxes that fit completely within the view. This could be extended to boxes that have their center within the view.
And I would consider showing clustered point resources in the same color as point coverages, and box centers and clustered box center resources within the view as the same color, but different from point coverages.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@dtarb After some discussion with Martin, we still think it is better to keep the list-view and map-view tabs. Instead of combining them together, we add a similar grid under the map, which shows all box resources overlap current map bound. If we combine these two views in one tab, users always have to do a filter action when they want to display the mappable results on the list view. We now always provide this filtered list under the map. Users can select mappable resource from this list. I have pushed the latest code to my PR #1388 . I do not how to deploy it on playground. Can you let someone to deploy it on playground and do some test on it? If people like this idea, I will continue the optimization work on this version.

OK.  @mjstealey can deploy for you or tell you the instructions for you to deploy yourself on one of the test VMs.

@xuezhaokun, @dtarb - deployed to https://playground.hydroshare.org
Branch discovery-add-geocoder-with-new-style using copy of production resources

@xuezhaokun @danames @horsburgh @dtarb
Keep in mind that we are trying to solve an open research problem. There is a new version that does some of what you suggest.
I would suggest that we stop when this is "good enough" and go on to other pressing issues:
a) discovery based upon file metadata.
b) user discovery
c) group discovery
We can always come back to this later. Methinks there is no easy solution that actually "solves" the current problem, because
a) most current solutions assume a bounded collection that is targeted at a single experiment/problem.
b) we actually have an unbounded collection that lacks that kind of cohesion.

@mjstealey I fixed some bugs on this branch. Can you help me to deploy the latest version of this branch to playground? @dtarb Can you just let people to test it and leave comments on it?

deploy the latest version of this branch to playground?

@xuezhaokun - This has been redeployed to playground.

@mjstealey Thanks!

Looking at on Playground the first thing that puzzled me was I see a map with 18 resources centered over Utah, 11 over NC both orange and two over Germany, red dot, but the list below lists 94.  18+11+2 != 94.
There is no indication of this on the page, but I figure out by clicking on items on the list below that they represent box coverages.  I can click on list items one at a time to get the box displayed, but scrolling the list and clicking one at a time is very unwieldy.
So, while I am very sympathetic to moving on, this does not resonate with me.
I actually prefer the current deployment on www that shows the centers of all box coverages on the map and then the box when you click on the center.  I suggest you actually go back to what is on www and work to enhance it from there.
Here are enhancements I would suggest starting from www.  Once a resource is selected by selecting the box center there should be an option to zoom to extent to see its coverage.  There should also be the ability to select resources actively by clicking a check box in the pop up or selecting with a select box, rather than automatically going with the map display.  The reason for this is so that when you zoom out to a big box you do not lose the resources you may already have selected.  I would also prefer to see the list of map selected resources below the map, rather than in the list tab, so that effectively the toggle Map results and all results is the tab switch.

@dtarb OK. I will discuss about it with Alva and see what we can do from that point.

I really don't like just having markers for the extents. The marker can be off the page, so that one has no indication that there is an extent. One option I have discussed with @xuezhaokun is to draw the borders of the extents without shading. This indicates that something is there even if the marker for the extent is off the screen.

@dtarb  I will try to see whether there is some easy way to implement @alvacouch idea on google map. For this idea, I am still not quite sure whether we will have the same performance issue as we had on showing all rectangles on the map. It seems one of the main issues here is whether we want to show box coverages' centers on the map. If not, how can we indicate users that we have box coverage resources and they can discover them on map... If we list all box resources as we have now, can we just make some help text to indicate users what the grid means and what they can do from the grid?

I think that having to click on a list to show a coverage is a bit clumsy.  My first preference would be to try what I suggested above with box centers in a different color, like it is on www right now and then only see the box when a user clicks on the center point.  @alvacouch does not like this due to box centers out of the extent shown not being able to be discovered.  One way to overcome this may be to add a link/button "Expand to show resources whose coverage overlaps the domain".  This button would expand the map to all resources meeting the filter criteria that overlap the domain, and show their centers.  Their coverage could then be shown by the same clicking option.  The search extent would remain the same, i.e. be smaller than the view extent (and be indicated by say a dashed line) and other resources in the expanded view extent that do not touch the search domain would not be shown.

@dtarb Your suggestion to "expand to show resources whose coverage overlaps the domain" does not make logical sense. Since the domain is the displayed region, this will change the domain. Thus, recursively, you'll end up with the whole world.
There is something more elegant that takes a bit more time to do. I have seen GIS apps that deal with overlapping domains by shading either the inside or outside of the borders of overlapping regions without shading the interior. Thus, the outlines are shown, but the inside of an outline is obvious from context.  For example, using a gradient rectangle, one gets:

@alvacouch you only read half of my suggestion.  "The search extent would remain the same, i.e. be smaller than the view extent (and be indicated by a dashed line)" separates search and view extent and stops the recursion.  Though if you do have one resource that covers the globe the first expand would go to the globe.  This may not be that bad as it would reflect clearly discovery of global resources and zooming back in will find other resources.  The suggestion does require separation of search extent and view extent though.
I think that shaded rectangles may work.  I look forward to the demo.

@dtarb @danames @xuezhaokun @horsburgh When Zhaokun and I were talking after the Wed meeting, I had a different and very simple idea for dealing with scale on the coverages.

First, make it possible for a user to drop a pushpin anywhere on the map. Then make the bottom view consist of all coverages overlapping that pushpin. This includes coverages that are larger than the current view.
Depict all coverages as mostly transparent outlines. Thus, if there is a lot of data for a coverage, the outline will be darker.
Hovering over a coverage in the bottom view fills its outline.

What do people think of that idea? It would most definitely deal with scale, which the popup solution doesn't. In particular, there are regions in which one can click (e.g., near the CZOs) in which there will eventually be hundreds of available coverages.

@dtarb @danames @xuezhaokun @horsburgh I might add that I've considered other options that seem to have incredible downsides. The following don't seem to scale:

Shading the interior of rectangles before clicking.
Getting a popup in response to an area click.

The proposal is relatively easy to code, because we don't register the individual rectangles for events (another scaling issues) and instead register the canvas as a whole.

@dtarb @danames @xuezhaokun @horsburgh I think it's really important to remember that in a discovery situation, we are doing to deal with depiction scale issues that we will never deal with in visualizing an individual resource. A single point can contain thousands of related resources. This is especially true if we eventually give the user the option for searching for "any resource that contains information on this point". This would include model instances as well as point coverages.

@dtarb @danames @xuezhaokun @horsburgh Of course, we could instead allow the user to drop a rectangle upon the area and report upon that rectangle, but that seems somewhat redundant, as this does the same thing as modifying pan and zoom.
Your thoughts?

@xuezhaokun @dtarb @danames @Horsburgh:
I had a brief conversation with Rick Hooper on this issue. He said that we should not be thinking in GIS terms. Instead, we should be thinking about the discovery problem and how to solve it best. He likes the list of things that show up on the map -- the same ones that have come into contention lately as too "awkward".
He has the following possible suggestions:

Perhaps separate the list of extents contained in the view from the list of extents that are larger than the view.
Rectangles are shown for the latter.
Hovering over an element in the list shades its box/polygon.
(we already know that shading all rectangles under the mouse leads to unusable shadings)

He also suggests that we might be thinking too literally in GIS terms. One alternative to traditional GIS is a "heat map" approach in which we separate the view into squares and shade each square in proportion to the amount of data for the square. Clicking on a square shows its data. Etc.

I think we have circled on this a lot and it's time for you to choose.  Each time I am asked, I find myself coming back to the suggestion already given which are:

Separation of search extent (a rectangle) from view.  This can be the same as dropping on a search rectangle that Alva suggested, and allows a button "expand to show selected resources" to show the resources found without adding more resources to the found set.
Showing box centers (as www does now).  This provides a place on the map to click to see details (and the box) for a box coverage resource.
Show a list of the resources within or overlapping the search extent box.  Clicking on a list element also shows the box.  This fills the list need expressed above and allows identifying resources whose centers may be outside the view extent.
Only showing the box for a resource that gets a click (either on its center on the map or on the list).
These operations are superimposed on the set selected by other non GIS filter facets (author etc. as I think is the case now) so we combine GIS and non GIS discovery.

This has formed itself in my mind as a model that would work.  I am open to other ideas, but each time I see an implementation that does not resonate, this is what I end up coming back to, as a suggestion.
The resource heat map idea does have some appeal, but as some level I think it is helpful to see the resource box and have a place to click (its center) to go to the landing page.  The heat map could be a mode that the map could be placed in (and if we monitor and record which mode people tend to use we would learn which is working better for users).  Could monitoring and learning from user behavior be a functionality that we add for HydroShare 2.0

@danames @mseul @dtarb We now have a super-elegant solution in which

Click always selects what's under the click.
Drag always pans.
Rectangles are selected with click, like points.

We are seriously considering whether dragging rectangles is needed, because

This is a different definition of what drag does.
That, in turn, requires a mode button to enable both pan and rectangle select.
(That mode button would have a hand and an arrow (pan versus select)).

Argument for the mode button: We can do rectangle selection.
Argument against the mode button: Simpler user interface.
(Obviously, if we do the mode button, select is going to be the default)
Your thoughts?
In other words, how important is it to be able to select a group of resources to show in the bottom box, and what kinds of things would we want to do to them as a group?

@alvacouch and @xuezhaokun

Oops. Pan should be the default mode. This means that click always means select, but drag won't mean select unless we disable pan.

I do not follow exactly what you are suggesting so perhaps should wait to see a demo.  I do not understand "Pan should be the default" and "click always means select" because to me pan means clicking at a point and then dragging the map.  How does one pan without clicking if click always means select.
I also think it is relatively natural to, when presented with a map with multiple dots, to be able to select more than one of them and do something with all the items selected.  In this case the things to do may be to add to a folder in my resources, or tag with a tag in my resources as ways to categorize and organize the things found.  If these things have to be done one resource at a time, it is OK, but not quite as slick.

@xuezhaokun Can this be closed?

Apparently we can't close it because there is still content under discussion.

I agree with this being closed as the noise to signal ratio in here is high.  There are many comments about test deploys that no longer exist, so the discussion needs to move on from this issue.  Lets work on map improvements in #1755 and other Discovery improvements in separate issues for them.


Feature request: customizable escape function

It' be nice to be able to pass an escaping function to accommodate instantiating templates for non-html languages. Pystache supports this via an escape parameter. As a use case, I use mustache templates in C++ code generation, where escaping & breaks everything. I can explicitly unescape things in the templates, but it's just easier to pass escape=lambda x: x. JSON string escaping comes to mind as another use case.

@redsun82 did you manage to get this workaround?

not really, I filed this when I was considering porting my code from pystache to chevron, but this was a blocker, so I just kept pystache

@redsun82  Got you. Why did you consider moving? I see pystache last commit is 10 years ago, do you have any problem with it?

@shahargl pystache works reasonably ok, but it's not up to date with the mustache spec. In particular I was interested in parents with overrideable blocks, which would simplify a bit my templates, but are not supported by pystache.
Obviously a workaround for this specific issue is to consistently use {{{...}}} in the templates instead of {{...}}, but that adds a bit of visual noise to the template files.


The links in the profile section of the user do not redirect to next page.

Description
The social links in the profile section of the user in LinkFree do not redirect to a new page, they open in the same page.
Screenshots

Additional information
No response

Opening on a new tab is a good idea. If the maintainers are okay, I can work on it with their blessings.

Opening on a new tab is a good idea. If the maintainers are okay, I can work on it with their blessings.

It's actually best practise and better for accessibility not to open links in new tabs/windows unless it causes the user to lose something they're already doing eg filling in a form. This is because not everyone can see that a new tab/window has opened and screen readers don't automatically announce that a new tab/window has been opened which can lead to  confusion about which tab is open and the browsing history may not be as expected. Therefore, I would not suggest we make this change.

As an advocate of a11y, this is great advice Emma. I didn't know it before.

I'll close this and the associated pull request since it's more accessible to leave them as they currently are.


Chinese characters are not correctly encoded while debugging Python in VS Code

VSCode Version: Code 1.6.1 (9e4e44c19e393803e2b05fe2323cf4ed7e36880e, 2016-10-13T16:21:53.542Z)
OS Version: Windows_NT ia32 10.0.10586
Extensions: donjayamanne.python-0.4.2, dvdbrink.vscode-sql-connect-0.2.1

Steps to Reproduce:
代码为：
print('我的代码')
输出显示为：
�ҵĴ���

Steps to Reproduce:
The code is  print('我的代码')
The out put is �ҵĴ���
@shixuexeon , can you try to run this piece of code in your terminal and provide the output?

Closed, moved to https://github.com/DonJayamanne/pythonVSCode/issues/431


dashboard for events

make custom cards for different events
features to be added, title, image, dates, tags, organised by, bookmark, add to calender icon.
a navigation bar to toggle between live, past, upcoming.

completed


build: clean up DEPLOYMENT_TARGET_*

These flags were used by CoreFoundation whcih was exposed through Foundation.
Now that that is no longer exposed, remove the unnecessary CFLAGS.

@swift-ci please test


Please support Angular  5

Please support Angular  5.
[16:02:56] Starting 'ngc'...
[16:02:56] 'ngc' errored after 1.59 ms
[16:02:56] TypeError: args.indexOf is not a function
at module.exports (/build/brower/gitrepos/src/packages/@mycompany/ngrx/node_modules/minimist/index.js:44:14)
Change gulpfile.js to:
/**

Run the Angular compiler, ngc, on the /.tmp folder. This will output all

compiled modules to the /build folder.
*/
gulp.task('ngc', function () {
return ngc(['-p', ${tmpFolder}/tsconfig.es5.json], (error) => {
if (error) {
throw new Error('ngc compilation failed: ' + error);
}
});
});

I'm working on an Angular 5 update. Should be released later this weekend 👍

v12.0.0 of the generator has been published with support for Angular 5 👍


Document that seed files are run in transactions

I was doing something further down that raised, so I spent one hour trying to figure out why the first object was not being created =(

Not only that but also that large files can take a very long time to show any progress as well as lock the database in the process.
Adding BREAK EVAL helps with seed-fu's memory but not with the pending transaction database memory usage.


Do not mutate options[:include] in ObjectSerializer#process_options

This pr makes it so options[:include] is not mutated when ObjectSerializer calls process_options.  This allows for the sharing of default include arrays that are stored in constants as frozen arrays.
For example:
class SomeSerializer
  include FastJsonapi::ObjectSerializer
  DEFAULT_INCLUDE = [:movies, :'movies.advertising_campaign'].freeze
end

---
class SomeController
  def show
    render json: SomeSerializer.new(
        organization_rfq,
        include: SomeSerializer::DEFAULT_INCLUDE
      ).serialized_json
  end
end

Prior to these change this was not passible as you would get a FrozenError: can't modify frozen Array exception when delete_if is called on options[:include].

whoops, closing this in favor of https://github.com/Netflix/fast_jsonapi/pull/366


Separated the WebMap javascript code to ease debugging

Also changed the name of the LOG_TAG to be consistent with other
components (ok, ok, that wasn’t essential :-) ). The map now centers
itself to the initial cord’s provided by the designer, but the code
isn’t doing it the correct way (the correct way is to load the js code
with the initial coord embedded it in [I think]). I’m just calling
setCenter in the mapisready() method. Enjoy. I’ll likely keep hacking
on this.
Change-Id: I2d583d564d4e5562606947753d951c9fe30c8e5c

@ajcolter I just added another commit. This commit arranges for GetMarkerLongitude and GetMarkerLatitude to return doubles instead of Longs, because well, they are floating point numbers, not integers.
At this point, can you create a project for me that demonstrates parsing failures so I can reproduce the problem you are running into. Thanks.


feat: Use pyhf contrib download to get pallet from HEPData

This PR adds pyhf's contrib extra as a requirement, and stipulates pyhf v0.5.3 or later to ensure this API exists. It does so to take advantage of this to easily get the entire pyhf pallet from the central location of the published analysis HEPData repo. This places both the background only workspace JSON and the signal patchset in a user defined directory
# Example
$ pyhf contrib download --verbose https://doi.org/10.17182/hepdata.90607.v3/r3 1Lbb-pallet
1Lbb-pallet/patchset.json
1Lbb-pallet/README.md
1Lbb-pallet/BkgOnly.json

and ensures all requirements are available at runtime for submission to FuncX.

@BenGalewsky This is ready for review.


License

Could you please add a licence for your work, (Maybe MIT), so its possible use is well defined.
Thank you.

I actually created one, and opened a pull request

I think MIT is the right one.
I've merged so I'm closing this issue. Thanks! 😃


move from beta to preview

Description
Change /beta to /preview following RHCLOUD-24353
Fixes # (THEEDGE3129)
Type of change
What is it?

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I run npm run lint:js:fix to check that my code is properly formatted

Codecov Report
Patch and project coverage have no change.

Comparison is base (155cb22) 29.82% compared to head (c53ceb9) 29.82%.

:exclamation: Current head c53ceb9 differs from pull request most recent head 4965238. Consider uploading reports for the commit 4965238 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #655   +/-   ##
=======================================
  Coverage   29.82%   29.82%
=======================================
  Files         127      127
  Lines        2860     2860
  Branches      885      885
=======================================
  Hits          853      853
  Misses       1836     1836
  Partials      171      171

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

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

@matoval @resoluteCoder ^^^


Getting a warning message ( in console ) on submitting the solution

Describe the Issue
There are some modules ( e.g: Create a Controlled Form module ) within the React section of the Front End Development Libraries course where, when the user submits their solution ( whether correct or incorrect ), then they end up with the following warning within the console:

act(...) is not supported in production builds of React, and might not behave as expected.

Since this warning is not relevant to the solution submitted by the user, I think it could make the user feel confused.
Affected Page
https://www.freecodecamp.org/learn/front-end-development-libraries/react/create-a-controlled-form
Expected behavior
In order to avoid any sort of ambiguity and to keep things as clear as possible, I believe when the user submits their solution and if their submitted solution is not correct ( partially or completely ), then they should only be getting relevant error messages printed onto the console which can help them in debugging their solution, or if their submitted solution is entirely correct, then they should be getting the following messages only ( within the console ):

// running tests
// tests completed

Screenshots

System

Device: Laptop
OS: macOS 13.0.1
Browser: Chrome
Version: 107.0.5304.110

I can see that the error message is pretty cryptic even though it happened somewhere along the stack trace.
If you don't mind, can you comment your JSX element  so that me and other people can paste the code immediately in the editor and see it for ourselves ?

Can you provide the path of this file.

If you want i can work on this issue. Can you assign this to me. I am expert in react but first timer in open source community. So apologize in advance if i am going out of way in asking this on the thread 🙏

Pretty sure that has been there forever. It looks to be caused by running tests with the production builds of React. Maybe we can just use the dev builds.
https://github.com/freeCodeCamp/freeCodeCamp/blob/main/curriculum/challenges/_meta/react/meta.json
https://github.com/freeCodeCamp/freeCodeCamp/blob/main/curriculum/challenges/_meta/react-and-redux/meta.json

<EMAIL_ADDRESS><EMAIL_ADDRESS>
Tested it briefly and it didn't seem to break anything, but I'm not sure what the reason for using the production builds is.
Or maybe the error message can be silenced somehow.

https://github.com/vercel/next.js/discussions/35676

I'm pretty sure I have seen this error on other React (maybe React/Redux) challenges as well.
I'm not sure if it is just because the prod build is smaller/faster or what?
I see no real harm in using the dev build and it would/should make the error go away. But someone from the dev team will have to look at this and approve it.
@naomi-lgbt is using the dev build of React an option here?

I'm not entirely sure, tbh. Maybe something @ojeytonwilliams can provide insight on.

So, the problem is that we currently bundle react-dom-test-utils into the script that runs the tests, so changing the meta doesn't help us.
However, once https://github.com/freeCodeCamp/freeCodeCamp/pull/49281/ is in, we will have full control over the scripts that we import and can choose which build we want for the react lessons.
I propose we revisit this issue once that's in main and experiment with development builds then.

I am interested to work on this issue. can anyone explain me more clearly what to do next?

Can I work on this?


Renamed psc-ide to psc-ide-client

In order to be more consistent I renamed the psc-ide exectuable into psc-ide-client. This will take effect with the purescript-0.8.1 release.

Thanks for the info. As of the current release the plugin is connecting directly to the server but opened https://github.com/nwolverson/vscode-ide-purescript/issues/2 as code plugin is not (and it's not configurable I think...)

ahh great! That's even better!