Multi-Project solution support

Hi!
I was wondering if there is a plan to support more complex solutions with multiple projects containing controls?
cheers,
Stefan

Thanks for the quick response. I tried to make it work in my app but it doesn't do anything :( Need to dig further in when I have time. I would be happy with the ability to specify projects manually like you described. I'm wondering why hot reload isn't working for me at all. I guess there's no logging/tracing which can be enabled, right?

@ClxS your solution works well for me. Thanks for sharing! @Kir-Antipov thanks again for all the help and the great work!

solution works well for me

That's great to hear! :)
However, I'm gonna leave this issue open, as it's something HotAvalonia needs to learn how to do out of the box.

So, yes, there are definitely plans to add proper support for referenced projects. The only thing that's missing here is establishing a relevance between a given referenced control assembly and its source project location. For instance, if you were to manually do something like this:
var context = AvaloniaHotReloadContext.FromAsembly(typeof(MyControl).Assembly, "/path/to/project/root/");
context.EnableHotReload(); // Note: the context needs to be saved somewhere, so the GC doesn't throw it away.

It should already work. I just haven't found an elegant way to:

Determine all referenced assemblies that contain Avalonia controls.
Find the project root for each of them.

It probably won't be the solution, but maybe it's possible to use a source generator to generate those contexts for referenced projects?

While it's definitely a solution, it has its downsides. Namely:

For this approach to work, all projects containing Avalonia controls need to be explicitly referenced and accessible during compile time. However, this is not always the case. For example, ClxS mentioned that they use a plugin system that only kicks in during runtime, rendering source generators ineffective for them.

I'm not really sold on using source generators in such cases due to how high level they are. You either need to maintain 3 copies of the same source generators to support The Big Three (i.e., C#, F#, and VB.NET), or go a different route like most .NET developers do and pretend that C# is the only .NET language, which couldn't be further from the truth.

Thus, I think I'm going to stick with the debug symbols-related solution.

That makes sense.
May I ask how long would it take, to fix that problem properly, using debug symbols?
If it's going to take a longer while, I could volunteer some of my time to create some simple generators for The Big Three, and to keep them working.
Once you'd finish the debug symbols based solution, source generator could get deprecated and subsequently removed.
That would only make sense, if the solution you want to go with would take considerably longer to be made, hence my question.

how long would it take

In my better years, I could have done this in a day. However, without going into too much detail, I'm not in my most productive form at the moment, so it's more like a "will do it in an hour within a week" kind of deal.
Since this is going to be a breaking change anyways (I need to abstract AvaloniaHotReloadContext so I can combine different contexts and support dynamic assembly loading), I'm going to tackle a bit more than just multi-project support. For example, I also want to implement support for asset hot reloading, which in turn requires a better different injection technique. My homebrewed one only supports injection into methods contained within assemblies built in the Debug mode; and for asset hot reloading, I would need to inject code into Avalonia itself, which has obviously been built with optimizations enabled, thus rendering my injection method irrelevant.
So, what I'm saying here is it will take some time, but not a lot, really.

I could volunteer some of my time to create some simple generators for The Big Three

The sentiment is very much appreciated! However, it will definitely be faster for me to implement the solution I already settled on :)

All right, in that case I will patiently wait!
And who knows, maybe I'll be able to help with something else down the line 😉

@ClxS, does your plugin system load assemblies via Assembly.Load(string path) or Assembly.Load(byte[] rawAssembly)?

On a slightly more generic note, I'm currently trying to think of a good way for users to provide location hints for their assemblies when it's really truly needed.
Within the current model, where hot reload is only enabled for a single project, it's easy - .EnableHotReload() accepts a path, which is usually provided by the compiler itself (thanks to the CallerFilePathAttribute), but can be easily overridden by a user themselves:
this.EnableHotReload("/path/to/control.cs");

However, a single string is not going to cut it in a multi-project setup. Any bright ideas, folks?

P.S. - by the way, everything else is already implemented, so I hope you will be able to at least test the new multi-project-oriented system in a few days when I'm done wiring up this last thing :)

@Kir-Antipov at the moment I the strong path form

@ClxS, that's great, actually, because assemblies loaded via .Load(byte[]) do not have their Location property set, as they were loaded from the memory and not from the disk.
Since you use .Load(string), the new .EnableHotReload() should work for you out of the box when I'm done!

I think I'm done here. .EnableHotReload() should work out of the box now, even if you dynamically load assemblies into the current application domain.
If HotAvalonia cannot determine the location of some assembly's source project (e.g., there are no debug symbols available, or projects are located in a different place compared to where they were when the assemblies were compiled, etc.), there's a new overload that lets you pass a callback function capable of resolving project paths:
this.EnableHotReload(
  asm => TryLocateAssemblyProject(asm, out string? directoryName) ? directoryName : null
);

However, I genuinely think that you won't need that with your current setups.
Anyway, if you folks could test it on your end as well, it would be very much appreciated :)
You can wire your projects directly to the sources of the development branch, or grab pre-built binaries from run#9329750366 and put them into a local NuGet repository (which is just a fancy name for a directory mentioned in the nuget.config).

Hey @Kir-Antipov , I have tested your changes on latest develomment branch related to app domain support and it works! Could you release HotAvalonia with those changes when you are free? Thanks

Thanks! Yup, I'll get back to HotAvalonia shortly. I have just a few small-ish tasks to finish before the next release.


(1315) Allow a task to be allocated to a user

This updates the reallocate endpoint to support multiple tasks. I’ve updated the body to accept a NewRellocation object with a Task Type and user ID.
As we don’t currently support any task type other than assessements, we return a 405 method not allowed response. I’ve also added some tests for all the other types to serve as placeholders, which can be replaced as we add support for the other task types.

 Allow a Task to be allocated to a user

That was my initial instinct, but then I cam across this Stack Overflow question: https://stackoverflow.com/questions/32889983/is-http-501-appropriate-for-an-unimplemented-api
TLDR: 501 is when the server doesn't recognise the request, and 405 is when the server recognises the request but can't carry it out


Return ReadCloser in getReader

After uploading big files to an azure storage, a call to getReader would load the complete file into memory leading to out-of-memory issues. This pr fixes that and unnecessary check for Close by just returning the ReadCloser calling getReader.

The two changes look sensible to me, unless @omBratteng has something else to say for the AzureStore. Otherwise, please have a look at the failing tests. If they pass, we can merge this.

@Acconut somehow mockgen generates an invalid handler_mock_test.go for me. the datastore.go types are not correctly imported.

Fixed the mocks manually and merged in https://github.com/tus/tusd/commit/1038298a7999922f09a925e2f59edc813fa8deca. Thank you.


Exclude internal methods in the caller filter

This filters internal ruby implementation methods by filtering lines that include <internal.

Hello @bjfish
TruffleRuby can add more lines to the backtrace?

To clarify, <internal:... is the format used by CRuby too for methods implemented in Ruby, for instance on CRuby master:
$ ruby -e 'tap { raise }'
-e:1:in `block in <main>': unhandled exception
	from <internal:kernel>:90:in `tap'
	from -e:1:in `<main>'
$ chruby truffleruby-dev
$ truffleruby -e 'tap { raise }'
-e:1:in `block in <main>':  (RuntimeError)
	from <internal:core> core/kernel.rb:534:in `tap'
	from -e:1:in `<main>'

Thanks @eregon :)

TruffleRuby can add more lines to the backtrace?

Just to clarify: no it does not add extra lines. But when a core library method is defined in Ruby it will show up in the backtrace (instead of the next user backtrace entry being repeated for core methods in C/Java).

To clarify, I mean something that generates this stack trace to be filtered, not just passing arbitrary strings in.

FWIW there are 20+ integration tests failing on TruffleRuby without this (due to reporting not the first user code line but internals).
Note <internal: is only used frequently in CRuby 3.0, not in 2.7 or before.

@JonRowe @benoittgt Could you re-review? It looks ready to merge to me.

Hello
Sorry for the delay. I tried this patch with truffleruby-head and it validates added specs. The last added specs is a little bit to broad on the Ruby version selection but it is a good "real world integration regression example" 🧙
For the CI on windows. This is unrelated, and I will try to fix it separately.

From the examples, this seems like information that might actually be relevant, and it doesn't even apply to released Rubys? So for now I'm closing, you should be able to remove these lines with the relevant external back trace filter.

@JonRowe So you are rejecting a PR that is doing the correct and standardized backtrace filtering for Ruby 3 and TruffleRuby? (and Ruby 2.x too, see below)
I'm shocked.
Please reconsider.
Also, this happens on CRuby 2.7 which already defines some methods of the core library in Ruby files, see the *.rb files at the root of https://github.com/ruby/ruby/tree/ruby_2_7.
However it seems hard to find a method which yields a block or so and would let us make a "real world integration example" and use RSpec::CallerFilter.first_non_rspec_line.
Actually there is one method taking a block, and it exists since Ruby 2.3 or even before:
$ ruby -ve 'Thread.exclusive { puts caller(0) }'
ruby 2.3.8p459 (2018-10-18 revision 65136) [x86_64-linux]
Thread.exclusive is deprecated, use Mutex
-e:1:in `<main>'
-e:1:in `block in <main>'
<internal:prelude>:15:in `block in exclusive'
<internal:prelude>:14:in `synchronize'
<internal:prelude>:14:in `exclusive'
-e:1:in `<main>'

$ ruby -ve 'Thread.exclusive { puts caller(0) }'
ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]
-e:1: warning: Thread.exclusive is deprecated, use Thread::Mutex
-e:1:in `block in <main>'
<internal:prelude>:12:in `synchronize'
<internal:prelude>:12:in `block in singleton class'
-e:1:in `<main>'

$ ruby -ve 'Thread.exclusive { puts caller(0) }'
ruby 3.0.0dev (2020-09-23T15:42:39Z use-blocking-callb.. d1d5f6d16f) [x86_64-linux]
-e:1:in `<main>': undefined method `exclusive' for Thread:Class (NoMethodError)

But as you can see that method is deprecated and then removed in Ruby 3 so it doesn't seem a good way to write a reliable test.

From the examples, this seems like information that might actually be relevant

It seems clearly not relevant for RSpec::CallerFilter.first_non_rspec_line which intends (AFAIK) to show the first "user code" location, not a location inside the core library, e.g. to show warnings.
Not merging this prevents running RSpec's own specs on TruffleRuby and causes the 20+ integration tests failures mentioned above.
For example, just bundle install && bundle exec rake spec on truffleruby-head gives:
...
  6) rspec warnings and deprecations #warning it should behave like warning helper sets the calling line
     Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }

       Kernel received :warn with unexpected arguments
         expected: (/\/home\/eregon\/code\/rspec-support\/spec\/rspec\/support\/warnings_spec.rb:45/)
              got: ("WARNING: Message. Called from <internal:core> core/hash.rb:223:in `fetch'.")
       Diff:
       @@ -1 +1 @@
       -[/\/home\/eregon\/code\/rspec-support\/spec\/rspec\/support\/warnings_spec.rb:45/]
       +["WARNING: Message. Called from <internal:core> core/hash.rb:223:in `fetch'."]

Clearly, the right location to report to the user is .../support/warnings_spec.rb:45, not Hash#fetch in the core library.
So, can you merge this?

The purpose of RSpec::CallerFilter.first_non_rspec_line is literally in the name, reject rspec lines, internal Ruby lines are valuable information to developers and its not up to us to exclude them by default.

What about the last example (for warnings) I showed?
Nobody wants:
WARNING: Message. Called from <internal:core> core/hash.rb:223:in 'fetch'.
Everybody wants:
WARNING: Message. Called from spec/rspec/support/warnings_spec.rb:45.
RSpec::CallerFilter.first_non_rspec_line is used for warnings, and that Called from <internal:core> core/hash.rb:223:in 'fetch' comes from:
https://github.com/rspec/rspec-support/blob/e16dbca59c0a6f0a0562153e3b28d86e674fef55/lib/rspec/support/warnings.rb#L30
So one alternative I see would be to increase the skip there. But by how much?
How to know if Hash#fetch calls the block via yield (which adds 1 entry) or via block.call (which adds 2 stack entries).
In this specific case though, we can probably just use call_site = options[:call_site] || CallerFilter.first_non_rspec_line to avoid deepening the stack.
Essentially to know if core library backtrace entries belong to RSpec or not we'd need to look what's the first non-internal entry above. It's possible, but it seems a lot of complications not needed for this case.
Is RSpec::CallerFilter.first_non_rspec_line used by anything except warnings (or other things which only want to show user code location)? If not, I think there is no point to make it complicated, we want to point to a user code location for warnings, not to a core library location.

With these changes:
diff --git a/lib/rspec/support/warnings.rb b/lib/rspec/support/warnings.rb
index 380150b..93d6979 100644
--- a/lib/rspec/support/warnings.rb
+++ b/lib/rspec/support/warnings.rb
@@ -27,7 +27,7 @@ module RSpec
       #
       # Used internally to print longer warnings
       def warn_with(message, options={})
-        call_site = options.fetch(:call_site) { CallerFilter.first_non_rspec_line }
+        call_site = options[:call_site] || CallerFilter.first_non_rspec_line
         message += " Use #{options[:replacement]} instead." if options[:replacement]
         message += " Called from #{call_site}." if call_site
         Support.warning_notifier.call message
diff --git a/spec/rspec/support/caller_filter_spec.rb b/spec/rspec/support/caller_filter_spec.rb
index 4c7004c..b7738a8 100644
--- a/spec/rspec/support/caller_filter_spec.rb
+++ b/spec/rspec/support/caller_filter_spec.rb
@@ -5,7 +5,7 @@ require 'rspec/support/caller_filter'
 module RSpec
   describe CallerFilter do
     it 'can receive skip_frames and increment arguments' do
-      expect(RSpec::CallerFilter.first_non_rspec_line(1, 5)).to include("#{__FILE__}:#{__LINE__}")
+      expect(RSpec::CallerFilter.first_non_rspec_line(3, 5)).to include("#{__FILE__}:#{__LINE__}")
     end

     it 'returns the immediate caller when called from a spec' do

we still have an extra failure for bundle exec rake spec on TruffleRuby:
  1) RSpec::CallerFilter the filtering regex does not match rubygems lines from `require` statements
     Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }
       expected result to have changed to include "/home/eregon/code/rspec-support/spec/rspec/support/caller_filter_spec.rb", but is now "<internal:core> core/kernel.rb:234:in `gem_original_require'"
     # ./spec/rspec/support/caller_filter_spec.rb:67:in `block (4 levels) in <module:RSpec>'
     # ./spec/rspec/support/caller_filter_spec.rb:50:in `in_rspec_support_lib'
     # ./spec/rspec/support/caller_filter_spec.rb:60:in `block (3 levels) in <module:RSpec>'

RubyGems' require is actually filtered as intended, but what we see here, "<internal:core> core/kernel.rb:234:in 'gem_original_require'" is actually the original require, that RubyGems aliases to gem_original_require. That original Kernel#require is implemented in Ruby in TruffleRuby.
So what should we do about this spec then? Filtering that internal require only seems not pretty.
I think the real intention behind such filtering is to show user code locations (as in non-rspec, non-core-library, non-rubygems), and that filtering core library entries makes sense.
But if you prefer something like the diff above, it can probably work too. Not sure how to address that spec about require though.

Another way to see this: RSpec::CallerFilter.first_non_rspec_line returns a single line.
A single core library is basically always useless (not enough context): it does not contain information relevant for an RSpec user.
So I think the better fix is to make RSpec::CallerFilter.first_non_rspec_line ignore core library lines, because they are never relevant for the end user.
@JonRowe @benoittgt Thoughts?

@JonRowe

you should be able to remove these lines with the relevant external back trace filter.

I don't think there is any possibility of customization/external filter for RSpec::CallerFilter.first_non_rspec_line.
Filtering backtraces shown by failed specs is a different thing, that is untouched in this PR.
I think maybe you misunderstood what this PR was about.
It's about giving a useful location to the user for e.g. RSpec warnings.

If this proves to be a problem for Ruby 3 I'll revisit it later on, for now I suggest you improve the Truffle Ruby implementation to match MRI.

I suggest you improve the Truffle Ruby implementation to match MRI.

OK, this is what was misunderstood.
<internal: is the standard format for core library methods defined in Ruby.
It's not a TruffleRuby thing, it is the backtrace format from MRI.
So asking to change that in TruffleRuby is unreasonable.
This is not an incompatibility of TruffleRuby, it is a bug of RSpec we are fixing (i.e., it can report useless locations for warnings in some cases as shown above). This bug happens to trigger test failures (kudos on testing that, example output), so fixing it also makes those tests pass on TruffleRuby.
The bug just happens more frequently on TruffleRuby because more core methods are defined in Ruby. I don't think you can blame TruffleRuby for that (and anyway MRI 2.7 is already doing it as well).
RSpec needs to handle these changes in the backtrace.
It only works now by luck because MRI 2.7 does not have many core methods defined in Ruby yet.
If Hash#fetch would be defined in Ruby on MRI, it would break exactly the same way as on TruffleRuby. Of course RSpec should not depend on that but just handle both cases gracefully.
BTW the <internal: formats seems to date from 1.9 or older: https://github.com/sinatra/sinatra/blob/91477e6dad7c9d8eb1c358e47b9d83b73d626f84/lib/sinatra/base.rb#L1212
and has always been used for methods defined in prelude.rb such as Thread.exclusive.
That backtrace format is already what CRuby 2.7 uses for quite a few core methods, as said in https://github.com/rspec/rspec-support/pull/426#issuecomment-697950203.
For instance:
$ ruby -ve 'TracePoint.new(0)' |& cat
ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]
<internal:trace_point>:96:in `new': no implicit conversion of Integer into Symbol (TypeError)
	from -e:1:in `<main>'

$ ruby -ve 'Thread.exclusive { puts caller }' |& cat
ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]
-e:1: warning: Thread.exclusive is deprecated, use Thread::Mutex
<internal:prelude>:12:in `synchronize'
<internal:prelude>:12:in `block in singleton class'
-e:1:in `<main>'

(note the <internal:trace_point>:96 and <internal:prelude>:12 entries)
CRuby 3 uses it for more core methods, as more of the core library methods are defined in Ruby.
I've worked for 6 years on TruffleRuby and I've always paid a lot of attention to have compatible backtraces with CRuby. In fact, TruffleRuby's backtraces are far more similar to MRI, than e.g. JRuby or Rubinius backtraces.
Initially, TruffleRuby hid core library methods defined in Ruby, much like C methods on CRuby, by repeating the next user's location, for maximum compatibility. This leads to silly backtraces, and so once the standard of <internal: was clear, TruffleRuby started using it.
From this experience, I am convinced this PR is the correct solution.
If you disagree, then please show me an example where it is useful to have something like:
WARNING: Message. Called from <internal:core> core/hash.rb:223:in 'fetch'.
instead of:
WARNING: Message. Called from spec/rspec/support/warnings_spec.rb:45.
or
WARNING: Message. Called from <internal:core> core/kernel.rb:234:in 'gem_original_require'
instead of
WARNING: Message. Called from /home/eregon/code/rspec-support/spec/rspec/support/caller_filter_spec.rb
BTW, Kernel#warn(uplevel: n) already does this filtering. Kernel#warn(uplevel: n) is Ruby 2.5+ so I guess RSpec cannot rely on that yet.
There is similar filtering in recent RubyGems to skip the RubyGems require as that gives no useful info, similar to <internal: backtrace entries.

@JonRowe @benoittgt Maybe I should open a new PR since it seems the purpose of this PR and what it fixes was not clear?

FWIW RubyGems skips <internal: for Kernel#warn, which is a very similar situation: https://github.com/rubygems/rubygems/blob/ce27b98272d5c37ebf45b2b1b66894699ae47d58/lib/rubygems/core_ext/kernel_warn.rb#L42 (disclaimer: it's my commit)

@eregon, @JonRowe is the lead maintainer. He has final words on PR and issues. So I will probably not argue anymore, I already shared my approval. 🙂


Enable a linter for markdown

Please take a look at the markdown lint implementation in the PR below:
https://github.com/ROCm-Developer-Tools/HIPIFY/pull/737/files#diff-1957eea3063ddb68ad0361c7ce7982cf609cbdb01e57c1cc791209d2980e8b7c

Implementing a linter is key to ensuring we maintain standards as large numbers of collaborators join.


Add guide for converting from existing implicit many-to-many relation to an explicit many-to-many relation

Converting from an implicit to explicit m-n relation is a fairly common use case that is not trivial, but we lack any guidance in our docs. It would be helpful to have a comprehensive guide that shows an example of how to do this.
Slack convo #1
Slack convo #2
Frederik's repo outlining a potential workflow

It would be great to learn how to do this backwards as well.

Quick update: The PR is still being worked on

👋 we're cleaning up our backlog of issues and are closing everything older than two years. If you still feel that this issue is relevant, please feel free to re-open and our team will take a look. Thank you!


calibre: fix html5lib error

Motivation for this change
Commit ff5423cdca4adc5a18463be1aa1dd1603453c724 broke calibre with stacktraces like this one for ebook-edit. The main executable help page does work, but doesn't show this error until you actually try to start the GUI.
It took a number of attempts to identify the cause: basically, the newer html5lib associated with mechanize is found first, rather than the bundled one, and having the old html5lib in the prior location (late in the buildInputs list) causes the same behavior.
Putting the legacy version first in the python package list resolved the issue.
Things done

[X] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] Linux

[X] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

Edited for commit hash.

When does calibre use mechanize? Because then it will use the wrong version of html5lib.

@FRidh, I'm not sure where else, but the command in question is calibredb; there is a way to pass it a URL, so as long as you have calibre running with the server enabled (or run the standalone server), then this one will show all book titles in the library matching the search (in this case, any works by Arthur Conan Doyle is used as the exemplar).
calibredb \
    --with-library="http://localhost:8080/#Calibre_Library" \
    list \
    -f title \
    -sort_by=title \
    -s 'authors:"=Arthur Conan Doyle"'

This does assume that your library uses the default name of Calibre Library; there are instructions for how to use calibredb to get a list of libraries on the server which IIRC should also trigger the bug.
I discovered yesterday that my computer's case fans are dead, so it overheats if I do any long compilation, so e.g. building chromium causes it to lock up or power off. As such, I hadn't gotten this into actual use to see if this is an issue in practice; I was just able to verify that the base commands would handle <cmd> --help as they have in the past. I'll run the above test once I have the system fully working, and will see if I can figure out another way around this, but we may have to override mechanize just for calibre (to not propagate html5lib).

Running a full test of my use case (as described above) with the changes in this branch does work.
My guess is that when calibre uses html5lib directly, it depends on html5lib_0_9999999, while other code uses mechanize instead, which acts as a wrapper around the newer html5lib (thus not exposing the new html5lib to most of calibre).
Perhaps someone more familiar with python packaging in nix can explain why this works, but including the older html5lib after mechanize in the buildInputs list or using the vendored version does not?

My guess is that when calibre uses html5lib directly, it depends on html5lib_0_9999999, while other code uses mechanize instead, which acts as a wrapper around the newer html5lib (thus not exposing the new html5lib to most of calibre).

I doubt it picks the correct version depending on what code is used. Instead, I think the parts of mechanize that are used work fine with another version of html5lib.
I'll merge this but its very fragile. Unfortunately I don't see any other solution either.


#151 - Additional fixes

Fixes #151: Reverted the instance variable for cql and handled within the CQL
instance to avoid creation of null streams
- This will avoid the initialization of the null stream which is created
during the initialization of the CQL instance.
- Create the streams only when there is a valid input in the parseCF function
- PredictionContextCache is not thread-safe - should not be static.

Coverage decreased (-10.7%) to 84.52% when pulling 12131a32b3a897e71a79f01e625846a1dbce632e on alexnavis:#151 into 61122472b1292a2e12ca6d3deae387b7548977e6 on ChronixDB:#151.


New Function: Volunteer Coordination

A common need for nonprofit orgs using Twilio is to coordinate ad hoc groups of volunteers (or volunteered supplies) over SMS. I believe a lightweight solution for this would be doable via SMS, backed by Twilio Sync as a data store.
Desired features:

Create "events" via SMS
-- upon event creation, optionally broadcast new event to all registered volunteers
Associate "needs" with events
Allow listing upcoming events via SMS
Display needs for an event via SMS
Allow volunteers to commit to covering all or some of a need for an event
-- If volunteers attempt to volunteer for a need that's already covered, tell them so and say if there are other needs.
Remind volunteers when their event commitment will be needed via SMS
Allow volunteers to un-commit/cancel their commitment via SMS
Upon cancelation, SMS registered volunteers to let them know that someone backed out, and requires backfill.
Ability for admins to broadcast to all volunteers manually

Probable solution:

Function that handles incoming SMS (bot interface)
Function that will be executed on an interval to send out commitment reminders, for now using something like Zapier or IFTTT

Real world use case descriptions:
A group of chefs want to provide free meals at a shelter. They need 5 volunteers to show up, and they need 100 servings of fruit, 100 sandwiches, and 100 desserts. They need chefs to be able to volunteer and commit to bringing food via SMS.
A disaster relief org learns about a natural disaster. They need 10 volunteers immediately at the disaster site. An admin creates an event, and broadcasts all volunteers. Volunteers immediately respond, until all needs have been met.

Working on the first function mentioned, the bot interface.


CORE-4868 - change PK of cpk_metadata to be the name, version and signer hash

DDLs:
create table cpk_metadata
(
    cpk_name                varchar(255)            not null,
    cpk_version             varchar(255)            not null,
    cpk_signer_summary_hash varchar(255)            not null,
    file_checksum           varchar(255)            not null
        constraint db_cpk_metadata_uc1
            unique,
    format_version          varchar(12)             not null,
    metadata                text                    not null,
    entity_version          integer                 not null,
    is_deleted              boolean                 not null,
    insert_ts               timestamp default now() not null,
    constraint cpk_metadata_pk
        primary key (cpk_name, cpk_version, cpk_signer_summary_hash)
);

create table cpi_cpk
(
    cpi_name                varchar(255)            not null,
    cpi_version             varchar(255)            not null,
    cpi_signer_summary_hash varchar(255)            not null,
    cpk_file_checksum       varchar(255)            not null
        constraint db_cpi_cpk_uc1
            unique
        constraint "FK_cpi_cpk_cpk_metadata"
            references cpk_metadata (file_checksum),
    cpk_file_name           varchar(255)            not null,
    entity_version          integer                 not null,
    is_deleted              boolean                 not null,
    insert_ts               timestamp default now() not null,
    constraint cpi_cpk_pk
        primary key (cpi_name, cpi_version, cpi_signer_summary_hash, cpk_file_checksum),
    constraint "FK_cpi_cpk_cpi"
        foreign key (cpi_name, cpi_version, cpi_signer_summary_hash) references cpi
);

If I understand correctly the change for PK for cpk_metadata is necessary so that Hibernate when running merge() would be able to find previously saved entity with same PK and auto-increment @Version entity_version.
@conalsmith-r3 - is my understanding correct?

If I understand correctly the change for PK for cpk_metadata is necessary so that Hibernate when running merge() would be able to find previously saved entity with same PK and auto-increment @Version entity_version. @conalsmith-r3 - is my understanding correct?

Yes, changing the PK allows us to rely on hibernate auto incrementing the entityVersion and since we have this on our CpkIdentifier, to properly identify different CPKs

I'm a bit late to this - and the Jira issue isn't clear. The file checksum of the cpi and cpk (s) is unique (subject to hash collision), if we were to change name, version, or ssh, the file checksum must change. So what's the reason for this change? Sorry if I'm missing the point here.

While working on CORE-4868 we decided to add entityVersion to the CPK identifier, but when storing a CPK during force upload, it would result in new row with the same name, version, signerSummaryHash and a different file checksum, and entityVersion would be 0. So the cache in FlowSandboxServiceImpl would have multiple CPKs with the same name, version, signerSummaryHash, but different fileChecksums, and an entity version of 0.
Now when a CPK is force uploaded and the cpk already exists, it will increment the entity_version on the CPK with the already existing name, version, signerSummaryHash, thus overwriting the existing CPK.

There is currently a problem with API change merged last night:

[2022-06-14T08:14:10.800Z] TEST net.corda.processors.crypto.tests.CryptoProcessorTests <<< ERROR: liquibase.exception.MigrationFailedException: Migration failed for change set net/corda/db/schema/config/migration/config-creation-v1.0.xml::config-creation-v1.0::R3.Corda:

[2022-06-14T08:14:10.800Z]      Reason: liquibase.exception.DatabaseException: data exception: invalid datetime format [Failed SQL: (-3407) INSERT INTO CONFIG.config (section, config, schema_version_major, schema_version_minor, version, is_deleted, update_ts, update_actor) VALUES ('corda.reconciliation', '', '1', '0', '0', 'false', '${now}', 'admin')]

[2022-06-14T08:14:10.800Z] liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for change set net/corda/db/schema/config/migration/config-creation-v1.0.xml::config-creation-v1.0::R3.Corda:

[2022-06-14T08:14:10.800Z]      Reason: liquibase.exception.DatabaseException: data exception: invalid datetime format [Failed SQL: (-3407) INSERT INTO CONFIG.config (section, config, schema_version_major, schema_version_minor, version, is_deleted, update_ts, update_actor) VALUES ('corda.reconciliation', '', '1', '0', '0', 'false', '${now}', 'admin')]

@kyriathar is currently looking into it.


Transient test failures

(If there's already an issue to discuss this issue, please reference it and close this one)
http://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents often has failures (red crosses) that are fixed simply by relaunching the tests (only those with certain rights on hydra can do this).
I'm opening this issue so that we can document, discuss and hopefully fix these transient failures.
As an example, we can look at nixos:trunk-combined:nixos.tests.networking.scripted.dhcpSimple.x86_64-linux to get the discussion going:
http://hydra.nixos.org/build/34509732/log ⇐ succeeded
http://hydra.nixos.org/build/34566924/log ⇐ failed
cc @edolstra @domenkozar

Looks to me that the problem occurs on or around: http://hydra.nixos.org/build/34566924/log#line-1155
error: unit ‘network.target’ is inactive and there are no pending jobs
unit ‘network.target’ is inactive and there are no pending jobs

Looking at similar failure for nixos.tests.printing.x86_64-linux in: http://hydra.nixos.org/build/34566747/log#line-1022
error: unit ‘cups.service’ is inactive and there are no pending jobs
unit ‘cups.service’ is inactive and there are no pending jobs

See #13559

possibly related, http://i.imgur.com/zd1fpWG.png
i was trying to debug some xorg stuff, and discovered xorg cant load libdbus, because libz files are in the dbus derivation!
12 hours later, the exact same qemu-vm did the right thing, and dbus was inside the dbus derivation, it fixed itself

That was with qemu using 9p-over-zfs, which may be troublesome (inode numbers mapping, ... who knows).

Well, could it be because of the fact that we had a bad dbus updated that got reverted? 9eb107dc5

nope, this was a directory listing on the exact same dbus derivation, and the host /nix/store was mounted to the guest, the filesystems should be 100% identical

This is supposed to be fixed now: https://github.com/NixOS/nixpkgs/commit/ad29b726866b5abeed9ad05cad52995295cf4813

"This" mean, the source of all/most the transient test failures?

There is one more test failing: raid (mdadm). We could open a separate issue for that one.

Also fixed: https://github.com/NixOS/nixpkgs/commit/3e7b510281e6144a441646dd6e32cc3f3bae1f8a

Really impressive stuff, can't wait to have my eyes traumatized from seeing so much green!

There is still a fairly common KDE test failure that I'm looking at now.


Cannot achieve the performance in the paper

Dear authors,
Thank you for sharing the code. I recently run the code on CIFAR10 dataset without changing any settings in the code. I achieved only 57.3% accuracy (44.0, 48.0, 52.7, 49.9, 41.6, 59.9, 57.3 for each cycle), which is far from 80.9% accuracy reported in the paper.
It seems that the settings in the code are not the final version. It will be very kind of you if you could provide the settings.
Best Wishes~

Hi, @Winfrand . Please check the Normalization for the training samples and test samples. The current code seems inconsistent. Specifically, just modify the cifar_transformer in main.py (line 19) as below.
def cifar_transformer():
    return transforms.Compose([
            transforms.ToTensor(),
            transforms.Normalize(mean=[0.5, 0.5, 0.5,],
                                std=[0.5, 0.5, 0.5]),
        ])

@GWwangshuo good catch, thank you! i will fix this in the repo.

@GWwangshuo Thank you very much! I will try this new setting.

Hello Authors,
I ran the scripts with the modification suggested by @GWwangshuo. I am still not able to achieve the performance mentioned in the paper for CIFAR10 dataset.
I ran multiple times for averaging out the results. I am able to achieve accuracy between 67%-70% for 40% split.
It seems there are still some settings which are not present in the current version.
If so, kindly provide them.
Also, @Winfrand How much accuracy did you get after this modification?
Thanks :)

@danishmsin I didn't check CIFAR10: only MNIST/SVHN/Imagenet and couldn't get good results for  VAAL as well


feat: pendingTransactions with links

Issues
Adds links to pending transactions.
Store pending transactions in localStorage with some TTL and waitForTransaction on page refresh.
Fixes https://github.com/snapshot-labs/snapshot/issues/3141
Changes

Extended useTxStatus() composable
Added txs with links to TheNavbar.vue
Migrated from pendingCount to createPendingTransaction, updatePendingTransaction, removePendingTransaction

How to test

Try to create delegate transactions or with safeSnap plugin

To-Do

[ ] Get transaction ids for safeSnap plugin

Self-review checklist

[x] I have performed a full self-review of my changes
[x] I have tested my changes on a preview deployment
[ ] I have tested my changes on a custom domain
[ ] I have run end-to-end tests yarn cypress:test:e2e, and they have passed

@j0hnfl0w any blockers with this PR?

@bonustrack do you approve this design
Single transaction:

Multiple transaction?

Maybe instead of showing multiple IDs we should show a button "View transactions" that opens a modal with a list of pending and complete transactions

or maybe pending transactions can live here

The text in grey with blue background doesn't work well, I'd rather make it white, or use a modal. The modal would give much more space.

I think we dont need the "Show more" button, we can just make the pending banner clickable and keep same height than before

Unless they hover. How can someone assume the banner is clickable? I think maybe we should add some icon that suggests the banner is clickable or show "pending transactions" as a link

Agree, there should be some indicator

Nice work @j0hnfl0w


Add support for cbc.ca

Example URL: http://www.cbc.ca/22minutes/videos/22-minutes-update/22-minutes-update-award-season

Another example would be: http://www.cbc.ca/hellogoodbye/episodes/season1/ep1-wish-you-were-here
These are hosted on theplatform.com, it seems most of CBC has moved over to that site.


Query the Open GL for its tex. supoport

Query for max texture size. And handle the non-power of two textures case.

Texture Cache: initial


-

Shark
?
Count of Content - X, Count of Comment - Y, Registration period - Z

Additional Account Badges

Badge
Unique  Likers [^2]
Special conditions

Whale (Moderator Type 1)
-
MODERATOR_REGISTER Transaction

Whale (Moderator Type 2)
?
?

Whale (Moderator Type 3)
?
?

Barracuda (Developer)
-
Determined by the source code

Basic Limits [^1]

Badge
Posts
Articles
Videos
Comments
Ratings  (Content)
Ratings  (Comment)
Flags

Minnow
5
1
1
20
30
60
-

Sturgeon
30
3
10
300
200
600
-

VideoExtend ?
30
3
100
300
200
600
-

Shark
30
3
20
300
200
600
200

Whale
30
3
20
300
200
600
600

Barracuda
30
3
20
300
200
600
-

Ratings to Content

Badge
★
★★
★★★
★★★★
★★★★★
Impact on reputation [^4]

Minnow
-
-
-
+
+
-

Sturgeon
-
-
-
+
+
-

Shark
+ [^3]
+ [^3]
+ [^3]
+
+
+

Whale
+
+
+
+
+
+

Barracuda
+
+
+
+
+
-

[^1]: One unit is restored within 1440 blocks
[^2]: Unique ratings from Account to Account according to the Ratings to Content table and only for content ratings (NOT comment ratings).
[^3]: If there are 10 active posts, videos or articles
[^4]: The impact only occurs for 2 (content) and 20 (comments) ratings in the last 48 hours


About code training

I am a beginner in human pose estimation, and I cannot find the script named "train_BUCTD_synthesis_noise.sh". What command should I use to train this code? Could you provide an example command?

Sorry for the confusing in the tutorial - you can use: train_BUCTD_COAM_gen_sample.sh, please check this script instead.


Add Support for --profile Flag to Enable AWS SSO Integration

Is your feature request related to a problem? Please describe
amazon-managed-grafana-migrator tool does not currently support the --profile flag, which is essential for utilizing AWS CLI profiles, especially for configurations involving AWS Single Sign-On (SSO)
Describe the solution you'd like
I would like the amazon-managed-grafana-migrator to support the --profile flag. This would allow users to specify which AWS profile to use directly through the command line interface, integrating seamlessly with the AWS CLI's profile management. This is particularly important for users with SSO configurations, allowing them to leverage different roles and permissions set up through AWS SSO.
Additional context
Adding this feature would simplify the workflow for users who manage multiple AWS profiles and rely on AWS SSO for security. It would enhance the usability of the tool in enterprise environments where different teams or projects may require different levels of access and credentials management. This support would align the tool more closely with other AWS services and tools that already support profile selection via the CLI

Thanks for opening this, we will look into it


Force input stream ANSI emulation for ConsoleZ

- What I did
Enabled arrow-key navigation in docker container terminals from a Windows docker client running from a ConsoleZ terminal. Closes #26991
- How I did it
I amended the recently added ConEmuANSI=ON check for forcing stdin ANSI emulation to also check for the presence of the ConsoleZVersion enviroment variable, which ConsoleZ injects into its terminal environments.
- How to verify it
Start up the docker client in a ConsoleZ terminal and shell into a docker container. Verify that the arrow keys move the cursor and navigate through the command history (assuming a sh-like shell).
- Description for the changelog

Windows

Fix an issue where arrow-navigation did not work when running the docker client in ConsoleZ

ping @jhowardmsft

LGTM. (Not tested - don't use ConsoleZ)

LGTM

Don't suppose this could make it into 1.12.2?

@vieux re comment above


[BLD]: follow NEP29 version support schedule

Increasing the minimum version of bluesky to python 3.8 inline with NEP29.
Description

Remove 3.6/3.7 from testing.
Set min version to 3.8 in setup.py
Motivation and Context

NEP29
How Has This Been Tested?

Passes unit tests.

The only other place where outdated python pops up is in the Azure pipelines?  Are those no longer in use, and should they be removed?

Please hold of merging this until we get one more release out.


[Bench] Reduce input cols number for fetch

To estimate output size of result query to allocate buffer we are running count* before some actual queries. This estimation requires only query body argumnets without select arguments, so this commit changes input_cols for count* query.
Resolves: #574
Signed-off-by: Dmitrii Makarenko<EMAIL_ADDRESS>

Looks good! Please fix some minors and it's good to go.

Should we add someone else to review?


Getting npm ERR! Failed at the<EMAIL_ADDRESS>install script.

After cloning WillzMu/projectZed repo, entering into projectZed folder and running npm install, the error pops up, npm ERR! Failed at the<EMAIL_ADDRESS>install script and some other errors, below is a screenshot.
I am using:
node v12.6.0
npm 6.9.0

Kindly assist in resolving!

So, after looking around, seems it's an issue with<EMAIL_ADDRESS>not supporting Node 12 and this ships with firebase-js-sdk. Issue here: Fails to build with node.js v12.0.0 release
I had to delete package-lock.json and ran npm install && npm start, web server ran fine with the error below:
$ npm start

><EMAIL_ADDRESS>start C:\REACT\projectZed
> react-scripts start

There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.

The react-scripts package provided by Create React App requires a dependency:

  "eslint": "5.6.0"

Don't try to install it manually: your package manager does it automatically.
However, a different version of eslint was detected higher up in the tree:

  C:\REACT\projectZed\node_modules\eslint (version: 6.1.0)

Manually installing incompatible versions is known to cause hard-to-debug issues.

If prefer to ignore this check, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That will permanently disable this message but you might encounter other issues.

To fix the dependency tree, try following the steps below in the exact order:

  1. Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.
  2. Delete node_modules in your project folder.
  3. Remove "eslint" from dependencies and/or devDependencies in the package.json file in your project folder.
  4. Run npm install or yarn, depending on the package manager you use.

In most cases, this should be enough to fix the problem.
If this has not helped, there are a few other things you can try:

  5. If you used npm, install yarn (http://yarnpkg.com/) and repeat the above steps with it instead.
     This may help because npm has known issues with package hoisting which may get resolved in future versions.

  6. Check if C:\REACT\projectZed\node_modules\eslint is outside your project directory.
     For example, you might have accidentally installed something in your home folder.

  7. Try running npm ls eslint in your project folder.
     This will tell you which other package (apart from the expected react-scripts) installed eslint.

If nothing else helps, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That would permanently disable this preflight check in case you want to proceed anyway.

P.S. We know this message is long but please read the steps above :-) We hope you find them helpful!

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `react-scripts start`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      C:\Users\Chizzo\AppData\Roaming\npm-cache\_logs\2019-10-08T17_51_57_167Z-debug.log

After which, I created a .env file in root folder with SKIP_PREFLIGHT_CHECK=true. Making progress, but getting the error below:
./src/reducers/projectsReducer.js
Module not found: Can't resolve '../data' in 'C:\REACT\projectZed\src\reducers'

Are you able to provide the data?

thanks @Chizzoz . Sorry to see you getting an error. did you try following the instructions in the screenshot:
  1. Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.   2. Delete node_modules in your project folder.   3. Remove "eslint" from dependencies and/or devDependencies in the package.json file in your project folder.   4. Run npm install or yarn, depending on the package manager you use.
This could be because there is an eslint package in the project root directory and in the client folder. I would recommend following the rules above first. Let me know if it helps

Hi! Yeah! That issue has been sorted, got it running. No got this issue:
./src/reducers/projectsReducer.js
Module not found: Can't resolve '../data' in 'C:\REACT\projectZed\src\reducers'

Can you provide the localized sample data?

I think this issue has been resolved, closing it.


Anti-bruting locking out NIPR NAT

When users on NIPR fail to login, either due to incorrect credentials or inactive account, the associated IP block is performed on the external address of the NAT, resulting in large swaths of users being blocks.

Staged


AWS SDK dependency installation

Which version and edition of Flyway are you using?
Flyway Community Edition 9.17.0 using flyway/flyway:9-alpine
If this is not the latest version, can you reproduce the issue with the latest one as well? (Many bugs are fixed in newer releases and upgrading will often resolve the issue)
It is the latest version
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
command line
Which database are you using? (Type & version)
SnowFlake 7.15
Which operating system are you using?
Mac OS
What did you do? (Please include the content causing the issue, any relevant configuration settings, the SQL statement(s) that failed (if any), and the command you ran)
FLYWAY_LOCATIONS=s3:mybucket/myfolder flyway migrate
What did you expect to see?
Successful migration
What did you see instead?
SEVERE: Can't read location s3:mybucket/subfolder; AWS SDK not found
Additional notes
I am aware that the documentation reads "To use AWS S3, the AWS SDK v2 and dependencies must be included, and configured for your S3 account." but the AWS documentation related to AWs SDK v2 is geared towards fresh maven projects, whereas I'm just interested in using the CLI tool.  I've tried downloading various jars using wget and saving them in /flyway/lib/ which appears to be in the CLASSPATH but to no avail.
Can you provide more detailed instructions on how to install all the necessary dependencies?

Hi @ebonharme , would you try whether this would help https://documentation.red-gate.com/fd/adding-to-the-classpath-184127216.html ?

hey @ebonharme, just curious, were you able to get this to work eventually?


Problem when using half2 kernel

I'm not sure if this is the right place to post that issue, please redirect me to the correct channel if it's the wrong one.
I recently added support for ROCm HIP on ExLlama, a standalone implementation of Llama. I had a bunch of problem with the hipified project outputting gibberish, it was found that this was an issue with kernels using half2.
Would it be possible to have someone with more knowledge than me look at where the problem is? Using python test_benchmark_inference.py -d GPTQ-model-dir -p -v  with and without -fh2 (force half2) should expose the problem.

The task of debugging this will be easier if you could share the code which PyTorch actually generates and tries to compile.

I do not know how to make a smaller reproducible version.
As for my system information, I do not believe that it's relevant, the two others people that contributed to my HIP patch also had that issue and a more popular project that used ExLlama didn't disable half2 kernels and got at least 4 people reporting issues and none reported it working.
If you really want to know, I'm using Arch Linux on kernel 6.3.8 with ROCm 5.4.3, my GPU is an RX 6700 XT overridden to gfx1030, I also tried with the latest rocm/dev-ubuntu-22.04 docker image.

Someone found the problem and fixed it. It was two different one.
First, HIP half2 struct is not the same as CUDA. On CUDA, half2 have two half type public variables x and y. Meanwhile, on HIP, x and y are unsigned short. I'm not sure if difference between CUDA and HIP are issues worth tracking.
The second issue was h2rcp producing incorrect result. The contributor that found the problem opened an issue on hipamd repo for that.


[Implementation] fetchmail to receive mail

https://sourceforge.net/p/postfixadmin/code/HEAD/tree/trunk/ADDITIONS/fetchmail.pl

Fetchmail is really useful ? What is the point of this solution ?

@hardware To receive mail from external IMAP/POP3 into local mailbox.

https://postfixadmin.domain.tld/edit.php?table=fetchmail

I added fetchmail forwarding support. Now you can set ENABLE_FETCHMAIL variable to true and configure your retrieval settings in postfixadmin.


Integration with preact-cycle

I'm using preact-cycle in my project and I generally prefer using actions (mutations) instead of including links with explicit strings, for example:
const DocumentButton = (props, {mutation}) => (

Document Name

)

const SELECT_DOCUMENT = (state, id) => {
 route(`/documents/${id}`)
}

This works but I get strange behaviors (css layout breaking, console errors stating that the history stack can't push the same entry, etc.)
Is there a way to integrate preact-router and preact-cycle such that I can manage the url within my store and control url changes via mutations?

It'd be quite difficult since window.history is a source of external state with its own lifecycle.  For example, you may wish to route to a given URL in your internal state representation, but should the browser push that as an entry into history, or update the URL in-place?
If you're looking to decouple entirely from browser history, you can use memory history:
import { createMemoryHistory } from 'history';

let history = createMemoryHistory();

<Router history={history}>
  etc
</Router>


[cli] dx halo identity throws error when agent is running

Start a new agent
Run dx halo identity

% DX_PROFILE=test dx agent start --ws=4567
Agent started.
% dx agent list
 profile process running locked restarts uptime
 ─────── ─────── ─────── ────── ──────── ──────────────────
 default         true                    Null
 test    15728   true           0        less than a minute
% DX_PROFILE=test dx halo identity
Identity key: 046808ed96cf1444047e7a3ccb5428d7759c6b22417ad097fea92b9e1cd91183f13054944932d68ed1d56f0d24bc38dc534ce1b5317133227034300022f6ea6387
Display name: undefined
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
Error: invariant violation: No identity. Default space is created with an identity. [identityKey] at packages/sdk/client/src/echo/space-list.ts:197
    at invariant (/Users/jessmartin/.asdf/installs/nodejs/18.14.2/lib/node_modules/@dxos/cli/node_modules/@dxos/invariant/dist/lib/node/index.cjs:40:9)
    at get default [as default] (/Users/jessmartin/.asdf/installs/nodejs/18.14.2/lib/node_modules/@dxos/cli/node_modules/@dxos/client/dist/lib/node/chunk-GXJ46TDK.cjs:886:36)
    at Object.next (/Users/jessmartin/.asdf/installs/nodejs/18.14.2/lib/node_modules/@dxos/cli/node_modules/@dxos/client/dist/lib/node/chunk-GXJ46TDK.cjs:848:74)
    at notifySubscription (/Users/jessmartin/.asdf/installs/nodejs/18.14.2/lib/node_modules/@dxos/cli/node_modules/zen-observable/lib/Observable.js:117:18)
    at onNotify (/Users/jessmartin/.asdf/installs/nodejs/18.14.2/lib/node_modules/@dxos/cli/node_modules/zen-observable/lib/Observable.js:159:3)
    at Object.next (/Users/jessmartin/.asdf/installs/nodejs/18.14.2/lib/node_modules/@dxos/cli/node_modules/zen-observable/lib/Observable.js:177:9)
    at /Users/jessmartin/.asdf/installs/nodejs/18.14.2/lib/node_modules/@dxos/cli/node_modules/@dxos/async/dist/lib/node/index.cjs:598:62
    at Set.forEach (<anonymous>)
    at Object.next (/Users/jessmartin/.asdf/installs/nodejs/18.14.2/lib/node_modules/@dxos/cli/node_modules/@dxos/async/dist/lib/node/index.cjs:598:25)
    at notifySubscription (/Users/jessmartin/.asdf/installs/nodejs/18.14.2/lib/node_modules/@dxos/cli/node_modules/zen-push/node_modules/zen-observable/lib/Observable.js:121:18)

I cannot repro this on c414ce052. where in your usage did you create an identity?

I cannot repro this on c414ce0.

Ah, I'm on 0.3.9-next.35264cb. Will try what newest on main and see what happens.

This appears to be fixed on main. Closing.


Default Production Tasks is not Stopping When Webpack returns non-zero!

See discussion in https://github.com/shakacode/react_on_rails/pull/730
https://github.com/shakacode/react_on_rails/blob/master/lib/tasks/assets.rake#L55
# Sprockets independent tasks
namespace :react_on_rails do
  namespace :assets do
    desc <<-DESC
Compile assets with webpack
Uses command defined with ReactOnRails.configuration.npm_build_production_command
sh "cd client && `ReactOnRails.configuration.npm_build_production_command`"
    DESC
    task webpack: :environment do
      if ReactOnRails.configuration.npm_build_production_command.present?
        sh "cd client && #{ReactOnRails.configuration.npm_build_production_command}"
      end
    end
  end
end

@robwise @alexfedoseev I think the bug is that we're not forcing the rake task to fail on the line that's running: ReactOnRails.configuration.npm_build_production_command.
By contrast, I think we're doing the correct thing here:
https://github.com/shakacode/react_on_rails/blob/master/lib/react_on_rails/test_helper/webpack_assets_compiler.rb#L11
# You can replace this implementation with your own for use by the
# ReactOnRails::TestHelper.ensure_assets_compiled helper
module ReactOnRails
  module TestHelper
    class WebpackAssetsCompiler
      def compile_assets
        puts "\nBuilding Webpack assets..."

        build_output = `cd client && #{ReactOnRails.configuration.npm_build_test_command}`

        raise "Error in building assets!\n#{build_output}" unless Utils.last_process_completed_successfully?

        puts "Completed building Webpack assets."
      end
    end
  end
end

@ypresto Given all this, would it make more sense to just change the code around assets.rake rather than recommending --bail?
@robwise @alexfedoseev any opnions?

Commented on PR, should we just do both?

100% we need to check the return status...
I'm not sure on the --bail because it might be preferable to see all the failures in the CI report or deployment. OTOH, it might be preferable for CI or deployment to fail more quickly. Default?

I think we default to bail early and then they can change it if they want CI to keep running

This issue is fixed by Webpack V2. Once that is merged...then it's up to the users to configure their package.json appropriately.

See #730 for a demonstration of how V2 fixes the issue.

I'll close this issue once I merge the Webpack v2 changes.

React on Rails is updated for Webpack v2! If you're on webpack v1, use the --bail option!


Update chapter_1.md

line 10: The Dursleys had a future incel of a son named Dudley who they thought was the main character.
paragraph 18: He must have accidentally picked up one of Mrs. Dursley's edibles that morning.

@sagee444 Nice updates! Thanks :)


Make KumoProxy a stand-alone package

KumoProxy is super helpful and easy to use, but deploying it is cumbersome. It would be nice if it were packaged as a separate utility that can be deployed and managed without having to install the full KumoMTA server.
The problem: Right now you need to install the full KumoMTA and then run only the proxy-server binary, which is really the only part you need. Also, it does not actually "install" with a system service.  If you want it to run and survive a restart, you need to create your own system service for it.
Ideally, the install should be as easy as sudo apt install kumoproxy

This is waiting for user funding


⚠ Samsung has degraded performance

In 4756bc7, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2840 ms

Resolved: Samsung performance has improved in 43f7520.


Incorrect(?) warning message when creating table .pngs (non-urgent)

It appears to be creating the .png files correctly, but I get this message:
Warning message: In table_format(crav_tab, image_path = "report3-tables/longlveg3_tablex_mostcommonanimalproductcravings.png") :   In order to save tables from this function, you must first install phantomjs using webshot::install_phantomjs()
And when I run webshot::install_phantomjs(), I get It seems that the version of "phantomjs" installed is greater than or equal to the requested version.To install the requested version or downgrade to another version, use "force = TRUE".
Which seems to be saying I already have it? And to be fair, the .png does get created so maybe I do, but I don't see phantomjs in my package list so I am confused.
(Non-urgent because it is creating the .pngs correctly)

What happens when you run:
webshot::is_phantomjs_installed()

I think this should work now (I put the "else" part of an "if...else" in the wrong spot). Let me know if it works and if not, can you run webshot::is_phantomjs_installed() and let me know what it says?


[QA] Link Astro docs to the webpage not github

[QA] Link Astro docs to the webpage not github

Verified run regression test plan, now we are getting Astro link webpage like instead of github
Results


Normal LSC light bulb

There is a LSC Smart Filament LED E27 bulb, but not the normal one with just white. I can add it, but it doesn't turn on or off.
NEW DATA ATRIBUTE: {“devId”:“085484012462ab4c0d80”,“dps”:{“20”:false,“21”:“white”,“22”:35,“23”:870,“25”:“000e0d0000000000000000c80000”,“26”:0,“101”:true}}

Hi,
What is the exact type of this led (because the normal filament led is already supported) and what are the attributes that change when you turn it on / off.

Yes, this isn’t a filament led, but a normal/ regular E27 bulb. It’s the cheapest bulb from the line.
If needed I can  provide some photo’s or info on the bulb?
Verzonden vanuit Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 voor Windows 10
Van: @.>
Verzonden: zondag 2 mei 2021 15:09
Aan: @.>
CC: Martijn @.>; @.>
Onderwerp: Re: [rebtor/nl.rebtor.tuya] Normal LSC light bulb (#15)
Hi,
What is the exact type of this led (because the normal filament led is already supported) and what are the attributes that change when you turn it on / off.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/rebtor/nl.rebtor.tuya/issues/15#issuecomment-830807273, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIZQWDQT5I7YXRXSJUTBDQ3TLVFITANCNFSM4T2NHZZA.

fixed


Concerns regarding Cometbft v1.0 upgrade

@adizere, @andynog I tried rolling updates to comet1.0 build, here are my first set of observations:
Repo: https://github.com/kwilteam/kwil-db/pull/760
Consensus:
No consensus breakage with a rolling upgrades.
P2P panics:
nodes on older versions panic as they receive messages from the nodes on newer versions, potentially due to the changes in this PR which introduces this new message (HasProposalBlockPartMessage), that the old nodes are not aware of. The panic closes the connection to the peer and reestablish it with every block. So there is significant p2p connection activity happening with every block.

Is panic necessary here? can the protocol be changed to ignore these messages and not cause the old nodes to panic?

What are the consequences of not consuming these HasProposalBlockPartMessage messages? Are there any liveness issues? I have not noticed any, but want to confirm. Also, Is coordinated upgrades the recommended approach for this?

Upgrade guidelines doc doesn't mention about this breaking nature in P2P layer, you might wanna add it there.

Node with older versions: Panicking

Peer disconnects with every block:

Logging issues:
There are lots of noise from the mempool, which I don't think is necessary. Below are the screenshots

This is one other log message I used to observe a lot while doing stress test and even on smaller loads. But I haven't observed this anymore on comet1.0, looks like u guys fixed it. But I want to bring it up.

Thanks for the feedback @charithabandi. I'll evaluate your feedback and use the information as part of an upgrade guide to v1 that I'm working on as part of https://github.com/cometbft/cometbft/issues/3416.

Thanks, @andynog.  Initially it seemed like 0.38->1.0 would be a rolling upgrade, not even requiring coordination among validators, but the P2P version bump and the addition of a new message makes that trickier.  No consensus breakers, however, which is a relief.  Thanks! :pray:
I suspect the following is not possible, but is there any way to update 0.38.x so that an unknown message type does not cause the panic and subsequent disconnect?  Or perhaps consensus.(*Message).Unwrap (or consumer) could recognize but ignore HasProposalBlockPart?

I think we should change the past releases so that we do not panic when we encounter an unknown message but simply ignore it.
Thanks for bringing this up @charithabandi ❤

@andynog do you want to work on this?

Hi @melekes, I'm not working on the solution to this problem at the moment, mostly the guide for now. If you want to take a stab in the solution I'm good with that.

Sorry for chiming late here. @charithabandi bear in mind that a rolling upgrade from v0.38.x to v1.0.0 (two different major versions) is not supported, as stated in our documentation. In other words, we don't support mixed networks with v0.38.x and v1.0.0 nodes. Chains must undergo a coordinated upgrade.
This also applies for v0.34.x--> v0.37.x, v0.37.x--> v0.38.x.

Just wanted to follow up on the discussion about the network upgrades and the P2P version bump. From what we've seen, the main thing holding back a rolling upgrade is the P2P changes, not any consensus issues. While we get that breaking compatibility is allowed in major releases, we’d really appreciate it if there’s any way to prevent old nodes from disconnecting during these upgrades. If it's just the P2P layer causing the break, a simple workaround could make a big difference with the upgrade process.
We know the versioning policy allows for these breaks, but fixing this would make it much easier for users like us to upgrade to 1.x without running into major issues. Of course, if there are other breaking changes and you’re not comfortable calling it a rolling upgrade, we totally get that too. But we’re happy to help test if P2P is the only problem affecting our setup.
Thanks for considering this – it would really help smooth out the upgrade process for your user base, including us!

Thanks for the feedback, I will revisit this again soon

Hi @charithabandi, We just pushed a PR (https://github.com/cometbft/cometbft/pull/4184) with a guide for upgrading from v0.38.x to v1.0. It is currently under review, but if you have any feedback or think anything important is missing, please let me know.
I still need to review the P2P feedback and see if we need to clarify anything.

P2P breakages are not mentioned anywhere in the doc, I am guessing they are still in review. The rest looks good to me.
Quick question: Is there a reason why ABCI's Commit() method doesn't pass height and the app hash as it's arguments and expects application to keep track of it? It's the data cometbft already persists after the FinalizeBlock(), why not pass this info in the Commit() call?

CommitRequest could indeed be passing height as other ABCI calls are. However, after the initial handshake (and as long as it doesn't crash) the app is supposed to know/remember its own height at every moment, so the app's handlers of other ABCI calls typically use the height passed for sanity checks. Bear in mind that CommitRequest (or RequestCommit) has not changed in v1.x, this has been like this for years. Having said all that, if there's a use case requiring the addition of the current height to CommitRequest we can still do it in v1.x (as long as it isn't cut yet), or in future versions.
As for the app hash, it's the same one the app is passing to CometBFT as part of FinalizeBlockResponse, so I don't see why CometBFT would need to give that same info back to the app in the subsequent call.

Well, I completely agree with you. But the 2-phase is commit is so hard with many edge cases, it's just easy on application if the hash and height information is sent back with the commits as cometbft has that info persisted.
It's especially important in the crash recovery scenario's where the crash occurs after the FinalizeBlock and before completely finishing the Commit() and app is in this weird half committed state. Also, Cometbft doesn't replay the FinalizeBlock if it has the results persisted and instead directly calls the Commit(), in this case application needs to persist the hash and height (and also where in the block stage we are). We are dealing with this in our App, but just letting you know that, our solution would be way simpler if we have this information passed in the Commit() call.

As mentioned in this comment rolling upgrades are not supported.
I will close this issue but the information can be used in a new issue for historical context. This should not be preventing the v1 release cut since what is discussed in this issue is not in scope for the v1 release.


could not convert ‘0’ from ‘int’ to ‘raisim::Vec<3ul>::’

Hello， after I typed make -j4 to compile the raisimpy, I got following errors:
In file included from /home/wzc/raisim_build/include/raisim/interfaceClasses.hpp:9:0,
                 from /home/wzc/raisim_workspace/raisimpy/src/visualizer.cpp:41:
/home/wzc/raisim_build/include/raisim/World.hpp:48:27: error: could not convert ‘0’ from ‘int’ to ‘raisim::Vec<3ul>::<anonymous union>’
     Vec<3> size = {0, 0, 0};
                           ^
/home/wzc/raisim_build/include/raisim/World.hpp:48:27: error: too many initializers for ‘raisim::Vec<3ul>’
/home/wzc/raisim_build/include/raisim/World.hpp:49:26: error: could not convert ‘0’ from ‘int’ to ‘raisim::Vec<3ul>::<anonymous union>’
     Vec<3> com = {0, 0, 0};
                          ^
/home/wzc/raisim_build/include/raisim/World.hpp:49:26: error: too many initializers for ‘raisim::Vec<3ul>’
In file included from /home/wzc/raisim_workspace/raisimpy/src/world.cpp:32:0:
/home/wzc/raisim_build/include/raisim/World.hpp:48:27: error: could not convert ‘0’ from ‘int’ to ‘raisim::Vec<3ul>::<anonymous union>’
     Vec<3> size = {0, 0, 0};
                           ^
/home/wzc/raisim_build/include/raisim/World.hpp:48:27: error: too many initializers for ‘raisim::Vec<3ul>’
/home/wzc/raisim_build/include/raisim/World.hpp:49:26: error: could not convert ‘0’ from ‘int’ to ‘raisim::Vec<3ul>::<anonymous union>’
     Vec<3> com = {0, 0, 0};
                          ^
/home/wzc/raisim_build/include/raisim/World.hpp:49:26: error: too many initializers for ‘raisim::Vec<3ul>’
In file included from /home/wzc/raisim_workspace/raisimpy/src/world.cpp:33:0:
/home/wzc/raisim_build/include/raisim/RaisimServer.hpp:71:29: error: could not convert ‘1’ from ‘int’ to ‘raisim::Vec<4ul>::<anonymous union>’
   Vec<4> color = {1, 1, 1, 1};
                             ^
/home/wzc/raisim_build/include/raisim/RaisimServer.hpp:71:29: error: too many initializers for ‘raisim::Vec<4ul>’
/home/wzc/raisim_build/include/raisim/RaisimServer.hpp:80:25: error: could not convert ‘0’ from ‘int’ to ‘raisim::Vec<3ul>::<anonymous union>’
   Vec<3> size = {0, 0, 0};
                         ^
/home/wzc/raisim_build/include/raisim/RaisimServer.hpp:80:25: error: too many initializers for ‘raisim::Vec<3ul>’
/home/wzc/raisim_build/include/raisim/RaisimServer.hpp:89:29: error: could not convert ‘0’ from ‘int’ to ‘raisim::Vec<3ul>::<anonymous union>’
   Vec<3> position = {0, 0, 0};
                             ^
/home/wzc/raisim_build/include/raisim/RaisimServer.hpp:89:29: error: too many initializers for ‘raisim::Vec<3ul>’
/home/wzc/raisim_build/include/raisim/RaisimServer.hpp:90:34: error: could not convert ‘1’ from ‘int’ to ‘raisim::Vec<4ul>::<anonymous union>’
   Vec<4> quaternion = {1, 0, 0, 0};
                                  ^
/home/wzc/raisim_build/include/raisim/RaisimServer.hpp:90:34: error: too many initializers for ‘raisim::Vec<4ul>’
CMakeFiles/raisimpy.dir/build.make:205: recipe for target 'CMakeFiles/raisimpy.dir/src/visualizer.cpp.o' failed
make[2]: *** [CMakeFiles/raisimpy.dir/src/visualizer.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
CMakeFiles/raisimpy.dir/build.make:218: recipe for target 'CMakeFiles/raisimpy.dir/src/world.cpp.o' failed
make[2]: *** [CMakeFiles/raisimpy.dir/src/world.cpp.o] Error 1
CMakeFiles/Makefile2:72: recipe for target 'CMakeFiles/raisimpy.dir/all' failed
make[1]: *** [CMakeFiles/raisimpy.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

I tried several ways but still failed. What can I do to fix this?

What g++ version are you using?

I am using g++ -8.

If this is important, I’ll go check it again as soon as I can.

that type of initialization of a vector class is supported after g++-6.0. I often got that error when using with g++-5

Thank you, I’ll go check it.

You are right. I set the compiler to g++-8, and the errors are perfectly solved. Thank you for your patient. @jhwangbo


Not all requested ID's are returned when using filter[id]

Note: this is in my opinion not a bug in Lux, but an interesting (and probably sensible) use case which is likely used by many Ember apps which might need some thought.
When using "filter" to request certain records (i.e. 1 through 50), not all requested ID's will be returned, only the first "page size" (25 by default). This causes Ember-data to fail because not all requested data is there.
Example URL (decoded) as created by Ember:
http://localhost:5000/my-resource?filter[id]=8679,8678,8677,8676,8675,8674,8673,8672,8671,8670,8669,8668,8667,8666,8665,8664,8663,8662,8661,8660,8659,8658,8656,8653,8652,8651,8650,8649,8648,8647,8646,8645,8644

Now this might be somewhat specific to Ember w/ coalesceFindRequests = true as it automatically retrieves relationships it needs based on ID's on the resources in this way. I'm not sure whether there is any control there over how many ID's it should provide per request, haven't found it yet. Ember-data also doesn't seem to grasp the concept of pagination without the page parameters and will not automatically retrieve the remaining pages.
Simple solution on the Ember side would be to turn off coalesceFindRequests, but this can/will cause a big amount of subsequent requests as then each ID is requested separately on the server.

You can get around this in Ember with groupRecordsForFindMany. Something like the following should work. I did not sanity check it though. 😉
import DS from 'ember-data';

const MAX_PER_PAGE = 25;

export default DS.JSONAPIAdapter.extend({
  coalesceFindRequests: true,

  groupRecordsForFindMany(store, snapshots) {
    const groups = [];
    const roundTotal = Math.ceil(arr.length / MAX_PER_PAGE) * MAX_PER_PAGE;

    for (let offset = 0; offset < roundTotal; offset += MAX_PER_PAGE) {
      groups.push(snapshots.slice(offset, offset + MAX_PER_PAGE));
    }

    return groups;
  }
});

Didn't know that one yet! Should work great. Thanks!


Reason: Error upserting embeddings to Pinecone...unsupported protocol scheme ""

Error:
Failed Files:

    <foo>.pdf
    Reason: Error upserting embeddings to Pinecone: Post "<url>.pinecone.io/vectors/upsert": unsupported protocol scheme ""

To reproduce:
Follow the setup instructions as per README on 20/4/23, upload a small file (mine was ~4mb after changing the allowed filesize), then try to ask a question - this error would then show up on the UI

Error:
Failed Files:

    <foo>.pdf
    Reason: Error upserting embeddings to Pinecone: Post "<url>.pinecone.io/vectors/upsert": unsupported protocol scheme ""

To reproduce: Follow the setup instructions as per README on 20/4/23, upload a small file (mine was ~4mb after changing the allowed filesize), then try to ask a question - this error would then show up on the UI

Similar Problem here, but I already get the error when trying to upload a file!

Same error; I tried with a ~300 kb PDF file size.

prepend https:// to your pinecone api endpoint address

prepend https:// to your pinecone api endpoint address

Yup, that's solved it for me, I think its not obvious because when you copy the endpoint from pinecone it comes without the https://

this should be added to readme.

I think it would be trivial to check the presence of "https://" when loading the endpoint from the env var and prepend it in code if it's missing


Adds regression test for fetch/get

wip

This is now both stale and targeting the wrong git repo. Closing.


Build problems with installed libgit2 1.8.0

This is not the first time similar problems are happening, but this time I'd like to track it down.
The current problem is that cargo-c 0.9.31, when built from pkgsrc, doesn't build after the pkgsc libgit2 package is upgraded from 1.7.2 to 1.8.0.
In pkgsrc (and probably most other packaging systems), we'd like to install only one copy of a library so that e.g. fixing security problems is easy - fix the library, rebuild all users, done. When using bundled libgit2, we need to find and fix the problem in all bundled copies of libgit2, which is much more work.
cargo-c 0.9.31 uses libgit2-sys-0.16.2+1.7.2.crate. The build fails with:
...
warning<EMAIL_ADDRESS>libgit2/src/libgit2/commit.c:300:5: error: conflicting types for 'git_commit_create'
...
warning<EMAIL_ADDRESS>libgit2/src/libgit2/commit.c:939:5: error: conflicting types for 'git_commit_create_buffer'
...
warning<EMAIL_ADDRESS>libgit2/src/libgit2/config_backend.h:47:12: error: conflicting types for 'git_config_backend_from_string'
...

(and many more). I suspect that this happens because git2-rs tries to build the bundled libgit2 1.7.2 against the system's 1.8.0 headers.
I see that the documentation says that only newer patch releases of 1.7.2 are supported, so you're already documenting that it won't work. The failure mode when 1.8.0 is installed is hard to diagnose (if you're only interested in cargo-c and just see the build fail).
I have two ideas for this:

allow newer major versions. Of course you can't predict the future and this might break, but building the included old version against newer headers has already broken a couple of times.
when building the bundled libgit2 code, make sure to avoid using system-provided headers. (If this is a problem in pkgsrc only, let me know - but it looks like pkgsrc only sets a rust link-arg to fix the rpath.)

Let me know if I got something wrong, or if you have other ideas how to improve the situation. Thank you!

when building the bundled libgit2 code, make sure to avoid using system-provided headers.

This should be the normal behavior. Perhaps there is an issue with pkg-config or perhaps an include environment variable is set?
Can you show an example using something like docker? For example, with this dockerfile:
FROM ubuntu:latest

WORKDIR /tmp
RUN apt update
RUN apt install -y curl git gcc cmake pkg-config libssl-dev python3
RUN curl -OL https://github.com/libgit2/libgit2/archive/refs/tags/v1.8.0.tar.gz
RUN curl -OL https://github.com/libgit2/libgit2/archive/refs/tags/v1.7.2.tar.gz
RUN tar -xzvf v1.7.2.tar.gz
RUN tar -xzvf v1.8.0.tar.gz

RUN cd libgit2-1.7.2 && mkdir build && cd build && cmake .. -DCMAKE_INSTALL_PREFIX=/usr && cmake --build . -j 8 --target install
RUN pkg-config --modversion libgit2

RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > rustup.sh
RUN sh ./rustup.sh -y --profile minimal
ENV PATH="/root/.cargo/bin:${PATH}"

RUN cargo new foo
WORKDIR /tmp/foo
RUN cargo add<EMAIL_ADDRESS>RUN echo 'fn main() { println!("{:#?}", git2::Version::get()); }' > src/main.rs
RUN cargo run

RUN cd /tmp/libgit2-1.8.0 && mkdir build && cd build && cmake .. -DCMAKE_INSTALL_PREFIX=/usr && cmake --build . -j 8 --target install
RUN pkg-config --modversion libgit2

RUN cargo clean
RUN cargo run

The output for the last commands is:
…
#13 [10/21] RUN pkg-config --modversion libgit2
#13 0.276 1.7.2
#13 DONE 0.3s

#20 [17/21] RUN cargo run
…
#20 4.549      Running `target/debug/foo`
#20 4.551 Version {
#20 4.551     major: 1,
#20 4.551     minor: 7,
#20 4.551     rev: 2,
#20 4.551     crate_version: "0.18.3",
#20 4.551     vendored: false,
#20 4.551     threads: true,
#20 4.551     https: true,
#20 4.551     ssh: false,
#20 4.551     nsec: true,
#20 4.551 }
#20 DONE 4.8s

…

#22 [19/21] RUN pkg-config --modversion libgit2
#22 0.258 1.8.0
#22 DONE 0.3s

#24 [21/21] RUN cargo run
…
#24 10.32      Running `target/debug/foo`
#24 10.32 Version {
#24 10.32     major: 1,
#24 10.32     minor: 7,
#24 10.32     rev: 2,
#24 10.32     crate_version: "0.18.3",
#24 10.32     vendored: true,
#24 10.32     threads: true,
#24 10.32     https: true,
#24 10.32     ssh: true,
#24 10.32     nsec: true,
#24 10.32 }
#24 DONE 10.5s

Here you can see with 1.7.2 installed, it uses the system version (vendored: false). With 1.8 installed it uses the 1.7.2 vendored version.

Sorry, docker is not native on NetBSD. I looked at the compilation line and it looks like this for me:
cc -O3 -ffunction-sections -fdata-sections -fPIC -m64 -O2 -g -fstack-clash-protection -I/usr/pkg/include -I/usr/include -I /scratch/devel/cargo-c/work/cargo-c-0.9.31/target/release/build/libssh2-sys-361572ac956294e9/out/include -I libssh2/src -I /scratch/devel/cargo-c/work/cargo-c-0.9.31/target/release/build/libssh2-sys-361572ac956294e9/out/build -I /usr/include -fvisibility=hidden -DHAVE_LONGLONG -DHAVE_SNPRINTF -DHAVE_UNISTD_H -DHAVE_INTTYPES_H -DHAVE_STDLIB_H -DHAVE_SYS_SELECT_H -DHAVE_SYS_SOCKET_H -DHAVE_SYS_IOCTL_H -DHAVE_SYS_TIME_H -DHAVE_SYS_UN_H -DHAVE_O_NONBLOCK -DLIBSSH2_OPENSSL -DHAVE_LIBCRYPT32 -DHAVE_EVP_AES_128_CTR -DHAVE_POLL -DHAVE_GETTIMEOFDAY -DLIBSSH2_DH_GEX_NEW -DLIBSSH2_HAVE_ZLIB -o /scratch/devel/cargo-c/work/cargo-c-0.9.31/target/release/build/libssh2-sys-361572ac956294e9/out/build/903bc623e643396f-agent.o -c libssh2/src/agent.c
...
cc -O3 -ffunction-sections -fdata-sections -fPIC -m64 -O2 -g -fstack-clash-protection -I/usr/pkg/include -I/usr/include -I /scratch/devel/cargo-c/work/cargo-c-0.9.31/target/release/build/libgit2-sys-0e1b24aff7320f06/out/include -I libgit2/src/libgit2 -I libgit2/src/util -I libgit2/deps/http-parser -I libgit2/deps/xdiff -I libgit2/deps/pcre -I /scratch/devel/cargo-c/work/cargo-c-0.9.31/target/release/build/libssh2-sys-361572ac956294e9/out/include -I /usr/include -fvisibility=hidden -DGIT_REGEX_BUILTIN=1 -DHAVE_STDINT_H=1 -DHAVE_MEMMOVE=1 -DNO_RECURSE=1 -DNEWLINE=10 -DPOSIX_MALLOC_THRESHOLD=10 -DLINK_SIZE=2 -DPARENS_NEST_LIMIT=250 -DMATCH_LIMIT=10000000 -DMATCH_LIMIT_RECURSION=MATCH_LIMIT -DMAX_NAME_SIZE=32 -DMAX_NAME_COUNT=10000 -DSHA1DC_NO_STANDARD_INCLUDES=1 '-DSHA1DC_CUSTOM_INCLUDE_SHA1_C="common.h"' '-DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C="common.h"' -o /scratch/devel/cargo-c/work/cargo-c-0.9.31/target/release/build/libgit2-sys-0e1b24aff7320f06/out/build/96639c8a8c534100-openssl.o -c libgit2/src/util/hash/openssl.c

so I suspect that because -I/usr/pkg/include is before -I/scratch/devel/cargo-c/work/cargo-c-0.9.31/target/release/build/libgit2-sys-0e1b24aff7320f06/out/include, the 1.8.0 headers are used instead of the 1.7.2 ones.
Perhaps it is added for another dependency?
Can you try a build where you set CPPFLAGS and/or CFLAGS to the path where libgit2 1.8 is installed on the host system?
(I tried removing pkg-config but openssl-sys uses it for finding openssl.)

I tried your recipe, manually, and indeed I can reproduce the failure when I use
CFLAGS=-I/usr/pkg/include cargo run

instead of cargo run.


”Cămărzana” is listed in the drop-down menu

Description:
"Cămărzana" is listed in the drop-down menu alongside its corresponding county and commune, according to the law.
Precondition:
The website is up an running.

Step 1
Type "Cămărzana" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Cămărzana, SATU MARE (Cămărzana)".


[CI] Raise error if 'read configuration from a PR comment' fails silently

Resolves https://github.com/RasaHQ/rasa/issues/10692

Definition of done

[X] if the PR comment is valid, the 'read configuration from a PR comment' step succes as normal (example)
[X] otherwise, fail the step (example)

/modeltest
include:
 - dataset: ["Carbon Bot"]
   config: ["Sparse + DIET(bow) + ResponseSelector(bow)"]

@virtualroot This PR is ready for review. Note: You got assigned by GitHub 😆


Always on top shortcut conflicts with WSA

Microsoft PowerToys version
0.53.1
Running as admin

[X] Yes

Area(s) with issue?
Always on Top
Steps to reproduce
A reddit user made me aware of that the shortcut for always on top conflicts with a WSA shortcut.
https://prod.support.services.microsoft.com/en-us/windows/accessibility-on-windows-subsystem-for-android-97b77924-6df9-4597-8394-15b6e34d1658#:\~:text=There are two ways to turn on the,sure the Subsystem Screen Reader is turned on.
Comment: https://www.reddit.com/r/Windows11/comments/rxkgp8/powertoys_053_with_always_on_top_powertoys_run/hrjd53g?utm_medium=android_app&utm_source=share&context=3
✔ Expected Behavior
No response
❌ Actual Behavior
No response
Other Software
No response

Current workaround is that the Always on Top shortcut can be changed on settings.
Perhaps we can pick another shortcut by default.

What does resolution of this issue look like? Changing the Always On Top default shortcut key?


Scanresult device id on iOS shows a long ID

Hello community,
when I check the scan results on iOS it just shows me a long id and on android, it shows me the correct mac address.
Is there a way to show the MAC address on iOS?
Thank you in advance,
cheers
Kevin

I'm experiencing the same thing also, the name of the device is different from Android. I would really appreciate someone having a look at this?
flutter_blue: ^0.7.2
child: Text(                 '${device.id.id.toUpperCase()} ${device.name.toUpperCase()}',                 style: TextStyle(color: Colors.white),               ),

Just to add to this request: I found the following snippets https://stackoverflow.com/questions/18973098/get-mac-address-of-bluetooth-low-energy-peripheral
please take a look at jlandyr's answer (answered Aug 29 '19 at 11:11)
Perhaps someone is capable of answering if this is even possible to do?

any updates?

This is also causing me issues, in my case I'd like to identify if it's one of our IoT devices using the scanresults but this doesn't seem possible on iOS without checking the characteristics

This is a limitation on iOS, not an issue of flutter_blue. This is the way as iOS identifies a device. It computes a unique identifier (uuid) using the device mac but the mac itself is not available when scanning a Bluetooth device.

This is a limitation on iOS, not an issue of flutter_blue. This is the way as iOS identifies a device. It computes a unique identifier (uuid) using the device mac but the mac itself is not available when scanning a Bluetooth device.

Thank you for the answer. I've also checked it in the apple developer forum and I seems to be correct. It seems like it'a an security design to not show the MAC address, because it can also be changed. https://developer.apple.com/forums/thread/105064


public code for GTEx web services?

Hi,
Thanks for making publicly available this valuable set of tools/code from the GTEx project.
We're interested in setting up our own version for internal use/data and we're curious if the code for the RESTful web services component(s) was also available publicly?
I saw that https://github.com/broadinstitute/gtex-public exists but it only lists the web services definition themselves rather than the actual web services code for the backend.
Thanks in advance,
Chris

Hi Chris:
No, the server-side code is not open source.  The server architecture is somewhat complex, with files in Google Cloud Storage, web services running in Google App Engine and Kubernetes, and about 1T of data in ~50 collections in MongoDB (along with all the ETL scripts to load those collections).  It just isn't feasible for us to document how to implement and load an instance.
Sincerely,
Jared Nedzel

Thanks @jnedzel for the quick response.
I completely understand about not making the server side public.


Fixing local playground issue

With a humble apology @Popov72  :-)

Thanks :)

You forgot a { at the end of line 569 ;)

How is this possible... Fixing and merging now

Hmm... well already fixed. Github seems to have a few issues...


How can I exclude a js file?

Version
2.6.10
Reproduction link
https://jsfiddle.net/chrisvfritz/50wL7mdz/
Steps to reproduce
Im using a js file for config settings like apiurl. After the build, these files merging in a bundle file. I need to change this file after build.
What is expected?
An excluded config file
What is actually happening?
Bundled these files

Hi, thanks for your interest but Github issues are for bug reports and feature requests only. You can ask questions on the forum, the Discord server or StackOverflow.


Relation to dy-sh/obsidian-consistent-attachments-and-links ?

I see @mnaoumov is the author of most of the commits to both this as well as the similar https://github.com/dy-sh/obsidian-consistent-attachments-and-links plugin.
Are these plugins serving different purposes? Any reason to choose one vs. the other?

@luckman212, yes, the plugins are different

Obsidian Custom Attachment location allows to have custom attachment folder based on file name, date, etc
Consistent Attachments and Links ensures that all links are valid and allows to collect corresponding attachments to their notes.

I personally use them together, but technically they don't depend on each other.

Okay thanks @mnaoumov - I personally only see the need for Obsidian Custom Attachment Location at the moment but it's good to know the 2 can coexist, I thought they would interfere with each other...


Problem with proxing on local server

Hi,
I've got a certain problem. After creation of team i can't access newly created pod (after pressing Start Hacking I return to creating new team). This issue only occures when I'm using my own config file. I changed only secure: false to secure: true, because i want to launch it on our production server. Do you know what may be the problem?

Yeah with secure set to true you won't be able to use it with a local proxy.
It will enforce that the cookies that the balancer needs are send via https. The https termination is expected to be handled by the loadbalancer / ingress controller or what ever you'd be running. So when proxying locally the cookie cannot be set correctly.
You can turn off secure while testing and turn it on once you have the https setup working.

Ok, i will try probably with Ingress, thanks for your help.

No problem 👍
Happy to help


failed to save D2_all to nifti files using the function dist.plot

Hello Team,
Thank you for providing the codes.
This may not be bugs.
I was able to calculate all_D22D array feature matrix (size of [145811, 223], ii.e. the same size as of all_mask ), and would save them into nifit files by using disp_plot.
The mask image has size [192,229,193].
The IDs is the list of 223 string, e.g. IDs=[ 'NCNC3185', 'NCNC3186', 'NCNC3188', 'NCNC3189', 'NCNC3190', 'NCNC3196', 'NCNC3197', 'NCNC3199', 'NCNC3200', 'NCNC3201', 'NCNC3203', 'NCNC3204', 'NCNC3206', 'NCNC3209',....]
When I used the following command,
mvc.dist_plot(all_dist = all_D2, all_mask = all_mask, subject_ids = IDs, feat_sub=[],save_results=True,out_dir=feature_results_dir, mask_f=mask_fname, mask_img=None, coordinate=(-10, -50, 10), vmin=None, vmax=5, hist_tr=100, nobin=100)
The error reads,
number of not NAN voxels:  145811
*** ValueError: NumPy boolean array indexing assignment cannot assign 145811 input values to the 1970710 output values where the mask is true
The error is due to the mismatch of the size of feature mat and the number of voxels in the mask file.
Do you have any suggestion in fixing this?
Thank you.
Ping

Thanks Ping, does projecting the data back into the mask and then saving directly through nibabel work as expected?

Hi Christopher,
Thank you for the reply.
In the dist.plot function, it seems to work fine up to the lines (#670 in
the mvcomp.py)
....
...
print("number of non NAN voxels: ", np.count_nonzero(d_out))
d_out = np.mean(all_dist, axis=-1)
m_out[oob_mask] = 0 # just zero the values that are fringe
I have not done saving through nibabel yet (my computer currently has some
issues and it has been frozen up.
Were the indices array needed in order to save it into nifiti file?
Thank you.
Ping
On Wed, Nov 6, 2024 at 6:31 AM Christopher J. Steele <
@.***> wrote:

Thanks Ping, does projecting the data back into the mask and then saving
directly through nibabel work as expected?
—
Reply to this email directly, view it on GitHub
https://github.com/neuralabc/mvcomp/issues/20#issuecomment-2459502525,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA43XNSFC6TW2JEOEYYHPIDZ7H4YRAVCNFSM6AAAAABQYRUVNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJZGUYDENJSGU
.
You are receiving this because you authored the thread.Message ID:
@.***>


add node.js to alpine image

could node.js as well be added to the alpine-based image? currently it's only included in the full version.
To support JS/TS scanning.
follow up to #9

could you publish the fix on the dockerhub?

I can do that. Was waiting to hear from @mobidev111 to see if it worked out right first, but might go ahead and push anyway if I don't hear back. 😄

@pawelmarkowski pushed. let me know if any issues.

@newtmitch works great! Thanks


fix backwards-incompatible change on gcsfuse

You'll probably have to make another dummy commit to the operator to trigger a rebuild

https://github.com/GoogleCloudPlatform/gcsfuse/blob/master/docs/semantics.md#name-conflicts


Bitfinex: Date argument ignored in getTrades()

My code goes like this:
String endDateString = "06/01/2017";
DateFormat df = new SimpleDateFormat("MM/dd/yyyy");
Date endDate = df.parse(endDateString);

Exchange exchange = ExchangeFactory.INSTANCE.createExchange(BitfinexExchange.class.getName());
MarketDataService marketDataService = exchange.getMarketDataService();

Trades trades = marketDataService.getTrades(CurrencyPair.ETH_BTC, endDate.getTime());

I get trades but the last trade occurs today while I'd expect it to occur on 06/01/2017. I know that the Bitfinex V2 'trades' service accepts start and end date parameters.
I tried the same code with other exchanges. I ran into either the same issue or just could not instantiate a MarketDataService. Any pointer would be appreciated.

In this lib implemented v1 for Bitfinex
@GET
  @Path("trades/{symbol}")
  BitfinexTrade[] getTrades(@PathParam("symbol") String symbol, @QueryParam("timestamp") long timestamp) throws IOException, BitfinexException;

Hello @fredfortier can you try passing in just the date object? If that doesn't work I can add a unit test and figure out what is going on.
Trades trades = marketDataService.getTrades(CurrencyPair.ETH_BTC, endDate);

Please let me know if this does or does not work. Thank you

@fredfortier You need to look at the implementation and see exactly what it's expecting. Every exchange is unique (unfortunately).


[BUG] Custom Months with days of 20 and less show up as days of 31

Describe the bug
When creating a month that has 20 days or less in it, the month is shown as 31 days in the Calendar.
To Reproduce
Steps to reproduce the behavior:
Create a custom month with a number of days of 20 or less.
Expected behavior
I feel that the Simple calendar should display a month with 20 days properly?
Screenshots

Foundry Information

Foundry Version: 11 patch 13
Game System: PF2E
Simple Calendar Version: eg 2.4.3
Simple Calendar Configuration: 5 day weeks, months with mostly 20 days, 22 months in a year.

Browser (please complete the following information):

Browser CHrome

Additional context
Add any other context about the problem here.

My guess is that the leap year rules are enabled and that it is a leap year. Under the leap year rules you can set the number of days a month has in a leap year or disable leap years all together.

Thank you! That was the issue, seems to be fixed after disabling leap years :)


Clip gizmo painters with viewport

Allows clipping the gizmo with the viewport to prevent it from rendering over other UI. Especially usefull with things like https://github.com/rerun-io/egui_tiles

Thanks!


Add the typing-extensions dependency

Description
Add the typing-extensions dependency
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[ ] Attached issue to pull request
[x] Changelog entry
[ ] Type annotations are present
[ ] Code is clear and sufficiently documented
[ ] No (preventable) type errors (check using make mypy or make mypy-diff)
[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Correct, in line with design
[ ] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )
[ ] If this PR fixes a race condition in the test suite, also push the fix to the relevant stable branche(s) (see test-fixes for more info)

Processing this pull request

Merged into branches master in 9adf93dc9e58306d947252762b65604b26e7faa1

Processing #6687.


optimize

hi, decided to try my hand at optimizing this module after doing some stuff with hughsk/moore. New version is ~5x faster and passes tests:thumbsup:
# old version 1000000 times
ok ~5.33 s (5 s + 328003895 ns)

# new version 1000000 times
ok ~1.01 s (1 s + 11613949 ns)

this is unarguably a more complicated algorithm to implement. I was actually planning on using semibran/delannoy to calculate the number of cells in the desired neighborhood, which would allow the algorithm to allocate the necessary memory beforehand. however, I found that it would be implausible to add that inline and I thought it would be a bad idea to add extra dependencies :grimacing:
I'll try to trim it down and see what I can come up with. if it works out, I might be able to get an extra speed boost.

:+1: Thanks for the PR, it looks great ! I'm a little too busy today but I'll merge and look more closely into it tomorrow.

This was merged and published as 1.0.1 on npm. 🎉
I credited you in the changelog and listed you as contributor on NPM.


feat(http-log): add a feature

Summary

Checklist

[ ] The Pull Request has tests
[ ] A changelog file has been added to CHANGELOG/unreleased/kong or adding skip-changelog label on PR if unnecessary. README.md (Please ping @vm-001 if you need help)
[ ] There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Full changelog

[Implement ...]

message:
type:
scope:
prs:
issues:

Changelog
message: add a feature Introduce a new fields a and b and c and d and e and f
type:
scope: Plugin
prs:
issues:
- 1000
- 1001
- 1002

Issue reference

FTI-1000 KAG-100

/update-changelog