User and Role with guid id get exception

Hello. I want to use guid ids for my app and i created CustomUser and CustomRole as
    public class CustomUser : DapperIdentityUser<Guid>
    {

    }

    public class CustomRole : DapperIdentityRole<Guid>
    {

    }

set Identity in Startup.cs
services.AddIdentity<CustomUser, CustomRole>(x =>
                                                         {
                                                             x.Password.RequireDigit = false;
                                                             x.Password.RequiredLength = 1;
                                                             x.Password.RequireLowercase = false;
                                                             x.Password.RequireNonAlphanumeric = false;
                                                             x.Password.RequireUppercase = false;
                                                         })
                    .AddDapperIdentityFor<PostgreSqlConfiguration, Guid>()
                    .AddDefaultTokenProviders();

but i get exception while dependecies resolve in my AccountController.cs
        private readonly UserManager<CustomUser> _userManager;
        private readonly SignInManager<CustomUser> _signInManager;
        public AccountController(UserManager<CustomUser> userManager, SignInManager<CustomUser> signInManager)
        {
            _userManager = userManager;
            _signInManager = signInManager;
        }

Raw exception
 System.InvalidOperationException: Unable to resolve service for type 'Identity.Dapper.Factories.Contracts.IQueryFactory' while attempting to activate 'Identity.Dapper.Repositories.RoleRepository4[Trytoremember.Core.Entities.CustomRole,System.Guid,Identity.Dapper.Entities.DapperIdentityUserRole1[System.Guid],Identity.Dapper.Entities.DapperIdentityRoleClaim1[System.Guid]]'.
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateArgumentCallSites(Type serviceType, Type implementationType, ISet1 callSiteChain, ParameterInfo[] parameters, Boolean throwIfCallSiteNotFound)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateConstructorCallSite(Type serviceType, Type implementationType, ISet1 callSiteChain)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.TryCreateExact(ServiceDescriptor descriptor, Type serviceType, ISet1 callSiteChain)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.TryCreateExact(Type serviceType, ISet1 callSiteChain)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateCallSite(Type serviceType, ISet1 callSiteChain)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateArgumentCallSites(Type serviceType, Type implementationType, ISet1 callSiteChain, ParameterInfo[] parameters, Boolean throwIfCallSiteNotFound)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateConstructorCallSite(Type serviceType, Type implementationType, ISet1 callSiteChain)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.TryCreateExact(ServiceDescriptor descriptor, Type serviceType, ISet1 callSiteChain)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.TryCreateExact(Type serviceType, ISet1 callSiteChain)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateCallSite(Type serviceType, ISet1 callSiteChain)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateArgumentCallSites(Type serviceType, Type implementationType, ISet1 callSiteChain, ParameterInfo[] parameters, Boolean throwIfCallSiteNotFound)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateConstructorCallSite(Type serviceType, Type implementationType, ISet1 callSiteChain)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.TryCreateExact(ServiceDescriptor descriptor, Type serviceType, ISet1 callSiteChain)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.TryCreateExact(Type serviceType, ISet1 callSiteChain)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateCallSite(Type serviceType, ISet1 callSiteChain)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateArgumentCallSites(Type serviceType, Type implementationType, ISet1 callSiteChain, ParameterInfo[] parameters, Boolean throwIfCallSiteNotFound)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateConstructorCallSite(Type serviceType, Type implementationType, ISet1 callSiteChain)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.TryCreateExact(ServiceDescriptor descriptor, Type serviceType, ISet1 callSiteChain)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.TryCreateExact(Type serviceType, ISet1 callSiteChain)    at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateCallSite(Type serviceType, ISet1 callSiteChain)
at Microsoft.Extensions.DependencyInjection.ServiceProvider.CreateServiceAccessor(Type serviceType, ServiceProvider serviceProvider)
at System.Collections.Concurrent.ConcurrentDictionaryExtensions.GetOrAdd[TKey,TValue,TArg](ConcurrentDictionary2 dictionary, TKey key, Func3 valueFactory, TArg arg)
at Microsoft.Extensions.DependencyInjection.ServiceProvider.GetService(Type serviceType)
at Microsoft.Extensions.Internal.ActivatorUtilities.GetService(IServiceProvider sp, Type type, Type requiredBy, Boolean isDefaultParameterRequired)
at lambda_method(Closure , IServiceProvider , Object[] )
at Microsoft.AspNetCore.Mvc.Controllers.ControllerActivatorProvider.<>c__DisplayClass4_0.b__0(ControllerContext controllerContext)
at Microsoft.AspNetCore.Mvc.Controllers.ControllerFactoryProvider.<>c__DisplayClass5_0.g__CreateController0(ControllerContext controllerContext)
at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.d__22.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Builder.RouterMiddleware.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.d__7.MoveNext()
`
But if change Id back to int everything works well.
Can you help me with this trouble?
Thank you.

I have ran your example with guid id and have got same exceptions :C

I've just forget to register IQueryFactory on the others extension methods... I'll update code and NuGet.

Fixed.

Thank you. Everything works well.


ckeditor not displaying until page reload

Hi tsechingho,
I'm using rails 4, bootstrap and ckeditor_rails.
Using the following in my _form view:
<%= f.text_area :content, :class => 'ckeditor' %>

results in a regular bootstrap flavored text_area the first time I visit new or edit. However, if I reload the page, it works.  The text_area becomes fully ckeditor enabled.
I have tried loading js file (//= require ckeditor-jquery) before and after bootstrap but this has no effect.
Any ideas?

  $(document).on('page:update', function(){
      console.log('page updated');
      if ($('.ckeditor')[0]) {
          CKEDITOR.replace($('.ckeditor').attr('id'));
      }
  });

page:before-change a Turbolinks-enabled link has been clicked (see below for more details)
page:fetch starting to fetch a new target page
page:receive the page has been fetched from the server, but not yet parsed
page:before-unload the page has been parsed and is about to be changed
page:after-remove a node (stored in event.data) has been removed from the DOM and should be cleaned up (jQuery data is cleaned up automatically)
page:change the page has been changed to the new version (and on DOMContentLoaded)
page:update is triggered alongside both page:change and jQuery's ajaxSuccess (if jQuery is available - otherwise you can manually trigger it when calling XMLHttpRequest in your own code)
page:load is fired at the end of the loading process.

Thank @trkrameshkumar works like a charm; however, javascript console reports an error "Cannot read property 'getEditor' of undefined" I'm guessing this is a CKEditor bug!

could you be more axplicit please ?
i use simple_form, my views with haml (rails-4.2.2)
nothing works with turbolinks, but also where to add the jquery script ? i can not read it @isratmir .
thanks for provide little bit more information.

@jerome2 try to add to application.js in app/assets/javascript folder

thanks for answer.
not works:
"SyntaxError: [stdin]:1:2: regular expressions cannot begin with * "
and show line:
"= javascript_include_tag 'application', 'data-turbolinks-track' => true"
an idea ?
(or an other one editor can works easy ?)

waiting guys, i think is not the good area for post comment issue.
first i installed gem jquery-turbolinks (and restart nginx server)
then no more problem with turbolinks.
(now no need more your jquery good code)
second, if i not use the way of simple_form in my form, it works, so this is to ask at simple_form gem issues area.
but thanks again for help.

You can keep turbolinks enabled, just reinitialize ckeditor each time page is changed (turbolinks event):
Create custom app/javascripts/ckeditor/reinit.js:
$(document).bind('page:change', function() {
  $('.ckeditor').each(function() {
    CKEDITOR.replace($(this).attr('id'));
  });
});

And add class='ckeditor' to your <textarea>.
That's all.

@kelso: thanks, this works also, but for some ther stuff, jquery-turbolinks help me.
that's fine, thank you.

@kelso :+1:  also loads custom config from ckeditor/config.js

Thanks @kelso, that did the trick.

for those using turbolinks5
jQuery(document).on('turbolinks:load', (e)->
    #do your initialize here
    $('textarea.ckeditor').each(->
        if $(this).css('visibility') != 'hidden'
            CKEDITOR.replace(this)
    )
    if Turbolinks
        Turbolinks.Cache()
)

@kelso's method works for Turbolinks Application Visits but not for Restoration Visits (when the user uses the forward and back buttons).
https://github.com/turbolinks/turbolinks#navigating-with-turbolinks
This is the code I'm using:
var RichTextArea = (function() {
  var exports = {};
  var selector = '.js-become-rich-text-editor';

  exports.load = function() {

    // Get already loaded instances
    var loaded_instances = Object.getOwnPropertyNames(CKEDITOR.instances);

    $(selector).each(
      function() {

        var editor_id = $(this).attr('id');

        // Remove CKEditor instance if already loaded.
        // Necessary for compatibility with Turbolinks restoration visits,
        // in which the instances are not removed
        if (loaded_instances.includes(editor_id)) {
          CKEDITOR.remove(CKEDITOR.instances[editor_id]);
        }

        // Initialize CKEditor instance
        CKEDITOR.replace($(this).attr('id'));
      }
    );

  }

  return exports;
})();

$(document).on('page:change', function() {
  RichTextArea.load();
});

To use, just add the class js-become-rich-text-editor to any editors you want to change into CKEditors.
Explanation:

The RichTextArea.load method is called on every page:change event (whenever Turbolinks changes the page).
loaded_instances contains the IDs of any CKEditor instances that have already been loaded
for each element with the class js-become-rich-text-editor on the page: 1) any matching loaded instance is removed from CKEditor instances, and 2) a new CKEditor instance is initialized

You can solve this by using data: { no_turbolink: true } on the link_to helper.
The a element linking to the page where the ckeditor textarea is located must have data-no-turbolink="true" set in order to instruct turbolinks to be temporarily disabled for that page.

trkrameshkumar 's solution  commented on 22 Sep 2014
worked for me
if you're using AJAX, place this script at the bottom of your new.js.erb file
CKEDITOR.replace('element_id');
Don't forget to add an id of 'element_id' to your text_area tag in the view file . finally a solution thank you!

@u007 's solution worked for me, rails version:  5.1.4
But Turbolinks.Cache()' is failed,  TypeError: Turbolinks.Cache is not a function`.

@zw963 remove the cache part

@u007, thanks, that worked.


TrasparencyLevelHint "AcrylicBlur" and "Blur" do not work on OSX

Describe the bug
Successor of #987. Transparency seems to have regressed for OSX with 0.10.0 and no longer seems to work.
To Reproduce
Avalonia 0.9.12:
<Window xmlns="https://github.com/avaloniaui"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        mc:Ignorable="d" Width="350" Height="200"
        x:Class="AvaloniaDialogTest0912.SplashScreen"
        WindowStartupLocation="CenterScreen"
        Background="Transparent"
        HasSystemDecorations="False">
  <TextBlock Text="This window is transparent" TextWrapping="Wrap" FontSize="35" Margin="5"/>
</Window>

Output:

Avalonia 0.10.0:
<Window xmlns="https://github.com/avaloniaui"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        mc:Ignorable="d" Width="350" Height="200"
        x:Class="AvaloniaDialogTest.SplashScreen"
        WindowStartupLocation="CenterScreen"
        TransparencyLevelHint="AcrylicBlur" Background="Transparent"
        HasSystemDecorations="False">
  <TextBlock Text="This window is transparent" TextWrapping="Wrap" FontSize="35" Margin="5"/>
</Window>

Output:

Expected behavior
I would expect the transparency to work in OSX with Avalonia 0.10.0 the same as it did in 0.9.12
Desktop (please complete the following information):

OS: OSX  10.13.6
Version 0.10.0

Also, if I remove TransparencyLevelHint="AcrylicBlur" the only difference is that the window background is white rather than a light gray

Small question, have you checked TransparencyLevelHint="Transparent" ?

@maxkatz6 Oh, that gives the expected result! I did not check it because I imagined it used similar underlying behavior as Blur or AcrylicBlur. Would this still be considered a bug if those options don't work?

Is this still broken? Seems to still be an issue in 11.1.3


Expo managed flow - android build 403 error (locally)

Hey guys, I would like to create/test builds locally before CI and stuck with android for a bit. CI works fine for android/ios, locally I can build for ios only atm. Appreciate any help or advice.
The same opened issue for flutter I saw: https://github.com/mapbox/mapbox-maps-flutter/issues/580
Environment

Dev OS: OSX 14.6
@rnmapbox/maps version: ^10.1.30 (tried with 10.1.27, 10.1.28, 10.1.29 also)
React Native version: 0.74.5
Expo version: 51.0.28

Steps to reproduce

npx create-expo-app newApp --template blank
cd newApp
expo install @rnmapbox/maps

> add plugin to the app.json

"plugins": [
      [
        "@rnmapbox/maps",
        {
          "RNMapboxMapsDownloadToken": "TOKEN" // selected every checkbox when generated this token just to be sure
        }
      ]
    ]

eas build --platform android --local

I can confirm that issue is not a token since IOS build is successfull and the app working fine but not for android.
However I still get token related error I assume:
[RUN_GRADLEW] FAILURE: Build failed with an exception.
[RUN_GRADLEW] * What went wrong:
[RUN_GRADLEW] Could not determine the dependencies of task ':app:buildReleasePreBundle'.
[RUN_GRADLEW] > Could not resolve all dependencies for configuration ':app:releaseRuntimeClasspath'.
[RUN_GRADLEW]    > Could not resolve com.mapbox.maps:android:10.16.2.
[RUN_GRADLEW]      Required by:
[RUN_GRADLEW]          project :app > project :rnmapbox_maps
[RUN_GRADLEW]       > Could not resolve com.mapbox.maps:android:10.16.2.
[RUN_GRADLEW]          > Could not get resource 'https://api.mapbox.com/downloads/v2/releases/maven/com/mapbox/maps/android/10.16.2/android-10.16.2.pom'.
[RUN_GRADLEW]             > Could not GET 'https://api.mapbox.com/downloads/v2/releases/maven/com/mapbox/maps/android/10.16.2/android-10.16.2.pom'. Received status code 403 from server: Forbidden
[RUN_GRADLEW]    > Could not resolve com.mapbox.mapboxsdk:mapbox-sdk-turf:6.11.0.
[RUN_GRADLEW]      Required by:
[RUN_GRADLEW]          project :app > project :rnmapbox_maps
[RUN_GRADLEW]       > Could not resolve com.mapbox.mapboxsdk:mapbox-sdk-turf:6.11.0.
[RUN_GRADLEW]          > Could not get resource 'https://api.mapbox.com/downloads/v2/releases/maven/com/mapbox/mapboxsdk/mapbox-sdk-turf/6.11.0/mapbox-sdk-turf-6.11.0.pom'.
[RUN_GRADLEW]             > Could not GET 'https://api.mapbox.com/downloads/v2/releases/maven/com/mapbox/mapboxsdk/mapbox-sdk-turf/6.11.0/mapbox-sdk-turf-6.11.0.pom'. Received status code 403 from server: Forbidden
[RUN_GRADLEW] * Try:
[RUN_GRADLEW] > Run with --stacktrace option to get the stack trace.
[RUN_GRADLEW] > Run with --info or --debug option to get more log output.
[RUN_GRADLEW] > Run with --scan to get full insights.
[RUN_GRADLEW] > Get more help at https://help.gradle.org.
[RUN_GRADLEW] BUILD FAILED in 21s
[RUN_GRADLEW] 10 actionable tasks: 10 executed
[RUN_GRADLEW] Error: Gradle build failed with unknown error. See logs for the "Run gradlew" phase for more information.

I also getting error while installing

Same problem

403 sounds like a token issue. You can check the eas generated project  grade files to see if the token is correct in them

I had same problem, 403 forbidden. It was because I used a public token, try with a private one.
I used a full scope token so I don't know witch scope is sufficient

Did you manage to find a solution for this issue? I'm encountering the same problem. I created a new secret token with all the permissions, but unfortunately, that didn’t resolve it.


Minor changes

Added a method to change authentication manually so that (like in my
case) if a user authenticates to see a screen and then navigates away
from that screen, you can change the authentication factor so the user
is no longer authenticated. I also changed the key in the NSLOG to
actually log the password.

Thanks for your library!


Bugfix/home page typo

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: skytrench sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Removes Azure container registry not supported limitation.

Fixed in v0.9.1 (#415)
To be merged after documentation is updated to v0.9.1

Why not just push this to the readme branch itself?

I think that’s a minor-enough issue that we can just track it as an issue
rather than stating it on the documentation.
On Thu, Jun 28, 2018 at 6:00 PM Tad Cordle<EMAIL_ADDRESS>wrote:

@TadCordle commented on this pull request.
In jib-gradle-plugin/README.md
https://github.com/GoogleContainerTools/jib/pull/466#discussion_r198999930
:

@@ -274,12 +274,6 @@ jib {

See the Jib project README.
-## Known Limitations
-These limitations will be fixed in later releases.
-* Pushing to Azure Container Registry is not currently supported.
Should we list docker-credential-acr-* not working?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleContainerTools/jib/pull/466#pullrequestreview-133037542,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEoLKqf32BSNUxQZgveKK8f1qZwRQp3Hks5uBVIDgaJpZM4U8Huh
.


Admin can view program form

Blocked on #97, #98
Describe the solution you'd like
Admin can view a form for creating a new program. For now that form only has fields for the program name and description.
Done when
Admin can view the form

wireframes : https://miro.com/app/board/o9J_lXULxwE=/?moveToWidget=3074457354355841620&cot=14

M1 Review - Complete


Multilingual root routes

Some routes should be language rooted instead of site-rooted on multilingual sites.
Some routes with public views as /sitemap should be language rooted. I think we need for example /en/sitemap and /es/sitemap on multilingual sites instead of just /sitemap
multilingualRoutes on routes.js
I propose to have another variable called multilingualRoutes as same as defaultRoutes, but adding it only when config.settings.isMultilingual is true.
multilingualRoutes example for sitemap
export const multilingualRoutes = [{
      path: `/(${config.settings.supportedLanguages.join('|')})/sitemap`,
      component: Sitemap,
    }]

add multilingualRoutes to routes
routes: [
...
    ...(config.addonRoutes || []),
    ...defaultRoutes,
    ...(config.settings.isMultilingual && multiligualRoutes),
]

Your proposal looks good to me. I think it should be:
routes: [
...
    ...(config.addonRoutes || []),
    ...((config.settings.isMultilingual && multiligualRoutes) || []),
    ...defaultRoutes,
]

Solved with PR #2578


Tuple enrichments are deprecated in 0.13 but not in 1.0

steps

0.13: https://github.com/sbt/sbt/blob/96ddc33a3e5ecc36ee34a2f032e307501390f4d8/main/settings/src/main/scala/sbt/Structure.scala#L295
1.0: https://github.com/sbt/sbt/blob/037559c8d3f1aee3db95c63650ef8cfd265b28fb/main-settings/src/main/scala/sbt/Structure.scala#L570

problem
Code that uses tuple enrichments in 0.13 compiles with deprecation warnings while it compiles clean in 1.0.
expectation
I expect tuple enrichments to compile without deprecation warnings in 0.13.
notes
I'm working on sbtfix and I'd like the expected output code to compile without deprecation warnings. Users expect a migration tool to remove deprecation warnings.
sbt version: 0.13.16

One distinction that is omitted is that in 1.0 they're not deprecated, but they're opt-in: https://github.com/sbt/sbt/pull/3291

Fair enough. Is it possible to import TupleSyntax in 0.13? The deprecation warnings should in either case be updated to reflect this change.

The deprecation warnings should in either case be updated to reflect this change.

Agreed.

Is it possible to import TupleSyntax in 0.13?

I'm not sure if it's possible simultaneously:

keep tuple syntax is deprecated without the import,
make it non-deprecated with the import, and
maintain backwards compatibility

I see. How about we remove the deprecation warnings as in #3455  and add a mention to TupleSyntax in the migration guide? There are other breaking changes in 1.0 that did not get deprecation cycles. False deprecation warnings create unnecessary fear to upgrade to 1.0. Some builds use tuple enrichments a lot.

In sbtfix are you "fixing" it by importing TupleSyntax?

I haven't handled tuple enrichments yet, but that is what I had in mind yes.

Reason I asked is because I'd prefer if we fixed people's builds/plugins by moving to .value instead..

Rewriting tuple syntax might be doable, but to my best knowledge it's not possible to translate tuple enrichments to .value in some cases without changing semantics. I'd like to prioritize the rewrites on lower hanging fruits.

to my best knowledge it's not possible to translate tuple enrichments to .value in some cases without changing semantics.

I believe it's possible to rewrite from tuple syntax to .value syntax and reserve the same behaviour. And if it's not possible for all cases, it's possible for >90% of them, imo.
What you are referring to is that the .value macro introduces some changes in semantics to Scala's semantics. See also Jorge's and Eugene's chat about that in PR #3079.
You have more knowledge of Scalafix and rewrites, but I think it's a mistake to ship a rewrite (especially out the box!) that migrates every sbt 1 build to opt into tuple syntax. I would much rather have a more conservative tuple-to-value-macro rewrite that we incrementally (and conservatively) improve to different shapes and uses of the tuple syntax.

I am happy to discuss tuple syntax rewriting in https://github.com/scalacenter/scalafix/issues/292
Regardless of the rewrite, what should be done about the deprecation warnings on tuple enrichments?

Regardless of the rewrite, what should be done about the deprecation warnings on tuple enrichments?

I'm as of yet still unconvinced the solution is to remove the deprecations in 0.13.17+.
As I said above the (imo) ideal solution would be one that:

keeps the tuple syntax deprecated without the import,
makes it non-deprecated with the import, and
maintains backwards compatibility

though I'm not sure if it's possible.

I agree that would be an ideal solution. What do you propose as the next actionable step? I find the current deprecation warnings confusing.

The current deprecation warnings read:

The sbt 0.10 style DSL is deprecated: '(k1, k2) map { (x, y) => ... }' should now be '{ val x = k1.value; val y = k2.value }'.\nSee http://www.scala-sbt.org/0.13/docs/Migrating-from-sbt-012x.html

In my opinion referring to it as "deprecated" is correct. Perhaps having the example is confusing. Also (somewhat confusingly) that page has become "Migrating from sbt 0.13.x" in the sbt 1 docs, to include additional changes; compare:

http://www.scala-sbt.org/0.13/docs/Migrating-from-sbt-012x.html
http://www.scala-sbt.org/1.0/docs/Migrating-from-sbt-013x.html

Do you think the following message helps remove your source of confusion?

The sbt 0.10 DSL is deprecated; see http://www.scala-sbt.org/0.13/docs/Migrating-from-sbt-012x.html

(I like dropping the newline because I've answered lots of questions where users read the first line and not the second line..)
and then mention the import sbt.TupleSyntax opt-in in the sbt 1 migration guide? WDYT?

Saying "The sbt 0.10 DSL is deprecated" is confusing IMO when import TupleSyntax._ is enough to keep using the same DSL in sbt 1.0. I understand the motivation to encourage users to move to .value but I feel @deprecated should be reserved for features that are truly deprecated. Bumping a big old sbt build from 0.13.6 to 0.13.16 typically results in a ton of deprecation warnings, which might scare off users who want to migrate to 1.0. I think sbt 1.0 is currently in a critical phase where there is momentum towards migrating.
Semantic tooling to encourage best practices hasn't been there so far so I totally understand the usage of @deprecated. However, maybe this will change soon. I'm currently adding support to implement linters in scalafix https://github.com/scalacenter/scalafix/pull/291 "use .value instead of tuple enrichment" could maybe be a linter warning instead of deprecation warning.

What are you defining as "features that are truly deprecated"? Do you mean @deprecated should only be used for things that are being dropped, not also for things that are being moved?
Here are some useful references I looked up.
The relevant definition of "deprecate" in the Oxford dictionary:

be usable but regarded as obsolete and best avoided, typically because it has been superseded.

(https://en.oxforddictionaries.com/definition/deprecate)
and from the Java documentation:

A deprecated class or method is [..] so unimportant, in fact, that you should no longer use it, since it has been superseded and may cease to exist in the future.
Java provides a way to express deprecation because, as a class evolves, its API (application programming interface) inevitably changes: methods are renamed for consistency, new and better methods are added, and fields change. But such changes introduce a problem. You need to keep the old API around until developers make the transition to the new one, but you don't want them to continue programming to the old API.

(https://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/deprecation/deprecation.html)
By those definitions moving the tuple syntax out of implicit scope means that the original implicit defs are deprecated.
Now, Scalafix changes the game and I'm a strong supporter of it, but I don't think we can redefine @deprecated. Maybe we need to find another name and add another annotation in the stdlib. @dropped, maybe?

You have convinced me that it is OK to keep the @deprecated on tuple enrichments.
My worry comes from the fact that there are lots of deprecation warnings that may demotivate users to upgrade.

Maybe we need to find another name and add another annotation in the stdlib. @dropped, maybe?

Might be a cool idea, but I prefer to invest my efforts on helping people upgrade to sbt 1.0 😉

Hopefully we can reassure them by promoting the availability of great tooling: the sbt 1 scalafix rewrites.

I have updated the PR following your advice. The message is now

The sbt 0.10 style DSL is deprecated; see http://www.scala-sbt.org/0.13/docs/Migrating-from-sbt-012x.html

Closing this since I'm guessing many builds have now moved on.


a question about released checkpoint

Hi!
In Table 3 of the paper, MANIQA-s achieves 0.686/0.707 on the validation set, and 0.667/0.702 on the test set. Are these two sets of results are obtained from testing the same model checkpoint?
I tried to test and submit using the checkpoint and test script you released, and achieved 0.69/0.71 on the validation set but only 0.66/0.68 on the test set. So I want to know if the results are tested from the same parameters.
Thanks!

The test sets results are obtained from the ensemble-model.

@YaoShunyu19 I will release other datasets checkpoints!


Library sync fails if jellyfin initial user is LDAP

Description
403 unauthorized error and unable to make an initial sync of libraries when using my LDAP admin.  When I setup using the local admin account  the libraries sycned with no issue.
Version
1.7.0

Steps to Reproduce

Setup Jellyfin with LDAP
Setup new Jellyseerr instance and configure using an LDAP admin account.

Screenshots
No response
Logs
No response
Platform
desktop
Device
docker
Operating System
docker
Browser
firefox
Additional Context
No response
Code of Conduct

[X] I agree to follow Overseerr's Code of Conduct

Having the same issue, however I can't sync libraries even when trying to use a local account.

Having the same issue, however I can't sync libraries even when trying to use a local account.

What's the error you get when you try to sync libraries with local account? Make sure local account is admin, and also make sure automstic grouping is disabled

Having the same issue, however I can't sync libraries even when trying to use a local account.

What's the error you get when you try to sync libraries with local account? Make sure local account is admin, and also make sure automstic grouping is disabled

In the browser console I can see "GET https://sub.domain.tld/api/v1/auth/me 401 (Unauthorized)

"
And also a POST of the above
And that is prior to signing in as well. This is happening for both local and LDAP account now. Yesterday, I was at least able to sign in.

What about the app logs?

So just enabled debug logs, but the only thing that comes in is about scheduled jobs.

So just enabled debug logs, but the only thing that comes in is about scheduled jobs.

When you attempt to login there's no log?

Correct.

@linedpaper #524 should fix it! :smile:

:tada: This issue has been resolved in version 1.8.0 :tada:
The release is available on:

v1.8.0
GitHub release

Your semantic-release bot :package::rocket:


Make result transformation async

I think we forgot to do this in other places too.
Without this change hydrations etc wouldn't block the thread, BUT they would be sequential.

Replacing with #353


Add workflowstate to the ebauth logs

This issue is imported from pivotal - Originaly created at Jun 12, 2018 by Bart Geesink
We are implementing a new statistics framework in OpenConext. In order to be able to determine the state (prodaccepted/testaccepted) it would be usefull if that state is logged to the ebauth logs, in addition to the current logs which look like this:

{"channel":"authentication","level":"INFO","message":"login granted","context":{"login_stamp":"2018-06-11T20:27:19+02:00","user_id":"urn:collab:person:example.com:admin","sp_entity_id":"https://spdashboard.test2.surfconext.nl/saml/metadata","idp_entity_id":"http://mock-idp","key_id":null,"proxied_sp_entity_ids":[]},"extra":{"session_id":"QIYDMkYL0iadmHL4k95LWykjBGb","request_id":"5b1ebf07cc1ab"}}
Code change

PR to master: https://github.com/OpenConext/OpenConext-engineblock/pull/551
PR to 5.7: TODO

@bartgeesink , will this way of logging the workflow state be sufficient?

Jun 20 14:53:23 apps EBAUTH[5365]: {"channel":"authentication","level":"INFO","message":"login granted","context":{"login_stamp":"2018-06-20T14:53:23+02:00","user_id":"urn:collab:person:example.com:admin","sp_entity_id":"https:\/\/teams.vm.openconext.org\/shibboleth","idp_entity_id":"http:\/\/mock-idp","key_id":null,"proxied_sp_entity_ids":[],"workflow_state":"prodaccepted"},"extra":{"session_id":"5Y53SRgSPB6yuv1N9UWoQpLjjF2","request_id":"5b2a4e42cdb83"}}

The key: workflow_state is used in the log entry's context. Is this an OK key? Or do you prefer something different? (Michiel Kodde - Jun 20, 2018)

That should be enough for our use case (Bart Geesink - Jun 20, 2018)


Restrict externally connectable to companion only

https://developer.chrome.com/apps/manifest/externally_connectable
Triggered by #105

No change required - by default, access is blocked from all websites. Access is allowed form extensions, but receiving those messages requires a message handler on runtime.onMessageExternal, which we don't have - so we are good.


nativescript-fingerprint-auth - Touch ID in ios locks the biometetic after 5th attempt fail

Hi Team
we have used the plugin nativescript-fingerprint-auth (https://github.com/EddyVerbruggen/nativescript-fingerprint-auth) in our app when we give the wrong finger prints for the five times it locks the biometeric device of the iOS. It is working after we lock and unlock the device using Pass code.
Is there any way to unlock biometeric using the code if they give the correct password.
regards,
Jai

Apple requires the passcode after 5 times, not the password. It's by design.


[WIP] BREAKING CHANGE: Native code audit, mostly Android

This PR contains a breaking change
Summary / Motivation
Get rid of warnings, fix some code styling, better null checks, remove usage of deprecated Android features, better file naming, use PaymentLauncher instead of stripe.onPaymentResult
For reviewing- it's probably most efficient to review this PR commit by commit
Testing

[x] I tested this manually
Existing automated tests should pass

Documentation
Select one:

[ ] I have added relevant documentation for my changes.
[x] This PR does not result in any developer-facing changes.

@michelleb-stripe requesting your review since you did the Android audit (here). Really the only commit that I think could use your attention is [this one]

I just sent @ccen-stripe a message this morning to get some feedback on one remaining comment: https://github.com/stripe/stripe-react-native/pull/832/files#r822856777


non-zero exit status 127

I am trying to run the code but this problem appeared to me
raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command 'g++-4.9 -std=c++11 -shared -o backward_warp_op.so backward_warp_op.cu.o backward_warp_op.cc -I /home/hzaal/tensorflow/lib/python3.4/site-packages/tensorflow/include -fPIC -lcudart -D GOOGLE_CUDA=1 -L /usr/local/lib64' returned non-zero exit status 127

Did you point the g++ in the config.ini to your local g++? It seems it can't find g++.

Thank you


Yara 4.2 make check fails on test-rules and test-exception

Following instructions from the docs, initially I ran:
./bootstrap.sh
./configure
make
sudo make install
And then:
make check
Which resulted in the following errors:

I'm running Kali over WSL2, latest kernel version: <IP_ADDRESS>-microsoft-standard-WSL2 x86_64.
Please let me know if there is any other information I can provide.
Update: I tried the latest stable version of yara (4.1.3) as well and test-exception fails there too.

It looks like the reexec function (https://github.com/VirusTotal/yara/blob/master/tests/test-exception.c#L222) in the test is not working as expected in WSL2. It could be either fork returning a negative number, execve returning non-zero or waitpid setting a non-zero status. It would be helpful if you can add some printf statements in reexec for determining at which point reexec is failing.

So, waitpid is setting status to 256, which apparently means that the child process received a SIGHUP signal. @hillu, do you have any clue about this issue?
The code is pretty old and nobody have complained before, so it looks like something that only happens in WSL, probably something that works different from other POSIX systems.

So, waitpid is setting status to 256, which apparently means that the child process received a SIGHUP

No, the child ended with exit(1). I don't have an idea why, though.
I'm not really sure what is going on here and I don't have a Windows box with WSL2 available for testing. Does the Linux environment share filesystems or does it run off its own block device?

Does the Linux environment share filesystems or does it run off its own block device?

Not sure to be honest but I would lean on the former.


Update CODEOWNERS

Signed-off-by: Ry Jones<EMAIL_ADDRESS>

Can someone remove me from the solang-committers team? I believe I probably am there because I created the team originally when it was part of labs. I don't think I need to be part of the CODEOWNERS.

Can someone remove me from the solang-committers team? I believe I probably am there because I created the team originally when it was part of labs. I don't think I need to be part of the CODEOWNERS.

done!


Update to repo-config v0.11.0

Update the files using the migration script with the following changes:

Group artifact-related actions so they are updated together.
Add asyncio_default_fixture_loop_scope pytest option as not specifying this is deprecated.
Disable some pylint checks that are already checked by mypy.

We also bump the build dependencies, so the distribution files use names that are compatible with PEP625, which will soon be required by PyPI and fix pylint warnings in examples that were previously ignored as they were not checked by pylint due to a sybil bug.

Skipping release notes as there are no visible changes.


What would decentralized publishing on IPFS for npm actually look like?

There was some talk of decentralized publishing for npm-on-ipfs on the IPFS GUI call yesterday as a potentially interesting area to explore.
After exploring some decentralized package manager ideas I thought I'd try to apply some of them to an npm implementation.
Assuming ipfs client support can be added to npm or yarn and that IPNS isn't slow (or DNSLink is used), how does one go about publishing a package directly to IPFS and then having someone else consume it?
One key aim here is to not require hosted infrastructure, can we just use standard IPFS tooling and keep the logic in the clients?
Also of note, none of these solve the discovery problem of "where do I find the decentrally published packages", which likely would be an opt-in search engine where publishing tools announce the cid of new published packages to be indexed.
Level 1
The simplest option would be to add the a tarball directly to ipfs:
ipfs add big-number-1.1.0.tgz
Then any user could specify it as a dependency in package.json:
{
  "name": "my-module",
  "dependencies": {
    "big-number": "ipfs://Qmfoo",
  }
}

Downsides to this:

hardcoding specific version
no update mechanism

Level 2
To add an update mechanism to level one, you could use ipns:
ipfs name publish $(ipfs add big-number-1.1.0.tgz)
Then any user could specify it as a dependency in package.json:
{
  "name": "my-module",
  "dependencies": {
    "big-number": "ipns://Qmfoo",
  }
}

Then when publishing a new version, just update ipns to point to the new one:
ipfs name publish $(ipfs add big-number-1.1.1.tgz)
Downsides to this:

end user can't control which version they are getting
may cause integrity errors with previous versions stored in lockfiles

Level 3
To allow end users to control which version they are installing, publish a modified index file (eg bignumber) along side the tarball.
Rather than adding a new field cid, like npm-on-ipfs does, instead make the tarball field the cid of that versions tarball:
"dist": {
  "shasum": "e6ab0a743da5f3ea018e5c17597d121f7868c159",
  "tarball": "ipfs://bafybeihmelfwcg664jeznipvrx2qzc6acrme5ztea2r4rljdqzrj72bx6u"
}

As in level 2, using an IPNS name for the index will allow for an update mechanism:
ipfs name publish $(ipfs add bignumber)
Then any user could specify it as a dependency in package.json:
{
  "name": "my-module",
  "dependencies": {
    "big-number": "ipns://Qmfoo^1.1.0",
  }
}

Missing parts:

A tool for generating an index file (packument) locally for one or more versions of package

Downsides:

Referencing an ipns hash in package.json isn't very human readable and provides no information about who the publisher of it is
By default dependencies will still be installed from npmjs.org over http, unless someone goes through and manually republishes all dependencies with their dependencies declared as ipns hashes as well

Level 4
Publishing a small registry directly to IPFS.
npm-on-ipfs has already shown how you can setup an npm registry on ipfs, by publishing multiple versions indexes (packuments) and adding them to a folder (or mfs), an IPFS address can then be used as a registry rather than a the location for one particular package.
small registries could be collections of useful modules for individual personal use, but the most likely use case is per-project registries that contain all the dependencies for that application.
Command to point your local npm client at an ipfs registry
npm config set registry ipns://QmT8wUy9CV3FHbjQeDG49ZL7at24u5fynBrkjum4MznNA7
The setting can also be added to a .npmrc file which can be commited in a repository so that all users of that project use the same registry:
registry=ipns://QmT8wUy9CV3FHbjQeDG49ZL7at24u5fynBrkjum4MznNA7

Then packages can be referenced in your package json using regular names:
{
  "name": "my-module",
  "dependencies": {
    "big-number": "^1.1.0",
  }
}

This has the added benefit that all sub-dependencies will also be pulled from IPFS automatically, but will require the publisher of that registry to ensure they have added all required versions of every sub-dependency to that IPFS folder before using it.
Missing parts:

A tool for generating an index file (packument) locally for one or more versions of package
A tool that uploads a number of generated packuments and tarballs to an IPFS folder (would probably want to also pin the root on a pinning service to ensure future availability)
A tool that monitors upstream sources of third party packages added to a registry and provides a way to bring in new releases and republish to IPFS

Downsides:

requires all end users of repos with a ipfs .npmrc to use IPFS for installing modules, as they won't be able to get the same packages from npmjs.org
only the one owner of the IPNS can publish new versions of the registry, which is restrictive for teams of multiple people
all other features that involve communicating with a http registry would be broken, only fetching packuments would work
having the registry config being a hash isn't very human friendly, would likely want to use DNSlink to make it friendlier

Note:

I'm not sure if @achingbrain's PR to npm would work with pointing whole registries at ipfs addresses, needs further investigation

I was going to open an issue on ipfs-desktop about the possibility of bundling a fork of npm with ipfs support added via pacote that would enable some of these ideas via the flick of a switch in IPFS desktop.
But thinking about it, npm-on-ipfs and the pacote patch come at the problem from two different angles and I suspect the current implementation of npm-on-ipfs would not directly benefit from the pacote patch being merged (or available in a fork).
This is because npm-on-ipfs acts as a transparent IPFS proxy for registry.npmjs.org, allowing individual users to opt-in to loading data from registry.npmjs.org over IPFS. It doesn't force other contributors to the same project to also use npm-on-ipfs.
The pacote patch on the other hand does force any other contributors to use IPFS as well, take the following package.json for example:
{
"name": "my-module",
"dependencies": {
"big-number": "ipns://Qmfoo^1.1.0",
}
}
ipns://Qmfoo doesn't have an equivalent http address, so the only way to resolve the address of big-number is to load it over IPFS.
I'd like to propose a slightly different approach inspired by ipfs-companion.
ipfs-companion-lib
ipfs-companion the browser extension does a neat thing where if it see's the browser loading a http url where the query path starts with /ipfs/ or /ipns/ (for example: https://ipfs.io/ipfs/Qmc5gCcjYypU7y28oCALwfSvxCBskLuPKWpK4qpterKC7z) then it makes the request using IPFS rather than http, it'll also detect DNSLinks on the domain name and x-ipfs-path http headers: https://github.com/ipfs-shipyard/ipfs-companion#automagical-detection-of-ipfs-resources
It also only upgrades requests if it detects that the user has an active IPFS node, either via an embedded one, IPFS desktop or a go-ipfs daemon.
If there was a low level javascript http library (perhaps called ipfs-companion-lib or http-or-ipfs) that had a similar ability to "upgrade" certain http requests to IPFS using a similar set of conditions to companion.
This would then enable users with IPFS support to enjoy loading modules from their neighbors without directly adding IPFS hashes to their package.json files. I suspect DNSLink or x-ipfs-path would be very useful here, allowing a registry mirror/proxy to host packuments and tarballs on IPFS as well as providing a http fallback without localhost:8080 ending up in package-lock.json files (one of the things npm-on-ipfs has to manually rewrite after installation).
It doesn't look like registry.js.ipfs.io currently publishes a DNSlink record but that'd be a good thing to add.
It'd also mean that for self-published packages, rather than using the pacote patch style ipns://Qmfoo dependencies, the ipfs gateway address could be used, which will work for both existing http clients and users who choose to use IPFS:
{
  "name": "my-module",
  "dependencies": {
    "big-number": "https://ipfs.io/ipns/Qmfoo^1.1.0",
  }
}

One other thing to note here, currently the npm-on-ipfs infrastructure uses js-ipfs and does not connect to the same DHT as go-ipfs, so trying to load tarballs and packuments through the ipfs gateway (http://ipfs.io/ipfs/bafybeihmelfwcg664jeznipvrx2qzc6acrme5ztea2r4rljdqzrj72bx6u) doesn't find anything.

There are quite a few things to unpack here..

(Missing parts) A tool for generating an index file (packument) locally for one or more versions of package

This should be trivial to implement - I can't find a detailed spec for packuments but there's an overview on the packote repo.

Referencing an ipns hash in package.json isn't very human readable

True, but you can have more memorable strings via DNSLink and it's better than having them in the source code.  If we get registry.js.ipfs.io to publish DNSLink TXT records it'll make this a bit more bearable.
Not sure how it would look though, maybe:
  "express": "ipns://express.npm.registry.js.ipfs.io#^4.0.0",

Also more unsure of how we'd deal with scoped packages (e.g. @hapi/hapi)?
  "hapi": "ipns://hapi-hapi.github.registry.js.ipfs.io#^18.0.0"

Referencing an ipns hash in package.json provides no information about who the publisher of it is

This is definitely a concern but one I hope we can solve outside of package managers.  For example, if the CID an IPNS name resolved to was an intermediate dag-cbor node like:
{
  "cid": "QMfoo...",
  "author": "MIIBCgKCAQEA6...",
  "signature": "ZGFzZHNsa2Rqc2Z..."
}

Where author is a public key, signature is the CID encrypted by the private key the public key corresponds to.  Verify the public key of the person you trust out-of-band, then decrypt the signature using the public key and it should match the cid.  Something like that, though IANASE (I am not a security engineer).

By default dependencies will still be installed from npmjs.org over http, unless someone goes through and manually republishes all dependencies with their dependencies declared as ipns hashes as well

I think this is ok.  We already pull deps from npmjs.org, github, arbitrary file:// & http:// URLs, and it all seems to work.

I'm not sure if @achingbrain's PR to npm would work with pointing whole registries at ipfs addresses, needs further investigation

Not as it stands - it's more aimed at the Level 3 use case above.
My gut feeling is that Level 4 adds a significant amount of complexity - it'd probably be good for teams working on large apps but may be overkill for small projects/libs.
The IPFS Companion approach is interesting - the x-ipfs-path seems to be the only reliable way to detect IPFS versions of the thing you're requesting, parsing it out of URLs seems very fragile.  Until npm/github add x-ipfs-path headers you'd depend on our centralised infrastructure which I don't think we should rely on.
You've also made enough of an HTTP request to get the x-ipfs-path header in the response so at that point it feels like you should just let the HTTP request run to completion (or would it just do a HEAD on the resource?).

currently the npm-on-ipfs infrastructure uses js-ipfs and does not connect to the same DHT as go-ipfs

Or any DHT for that matter.  It's coming in 0.36.0 though - if it doesn't we can convert registry.js.ipfs.io to use go-ipfs under the hood, though it's been a very useful vector for performance testing js-ipfs up until now.

If there was a low level javascript http library (perhaps called ipfs-companion-lib or http-or-ipfs) that had a similar ability to "upgrade" certain http requests to IPFS using a similar set of conditions to companion.

How do you see this working?  We could monkey-patch node internals but you'd have to require it somehow.  Also it seems a bit weird to co-opt the http:// protocol if that's what the user has specified.

Ermergerd there's a lot here, sorry for the stream of consciousness.
The way I see npm-on-ipfs working in future is something close to Level 3:

registry.js.ipfs.io ingests modules from npm, github's new registry and any others that pop up
Add CIDs to the packuments of these modules as it currently does
Publish IPNS names for the packuments
Present a search engine for module IPNS names at https://registry.js.ipfs.io - might show READMEs too or something, like a libraries.io-lite
People use ipns://Qmfoo#^1.0.0 in their package.json files
Either the pacote PR is merged or we publish an npm fork that just tracks upstream and has the PR merged
Add a similar transport to yarn - could encourage people to use that instead of an npm fork?  Probably preferable - forking should be a last resort as it's a bit aggressive and adds maintenance overhead
Provide a tool to let people generate their own packuments and publish IPNS names - optionally inform registry.js.ipfs.io of their existence which would replicate the IPNS name & add it to the search engine

I'm been doing some real world testing with this today, although instead of using @achingbrain's pacote patch, I just used the local http gateway provided by the ipfs daemon.
Level 1
This works as expected:
$ npm pack my_module
$ ipfs add my_module-1.0.0.tgz

Install it:
$ npm install http://localhost:8080/ipfs/QmeuiRzbjhnyghoADPCrmPpQYgLj4eG94TWVcedXp6S2mg
It results in the local gateway url to the tarball being added to package.json as the version:
{
  "name": "testing",
  "dependencies": {
    "base62": "http://localhost:8080/ipfs/QmeuiRzbjhnyghoADPCrmPpQYgLj4eG94TWVcedXp6S2mg"
  }
}

and a similar package-lock.json file:
{
  "name": "testing",
  "requires": true,
  "lockfileVersion": 1,
  "dependencies": {
    "base62": {
      "version": "http://localhost:8080/ipfs/QmeuiRzbjhnyghoADPCrmPpQYgLj4eG94TWVcedXp6S2mg",
      "integrity": "sha512-YtkASiZCn90Bd78+tLHSSxtrUekRLUchUhtPCp46vONCJEHJrXOJc97x6Ipdfos0xKIw/9fVBo1adBV5MAkhEA=="
    }
  }
}

Level 2
Similar to level 1 but with an ipns name.
Generate a tarball and add it to IPFS:
$ npm pack my_module
$ ipfs add my_module-1.0.0.tgz

Then publish it under an ipns:
$ ipfs name publish QmeuiRzbjhnyghoADPCrmPpQYgLj4eG94TWVcedXp6S2mg

Install it:
$ npm install http://localhost:8080/ipns/QmeuiRzbjhnyghoADPCrmPpQYgLj4eG94TWVcedXp6S2mg
I couldn't get that last stage to complete, it timed out every attempt, ipns is still too slow to recommend anyone use it. That said, I expect to get the same results as with Level 1 just with a slightly different url.
This also has the existing downside of not allowing users to control which version they are installing and will cause integrity checks with lockfiles, so not a good idea to use for demos either.
Level 3
Turns out this does not work at all, although not because of IPFS but a misunderstanding in how npm installation arguments work.
The theory was that you could publish a "packument" to IPFS and then pass the address to npm along with a version and it would just work.
Testing with a regular packument from npmjs.org over http reveals the problem:
$ npm install http://registry.npmjs.com/bignumber
npm ERR! code ENOPACKAGEJSON
npm ERR! package.json Non-registry package missing package.json: http://registry.npmjs.com/bignumber.
npm ERR! package.json npm can't find a package.json file in your current directory.

If you pass anything that looks like a url (or any other address that pacote already supports like git://) then npm is expecting to find a single folder of a release with a package.json in the root.
In other words, you can't pass a packument to npm install, which invalidates Level 3 entirely 🙈
Level 3.1 (previously level 4)
So if level 3 doesn't work, what does?
As far as I can tell the only way to pass a packument tonpm install is with the --registry flag:
npm install<EMAIL_ADDRESS>--registry=https://registry.js.ipfs.io
One catch at the moment is that the --registry option has to use http(s):
$ npm install bignumber --registry=/Users/andrewnesbitt/code/testing/bignumber
npm WARN invalid config registry="/Users/andrewnesbitt/code/testing/bignumber"
npm WARN invalid config Must be a full url with 'http://'
npm ERR! Only HTTP(S) protocols are supported

fun fact: npm uses a different module for making registry requests than pacote: npm-registry-fetch, so @achingbrain's pacote patch won't automatically add ipfs support here too
But we can use the local http gateway provided by ipfs 🎉
The command npm install<EMAIL_ADDRESS>--registry=https://registry.js.ipfs.io ends contructing a packument url like https://registry.js.ipfs.io/bignumber in which it then searches for version 1.1.0.
If we take the packument from https://registry.js.ipfs.io/bignumber and drop it in an empty folder called my_registry:
wget -P my_registry https://registry.js.ipfs.io/bignumber
Then add that folder to ipfs:
ipfs add -r my_registry
We can then use the CID folder as the root registry over the local gateway:
$ npm install<EMAIL_ADDRESS>--registry=http://localhost:8080/ipfs/Qmds3SRV8ABBN6zgQAqPZxHLZDGcURJHYyAZ1AGcNvmsPx

+<EMAIL_ADDRESS>updated 1 package in 0.185s

Which results in the following package.json:
{
  "name": "testing",
  "dependencies": {
    "bignumber": "^1.1.0"
  }
}

and package-lock.json:
{
  "name": "testing",
  "requires": true,
  "lockfileVersion": 1,
  "dependencies": {
    "bignumber": {
      "version": "1.1.0",
      "resolved": "https://registry.js.ipfs.io/bignumber/-/bignumber-1.1.0.tgz",
      "integrity": "sha1-5qsKdD2l8+oBjlwXWX0SH3howVk="
    }
  }
}

But there's an issue there, the resolved url in package.json is a http url to registry.js.ipfs.io, which won't use ipfs to load at all.
Let's update the packument to point to the actual tarball hash on ipfs via the local gateway and readd that to ipfs:
{
   "_id":"bignumber",
   "name":"bignumber",
   // ...
   "versions":{
      "1.1.0":{
         "name":"bignumber",
         "version":"1.1.0",
         // ...
         "dist":{
            "shasum":"e6ab0a743da5f3ea018e5c17597d121f7868c159",
            "tarball":"http://localhost:8080/ipfs/QmeERhULUu7nwgLvxFrnnvJViKqwUxpmswWKzg41ensSYk"
         }
      }
   },
  // ...
}

The updated package-lock.json:
{
  "name": "testing",
  "requires": true,
  "lockfileVersion": 1,
  "dependencies": {
    "bignumber": {
      "version": "1.1.0",
      "resolved": "http://localhost:8080/ipfs/QmeERhULUu7nwgLvxFrnnvJViKqwUxpmswWKzg41ensSYk",
      "integrity": "sha1-5qsKdD2l8+oBjlwXWX0SH3howVk="
    }
  }
}

You can now turn off your wifi and successfully run the installation command again and it "just works™" 🎂
This would be a good place to use ipns, publishing a name for the folder means you can publish new versions (add another version to the packument) or add new packuments to the folder, re-add the whole folder and update the ipns.
This is very similar to how npm-on-ipfs actually works, except uses the local gateway rather than running it's own web server proxy.
In theory if you connect to the npm-on-ipfs swarm and fetch the root of the mfs from https://registry.js.ipfs.io/ you can load packuments from there over the local gateway too:
$ ipfs swarm connect /dns4/registry.js.ipfs.io/tcp/10042/ipfs/QmfKqxieE71QoAchNk5e2MKmvWKjGdUnSifHqq1xZLEzyn
$ npm install<EMAIL_ADDRESS>--registry=http://localhost:8080/ipfs/QmNfmaA4K9G6yWYxJoRhPiYjJvYXMjPMkuuazqGahg2r4S

There's a couple ugly bits when it comes to this being more widely used:

package-lock.json contains urls that point to localhost:8080, if this file gets committed to source control and other people try to npm install without running an ipfs gateway, they may get a confusing error, although @olizilla also mentioned that in some recent version of npm, passing the registry option (or setting it via .npmrc) will ignore the "resolved" field.
setting the registry address to a hash isn't very user friendly, but a DNSLink address would be much nicer: npm config set registry http://localhost:8080/ipns/my_module.mydomain.io

There also needs to be a tool to generate a packument as writing one by hand is very error prone!
extra ipfs-npm commands
Some potential commands that could be built into the ipfs-npm cli:
$ ipfs-npm packument command that generates a packument for a package that's published on ipfs
$ ipfs-npm publish command that publishes to IPFS (npm pack, ipfs-npm packument, put them both in a folder, ipfs add -r and optionally ipns/dnslink name publish)
And a couple extra commands that I thought of whilst experimenting:
$ ipfs-npm alias command that installs it as the default npm in your shell
$ ipfs-npm pin $package command that pins packuments and tarballs for packages you want to keep locally

Some thoughts:

$ ipfs-npm publish

This will conflict with npm publish, since at the moment everything following ipfs-npm is passed to npm/yarn.  Maybe we could have different commands aliased by the ipfs-npm module?  E.g. ipfs-npm-publish or something a bit more memorable?

"tarball":"http://localhost:8080/ipfs/QmeERhULUu7nwgLvxFrnnvJViKqwUxpmswWKzg41ensSYk"

Having this sort of thing end up in your lock file doesn't bode well for repeatable builds as things will break if ports change or the daemon isn't running on the current machine, etc, which is why ipfs-npm rewrites them to be https://registry.js.ipfs.io/... URLs
Maybe if the pacote PR gets merged we can rewrite them to ipfs://Qmfoo URLs instead?

$ npm install<EMAIL_ADDRESS>--registry=http://localhost:8080/ipfs/Qmds3SRV8ABBN6zgQAqPZxHLZDGcURJHYyAZ1AGcNvmsPx

I like the simplicity of using the local gateway as the registry but it means we can't rewrite the lock file post-install.  Then again if the pacote PR gets merged, and the registry uses ipfs://Qmfoo URLs in the pacument dist.tarball fields we might not need to rewrite it.

I thought I'd take a stab at making a script that implements a certain amount of Level 3.1 (previously Level 4), here's what I came up with: https://github.com/andrew/ipfs-npm-republish
First npm install it: $ npm install -g ipfs-npm-republish
Then change into a directory with a package-lock.json and run: $ ipfs-npm-republish
This will do the following steps:
1. List dependencies for current directory from package-lock.json
2. Calculate list of packages to be republished
3. create a tmp folder to act as ROOT
4. For each package
  1. Fetch packuments for each package and write to ROOT
  2. For each depended upon version:
    1. download the tarball to ROOT
    2. ipfs add tarball
    3. rewrite the dist.tarball url to a local gateway url with tarball hash
5. ipfs add -r ROOT
6. pin ROOT hash
7. set per-project npm config to use new micro-registry in .npmrc
8. output command to update registry to point to ipfs ROOT hash

The code probably isn't the best and it doesn't handle unexpected errors very well but when it works you do end up with a valid npm registry hosted on IPFS 🎉
Things it doesn't do:

handle any non-https dependencies (it skips git dependencies entirely)
republish offline, it needs to download the packuments from registry.npmjs.org before adding to ipfs
uses IPNS, it's just too slow to be useful right now

It's also small steps towards the ideas in https://github.com/ipfs/package-managers/issues/52 around "portable packages", where you could use ipfs-npm-republish to create a micro-registry for a package and one for an application, then have a function that can merge those two micro-registries together, enabling someone to add the package to the application and generate a new package-lock.json without relying on a traditional registry or proxy at all.

Next step I'm going to look at doing is republishing for a package, which is subtly different than what ipfs-npm-republish currently does, which is to republish only the dependencies of an application.
In this case you'll be able to do: $ ipfs-npm-republish react and it'll do the following:

Download the react packument from an upstream registry
Locally run npm install react in a tmp dir to collect the transitive dependencies for that package
Create a micro-registry for both react and it's full dependency list

Then you'll have everything you need to do a command line installation of react from that one micro-registry

As of v1.0.3 you can now republish individual modules directly from npmjs.org:
$ ipfs-npm-republish<EMAIL_ADDRESS>  Added object-assign
  Added loose-envify
  Added prop-types
  Added react-is
  Added react
  Added scheduler
  Added js-tokens

New registry url: http://localhost:8080/ipfs/QmadqAJ9rDUD7zdoyNc12gH4npVGLZN9V6fkybshEHanZz

Use it with the following command

  $ npm install<EMAIL_ADDRESS>--registry=http://localhost:8080/ipfs/QmadqAJ9rDUD7zdoyNc12gH4npVGLZN9V6fkybshEHanZz

As of v1.0.6 of ipfs-npm-republish you can now publish directly to IPFS without needing to first publish to npmjs.org.
Running ipfs-npm-republish publish from the root of a project directory will run npm pack and create a micro-registry for that newly created release along with it's runtime dependencies, which then works independently of npmjs.org even if it's dependencies originally came from there.
Aside from some performance issues on very large dependency trees, the last major area to cover is "update", which would in-effect take an existing IPFS micro-registry, check upstream for dependency updates and then publish a new micro-registry with the updated dependencies.
N.b. "update" in this sense is a little different to using IPNS for a micro-registry as it'll need to support packages from sources outside of IPFS, micro-registries published with IPNS should be auto-updating without any extra work.
This will require storing some more extra metadata in the packuments, which I'm planning on modelling on some of the ideas from https://github.com/ipfs/package-managers/issues/22, being able to follow the providence of the packages to get back to their original publish location, either on a traditional registry or hopefully the IPNS of the micro-registry they were published to.

v1.0.8 of ipfs-npm-republish is out, includes some significant refactoring:

uses base32 cidv1 hashes everywhere
properly handles multiple versions of dependencies
micro-registries are now 30% smaller when created
you can now republish namespaced packages like @typed/foobar

I spoke to @olizilla yesterday about having IPFS desktop install npm-on-ipfs via a microregistry.
This would be pretty neat, IPFS Desktop wouldn't need to include ipfs-npm-republish as a runtime dependency, it can just store a CID (or eventually an IPNS name) to the npm-on-ipfs micro-registry created by ipfs-npm-republish.
There are a couple of bugs before that can work seemlessly:

publishing such a large pile of dependencies is very slow and needs some performance improvements https://github.com/andrew/ipfs-npm-republish/issues/4
js-ipfs has transitive git dependencies, which are currently not published to the microregistry (also those really should be swapped out or properly published to npm anyways) https://github.com/andrew/ipfs-npm-republish/issues/7

Any help on those two bugs would be great!


drivers: wifi: esp32: fix wifi receive callback

The wifi receive callback was being set before the underlying interface was initialised. This resulted in no packets being passed up to station once connected.

There already a PR to fix this:  #55854

@sylvioalves
Whoops sorry, there wasn't when I started debugging it....should have checked before I submitted :)
Good news that it is fixed though!


fix self.filtered_tokens bug that cause an exception for some characters in datestring

I use jalali parser for parse some jalali datetime string in my crawler.  it throws an exception for this string: "۱۳۹۸/۰۶/۳۱ در  ۱۴:۵۲"  because of "در" word. in line 192 of dateparser/parser.py , when use t[1] < 1 , for that word, tokens contain ('د','') and ('ر','') items and for these items, t[1] is str , not int. then it cause an exception. 'در' == "at"

This probably affects _no_spaces_parser as well, so the fix should be either in tokenizer or in both _parser and _no_spaces_parser. Can you have a look at tokenizer, see if you can improve it to support this scenario?
It would also be great to have tests for the fix.

Hi @emadkha, thank you for raising this!
The TypeError you mention was fixed in this PR: https://github.com/scrapinghub/dateparser/pull/622 and it was released within the new version 0.7.4. :tada:
Now you can use:
>>> from dateparser.calendars.jalali import JalaliCalendar
>>> JalaliCalendar("۱۳۹۸/۰۶/۳۱ در ۱۴:۵۲").get_date()
{'date_obj': datetime.datetime(2019, 9, 22, 14, 52), 'period': 'day'}

And it works as expected. I will close this PR but feel free to open it again if your problem persists!
Thanks

P.S: I'm trying to implement a new `jalali` parser to allow us to do this directly:
>>> dateparser.parse("۱۳۹۸/۰۶/۳۱ در ۱۴:۵۲", settings={'PARSERS': ['jalali']})
datetime.datetime(2019, 9, 22, 14, 52)

However, it doesn't work for now. This is the PR: https://github.com/scrapinghub/dateparser/pull/627 if you want to take a look.


create as-proba

The idea is to transform massa/as to a group a multiple independant repos.
We should create as-proba and migrate there the math/probability directory.

Should be started after #38 to reduce potential conflicts


Improve Docker caching of JavaScript dependencies

ADDing the project directory before npm install meant that any change, anywhere in the project directory, would invalidate the Docker build cache for the npm install step. Given that this step involves a number of network requests, and installs npm and bower packages, it ends up being very slow.
Explicitly ADDing bower/npm package config (and the README, which is apparently used for the npm package description) means Docker only invalidates the cache (and, thus, re-runs the npm install) when these files change. This dramatically improves rebuild times (from ~2m30 to <10s) for the majority of changes.

@matharden Are there any other files than those I'm explicitly ADDing in this change we should have in place before we run npm install?

No. Just the ones you've mentioned.

Ran it. Seems very quick.


test(isBrowser): add tests

Per #824, this PR adds some tests for the isBrowser util.  It also fixes the typeof check which forgot to account for null objects.
Tests are run in karma, so we can assert the positive case.  We're utilizing the imports loader to load the module as if both the document and window are each either undefined and null to assert the negative case.

Current coverage is 100% (diff: 100%)

Merging #826 into master will not change coverage

@@           master   #826   diff @@
====================================
  Files         136    136
  Lines        2217   2217
  Methods         0      0
  Messages        0      0
  Branches        0      0
====================================
  Hits         2217   2217
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last update c751fb3...686a0a2


Expand "Resources" page

Add a section on "So you want to open source your project..."
Ex of resource to add:

https://opensource.guide/starting-a-project/

Hey @emmet0r,
I am interested in work on this issue.
Could you provide more details on:

What format and structure should the section follow? (e.g., bullet points, paragraphs, links with descriptions)
Are there other resources or specific topics you'd like me to include in this section? For example:

Licensing guidance
Community building tips
Repository setup guidelines

Should the tone and style match existing sections on the "Resources" page?

Looking forward to your guidance so I can contribute effectively.
Thanks!

Hey @emmet0r I am interested and excited to contribute to your organisation, and i can solve that issue; so can you please provide me the general overview for the issue so that I can proceed with the problem.


Access to camera denied in IE11

I get "Webcam.js error: Access to the camera denied" in IE 11 when running from a web server. If I run the same code on a server running at 192.168.1.x (ie local machine) in the same browser/computer, everything works fine. I checked that flash was set to ask for access, and the IE security settings were set to Medium. Webcam.js is set to force flash.
Is this a bug? It says it's denied even though the camera permission request window never appears.

Seems the issue was the SWF was not preloaded. When preloading it before initializing the webcam object it worked. Race condition?

Wow, that is very bizarre.  I've never experienced that issue before.  I
will try to reproduce once I get my PC working again.
Thanks for the bug report.  How did you preload the SWF?
--
Joseph Huckaby
<EMAIL_ADDRESS>On Fri, Jan 22, 2016, at 01:53 PM, ErikEklund wrote:

Seems the issue was the SWF was not preloaded. When preloading it before initializing the webcam object it worked. Race condition?

—
Reply to this email directly or view it on GitHub[1].

Links:

https://github.com/jhuckaby/webcamjs/issues/148#issuecomment-174064678

Used preloadjs to preload. I tried to recreate this on a test page (only the cam with no preloader and nothing else), on two different external servers, but that worked every time. Might be that I preloaded other stuff in the background while adding the webcam, causing slower loading.
Hard to tell the exact cause of the issue. Feel free to close this bug as it's not reproducable.

I'm having the same issue, but it happens local or remote, and I'm not using preloadjs. The only strange thing is that I'm showing it from a modal

Yeah, It happens when you access domain for the first time and after clearing localStorage

I have same error message.
With flash plugin and a width less than < 214px
Webcam.set({
    width: 200,
    ...
});

It seems container is to small for Flash parameters dialog.
So in this case, flash parameter dialog is not shown.
And we have an error from Webcam.js:

Access to camera is denied

I understand if it would not be fixed but it can help in case of debugging

@emhar I found that the height matters too. 137px failed, 150px worked.

I have that problem too. When I use webcam.js in my website, it works fine at first, but the error "Access to camera denied" occurs when i open the camera for the second time. I still don't know why or how to fix it. Must the swf file be placed in the same category with webcam.js? Please help me and I will be very thankful. @ErikEklund  @jhuckaby

Hello everyone i fixed this issue by using preloadjs. The idea is to attach the camera when the swf file is loaded. I used preloadjs which you can download it here https://www.createjs.com/downloads.
Example
`   var queue = new createjs.LoadQueue(false);
queue.on("fileload", handleFileComplete);
queue.loadFile('/Content/Images/webcam.swf');
function handleFileComplete(event) {
    $("#video").hide();
    Webcam.set({
        swfURL: '/Content/Scripts/webcam.swf',
        width: 320,
        height: 240,
        image_format: 'png',
    });

    Webcam.attach('#cam-video');
    $("div.image-capture-container").on("click", "a.js-capture", function (e) {
        captureImage();
    });
}

`


Getting error "Unable to resolve app config"

When trying to run loweagent, the application does not start.
Input
./loweagent -e libreoffice
Output
[INFO]{config}: Config loaded successfully
[INFO]{main}: Determining program mode from exec param: vlc
[INFO]{main}: Main program name is vlc
[ERR]{main}: Unable to resolve app config

LoWeExposer is active and enabled on Windows. I had built it using build.cmd  using the Developer Command Prompt for VS 2017. The build had completed successfully.
The Windows version is 1803 and Ubuntu version on WSL is 18.04

@playerdefault
You cannot start LibreOffice directly. First your should start X plus a WM.
Please consider these instructions: https://github.com/kpocza/LoWe/blob/master/docs/x.md
Start LibreOffice in the X environment afterwards.
The respective error message isn't referring to the app.config file (LoWeExposer.exe.config) on the Windows side but the fact the LibreOffice app is not configured for direct execution.

Ah. Got it. Thanks. But it would be a useful feature to handle opening applications directly instead of opening an X server.
Warm regards,
Swaraj Mohapatra
Member Technical Staff, Dev
First American (India)

From: PÓCZA Krisztián<EMAIL_ADDRESS>Sent: Friday, August 23, 2019 4:37:45 PM
To: kpocza/LoWe<EMAIL_ADDRESS>Cc: playerdefault<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [kpocza/LoWe] Getting error "Unable to resolve app config" (#12)
@playerdefaulthttps://github.com/playerdefault
You cannot start LibreOffice directly. First your should start X plus a WM.
Please consider these instructions: https://github.com/kpocza/LoWe/blob/master/docs/x.md
Start LibreOffice in the X environment afterwards.
The respective error message isn't referring to the app.config file (LoWeExposer.exe.config) on the Windows side but the fact the LibreOffice app is not configured for direct execution.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/kpocza/LoWe/issues/12?email_source=notifications&email_token=AGLJZ7ECXCMVWB5VMO3SLYTQF7AIDA5CNFSM4IL34CX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD474WNQ#issuecomment-524274486, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGLJZ7A4J3WBNQTFORICRFDQF7AIDANCNFSM4IL34CXQ.


Update edited keyframe's snap mode properly

The edited keyframe was never notified of changes to the animation editor's snap mode, so the keyframe's time property in the inspector always displayed as "time" instead of changing to "frame" when the snap mode was set to "FPS".
I also changed the property's slider's snap increment to 1 when in "FPS" snap mode.

Thanks!

Cherry-picked for 3.1.2.


Version number after checking out a tag and making changes should be scoped to the major-minor version from that tag

When someone checks out a tag and makes changes, the plugin calculates the new version using the latest version overall. Instead, the latest version should be scoped to the major and minor version from that tag. For example, suppose we have tags 2.0.0, 1.2.2, 1.2.1, 1.2.0 and we check out 1.2.0 and make changes. If we bump the patch-version for example, the new version should be 1.2.3 instead of 2.0.1.

PR #43 should take care of this issue

:+1:


IRC: Local Channel Types

The current IRC service limits the 'room' field to the # prefix, which doesn't allow for local server type channels to be used, which are prefixed with &, not #
This also prevents private messaging a specific user, instead of a channel.
In my case, I was going to use the service to announce to a channel named ~#github which signifies it is local to our IRC bouncer.
The easiest way to rectify this would simply be to change line 27 of irc.rb from
rooms   = data['room'].gsub(",", " ").split(" ").map{|room| room[0].chr == '#' ? room : "##{room}"}

to the following
rooms   = data['room'].gsub(",", " ").split(" ")

This will be tough to do since we have a lot of room names without the # prefix now.

Perhaps instead of checking that it starts with #, check if it contains #.
Or perhaps keep a list of valid channel prefixes and compare with that.
Or even add a checkbox to signify that the room name should be left unaltered.


Add Reflect Finance

reflect.finance (RFI) is an innovative Ethereum token that re-imagines the concept of DeFi yield generation
WEB: https://reflect.finance/
ETHERSCAN: https://etherscan.io/token/0xa1afffe3f4d611d252010e3eaf6f4d77088b0cd7
GITHUB: https://github.com/reflectfinance
MEDIUM: https://reflectfinance.medium.com/
TWITTER: https://twitter.com/ReflectFinance
TELEGRAM: https://t.me/reflect_finance
COINGECKO: https://www.coingecko.com/en/coins/reflect-finance

Hi @CaptainStake  - I would like to merge this request but there is a new requirement that the logo has to be in SVG format. Can I ask you to add it as a replacement for the PNG one? Thanks
Also, there is the requirement that the address has to follow the EIP-55 format

Hi @CaptainStake  - I would like to merge this request but there is a new requirement that the logo has to be in SVG format. Can I ask you to add it as a replacement for the PNG one? Thanks
Also, there is the requirement that the address has to follow the EIP-55 format

Hi @xrn thanks for your time on this I have added the SVG & updated the contact-map.json do you need anything else?
Thank you

Hi @xrn thanks for your time on this I have added the SVG & updated the contact-map.json do you need anything else?
Thank you

@CaptainStake address is still not EIP-55 format :)

@CaptainStake address is still not EIP-55 format :)

@xrn apologies, please see update, is that correct?

@xrn apologies, please see update, is that correct?

@xrn thank you for your help and advice. Have a good new year, quick question how long does this data take to pull through to the front end on metamask in your experience?

@xrn thank you for your help and advice. Have a good new year, quick question how long does this data take to pull through to the front end on metamask in your experience?

RFI has to be included in the new release of this repository and then in the new release of MetaMask - it can take the next 2-3 weeks.

RFI has to be included in the new release of this repository and then in the new release of MetaMask - it can take the next 2-3 weeks.


Specify additional path for Dogfile

dog search for Dogfiles.yml in current directory, but user can specify a different path.

We could use -f /path/to/Dogfile.yml

I've thinking about this and my current opinion is that it doesn't make sense.
If directory == project, then there is no reason to point to a file. Why not point to a directory then? Because I don't think it's necessary if we do an analogy with other project-based tools like git.


Add LICENSE files to releases of individual crates

Hi there!
In order to give proper attributions for any crates I use, I use the cargo about tool. This automatically gathers the licenses for each (transitive) dependency used. This tool is currently failing for all crates in this repository, as the LICENSE file is situated in the root of the repository and is therefore not included in the bundles that are pushed to crates.io.
I've gone ahead and manually elaborated the licenses in my project for now, but it'd be great if you could consider adding the licenses to the releases of the individual packages too.
Thanks for all the work on rust-minidump!

I think this might be useful for cargo-deny too.

Done

Thanks!


SSO & API Roles and clients

We use SSO to login to Jamf, and now it appears that we can't use MUT anymore. I tried creating an API client and assigning some roles, but I get an error when it tries to get the token. Are the new API roles and clients supported? If not, what is the planned timeline to support them? MUT has been a life saver when adding thousands of machines to static groups for mass deployments!

Same issue!  I found this  but creating a different account is not allowing me to login.

Same issue! I found this https://community.jamf.com/t5/jamf-pro/mut-login-with-sso-issue/td-p/290151 but creating a different account is not allowing me to login.

Our security had us get off local accounts and switch to SSO. I was able to create a local Jamf account and get it working, but you would Jamf's own tool would support their new API methodology.

SSO logins are still working for us with v6.2.1.


Upload file to hdfs very slow.

version: 3.11.0,3.12.0
Upload file to hdfs very slow.   Other users can not browse the HUE UI while uploading a large file.

Could you quantify more, e.g. how large is the file, for all the files or just certain files, where is Hue, where is HDFS, what is Hue CPU at this time?
We are planning to test 20GB file upload soon, so we could test for that too.

200M，HUE CPU > 100%

With SSL enabled?

I have same trouble.
Without SSL.

+1,also met with this issue,it is too slow to upload just 180M jar


springboot3中dto校验注解报错

Annotation whose simple name is "Null" but qualified name is not "javax.validation.constraints.Null"
springboot3中已改为jakarta.validation.constraints

Try 0.8.132