Use regular pip install for torch+cpu package; Deprecate light-the-torch

cool! Curious what the difference between light-the-torch and regular pip install is?

light-the-torch can not specify the torch version, which is a tricky when matching sentence-transformer and other ml library packages.


Run flake8 on CI

Add flake8 to Python requirements
Remove empty lines in imports
Add docstrings to tests
Run flake8 on CI

@ablbot autosquash


Update README.md

Updated README file for the repo
p.s idk the use of file so have left some places empty so either tell me the purpose or add it yourself before merging this pr.

Also it would be helpful if hacktoberfest-accepted label was added to this pr.

Hi sorry to bother you but if you could pls tell me the reason that it was marked invalid it would be a grate help in that improving my future contributions

PR does not follow contributing guidelines. Thanks for showing interest in project.
Please read CONTRIBUTION.md for more details.


[WIP] Re-enable Windows build

The PR updates the CMake-based buildsystem by adding and removing the files that changed from Ipopt 3.13 to 3.14 .
Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

The PR is ready for revidew @conda-forge/ipopt .


resultFormat name in camel case

Description
This PR simply adds a camel-case name for ResultFormat which will be used in its toString.

This PR has:

[x] been self-reviewed.

[ ] using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)

[ ] added documentation for new or modified features or behaviors.
[ ] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[ ] added or updated version, license, or notice information in licenses.yaml
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[x] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
[ ] added integration tests.
[ ] been tested in a test Druid cluster.

@suneet-s nope, this PR just changes the display name of the enums. Jackson seems doing some magic somewhere that converts the string to ResultFormat no matter what the letter case is in the string. I added some test for it.


Incorrectly parsed Html

Using the AngleSharp html parser on the file below causes an invalid attribute node to be created.
The attribute name is something line "\\documentary".
(Btw, the content is from a news article in the Irish Times.)
https://www.dropbox.com/s/9joo87xf05ssynw/error_in_attribute.html?dl=0

Thanks for the report - I will investigate this issue.

Hm I cannot reproduce this issue. Can you confirm that the following selector gets the element which causes the possible problems: document.QuerySelector("img.img-responsive")?
I pretty much compared AngleSharp's result with the current results delivered by the Blink engine (Opera 28) and both are the same. Am I missing something?

Yes, that's the one. It has an attribute named documentary." that includes the period, backslash and quote. I'm using the nuget assembly, version <IP_ADDRESS>131. Is that too old?

I updated the assembly and verified that the same problem occurs with 0.8.1 as well.
Incidentally, I'm reading the file with
var html = File.ReadAllText(filename).
And parsing with an empty Configuration object.

It's supposed to be like that. So this is not an issue, but rather one of HTML's "features".

Just so I understand, could you explain this a bit more please?

Well, what else is there to say. I could write about tokenization in HTML5 documents, but all you need to know is that the given snippet that is responsible for the image element generation contains a dot and a backslash, which are legal characters in an attribute name. Also quotation marks are allowed. However, quotation marks (among some other characters) are parse errors.
These errors will never result in an exception or anything bad, but are indications that the page might not result in the desired tree.
HTML5 contains a lot of "features" that are included to be as backward compatible (not only with HTML, but also with former HTML error correction which was freely implemented by browser vendors, as there was no official error correction) as possible.

Understood. Some of my code converts the parsed Html into Xml (i.e. x-html) so I guess I'll have to eliminate tags that are unrecognized.


abtasty specific ci

will fix timeframe resolution in another mr, the changes were introduced elsewhere and are important.


LinearBasis + RandomRBF_ARD breaks, hypers dimension inconsistent

Probably because RandomRBF_ARD takes a list, not a vector of hyperparameters


Dependency conflict

I am not sure what is the reason but I am suspecting a Newtonsoft dependency conflict. I have an asp.net core rc2 web app (.net framework) and a class library with entity framework core installed. When I run the app I get following error
An exception of type 'System.IO.FileLoadException' occurred in Microsoft.Extensions.Configuration.FileExtensions.dll but was not handled in user code

Additional information: Could not load file or assembly 'Newtonsoft.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

You can find the app here
https://github.com/pantonis/AspNetRC2EFCore

Managed to reproduce it

@davidfowl @anurse can you guys take a quick look at this? Should this move to the CLI repo? Or tooling?

BTW I set up a quick mtg for Monday to discuss this.

@pantonis we looked into this issue and it turns out to be an issue with .NET CLI and NuGet.
I moved the bug to here: https://github.com/dotnet/cli/issues/3205
Thanks,
Eilon

Is there any workaround? I m currently blocked and cannot start working on my project. Deadlines are pushing me.
Thanks.

@pantonis I think that if you wrap the project manually by creating your own project.json that just includes a reference to the bin/*.dll file, you can then reference that from your main app's project.json file. The problem you're encountering here is due to the project type reference, which is where the NuGet/.NET CLI bug gets tripped up and doesn't know which "other" DLLs to grab from the bin folder of the csproj.

@Eilon project.json in a .net class library?

@pantonis you'd have something like this:
/src/ClassLibrary/
    MyProj.csproj
    packages.config
/src/ClassLibraryWrapped
    project.json (that points to ../ClassLibrary/bin/Release/MyProj.dll)
/src/MyWebSite
    project.json (that points to ClassLibraryWrapped)

The /src/ClassLibraryWrapped should be a Class Library (.NET Core)?

Thanks.
I have more than 10 class libraries. This will cause me a mess. Please fix the problem as soon as possible because I think the majority of people will have same problem. I already saw a lot of people complaining on the same problems with .csproj and .xproj incompatibilities.

@pantonis indeed, I agree this bug is very cumbersome to work around. I recommend adding a comment to https://github.com/dotnet/cli/issues/3205 to further voice your urgency.

Hi all, is this problem resolved yet? Thanks.

This f'in ridiculous! I've now spent the entire afternoon trying to understand why a reference added using the "Add Reference" in Visual Studio works, yet simply adding the example same declaration directly in the project.json doesn't.

@sayedihashimi @BillHiebert @barrytang do you guys know the right place to track the status of this work? The Tooling repo? A CLI repo? Another place?

Ah, it seems that https://github.com/NuGet/Home/issues/2865 is the right place to track the status of this fix. Please add your thoughts to that issue if they're not already tracked there. Thanks!


MOSEK with GitHub action?

Would be nice to be able to use the MOSEK solver with GitHub actions. For instance, that a license is not required if MOSEK is used in a workflow launched by a GitHub action. I do not know whether this would be feasible?

I doubt that is possible.
søn. 18. jul. 2021 13.23 skrev Guillaume Berger @.***>:

Would be nice to be able to use the MOSEK solver with GitHub actions. For
instance, that a license is not required if MOSEK is used in a workflow
launched by a GitHub action. I do not know whether this would be feasible?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MOSEK/Mosek.jl/issues/206, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACOAE4MHGT4REVTYEEXOXPTTYK2UTANCNFSM5ASBPRJA
.

Ok. Good to know...

This is an issue that has been raised before. It is possible to use most MOSEK functionality without a license by using optimizermt instead of optimize with a public MOSEK solver server. http://solve.mosek.com is free for problems of limited sizes.

@ulfworsoe Thanks for the complemented answer. Is there a way to use the MOSEK solver server with JuMP? If yes, would you have an example where this is done? Thank you!

I think that should be possible.
When creating the Optimizer, you have to define a fallback optimizer - you can take a look at the tests here: https://github.com/jump-dev/MosekTools.jl/blob/master/test/runtests.jl
I should mention that the solve.mosek.com only accepts small problems and imposes a quite short time limit, so it's only really practical for testing and toy-sized problems. I mention this because some of the JuMP test problems turned out to be too large.

Thank you very much for the answer! I will try this. Good to know it works only for really small sized problems...


Improve platform specific gem resolution

What was the end-user problem that led to this PR?
Platform specific gems aren't resolved when platform specific gems are conflicted.
For example, in the following situation, foo-1.0.0-x64-mingw32 that requires bar<1 is conflicted because there is no bar<1. Without this change, Bundler raises a conflict error. But users can use foo-1.0.0 (no x64-mingw32) in this situation. With this change, Bundler resolves to foo-1.0.0 (no x64-mingw32).
@index = build_index do
  gem "bar", "1.0.0"
  gem "foo", "1.0.0"
  gem "foo", "1.0.0", "x64-mingw32" do
    dep "bar", "< 1"
  end
end
dep "foo"
platforms "x64-mingw32"

See also #6247. This change includes the specs that were added in #6247.
What was your diagnosis of the problem?
Not platform specific gem (foo-1.0.0 in the above case) isn't tried to be resolved when platform specific gem (foo-1.0.0-x64-mingw32 in the above case) is available.
What is your fix for the problem, implemented in this PR?
In this PR, not platform specific gem (foo-1.0.0 in the above case) is also tried to be resolved even when platform specific gem (foo-1.0.0-x64-mingw32 in the above case) is available. Priority is "platform specific gem" -> "not platform specific gem". So platform specific gem is usable, platform specific gem is used. Not platform specific gem is used as fallback.
search_for represents this. Here is the search_for specification:
https://github.com/bundler/bundler/blob/master/lib/bundler/vendor/molinillo/lib/molinillo/modules/specification_provider.rb#L11-L13

Search for the specifications that match the given dependency. The specifications in the returned array will be considered in reverse order, so the latest version ought to be last.

Why did you choose this fix out of the possible options?
I choose this fix because this is based on Molinillo's specification.

Oh, I need more codes....

I've cherry-picked the commit in #7526 to fix unrelated CI failure.

Umm. I need to care specific_platform feature flag.

Thanks so much @kou!
This is awesome!! I'll review this shortly. Even if this is a bug fix, I think it might be worth releasing it as 2.2.0 together with other platform improvements:

Windows CI and test fixes.
I'd like to considered reintroducing https://github.com/bundler/bundler/pull/7215, since I only reverted it due to these multiplatform resolution issues. Could you give me your opinion about it if you have time?

Thanks again for fixing this, I did try fix it myself in the past but never quite finished the work because it was hard :sweat_smile:.

I'd like to considered reintroducing #7215, since I only reverted it due to these multiplatform resolution issues. Could you give me your opinion about it if you have time?

Sure!
I confirmed #7215 and related issues: #7329, #7315, brianmario/mysql2#1064 and rails/rails#37224
We need one more improvement to reintroduce #7215. The following example should be passed:

I tried this PR with RubyInstaller-2.7.0-1-x64 on Windows Server 2016. It succeeds to run the new resolver specs, but bundle install still fails to resolve the following Gemfile in real world:
c:\Users\kanis\bundler>cat Gemfile
source "https://rubygems.org"
gem "ffi"

c:\Users\kanis\bundler>bundle install
Fetching gem metadata from https://rubygems.org/..........
Resolving dependencies...
Using bundler 2.2.0.dev
Fetching ffi 1.11.3 (x64-mingw32)
Installing ffi 1.11.3 (x64-mingw32)
Gem::RuntimeRequirementNotMetError: ffi requires Ruby version >= 2.2, < 2.7.dev.
The current ruby version is <IP_ADDRESS>.
An error occurred while installing ffi (1.11.3), and Bundler cannot continue.
Make sure that `gem install ffi -v '1.11.3' --source 'https://rubygems.org/'`
succeeds before bundling.

In Gemfile:
  ffi

I verified that the new code paths are actually called.

Thanks both so much :purple_heart:!
Just to make sure, does the remaining failing test case mentioned by @kou correspond to the realworld failing example found by @larskanis? It seems to me that the first one has an explicit maximum required ruby, but in @larskanis' case the upper bound is somehow being incorrectly considered.

@kou I made the Windows CI check in master required,so if you rebase we can make sure that everything current passing is still passing on Windows, and I think with this patch we might be available to unskip some pending specs on Windows. For example, in spec/install/gems/resolving_spec.rb and spec/install/gemfile/platform_spec.rb.
Also, @larskanis, since the case you mention looks very simple, I guess that'd be a regression caused by this PR, or is it something already not working?

@deivid-rodriguez The error message above is exactly the same as on current bundler-2.1.2. It's no regression, but it doesn't do what the PR is supposed to do.
My expectation was, that with this PR the platform=ruby version of the gem is selected while Resolving dependencies..., but for some reason it isn't, so that the platform=x64-mingw32 version is fetched. That unsurprisingly then fails at the install step.

Right, and the current workaround people use to install that Gemfile under Windows is the force_ruby_platform config I guess?

Yes, it works with force_ruby_platform, but then doesn't consider platform=x64-mingw32 any longer for any gems.

This is not a bug of resolver. This is a bug of Bundler::CompactIndexClient#parse_gem.
We need the following patch:
diff --git a/lib/bundler/compact_index_client/cache.rb b/lib/bundler/compact_index_client/cache.rb
index f6105d3bb3..0dae227508 100644
--- a/lib/bundler/compact_index_client/cache.rb
+++ b/lib/bundler/compact_index_client/cache.rb
@@ -95,18 +95,52 @@ module Bundler
       def parse_gem(string)
         version_and_platform, rest = string.split(" ", 2)
         version, platform = version_and_platform.split("-", 2)
-        dependencies, requirements = rest.split("|", 2).map {|s| s.split(",") } if rest
-        dependencies = dependencies ? dependencies.map {|d| parse_dependency(d) } : []
-        requirements = requirements ? requirements.map {|r| parse_dependency(r) } : []
+        dependencies, requirements = rest.split("|", 2) if rest
+        dependencies = dependencies ? parse_dependencies(dependencies) : []
+        requirements = requirements ? parse_requirements(requirements) : []
         [version, platform, dependencies, requirements]
       end

+      def parse_dependencies(string)
+        string.split(",").map {|d| parse_dependency(d) }
+      end
+
       def parse_dependency(string)
         dependency = string.split(":")
         dependency[-1] = dependency[-1].split("&") if dependency.size > 1
         dependency
       end

+      # Parse the following format:
+      #
+      #   line = "checksum:#{checksum}"
+      #   line << ",ruby:#{ruby_version}" if ruby_version && ruby_version != ">= 0"
+      #   line << ",rubygems:#{rubygems_version}" if rubygems_version && rubygems_version != ">= 0"
+      #
+      # See compact_index/gem_version.rb for details.
+      def parse_requirements(string)
+        requirements = []
+        checksum = string.match(/\A(checksum):(\h+)/)
+        if checksum
+          requirements << [checksum[1], [checksum[2]]]
+          string = checksum.post_match
+          string = string[1..-1] if string.start_with?(",")
+        end
+        rubygems = string.match(/(rubygems):(.+)\z/)
+        if rubygems
+          string = rubygems.pre_match
+          string = string[1..-1] if string.start_with?(",")
+        end
+        ruby = string.match(/\A(ruby):(.+)\z/)
+        if ruby
+          requirements << [ruby[1], ruby[2].split(/\s*,\s*/)]
+        end
+        if rubygems
+          requirements << [rubygems[1], rubygems[2].split(/\s*,\s*/)]
+        end
+        requirements
+      end
+
       def info_roots
         [
           directory.join("info"),

I think that the fix should be done by a separated pull request.

https://github.com/bundler/bundler/pull/7554 for Bundler::CompactIndexClient#parse_gem.

For example, in spec/install/gems/resolving_spec.rb and spec/install/gemfile/platform_spec.rb.

Trying.

We could unskip 2 examples in spec/install/gemfile/platform_spec.rb.

Nice, that's something :sweat_smile:.
So, let me see if I got this:

The realworld example about the ffi gem is not reproducible with our test setup, but it will be fixed by #7554.

The missing functionality to be able to reintroduce #7215 would be to get the example you mentioned in https://github.com/bundler/bundler/pull/7522#issuecomment-571026880 passing. This is a different case from the ffi's realworld example and that work is yet to be done.

Is this correct?

The realworld example about the ffi gem is not reproducible with our test setup, but it will be fixed by #7554.

Yes.
The following example with Ruby 2.6 on Windows may reproduce the ffi gem case:
gemfile <<-G
  source "https://rubygems.org"

  gem 'ffi', '<= 1.11.3'
G

bundle! :install

But I didn't try it.

The missing functionality to be able to reintroduce #7215 would be to get the example you mentioned in #7522 (comment) passing. This is a different case from the ffi's realworld example and that work is yet to be done.

Yes.
I think that the work should be done by a separated pull request. #7215's use case is different from this. #7215 always uses all platforms. This improves resolution for "ruby" platform and other specific platform.

Thanks for your comments. We got better names.
Once CI is green, could you merge this? Then could you also review #7554?

I did another try with this PR and #7554 merged together. It fails with a real world example:
$ cat Gemfile
source "https://rubygems.org"
gem "ffi", "~> 1.11"
$ ruby -Ilib exe/bundle install
Fetching gem metadata from https://rubygems.org/..........
Resolving dependencies...
Bundler found conflicting requirements for the Ruby  version:
  In Gemfile:
    Ruby  x64-mingw32

    ffi (~> 1.11) x64-mingw32 was resolved to 1.11.3, which depends on
      Ruby  (>= 2.0)

$ ruby -v
ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x64-mingw32]

If I omit "~> 1.11" from the Gemfile, it installs ffi-1.9.25, which was the last version without ruby version constraint.
I think the same error can be simulated by changing a spec slightly:
diff --git a/spec/resolver/platform_spec.rb b/spec/resolver/platform_spec.rb
index 9a97a2c67c..134f18425a 100644
--- a/spec/resolver/platform_spec.rb
+++ b/spec/resolver/platform_spec.rb
@@ -69,7 +69,9 @@ RSpec.describe "Resolving platform craziness" do
     @index = build_index do
       gem "foo", "1.0.0"
       gem "foo", "1.0.0", "x64-mingw32"
-      gem "foo", "1.1.0"
+      gem "foo", "1.1.0" do |s|
+        s.required_ruby_version = [">= 2.0"]
+      end
       gem "foo", "1.1.0", "x64-mingw32" do |s|
         s.required_ruby_version = [">= 2.0", "< 2.4"]
       end

It fails with the following error, although the change should be irrelevant:
       expected: ["foo-1.1.0"]
            got: ["foo-1.0.0-x64-mingw32"]

Woow, thanks again @larskanis for the thorough testing. I tried to have a look at the new failing spec, and this is what I got:

First thing I noticed when debugging is that there were duplicated spec groups for ruby and rubygems version requirements, one with lower case name and one with uppercase. Not sure where the difference comes from (I would've expected all uppercased?), but downcasing things removed the duplication. This changed nothing regarding the failing spec. Patch is:

diff --git a/lib/bundler/definition.rb b/lib/bundler/definition.rb
index 3e5186039a..876a1d8db8 100644
--- a/lib/bundler/definition.rb
+++ b/lib/bundler/definition.rb
@@ -864,8 +864,8 @@ module Bundler
           concat_ruby_version_requirements(locked_ruby_version_object) unless @unlock[:ruby]
         end
         [
-          Dependency.new("Ruby\0", ruby_versions),
-          Dependency.new("RubyGems\0", Gem::VERSION),
+          Dependency.new("ruby\0", ruby_versions),
+          Dependency.new("rubygems\0", Gem::VERSION),
         ]
       end
     end
diff --git a/lib/bundler/resolver/spec_group.rb b/lib/bundler/resolver/spec_group.rb
index 4ebb747956..ef089ae0ed 100644
--- a/lib/bundler/resolver/spec_group.rb
+++ b/lib/bundler/resolver/spec_group.rb
@@ -116,10 +116,10 @@ module Bundler
         return [] if !spec.is_a?(EndpointSpecification) && !spec.is_a?(Gem::Specification)
         dependencies = []
         if !spec.required_ruby_version.nil? && !spec.required_ruby_version.none?
-          dependencies << DepProxy.new(Gem::Dependency.new("Ruby\0", spec.required_ruby_version), platform)
+          dependencies << DepProxy.new(Gem::Dependency.new("ruby\0", spec.required_ruby_version), platform)
         end
         if !spec.required_rubygems_version.nil? && !spec.required_rubygems_version.none?
-          dependencies << DepProxy.new(Gem::Dependency.new("RubyGems\0", spec.required_rubygems_version), platform)
+          dependencies << DepProxy.new(Gem::Dependency.new("rubygems\0", spec.required_rubygems_version), platform)
         end
         dependencies
       end
diff --git a/lib/bundler/source/metadata.rb b/lib/bundler/source/metadata.rb
index<PHONE_NUMBER>..09171f10dd 100644
--- a/lib/bundler/source/metadata.rb
+++ b/lib/bundler/source/metadata.rb
@@ -5,8 +5,8 @@ module Bundler
     class Metadata < Source
       def specs
         @specs ||= Index.build do |idx|
-          idx << Gem::Specification.new("Ruby\0", RubyVersion.system.to_gem_version_with_patchlevel)
-          idx << Gem::Specification.new("RubyGems\0", Gem::VERSION) do |s|
+          idx << Gem::Specification.new("ruby\0", RubyVersion.system.to_gem_version_with_patchlevel)
+          idx << Gem::Specification.new("rubygems\0", Gem::VERSION) do |s|
             s.required_rubygems_version = Gem::Requirement.default
           end

diff --git a/spec/install/gems/resolving_spec.rb b/spec/install/gems/resolving_spec.rb
index 0e933bfd8e..4d1fb98263 100644
--- a/spec/install/gems/resolving_spec.rb
+++ b/spec/install/gems/resolving_spec.rb
@@ -174,17 +174,17 @@ RSpec.describe "bundle install with install-time dependencies" do
             gem 'require_ruby'
           G

-          expect(out).to_not include("Gem::InstallError: require_ruby requires Ruby version > 9000")
+          expect(out).to_not include("Gem::InstallError: require_ruby requires ruby version > 9000")

           nice_error = strip_whitespace(<<-E).strip
-            Bundler found conflicting requirements for the Ruby\0 version:
+            Bundler found conflicting requirements for the ruby\0 version:
               In Gemfile:
-                Ruby\0 (#{error_message_requirement})#{error_message_platform}
+                ruby\0 (#{error_message_requirement})#{error_message_platform}

                 require_ruby was resolved to 1.0, which depends on
-                  Ruby\0 (> 9000)#{error_message_platform}
+                  ruby\0 (> 9000)#{error_message_platform}

-            Ruby\0 (> 9000), which is required by gem 'require_ruby', is not available in the local ruby installation
+            ruby\0 (> 9000), which is required by gem 'require_ruby', is not available in the local ruby installation
           E
           expect(err).to end_with(nice_error)
         end
@@ -222,7 +222,7 @@ RSpec.describe "bundle install with install-time dependencies" do
         gem 'require_rubygems'
       G

-      expect(err).to_not include("Gem::InstallError: require_rubygems requires RubyGems version > 9000")
+      expect(err).to_not include("Gem::InstallError: require_rubygems requires rubygems version > 9000")
       expect(err).to include("require_rubygems-1.0 requires rubygems version > 9000, which is incompatible with the current version, #{Gem::VERSION}")
     end
   end
diff --git a/spec/resolver/basic_spec.rb b/spec/resolver/basic_spec.rb
index 57897f89b4..63fefec560 100644
--- a/spec/resolver/basic_spec.rb
+++ b/spec/resolver/basic_spec.rb
@@ -91,7 +91,7 @@ RSpec.describe "Resolving" do
     @index = build_index do
       gem "mail", "2.7.0"
       gem "mail", "2.7.1.rc1"
-      gem "RubyGems\0", Gem::VERSION
+      gem "rubygems\0", Gem::VERSION
     end
     dep "mail"
     @locked = locked ["mail", "2.7.0"]
@@ -169,10 +169,10 @@ Bundler could not find compatible versions for gem "a":
         s.required_ruby_version = "~> 2.0.0"
       end

-      gem "Ruby\0", "1.8.7"
+      gem "ruby\0", "1.8.7"
     end
     dep "foo"
-    dep "Ruby\0", "1.8.7"
+    dep "ruby\0", "1.8.7"

     deps = []
     @deps.each do |d|
diff --git a/spec/support/indexes.rb b/spec/support/indexes.rb
index dc6e0bd1e9..83d8fc4180 100644
--- a/spec/support/indexes.rb
+++ b/spec/support/indexes.rb
@@ -77,7 +77,7 @@ module Spec
         gem "rack-mount", %w[0.4 0.5 0.5.1 0.5.2 0.6]

         # --- Pre-release support
-        gem "RubyGems\0", ["1.3.2"]
+        gem "rubygems\0", ["1.3.2"]

         # --- Rails
         versions "1.2.3 2.2.3 2.3.5 3.0.0.beta 3.0.0.beta1" do |version|
@@ -414,7 +414,7 @@ module Spec
         gem("b", %w[0.9.0 1.5.0 2.0.0.pre])

         # --- Pre-release support
-        gem "RubyGems\0", ["1.3.2"]
+        gem "rubygems\0", ["1.3.2"]
       end
     end
   end

Then I noticed that when adding the ruby requirement for the foo-1.1.0 (ruby) gem, it was no longer being consider because the only spec group about ruby version requirements was for the x64-mingw32 platform. So I tried adding the Ruby spec group unconditionally with this patch:

diff --git a/lib/bundler/resolver.rb b/lib/bundler/resolver.rb
index 8a95273a0f..7de6920be1 100644
--- a/lib/bundler/resolver.rb
+++ b/lib/bundler/resolver.rb
@@ -150,13 +150,10 @@ module Bundler
       search.each do |sg|
         spec = sg.spec_for(platform)
         next if spec.nil?
-        spec_platform = spec.platform
-        if spec_platform && spec_platform != Gem::Platform::RUBY
-          # Add a spec group for "non platform specific spec" as the fallback
-          # spec group.
-          sg_ruby = sg.copy_for(Gem::Platform::RUBY)
-          selected_sgs << sg_ruby if sg_ruby
-        end
+        # Add a spec group for "non platform specific spec" as the fallback
+        # spec group.
+        sg_ruby = sg.copy_for(Gem::Platform::RUBY)
+        selected_sgs << sg_ruby if sg_ruby
         if platform != Gem::Platform::RUBY
           # Add a spec group for ["non platform specific spec", "platform
           # specific spec"] to resolve a spec for multiple platforms.

That fixed the new failing spec, with the following issues:

It needs the first patch about "casing" to not break other resolver specs, not sure why.
It breaks the following spec:

 $ bin/rspec spec/resolver/platform_spec.rb

Randomized with seed 58895
.............F

Retried examples: 0

Failures:

  1) Resolving platform craziness with conflicting cases reports on the conflict
     Failure/Error: raise "The resolve succeeded with: #{got.map(&:full_name).sort.inspect}"

     RuntimeError:
       The resolve succeeded with: ["bar-1.0.0", "baz-1.0.0", "foo-1.0.0", "foo-1.0.0"]
     # ./spec/support/indexes.rb:48:in `should_conflict_on'
     # ./spec/resolver/platform_spec.rb:170:in `block (3 levels) in <top (required)>'
     # ./spec/spec_helper.rb:112:in `block (3 levels) in <top (required)>'
     # ./spec/spec_helper.rb:112:in `block (2 levels) in <top (required)>'
     # ./spec/spec_helper.rb:77:in `block (2 levels) in <top (required)>'
     # ./spec/support/rubygems_ext.rb:98:in `load'
     # ./spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
     # ./spec/support/rubygems_ext.rb:45:in `gem_load'

Finished in 0.25476 seconds (files took 0.13311 seconds to load)
14 examples, 1 failure

Failed examples:

rspec ./spec/resolver/platform_spec.rb:166 # Resolving platform craziness with conflicting cases reports on the conflict

Randomized with seed 58895

However, it seems to me that the new result is the correct one for this spec... :thinking:

Ah, sorry. I didn't confirm installed ffi gem version.

Not sure where the difference comes from (I would've expected all uppercased?)

Are "Ruby" and "RubyGems" instead of "ruby" and "rubygems" expected? Then it will be fixed by improving Bundler::CompactIndexClient::Cache. https://rubygems.org/info/ffi returns ruby:...,rubygems:... and Bundler::CompactIndexClient::Cache use the "ruby" and "rubygems" as is.
Anyway, we could confirm that #7554 can solve Ruby version problem. Could you merge #7554 first? Then I can send a new pull request to change "ruby" and "rubygems" to "Ruby" and "RubyGems". Then I will rebase this branch and fix this case.

However, it seems to me that the new result is the correct one for this spec... :thinking:

I think so too.
With this improvement, the spec should choose "bar-1.0.0" because "bar-1.0.0-java" isn't usable with both "ruby" and "java". If "bar-1.0.0-java" is used, "baz" is conflicted with "ruby" and "java".

Are "Ruby" and "RubyGems" instead of "ruby" and "rubygems" expected? Then it will be fixed by improving Bundler::CompactIndexClient::Cache. https://rubygems.org/info/ffi returns ruby:...,rubygems:... and Bundler::CompactIndexClient::Cache use the "ruby" and "rubygems" as is.

Anyway, we could confirm that #7554 can solve Ruby version problem. Could you merge #7554 first? Then I can send a new pull request to change "ruby" and "rubygems" to "Ruby" and "RubyGems". Then I will rebase this branch and fix this case.

I don't know if "Ruby" and "RubyGems" or "ruby" and "rubygems" are expected. I think the only user visible difference is the case of the error messages that get printed. In that case, I think I actually prefer lowercase, but since that would be a user visible change (even if minimal) that requires changing expectations, I agree it's better to fix it for now Bundler::CompactIndexClient::Cache to use CamelCase consistently :+1:
Your plan sounds good to me, I'll switch over to reviewing and merging #7554.

I don't know if "Ruby" and "RubyGems" or "ruby" and "rubygems" are expected.

Ah, OK. I misunderstood.

I think the only user visible difference is the case of the error messages that get printed. In that case, I think I actually prefer lowercase, but since that would be a user visible change (even if minimal) that requires changing expectations, I agree it's better to fix it for now Bundler::CompactIndexClient::Cache to use CamelCase consistently +1

I understand. It may be better that we change "Ruby" and "RubyGems" to "ruby" and "rubygemns" when we release Bundler 3.0.0.

I can see how you misunderstood me, since first I said

I would've expected all uppercased?

and then

I don't know if "Ruby" and "RubyGems" or "ruby" and "rubygems" are expected

:rofl:
First sentence I meant that from reading the code i didn't figure out the reason for the discrepancy and thought every spec group would be in CamelCase. In the second, I meant that I'm not sure what the preferred behavior is from an end user point of view.
Anyways, #7554 landed, so now I should be expecting a new PR to normalize spec groups about metadata to be named RubyGems/Ruby consistently (instead of rubygems/ruby), right?

It may be better that we change "Ruby" and "RubyGems" to "ruby" and "rubygemns" when we release Bundler 3.0.0.

Maybe we don't need a major version bump for that tiny UI change, but we either way let's keep the same behaviour for now and we can change that little thing later :+1:.
Thanks again @kou!!

Anyways, #7554 landed, so now I should be expecting a new PR to normalize spec groups about metadata to be named RubyGems/Ruby consistently (instead of rubygems/ruby), right?

Right.
I've created a pull request for it: https://github.com/rubygems/bundler/pull/7570
I'll also improve dependency resolution in this branch.

Ok, so after #7570 being closed, what's the status here? Should we normalize things to always be "ruby/rubygems" instead of "Ruby/RubyGems" in a separate PR using the changes I mentioned in https://github.com/rubygems/bundler/pull/7522#issuecomment-572635007?


can you add hugo_extended_xxx_Linux-ARM64.tar.gz to release resources

can you add hugo_extended_xxx_Linux-ARM64.tar.gz to release resources, thanks

There is another issue about this somewhere, the conclusion there is that it isn't trivial.


Forcing full backtrace when running only one file

I usually run my specs using Guard. When saving a file, the specs auto run using the command bundle exec rspec #{spec_path}.
Even defining the config.full_backtrace = false on my spec_helper.rb this configuration is orvewritten by this code and I end up with a full backtrace.
The full backtrace forces me to scroll up the terminal and brakes the magic of the workflow.
Would be possible to keep my original configuration even when running with only one file?

Even defining the config.full_backtrace = false on my spec_helper.rb this configuration is orvewritten by this code and I end up with a full backtrace.

The code you've referenced is common spec helper code for the spec suites of the various RSpec gems, and isn't intended to be loaded or used by end users.  Have you added a require 'rspec/support/spec' to your code somewhere to load it?  If not, I doubt it's being loaded and something else is probably going on.

Thank you, Myron!
It was being loaded in our rails_helper.rb.  Removed and problem solved!
The magic of the BDD flow is now preserved!


Cleanup Unused Classes

The v2.0 update is an ideal time to remove stuff. Find classes and systems that are largely unused and get rid of them.
Candidates for Removal

The whole Animation subsystem.

Not aware of anyone using it, didn't ever use it myself.
Feels a bit clumsy to programmers and is mostly useless to artists without editor support.
Extending it doesn't seem useful in the wake of far better systems like Spine.

Certain very specialized MathF methods.

GetLinearPrediction, GetLinearPrediction2

Done.


wiff converted mZml

Basic information

My operating system and version:: Windows 10.0
My MZmine version: 3.4.16

What happened
I have wiff file that I have converted by MSConvert in 64bit MzML. When I opened in the 3.4.16 MZMine version a warning appears beside the MzML file: "Some scan were recognized as empty  (no detected peak). The possible reason might be the high noise levels influencing the mzml conversion."
In this context, MzMine is unable to generate metadata file in csv.
The former version MZMine 2.5.3 seems to work on this converting files.
Manu thanks in advance for your support!

I am facing the same issue. MzMine 2.5.3 seems to be able to detect the peaks on these converted files without any problems but MzMine 3 and further versions have not been able to.

Please upload the example file in wiff and mzml format and specify what you did for conversion

Dear mzmine team,
I have uploaded the files in both wiff and mzml format. I have used
MSConvert to convert the wiff to mzml format for the data import and the
screenshot for this steps has been attached.
Steps followed in MzMine:

Importing raw data (A screenshot has been attached  where the scans can
be seen from the raw file in MzMine itself)
Mass detection-> Mass detection; This step was performed for detecting
masses at MS1 and MS2 level.
Feature detection -> MSn feature list builder  (Error message: No scans
detected in selection range: This message pops up for all the files even
though the scans are visible in the raw file section) The screenshot for
the parameters has also been attached.

P.S.: I have also repeated the things with the latest release of MzMine
3.5.0.
MzMine_enquiry.zip
https://drive.google.com/file/d/16Oi-d-12Ij51mjNc3s9K5GwdFE8xaBNW/view?usp=drive_web
Thank you. Regards,
On Mon, May 22, 2023 at 11:24 PM Steffen Heuckeroth <
@.***> wrote:

Please upload the example file in wiff and mzml format and specify what
you did for conversion
—
Reply to this email directly, view it on GitHub
https://github.com/mzmine/mzmine3/issues/1307#issuecomment-1557651130,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2JMYONKTJDF4R5JZYJNUDTXHOR57ANCNFSM6AAAAAAW44HCYM
.
You are receiving this because you commented.Message ID:
@.***>

--
Shubham Upadhyay,
Junior Research Fellow,
Center for Systems Biology and Molecular Medicine,
Yenepoya (deemed to be University), Deralakatte,
Mangalore-575018.
India.

I am also facing the same issue with .wiff files

Hi,
I tested with 3 mzML files from Shubham-Specksy and it worked fine (version 3.9.0). I noticed in the provided screenshot of the MZmine MSn feature list builder parameters that a MS level filter was applied. You can find in the module documentation to not set a MS level filter in the Scan filter. Furthermore, I noticed you are filtering for centroid spectra in a dataset that looks like profile data.
@Sehrawatsurender, can you check if you also apply these filters?

I have wiff file that I have converted by MSConvert in 64bit MzML. When I opened in the 3.9

MZMine version a warning appears beside the MzML file: "Some scan were recognized as empty (no detected peak). The possible reason might be the high noise levels influencing the mzml conversion.

Its just as warning and should not necessary cause problems. Did you successfully create a feature list with the MSn feature list builder?
Make sure to run mass detection first for all MS level.

Thanks @ansgarkorf
I am trying to process the data.
i am new to MZmine, I have a few basic questions

is MZmine only process the DDA data or both DDA or DIA.
how to choose a library, if someone acquired on QTOF, can he still use MoNA-export-LC-MS-MS_Positive_Mode or MoNA-export-All_LC-MS-MS_QTOF library from mass bank, or can we use mulltiple libraries.

If you are new to MZmine I recommend to have a look at the documentation page:
https://mzmine.github.io/mzmine_documentation/
To facilitate an easy introduction to MZmine data processing we have created a wizard to setup workflows/batch files.
https://mzmine.github.io/mzmine_documentation/wizard.html
In the wizard you can switch between DDA and DIA.
In the annotation tab you can add multiple libraries at the same time.

@Shubham-Specksy sorry this issue wasnt addressed earlier. If you are still interested in using the module can you please check if my suggestions work for you? Thanks!


Clarify Config Source Ordering Effects

Fixes #303 @Rick-Anderson

:shipit:

@rachelappel

@rachelappel  looks good :shipit:


add BigQuery.fromServiceAccountJson

This fixes some of the issues in https://github.com/seratch/bigquery4s/issues/5 - namely, making it possible to connect with a service account json credentials file.
I tested it locally by building the jar and including it in my project. Then this works:
val bq = BigQuery.fromServiceAccountJson("/tmp/service_account.json")
val jobId = bq.startQuery("some-project", "SELECT * FROM some_table")
val job = bq.await(jobId)
val rows = bq.getRows(job)
val output = rows.map(_.cells.map(_.value.orNull).mkString(",")).mkString("\n")

Thanks, LGTM.


RFC: Release process

TODO

[ ] Decide what to do about each of the review comments
[ ] Merge as a draft

RFC

Feature Name: release_planning
Start Date: 2020-09-14
Design PR: ZcashFoundation/zebra#0000
Zebra Issue: ZcashFoundation/zebra#0000

Rendered.
This is a version of the notes I posted in slack for preliminary
discussion, slightly reformatted to fit the Zebra RFC template.
@yaahc suggested I post them as an RFC to have a concrete proposal for
discussion.
Unanswered Questions

Q: Do we want to create a nix pkg?
A: No, Nix release timelines are every 6 months, which is incompatible with Zcash's current 6 month network upgrade cycle. Our users would be stuck on Nix unstable. (Nix doesn't support having some packages on unstable very well.)

I wrote up a bunch of technical ideas on how to automate the releasing when a human provides the appropriate information and signals 'go' in this ticket, I can suggest inline with the RFC later
https://github.com/ZcashFoundation/zebra/issues/755

I think as part of this RFC we should investigate the tools available in the ecosystem for managing releases for rust projects. So far I know of two such tools, though I'm sure there are more. Here's the summary of their features as I know them, though I'm sure my explanations are incomplete.

cargo release => run as a cli locally, automatically increments version, creates commit, publishes, creates tag, bumps version again to next_version.alpha-0 and creates a second commit, then finally pushes commits and tag to github. Has support for replacements on release for doing things like updating the CHANGELOG.md or similar files on release.

@anp's automation for moxie => runs in CI, checks version number in Cargo.toml and checks to see if it has already been published, if not it publishes and tags that commit as a new release.

A barebones example of using a manually triggered workflow to run cargo-release (this doesn't include the second part of pushing the new commits back to repo)
https://github.com/dconnolly/zebra/blob/main/.github/workflows/release.yml

:+1: to checking out what tools already exist.  I have some personal hesitation about the risks of complex automation (i.e., in general my preference is to have a simpler 80-90% solution than a more complex 100% solution) because of experiences with building something complex and then having it break, but I have no particularly strong feelings about any specific solutions.  To me the highest priority is having something that's reliable and easy so that we can release often and with confidence (per https://github.com/ZcashFoundation/zebra/pull/1063#discussion_r488545704).
It might be useful to ask @hawkw for advice on what's worked well / not well for tokio and tracing.

Any more comments on this one? Looks like it could be ready to merge soon!

From discord, @dconnolly made our first alpha release by running the following commands
git fetch origin
git checkout main
git rebase origin/main
git tag -a v1.0.0-alpha.0 -m "<message>"
git push origin --tags

We decided to merge this RFC as a draft, see #1963 for the next steps.


Add method column_values to MiqExpression::Field

backend part for https://bugzilla.redhat.com/show_bug.cgi?id=1558932
for offering existing values during a typing MiqExpression in expression editor for column which is currently written
limits of returned results will be discussed according to UI needs(cc @PanSpagetka )

Links
https://bugzilla.redhat.com/show_bug.cgi?id=1558932
@miq-bot add_label enhancement
cc @PanSpagetka

@lpichler @gtanzillo what is the status of this PR?

Reviewed this with @lpichler... This PR is the backend part of a new API (PR here) supporting the new expression editor. That work is currently on hold.
I'd prefer to wait on this PR until we can do a review of the new API to make sure we are comfortable with the usage.


Chore/manifest v3

Upgrades manifest as per https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/
To investigate: upgrading to service workers as per https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/

Whoops, PR'd the wrong branch

@emcniece I get an error when I try to load this:
The "background.scripts" key cannot be used with manifest_version 3. Use the "background.service_worker" key instead.

Well... I guess we're forced to explore the service worker conversion now instead of later in that case.

no rush

@emcniece I am going to close this and we can take a look at it ASAP. I've gotta figure out how the service worker things works too.

https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/

@emcniece I updated the code so now it builds. But currently the waveform display is broken by manifest V3. Take a look at it if you have any time. I'll take a look as well.


Use --if-exists option with dropdb

This change adds a flag to the dropdb command so that we don't issue
an error if the local development database doesn't exist when we try to
drop it. A notice is issued by PG, but execution will continue.
PG docs: https://www.postgresql.org/docs/9.3/static/app-dropdb.html
cc: #137

Yeah, I would love to build an "integration" suite that ran these commands against a fake shell that recorded the results. I have to run the utility against a real database before I release to have confidence that everything's in order.


Load a project catalog by default, allow user to override.

The default catalog are projects derived from popular getting started guides.  There are some projects, e.g. graphql, native, that do not have getting started guide but can be included.
The url/name for the default catalog
spring catalog add gs https://github.com/rd-1-2022/spring-gs-catalog

Allow the user to override the default by setting the property spring.cli.project.catalog.default-url and spring.cli.project.catalog.default-name

Added in 081a76e3e076504eacd0368e390dabcc8a4658ce
docs updated


Bump crossfont to 0.7.0

I think no changelog is required for this one.

I think no changelog is required for this one.

Yep, no need to worry about that, the CI step is there just because I constantly forget to ask people to fill in the changelog :smile:

Thanks!


We should advertise the tipping/link to the user for lnpage

https://twitter.com/theguyswann/status/1433934882221273091?s=21
maybe have a link for it in the settings page so people are aware of this option

I have a working prototype, so to speak, on this [branch] (https://github.com/danwebb1/galoy-mobile/tree/feature_advertise_copy_tip_link). I am having environment issues with Android locally so I have to deal with that when I get free time. Needs to be tested on Android and polished but its close. If anyone else can finish this off quickly, feel free to use or lose what I started!


Suggestions

Here are some possible changes you might want to consider
The third commit is a bit heavy as it switches to a work stealing based approach but the rayon crate makes it super easy to express (the hard part actually becomes the visual progress reporting)
This approach lifts some of the synchronization burden you previously had:

No more need to share a boolean atomic to notify workers to abort their current work
No more 'static restriction for the things shared between the threads. This avoids having to allocate a new starts_with String for each worker and makes Arcs useless
The progress reporting logic can stay external, it doesn't have to intrude in the actual computation

The last commit improves the performance by a lot
you were previously recreating a new Secp256k1 instance for each Address and running cargo flamegraph revealed that this was the current bottleneck of the algorithm
If you're on nightly you can run cargo bench and you'll see something like this:

@Globidev wow! these are great improvements. I was not aware of cargo-flamegraph or cargo bench thanks for the insight! 🙂


Minor rewording

Overview
Tried to make a couple of sentences parse a little better. Nothing more than a bit of plain Englishing.

@janedallaway Thank you! These improvements are fabulous. :sparkles:
I'm going to merge this pull request. If you spot any other "plain Englishing" to do, we appreciate your help. 💖 :octocat:

Also - it may take a little while for these changes to appear on the site, but don't worry, they'll be there soon!


Problems on the DEC axis for the southern hemisphere

Hi. My name is Armando Leonardo.
Sorry for the English, but I'm using Google Translate to help me.
I live in the southern hemisphere, in Brazil, and I have a problem moving the DEC axis. As expected and described on the website, the DEC axis appears on the LCD -90º. However, when I move it to a target, only the DOWN button obeys, negatively incrementing the value, that is, the OAT only increments values from -91 to -270, when it should implement values from -89 to 0 and 360 to 270.
I've already checked the behavior of the buttons, as per the troubleshooting guidelines, but everything is OK with the buttons.
It seems to me that there is a problem in the programming, which does not include the southern hemisphere, because of the use of the (-) sign.
Would you be able to help me?
Thanks.
https://user-images.githubusercontent.com/43935909/129978168-7f2842cc-11da-4c14-b16e-d7ea4b3424d1.mp4

Hi, what firmware version are you using? Please try with the latest develop code and let me know if it is still an issue: https://github.com/OpenAstroTech/OpenAstroTracker-Firmware/archive/refs/heads/develop.zip.

Hi. I'm using version 1.9.19.
I'll try as you suggested and let you know.
Thanks.

Trishmapow, I did as you directed me.
I installed the new version, 1.9.28, and even installed the new version of IDE Arduino.
Unfortunately it still has the same problem.
I would like to add that in the CTRL, MANUAL SLEWING menu, both the DOWN and UP buttons work normally.
The problem is only the inclusion of the DEC coordinates to move the axis to the target.


The caption of this page is misleading

Caption is misleading there is no actual configuration information on the page. This information is in the equally misleading Docker on Windows section. If the captions was "On prem Log Collector" and "Windows Docker Log Collector" respectively he documentation would be MUCH improved and information easier to get at when using the documentation.
Brgds
Johan Møller

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

ID: 83e0555c-41e5-0ba3-4c4b-f9c386644a72
Version Independent ID: 876888bc-8046-0a25-a0b7-67f938cc45c1
Content: Configure automatic log upload for continuous reports in Cloud App Security
Content Source: CloudAppSecurityDocs/discovery-docker.md
Service: cloud-app-security
Product: ****
Technology: ****
GitHub Login: @shsagir
Microsoft Alias: shsagir

@Alrudin Thanks so much for taking the time to leave us your comment on our documentation. We're researching your issue to update the page based on your suggestions. If relevant, changes will be made in the next possible publish.
We're closing this as an open issue for now, but feel free to continue to comment here as necessary. We appreciate your contribution to our community.


Says "A NEW VERSION IS AVAILABLE" at the top even when on the latest version

Describe the bug
It says there is a new version available when I am on the latest already
Version
v0.44
I am running in docker on my synology NAS

+1, same issue here.

OOps sorry, forgot to update the check, it will clear itself


A serious performance pitfall with set in nopython mode

The following code takes a rather long time (does not finish in a few minutes). I am using 0.26
@jit(nopython=True)
def test():
     x=set([1])
     for i in range(1000):
        x.add(5)
        x.discard(5)
test()

In contrast,
@jit(nopython=True)
def test():
    x=set([1])
    for i in range(1000):
        x.add(5)
test()

takes  12.6 µs per loop in ipython.
@jit(nopython=True)
def test():
    x=set([1])
    for i in range(1000):
        x.discard(5)
test()

takes 10.7 µs per loop in ipython.
Finally,
def test():
    x=set([1])
    for i in range(1000):
        x.add(5)
        x.discard(5)
test()

takes 144 µs per loop in ipython.
So what is going on here?

@pitrou: Can you take a look at this?

Ok, it's not a performance issue, it's a bug in the key insertion logic in the face of deleted entries. Thank you for reporting this, we will be submitting a fix soon.

Hmm, thanks for your prompt response. Numba is a great package. Btw, Is there any technical reason that strings are currently not supported in nopython mode? Does the development team have plans to support strings and dictionaries (in nopython mode) in the future?

For strings, the only limitation is effort to implement the required operations.  We've been focusing on other use cases, but strings are eventually on the todo list.
Dictionaries in nopython mode are more challenging because passing a dictionary into a nopython mode function requires us to unwrap it, but then also ensure changes to the dictionary are visible when the function returns.  Our recent additions of support for lists and sets were an attempt to see how feasible this was with simpler mutable data structures.  It seems to have gone well, and I agree that dictionaries are hugely useful data structures, so you will probably see support in the future, but I don't know when.


Probable first attempt at sponsors controller

@kylekthompson @emilyengle #18
Probably have the auth checks wrong, pls comment

Check update method - might have done that incorrectly.

Fixes #18


Prototype new pages

Prototype out the new wind, hydro, and thermal pages
just put in some h1 and p tags to fill out all the info, it'll be reorganized and finalized by myself later.
If some images that would make good vector art can be found, throw those in there too.

work on the prototype-new-pages branch.
when finished open a PR

@Fake4091 please respond.


Document upload: Invoices

There is a common use-case for me and for business: Attach a receipt/invoice to a transaction.
How I do it: With metadata, like this
2016-10-20 * "Fancy Restaurant" "Business Dinner with Bill Gates" #project-a
    statement: "invoices/Expenses/BusinessDinners/2016-10-20 Dinner Receipt Gates.pdf"
    Expenses:BusinessDinners                      150.00 USD
    Assets:Cash

This differs from the current document upload, and the document feature in beancount, as it does not list this document explicitly in the Journal (different folder than the documents-folder), but adds the PDF as metadata to the transaction and can be viewed directly with the transaction in the Journal.
It would be a very handy feature if we extend the documents drag'n'drop to the Journal, where, when dropped on a transaction, the document is uploaded and the metadata entry is added. There would have to be a separate fava-option for the path to the "invoices"-folder, as it differs from the "documents"-folder (so that the receipts/invoices do not show up as documents in the Journal).
@yagebu Do you think it is possible to add the metadata-entry to the Beancount-file when dragging-dropping the document on a transaction in the Journal?

(I know we are opening Pandora's box when we start implementing features that directly modify the beancount file. But maybe it's worth discussing.)

If I recall correctly, attaching documents to postings has been discussed
previously on the beancount mailinglist. This is something I would find
useful as well. @blais was there some rationale for not supporting this in
beancount itself (besides overloading the metadata)?
It seems fava is becoming a good place for prototyping new features. Would
this be something you'd be interested in adding to beancount after a period
of use in fava to iron out the usage?
On Thu, Oct 20, 2016, 15:51 Dominik Aumayr<EMAIL_ADDRESS>wrote:

(I know we are opening Pandora's box when we start implementing features
that directly modify the beancount file. But maybe it's worth discussing.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-255023692, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAdWBxGK3i3vYrDg1CoWORwYh9VGhm0wks5q1w99gaJpZM4KbxNC
.

--
Best regards,
Daniël Bos
Your government is reading your email. Slow them down with encryption.
My public key: http://goo.gl/gms497 (4096 bit RSA, id EF2D5D91)
Fingerprint  : D8D0 9FBE F075 F709 7B52  2F73 326C 2123 EF2D 5D91

I'm not sure I understand what's missing.
You can already attach metadata to transactions or postings, e,g. doc:
"mydocument.pdf"
If you'd like to generate actual Document directives from those, writing a
plugin should be straightforward for this, and I'd gladly merge that in
Beancount itself.
What more is needed?
On Thu, Oct 20, 2016 at 3:26 AM, Daniel Bos<EMAIL_ADDRESS>wrote:

If I recall correctly, attaching documents to postings has been discussed
previously on the beancount mailinglist. This is something I would find
useful as well. @blais was there some rationale for not supporting this in
beancount itself (besides overloading the metadata)?
It seems fava is becoming a good place for prototyping new features. Would
this be something you'd be interested in adding to beancount after a period
of use in fava to iron out the usage?
On Thu, Oct 20, 2016, 15:51 Dominik Aumayr<EMAIL_ADDRESS>wrote:

(I know we are opening Pandora's box when we start implementing features
that directly modify the beancount file. But maybe it's worth
discussing.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-255023692, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AAdWBxGK3i3vYrDg1CoWORwYh9VGhm0wks5q1w99gaJpZM4KbxNC>
.

--
Best regards,
Daniël Bos
Your government is reading your email. Slow them down with encryption.
My public key: http://goo.gl/gms497 (4096 bit RSA, id EF2D5D91)
Fingerprint : D8D0 9FBE F075 F709 7B52 2F73 326C 2123 EF2D 5D91
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-255029466, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUgkwSpTiVdRADjrHPLeXo4BA1NSCeVks5q1xemgaJpZM4KbxNC
.

I agree that this could be a useful feature but instead of adding metadata, we should simply add Document directives. I don't see how using metadata would offer anything that Document directives can't do. It also seems like it would be much less "idiomatic" Beancount code.
I don't see why there is a need for a different folder, isn't documents/Expenses/... exactly the place where invoices should go?

What I understand Document directives are something entirely different: They represent stand-alone documents that are related to a specific account (not transaction), eg. a Bank-Statement or a contract.
Invoices have to be directly connected to a transaction. Imagine there are two transactions on a specific account on the same day, and two invoices. With just Document directives you could not distinguish which invoices belongs to which transaction.
That's also the reason for two folders: If you just have the Documents folder, all PDFs etc. you drop in there will be displayed in the Journal as stand-alone Documents, and cannot be distinguished from transaction-linked invoices - see the difference above.

What I understand Document directives are something entirely different: They represent stand-alone documents that are related to a specific account (not transaction), eg. a Bank-Statement or a contract.

Invoices are also documents in my view, it's just that in addition to belonging to an account, they are also linked to a transaction. So why not just do that and add a Document entry that's linked to the transaction? Metadata wouldn't be a solution, as it would only a one-to-one relation between transactions and invoices, which is insufficient. Say you pay an invoice in instalments or pay several in one transaction.
It seems to me that for the income statement accounts invoices basically are what the bank statements are for balance sheet accounts. Say you don't have any documents in Expenses/BusinessDinners, what else should be in that folder? Of course, by using documents, having a separate folder for invoices would easily be possible as Beancount allows for multiple documents folders, I just don't see the need as the accounts basically make that distinction.

Invoices are also documents in my view, it's just that in addition to belonging to an account, they are also linked to a transaction. So why not just do that and add a Document entry that's linked to the transaction? Metadata wouldn't be a solution, as it would only a one-to-one relation between transactions and invoices, which is insufficient. Say you pay an invoice in instalments or pay several in one transaction.

Absolutely valid (and necessary) point. The one-to-one relation is not enough, and currently a problem for me as well (as I have some cases where there is a one-invoice-many-transactions scenario).

It seems to me that for the income statement accounts invoices basically are what the bank statements are for balance sheet accounts. Say you don't have any invoices in Expenses/BusinessDinners, what else should be in that folder?

Take my Expenses:Telecommunication:Phone-account for example. I have invoices there (my monthly voice and data plan invoices) and also contracts (changes in my contract, eg. more GB/month, etc., or documentation of correspondence with the Telco support). Having both as Document directives and in the same folder looks weird and wrong to me in the Journal.

Of course, by using documents, having a separate folder for invoices would easily be possible as Beancount allows for multiple documents folders, I just don't see the need as the accounts basically make that distinction.

I think the perfect solution would be to have a separate directive for invoices that works exactly like the Document directive:

You can link them to multiple transactions, as you pointed out.
You could have separate folders for the files.
You could display it differently from Document directives in the Journal (what I am after): Display them with the transaction as something that belongs to the transaction, not just another "standalone"-row in the Journal (you could have this as a second feature as well -> just disable the "Jounal" type by default).

I would be very interested what @blais thinks about this discussion/ideas.

Sure, then just use another documents folder for the invoices. I personally just keep them in the same folder so I'm against forcing this on the user.

I think the perfect solution would be to have a separate directive for invoices that works exactly like the Document directive

I'm very much against this. If it just works like the document directive, it should just be done using the document directive. Everything you list can be done using Document directives. I'd also find this feature way more useful if it supports documents, it could be used to attach your monthly account statement to a balance directive for instance.
@blais: Beancount only supports links (and tags) for transactions. Could we have them for all entry types?

The way I would imagine this to work: You drop a file on an entry (any kind of entry), then the upload dialog will open as normal (so you can select your invoices folder if you want) and then the file is uploaded to the specified folder and a Document entry is entered in the file directly above the entry that the file has been dropped on. A link (maybe the first characters of the entry hash) should then be added to both entries to link them.
(of course all of the above is only possible if tags and links are supported for any entry in Beancount)

The way I would imagine this to work: You drop a file on an entry (any kind of entry), then the upload dialog will open as normal (so you can select your invoices folder if you want) and then the file is uploaded to the specified folder and a Document entry is entered in the file directly above the entry that the file has been dropped on. A link (maybe the first characters of the entry hash) should then be added to both entries to link them.

This would be very close to what I imagine 👍
For a specific account where there are many invoices and some (let's say) contracts, how would you differentiate between them in the Journal? I think it would be helpful (and a bit more tidy) if "linked invoice-documents" are not rendered in the Journal like normal documents (in their own row), but as parts of the transaction row (like metadata), and just "standalone-documents" (like contracts) as normal document rows.

I think it would be helpful (and a bit more tidy) if "linked invoice-documents" are not rendered in the Journal like normal documents (in their own row), but as parts of the transaction row (like metadata), and just "standalone-documents" (like contracts) as normal document rows.

One could tag invoices with, say, #invoice, and then we could provide a way to hide those document entries by default. Maybe this can be done with a more generic "filter" that could have other uses as well. One-to-many and many-to-one would make it hard to link (and display) them with one single transaction. But clicking on the ^link could open an overlay for the "linked entries" so that would be a quick way to access them.

One could tag invoices with, say, #invoice, and then we could provide a way to hide those document entries by default.

Sounds good! There could be other use-cases for this as well.

One-to-many and many-to-one would make it hard to link (and display) them with one single transaction.

I would simply duplicate the information - display the invoice for every transaction if it is a one-to-many.
Maybe a bit too specific, but we could add a filter for the Document entries based on the (root)-directory they are in. Therefore I could choose the "invoices" folder when I upload an invoice, and then hide those in the Journal (and maybe via a setting per default), and when choosing "documents" they are displayed by default as normal documents. ("invoices" and "documents" being two entries for document_root)

Links and tags are now implemented for document directives:
https://bitbucket.org/blais/beancount/commits/6e2b12d043c9
https://bitbucket.org/blais/beancount/commits/5ae910ad5cdf
Thanks @blais for the quick response 🙂

On Sat, Oct 22, 2016 at 12:16 PM, Dominik Aumayr<EMAIL_ADDRESS>wrote:

What I understand Document directives are something entirely different:
They represent stand-alone documents that are related to a specific account
(not transaction), eg. a Bank-Statement or a contract.
Invoices have to be directly connected to a transaction. Imagine there are
two transactions on a specific account on the same day, and two invoices.
With just Document directives you could not distinguish which invoices
belongs to which transaction.

I don't agree with this distinction. I created Document directives just to
they could be listed and rendered in the web interface and found, etc. I do
think they can be associated with particular Postings or Transactions.
Right now, there are two ways they can get created:

explicitly, by the user, with the input syntax.
with the option that searches the filesystem, finds filenames with
dates, and creates the directives from those (that's most of them TBH).

What I'm proposing here, is that the _creation _ of these Document
directives could also be driven by a third method, by inspecting metadata
from a plugin that reads Posting metadata and inserts corresponding
Document directives for particular metadata fields (e.g. doc:
"filename.pdf"), perhaps even a link between the Transaction and the
Document to allow for linking them together and some UI support to list a
transaction's documents. That could be a useful feature.
That's also the reason for two folders: If you just have the Documents

folder, all PDFs etc. you drop in there will be displayed in the Journal as
stand-alone Documents, and cannot be distinguished from transaction-linked
invoices - see the difference above.

I just use a single directory hierarchy.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-255537546, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUgk4P8YXKx5i_Gm3OXnwKdpvStjgFBks5q2jbUgaJpZM4KbxNC
.

Sorry I forgot to email about it
Yes I managed to do this on the train last night
Eventually will make this more comprehensive and make it work for all
directives
HTH,
On Oct 24, 2016 03:39, "Dominik Aumayr"<EMAIL_ADDRESS>wrote:

Links and tags are now implemented for document directives:
https://bitbucket.org/blais/beancount/commits/6e2b12d043c9
https://bitbucket.org/blais/beancount/commits/5ae910ad5cdf
Thanks @blais https://github.com/blais for the quick response 🙂
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-255669179, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUgk-lglrRArt_XhfcS4IdeK-OLlEprks5q3GDNgaJpZM4KbxNC
.

Yes, links and tags for all directives is possible. Idealy that would
ideally be done in concert with the revamp of links and tags as metadata,
which has been discussed a while back.
In the meantime, I could add you a links field for Document directives
easily (with input syntax as well). Let me know if that would be useful.

Sure, then just use another documents folder for the invoices. I
personally just keep them in the same folder so I'm against forcing this on
the user.
I think the perfect solution would be to have a separate directive for
invoices that works exactly like the Document directive
I'm very much against this. If it just works like the document directive,
it should just be done using the document directive. Everything you list
can be done using Document directives. I'd also find this feature way more
useful if it supports documents, it could be used to attach your monthly
account statement to a balance directive for instance.
@blais https://github.com/blais: Beancount only supports links (and
tags) for transactions. Could we have them for all entry types?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-255575223, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUgk-4ao8dV95QExIvWBtJ6I8jTFGClks5q2xaKgaJpZM4KbxNC
.

What I'm proposing here, is that the _creation _ of these Document directives could also be driven by a third method, by inspecting metadata from a plugin that reads Posting metadata and inserts corresponding Document directives for particular metadata fields (e.g. doc: "filename.pdf"), perhaps even a link between the Transaction and the Document to allow for linking them together and some UI support to list a transaction's documents. That could be a useful feature.

I like the idea of not having to explicitly create links between Postings and Documents, but have these be generated automatically from a metadata field on the relevant Posting. This helps avoid having to clutter my source file with Document directives (I have those generated automatically from a document folder).
If you want to manually link, you can, but this way you're not forced to.
One suggestion though, it would be useful if you didn't have to specify the full path in the metadata. If the document can't be found using the specified name, you could "fuzzy" match it based on the account hierarchy of the legs and posting date (similarly as the Document directives are created based on the document folder)
E.g.
2016/10/26 * "Supermarket" "Groceries"
      doc: "receipt.pdf"
  Expenses:Groceries                               10.00 EUR
  Assets:Bank

Would try to locate the Document directive using:

documents/receipt.pdf
documents/Expenses/Groceries/receipt.pdf
documents/Assets/Bank/receipt.pdf
documents/Expenses/Groceries/2016-10-26.receipt.pdf
documents/Assets/Bank/2016-10-26.receipt.pdf

Since the Document directives have already been created, this would be an in-memory exercise, not an expensive disk search.

I like both ideas very much: The automatic generation of the document directives from Metadata (what @blais suggested), and that the folder-paths can be "fuzzy-matched" (what @corani suggested).
@blais Can we already implement a plugin that creates Document-directives based on metadata?

Of course you can do that.
Plugins are designed so users can implement what they need.
I'm not sure of your question: Do you need me to do one?
On Thu, Oct 27, 2016 at 8:36 AM, Dominik Aumayr<EMAIL_ADDRESS>wrote:

I like both ideas very much: The automatic generation of the document
directives from Metadata (what @blais https://github.com/blais
suggested), and that the folder-paths can be "fuzzy-matched" (what @corani
https://github.com/corani suggested).
@blais https://github.com/blais Can we already implement a plugin that
creates Document-directives based on metadata?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-256628845, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUgk9VODG4uUe18pxrirpWg3C_8kLMqks5q4JrlgaJpZM4KbxNC
.

We don't need to create Document directives, that's the beauty of it. We
just need to add the links to match up existing Postings and Documents.
On Thu, Oct 27, 2016, 20:36 Dominik Aumayr<EMAIL_ADDRESS>wrote:

I like both ideas very much: The automatic generation of the document
directives from Metadata (what @blais https://github.com/blais
suggested), and that the folder-paths can be "fuzzy-matched" (what @corani
https://github.com/corani suggested).
@blais https://github.com/blais Can we already implement a plugin that
creates Document-directives based on metadata?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-256628845, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAdWB8fDDiXAYq1k9y5McILraANf1slXks5q4JrlgaJpZM4KbxNC
.

--
Best regards,
Daniël Bos
Your government is reading your email. Slow them down with encryption.
My public key: http://goo.gl/gms497 (4096 bit RSA, id EF2D5D91)
Fingerprint  : D8D0 9FBE F075 F709 7B52  2F73 326C 2123 EF2D 5D91

I'm not sure of your question: Do you need me to do one?

The question was basically about if it is possible to generate document directives with a plugin (didn't know that).
So my updated proposal are three changes:
1. Plugin to convert metadata-fields to Document directives
@blais Would you write a plugin for us that does that? 😇
So simply scan all transactions that have the invoice-metadata field (or any other suiting field-name of your choice), and create a Document directive for each invoice, with a link to the transaction it comes from.
2. Changes to Fava

Add multi-folder-support for drag'n'drop: If you have multiple document_root-folders specified, ask the user before uploading in which folder it should go into.
Add drag'n'drop support for the journal: Drop a document on a transaction.
If dropped on a transaction, add the metadata-field (invoice) with a link to the document to that transaction.

3. Changes to beancount
Add support for "fuzzy-matching" like @corani suggested above: When only a filename is specified in the metadata-field (and Document directive), search different locations based on the Account this is on/in.
@blais What do you think about this change to beancount?

And an addition to the Fava-part: Let the user specify if the plugin should be invoked, eg. if the document directives should be generated. This way, users can opt-out of this functionality.

On Fri, Oct 28, 2016 at 7:14 AM, Dominik Aumayr<EMAIL_ADDRESS>wrote:

I'm not sure of your question: Do you need me to do one?
The question was basically about if it is possible to generate document
directives with a plugin (didn't know that).
So my updated proposal are three changes:

Plugin to convert metadata-fields to Document directives

@blais https://github.com/blais Would you write a plugin for us that
does that? 😇
So simply scan all transactions that have the invoice-metadata field (or
any other suiting field-name of your choice), and create a Document
directive for each invoice, with a link to the transaction it comes from.

I don't mind, but I have other more important changes to bring in. Might
take a bit of time.
I'll put it on the list.

Changes to Fava

Add multi-folder-support for drag'n'drop: If you have multiple
document_root-folders specified, ask the user before uploading in
which folder it should go into.
Add drag'n'drop support for the journal: Drop a document on a
transaction.
If dropped on a transaction, add the metadata-field (invoice) with a
link to the document to that transaction.

Changes to beancount

Add support for "fuzzy-matching" like @corani https://github.com/corani
suggested above: When only a filename is specified in the metadata-field
(and Document directive), search different locations based on the Account
this is on/in.
@blais https://github.com/blais What do you think about this change to
beancount?

This is the same as (1), I could just make the plugin search for the
filename in all the document directories.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-256895713, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUgk111zoTRlP5PCUPmSAwny5jHb9zuks5q4dkUgaJpZM4KbxNC
.

On Sat, Oct 29, 2016 at 9:01 AM, Martin Blais<EMAIL_ADDRESS>wrote:

On Fri, Oct 28, 2016 at 7:14 AM, Dominik Aumayr<EMAIL_ADDRESS>wrote:

I'm not sure of your question: Do you need me to do one?
The question was basically about if it is possible to generate document
directives with a plugin (didn't know that).
So my updated proposal are three changes:

Plugin to convert metadata-fields to Document directives

@blais https://github.com/blais Would you write a plugin for us that
does that? 😇
So simply scan all transactions that have the invoice-metadata field (or
any other suiting field-name of your choice), and create a Document
directive for each invoice, with a link to the transaction it comes from.

I don't mind, but I have other more important changes to bring in. Might
take a bit of time.

I'll put it on the list.

https://bitbucket.org/blais/beancount/commits/13636f6e2c88c75997496c8ee5355573a0583e59
BTW, the more important changes I'm prioritizing are of large impact: I'm
finalizing making the newer "FULL" booking algorithm the default one and
push it everywhere. I'd like to make the old flawed SIMPLE algorithm
obsolete and even delete the code eventually. Then I can easily add trade
reporting and average booking method can be built on top.

Changes to Fava

Add multi-folder-support for drag'n'drop: If you have multiple
document_root-folders specified, ask the user before uploading in
which folder it should go into.
Add drag'n'drop support for the journal: Drop a document on a
transaction.
If dropped on a transaction, add the metadata-field (invoice) with
a link to the document to that transaction.

Changes to beancount

Add support for "fuzzy-matching" like @corani https://github.com/corani
suggested above: When only a filename is specified in the metadata-field
(and Document directive), search different locations based on the Account
this is on/in.
@blais https://github.com/blais What do you think about this change to
beancount?

This is the same as (1), I could just make the plugin search for the
filename in all the document directories.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aumayr/fava/issues/386#issuecomment-256895713, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUgk111zoTRlP5PCUPmSAwny5jHb9zuks5q4dkUgaJpZM4KbxNC
.

@blais I started to implement the plugin, as the examples in the beancount repo are very good and it does not seem to be too hard.
One question though: How can I modify entry.links? It seems to be a frozenset, and as entry is a namedtouple, I can not modify any of it's keys.

I added a first draft of the plugin that converts the statement-metadata on a Transaction and/or it's Postings to a Document entry: PR #393
This includes the "fuzzy-matching" for the path suggested by @corani

One question though: How can I modify entry.links? It seems to be a frozenset, and as entry is a namedtuple, I can not modify any of it's keys.

https://docs.python.org/3/library/collections.html#collections.somenamedtuple._replace

See collections.namedtuple._replace().
Plugins aren't supposed to modify the objects provided as input; create a
new one using _replace.
On Sun, Oct 30, 2016 at 4:32 AM, Dominik Aumayr<EMAIL_ADDRESS>wrote:

@blais https://github.com/blais I started to implement the plugin, as
the examples in the beancount repo are very good and it does not seem to be
too hard.
One question though: How can I modify entry.links? It seems to be a
frozenset, and as entry is a namedtouple, I can not modify any of it's
keys.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/beancount/fava/issues/386#issuecomment-257138719, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUgk8pNtY70v6yG_n2zAU6S0ry2Lq-jks5q5FY2gaJpZM4KbxNC
.

That's on purpose, using FP style and avoiding some side-effects,
generally.
Replace the links attribute with ._replace(), creating a new tuple in the
process.
On Sun, Oct 30, 2016 at 11:29 AM, Jakob Schnitzer<EMAIL_ADDRESS>wrote:

One question though: How can I modify entry.links? It seems to be a
frozenset, and as entry is a namedtuple, I can not modify any of it's keys.
https://docs.python.org/3/library/collections.html#
collections.somenamedtuple._replace
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/beancount/fava/issues/386#issuecomment-257157795, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUgkz1Qh1dNuG7ZwciefDH-s_y-Fo9wks5q5LfQgaJpZM4KbxNC
.


consumption_metrics: sending previously sent values on restart

Related: #3542, #5175
Maintaining an up-to-date cache, and reading the cache in the process start would allow us to send values at tight intervals before synthetic sizes have been calculated. We cannot maintain the cache by writing it once during shutdown, because in pratice pageservers often get SIGKILLed by systemd.
Alternatively the cache could be maintained by the service where pageserver sends the metrics to.

Solving this might lead to another issue which is uploading while executor threads are blocked.


Calendar not using daily notes format

Describe the bug
I'm using a quite standard 'daily notes' format MM-DD ddd but clicking on day in the calendar reverts back to the original.
Already tried:

reinstalling calendar plugin (restarting obsidian after de-install, re-install)
changing date formats to be extremely simple (restarting obsidian after each change)
disabling / enabling daily notes

Expected behavior
When clicking on a specific day in the calendar it should go to the note formatted according to the daily notes format
Screenshots

Environment (please specify)
OS
macOS
Obsidian Version (e.g. v0.10.6)
0.12.19

Hi @CaseyRo, the issue here is with the format itself. You've definitely made it apparent that the calendar plugin could use some better messaging when it fails to parse the date format. Really sorry about that!
There are a few implicit requirements for the date format:

The date needs to be unambiguous (so it needs some token for the year YYYY)
It only supports tokens that moment.js (the library that Obsidian uses) can parse. That list is here:

I'll see what I can do about improving the messaging there so it doesn't fail silently. I also have some ideas around making the date format a bit more flexible.

@liamcain thanks for your response! To turn this 'bug report' into a feature request, my use cases here:

use year/month/date for sorting files into folders, doesn't seem to work currently (using YYYY/MM/DD as format)
we use calendar weeks quite a lot in our company, and I like to order it in the same way, moment.js offers ww or WW in their documentation, when using moment.format. The same principle to order documents in week folders would then be my next wish ;-)

Thanks for catching up over Christmas! Happy holidays!

@liamcain - I have a related request, if it's possible: could Calendar ignore any text appended to a filename after the parseable date format?
Use case -- I often add text to a daily note filename to make it easier to skim for the major points of that day:

day 2021-12-23 Nextcloud add-ons
day 2021-12-22 Teamwork import of Trello board fail
day 2021-11-23 Mailchimp, link in bio, WP image captions

Calendar picks up my daily notes just fine, until I append any text to the filename.
Is this a technical possibility? Or should I just be reconsidering my method?

Yes, please allow to add any text after the date format.
Another way tu put it is; please allow a filename format like YYYY-MM-DD *


[Bug]: Getting error on fetching appsmith's mock-api

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Getting Internal server error on using mock-api of appsmith i.e https://mock-api.appsmith.com/users.
This issue can be seen on Production, Release and all DPs

Steps To Reproduce

Create new API
Use mock api i.e https://mock-api.appsmith.com/users
Run the query and observe the error

Public Sample App
No response
Issue video log
No response
Version
Cloud/Production

Note: Other APIs are working fine.

Closing it since it is not reproducible any more.


[Question] How to access the text content of publication using Locator for adding highlight/ underline feature?

I would like to add highlight/underline and ability to add notes feature . From my understanding in readium architecture a text object in Locator helps us to access text in the publication. But I’m not getting the text object in react native readium. Could you please provide information on how to access the text object using React Native Readium?
If my explanation isn't clear, the text object I'm referring is : https://readium.org/architecture/models/locators/#the-text-object

@bilalshams7 this is not a currently supported. Would love a PR for it though!


Can your example run on the Windows Iot?

Because when I open the sample project, the debug options does not contain a "remote machine" option.

C++/WinRT works on Windows 10 IoT. We'll look into publishing an IoT sample.

Thanks a lot!


Basic image class with setup steps and function chaining.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1314  👈
#1308
#1307
#1297
#1296
#1273
#1274
#1309
#1272
#1283 : 1 other dependent PR (#1284 )
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rohinb2 and the rest of your teammates on  Graphite

Merge activity

Nov 25, 6:16 PM EST: A user started a stack merge that includes this pull request via Graphite.


Add proper file extensions when importing a typescript file from a typescript file

Problem
Given this configuration:
{
    "n/file-extension-in-import": ["error", "always"]
}

and file1.ts
import something from "./file2"

eslint will fix this with a .ts added to the import statement, which is invalid and breaks the compilation of typescript.
Solution
When a typescript file (.ts / .cts / .mts files, .cts and .mts have been supported since TypeScript 4.5) imports another typescript file, eslint will now use the proper matching file extension instead of the original referenced file extension.
This means that, for example, when a .ts file imports another .ts file, eslint will now suggest using a .js extension in the import statement.
Release
As far as I can tell, this should be good to release as a patch.
Credit
Mostly cherry-picked from https://github.com/giladgd/eslint-plugin-node/tree/dev/giladgd/fixImportExtentionFixingInTypeScript and lingering PR https://github.com/mysticatea/eslint-plugin-node/pull/303
Thanks @giladgd

@aladdin-add I don't want to be pushy, but any chance of a quick turnaround release?  I'm migrating a huge codebase and struggling without this (and my private package attempts are currently failing on my private namespace).

released in https://github.com/weiran-zsd/eslint-plugin-node/releases/tag/15.2.1 🎉

@aladdin-add This behavior works in 15.2.1 but does not work in 15.2.2. In 15.2.2, the .ts extension is inserted in a TS file importing another TS file instead of inserting a .js extension. I think https://github.com/weiran-zsd/eslint-plugin-node/pull/24 broke this behavior.
cc @rosskevin

I'm looking at it now.  I thought I added the proper valid tests but it doesn't look like it (or I just got mixed up in the process).


New plugins not showing in plugins list

I have previously been able to create plugins without any issues. However, now new plugins does not appear in the list after creation, and I am unable to create a database, etc. The plugin is also not visible under system settings. However, I can see the plugin in the plugin folder on the server.  My plugin is matching the configured Builder author namespace .I am using version 3.5.12.

Hello @H-sans,
Please make sure to check the case sensitivity of the folder names. They should be entirely in lowercase.he folder names should be entirely lowercase.

Thanks for the swift reply @daftspunk. I've checked the case of the folder names, I've also tried combinations with both lower and uppercase, and still getting the same issue. The strange thing is that previously there hasn't been any issue creating plugins.

Make sure to check the author namespace in Settings → Builder to match expectations.

I did that

Upgraded to 3.5.13 and now they are visible.

I need to force update to make my new plugins show


Update install command to reflect the new username

+1 please accept this. Ran into this issue myself


FUSEQE-10924 Edit kamelet yaks tests for product

Added temporary namespace and Camel K operator installation
Removed loading kamelets
kubectl -> oc
Includes also the jira test

@christophd can you review this?

@christophd can you review this?


Question about .NET Core

Hello,
Would it be possible to make this package compatible for .NET Core 2.0+ ?
Thank you
Best Regards
David

Hi David,
As for now .NET Core provides only client-side WCF library. And it seems to me it is possible to copy solution folder, adjust and compile targeting .NET Core, so you would be able to intercept outgoing soap requests.
Unfortunately I don't have time to check and release it by myself now.
May be you can try to do it?

OK, I don't have to much time right now, but I will let you know if I finally have time to get it working.
Thank you
Best regards
David

Hi!
I understand this feature was never released, right?
Thx

Unfortunately, there is not .NET Core version right now.


theme color not working properly

background color don't seem to be changing properly in the dark ranges .. it outputs in black or grey shades with no color .. on the bright/white side it does changes its color shades.. Do not know why that happens on the dark side

Thanks for reporting the issue! Can you provide a minimal cast file along with instructions for reproducing?

cast file
Recorded from asciinema
Methods for conversion :

Directly from your repo https://dstein64.github.io/gifcast/

Forked it on windows and linux and opened it from local storage

PS now realized did not installed
xterm.js
omggif
Could this have caused issue with color code version ??? 😔😅

@trinib can you provide details on which particular theme has the problem and how the rendered GIF differs from the expected output? It would be helpful for debugging if the cast file is minimal. That is, as short as possible but still showing the problem.

Thanks for the details @trinib! I can reproduce the issue.
I've committed e99a1e40cca1cb8f2939c57c7b06e0e148bd7319 which fixes a bug preventing the color palette from properly being set. Force reloading gifcast (e.g., with ctrl-shift-r) should pull the latest code to your browser.
I'll close this ticket. Please re-open and/or let me know if the update doesn't address the problem for you.

working thanks


Error while processing shader in mainline bevy

When using regular v0.9.1 instead of Shfty/bevy:early-shader-defs, Shaders fail to process - preventing their material from rendering - and print the following error:
ERROR bevy_render::render_resource::pipeline_cache: failed to process shader: This Shader's format does not support processing shader defs.
Upstream issue: bevy/#7771

A fix has been merged into bevy main, so this is no longer a blocker.
However, https://github.com/bevyengine/bevy/pull/7903 remains underway, which is a nicer solution to the problem, and the one currently depended on by bevy-rust-gpu - will continue to work on it and close this issue once it's merged.

Closing this in lieu of a new issue specific to the need for shader def access.


Not able to order titles in the views menu

By using single day and daily package, I created weekly, monthly, quarterly and yearly view.  But when I added these to views menu it comes in different order. I mean yearly first, second weekly like that. When i push these titles to the view menu i gave the order field.  but it still shows the same problem. Is there any solution to solve this?.

Would be great if you could make these packages publicly available! I would like to make the same and that would be a nice starting point. Thanks

This should be fixed on the devel branch.


add a new func to calculate points_on_line

Proposed changes
Include a brief description of the changes being proposed, and why they are necessary.
Closes issues (optional)

Closes Issue #000
Closes Issue #000

Checklist (replace [ ] with [x] to check off)

[ ] Notebook created using the DEA-notebooks template
[ ] Remove any unused Python packages from Load packages
[ ] Remove any unused/empty code cells
[ ] Remove any guidance cells (e.g. General advice)
[ ] Ensure that all code cells follow the PEP8 standard for code. The jupyterlab_code_formatter tool can be used to format code cells to a consistent style: select each code cell, then click Edit and then one of the Apply X Formatter options (YAPF or Black are recommended).
[ ] Include relevant tags in the final notebook cell (refer to the DEA Tags Index, and re-use tags if possible)
[ ] Clear all outputs, run notebook from start to finish, and save the notebook in the state where all cells have been sequentially evaluated
[ ] Test notebook on both the NCI and DEA Sandbox (flag if not working as part of PR and ask for help to solve if needed)
[ ] If applicable, update the Notebook currently compatible with the NCI|DEA Sandbox environment only line below the notebook title to reflect the environments the notebook is compatible with

Proposed Changes: add a new function to dea_tools.spatial to calculate points_on_line. This is a simple reproduction of a function that currently exists in the DEA Coastlines workflow


API for creating extensions?

Hi, I found this crate when looking for a markdown parser but my use case has needs beyond that of commonmark and the provided extensions. If there, or if not could there be, some sort of API to allow creation of custom syntax rules, e.g., callouts, <ins>/<del> tags, and whatever else people have need for on a more local basis?

Thanks for reaching out @tryoxiss!
This is a duplicate of https://github.com/wooorm/markdown-rs/issues/32
Happy to discuss more there.


Consider implications of ZFS MMP prerequisites in monitored mode

In IML monitored mode, we can only operate safely iif MMP Zfs is able to function correctly.
For this, hostid s need to be set and multihost property set on zpools.
Do we set either of those if not present or should we enforce checks before IML tries anything?
Obviously setting anything in monitored mode that would have side-effects on users system is not acceptable, and if IML, for example, imports pools in IML without the necessary ZFS MMP prerequisites being set we also risk side effects.

In monitored mode, we should do nothing that alters any configuration of anything to do with Lustre.
If users are able to set up filesystems that do not meet the requirements of IML, IML should refuse to work with them.
Any requirements of configuration of Lustre by IML needs to be detailed in the documentation.
The other option of course is to alter our methods to not have such requirements, if that is possible.


Update Images.md with ImageBackground

This part of the documentation was outdated since v0.46. :)

@Minishlink
Thank you!
This is reasonable changes but I would move the point a little bit. I would suggest to implement this behaviour manually for each particular case and highlight that fact that actual implementation of  is super simple. And I would advice to use  only after taking a look of the the source code to make the best choice suited each particular case.
Could you please mention this in the documentation?

@shergin Sure, does this seem good?