@ojeytonwilliams looked at the list and my assigned files mixed up with @thecodingaviator /client/src/components/formHelpers/ and my /client/src/components/helpers/**. Just want to make sure my changes matter lol.

We seem to be wasting space currently by excessively padding Array objects. Even though array data is only aligned to 16 bytes, we for some reason align the object size to 64 bytes, then add more (un-aligned) space anyway. Hence the smallest array object is 80 bytes when it could be 48 (or 96 -> 64 when there are some elements). I can't think of a reason to do that, but maybe I'm missing something.

before:

julia> f() = for _ in 1:10^6; []; end

julia> @btime f()
  19.540 ms (1000000 allocations: 76.29 MiB)

after:

julia> @btime f()
  18.020 ms (1000000 allocations: 45.78 MiB)

Can you print out what self.embed(self.vocab) returns? If its a SymbolicTensor, then this is indeed unsupported and we should figure out if getting back a Symbolic Tensor is expected. I looked at the code and from https://github.com/ddangelov/Top2Vec/blob/master/top2vec/Top2Vec.py#L803 its a bit unclear which self.embed case is this failing for.

With Crystal:1.0.0 LLVM:10.0.0, Assignment is automatically typecasted c : Float64 = 0_i32

Function argument is automatically typecasted

def func1 ( a : Float64 )
  a
end
func1(0_i32)

But, return type casting is not done automatically. This causes compilation error - "Error: method top-level func2 must return Float64 but it is returning Int32" def func2 : Float64

Return type as Float64 is not accepted; Compilation error for func2

0 end

@asterite have clarified that the behavior is as expected with the current version. But it would be logical to have same rules applied for all these cases. While it is valid point that user would expect same type that is being enforced for the return type, then the same rule would be expected to be applied for assignment and function arg cases as well.

https://forum.crystal-lang.org/t/integer-return-type-not-typecasted-only-when-returning-from-function/3402

Since we can not start a redis server on port 0. See https://github.com/redis/redis/blob/unstable/src/server.c#L3192

Also masterport is an int. It seems better to use atoi. It's more intuitive and reduces the code. (Minor cleanup)

ref link: https://github.com/redis/redis/pull/7842

replaces https://github.com/moby/libnetwork/pull/2590 closes https://github.com/moby/libnetwork/pull/2590

Accessible via scm_plugin method.

Summary

Provides a way to access the deployment's Capistrano::SCM::Plugin instance from within a deploy script. (via an scm_plugin method)

My use case for this was that I wanted to invoke git:check on my local machine, from which I trigger the deployment. As my local machine does not have a release role, it isn't possible to simply invoke the built-in rake task.

Short checklist

• [x] Did you run bundle exec rubocop -a to fix linter issues?
• [x] If relevant, did you create a test?
• [x] Did you confirm that the RSpec tests pass?

Oh and the issue with the empty articles should be already fixed by https://github.com/kovidgoyal/calibre/commit/6c3f1ebb5f060895bd8dc79f193479ee07d0a26e

android.useAndroidX=true

is already there by default

android.enableJetifier=true

Yes! that's solve the problem. Signs that Fast Android Networking library need to be modernized to androidX

Thank you

It fails often, but not 100% reliably.

FWIW, I tried it locally 50 times. It passed always. :man_shrugging:

• Fix processing of Atlantic recipes as they were producing blank articles
• Seperate out magazine & website logic to respective recipes

I keep them identical deliberately, so changes to one can be made to the other easily. Apart from the index processing the actual article markup processing should be identical in the two recipes. Could you please resubmit your PR with just the changes you need without splitting out the magazine/web parts.

Ok, did it! But with this change I had to modify one validation in server > lib > pushConfig.js, otherwise the custom certificates wouldn't work in unregistered servers.

You can call ujson.loads(resp.text)?

Maybe I'm barking up the wrong tree. This seems like a fix https://github.com/JuliaLang/julia/pull/41286

Fixes https://github.com/JuliaLang/julia/issues/41281

It seems like the case in https://github.com/JuliaLang/julia/issues/41281 that results in @time reporting >100% compilation time is fixed by pre-running the timing sampling lines within @time to ensure they're compiled(?)

Perhaps instead of this PR, I wondered if there's some type instability/invalidation going on that could be fixed, given that @time 1+1 is baked into the sysimage? Or, perhaps this PR is a failsafe solution?

Master

julia> @time map(x -> 2x, 1:3);
  0.035300 seconds (52.03 k allocations: 3.258 MiB, 107.03% compilation time)

julia> @time map(x -> 2x, 1:3);
  0.028745 seconds (49.72 k allocations: 3.057 MiB, 99.36% compilation time)

julia> x = rand(2,2);

julia> @time x * x;
  0.651758 seconds (2.54 M allocations: 140.827 MiB, 5.07% gc time, 99.95% compilation time)

julia> @time x * x;
  0.000006 seconds (1 allocation: 112 bytes)

This PR

julia> @time map(x -> 2x, 1:3);
  0.032076 seconds (52.04 k allocations: 3.241 MiB, 98.54% compilation time)

julia> @time map(x -> 2x, 1:3);
  0.029221 seconds (49.72 k allocations: 3.057 MiB, 99.45% compilation time)

julia> x = rand(2,2);

julia> @time x * x;
  0.632906 seconds (2.54 M allocations: 140.827 MiB, 7.51% gc time, 99.94% compilation time)

julia> @time x * x;
  0.000005 seconds (1 allocation: 112 bytes)

If anyone has any other @time calls that result in >100% I'd happily test them with this

I'll be switching to Visual Studio Code.

You don't see the irony here on this subject that Bing and VSCode are developed by the same company?

@marekr That's... kind of the point. I love Bing, I use it as my primary search engine. I'm a huge Microsoft fan. I love almost all of their products and the way they run their business is exceptional compared to others (because I've put much research into it and I've learned each alternative and product and know what I like, as compared to blindly following what's been given to me). I know that me leaving doesn't make a hint of difference, but, after all, the removal of this feature didn't make a hint of difference either did it? Or any of this complaining? Or, heck, what's even the point of talking about it? Like you said, the dev can do whatever he wants. As such, we can also do whatever we want.

I mean, if we're going to ignore the vocal part of the userbase, why even bother having opinions, right? Sorry, that's jumping to conclusions, but you can see where I'm going. It's a huge pet peeve of mine that a developer would make something open source, allow the community to contribute and discuss, and then when the community actually does that, they get shunned and pushed away like we're not supposed to talk about it or something.

Instead of taking in a new struct CompleteMultipartUploadOptions we should take just PutObjectOptions{} all the necessary fields are already present.

That's interesting. The fact that you were getting the ICE consistently would seem to rule out any kind of transient I/O issue - Rust would need to fail to open /home/rana/.cargo/registry/src/github.com-1ecc6299db9ec823/bitpacking-0.8.4/src/lib.rs each time you got the ICE.

I've opened https://github.com/rust-lang/rust/issues/86480 to track an issue that I've discovered from investigation this. It's possible that these two issues are actually the same, but I'm not certain.

Apart from this PR that I made after seeing the new plugin in the update from ohmyzsh, I'm wondering if it's not over-engineering for a basic functionality provided by grep ?

So we actually have 2 plugins to do that:

• aliases
• alias-finder

• Fix processing of Atlantic recipes as they were producing blank articles
• Seperate out magazine & website logic to respective recipes

guess_head_span ends up calling ensure_source_file_source_present, which calls add_external_src. If the source file of the span is an imported file, then whether or not this method succeeds depends on the current file on disk:

https://github.com/rust-lang/rust/blob/0f6ba39fd89cff295067d974c49fc64b0b52ad18/compiler/rustc_span/src/lib.rs#L1447-L1451

However, the hash of the external crate depends on the hash of the file at the time the external crate was compiled, not the time the current crate is compiled. If the external crate is a Cargo dependency (in ~/.cargo/registry), then changing a file in the dependency will not cause it to be re-built, allowing a new compilation session to read in a different file than the one used to originally compile the external crate.

Since guess_head_span falls back to the passed-in span if reading the source file fails, the span that we end up using depends on global untracked state (the current contents of an external crate's file on disk).

No change to /home/rana/.cargo/registry/src/github.com-1ecc6299db9ec823/bitpacking-0.8.4/src/lib.rs. That's stable. I don't edit it.

/home/rana/.cargo is on an ordinary partition as well. Here is the output from lsblk.

rana@aum:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 238.5G  0 disk 
└─sda1        8:1    0 238.5G  0 part 
sr0          11:0    1  1024M  0 rom  
nvme0n1     259:0    0   1.1T  0 disk 
├─nvme0n1p1 259:1    0   512M  0 part /boot/efi
└─nvme0n1p2 259:2    0   1.1T  0 part /

The workflow was only to add new tests, and use the in-IDE "Run test" link shown in the snapshot.

The current output window command (that's currently working) shows:

> Executing task: cargo test -- --nocapture num_bits_pkg <

    Finished test [unoptimized + debuginfo] target(s) in 0.09s
     Running unittests (target/debug/deps/tsr-6150d47f1fc41f28)

running 3 tests
num_bits_sorted 13
num_bits_sorted 13
num_bits_sorted 13
test pck::test::num_bits_pkg_2 ... ok
test pck::test::num_bits_pkg_3 ... ok
test pck::test::num_bits_pkg ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 15 filtered out; finished in 0.00s

When I get back to that workflow of adding new tests and code I expect it to crash as consistently as it did before. But I also plan to stop using nightly because of it.

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

In the following questions <cask> is the token of the cask you're submitting.

After making all changes to a cask, verify:

• [x] The submission is for a stable version or documented exception.
• [x] brew audit --cask <cask> is error-free.
• [x] brew style --fix <cask> reports no offenses.

Additionally, if adding a new cask:

• [x] Named the cask according to the token reference.
• [x] Checked the cask was not already refused.
• [x] Checked the cask is submitted to the correct repo.
• [x] brew audit --new-cask <cask> worked successfully.
• [x] brew install --cask <cask> worked successfully.
• [x] brew uninstall --cask <cask> worked successfully.