text:
Prevent unnecessary downloads of library packages - just update the json/lock files

I was investigating slow dependabot running on some Drupal projects and came across issue #2416
Several things became clear as the cause, specifically around Drupal projects. One was that dependabot is slowed down by downloading actual packages when it does not need to.
This PR targets that by introducing a replacement for the LibraryInstaller that does not download or install anything - it effectively acts like MetadataPackageInstaller that's virtual.
Overall it shaves a few seconds off some of my local runs but might be worthwhile just for the bandwidth reductions.

Referencing #2999

Referencing #2999

Looking forward to giving this a spin! Thanks so much for digging into this @driskell

Looking forward to giving this a spin! Thanks so much for digging into this @driskell

@jurre No worries - I had set it as a personal challenge to dig into what's happening!
It's most noticeable if I remember on the patching - so once it finds the update, and then applies to get the lock file - that stage is noticeably faster. However, it may still be slow for things like Drupal where we'd be waiting on if Composer think my patches are acceptable, in which case once Dependabot receives those updates to Composer it should fix the main issue.

@jurre No worries - I had set it as a personal challenge to dig into what's happening!
It's most noticeable if I remember on the patching - so once it finds the update, and then applies to get the lock file - that stage is noticeably faster. However, it may still be slow for things like Drupal where we'd be waiting on if Composer think my patches are acceptable, in which case once Dependabot receives those updates to Composer it should fix the main issue.

Composer v2 has a composer update --no-install feature, which allows to update the lock file without running the installation of new deps in the vendor folder. Configuring the code to run in this mode would be cleaner than replacing the LibraryInstaller IMO (and less code to maintain)

Composer v2 has a composer update --no-install feature, which allows to update the lock file without running the installation of new deps in the vendor folder. Configuring the code to run in this mode would be cleaner than replacing the LibraryInstaller IMO (and less code to maintain)

Composer v2 has a composer update --no-install feature, which allows to update the lock file without running the installation of new deps in the vendor folder. Configuring the code to run in this mode would be cleaner than replacing the LibraryInstaller IMO (and less code to maintain)

That's a good suggestion. I traced that setting back to setting $installer->setInstall(false), but I get a bunch of test failures when doing that. I don't have time to spend a lot of cycles on this right now, but if there's something else we'd need to configure that you know of I'd love to hear!

Composer v2 has a composer update --no-install feature, which allows to update the lock file without running the installation of new deps in the vendor folder. Configuring the code to run in this mode would be cleaner than replacing the LibraryInstaller IMO (and less code to maintain)

That's a good suggestion. I traced that setting back to setting $installer->setInstall(false), but I get a bunch of test failures when doing that. I don't have time to spend a lot of cycles on this right now, but if there's something else we'd need to configure that you know of I'd love to hear!

That's a good suggestion. I traced that setting back to setting $installer->setInstall(false), but I get a bunch of test failures when doing that. I don't have time to spend a lot of cycles on this right now, but if there's something else we'd need to configure that you know of I'd love to hear!

I don't think there is anything else needed to configure that. And without seeing which test failure you have, I cannot give you an idea about a solution (note that even when seeing them, I don't guarantee that I will have an idea, given that I don't know the dependabot codebase, only the composer one)

That's a good suggestion. I traced that setting back to setting $installer->setInstall(false), but I get a bunch of test failures when doing that. I don't have time to spend a lot of cycles on this right now, but if there's something else we'd need to configure that you know of I'd love to hear!

I don't think there is anything else needed to configure that. And without seeing which test failure you have, I cannot give you an idea about a solution (note that even when seeing them, I don't guarantee that I will have an idea, given that I don't know the dependabot codebase, only the composer one)

That's a good suggestion. I traced that setting back to setting $installer->setInstall(false), but I get a bunch of test failures when doing that. I don't have time to spend a lot of cycles on this right now, but if there's something else we'd need to configure that you know of I'd love to hear!

I don't think there is anything else needed to configure that. And without seeing which test failure you have, I cannot give you an idea about a solution (note that even when seeing them, I don't guarantee that I will have an idea, given that I don't know the dependabot codebase, only the composer one)

Nice, that would definitely mean this PR is not needed. I did wonder though when I did this one if installers need to be installed still and loaded in case they impact the output. Would setInstall stop those installer plugins from being installed and loaded?

That's a good suggestion. I traced that setting back to setting $installer->setInstall(false), but I get a bunch of test failures when doing that. I don't have time to spend a lot of cycles on this right now, but if there's something else we'd need to configure that you know of I'd love to hear!

I don't think there is anything else needed to configure that. And without seeing which test failure you have, I cannot give you an idea about a solution (note that even when seeing them, I don't guarantee that I will have an idea, given that I don't know the dependabot codebase, only the composer one)

Nice, that would definitely mean this PR is not needed. I did wonder though when I did this one if installers need to be installed still and loaded in case they impact the output. Would setInstall stop those installer plugins from being installed and loaded?

Custom installer can change the location of the the installed package on disk. But they cannot change the version being selected (and so cannot affect the lock file).
The only plugins that can affect the lock file are the ones which are hooking into the dependency solver itself (using the pre-pool-create event), like symfony/flex for instance. And for that to work during  a composer update, the plugin must be installed before running the update (so either as a global plugin, or by running a composer install first to have a vendor folder).

Custom installer can change the location of the the installed package on disk. But they cannot change the version being selected (and so cannot affect the lock file).
The only plugins that can affect the lock file are the ones which are hooking into the dependency solver itself (using the pre-pool-create event), like symfony/flex for instance. And for that to work during  a composer update, the plugin must be installed before running the update (so either as a global plugin, or by running a composer install first to have a vendor folder).

@jurre Was the approach you suggested merged as the PR is showing as closed?
I am now having issues in all my repositories where security updates are no longer appearing because dependabot simply can’t scan the repository in time anymore even though I’ve effectively set it to only check 3 packages. Investigating the logs from GitHub I can see it is literally downloading the ZIP for many packages each time and never gets to complete the second package... so for some reason something has made things a lot worse. I think it takes now 5 days or more to even get the updates for the 3 packages which isn’t sustainable.
I also worry how much CO2 this is burning unnecessarily it’s almost like mining bitcoins lol.
If there was an issue with the approach it be good to know as I’m keen to help get this working. The optimisation PRs at composer that are needed for extremely quick scans with little CO2 are stuck or might need some test attention (composer/composer#9620 composer/composer#9619 composer/composer#9261) but hopefully moving along as the maintainers find time but this issue here looks to me like a good win!

Was the approach you suggested merged as the PR is showing as closed

No, I closed it as I ran into a bunch of different test failures that I didn't really have time to investigate. The logs for those have since been garbage collected by Actions, so I've re-opened the PR temporarily to regenerate the CI failures, but I will close the PR again after that, as I'm trying to cut down pending PRs that I'm not actively working on to keep myself sane.
I'm surprised things have gotten that much worse, as nothing has really changed on our end 🤔
It would be great if we could leverage changes to composer like the PR you linked to instead of building something bespoke for Dependabot, but if we can get the config flag working that seems reasonable to me.

Trying to migrate from dependabot-preview to dependabot for a whole bunch of PHP projects, I noticed that updates currently fail for me with the message

Dependabot can't access your-org/your-repo
You can fix the issue by granting Dependabot access, which will enable any repository in @your-org to get automatic updates from your-org/your-repo. Be sure that you want to share your-org/your-repo with everyone in your organization.

I am using a private package registry, but that seems to work find and access is granted (I configured it accordingly). Now, to my knowledge, Composer obtains all the information it needs from the registries, so I wonder why the above error occurs.
Am I right assuming that if the change suggested here were made, it would no longer be necessary to configure the additional permissions in https://github.com/organizations/my-org/settings/security_analysis, under "Grant Dependabot access to private repositories"?

@mpdude that seems like a different issue, it appears that you're pulling in a git dependency and Dependabot cannot access it.
I don't think that these changes would affect access to private sources, Dependabot would still need to access them to find version info etc.
Could you open up a new issue for this and fill out the questions in the template? I'll be more than happy to help you sort it out 👍

@jurre Tried my very best over at #3628.

Is this PR still being considered? We are experiencing the issues described in https://github.com/dependabot/dependabot-core/issues/2416 & https://github.com/dependabot/dependabot-core/issues/2999, and while there are also some issues/PRs against Composer (https://github.com/composer/composer/pull/9261, https://github.com/composer/composer/pull/9620), I have not seen any recent traction on those. I know the sentiment seemed to be that if it could be fixed in Composer that would be ideal, but if this could be resolved here with little downside, I would be the first to cheer that on.

Was the approach you suggested merged as the PR is showing as closed

No, I closed it as I ran into a bunch of different test failures that I didn't really have time to investigate. The logs for those have since been garbage collected by Actions, so I've re-opened the PR temporarily to regenerate the CI failures, but I will close the PR again after that, as I'm trying to cut down pending PRs that I'm not actively working on to keep myself sane.
I'm surprised things have gotten that much worse, as nothing has really changed on our end 🤔
It would be great if we could leverage changes to composer like the PR you linked to instead of building something bespoke for Dependabot, but if we can get the config flag working that seems reasonable to me.

I just tested the setInstall locally to take a look. Using setInstall(false) disables installation completely - it won't even hit the InstallationManager. So the get_latest_resolvable_version request and likely others will never find the packages as it relies on the InstallationManager to return the list of installed packages. I can think also this won't install any installer packages that might impact the output file.

I fixed up the PHPCS for this and used NoopInstaller instead. I also tried to fix up tests but it warrants a bit of discussion - I've mostly repurposed tests for reporting nice errors into tests to ensure no error happens since those tests begin to fail because no attempt is made to download or install and so bad commits and references and variables aren't relevant.

Custom installer can change the location of the the installed package on disk. But they cannot change the version being selected (and so cannot affect the lock file).
The only plugins that can affect the lock file are the ones which are hooking into the dependency solver itself (using the pre-pool-create event), like symfony/flex for instance. And for that to work during a composer update, the plugin must be installed before running the update (so either as a global plugin, or by running a composer install first to have a vendor folder).

Sorry I just reread this and took a further look into setInstall() - and ended up just removing the entire custom installation manager (DependabotInstallationManager) - since it occurred to me it's not really the ideal way to get Composer's list of installed packages - we can instead get it from the lock data by using the locker to get the locked packages repository and get the packages there. That is not quite "what did we install just now" but it definitely is the "what is installed overall" and should be equal if not richer to what was currently being used (since it likely the installation manager was receiving an install operation for every package anyway in the dependabot case...)
Looks like all tests still pass!

@jurre @stof Found an issue when using setInstall(false) with https://github.com/wikimedia/composer-merge-plugin
That plugin adds additional install requirements based on merges of composer.json from other installed packages. Thus I don't think you can not allow it to be installed, and potentially even you cannot disallow installation of libraries as any one could provide a merge...
In my test runs on one repository I have (I can't share) then during updates dependabot would start to remove the additional requirements provided by the merge plugin....

I think just doing this in the UpdateChecker would be fine, as long as the Updater still installs. That would still give a speed benefit for where update not needed.
I accidentally force pushed now I can't reopen heh. Will raise separately once tested.

New PR #4635

authors: driskell jurre markdorison mpdude stof

repo: dependabot/dependabot-core


text:
Add an options argument to the bundler_version helper method that is passed from the public API down

In order to start testing bundler 2 support, we want to be able to optionally use it in Dependabot core by passing an options[:bundler_2_available] flag into the Fetcher, Parser and Updater APIs from the running environment.
This PR adds this configuration layer which currently results in the Bundler native helper using a stubbed V2 library which returns a NotImplemented error for the existing method signatures.
This error is this used as a testing proof that our top-level classes fail due to this error if we pass in the options to verify we have passed the configuration correctly. This is further verified by making options a required argument of the bundler_version helper method, ensuring we get an ArgumentError in any cases we've missed.

I think there's a few more, my plan was to take this PR right up to having a null adapter that just raises if the feature is on

I think there's a few more, my plan was to take this PR right up to having a null adapter that just raises if the feature is on

Ah yes that makes sense 👌

Looks like quite a few classes require options to be passed in

Aha, I made it a required argument and didn't update the unit tests 🤕  Should be a relatively quick fix.

The CI failures seem to be limited to the new tests that use the v2 native helper, but I'm not seeing them locally, I suspect the issue is the v2 helper just isn't set up properly for CI yet. I've committed DEBUG_HELPERS=true to verify this while I go through the dockerfile and ci workflow.

Yep, that was the issue, I forgot to add v2 to the Dockerfile and had some build script tweaks to make 😅

source: gharchive/pull-request

authors: brrygrdn feelepxyz

license: MIT

license_type: permissive

license_source: github-api


text:
Build Server uploading zip

Q
A

Issue Type
Question/Feature Request

Deployer Version
N/A

Local Machine OS
N/A

Remote Machine OS
N/A

Description
Is any way to upload by Build Server .zip with built project? Uploading 115k files to 15 app nodes sucks 😓

When I try to upload zip file, it is uploading but it corrupt the file on the production server.
task('upload', function () {
upload(DIR . "/.build/current.zip", '{{release_or_current_path}}');
});
@antonmedv @fnowacki
Can you please take a look on upload task if I am doing something wrong here?

source: gharchive/issue

authors: fnowacki lexjwa

repo: deployphp/deployer


text:
NPM install fails on DigitalOcean server

Deployer version: 6.8.0
Deployment OS: MacOS (locally) / Ubuntu 20.04 (remotely)

I followed this guide : https://lorisleiva.com/deploy-your-laravel-app-from-scratch/install-and-configure-deployer
This was my original deploy.php (edited for anonymity)
namespace Deployer;

require 'recipe/laravel.php';
require 'contrib/php-fpm.php';
require 'contrib/npm.php';

// Project name
set('application', 'fakeproject');

// Project repository
set('repository', 'https://github.com/revmitcz/fakeproject.git');
set('php_fpm_version', '8.0');

// [Optional] Allocate tty for git clone. Default value is false.
set('git_tty', true);

// Shared files/dirs between deploys
add('shared_files', []);
add('shared_dirs', []);

// Writable dirs by web server
add('writable_dirs', []);
set('allow_anonymous_stats', false);

// Hosts

host('prod')
    ->set('remote_user', 'root')
    ->set('hostname', 'fakeproject.app')
    ->set('deploy_path', '/var/www/{{hostname}}');

// Tasks

task('deploy', [
    'deploy:prepare',
    'deploy:vendors',
    'artisan:storage:link',
    'artisan:view:cache',
    'artisan:config:cache',
    'artisan:migrate',
    'npm:install',
    'npm:run:prod',
    'deploy:publish',
    'php-fpm:reload',
]);

task('npm:run:prod', function () {
    cd('{{release_path}}');
    run('npm run prod');
});

after('deploy:failed', 'deploy:unlock');

When I got to the dep deploy step, I had a number of issues - most of them I've worked out on my own, but now I'm absolutely stuck at this error message :
npm ERR! cipm can only install packages with an existing package-lock.json or npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or later to generate it, then try again.
I changed their deploy tasks, removing both npm:install and npm:run:prod and adding your recommended one of the line after('deploy:update_code', 'npm:install'); while also removing the added npm:run task they added.
No matter what I do, I still run into that NPM error. What is the correct solution to this issue?

Update : Looks like forcing composer to use deployer ^7.0 fixed the issue.
For anyone also following the guide linked above, here's how the PHP deploy file should end (provided you're using deploy 7+), which will also avoid warnings about avoiding reloading php-fpm :
task('deploy', [
    'deploy:prepare',
    'deploy:vendors',
    'artisan:storage:link',
    'artisan:view:cache',
    'artisan:config:cache',
    'artisan:migrate',
    'deploy:publish',
]);

after('deploy:update_code', 'npm:install');
after('deploy:failed', 'deploy:unlock');

I changed their deploy tasks, removing both npm:install and npm:run:prod and adding your recommended one of the line after('deploy:update_code', 'npm:install'); while also removing the added npm:run task they added.

I'm currently following the same guide and have been weighing up whether to compile on the server or before pushing. Can I ask what made you decide to remove these and add the specified line?

I'm currently following the same guide and have been weighing up whether to compile on the server or before pushing. Can I ask what made you decide to remove these and add the specified line?

Unfortunately, the simple answer is probably very unhelpful : I ran into issues, saw "oh also change this" and changed it.
I'm quite a newb in the world of even utilizing npm in the first place, so I don't have a great answer for what's the better solution. The site I was launching with this guide is like pre-alpha, just so I can show it properly to other team members without needing a separate service, and to test deployments to see if it'll hold up once the code is further along.
That said, so far, no issues. What I see locally on my system matches and functions exactly what I see on the live DO server after any deployment.

authors: Kaos-Industries revmitcz


text:
🛑 depositar-demo is down

In 31a82aa, depositar-demo (https://demo.depositar.io/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: depositar-demo is back up in 53860e3.

repo: depositar/status


text:
💄 [메인페이지] 피드백 버튼 위치 수정

💡 개요

피드백 버튼 위치 수정했습니다.
우측 여백 값을 기준으로 정하면 푸터와 정렬이 안 되는 거 같아서 푸터를 기준으로 수정했습니다.

피그마

우측 여백 값 기준 정렬

푸터 기준 정렬 (현재 적용 내용)

📑 작업 사항
🔎 기타

아 그르네영.. 작은 화면에서는 그래서 숨겨졌었네여. 수고하셨음당 👍 👍 👍

감사합니다 ~!! 🥺✨


text:
Wish list of outputs for a QSO VAC

This purpose of this ticket is to organize discussion on the desired contents of a QSO VAC, which would be constructed from a QSO catalog.
The desired contents are emission line and continuum measurements that could be useful for the LyA, GQC, and GQP WGs. For example, we should be able to improve quasar redshifts with information about BH mass and luminosity relative to Eddington. This in turn requires measurements of continuum luminosities, parametric and non-parametric line shape information, removal of FeII emission, and power-law fits to the continuum.
The parent QSO catalog would be the official QSO catalog produced by the LSS WG. Therefore this does not include low-luminosity AGN in galaxies whose continua include significant stellar emission. The rationale is they have quite secure redshifts from the stellar features, and they are usually sufficiently low redshift and luminosity that issues like Fe template subtraction do not apply.
Here are some quantities to start a discussion of the contents:

Key emission lines: CIV, MgII, Hbeta for BH measurement
Emission lines to add to emlines.ecsv: He II 1640.42, Al III 1857.40 to add to
Fit/subtract Fe emission blends (esp. from 2250-3000A around Mg II)
Fit PL continuum
Non-parametric quantities: first and second moment + FWHM of the "Key emission lines"
Continuum luminosities at 1450, 1700, 3000, 5100 Angstroms

Some references on Fe templates are:

Vestergaard & Wilkes (2001)
Tsuzuki et al. (2006)
Salviander et al. (2007)

For reference, here is a figure with a fit to the Fe emission around Mg II from a recent paper led by Zhefu Yu:

Caption: The four colored lines are a PL continuum and the three Fe templates referenced above. Also okay to ignore the single-epoch spectrum.

@paulmartini I'd like to make some progress on this ticket but I could use your help with the templates.
First, you've suggested three possible template sets, V01, T06, and S07, but if we had to select one, which one would you select? I can fit subsets of objects with all three (in separate calls to FastSpecFit), but I suggest we select a fiducial set (or derive our own from DESI observations themselves??).
Could you (or a student) put the templates into a simple FITS format that I can use (and put them somewhere I can access on NERSC)? For example, here are the current templates--
https://data.desi.lbl.gov/public/external/templates/fastspecfit/README.txt
https://data.desi.lbl.gov/public/external/templates/fastspecfit/1.0.0/
Second, can you provide more input regarding the power-law fitting you would like me to perform? I did play around with this previously and used a simple F_nu \propto \nu^(-alpha) or F_lambda \propto \lambda^(alpha-2) model, with alpha ranging between 0.5 and 2.0. Is this what you had in mind, too? For reference, this is the paper I've been looking at, but let me know if you have other favorites--
https://www.aanda.org/articles/aa/pdf/2017/08/aa30378-16.pdf
Finally, do you want me to try to fit the host-galaxy continuum, too, or can we safely ignore it?
I'm looking forward to hearing your thoughts.

Hi @moustakas --
Great that you plan to work on this soon!
I've made a fits file with four templates and placed them in a single fits file here:
/global/cfs/cdirs/desi/users/martini/qsospecfit/fetemplates.fits
The first (EXTNAME = DEFAULT) is the variant of the Vestergaard & Wilkes (2001) template we've used the most. The three other templates are another Vestergaard & Wilkes template and the two others mentioned above. The EXTNAMEs should be clear, and there is more information in a COMMENT in each extension. Let me know if you'd like these arranged differently.
I suggest just using the one I called 'DEFAULT.' Zhefu Yu has done experiments with the others and not found big differences. The big disadvantage of the Vestergaard & Wilkes template is that there is not empirical data at the location of MgII, and ignoring an FeII contribution at those wavelengths probably leads to an overestimate of the MgII line flux and FWHM. Yet for scaling relations this may not matter too much, given the calibration process.
The power-law fit you mention is a good match to observations of the ultraviolet continuum, namely alpha = 0.5 to 2.0 where F_nu \propto \nu^(-\alpha).
For quasars we can ignore the host-galaxy continuum. I think it is okay to ignore it.

@arjundey has recommended adding CII] 2326 to the line-list.

Some notes / papers for myself:

https://github.com/imcgreer/simqso/blob/master/examples/SimpleSpecExample.ipynb
https://github.com/MJTemple/qsogen
https://iopscience.iop.org/article/10.3847/0004-6256/151/6/155/pdf
https://arxiv.org/pdf/2109.04472.pdf

Whittle+85 (https://ui.adsabs.harvard.edu/abs/1985MNRAS.213...33W/abstract) recommend a few non-parametric line-profile measurements that may be useful.

Some additional AGN/QSO modeling refs (courtesy @bd-j!)--
Lyu+22 added semi-empirical AGN optical-FIR templates, and different SF dust emission templates - this is built off a very old prospector version, and I think uses a custom FSPS:
https://ui.adsabs.harvard.edu/abs/2022ApJ...941..191L/abstract
This adds a power law continuum with attenuation independent from the stars - I hope it will be added to prospector soon.
https://ui.adsabs.harvard.edu/abs/2024arXiv240302304W/abstract
https://ui.adsabs.harvard.edu/abs/2024arXiv240302304W/abstract
This uses Lyu+22 and also a version with just a scaled Polletta 2006 QSO template added on:
https://ui.adsabs.harvard.edu/abs/2024ApJ...968....4P/abstract
https://ui.adsabs.harvard.edu/abs/2024ApJ...963..128B/abstract
This adds a scaled empirical AGN emission line template from Richardson 2014 - this is actually in prospector as AGNSpecModel, but was really just used to explore the potential impact of AGN emission lines on photo-as
https://ui.adsabs.harvard.edu/abs/2022arXiv220802794N/abstract
There's been some other work about including emission lines more flexibly, including produced by AGN-like ionizing continuua, in
https://ui.adsabs.harvard.edu/abs/2024arXiv240504598L/abstract
https://ui.adsabs.harvard.edu/abs/2024ApJ...969L...5L/abstract

@paulmartini, @yzfkieran817 @wei-jian
Below is the VW01 template (originally provided by @paulmartini), resampled to constant-velocity pixels and then smoothed by a Gaussian kernel ranging in sigma between 150 and 10,000 km/s.
A couple questions:

I've resampled the template to have constant 75 km/s pixels (the original template has constant-lambda, not constant log-lambda). Is this reasonable?
Is the 150-10,000 km/s prior range reasonable?
In the original template there are several wavelength ranges which are identically zero, including around the MgII wavelength range. Do I need to reset these flux values to zero after smoothing by the velocity dispersion factor?

Hi @moustakas  --
Here are my answers (and @yzfkieran817's):

Yes, the resampling to 75 km/s pixels seems reasonable.
Yes, the prior range of 150-10,000 km/s looks reasonable.
No need to reset the values to zero in the wavelength ranges where they are zero in the template.

@paulmartini @yzfkieran817
Regarding this request:

Non-parametric quantities: first and second moment + FWHM of the "Key emission lines"

I have implemented something (currently in a branch) but would be grateful if you could check my math and code here and make sure it's what you want / need. In particular, there are a variety of
Specifically, I isolate the pixels in the continuum-subtracted (not yet iron-subtracted, but that's in the works) spectrum centered on each of the following four lines: CIV, MgII (mean wavelength of the doublet), Hbeta, and [OIII] 5007.
The central wavelength and width are taken to be the Gaussian-weighted center (based on my line-fitting) +/- 5-sigma, where "sigma" is again based on the Gaussian fit to the line.
Then, I simply (and non-parametrically) compute:
$M_{1} = \sum_i (W_{i} F_{i}) / \sum_i F_{i}$
$M_{2} = \sum_i (W_{i} - M_{1})^{2} F_{i} / \sum_i F_{i}$
$M_{3} = \sum_i (W_{i} - M_{1})^{3} F_{i} / \sum_i F_{i}$
where $W_i$ and $F_i$ are the wavelengths and fluxes, respectively, and $M_1$, $M_2$, and $M_3$ are the three moments in observed-frame Angstrom, Angstrom$^2$, and Angstrom$^3$, respectively.
There are many definitions of these moments, including the standardized (normalized) moments, which I'm not computing, but maybe this is what you want / prefer?
As a quick example, here's CIV on sv3/dark/25960/39627776256380593

Note that I would like to use these calculations to help identify / pre-select spectra with possible outflows, particularly using [OIII] 5007, so it would be great to use maximally useful definitions.
@stephjuneau @Ragadeepika-Pucha others...

This looks good to me, @moustakas.  Specifically, I think it is better to compute the moments as you've done, rather than the standardized/normalized versions, and it is better to report observed-frame quantities. These should be more straightforward to use for the primary science drivers of these additions, namely outflows and centroid shifts associated with these emission features. I also looked over the code and the implement matches what I expected. Thanks!

Hi @moustakas , @paulmartini  et al.
For [OIII]4959,5007, the most common method for non-parametric measurements that I see in the literature is using the cumulative flux velocities like this figure (from Speranza et al. 2024):

And here are other examples from the QSOFEED project from Bessiere et al. 2024:

I suspect that the reason Chiara is using these measurements in her work is that they're very commonly used so that would allow us to make direct comparisons with the literature. There are many more examples but just another selected highlight is this work by Davies et al. 2020 may be one of the most careful analyses of mass outflow rates for ionized outflows in AGN that I'm aware of. See their Section 3.2 for velocities, where they use v_peak (as the offset between the velocity of [OIII] peak and systemic velocity) to determine if [OIII] is mostly outflow or ISM and v98 (which as they define it is the max of |v02| and v98). Then their definition of v98 is used directly as "v_out" to compute the mass outflow rate and kinetic energy:

For funsies, this figure shows a range of expected profiles for [OIII] bicones depending on inclination i and on dust extinction:

This paper by Bae & Woo (2016) also has a lot of detailed predictions of line profiles from modeling the outflows in 3D, and here's a passage about bulk velocities for outflow properties and other references:

All that said, maybe Paul has read different papers that instead used quantities like you're proposing? Could you please post some examples as I'd be interested in taking a look! IMO, any of the quantities will be interesting but I'm definitely more familiar with the cumulative-flux velocities to infer physical outflow properties.

@stephjuneau thank you for these additional references and suggestions.
I'll let @paulmartini comment regarding the definitions he prefers, but I'm hopeful that the three moments currently coded up are adequate for at least pre-selecting objects / emission lines for more detailed analysis.

Hi @moustakas, @stephjuneau - My motivations were to identify lines centroids that did not match the systematic redshift, as we care about redshift errors for the LyA / QSO correlation analysis, and to identify objects with non-Gaussian line shapes, which might provide further information about the reliability of the redshift measurements. I suggested the three moments because they are conceptually simple and statistically robust. I think that they should suffice to identify targets for more detailed study for other science goals, such as the study of AGN winds. I suspect those will be a small minority of the total sample, although I defer to John on whether or not he wants to add more line measurements for every object.

authors: moustakas paulmartini stephjuneau

repo: desihub/fastspecfit


text:
"End job" function in order to create multiple jobs from the same python script

My use case is tracking every iteration of a hyperparameter optimization process. I've created a function that roughly looks like:
def model_score(hyperparameters):
    xtrain, ytrain, xtest, ytest = get_data()
    model = create_model(hyperparameters)
    model.fit(xtrain, ytrain)
    score = model.evaluate(xtest, ytest)
    return score

I am then passing this function to my favorite optimization algorithm (like skopt's gp_minimize, hyperopt's fmin and so on) but I also want to log the inputs and outputs in the process:
def model_score(hyperparameters):
    foundations.log_params(hyperparameters)
    xtrain, ytrain, xtest, ytest = get_data()
    model = create_model(hyperparameters)
    model.fit(xtrain, ytrain)
    score = model.evaluate(xtest, ytest)
    foundations.log_metric(score)
    return score

While this code doesn't raise any errors, it only logs the first parameter iteration as a "job" and assigns all the metric iterations to it. I'm wondering if it would be possible to have something like a foundations.end_job() function that I would call once I log my metrics so that the next time log_parameters is called, it creates a new job.

Hey @cbalaf , curious - can't you use the submit job method in the Python SDK to achieve this?
The SDK allows you to submit jobs programatically
https://docs.atlas.dessa.com/en/latest/sdk-reference/SDK/#job-submission

does the deployment object contain information about the job? If so, then yes, otherwise the issue is that I want the input to a subsequent job to depend on a previous one - which means that I would like to have output from a job returned to the program

It depends what information you need from the previous job.
If it's a metric from a previous job, can you try using .log_metric() on the upstream job, which should give access to that resulting metric using the deployment object

oh, that's great! I guess my question then becomes on whether the upstream job needs to be a in a separate script that needs to be invoked or whether it can be a function defined in the same script

The way we organize our code is usually having a main file like hyperparameter_serach.py that acts as the driver, and kicks off all jobs for the search.
Here's a tutorial that hopefully clarifies usage of foundations.submit via random walk logic: https://docs.atlas.dessa.com/en/latest/tutorials/auction_price_regression_tutorial/#random-walk-search
It uses get_metric along with some basic logic to randomly walk through a search space. Let me know if this helps!

hey @cbalaf , did the answer above help you get through the issue?

It helped seeing how I could do what I wanted within the current atlas logic. Didn't necessarily address the original reason why I opened this. In any case, this isn't a bug or a blocker, just my idea of an enhancement

authors: cbalaf mohammedri pippinlee shazraz

repo: dessa-oss/atlas


text:
speaker_embedding_dimension

Line 220 in model.py:
self.speaker_embedding_dim = hparams.encoder_embedding_dim

Should be
self.speaker_embedding_dim = hparams.speaker_embedding_dim

??

Yes, you're right @tshmak . I probably did that because I wanted to add/point-wise multiply the speaker embeddings to the the encoder output, rather than concatenate them.
But it shouldn't lead to a problem, as I don't think that attribute(self.speaker_embedding_dim) is being used elsewhere.
Do you want to open a pull request? Or shall I correct ?

Please correct, as my repository contains other modifications to your program also. Just to clarify, your program concats rather than add/multiply the speaker embedding right? (cf. here). Is it because you tried add/multiply and in the end decided to stick with concat?

@tshmak Yes, the program concats right now. It is because the papers says to concatenate. Although, I am yet to try multiplying/adding , but i lost server access, so couldn't do.


text:
🛑 OKTicket is down

In 10d4ee3, OKTicket (https://www.okticket.es) was down:

HTTP code: 0
Response time: 0 ms

Resolved: OKTicket is back up in 40a07bd.

repo: dev-okticket/status


text:
🛑 BBDD Mongo is down

In bb6d66c, BBDD Mongo (https://api.okticket.es/v2/public/api/monitor/mongodb) was down:

HTTP code: 0
Response time: 0 ms

Resolved: BBDD Mongo is back up in 2479df7 after 5 minutes.


text:
Automatically discover clusterName

Description
Try to discover clusterName based on current folder name. Consider validating the discovered name by looking for a corresponding YAML-file.
Example:

CWD=$(current work dir)
Check for file with name $CWD-k3d-config.yaml

I do not want to enforce ways of working, so do you have a suggestion of how I could handle if there are multiple KSail clusters initialized in the same folder?

I think a good default behavior is a good thing, and allow the user to override it. In this case:

If the user specifies a cluster name, user it.
If not, look for a config file (cluster) with the same name as the folder.

I do not understand the proposed solution - will the ksail native config file only contain exactly one clusterName or multiple. If you can, please elaborate on the ksail native config file, especially the example.

It will contain one cluster name.
See it as a per-project configuration. One project should not need more than one ksail project. In rare cases where there could be more than one ksail cluster in a folder, the configuration will use the cluster name to infer which one to provision when running:
ksail up

authors: devantler rvangsgaard

repo: devantler/ksail


text:
Added URL Encode Decode

Type of Pull Request

[ ] Bug fix
[x] Enhancement

Related Issue #s or links (if any):
Issue #7
Description of Changes
Added URL Encode Decode following similar UI as others.
Passed all the tests

Sure, I'll make those fix. This is my first nextjs typescript project so I had some trouble to get started and create test.

I hope all's good now :), if so, I am thinking of adding one more tool to this repo.

@TechSpiritSS Excellent, thank you!

@dlford Thanks :)

authors: TechSpiritSS dlford


text:
Unique key of component causes extra elements to appear

Hi,
I'm using preact-compat to implement a user survey. Each question has an associated "answer type" component that allows the user to enter an answer e.g. an input field, a range slider or some buttons.
If two questions follow each other that use the same answer component then the data from the last answer is not removed.
I've tried to use a unique key to force the replacement of the component but this causes two components to appear e.g. <AnswerInput key={uniqueQuestionId} />.
Here's a test case on Codepen. If you enter some text in the input and click increment, on every other click, I see 2 instances of the  component:

The same example using React doesn't pass the key through as props but entering text and clicking "Increment" clears the text box.
Is there a better approach to this?

@andrewn this might be related to developit/preact#73 - currently my top priority. I appreciate the minimal example, I will use it as I test out a solution.

Confirmed, this is a duplicate of developit/preact#73. Will close this issue once the upstream is fixed and that version has been propagated to preact-compat.

@andrewn Just released Preact 4.1.2 and preact-compat 1.6.1, which I can confirm fixes this issue. Thanks!
Your pen running on preact-compat 1.6.1: http://codepen.io/developit/pen/EKKEvP
(Also just a tip: wzrd.in/standalone/preact-compat already bundles preact itself, so there's no need to re-include it)

Thanks!

@developit I think I've found another issue. Using the same example running preact-compat 1.6.1 do the following:

Enter some text into the input field
Click "Increment", the text disappears as expected
Click "Increment" again, the text is back
Repeat and the text is gone again.

Shall I raise this as another bug?

This happens because you are not setting a value for the input. Preact (currently) does not modify any attributes it has not been told about.
So technically not a bug, but I think it's worth opening an issue on the Preact repo to start a discussion around whether the existing behavior is what we want. Certainly I can see a case for resetting input state at least.

The same example using React does clear the input so I guess I expected preact-compat to do the same.
I'll open an issue in preact as you suggest. :-)
Thanks for the quick reply!

Yup - React actually doesn't recycle DOM elements, so the second time the <input> is rendered (referenced) it's a fresh copy. Preact is a bit nuts about recycling (constant memory and all that).

authors: andrewn developit

repo: developit/preact-compat

license: mit

license_source: bigquery


text:
No need for @bind and ::this.method. We already have short function syntax.

I saw usage of @bind and ::this.method in some examples.
I think it's better to change this to
class A extends Component {
    // With this syntax it will be already bound to this context
    handleSmthn = () => {
        this.setState({});
    }

    render() {
        return
Clock me!
;
    }
}

It's much better and no need for additional tools.

True, I guess that avoids the external dependency. I like the @bind syntax for performance reasons (the bound method is more easily garbage collected), but for demos it is unnecessary.
Do you think the class property syntax for methods will be understandable for people? I guess we could add a note with a link to an explanation if need be.

Personally I find it more attractive and people should use it too. It's on stage-1 as far as I know.
What is your opinion about GC with this code transpiled? https://goo.gl/Dux8xW
If everything is ok with it - I think we should insist on using this syntax so we would teach newcomers more about es2015-2016
And propose linkState as not salvation from bind problem but as useful tool, which helps binding without addChangeListener etc or activating something via actions.

My GC comment was mostly about the transpiled code (creating a closure within the constructor) - I'm not knowledgable enough about the 2016 spec to know if the actual implementation in engines would be significantly different.  One one hand its nice because you use a single shared closure to scope the context for N arrow functions (ideal). On the other hand, while Function.prototype.bind() has worse runtime performance than creating a closure, it pushes the problem into the JS engine, which will always get faster over time.  Since .bind() internally creates functions that are not quite the same as regular JS functions (like a lightweight proxy), I've always pictured the internal implementation being something like a Weak Map (I may be wrong on this?), which is more easily garbage collected than a closure.
That said, since my reasons for liking @bind are mainly style and opinion, I don't want to force that on anyone. We can certainly start switching the examples over to use class property arrows in place of @bind().  Perhaps I'll even take to doing it in my own work ;)
As for linkState(), I'd like to reword some of the documentation to be more along those lines - it's a way to create event handlers declaratively, anything else is basically sugar.
Cheers

@idchlife I'm migrating this to developit/preact-www#7 since that's where the PRs will go.

authors: developit idchlife

repo: developit/preact


text:
lat lon validation feasible?

Hi all, great work on the models so far 🎉
I'm wondering if it would make sense to include validation for latitude & longitude for coordinates and bbox?
So to check if coordinate input is in the correct order (lon, lat as per geojson spec) for lat input >90 or <-90
Boundaries checks would be:
-180.0 <= lon <=180.0
-90.0 <=lat <= 90.0
Not sure how to do this.. Is it even possible to validate tuples that don't have a key?

The newest version of the geojson spec uses WGS84:

The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees.

Older versions of the spec allowed other coordinate systems:

Note: the use of alternative coordinate reference systems was specified in [GJ2008], but it has been removed from this version of the specification because the use of different coordinate reference systems -- especially in the manner specified in [GJ2008] -- has proven to have interoperability issues.

But the spec notes that if interoperability is not an issue, than alternative coordinate systems can be used:

However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.

My concern is that adding coordinate validation specific to a single coordinate system will be too restrictive, as the spec seems to indicate that it is possible to have a geojson object that is not WGS84.  In such a case we might raise validation errors on a "valid" object.  I'm interested in other people's opinions on how the models should be supporting specific coordinate systems if at all.

Hmm valid point, although i guess in most cases WGS84 will be used.
Maybe an option would be to validate WGS84 by default but make it possible to adjust it to other CRS.
Still not sure if it is even possible to implement the validation, as the Coordinates are not a BaseModel but a Tuple..
Anyway, for my use case i can still create Model inheriting from Polygon and do the validation there i guess

Anyway, for my use case i can still create Model inheriting from Polygon and do the validation there i guess

I think this is the best solution for now.

Still not sure if it is even possible to implement the validation, as the Coordinates are not a BaseModel but a Tuple..

A good approach is overriding the coordinates validator to also check each coordinate, for bbox you could do the same.  Pydantic also lets you define a custom root type which lets you validate each Coordinate:
from geojson_pydantic.geometries import Coordinate, Point as _Point
from pydantic import BaseModel, Field, root_validator

class WGS84Coordinate(BaseModel):
    __root__: Coordinate

    @root_validator(pre=True)
    def validate_coords(cls, values):
        if abs(values['__root__'][0]) > 180:
            raise ValueError("invalid longitude")
        if abs(values['__root__'][1]) > 90:
            raise ValueError("invalid latitude")
        return values

    def __iter__(self):
        return iter(self.__root__)

    def __getitem__(self, item):
        return self.__root__[item]

class Point(_Point):
    type: str = Field("Point", const=True)
    coordinates: WGS84Coordinate

pt = Point(coordinates=[-118,34])
assert pt.coordinates[0] == -118
assert pt.coordinates[1] == 34

# This will raise validation error (invalid longitude)
pt = Point(coordinates=[34,-118])

That's exactly what i need!
You make it look so easy. I was looking at the pydantic root type before, but was a bit deterred by the example as it looked rather complex.
Thank you for the structured example

Thanks @TheGreatRefrigerator @geospatial-jeff; I agree with leaving this out for now because other projections can technically be used. I think the example shown is a good way validate if needed

Hey thanks for this useful library! I have a question related with this kind of validation. Let's say I now want to have a FeatureCollection that validated each geometry according to your defined WGS84Coordinate. Do I need to define again each class ? Can't find a simple way to achieve it, while i thought that was the point of being a generic class.

@bensdm sadly it would be a bit verbose
from typing import List, Union
from pydantic import BaseModel, Field, root_validator

from geojson_pydantic import geometries, features

# Overide the Position Type (with a Pydantic Model)
class Position(BaseModel):

    __root__: geometries.Position

    @root_validator(pre=True)
    def validate_coords(cls, values):
        if abs(values['__root__'][0]) > 180:
            raise ValueError("invalid longitude")
        if abs(values['__root__'][1]) > 90:
            raise ValueError("invalid latitude")
        return values

    def __iter__(self):
        return iter(self.__root__)

    def __getitem__(self, item):
        return self.__root__[item]

# Create new Geometries Models
class Point(geometries.Point):
    """Point Model"""

    coordinates: Position

class MultiPoint(geometries.MultiPoint):
    """MultiPoint Model"""

    coordinates: List[Position]

class LineString(geometries.LineString):
    """LineString Model"""

    coordinates: List[Position] = Field(..., min_items=2)

class MultiLineString(geometries.MultiLineString):
    """MultiLineString Model"""

    coordinates: List[List[Position]]

class Polygon(geometries.Polygon):
    """Polygon Model"""

    coordinates: List[List[Position]]

class MultiPolygon(geometries.MultiPolygon):
    """MultiPolygon Model"""

    coordinates: List[List[List[Position]]]

# Geometry Type
Geometry = Union[
    Point,
    MultiPoint,
    LineString,
    MultiLineString,
    Polygon,
    MultiPolygon,
]

# Use Generics and set `features` to have geometries of type `Geometry` (with the constrained coordinates)
FeatureCollection = features.FeatureCollection[
    Geometry,
    features.Props,
]

authors: TheGreatRefrigerator bensdm drewbo geospatial-jeff vincentsarago

repo: developmentseed/geojson-pydantic


text:
Warning for RNGoogleSigninButton on RN 0.42.2 Android

Warning: Native component for "RNGoogleSigninButton" does not exist
What's wrong?

Was a problem with some other library I was using.

hi @eshwartm how did you solve the error if you remember?

@bodaz Yes so I was using react-native-navigation and due to that I had to import this package in a different place than what is mentioned here. Not sure how that helps you.

authors: bodaz eshwartm

repo: devfd/react-native-google-signin


text:
Stuck in link

When i run : react-native link react-native-google-signin
it say's
Scanning folders for symlinks in D:\OneDrive\Documenten\BIT\bitboard-mobile\node_modules (15ms)
rnpm-install info Linking react-native-google-signin android dependency
rnpm-install info Android module react-native-google-signin has been successfully linked
rnpm-install info iOS module react-native-google-signin is already linked

After that he will not continue https://i.imgur.com/gXHlCKr.png

Experiencing the same error in my project. Anyone able to fix this?

authors: Compulsor wsslfnstr


text:
Create new version for Go stack using golang 1.19

Which area/kind this issue is related to?
/area registry
Issue Description
As the go version 1.18 is currently EOL, we should update the go stack of the registry to use version 1.19. On the other hand, all versions using 1.18 should be marked as Deprecated by adding a tag in their metatada.tags field.
Acceptance Criteria

[x] Create 2 new versions for go stack -> 1.2.0 (to update the default stack version) and 2.2.0 (to update the stack versions having schemaVersion: 2.2.x)
[x] Add Deprecated tag to go stack versions 1.0.2, 1.1.0, 2.0.0, 2.1.0.
[x] Update the stacks/go/stack.yaml file and set 1.0.2 as the default version.
[x] Update the renovate.json file to skip directories stacks/go/1.0.2/, stacks/go/1.1.0/, stacks/go/2.0.0/, stacks/go/2.1.0/ because they will be deprecated
[x] Update the https://github.com/devfile-samples/devfile-sample-go-basic to use golang version 1.19 and have as a parent the new version of the go stack.

Created a sample PR (https://github.com/devfile-samples/devfile-sample-go-basic/pull/31) which will be merged right after the stack version deployment.

Re-opening as the sample PR is still under review :)

repo: devfile/api


text:
Could not load plugin descriptor for plugin directory [.DS_Store]

Problem description
MacOS using the latest version,  and analysis-ik plugin, start up fail.
Extra information
➜  docker-elk git:(master) ✗ tree
.
├── LICENSE
├── README.md
├── docker-compose.yml
├── docker-stack.yml
├── elasticsearch
│   ├── Dockerfile
│   ├── config
│   │   └── elasticsearch.yml
│   └── plugins
│       └── analysis-ik
│           ├── commons-codec-1.9.jar
│           ├── commons-logging-1.2.jar
│           ├── config
│           │   ├── IKAnalyzer.cfg.xml
│           │   ├── extra_main.dic
│           │   ├── extra_single_word.dic
│           │   ├── extra_single_word_full.dic
│           │   ├── extra_single_word_low_freq.dic
│           │   ├── extra_stopword.dic
│           │   ├── main.dic
│           │   ├── preposition.dic
│           │   ├── quantifier.dic
│           │   ├── stopword.dic
│           │   ├── suffix.dic
│           │   └── surname.dic
│           ├── elasticsearch-analysis-ik-7.6.0.jar
│           ├── httpclient-4.5.2.jar
│           ├── httpcore-4.4.4.jar
│           ├── plugin-descriptor.properties
│           └── plugin-security.policy
├── extensions
│   ├── README.md
│   ├── apm-server
│   │   ├── Dockerfile
│   │   ├── README.md
│   │   ├── apm-server-compose.yml
│   │   └── config
│   │       └── apm-server.yml
│   ├── app-search
│   │   ├── Dockerfile
│   │   ├── README.md
│   │   ├── app-search-compose.yml
│   │   └── config
│   │       └── app-search.yml
│   ├── curator
│   │   ├── Dockerfile
│   │   ├── README.md
│   │   ├── config
│   │   │   ├── curator.yml
│   │   │   └── delete_log_files_curator.yml
│   │   ├── curator-compose.yml
│   │   └── entrypoint.sh
│   └── logspout
│       ├── Dockerfile
│       ├── README.md
│       ├── build.sh
│       ├── logspout-compose.yml
│       └── modules.go
├── kibana
│   ├── Dockerfile
│   └── config
│       └── kibana.yml
└── logstash
    ├── Dockerfile
    ├── config
    │   └── logstash.yml
    └── pipeline
        └── logstash.conf

Stack configuration
add analysis-ik plugin command to elasticsearch Dockerfile.
  1 ARG ELK_VERSION
  2
  3 # https://www.docker.elastic.co/
  4 FROM docker.elastic.co/elasticsearch/elasticsearch:${ELK_VERSION}
  5
  6 # Add your elasticsearch plugins setup here
  7 # Example: RUN elasticsearch-plugin install analysis-icu
  8
  9 COPY plugins plugins

Docker setup
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:21:11 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:29:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

docker-compose version 1.25.4, build 8d51620a
docker-py version: 4.1.0
CPython version: 3.7.5
OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019

Docker logs

elasticsearch_1  | {"type": "server", "timestamp": "2020-04-20T12:33:25,339Z", "level": "ERROR", "component": "o.e.b.ElasticsearchUncaughtExceptionHandler", "cluster.name": "docker-elk", "node.name": "8ac6e9abc043", "message": "uncaught exception in thread [main]",
elasticsearch_1  | "stacktrace": ["org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Could not load plugin descriptor for plugin directory [.DS_Store]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:174) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:161) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:125) ~[elasticsearch-cli-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.cli.Command.main(Command.java:90) ~[elasticsearch-cli-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:126) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "Caused by: java.lang.IllegalStateException: Could not load plugin descriptor for plugin directory [.DS_Store]",
elasticsearch_1  | "at org.elasticsearch.plugins.PluginsService.readPluginBundle(PluginsService.java:401) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.plugins.PluginsService.findBundles(PluginsService.java:386) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.plugins.PluginsService.getPluginBundles(PluginsService.java:379) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.plugins.PluginsService.<init>(PluginsService.java:151) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.node.Node.<init>(Node.java:313) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.node.Node.<init>(Node.java:257) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:221) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:221) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:349) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:170) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "... 6 more",
elasticsearch_1  | "Caused by: java.nio.file.FileSystemException: /usr/share/elasticsearch/plugins/.DS_Store/plugin-descriptor.properties: Not a directory",
elasticsearch_1  | "at sun.nio.fs.UnixException.translateToIOException(UnixException.java:100) ~[?:?]",
elasticsearch_1  | "at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]",
elasticsearch_1  | "at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ~[?:?]",
elasticsearch_1  | "at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219) ~[?:?]",
elasticsearch_1  | "at java.nio.file.Files.newByteChannel(Files.java:374) ~[?:?]",
elasticsearch_1  | "at java.nio.file.Files.newByteChannel(Files.java:425) ~[?:?]",
elasticsearch_1  | "at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420) ~[?:?]",
elasticsearch_1  | "at java.nio.file.Files.newInputStream(Files.java:159) ~[?:?]",
elasticsearch_1  | "at org.elasticsearch.plugins.PluginInfo.readFromProperties(PluginInfo.java:156) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.plugins.PluginsService.readPluginBundle(PluginsService.java:398) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.plugins.PluginsService.findBundles(PluginsService.java:386) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.plugins.PluginsService.getPluginBundles(PluginsService.java:379) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.plugins.PluginsService.<init>(PluginsService.java:151) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.node.Node.<init>(Node.java:313) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.node.Node.<init>(Node.java:257) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:221) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:221) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:349) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:170) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "... 6 more"] }
elasticsearch_1  | uncaught exception in thread [main]
elasticsearch_1  | java.lang.IllegalStateException: Could not load plugin descriptor for plugin directory [.DS_Store]
elasticsearch_1  | Likely root cause: java.nio.file.FileSystemException: /usr/share/elasticsearch/plugins/.DS_Store/plugin-descriptor.properties: Not a directory
elasticsearch_1  | 	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
elasticsearch_1  | 	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
elasticsearch_1  | 	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
elasticsearch_1  | 	at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
elasticsearch_1  | 	at java.base/java.nio.file.Files.newByteChannel(Files.java:374)
elasticsearch_1  | 	at java.base/java.nio.file.Files.newByteChannel(Files.java:425)
elasticsearch_1  | 	at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420)
elasticsearch_1  | 	at java.base/java.nio.file.Files.newInputStream(Files.java:159)
elasticsearch_1  | 	at org.elasticsearch.plugins.PluginInfo.readFromProperties(PluginInfo.java:156)
elasticsearch_1  | 	at org.elasticsearch.plugins.PluginsService.readPluginBundle(PluginsService.java:398)
elasticsearch_1  | 	at org.elasticsearch.plugins.PluginsService.findBundles(PluginsService.java:386)
elasticsearch_1  | 	at org.elasticsearch.plugins.PluginsService.getPluginBundles(PluginsService.java:379)
elasticsearch_1  | 	at org.elasticsearch.plugins.PluginsService.<init>(PluginsService.java:151)
elasticsearch_1  | 	at org.elasticsearch.node.Node.<init>(Node.java:313)
elasticsearch_1  | 	at org.elasticsearch.node.Node.<init>(Node.java:257)
elasticsearch_1  | 	at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:221)
elasticsearch_1  | 	at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:221)
elasticsearch_1  | 	at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:349)
elasticsearch_1  | 	at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:170)
elasticsearch_1  | 	at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:161)
elasticsearch_1  | 	at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86)
elasticsearch_1  | 	at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:125)
elasticsearch_1  | 	at org.elasticsearch.cli.Command.main(Command.java:90)
elasticsearch_1  | 	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:126)
elasticsearch_1  | 	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92)
elasticsearch_1  | For complete error details, refer to the log at /usr/share/elasticsearch/logs/docker-elk.log
kibana_1         | {"type":"log","@timestamp":"2020-04-20T12:33:25Z","tags":["info","plugins-service"],"pid":6,"message":"Plugin \"case\" is disabled."}
docker-elk_elasticsearch_1 exited with code 1

macOS created some .DS_Store files that confuse Elasticsearch.
rm plugins/.DS_Store should solve your problem.
I will push a .dockerignore file to the repository so those files get ignored by default.

@linyongfu2013 if you pull my latest commit your issue should go away.

macOS 创建了一些.DS_Store混淆 Elasticsearch 的文件。
rm plugins/.DS_Store应该可以解决您的问题。
我会将.dockerignore文件推送到存储库，以便默认情况下忽略这些文件。

nice

repo: deviantony/docker-elk


text:
Menu highlighting is broken

Clicking menu items on top at random doesn't necessarily lead to said items being highlighted. Highlight behavior is highly erratic.

So many bugs, so little time...
I guess I'm going to do pull requests on this one, but fixing required some heavy changes and I hate javascript with a passion.

I've made several commits regarding this and previously reported issue, hope you all can see them.
And while highlighting works great for clicking and page load, scrolling+dynamic highlighting is broken.

repo: devlom/grav-theme-hola


text:
Make validator comments english with translations

'строка %s' % line_num --> _('string %s') % line_num
rus translations
specify language as parameter

Closed by #59

authors: Melevir patrnk


text:
Experiment on Cora

Hi,
Sorry to bother you, I am wondering if there is any experiment using GCN on Cora dataset in your code? I am still not finding that yet.

Hi,
Sorry for the late reply! Do you still need that code?

Thanks for your reply! I've already solved my problems now. Just forgetting about my requirement is OK.😊

Thank you! Hope experiments go smoothly.

repo: devnkong/FLAG


text:
[docs]: fix article "Remove a Subnet"

Description
Article Remove a Subnet needs to be updated, more details @ #855
Issue List

[ ] Guide the user to click Resource Name

Steps below needs to be fixed accordingly

1. In the list of networks, find the network with the subnet you want to remove and click DETAILS
1. In the list of subnets, find the subnet you want to remove and click DETAILS

This issue remains relevant to documentation

@anurag-compile I've assigned this issue to you, as requested.
Happy contributing 😄

please explain little bit like exactly what is required?

@anurag-compile, this article uses an outdated instruction to guide users to access the "Resource Details" page; this issue goal is to update the article to guide the user in the new UI.
We currently have the article Add a Pipeline as a reference of the new UI instructions, please use it as a guideline on how to modify this article
More information on the UI changes in #855

Details Button replaced with Details link
Pages that listed resources (e.g: Applications) had a button on labeled DETAILS to access a resource details page (e.g: Application Details), as mentioned in the article quoted below from the documentation available @ Add a File

@anurag-compile it's simple if you sign up to Devopness at https://www.devopness.com/ and see the documentation page being loaded when clicking on the ❓ button.
You haven't used Devopness yet, am I right?

@anurag-compile I'm reopening this issue, as it is still a relevant issue for our documentation.
Let me know if there's anything me or the team can do to help you in resolving this issue

authors: jfoliveira thlmenezes

repo: devopness/devopness


text:
syslog not availble for windows

i try to build krakend for windows, but building failed.
I just recognise, as far as i tested it, the only reason why krakend-ce build failed for windows is, that the logging is using syslog, which is not availble for windows and plan9.
I would like to have a krakend as a windows binary.
(I just dig a little deeper in this issue and implemented a little work around, 2 src files with different build tags, one for windows without syslog and one for the rest.)

Hi @willie68, couldn't you issue a PR for your changes because it is useful to have krakend-ce running on Windows?

Hi,
i already did this, see https://github.com/devopsfaith/krakend-gologging/pull/4

Sorry, my bad. I didn't notice it because your PR is closed already. You closed it because the maintainer doesn't want to support Windows?
Anyway, it does seem like syslog support have been removed from log.go for non-Windows built, as mentioned in https://github.com/devopsfaith/krakend-gologging/pull/4#issuecomment-601115294.

Yes, that was the main reason.
But can't see any changes on the master branch... But, if you need this, you can simply use the files on my fork.

before closing this, I want to extend my point at the linked discussion: we don't have the resources to keep all the features available on every OS/arch or to manage several production-ready versions with different sets of features/behaviours. that's why we decided to just support gnu/linux environments for production and gnu/linux and osx envs for devel.
this is not me telling you "you should not use windows", this is me suggesting you "if you're on windows, try krakend via docker".

Thats ok for me. No problem. The idea behind windows support for me ( and i think i'm not the only one)  is, that i had to develop software on windows (Company policy). On our side it is not planned to run this software productively on Windows. Our productive cloud stack is based on kubernetes/docker, so everything is fine.

authors: kpacha myusri willie68

repo: devopsfaith/krakend-gologging


text:
local invoke 配置 layer 时解压偶现 end of central directory record signature not found

问题定位：
调用 core 的下载方法解压偶现
解决方式：
后面在用 layer 下载方法是支持一个 解压路径的参数，直接使用 core 提供下载方法解压

await core.downloadRequest(url, corePath, { filename, extract: true, strip: 1 });

或者重拾三次

已发布

repo: devsapp/fc


text:
Feature request: managing schemas

Hi,
Right now there is nothing like this for schema management. It might be useful to also allow/declare what topics/subjects use what schemas:
config:
  #Where the schemas reside
  schemaDir: /tmp/output_dir/
  schema:
    registry:
      url: http://localhost:8081
#     username: test
#     password: test
schemas:
  - relativeLocation: Personnel.json
    # This is equals to confluent references:  https://docs.confluent.io/platform/current/schema-registry/develop/api.html#post--subjects-(string-%20subject)-versions
    references:
      - name: com.person.json
        subject: person
        version: -1
    # If left blank, it will auto submit to personnel-value
    subjects:
      - personnel-raw-value
      - personnel-refined-value
      - personnel-x-value

This would allow the topic state, and schema state to be managed by one tool/file.
java -jar kafka-schema-gitops-1.0-SNAPSHOT-jar-with-dependencies.jar -i <input_yaml> validate # or execute

I really like this idea. I will definitely take this on in the future; though I'm not sure exactly when I'd have time to take it on. I could see it happening within the next couple of months.

I'm very much interested into this too. I'm ready to help with this.
Best,
Jerome

I love this idea and this would be an awesome feature to have. I think it fits in great with the other features of kafka-gitops. I've got some availability coming up and would be able to help out as well.
@jrevillard I'd be happy to have your help as well! With a feature this big, I'd like to do a bit of planning & outlining before we get started on the code. I'd like to make a few examples of how to structure the YAML and discuss.

Hello,
I just seen that you have a first implementation @Twb3 ! https://github.com/Twb3/kafka-gitops/commit/50fa5ccb54ec77ee618d4152436a66804783fa9c
What's the status ? Do you need help ?
Best,
Jerome

Looking forward to having this feature @Twb3!

Hey guys sorry I did not see this earlier.  I did a quick POC for myself to see what's possible.  I think I've got it mostly nailed down.  I hope to propose a file structure soon.  Just need to write it up

Schema Registry POC
https://github.com/Twb3/kafka-gitops/commit/50fa5ccb54ec77ee618d4152436a66804783fa9c
Proposed Schema State File Structure
schemas:
  order-value:
    type: Avro
    file: order-schema.avsc
  order-2-value:
    type: Avro
    file: order-schema.avsc
  shipment-value:
    type: Avro
    file: shipment-schema.avsc
    references:
      - name: order-value
        subject: order-value
        version: 1

Each schema entry above is the name of the subject to be registered in the Schema Registry.  I did this to keep it similar to how topic and service entries are the name of the resource to be created.
Type is self-explanatory although this POC is restricted to only Avro, because I don't know how to parse PROTOBUF yet. (I couldn't find good examples in the confluent schema registry client either)
File is a reference to the schema file located at SCHEMA_DIRECTORY.
Config
Config is handled via environment variables:
SCHEMA_REGISTRY_SASL_JAAS_USERNAME
SCHEMA_REGISTRY_SASL_JAAS_PASSWORD
SCHEMA_REGISTRY_URL (default is http://localhost:8081)
SCHEMA_DIRECTORY (absolute path to directory of schema files) (default is System.getProperty("user.dir"))
Login module is currently hardcoded to org.apache.kafka.common.security.plain.PlainLoginModule
Things to discuss
Schema differences
To know if a schema needs to be updated, I am parsing the schema file and generating a diff using zjsonpatch. I chose to use zjsonpatch because it returns differences by json node rather than the entire file.  For example, the content of your schema could be identical, but you could have rearranged the order of nodes.  The more I think about this while I type it makes me think it's not necessary.  Ultimately, this part still needs work.
Deletion
Schema Registry allows us to soft-delete and permanently delete.  I think we would want to always permanently delete since we want our state file to represent exactly what is deployed.  This is how my code currently works.  I believe this also deletes all versions.
Validation
For validating schemas I did more than just validate the yaml is valid.  I check that the schema file exists at SCHEMA_DIRECTORY and I use methods from Confluent's Schema Registry Client to validate that the Avro schemas can be parsed.  As a result of this, when you validate a schema with references it will actually make a call to your schema registry to validate that the schema you want to reference exists.  This may go too far for validation.  Just need some input.

Nice. Avro is a very good start. Just make sure that this also will work against schema registry in confluent cloud.
When can we start testing? :)

Dear @Twb3,
This seems really promising thanks !
Yes Avro is a good start and the final goal would be to support: Thrift, Protocol Buffers, and JSON Schema. You say that you use the Confluent's Schema Registry Client to validate that the Avro schemas, so I think that this library would be capable of validate the other types isn't it ?
Concerning config, I could contribute with Kerberos as I will need it :-)
Best,
Jerome

Hi @Twb3 @HSA72 @devshawn ,
I don't know if you were aware of this: https://github.com/domnikl/schema-registry-gitops

There is one thing which is complicated for me to answer which is: how to deal with schema ids and versions ? Indeed, those IDs are generated server side and are used by the Kafka clients to identify the good schema. This means that there is no way to ensure the a schema will have the good ID/version and therefore, kafka-gitops cannot be the source of trust for this isn't it ?

As promised, you can more than a POC implementation in #76 !
Please comment, improve etc...

@HSA72 I apologize for not following up on this sooner.  I have not had the opportunity recently to dedicate time to this feature.
@jrevillard Thanks for posting that link to the schema registry gitops implementation!  Looks promising.

As promised, you can find more than a POC implementation in #76 !
Please comment, improve etc...

Nice I will take a look!

@jrevillard I wasn't aware of that project - pretty nice. I still like our approach of putting it into this tool. Maybe their owner would like to help contribute as well?
I'll let you and @Twb3 take the lead on this and then give suggestions and take a look at the POC shortly.

repo: devshawn/kafka-gitops


text:
Q: Custom User ACLs

Hello,
in my state.yaml file, i have this block of sample code:
customUserAcls:
my-test-user:
read-all-kafka:
name: data-
type: TOPIC
pattern: PREFIXED
host: "*"
operation: READ
permission: ALLOW
in the output of the 'plan' switch, it doesn't show the acl being added.  Additionally, do I use 'read-all-kafka' if the user only need to read from only 1 topic?
thanks,

nevermind, figured it out.  had to use users: w/ customUserAcls:


text:
Build is resolving to wrong @angular/core component

When building the main web application (after building the libraries for the "three" and "four" examples), the build fails with the following error:
ERROR in Error: Error encountered resolving symbol values statically. Function calls are not supported.
Consider replacing the function or lambda with a reference to an exported function (position 194:50 in the original .ts file),
resolving symbol NgModule in /home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/demo-app-example-three/node_modules/@angular/core/core.d.ts, resolving symbol ExampleThreeModule in /home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/demo-app-example-three/dist/demo-app-example-three.d.ts, resolving symbol ExampleThreeModule in /home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/demo-app-example-three/dist/demo-app-example-three.d.ts
    at positionalError (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler/bundles/compiler.umd.js:25266:35)
    at simplifyInContext (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler/bundles/compiler.umd.js:25109:27)
    at StaticReflector.simplify (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler/bundles/compiler.umd.js:25123:13)
    at StaticReflector.annotations (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler/bundles/compiler.umd.js:24553:41)
    at _getNgModuleMetadata (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler-cli/src/ngtools_impl.js:138:31)
    at _extractLazyRoutesFromStaticModule (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler-cli/src/ngtools_impl.js:109:26)
    at /home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler-cli/src/ngtools_impl.js:129:27
    at Array.reduce (native)
    at _extractLazyRoutesFromStaticModule (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler-cli/src/ngtools_impl.js:128:10)
    at Object.listLazyRoutesOfModule (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler-cli/src/ngtools_impl.js:53:22)
    at Function.NgTools_InternalApi_NG_2.listLazyRoutes (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@angular/compiler-cli/src/ngtools_api.js:91:39)
    at AotPlugin._getLazyRoutesFromNgtools (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@ngtools/webpack/src/plugin.js:207:44)
    at _donePromise.Promise.resolve.then.then.then.then.then (/home/dfbaskin/dev/lerna-angular-cli-monorepo/packages/demo-app-main/node_modules/@ngtools/webpack/src/plugin.js:443:24)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

The error indicates that the compiler is picking up the @angular/core component from the "three" example rather than using the one from the main project (which I believe leads to duplicate instances of core definitions).
To work around the issue, you must remove the @angular/core directory from the node_modules path in the "three" example.

Added a work-around branch that moves the output of packagr to a libs folder within the main project (within the src directory).  This fixes the build errors, but it seems like there should be a way to build without doing this.

repo: dfbaskin/lerna-angular-cli-monorepo


text:
Update nft-collections.mdx

Fixing background flag on the command for starting the local replica

Thank you for your contribution to the IC Developer Portal. This repo contains the content for https://internetcomputer.org and the ICP Developer Documentation, https://internetcomputer.org/docs/.
If you are submitting a Pull Request for adding or changing content on the ICP Developer Documentation, please make sure that your contribution meets the following requirements:

[x] Follows the developer docs style guide.
[x] Follows the best practices and guidelines.
[x] New documentation pages include document tags.
[x] New documentation pages include SEO keywords.
[x] New documents are in the .mdx file format to support the previous two components.
[x] New documents are registered in /sidebars.js, otherwise, it will not appear in the
side navigation bar.
[x] Make sure that the .github/CODEOWNERS file is
filled with new documents that you added. This way we can ensure that future Pull Requests are reviewed by the right people.

Dear @MykleNero,
In order to potentially merge your code in this open-source repository and therefore proceed with your contribution, we need to have your approval on DFINITY's CLA.
If you decide to agree with it, please visit this issue and read the instructions there. Once you have signed it, re-trigger the workflow on this PR to see if your code can be merged.
— The DFINITY Foundation

authors: MykleNero sa-github-api

repo: dfinity/portal


text:
Can you add License information to this component

We want to use this component, but the company policy does not allow the use of components without a license,
so could you add the license information to the repO?

Hi!
I think we can add MIT license, like in other repositories of our organization. Is this license suitable for you?

Also, can you tell us how you are going to use code from this repo? I'm just curious, so if this is under NDA, it's totally fine if you don't tell.

The company's project uses this REPO, but for compliance checks, it is not possible to use components without a license, so I asked if you could add a license

Fixed via 03808a2, 1b70dc6

authors: IAlwaysLY insolor

repo: dfint/df-translate-hook


text:
Request: Updated program Icon

The current program Icon looks pretty out of place and awfully fuzzy pinned to the taskbar.

Yeh, can't agree more. Would be grateful if someone could make a better icon, I myself, unfortunately, do not have time. So if you or you might know someone who can create one - I will be happy to update it.

authors: dfs-minded stickynoteme

repo: dfs-minded/indexer-plus-plus


text:
refactor(front): refactors PageTransition, scrollTop, and related s…

…tyles
closes #549

opts out of svelte transition scrolltop
only uses scrollTop if transitioning to/between subpages (not home)
adds additional animation steps to PageTransition
adjusts styles accordingly

move body radial to :before and animate opacity on transition


text:
interface conversion: interface {} is *jwt.Token, not *jwt.Token (types from different packages)

Thank you for your work on this library. I am currently following this tutorial and running into a strange error: https://echo.labstack.com/cookbook/jwt
The error text is:
echo: http: panic serving [::1]:60942: interface conversion: interface {} is *jwt.Token, not *jwt.Token (types from different packages)

I'm using the v4 preview. I'm able to generate the token fine, but reading it as jwt.Token is giving me the error in the title. The code is:
func restricted(c echo.Context) error {
	user := c.Get("user").(*jwt.Token) // <-- This line
	claims := user.Claims.(jwt.MapClaims)
	name := claims["name"].(string)
	return c.String(http.StatusOK, "Welcome "+name+"!")
}

The middleware was set as follows:
e.Use(middleware.JWT([]byte("secret")))

Would you have any advice for how to proceed? Thank you

Since you're referencing the *jwt.Token instance exposed by echo, you would need to use the same version of the package that they are. At least for that type assertion. You can still use the v4 preview in other places, most likely. I'd try something like this:
import (
    ...
    jwtv3 "github.com/dgrijalva/jwt-go"
    "github.com/dgrijalva/jwt-go/v4"
    ...
)

Then, on that type assertion line (and likely the one that's after it), you'd refer to jwtv3 rather than just jwt. Like so:
user := c.Get("user").(*jwtv3.Token)
claims := user.Claims.(jwtv3.MapClaims)

I got the same problem, but for me, the solution does not was the suggested by @dcormier, I double-check that I'm importing github.com/dgrijalva/jwt-go in all parts of my source code but for some reason, after I run go mod tidy in the go.sum file I see that it is trying to use github.com/dgrijalva/jwt-go and github.com/form3tech-oss/jwt-go in my solution I just finishing using github.com/form3tech-oss/jwt-go I can't continue wasting time guessing or doing research about the magic on go mod tidy but if someone in the future read this and knows the exact why of this behavior, please share.

authors: dariov1988 dcormier sarimabbas

repo: dgrijalva/jwt-go


text:
Dockerfile

Docker can be great to this project, you should consider to add it.
Actually i'am working in a dockerfile to a personal project using your boilerplate.

Nice to hear! Yes, I should have done this already. Maybe you like to share your Dockerfile here or submit a pr?

authors: MSLacerda dhax

repo: dhax/go-base