Compatibility with navigation

The new navigation as stated in issue #9 and issue #7 is not in consistency with those at http://beta.brlcad.org/wiki/Main_Page . In this pull request I have incorporated the navigation from http://ishwerdas.com/brlcad/ .
The result of merging this pull request can be seen at http://ishwerdas.com/black/

On my machine, at least, the menus still look different between the mediawiki and the landing page, is that intended?

The only difference that's intended is the new logo and the lack of icons. I will use an icon font (instead of the current approach of using images) in next request so that will be settled. If there's any other difference give me a screenshot, and I will check. Thanks for taking a look.

Hmm, interesting.  I see a few other differences here as well: the font is different (sans serif vs. serif, and slightly bigger), and the community/blog items on the wiki are news/support on the main page.  Can you reproduce those, or do you need screenshots?

I think I know what's happening but I would still need screenshots.

Inderpreetsingh: okay, see the attached files.

Yeah that's what I thought. So this is a problem with mediawiki theme which is not picking the Open Sans font on some computers. I was of opinion that I fixed it, but may be the mediawiki theme here is not pulled to the latest from original repo or the issue is still there. Whatever the case is, I will check.
So, the serif in mediawiki needs to change to sans-serif (Open Sans/ Lato). This is how I see mediawiki on my machine.

Ah, okay, that makes sense.  In that case, this looks good to me, except for the community/blog vs. news/support difference in the actual items.

Okay, I am merging this to keep moving forward. If there are any issues, we can easily revert as I haven't completely thrown away the code for previous navigation.

Coming late to the discussion, but I think this needs a bit more work.  I like how the menu persists during scrolling, but I find the initial landing page impression less appealing now than the previous rendition.  There's a stylistic imbalance and de-emphasis of the menu due to the decreased menu and font sizing.
What I think we need is to blend both concepts.  I suggest we start with a large menu and have that dynamically reduce to a thinner overlay menu on scroll.
This allows the initial logo impression to remain balanced in proportion to the 'BRL-CAD' title text and overlapping with the dynamic canvas, which I think is important to retain.
A minor issue on Mac platform, the menu fonts are now distinctly different (undesirably so) from the rest of the page which uses a thicker sans serif.

I liked the idea of scroll then fix navigation menu. The de-emphasis on the menu was intended keeping in mind the fitts law, and also so that there are fewer elements demanding attention above the cover. Also, It brings call-of-action (Learn More button below blurbs) inside cover, which IMHO was necessary. Though the appeal is subjective, I understand the visual imbalance it's creating.
Will work on creating a scroll-then-fix menu which is larger at first. Will also suggest gauravjeet to change it's vertical rhythm, he has already made font-sizes smaller in PR #13 to provide a balance.

Regarding fonts, the fonts are very inconsistently defined across the CSS file.
Somewhere it's  SegoeUI, Open Sans, Roboto, Sans-serif, Arial
and then somewhere it would be like Intro, SegoeUI, Open Sans, Arial, Sans-serif
And none of the fonts are actually loaded into the website. So we are on the mercy of user installing these fonts on their desktop for a consistent view. I think we should link a font like Open Sans, and keep it primary font. So the font definition everywhere would be
"Open Sans", Intro, SegoeUI, Arial, Sans-serif

@brlcad Can you please also post a screenshot here for me to understand the font issue better, thanks! :)


EgorBot for EgorBo in #9

Processing https://github.com/EgorBot/runtime-utils/issues/9#issuecomment-2323757019 command:

-arm64
using BenchmarkDotNet.Attributes;
using System.Collections.Generic;

public sealed class SealedClass {}

public class Bench
{
    SealedClass _bench = new();
    List<SealedClass> _list = new() { null };

    [Benchmark]
    public void Test() => _list[0] = _bench;
}

(EgorBot will reply in this issue)

Benchmark results on Arm64
BenchmarkDotNet v0.14.0, Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Unknown processor
DefaultJob : .NET 9.0.0 (<IP_ADDRESS>507), Arm64 RyuJIT AdvSIMD
StdDev=0.0057 ns

Method
Mean
Error

Test
5.378 ns
0.0061 ns

BDN_Artifacts.zip

Build log
cc @EgorBo


Tags query encoding is wrong

The newest version changes the way tags are encoded. It used to encode the individual tags and concatenate them with + symbols. Now it's encoding the entire string of tags including the + symbols.
E.g. it used to be like this:
https://gelbooru.com/index.php?page=dapi&s=post&q=index&json=1&tags=izumi_konata+-rating%3Aexplicit+-rating%3Aquestionable
and it now turned into:
https://gelbooru.com/index.php?page=dapi&s=post&q=index&json=1&tags=izumi_konata%2B-rating%253Aexplicit%2B-rating%253Aquestionable
This breaks at least the gelbooru api, didn't test for other sites.

Yup, broke that in 2.6.0, fixed in 2.6.1


AD Integration errors

Rancher versions:
rancher/server: v2.0.0-beta2
rancher/agent: NA
Infrastructure Stack versions:
healthcheck:
ipsec:
network-services: canal
scheduler:
kubernetes (if applicable): RKE v1.9.5-rancher1
Docker version: (docker version,docker info preferred)
Containers: 18
Running: 17
Paused: 0
Stopped: 1
Images: 22
Server Version: 17.03.2-ce
Storage Driver: devicemapper
Pool Name: docker-thinpool
Pool Blocksize: 524.3 kB
Base Device Size: 10.74 GB
Backing Filesystem: xfs
Data file:
Metadata file:
Data Space Used: 6.247 GB
Data Space Total: 51 GB
Data Space Available: 44.75 GB
Metadata Space Used: 1.729 MB
Metadata Space Total: 532.7 MB
Metadata Space Available: 530.9 MB
Thin Pool Minimum Free Space: 5.1 GB
Udev Sync Supported: true
Deferred Removal Enabled: true
Deferred Deletion Enabled: true
Deferred Deleted Device Count: 0
Library Version: 1.02.140-RHEL7 (2017-05-03)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 3.10.0-693.5.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.639 GiB
Name: iec-co-etcd01.ph.esl-asia.com
ID: UIGK:X6ZY:WCHG:5AVK:F3Y2:FP2J:BBXT:KQSU:EDWK:SHMU:4WQJ:LDHP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
<IP_ADDRESS>/8
Live Restore Enabled: false
Operating system and kernel: (cat /etc/os-release, uname -r preferred)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
3.10.0-693.5.2.el7.x86_64
Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO)
VMWare
Setup details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single node Rancher server, internal DB
Environment Template: (Cattle/Kubernetes/Swarm/Mesos)
Rancher Beta2: Kubernetes
Steps to Reproduce:
New instance of Rancher v2.0.0-beta2 started. Provide identical data for the AD integration, i.e.

Group Search Base is not reflected after changes are saved
Users that can be added as member to a cluster in v1.6.14 cannot be added in v2.0.0-beta2. The username shows up when starting to type in the Site Access user box but give an error:
Principal not found: Internal Server Error.
Exactly the same works in v1.6.14

Results:

Group search base is not reflected although AD groups can be added to Site Access
Users that can be added in v1.6.14 cannot be added in v2.0.0-beta2

i noticed that we are swallowing an error
https://github.com/rancher/rancher/blob/master/pkg/auth/providers/providers.go#L67
can you make it so that we unswallow that error?
Im not sure that you are going to be able to fix this part of the problem

Users that can be added as member to a cluster in v1.6.14 cannot be added in v2.0.0-beta2. The username shows up when starting to type in the Site Access user box but give an error:
Principal not found: Internal Server Error.

Because we dont have enough information, but unswallowing that error might give us more details for future cases. Also, we might get "not found" errors. Such errors should not necessarily ALWAYS be logged.
Whats happening is that if we cant find a user in AD, we fallback to seeing if they exist as a local user. BUT, when we do that fallback logic, we lose the original error and just return a "not found" error that k8s gives us. So, i think what you need to do is:

do the firest look up
if err, lookup using the local provodier
if err from local, return a new custom error that has the id that is being looked up and the error message from BOTH providers

(But also see if you can actually repro their problem. I doubt you will be able to)
And you can fix the group base thing. That should be independent of the reported error

@EricVS can you identify anything different about the users that dont work vs ones that do (if any do)?
we dont have enough information to reproduce

@cjellick : sorry for the late reply, I'm swamped at work and haven't had any time to address the questions in the thread. I'll do my best to get it in before Friday.
With regards to the users, those are exactly the same as which work in the stable version of Rancher, even using the same AD Controller for authentication.
Kind regards,
Eric V.

@EricVS but do you have some users that work in 2.0 and some that do not?
If so, can you identify any differences in them from an AD perspective?
If not, then does that mean that none of AD in 2.0 works for you?

I cannot reproduce the group search base issue. If I enter one, it is properly saved and reflected in the UI.

@EricVS the users that didnt work, were they in a different domain from the default one you configured. I see you configured it as ESL-ASIA

@EricVS we put a fix into our AD integration for another user. I believe it may have been the same as your issue for users not working. If you have an opportunity, could you spin up rancher/rancher:v2.0.0-rc1 to see if it resolves that issue:
WARNING: that image has not been fully QAd. It should only be used for testing this issue, not for actual fullblown use.

Hi Denise,
Sorry for the delay in trying and replying but it's been hectic. We're
planning to get up and running with v2.0.0 in two weeks due to other more
pressing matters. I'll update you and this thread once that's done. Thank
you for your patience.
Kind regards,
Eric v.
On Thu, May 10, 2018 at 1:24 AM Denise<EMAIL_ADDRESS>wrote:

@EricVS https://github.com/EricVS If you have time to try out v2.0.0 to
see if you still have issues, please let us know. For now, I'll keep this
ticket open and move it out until we hear back from you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rancher/rancher/issues/12622#issuecomment-387813276,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQgPzBxmRhRKNE48zmUs15uKXanjIJ9ks5twyZggaJpZM4TPa59
.

--
Kind regards,
Eric V.

I cannot reproduce and we have fixed a ton of bugs in the auth provider integration. I am going to move this over for testing

note that no explicit code change has been made for this and that it is currently assigned to v2.0.7, so there is not an immediate need to rush to verify this

Master 7/17/18
Updated Group Search Base, validated value took under v3/authconfig.
Confirmed ability to search for groups/users on cluster and site access level.
Validated users are able to login.


Fix: Handle empty lines and errors gracefully during insert

Hello.
Not sure if you accept MRs. This proposes a fix to handle empty lines when calling surround-insert.
Thanks for the package.
Description
This factors out determining the bounds to new helper function surround--infer-bounds during surround-insert.
The new function handles a third case: When the line is empty, insert the pair at point.
The new function has an optional parameter that signals an error when the bounds couldn't be inferred. surround-insert sets this to t to avoid potentially passing nil to goto-char which itself signals an error that's not easy to reason about (number-or-marker-p).

Thanks for the patch - I appreciate it.  I think the reason I hadn't noticed this is I have electric-pair turned on, so entering a paren on a blank line enters the closing one automatically.  I would only think to use surround for surrounding existing text.
I really need to study how to use Emacs unit tests...

It has been merged and the version bumped to 1.0.3, so it should be ready on MELPA sometime soon.

When it comes to testing, you could have a look at my (crummy) projects like partial-recall that use cask and my (equally crummy) Emacs Makefile helper.


Error while Building Caffe2

While building caffe2, I am getting some weird errors. It might has to do some thing about the ffmpeg version. Can someone please specify the ffmpeg version required. I am stuck on this for a week now. Would be highly obliged.
/pytorch/caffe2/video/video_decoder.h:76:3: error: ‘AVPixelFormat’ does not name a type
AVPixelFormat pixelFormat_ = AVPixelFormat::AV_PIX_FMT_RGB24;

For anyone having such error, it was fixed using a version of ffmpeg 2.


add possiblity to not reload service when change conf

Introduce service_manage to not reload wildfly service when conf has changed.

Coverage remained the same at 74.385% when pulling a658b817366fa43cb64da156882d1cbc24058f68 on bc-bjoern:service into acba51c2c707141874fcde7c0a6954bc65a76861 on biemond:master.

Thanks


Dropdown with wrapSelection={false} - "too much recursion" error

Got an error "too much recursion" in Dropdown with wrapSelection={false} when the first/last item is disabled and I move in that direction

Please complete the full issue report.  I've tested this on the latest version and it is working.
https://react.semantic-ui.com/modules/dropdown#dropdown-example-wrap-selection-false
import React from 'react'
import { Dropdown } from 'semantic-ui-react'

const options = [
  { key: 1, text: 'One', value: 1 },
  { key: 2, text: 'Two', value: 2 },
  { key: 3, text: 'Three', value: 3 },
  { key: 4, text: 'Four', value: 4, disabled: true },
]

const DropdownExampleWrapSelectionFalse = () => (
  <Dropdown search selection wrapSelection options={options} placeholder='Choose an option' />
)

export default DropdownExampleWrapSelectionFalse

Did you move to the last item in your example?
I got this error in FF dev console, other browsers can react differently.
I think that this part of code in moveSelectionBy method is incorrect:
// if 'wrapSelection' is set to false and selection is after last or before first, it just does not change
if (!wrapSelection && (nextIndex > lastIndex || nextIndex < 0)) {
  nextIndex = startIndex
} else if (nextIndex > lastIndex) nextIndex = 0
else if (nextIndex < 0) nextIndex = lastIndex

if (options[nextIndex].disabled) {
  this.moveSelectionBy(offset, nextIndex)
  return
}

After the first loop it's got stuck when nextIndex = startIndex which is disabled

Chrome says Uncaught RangeError: Maximum call stack size exceeded


lars cookbook

This needs integration testing data

@karlnapf  this looks ok ?

Looks good to me.
What we need is

squash commits
send a data PR with integration testing data (before merging this one)
once that is merged, also update the data submodule hash in here so that integration tests are executed

Yes, I have linked the data pr. https://github.com/shogun-toolbox/shogun-data/pull/122

I just merged it, so only squash and data update

Hey @Saurabh7 would you mind squashing these? Then we can merge

Yep, squashed and rebased.

Another candidate for  #3580


Search as well as Replace fail under special circumstances

When searching for, say ⎕Ed  in ⎕SE Fire crashes when a demo script is running.
This might be caused partly due to the fact that the demo script is fixing part of itself or/and because it is assigning functions and global variables on the same line separated by a ⋄.
Replacing ⋄ by NL in Fire.RemoveFnsAndOpr avoided the crash but the body, after masking all text, still contained a dfn when it shouldn't.
An attempt to break it down was tested with the new test functions Test_Replace_004 and Test_Replace_005 but both test cases pass. No more time at the moment to investigate further but there must be at least additional condition before the bug shows.
Also, avoiding the crash did net help when a "Replace" let to a WS FULL later on due to an endless loop.

See #17: same problem but way simpler


Python 2.x compatibility fixes.

@jcellary: Look at this changes  - they should fix the issues in Python 2.x.

LGTM


Write ATS for TG requirement 54

The CRS request parameter states what Layer CRS applies to the BBOX request parameter. Values must be CRS that are defined in the INSPIRE Annex I, theme 1, Coordinate Reference System.

This requirement is not fully covered by the WMS ATS, because only the CRSes defined in the INSPIRE Annex I, theme 1, Coordinate Reference System are allowed.


Allow events in read only TextArea

Fix default filtering strategy to correctly allow events for text area elements when is set to read only.
Note the comment above says that the event will be ignored when the text area is no read only.

Pull Request Test Coverage Report for Build 195

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 81.406%

Totals

Change from base Build 193:
0.0%

Covered Lines:
193

Relevant Lines:
207

💛  - Coveralls

Codecov Report

Merging #119 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #119   +/-   ##
=======================================
  Coverage   93.23%   93.23%
=======================================
  Files           1        1
  Lines         207      207
=======================================
  Hits          193      193
  Misses         14       14

Continue to review full report at Codecov.

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


All binaries in release tarball are Mach-O 64-bit x86_64 executable

Although their postfix suggests Linux, FreeBSD and Solaris binaries.
~/Downloads/prometheus-zfs/bin: file *
prometheus-zfs-darwin:  Mach-O 64-bit executable x86_64
prometheus-zfs-freebsd: Mach-O 64-bit executable x86_64
prometheus-zfs-linux:   Mach-O 64-bit executable x86_64
prometheus-zfs-solaris: Mach-O 64-bit executable x86_64

Thanks for the report. It's fixed in v0.1.1
https://github.com/eripa/prometheus-zfs/releases/tag/v0.1.1
But please note the WIP state of this project. v0.1.0 and v0.1.1 is not recommended to use in production.


feat: report telemetry when sandbox login button pressed

Fix replaces url for a button + command to add telemetry tracking when button pressed
Signed-off-by: Denis Golovin<EMAIL_ADDRESS>

@benoitf Shouldn't we have engine compatibility check somewhere here probably? Then if extension requires newer engine version it should not be offered for update or it should indicate update is available, but not compatible with current podman desktop.

@dgolovin until now it was not a priority until now but yes if we want to have newer versions not rolling out to old versions of Podman Desktop it would be a new enhancement.
but engine requirement should require probably to be first exposed at https://registry.podman-desktop.io/api/extensions.json
and I suppose in several other places when we grab "first version" from the list of versions.
coming back to the root problem of this PR
maybe we could check that if we have both href and command, command is used in the markdown implementation
so if we keep both href and command, old versions of Podman Desktop will call the href, and newer versions will call the command (and then telemetry will be reported)

@benoitf brilliant! it works, but I had to put href in double quotes to avoid parsing issued. Tested on v1.3.1 branch and main.


[FEA]: Show warning when pipeline_max_batch_size < model_max_batch_size

Is this a new feature, an improvement, or a change to existing functionality?
Improvement
How would you describe the priority of this feature request
Medium
Please provide a clear description of problem this feature solves
When running a pipeline with pipeline_max_batch_size < model_max_batch_size, its not clear to the user that inference requests will be clamped to the minimum values. So the inference batch size effectively is min(pipeline_max_batch_size, model_max_batch_size) which can subtly reduce performance if the user is not aware of the differences between the two options.
Describe your ideal solution
In this scenario, we should generate a warning stating that the value of model_max_batch_size will be reduced to pipeline_max_batch_size. This would at least help indicate what batch size the inference is truly running at.
Describe any alternatives you have considered
The model_max_batch_size could potentially be remove and automatically determined. Will file a secondary bug to address that issue.
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I have searched the open feature requests and have found no duplicates for this feature request

It sounds like the value's we're considering are:
Config.pipeline_batch_size
Config.model_max_batch_size

These are currently values, not properties.
There are a couple of ways to address this issue:

Change pipeline_batch_size and model_max_batch_size to properties and run some validation each time either value is set, issuing a warning when pipeline_batch_size < model_max_batch_size.

Refactor Config so all values must be constructor-injected, and all settings are read-only properties. Validation will only need to be run in the constructor, instead of each time a property is set.

The quickest/easiest thing to do is the first option, but if the validation logic gets more complicated in the future, running validation in each setter could get messy.
To avoid a breaking change, I'm going to go with the first option, but encapsulate the validation logic in a private _validate method which can be called from both setters so we do not need to maintain multiple paths for config validation.


Parallelize memory annotations

The current script in ./gematria/datasets/convert_bhive_to_exegesis_inputs.cc runs sequentially. This is somewhat of a problem for using the Exegesis annotator, which isn't particularly fast. This can easily be parallelized as we don't care about the timings at all while running the annotations. This should be doable with some refactoring and use of LLVM's threading APIs.

Not planning on doing this within the process itself as doing it out of process with ray seems to work much better.


Remove deprecated functions

Description
Fixes #82 by removing the deprecated functions.
Type of change
Please delete options that are not relevant.

[x] Breaking change (fix or feature that would cause existing functionality
to not work as expected)

How Has This Been Tested?
Ran local unit tests.
Test Configuration:

Operating system: OS X Ventura
Version number: Python 3.10
Any details about your local setup that are relevant: gcc 14.2.0

Checklist:

[x] Make sure you are merging into the develop (not main) branch
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] Add a note to Changelog.rst, summarising the changes
[x] Add yourself to AUTHORS.rst and .zenodo.json

Pull Request Test Coverage Report for Build<PHONE_NUMBER>8
Details

0 of 0   changed or added relevant lines in 0 files are covered.
8 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.3%) to 93.73%

Files with Coverage Reduction
New Missed Lines
%

tests/test_struct_aacgmv2.py
3
97.62%

init.py
5
86.84%

Totals

Change from base Build<PHONE_NUMBER>8:
-0.3%

Covered Lines:
1095

Relevant Lines:
1165

💛  - Coveralls


Official way to modify page metadata/title/etc.

As briefly discussed here: https://github.com/vuejs/vue-hackernews-2.0/issues/78#issuecomment-264642351
After a quick check I have found there are at least 3 separate 3rd party libraries attempting to tackle this problem. None of them are particularly complete. The only one that handles server-side rendering is https://github.com/declandewet/vue-meta, and it is still quite buggy. The maintainer has told me that he doesn't have time at the moment to work on it due to working on his real project.
Adjusting page metadata is something that every serious site needs. It is as important as server-side rendering, and goes hand-in-hand with it.
There should probably be an official way to handle it, just like there is an official routing library, which is beautifully integrated into Vue and will always be kept up-to-date.

Manually solved this issue by returning third argument as component.$data from "renderToString" function.. now I have all Component data in my server data variable:
bundleRenderer.renderToString((err, html, data) => { ... });
I hope in future update we will see this decision.

Meta information for SEO purposes doesn't need to be dynamically updated if at all.
This is due to services mechanisms to query your website, for a page URL they will index by the initial synchronous request. That means that even if you update via JS, search engines will most likely not index this way probably won't ever as this is indeterministic.
The best way to optimize for SEO purposes is to statically generate your content for consumption by web crawlers. Or manipulate the head with the correct meta content, at server level. This is fairly simple to achieve by injecting the content into the head of the served document.
The only real exception for user experience is to dynamically update the title of the document. Other than that there is no true benefit of updating the title dynamically.
There are exceptions such as AddThis which will require manipulation via there client API to ensure that on using the client functionality that the content is set as preferred.
Plugins that manipulate the while 'head' of the document are generally fairly expensive for there purpose. There is probably no reason you should be updating the head completely to regenerate the meta data client side.
That said, it is certainly on our agenda, to provide some more information for best practices when it comes to this common scenarios. We are planning to form a cookbook to provide this sort of information.
Perhaps asking in the Vue forum may be of aid, as there may be others that could provide there opinions in this subject.

My best advice if you are concerned with providing meta content to the head would be:
(Assuming you are using state management and you are able to provide to the context of the server renderer)

Add place holders to the html document template like {{ SEO_DESCRIPTION }}
Create a store for SEO, updating with correct data
When serving the head of document ect, replace the placeholders with correct data.

If using any client base tools, you can use the store data and update the title as necessary.
If you have any more questions or concerns let me know.

Considering mine is an SPA, and Vue's main use case is probably SPAs, I do think it is important to reactively update the title for a better user experience.
As you put it, it sounds fairly straightforward, so we can also assume that it wouldn't take much to integrate such a capability into Vue itself, then?

For user experience, in a SPA it's as simple as updating the title on a route change.
However, it's not deterministic when it may be needed to update. For example some use cases could dictate opening a model window is enough to change the title.
This is simple JavaScript, inevitably creating an abstraction in Vue to just change the documents title is too much. As said if using as a SPA, which now days is becoming and  considered an anti-pattern, then your only real focus on meta data is the title for the UI experience. Which is simple to do and even a plugin would not cater for many use cases, and will essentially be a wrapper to change the document title.
The real problem with dynamic meta information, falls to the server level. At server level many tools can be used, many template engines and many other variants. Thus, suggestions and advice to a simple solution is best IMHO.
If Vue dictates a setup or we officially stamp approval on a plugin, it will prevent choice of tooling out of scope of Vue. Thus these are problem domains that are subject to what tools you use, which Vue should avoid creating friction with.

My current project has a modal, and yes, the title and other metadata (og image, etc.) need to change depending on what the modal is showing. It doesn't matter that it's just a modal, and Vue shouldn't care that it's just a modal. It's declared as a child in vue-router just like any other child. I should be able to just include the required metadata changes in the component declaratively, kinda how vue-meta works. As you said, changing something like the og image is obviously important to be handled by the server, but Vue doesn't offer a clear way of going about that.
As for saying SPA is an anti-pattern, well that's just going with the current winds of JavaScript trends, which change every few months. As Evan pointed out in a recent tweet: "People like different things, you know. I wish more programmers understood that too." And in many projects, an SPA makes the most sense.

On the client, what depends on the OG image meta data?
If a SPA it's very unlikely that search engines / Facebook ect will pick up the correct meta information if you are dynamically updating. As this update will be asyncronous, clever search engines will attempt to but if you are relying on requested data after page has loaded then this will not be picked up.
Could you explain you use case in more detail? So I can understand how a tool like vue-head / vue-meta makes sense to your application.

Yes, that's why I said:

changing something like the og image is obviously important to be handled by the server

That is only important for when something like Facebook gets this information from the page. It doesn't matter on the client.
The title and theme are two examples of metadata that does matter on the client.
This is why it is important that handling of metadata is correct both on the client and on the server.
Projects like vue-meta matter because they prevent many devs "reinventing the wheel" of having declarative updating of page metadata, which is handled in a consistent way both on the client and with server-side rendering.
For example, if you have a list of items and when a user clicks on one you want a page with more details to open, you want it to open instantly since you already have the data (SPA is awesome) or very quickly because you just need to grab a couple of small bits of data (SPA still awesome). But, you also want this data page to be directly-accessible. In a SSR app the user would get this page pre-rendered with all the correct page metadata, which should be the same as if the user got there instantly from clicking a list item. In that case, the page should also have the correct metadata applied.
That is just one example.

It doesn't make sense to me that Vue has an excellent way of keeping the URL in sync with these navigational changes but does not have a sensible way to keep metadata in sync along with it.

@blake-newman How can I tell what page the user is on in order to display the right data? Could you give a more in-depth response on how to do this? Thanks!

Ok. I don't have any experience with SSR.
But since it is 2017 I update my page titles and descriptions on SPA misused websites
on the client and regarding the only search engine with relevance in my region it is working quite ok.
I have Single File Components with the following code:
created: function() {
  document.title = 'New Title'
  document.head.querySelector('meta[name=description]').content = 'New Description'
}

Hi guys, I join this conversation cause I been burning my brains out trying to figure out how to do this.
I'm making a news site that fetches data from the wordpress api (we're using wordpress for the client to upload the news).
So naturally I made dynamic routes with the name of the news post in it like so: www.mywebsite.com/news/a-news-title
So the problem is, one of the requirements is that users should be able to copy and paste that link on facebook and get the right preview (the news post image, title and short description).
So first I tried my hands at the vue-meta plugin, which does work, I can see the meta tags updating when I inspect the page BUT when I paste the link on facebook I don't get the preview for the news post.
After a lot of googling my guess is that the facebook crawler does not wait for my site to run the javascript code and update the metadata before reading the og:tags and that's why the right information is not showing. Am I Right?
Is the only solution to my problem to use SSR to render these news posts? or is there another way?
I have zero experience with ssr.

@leocirculo You can either use SSR or pre-rendering. Since you are using wordpress, pre-rendering may be the best way to go. https://www.npmjs.com/package/prerender-spa-plugin

A userland solution is now documented in https://ssr.vuejs.org/en/head.html
Alternatively there are community solutions and Nuxt also handles this for you.

@cw789 https://github.com/vuejs/vue/issues/4379#issuecomment-289716688
Based on this solution, is there a simplier way to set multiple meta tags from some sort of loop?

@ruchern I don't understand what goal you want to reach.

The ability to change the title seems to me the basic and thus fundamental feature.
I have a site developed with PHP and now I am doing a kind of practice to re-write it with React (Done) and Vue so that I can assess how convenient it would be.
My site is a book collection site, so to change the title of my dynamic page (site.com/books/12345.html) to reflect the book title this page is on is quite useful. I also need to update the description and keywords section to include the title, author, publisher, tags, etc.
Just a piece of my thought.

Changing title and meta is really important for professional websites, can't live without it. Vue team should take this as high priority and make this happen. How could this simple feature made unavailable to Vue? unbelievable.

Based on https://ssr.vuejs.org/en/head.html i create a function reusable, like the documentation expose i create mixin to handle a head, for now title and metas...
I have some questions about that, but i want to know what's your opinion about my code....

I create a new mixin with the name head.js... this looks like this:

const cleanMetas = () => {
  return new Promise ((resolve, reject)=>{
    const items = document.head.querySelectorAll('meta')
    for(const i in items) {
      if(typeof items[i]==='object' && ['viewport'].findIndex(val=>val===items[i].name)!=0 && items[i].name!=='')
        document.head.removeChild(items[i])
    }
    resolve()
  })
}

const createMeta = (vm, name, ...attr) => {
  const meta = document.createElement('meta')
  meta.setAttribute(name[0], name[1])
  for(const i in attr){
    const at = attr[i]
    for(const k in at) {
      meta.setAttribute(at[k][0], getString(vm, at[k][1]))
    }
  }
  document.head.appendChild(meta);
}

const getString = (vm, content) => {
  return typeof content === 'function'
    ? content.call(vm)
    : content
}

export const getMeta = (vm, meta, env) => {
  if(typeof meta !== 'object')
    return

  if(env){
    return Object.keys(meta)
    .map(value => {
      return Object.keys(meta[value])
        .map(key => `${key}="${getString(vm, meta[value][key])}"`)
        .join(" ");
    })
    .map(value => `  <meta ${value} >`)
    .join("\n");

  } else {
    return meta
  }
}

const serverHeadMixin = {
  created () {
    const { head } = this.$options
    if(head){
      const { title } = head
      if(title){
        this.$ssrContext.title = `${getString(this, title)} :: Vue SSR`
      }

      const { meta } = head
      if(meta)
        this.$ssrContext.meta = `\n${getMeta(this, meta, true)}`
    }
  }
}

const clientHeadMixin = {
  mounted () {
    const vm = this

    const { head } = this.$options
    if(head){
      const { title } = head
      if(title){
        document.title = `${getString(this, title)} :: Vue SSR`
      }

      cleanMetas().then(()=>{
        const { meta } = head
        if(meta){
          for(const nm in meta) {
            const name = Object.entries(meta[nm])[0]
            const attr = Object.entries(meta[nm]).splice(1,Object.entries(meta[nm]).length)
            createMeta(vm, name, attr)
          }
        }
      })
    }
  }
}

export default process.env.VUE_ENV === 'server'
  ? serverHeadMixin
  : clientHeadMixin

And add to src/app.js

...
import headMixin from './util/head'

Vue.mixin(headMixin)
...

Set up my components like this:

<script>
  export default {
    head: {
      title() {return `${this.name}  con `} ,
      meta: [
        { name: 'description', content() { return `El perfil de ${this.name}`} },
        { name: 'keywords', content() { return `${this.name} ${this.lastname} ${this.email}` } },
        { name:"twitter:card", content:"summary"},
        { name:"twitter:site", content:"@jqEmprendedorVE"},
        { name:"twitter:creator", content:"@jqEmprendedorVE"},
        { name:"twitter:url", content:"https://vue-firebase-ssr.firebaseapp.com"},
        { name:"twitter:title", content() {return `${this.name} creando Vuejs SSR + Firebase`}},
        { name:"twitter:description", content:"Modelo de Vuejs SSR con Firebase Cloud Function + Hosting"},
        { name:"twitter:image", content:"https://www.filepicker.io/api/file/nS7a8itSTcaAsyct6rVp"}
      ]
    },
    asyncData ({ store, route }) {
      // return the Promise from the action
      return store.dispatch('fetchItem', 1)
    },
    computed: {
      // display the item from store state.
      item () {
        return this.$store.state.items[1]
      },
      name () {
        return this.$store.state.items[1].nombre
      },
      lastname () {
        return this.$store.state.items[1].apellido
      },
      email () {
        return this.$store.state.items[1].correo
      }
    },
    data() {
      return {
        data: ':: SSR'
      }
    },
    created() {
      this.$firebase.db().ref('data').once('value', snapshot=>{
        // console.log(snapshot.val())
      })
    }
  }
</script>

Finally my template look like this:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>{{ title }}</title>{{{ meta!=='' ? meta : '' }}}
  <meta name="viewport" content="width=device-width, initial-scale=1, minimal-ui">
</head>
<body>
  <!--vue-ssr-outlet-->
</body>
</html>

I don't know if that is a good practices, but is my first intent in manage the head tag...
My first question. Is really necessary show de meta in the client? what is the benefys. Anyway, like a in the title, in my code i recreate metas for the client, like as updated the title... what's your opinion about that
DEMO
Repo

I used vue-headful, all the tags are coming correctly. but when i use google crawl tool to fetch the url, it shows nothing.
Any other suggestions?

@siddhartharora02 Downvoting my post first and then ask for help seems rather impolite to me. Why should I even invest my time to help you when all I get in return is a downvote?
Anyway, vue-headful sets the title with JavaScript. Google and other search engines do support running scripts when indexing your page (with some caveats). By "google crawl tool", do you mean "Fetch as Google" which is part of the Google Search Console? If yes, which button did you click: "Fetch" or "Fetch and Render"?
You might want to have a look at the help article about "Use Fetch as Google for websites":

Fetch: Fetches a specified URL in your site and displays the HTTP response. Does not request or run any associated resources (such as images or scripts) on the page. [...]
Fetch and render: Fetches a specified URL in your site, displays the HTTP response and also renders the page according to a specified platform (desktop or smartphone). This operation requests and runs all resources on the page (such as images and scripts). [...]

Ok. I don't have any experience with SSR.
But since it is 2017 I update my page titles and descriptions on SPA misused websites
on the client and regarding the only search engine with relevance in my region it is working quite ok.
I have Single File Components with the following code:
created: function() {
  document.title = 'New Title'
  document.head.querySelector('meta[name=description]').content = 'New Description'
}

Great work, thanks.

I am surprised there's so much discussion whether the ability of changing meta tags or title is an important feature.
I am managing a large application. Content marketing, SEO, sharing on social media is important marketing tool. It's no question to me, whether it's a needed feature or not.
I went through available plugins. There's always something missing. I am using vue-server-render to serve complete application. It's already working fine, I took the example from vue-hackernews-2.0 template
What I would like to do now, is to change the meta tags, directly from component. Here's why.
Every route has a coresponding page, most of them are dynamic pages, for example product/:slug. When a page mounts, I am fetching corresponding data from API, in this example the product informaiton. From the same endpoint I would like to serve meta-data. Which means one api call per page. Other solutions propose to fetch data on server level. That would mean that I have to modify the componenets, to use this data. Or to make two API calls (and have additional API endpoints). It seems overly complicated to me, while the setup already is insanly complex.
For the proposed solution to work, I would have to change the meta tags from component level.

@jqEmprendedorVE I've tried your solution, but the meta ends up in the body as Object [object]
I've tried to use vue-server-render, which exposes this.$ssrContext, except it doesn't expose it in my case, I am not sure why and how to fix it
I've tried @nuxt/vue-meta, which is not working, not to mention the entire @nuxt package has completely different architecture, to "simplify" things, which in my case would be much additional  work fixing nuxt bugs or developing workarounds (things just don't work there as they are supposed to)

Does anyone have a solution to modify the  tags from component level?

Ok. I don't have any experience with SSR.
But since it is 2017 I update my page titles and descriptions on SPA misused websites
on the client and regarding the only search engine with relevance in my region it is working quite ok.
I have Single File Components with the following code:
created: function() {
  document.title = 'New Title'
  document.head.querySelector('meta[name=description]').content = 'New Description'
}

Great work, thanks.

This won't work through SSR, as document, or head is not defined. It would break SSR actually, unless you move the code to mounted event.


Add JSDoc comments for better IDE support

JSDoc comments can be added to most methods to clarify not only their purpose and usage, but also their parameter's expected types. Since this project is not written in TypeScript, IDEs could use these comments instead in order to provide useful code completion etc.
Please direct any PR towards the refactor-everything branch and only work on lib/netflix2.class.js as this is soon going to replace lib/netflix2.js.

I can do this one

#28 is a great start for this issue, but there are still a few methods without JSDoc comments, so I'll leave this issue open for now.


Is it possible to use secret from other namespace for SecretStore.spec.provider.gitlab.auth.SecretRef

I'm not sure if it is bug feature request or request for clarification so not following description template.
The use case I have

Multiple projects
Each project has it's own group on gitlab and own team
Each project has namespace on k8s
Gitlab variables of the project group to be consumed with external secrets gitlab provider for consumption in project namespace
No project may use secrets of another project

Ideally I'd like to have SecretStore pointed to project gitlab group vars in each project namespace
But it looks  like I need to create gitlab access token for each project group and secret with it in each project namespace to be referenced by SecretStore.
It looks redundant, having a single gitlab token with access to all projects and secret for it stored out of project namespaces looks quite straighforward solution but unlike ClusterSecretStore , namespace scoped SecretStore ignores namespace field in SecretRef
Am I missing something and there is a reasoning behind such restriction or it is just smth that is not impelmented yet?

Yes.
// A reference to a specific 'key' within a Secret resource,
// In some instances, `key` is a required field.
type SecretKeySelector struct {
	// The name of the Secret resource being referred to.
	Name string `json:"name,omitempty"`
	// Namespace of the resource being referred to. Ignored if referent is not cluster-scoped. cluster-scoped defaults
	// to the namespace of the referent.
	// +optional
	Namespace *string `json:"namespace,omitempty"`
	// The key of the entry in the Secret resource's `data` field to be used. Some instances of this field may be
	// defaulted, in others it may be required.
	// +optional
	Key string `json:"key,omitempty"`
}```

I c.
Looks like the only option I have is using instance of ClusterSecretStore per project with   conditions[0].namespaces=[]
Not all project specific resources (secret store) reside in project namespace in this case, but not that critical

I'm not sure I understand. What I just showed you is the auth thing. So you just add the namespace and that's it? 😁 I'm probably misunderstanding something.

Yep but  namespace comments has  " Ignored if referent is not cluster-scoped.". So in SecretStore only secret from same namespace may be referenced

Ah okay, sorry. I didn't notice that.


feat: :merge() function

Follow up of #64

I'd feel this might be a bit too magical and less intuitive?

I'd feel this might be a bit too magical and less intuitive?

I agree. Lets hold this until we get more resource about use cases.


Wrong output when using with<EMAIL_ADDRESS>and ES6

The bindings I have written
[@genType]
type captureMode = [ | `mount | `continous | `update | `none];

[@genType]
type imageFormat = [ | `jpg | `png | `webm];

[@genType]
type result = [ | `tmpfile | `base64 |<EMAIL_ADDRESS>"data-uri"] `dataUri];

[@genType]
type options = {
  format: imageFormat,
  quality: float,
  result,
};

<EMAIL_ADDRESS>"react-native-view-shot"]
<EMAIL_ADDRESS>"./ViewShot.gen"]
<EMAIL_ADDRESS>external make:
  (
    ~captureMode: captureMode=?,
    ~options: options=?,
    ~onCapture: string => unit=?,
    ~onCaptureFail: unit => unit=?,
    ~ref: 'a=?,
    ~children: React.element
  ) =>
  React.element =
  "";

let make = make;

But then .gen the output is
/* Untyped file generated by genType. */

import {make as makeNotChecked} from 'react-native-view-shot';

const $$toJS239279797 = {"758966995": "tmpfile", "-718799473": "base64", "299516770": "data-uri"};

const $$toJS297684740 = {"207950297": "mount", "-571016554": "continous", "117802505": "update", "-922086728": "none"};

const $$toJS742076014 = {"5296353": "jpg", "5594281": "png", "-822780583": "webm"};

// In case of type error, check the type of 'make' in 'ViewShot.re' and 'react-native-view-shot'.
export const makeTypeChecked = makeNotChecked;

// Export 'make' early to allow circular import from the '.bs.js' file.
export const make = function react_native_view_shot(Arg1) {
  const result = makeTypeChecked({captureMode:(Arg1.captureMode == null ? Arg1.captureMode : $$toJS297684740[Arg1.captureMode]), options:(Arg1.options == null ? Arg1.options : {format:$$toJS742076014[Arg1.options[0]], quality:Arg1.options[1], result:$$toJS239279797[Arg1.options[2]]}), onCapture:Arg1.onCapture, onCaptureFail:Arg1.onCaptureFail, ref:Arg1.ref, children:Arg1.children});
  return result
};

Which makes the code fail in runtime. What I believe was expected
import makeNotChecked from 'react-native-view-shot';

I'm using genType 2.30.0, BS 5.0.4 and ReasonReact 0.7.0

@fakenickels looks like the intent here is to import the default export of 'react-native-view-shot', while the current code imports make from that module.
Would you try with:
<EMAIL_ADDRESS>("react-native-view-shot", "default")]
<EMAIL_ADDRESS>"./ViewShot.gen"]
<EMAIL_ADDRESS>external make:
...

There's some doc here, but perhaps it can be clearer (lmk of any suggestions):
https://github.com/cristianoc/genType#export-and-import-values

@cristianoc I tried also with that but the output was
import {default as makeNotChecked} from 'react-native-view-shot';

which is still invalid

Actually that should have worked and it just did, sorry it must have been something else messing up with my code imports 😅


Export main plugin class and update all imports ? = require(?) to named exports

this PR allows the types exposed by this plugin to be effectively used inside a .ts file.
the imports can be as:
import { ForkTsCheckerWebpackPlugin } from 'fork-ts-checker-webpack-plugin'
import ForkTsCheckerWebpackPlugin from 'fork-ts-checker-webpack-plugin'
import * as ForkTsCheckerWebpackPlugin from 'fork-ts-checker-webpack-plugin'

currently only this variants are allowed:
const  ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')
import ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')

this PR also updates all commonjs style imports to named imports/export and closes #162

Thanks for the work! Looks good. With this change do the existing imports still work? i.e.
const  ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')
import ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')

If not then this would need to be a breaking changes release.
Could you also update the CHANGELOG / version number in the package.json please?

its is a breaking change... the output of that object would be:
const  ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')
import ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')

console.log(ForkTsCheckerWebpackPlugin)

{
  default: [Function ForkTsCheckerWebpackPlugin]
  ForkTsCheckerWebpackPlugin: [Function ForkTsCheckerWebpackPlugin]
}

so the import should be like this in this case:
const  ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin').ForkTsCheckerWebpackPlugin
import ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin').ForkTsCheckerWebpackPlugin

or

const { ForkTsCheckerWebpackPlugin } = require('fork-ts-checker-webpack-plugin')
import { ForkTsCheckerWebpackPlugin } = require('fork-ts-checker-webpack-plugin')

similiar how it was done here: https://github.com/Realytics/fork-ts-checker-webpack-plugin/pull/163/commits/d48440f7e9af0e04f39bacd12d47261f5ba11f6d#diff-f41e9d04a45c83f3b6f6e630f10117feL16

but hold on, i think there is a way to keep the exported object like this:
{
  [Function ForkTsCheckerWebpackPlugin]
  default: [Function ForkTsCheckerWebpackPlugin]
  ForkTsCheckerWebpackPlugin: [Function ForkTsCheckerWebpackPlugin]
}

so it wouldn't be a breaking change let me do some experiments here first..

Sure

So this commit is very noisy; could you undo the whitespace changes please? I can't make out what's actually changed here... https://github.com/Realytics/fork-ts-checker-webpack-plugin/commit/2106654b03b52da9dd63a23df996712bc0461190
Probably we should switch to using prettier for consistent formatting in future.
It's unclear to me whether consumption is still unchanged; I'd like users to be able to use this consumption ideally:
const  ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')
import ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')

It feels that ought to be possible. ts-loader manages it. Maybe this helps?
https://github.com/TypeStrong/ts-loader/blob/d28ba6f732346067535d25889b8d56c95961c4a6/src/index.ts#L505

@johnnyreilly sorry my IDE had that format before commit option on..... forgot to unckeck.. it is clean now...
and if i only export it like this:
export = ForkTsCheckerWebpackPlugin

it would be exactly the same as it was originally.... so i would still face the same problem importing it..
and what i meant about this being a breaking change or not... let says that the user has module: commonjs on his tsconfig.json, this wouldn't be a breaking change for them, however those with the option set to module: esnext or es2015 would break, because it would no longer be a commonjs import but ES one.. which has to be imported as any of these forms:
import { ForkTsCheckerWebpackPlugin } from 'fork-ts-checker-webpack-plugin'
import ForkTsCheckerWebpackPlugin from 'fork-ts-checker-webpack-plugin'
import * as ForkTsCheckerWebpackPlugin from 'fork-ts-checker-webpack-plugin'

and of course importing by require('fork-ts-checker-webpack-plugin') would still work the only difference is that doesnt return a function but an object like this:
{
  default: [Function ForkTsCheckerWebpackPlugin]
  ForkTsCheckerWebpackPlugin: [Function ForkTsCheckerWebpackPlugin]
}

so i think this change is a breaking change, but it would only affect a very low percentage of this plugin users... because their webpack.config would have to be written in .ts for them to feel any effect, which i believe everyone defaults to a .js file..

Hey @milewski
So for users writing vanilla js, they can still write  const  ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin') and they don't need to then .ForkTsCheckerWebpackPlugin to use the plugin? i.e. it's a default export still?

@johnnyreilly sorry for the confusion... i followed the example u sent (https://github.com/TypeStrong/ts-loader/blob/d28ba6f732346067535d25889b8d56c95961c4a6/src/index.ts#L505) and this seems to be a much better solution, by doing so i dont need to change the export method and it will work for .js and .ts with the exacly same signature
the last commit reverts the export back how it was originally and
for .js
console.log(require('fork-ts-checker-webpack-plugin'))
// { [Function: ForkTsCheckerWebpackPlugin] }

for .ts
console.log(require('fork-ts-checker-webpack-plugin'))
// { [Function: ForkTsCheckerWebpackPlugin] }

import * as ForkTsCheckerWebpackPlugin from 'fork-ts-checker-webpack-plugin'
console.log(ForkTsCheckerWebpackPlugin)
// { [Function: ForkTsCheckerWebpackPlugin] }

// Invalid imports for .ts
import ForkTsCheckerWebpackPlugin from 'fork-ts-checker-webpack-plugin'
import { ForkTsCheckerWebpackPlugin } from 'fork-ts-checker-webpack-plugin'

so this PR is not a breaking change for neither .ts users nor .js users

done 👍

Thanks! Shipping with https://github.com/Realytics/fork-ts-checker-webpack-plugin/releases/tag/v0.4.10


Remove jQuery Dependency

Issue
This package relies on jQuery ( https://github.com/splunk/splunk-sdk-javascript#client-side-code-example ).
jQuery is not widely used anymore and for simple things like making API calls the fetch API would be better.

👍🏻 agreed. Any thoughts from the splunk team on this. We have multiple projects facing issues with this dependency.

@amcdnl as of now we don't have any plans to migrate to fetch API. Please let us know if there is any specific need for using fetch API
@aaronlippold would you please share details of issues that are being faced in the projects because of the jQuery dependency.

jQuery issue

Our webapp until just recently used the splunk js sdk to interface with splunk instances
We are attempting to migrate the webapp to support Node v18 - there is much grief already posted on the internet about it being a difficult process due to node internals changing impacting several base libraries
We use webpack to transpile our code from typescript to javascript - during that transpilation process, it goes through and adds 'use strict' to everything including dependencies
In our branch where the migration work is being done, we are currently experiencing some runtime errors with anything using jQuery due to jQuery not being compatible with 'use strict'
The runtime error we get is as follows and was traced to a jQuery internal function: Uncaught TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
Removing jQuery as a dependency would help us with this issue.  For now, we've instead converted to calling the api directly via axios

Fork reason

For some reason, we were having issues with using this library in the browser due to process.env being overwritten in this library
Unfortunately, the dev who did the implementation for the functionality using this sdk is no longer with the company so I have no further details atm


Code Coverage for just unit tests?

Not really an issue, but is it possible to create a task that only runs the mock unit tests, and generates code coverage reports from that?
My current unit test tasks are testMockDebugUnitTest. Would like to get coverage on those tests. Is it possible with our plugin?

In its current form, JacocoEverywhere doesn't support that, but you can get what you want by forcing Gradle to exclude integration task from the execution graph:
./gradlew createMockDebugAndroidTestCoverageReport -x :app:connectedMockDebugAndroidTest
This way you ask Gradle to generate test report for both unit & integration tests (so JacocoEverywhere builds all the dependencies), but also with -x option you tell Gradle to exclude actual Integration test task. So what's gonna happen - is just a unit test portion will be executed. Kinda hacky, but should work

This works thank you!


Upgrade to dependecychecker 1.3.1

Hi
We have been using dependency checker for some time now and I just upgraded to 1.3.1 from a 1.1.1 version. I have a two questions that I am hoping you can help with.
cmdline arguments used:
/opt/app/dependencychecker/bin/dependency-check.sh --app auth --nexus http://mavenrepo.*********.net:8081/nexus/content/groups/releases-only --out /opt/app/auth/ASSE/dependencyreport --format ALL --scan /opt/app/auth

Should I remove the --nexus option in favor of the CentralAnalyzer as suggested in the documentation.
Will this increase build times?

What is the implication of the 404 from or nexus ? Any way I can determine whats causing this.

[INFO] Analysis Starting
[WARN] Expected 200 result from Nexus, got 404
[WARN] There was an issue getting Nexus status. Disabling analyzer.
[WARN] An error occurred with the .NET AssemblyAnalyzer;
this can be ignored unless you are scanning .NET DLLs. Please see the log for more details.
[ERROR] Exception occurred initializing Assembly Analyzer.
[INFO] Creating the CPE Index
[INFO] CPE Index Created (2019 ms)
[INFO] Analysis Complete (9588 ms)

The Central analyzer uses the Maven Central repo on the Internet to look up classes. If you have an internal Nexus repository, you can use either one - but if folks are bypassing the internal Nexus repository and getting stuff straight from Central, then the odds are better that it will be found on Central. It may increase build times slightly because it's going to the Internet instead of an internal server to get that information.
The 404 response is because when the Nexus analyzer starts, it attempts to hit the Nexus service to verify that it's indeed a Nexus server running the way it expects it to, but it's not (hence the 404). So as it stands right now, because you've configured Nexus, it disables the Central analyzer, but because the Nexus analyzer gets a 404 initially, it gets disabled as well. The correct URL for a Nexus service probably ends with /service/local - so if your internal Nexus repository is at http://some.host.com/nexus, the service URL is probably http://some.host.com/nexus/service/local
In short, here are the pros and cons of each:
Central:

GENERALLY more accurate as it's going to have more stuff than your internal repository
May be slower because it's going to the Internet
May be missing re-packaged open source libraries that are on your Nexus server
You may have to configure a proxy for the Central analyzer to work (if you're behind a proxy).

Nexus:

Will probably only have components that internal folks have requested through that
May be faster since it's internal
Probably will not require proxy configuration

Thank you for the update. Very much appreciated


REQUEST FOR FEATURE: Render PDF Files

Hi,
I wanted to ask if it would be possible to also render the pdfs tat can be rendered in Obsidian (with ![[test.pdf]]).
This probably could be achieved with a iframe or something else.
I  hope this is possible to implement, because there is literally no other plugin out there that can do this.
Regards

Thank you for your suggestion.
markdown
![[sample.pdf]]

rendered

infer width & height using pypdf

<iframe src="sample.pdf" width="700" height="940"> </iframe>

I would try on above sterategy.
But i'm a bit busy these days, so I think it will take up to 2 weeks.

Sorry for late reply. I tried this. But with my bad frontend knoledge, i was not able to make responsive and cool looking ui for embedded pdf. Also there should be some another libary like pypdf to get the width and height of the given pdf which is over the range of this plugin.
This plugin should provide simple regex based syntax transport, not dynamic resolution for some contnent.
If you requires the dynamic conversion like this, I suggest mkdocs-macro as a solution for it.
Somehow i would remain this issue as open.
Someone who can implement this feature without other dependencies and only with some extra css and html conversion,  please help with this issue

@jokulab !
I add requested feature in new release. It was quite late. Again, Sorry for late reply.
You can see https://ndy2.github.io/mkdocs-obsidian-support-plugin/features/pdf/ to see the usage with examples


Cypress/e2e: Fixed Webhook and Tutorial navigation test cases

Summary
Fixed Webhook and Tutorial navigation test cases
Screenshots

Release Note
NONE

/release-note-none


Backup all databases

How do I go about backing up all the databases on the server?

What would the files that are saved be called? date.all.tar.gz?  I guess the db.name setting wouldn't make much sense anymore.

Just asking again, was this ever implemented?

Has this been implemented in Backup v3?

See https://github.com/meskyanichi/backup/pull/266.

Excellent, hopefully that gets merged, thanks :)

Looks like this has been merged - https://github.com/meskyanichi/backup/pull/266#issuecomment-3855523
Thanks!

was this ever implemented for mongo?
Thanks


Hugging face

Hugging face for fastai. In addition, please add an example!
Works for Mac and Linux!

Done


CREM updates for CMIP6

This PR contains the following updates to the Cloud Regime Error Metric (CREM) diagnostic:

added support for CMIP6 models (sic/siconc)
regridding now done by preprocessor
added provenance output
netCDF output is now always written (user switch write_netcdf is now ignored)
updated Sphinx documentation

Codacy fails because the code contains a function that is too complex and has too many local variables. In the previous PR merging the first version of the CREM diagnostic into version2_development, it was agreed that this is fine. As the code has been simplified compared with the previous version, I consider that it is still fine to ignore these Codacy issues (now reduced to 2).

The proposed change has been implemented. Codacy issues are down to 2.

@mattiarighi The code looks good, but can you please test?


Nc account by id

Explain the changes

This PR removes references of account name from bucket json files.
The  bucket_owner field is removed from bucket schema.
Principal in bucket policy is account id instead of account name.
In order to find account id by account name, a new dir root_accounts was added with symlinks from account name to account json.

Issues: Fixed #xxx / Gap #xxx

A Change to account name doesn't require updating bucket json files.

Testing Instructions:

Same tests

[ ] Doc added/updated
[ ] Tests added

@alphaprinz
Will these bugs 8080 8167 get fixed by this PR ?
If so, please add them to the PR description, thanks

superseded by
#8326 #8289 #8279 #8280 #8312


Unresolvable QR code

Unresolvable QR code
import cv2, zxingcpp

img = cv2.imread('1.jpg')
barcodes = zxingcpp.read_barcodes(img)
for barcode in barcodes:
	print('Found barcode:'
		f'\n Text:    "{barcode.text}"'
		f'\n Format:   {barcode.format}'
		f'\n Content:  {barcode.content_type}'
		f'\n Position: {barcode.position}')
if len(barcodes) == 0:
	print("Could not find any barcode.")

QR code generation website
https://cli.im/text

The problem is the dark background, which makes it a anon-conforming QRCode. A valid QRCode symbol as to be surrounded by white pixels. If you crop the dark background away, it works just fine:


Correction for raw affiliation Histoire et Sources des Mondes antiques; Université Jean Moulin - Lyon 3

Correction needed for raw affiliation Histoire et Sources des Mondes antiques; Université Jean Moulin - Lyon 3
raw_affiliation_name: Histoire et Sources des Mondes antiques; Université Jean Moulin - Lyon 3
new_rors: 05b5c0584;01yx7av22
previous_rors: 05b5c0584;04yavcg77
works_examples: W4300716716;W4317658735
contact: 99e77549b36191015090ec09d83fcc67:c6fb94dc4d3eb5a166c6de2d14c5 @ ens-lyon.fr

This issue was accepted and ingested by the OpenAlex team on 2024-11-01. The new affiliations should be visible within the next 7 days.


Bookstore: connect to API

In this PR I :

Install axios.
Create getBookFromAPPi function.
Configure extra Reducers to manage lifecycle actions.
Fetch the books from Bookstore API when the component has rendered with useEffect.
Add postBookToAPI function.
Add removeBookFromAPI function

Thank you @FrederickMih  for your review.


bugfix: Windows WMI 探测未更改认证端口信息 (closed #805)

Codecov Report

Merging #806 (9dac8cf) into V2.2.16-rc (affdcbf) will decrease coverage by 0.00%.
The diff coverage is 50.00%.

@@              Coverage Diff               @@
##           V2.2.16-rc     #806      +/-   ##
==============================================
- Coverage       71.04%   71.03%   -0.01%
==============================================
  Files             294      294
  Lines           21596    21596
==============================================
- Hits            15343    15341       -2
- Misses           6253     6255       +2

Impacted Files
Coverage Δ

...nents/collections/agent_new/choose_access_point.py
95.12% <ø> (ø)

apps/backend/utils/wmi.py
36.36% <50.00%> (ø)

apps/backend/subscription/steps/plugin.py
47.48% <0.00%> (-0.56%)
:arrow_down:

...onents/collections/agent_new/check_agent_status.py
100.00% <0.00%> (+5.55%)
:arrow_up:

Continue to review full report at Codecov.

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


Remove version information from file names in releases

Background
Currently releases include the version in the file name:
https://github.com/palomachain/paloma/releases/download/v0.0.1-alphawasmd4/paloma_0.0.1-alphawasmd4_Linux_x86_64.tar.gz

I would like to download the latest release generically:
wget https://github.com/palomachain/paloma/releases/download/latest/paloma_linux_x86_64.tar.gz

Done when

[ ] A new release is cut with this scheme
[ ] Documentation is updated.

Closing as wont' fix fo rnow.


Docs: github pages

make github pages
get started on documentation

github pages deployed
documentation will be started in a separate issue


DPS memory re-write

Hello I have one question. How do I UNDO a re-written memory in process hacker?

Here for example I edited the memory of the process (DPS) by replacing the those memories with 0
So i wanted to ask how do I undo that action? Or does that action leave any traces in process hacker that I should know to find if someone did that?

how do I undo that action?

LmHex to open the file on disk and re-read the bytes for the offset:
https://github.com/WerWolv/ImHex
Alternatively since all those changes are not permanent, just reboot the machine.

Or does that action leave any traces in process hacker that I should know to find if someone did that?

The primary issue with undo is that it would require saving copies of every page for every character change which would very quickly use GB's of memory.