[Bug]: GCC building failed when following the Contribution guidelines

Issue Type
Build/Install
Modules Involved
Others
Have you reproduced the bug with SPU HEAD?
Yes
Have you searched existing issues?
Yes
SPU Version
0.8.0dev20240202
OS Platform and Distribution
Ubuntu 20.04.4 LTS
Python Version
3.8.13
Compiler Version
GCC 9.4.0
Current Behavior?
Hi,
I'm following the Contribution guidelines to build SPU from source code with the command bazel build //... -c opt and meets the error:
WARNING: /shared/lab/spu/libspu/compiler/front_end/BUILD.bazel:17:15: in cc_library rule //libspu/compiler/front_end:hlo_importer: Target '//libspu/compiler/front_end:hlo_importer' violates visibility of target '@xla//xla/service/gpu:dot_dimension_sorter'. Continuing because --nocheck_visibility is active
INFO: Analyzed 521 targets (0 packages loaded, 0 targets configured).
INFO: Found 521 targets...
ERROR: /root/.cache/bazel/_bazel_root/e9d0df940c1be53c92c3231724d94151/external/yacl/yacl/crypto/utils/BUILD.bazel:19:16: Compiling yacl/crypto/utils/rand.cc failed: (Exit 1): gcc failed: error executing command (from target @yacl//yacl/crypto/utils:rand) /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 54 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from external/yacl/yacl/crypto/utils/rand.h:25,
                 from external/yacl/yacl/crypto/utils/rand.cc:15:
external/yacl/yacl/base/dynamic_bitset.h: In instantiation of 'constexpr yacl::dynamic_bitset<Block, Allocator>::dynamic_bitset(yacl::dynamic_bitset<Block, Allocator>::size_type, uint128_t, const allocator_type&) [with Block = __int128 unsigned; Allocator = std::allocator<__int128 unsigned>; yacl::dynamic_bitset<Block, Allocator>::size_type = long unsigned int; uint128_t = __int128 unsigned; yacl::dynamic_bitset<Block, Allocator>::allocator_type = std::allocator<__int128 unsigned>]':
external/yacl/yacl/crypto/utils/rand.cc:102:1:   required from here
external/yacl/yacl/base/dynamic_bitset.h:2296:20: error: division by zero is not a constant expression
 2296 |   constexpr size_t init_val_required_blocks = u128_bits_number / bits_per_block;
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~
INFO: Elapsed time: 11.492s, Critical Path: 9.66s
INFO: 174 processes: 64 internal, 110 processwrapper-sandbox.
FAILED: Build did NOT complete successfully

Standalone code to reproduce the issue
See above.

Relevant log output
No response

gcc 9.4.0 is not satisfied with the build prerequisite

gcc 9.4.0 is not satisfied with the build prerequisite

Thank you for pointing this, it can be built successfully now.


Add a checkbox not to verify a certificate

My ES cluster is a temporary one and does not have a valid certificate. I am seeing an error message:
app.js?v=1:34 GET https://example.com:9200/_cluster/state net::ERR_CERT_AUTHORITY_INVALID

The workaround is to access https://example.com:9200 from another browser window and click proceed button. Is there a way to make skipping SSL cert check in a more user-friendly way, e.g. checkbox?

This issue is more related to certification for Elasticsearch cluster. Elasticsearch curl/API can only work if the authorized connection string is provided.

I found two workarounds for this:

Open direction connection to Elastic in the separate window and allow the cert
Add a cert to the trust store locally


tsd --save flag modifies permissions of parent directories unnecessarily

Using tsd 0.6.0-beta.5.
I have a directory structure that looks like this: /var/www/applications/my-app/tsd.json. Anytime I run tsd with the --save flag, it sets the my-app folder's permissions to 744. As a result, the apache user can no longer execute the application contained in my-app.
The problem appears to be caused by this line.
I can probably put together a pull request to fix the issue, but in order to do so, I have a couple of questions.

Why does tsd traverse the parent directories? Is there any reason it couldn't just start from the project root where it is being run?

Why is tsd modifying permissions on existing directories?

Why is tsd specifying an exact set of permissions rather than just u+w in order to guarantee write permissions exist?

I spent quite a while (several days) on this seemingly random failure, and want to make sure others don't run into the same thing. :smile:
Thanks!

Unfortunately others do run into the same thing. We have been struggling with this issue for months now. After each tsd call (from cli as well as with gulp-tsd) we need to change permissions to our own folders back again :-(.
My only question is: Why does tsd have to touch the permissions at all? Default mkdir() call creates the directory under default permissions (given by process' umask). Why is not this sufficient?

The same happens in our setup. Any chance this bug will be fixed soon?

Spent also several hours debugging this. I think it's a critical bug since it makes website completely unusable.


Maintain whitespace or insert whitespace with .Text()

My original question was too vague, so let me try to refine it.  I am attempting to obtain the text from a "set" of elements obtained using .NextUntil().  This text will be for a lucene index for searching.  The issue I am having is that the Text() call correctly strips the html from the set but what I need is to insert some whitespace to maintain separation between words from different elements:

this is a para

this is another para

... becomes
this is a parathis is another para
... instead of the desired output of
this is a para this is another para
What is the best way to accomplish this?
Cheers :)

Is there a general way to get all the inner text from any given CQ? I'm looking for a solution that can handle stuff like a CQ with multiple root elements, for example.


RFC: add the Freeze trait to libcore/libstd

Rendered
There was some pre RFC discussion here.

Isn't LLVM's name for turning uninit data into a fixed-but-arbitrary data value also called "freeze"?
If so, perhaps we should use some other name.
This is a bikeshed, but seems like a fair one.

@Lokathor Totally fair. Freeze also use to be a public API long ago, so googling "rust freeze trait" may yield some inaccurate information. I'll add that to the unresolved questions.

Yeah those are two totally different uses of the same word. :/

To get bikeshedding rolling, how about Final, Immut, NoAlias, or ReadOnly? The last two match the llvm attributes that &T would have.
Additionally, I think libcore must provide a PhantomUnfrozen as the user workaround is a pessimization that would remove the noalias readonly attributes.

Additionally, I think libcore must provide a PhantomUnfrozen as the user workaround is a pessimization that would remove the noalias readonly attributes.

That would seem to imply that there are two kinds of !Freeze types:

'really !Freeze, which affects both Rust mutable/immutable memory placement and LLVM attributes
'psuedo-!Freeze, which does not affect LLVM attributes but causes rustc to do 'something'.

What are the use cases for PhantomUnfrozen?

The only use case for PhantomUnfrozen is to allow crate authors to reserve some extra flexibility in their implementations without breaking downstream crates. In other words, to prevent folks from depending on one or more of a crate author's types being Freeze.

So, what if people just opted into Freeze instead using a normal Derive, like how it works with Copy

I think most of the arguments for having Unpin, Sync, and Send send not work the same as Copy would also apply to Freeze.
For example:
#[derive(Freeze)]
pub struct Bar<T>(*const T);

Would not be Freeze if T is not Freeze. That is incorrect.

That's just because the derivation system is overly simplistic and needs to be improved.
The fundamental idea that trait impls are a public part of the API of a type, thus also being a stability hazard that designers should have to opt in to, stands.

To get bikeshedding rolling, how about Final, Immut, NoAlias, or ReadOnly? The last two match the llvm attributes that &T would have.

I also think the "shallow"/"direct" aspect in the RFC should be part of the name, or else a lot of people will misinterpret this trait name as being about deep immutability the first time they see it. Unless I'm missing a huge part of the motivation, nobody should be writing this trait name very often, so I'm inclined toward relatively lengthy names. My current favorite would be ShallowImmutable and (if we need it) PhantomShallowMutable.
I dislike Final because of its established use in other languages for inheritance stuff, and NoAlias because (unless I've horribly misunderstood something) this has nothing at all to do with whether aliases can exist, only with whether mutation can be done through those aliases. I have no complaints with ReadOnly.

Freeze is unsafe. Freeze has no methods. Freeze is about the structure of a type. In the above example, Bar is always correct to be Freeze. Whether or not it should be PartialEq, Hash, Copy, etc. cannot be known without more information. IMO, it shares much more in common with Send/Sync than Copy. One thing it does share with Copy is that lambdas would need to automatically impl Freeze.

The fundamental idea that trait impls are a public part of the API of a type, thus also being a stability hazard that designers should have to opt in to, stands.

I do not feel that this is a substantial enough problem to block adoption, and I don't think #[derive(..)] is a good option. It is not a feature that will see widespread usage. I would be interested in more opinions though.

That would seem to imply that there are two kinds of !Freeze types

We could reduce the number of kinds of !Freeze types to 1 by placing a PhantomUnfrozen in
UnsafeCell. That might somewhat harm teachability tho.

My current favorite would be ShallowImmutable

I like that too.

I think libcore must provide a PhantomUnfrozen as the user workaround is a

PhantomData<UnsafeCell<()>> should do it.

PhantomData<UnsafeCell<()>> should do it.

This wouldn't work due to this impl (necessary since Box/Vec/etc have a PhantomData<T> in their memory layout):
unsafe impl<T: ?Sized> Freeze for PhantomData<T> {}

unsafe impl<T: ?Sized> Freeze for PhantomData<T> {}

Interesting, I did not know this existed.

Is it possible to use specialization to make PhantomData<UnsafeCell<()>> impl !Freeze? (I'm way behind on what subsets of specializations are sound/unstable/maybe-stabilizable/exposable-in-std)

Wht about just using plain UnsafeCell<()> as field?

That would seem to imply that there are two kinds of !Freeze types

Hm. I have to say a non-attribute-affecting Freeze still sounds like a rather big hack though. We'd basically need a duplicate of that trait internally in the compiler to determine whether to add attributes.

Wht about just using plain UnsafeCell<()> as field?

It sounds like the consensus is that PhantomUnfrozen as written, is not a great idea.
Given that the user can write a version of PhantomUnfrozen in their own code, I am gonna suggest it gets removed entirely.
#[repr(transparent)]
pub struct PhantomUnfrozen(UnsafeCell<()>);
unsafe impl Sync for PhantomUnfrozen {}

The downside to removing PhantomUnfrozen, whose sole concern is future compatibility, is that the user code version impacts code gen/optimization a bit by removing the noalias and readonly llvm attributes.
In the future, if anyone really wants a version of PhantomUnfrozen that doesn't impact optimization a separate RFC can be written.

I am very much in favor of this RFC. I use this exact trait in Sundial GC. Although it's not a stability blocker, since I use every nightly feature under the sun, and need GAT before I can think about targeting stable.

@Avi-D-coder The Immutable trait is not equivalent to Freeze. You are implementing !Immutable for &T and &mut T, while !Freeze is only implemented for UnsafeCell<T>.

Yes, but I should should split those into their own trait. And they are only needed due to other limitations of the current type system namely GAT.

This seems like a useful thing to have for some applications, but I'm concerned about the stability hazard it poses to library authors. Under this RFC, if I'm writing a library and I change a private field to be !Freeze, wouldn't I need to bump my major version number?
Send and Sync technically have the same problem, but they are deeply entrenched and relevant to a lot of Rust code. If this is going to become stable, it seems like there's going to need to be a huge education effort to make library authors aware of the existence of this trait. (Even if it's not at all relevant to their libraries purpose.)
I wonder if there is a more general version of this where libraries can create their own auto traits, and then users can explicitly opt-in to potential instability.

Yes, this trait should absolutely be only an opt in, with a compiler error if you opt in to it for a type that would be invalid.

As an opt in trait, it loses most of it's utility.
If it's opt in, users of my library would have to wrap foreign types in new types, just to GC them.
The stability story around auto traits is never good, but there are far too many things you can't do without them.

If I were to bikeshed, I'd use Stop. It have a similar meaning to Freeze, 4 characters like Sync and Send and also start with S.
But doesn't this look familiar to Pin?

Pin means "can't move", Freeze means "no T or &T mutation"

Pin means "can't move", Freeze means "no T or &T mutation"

I does sounds the same to be, I may have thought Freeze is just a synonym to Pin first if you didn't mention the difference. What I thought was? If something was frozen, it also can't move right? We may need to be careful on the documentation later to state the difference between them to avoid confusion.

If something was frozen, it also can't move right?

An ice cube 🧊 is frozen but you can easily move it around 🙃. The two concepts are orthogonal.
Seriously, as Freeze basically means cell-free. All primitive types like u32 are frozen as well as Unpin.

Another use case for Freeze maybe using generics in consts:
struct Generic<T: 'static>(&'static T);

trait ConstDefault {
    const DEFAULT: Self;
}

impl<T: ConstDefault + Copy + 'static> ConstDefault for Generic<T> {
    const DEFAULT: Self = Generic(&T::DEFAULT);
    // error[E0492]: cannot borrow a constant which may contain interior mutability, create a static instead
    //  --> src/lib.rs:8:35
    //   |
    // 8 |     const DEFAULT: Self = Generic(&T::DEFAULT);
    //   |
}

(playground)

I have another use case.
I have plans for an append-only log data structure that can have multiple writers, while retaining lock-free Vec-like reads (slice derefs, and single pointer dereferencing). I believe that having Freeze+Unpin trait bounds on my items should make it safe for me to copy their bytes to a new allocation when I reach capacity (I'll be manually dropping). By doing this, I can keep my old references valid until they are dropped (I reference counting access) while new writes and references can occur on the new allocation. I'm hoping this data structure will make for a great transaction log for an in-memory database or the perfect centerpiece for an event source application.
Admittedly, Freeze and Unpin (and Sync) would have a pretty high bar for someone trying to understand my interface, but I'd much rather standardize on core traits than have my users puzzle over trait bounds that I had to create.

The lang team discussed this in our most recent meeting and has a handful of thoughts. For one, we agreed that the name Freeze isn't super clear, and for how rare it would be to name, we'd prefer something more descriptive like NoInteriorMutability.
However, our most significant concern was around backwards compatibility. This RFC proposes to expose a new auto trait which makes it backwards-incompatible to add a field with interior mutability to an existing type which previously had no interior mutability. This proposal would require library authors who may want to add interior mutability in the future to mark their types with PhantomData<UnsafeCell<()>>. The RFC further addresses this restriction in two places:
Under "drawbacks":

Crate owners have to now commit to an interior mutability story, or risk breaking changes in the future."

Under "rationale and alternatives":

Crate owners who incidentally have Freeze types in their API, and wish to add in interior mutability at a later date, can do so by simply adding any pointer based indirection (e.g. Box) to any parts of their type which may be modified through an immutable reference to avoid breaking changes. Moreover, adding interior mutability is often already a breaking change. UnsafeCell is not Sync nor RefUnwindSafe, and is invariant over T.

The team felt hesitant about the idea of adding yet another backwards compatibility footgun to library authors. Adding new types with interior mutability to a structure is a common operation, and requiring library authors to stick UnsafeCell<PhantomData<()>> everywhere or add runtime penalties via Box feels more burdensome than is justified in order to unblock the relatively more niche use-case this RFC enables.
Personally, I think the best way forward here would be to start with an external crate which offers such a trait, implements it for common types, an unsafe wrapper type, and perhaps includes a derive macro. This is less ergonomic and possibly more error-prone than the auto-trait solution proposed by this RFC, but I believe it is the correct trade-off in this case. With that in mind:
@rfcbot fcp close

Wanted to note that "makes it backwards-incompatible to add a field with interior mutability to an existing type which previously had no interior mutability" is not quite true -- it is already backwards incompatible to do so with some types (like Cell/RefCell) though not with Mutex. See https://github.com/rust-lang/rust/issues/60715#issuecomment-491533461 for example for a prior note on this.

@rfcbot reviewed
If this RFC is reopened in the future, I would want it to discuss PhantomData in more detail. Specifically: PhantomData<T> has impl Send if T is Send, impl Sync if T is Sync, impl Unpin if T is Unpin, impl UnwindSafe if T is UnwindSafe. But, libcore's current Freeze trait has an impl for PhantomData<T> regardless of whether T is Freeze. Before stabilizing we'd want to evaluate the rationale of that.

On a related note, will auto traits or something like them ever be stabilized?

Personally, I think the best way forward here would be to start with an external crate which offers such a trait, implements it for common types, an unsafe wrapper type, and perhaps includes a derive macro.

However, this loses integration with the language, disallowing, for example, using T: Freeze in consts.

@WaffleLapkin that's a good point, this is more appealing as part of a more general support for constants or statics. However, I don't believe that there are rules that require statics to be freeze in general, right? I think it's more like if the static is freeze, we can put it in a read-only section (and otherwise we cannot).

@rfcbot reviewed

@nikomatsakis yes, statics and consts are not required to be Freeze.
However, if you want to borrow constant value in a generic context, I'll have a lot of problems. statics are not available in a generic context. While consts are available in generic contexts, it's not possible to borrow it if it's not Freeze (error[E0492]: cannot borrow a constant which may contain interior mutability, create a static instead).
For my particular use-case, I've found a workaround, it's a bit annoying.

Genuine question: is there a reason why Freeze can't exist while also adopting a convention of its implementation not being semver-compatible?
Like, it technically already exists as a feature of the language. And we can technically already observe it in code through the restriction on const borrowing. For a relatively obscure feature, I don't see why its existence would require everyone to add PhantomCell like fields to their types.

I agree 💯.
We shouldn't let semver constrain language features. Compatibility is important, but nothing prevents me as a author from making a breaking change in a minor version. Ultimately semver us a useful convention followed by authors, not a guarantee upheld by the compiler.

Semver is a bit more than a convention considering how cargo is designed to reduce the number of versions used based upon it, and there's a very specific definition of breaking changes that could theoretically be applied algorithmically to Rust code. But, I agree in this case that we could make an exception.

There is some desire to use Freeze for some copy-on-write data structures. However, as I noted on Zulip, I think Freeze alone is not sufficient for this.
I somehow feel like https://github.com/rust-lang/rust/issues/49206 is related, because this is about observing the address at which some shared data lies, but I cannot put my finger onto it or make this precise.

Approving on behalf of withoutboats, as per https://github.com/rust-lang/team/pull/526.

We should reconsider stabilizing some sort of built-in Freeze. As of today, it's impossible to declare a generic value parameter in a const fn and to take its address, since it may have interior mutability. We shouldn't hamstring generics in const for a possibility we could opt-out of if given the chance. Adding interior mutability is already a breaking change because of this, so I really don't buy the semver argument.

The const fn situation is a temporary one, so it is IMO not a good argument for permanently stabilizing Freeze.
Think of it this way: we could have just disallowed &T in const fn entirely. But to allow at least some more code, we decided to allow &impl Freeze and only disallow interior mutable and generic references. That's way better than disallowing all references. I can understand it is frustrating though.

I recently discovered? another use-case for Freeze that has nothing to do with shared data https://internals.rust-lang.org/t/interior-mutability-reflection/18198

I'm currently in the process of researching sort implementations. And have ideas I want to and am already upstreaming into the standard library. One important concept is something I call observable_is_less. The user can provide a custom comparison function either by implementing Ord or by calling sort_by. For types that allow interior mutability as marked by containing an UnsafeCell, this user provided comparison function could mutate the stack value. No matter what path the execution takes, or even if Ord is implemented incorrectly. One invariant that needs to be upheld by the sort implementations is that every possible write to the stack value of the type, has to be 'observed' in the user provided slice when the sort function returns, either normally or via panic. This gets tricky when working with temporary memory, eg. for merging. Certain optimisations would be invalid for such types, for example they may compare two values, but might skip writing one of them into temporary memory because it has already been written before. And then later write that temporary memory over parts of the input slice. In that case one or more 'writes' as per calls to is_less would have been missed. This leads to unexpected behaviour and even possibly UB.

Right now, I'm using Copy via specialisation to determine what types these optimisations are safe to do for, but it would be great and benchmarks suggest beneficial even for types such as String to allow such optimisations. However I'm not aware of any way to write such a function fn has_interior_mutability<T>() -> bool. The compiler already has this information, it would be great to somehow get access to that information. IIRC there is a way to 'check' if a type has interior mutability by seeing if a function compiles that would be invariant over a shared reference to such type. But such check can only cause a compiler error, not provide runtime/compile-time branching.

Crate owners have to now commit to an interior mutability story, or risk breaking changes in the future."

They already do, there is more cases than the const fn one, that break when such a type is added eg:
pub struct SomeType<'a> {
    val: &'a i32,
    // x: std::cell::Cell<&'a i32>, // Enable this for error.
}

pub fn assert_covariance<'x: 'y, 'y>(x: SomeType<'x>) -> SomeType<'y> {
    //  This function only compiles for covariant types.
    x
}

If the authors choose to add the uncommented line, the code stops compiling. I see a clear benefit here, and a dubious reason not to add something like this.

That is because the variance between &'a i32 and Cell<&'a i32> is different. That has nothing to do with interior mutability.

Well the variance here, changes as direct result of transitively containing UnsafeCell or not. Arguably that's the same effect for users.

If the main concern is code breaking. I suggest this alternative design:
(const?) fn has_direct_interior_mutability<T>() -> bool;

If we add such a function to the standard library it would serve the purpose of allowing such optimisations, without building things that will stop compiling if users add a new member. With constant propagation and folding the optimiser ought to be able to generate efficient code depending on the types property. To motivate it, here is what a simple type wrapping a u64 not marked copy would loose out on potential performance, rust_new_stable_no is with the relevant optimisations disabled for u64:

Well the variance here, changes as direct result of transitively containing UnsafeCell or not. Arguably that's the same effect for users.

Invariance can arise without interior mutability.  So it's really unrelated to this discussion.

Right now, I'm using Copy via specialisation

It makes me very sad that Copy is used as a marker for absence of interior mutability, these two concepts are entirely orthogonal and there is no fundamental reason that Rust can't have Copy !Freeze types. The fact that people make assumptions like this will make future evolution of some parts of Rust a lot harder. :(  (see https://github.com/rust-lang/rust/issues/25053)

Invariance can arise without interior mutability. So it's really unrelated to this discussion.

It seems, I poorly explained my point. My understanding is, that the main reason this proposal was declined, was a worry that it would make it easier for library Authors to inadvertently break SemVer. I gave the example to demonstrate, that something very similar, already happens today on stable.

It makes me very sad that Copy is used as a marker for absence of interior mutability.

It's a tricky situation, here are the options I'm seeing:

A) Ignore the possible optimisations.
B) Adjust the code so it is safe for types with direct interior mutability.
C) Add an unsafe marker trait.

A, is IMO a bad fit for Rust, a language that that markets itself as an efficiently way to exploit hardware resources. I tried B, and have not had good success, even the failed attempts I had, made the code significantly more complex. That's not a property that should be ignored, especially because unsafe code is being used. C, is really problematic too. It creates this two class 'society', where builtin u64 ... sort(), and struct X{u32: a, u32: b}  ... sort_by_key(|x| x.a) would have vastly different performance.
Is using Copy a hack, absolutely! Are the alternatives better, I would argue, that no, the alternatives are worse. However there exists a solution, the compiler already knows the required information, it only has to surface it to the user. Then all these problems go away, including:

These two concepts are entirely orthogonal and there is no fundamental reason that Rust can't have Copy !Freeze types.

And if I understood correctly, Orson Peters the author of pdqsort who is currently working on glidesort came across the same problem and came up with the same 'solution' of limiting certain optimisations to Copy types. So I argue, if we don't provide a good solution, people will use the bad options, creating further problems down the line.

Invariance can arise without interior mutability. So it's really unrelated to this discussion.

Workarounds, such as assert_covariance, seem to rely on the assumption that all covariant type constructors prevent interior mutability. Is it therefore fair to rephrase @RalfJung's criticism that covariance is merely a sufficient (but not a necessary condition) for the absence of interior mutability? Or is the criticism that covariance cannot rule out interior mutability, and checks such as assert_covariance are therefore doomed to begin with?

I meant to say that we are not making a guarantee that covariance has any relation with UnsafeCell either way.
In fact I don't even know what you mean by this question. Covariance is a property of type constructors, not type. The following type has interior mutability but is covariant in its only agument:
struct MyType<T>(T, Cell<i32>);

Thank you very much for clarifying.

It would be great to have this for zerocopy; we need to reason about this for things like https://github.com/google/zerocopy/issues/8 and https://github.com/google/zerocopy/issues/251.

This is a closed PR, please stop posting here, it's really not useful. https://github.com/rust-lang/rust/issues/60715 is a more appropriate place to comment.


Fixed and added new lines, translation to Brazilian Portuguese

Several new lines translated to Brazilian Portuguese and
Non-standardized translations of old lines were corrected to conform to a standardization.

@viniciusmi00 I will release a beta of BatFi 2.11 with your fixes today :)


Fix tests with Firefox >= 67

Add preference to keep proxying localhost with newer Firefox versions.

Latest Travis CI builds were failing because of this, e.g.:
https://travis-ci.com/zaproxy/zap-hud/jobs/202457295#L565


Lua error

Hello,
while using the Armory addon to link a spell from the Spellbook, i get this error from Dressup lol :
4x DressUp\comms.lua:189: attempt to index local 'link' (a number value)
DressUp\comms.lua:189: in function `HandleModifiedItemClick'
[string ":OnClick"]:2: in function <[string ":OnClick"]:1>
Locals:
link = 79134
(*temporary) = nil
(*temporary) = 79134
(*temporary) = nil
(*temporary) = "attempt to index local 'link' (a number value)"
OriginalHandleModifiedItemClick =  defined @FrameXML\ItemButtonTemplate.lua:135
could just be a taint from Armory itself but i prefer to warn both addon authors :p

Probably a bug in this addon and even if it's not I can at least add extra checks to make sure it doesn't happen again.


Add DB

PR title
Status
READY/IN DEVELOPMENT/HOLD
Description
A few sentences describing the overall goals of the pull request's commits.
Related PRs
List related PRs against other branches:

branch
PR

other_pr_production
link

other_pr_master
link

Todos

[ ] Tests
[ ] Documentation

Steps to Test or Reproduce
Outline the steps to test or reproduce the PR here.
git pull --prune
git checkout <feature_branch>
pytest --showlocals

Impacted Areas in Application
List general components of the application that this PR will affect:

:white_check_mark: Build ebook_homebrew 1.0.371 completed (commit https://github.com/tubone24/ebook_homebrew/commit/69b75fc4e9 by @)

:white_check_mark: Build ebook_homebrew 1.0.372 completed (commit https://github.com/tubone24/ebook_homebrew/commit/34176e2cfe by @)

:x: Build ebook_homebrew 1.0.373 failed (commit https://github.com/tubone24/ebook_homebrew/commit/505311347a by @)

:x: Build ebook_homebrew 1.0.374 failed (commit https://github.com/tubone24/ebook_homebrew/commit/f93ac32f67 by @)

:x: Build ebook_homebrew 1.0.375 failed (commit https://github.com/tubone24/ebook_homebrew/commit/bb93b81400 by @)

:white_check_mark: Build ebook_homebrew 1.0.376 completed (commit https://github.com/tubone24/ebook_homebrew/commit/bb93b81400 by @)

:white_check_mark: Build ebook_homebrew 1.0.377 completed (commit https://github.com/tubone24/ebook_homebrew/commit/e956b796da by @)

:x: Build ebook_homebrew 1.0.378 failed (commit https://github.com/tubone24/ebook_homebrew/commit/ac52374e56 by @)

:white_check_mark: Build ebook_homebrew 1.0.379 completed (commit https://github.com/tubone24/ebook_homebrew/commit/ac52374e56 by @)

This pull request introduces 1 alert when merging c3ea879ed3005ef42bf33c33afe9ed0c61c99a42 into 4e1ee804f468cd6ca5200bb89ed5b130de045c8e - view on LGTM.com
new alerts:

1 for Unused import

This project has automated code review enabled, but doesn't use the LGTM GitHub App. Migrate over by installing the app. Read about the benefits of migrating to GitHub Apps in the blog.

Comment posted by LGTM.com


allow to skip setup on debuggable builds by tapping the Welcome message

Importing android.os.Build may increase attack surface, should be carefully evaluated


Move replacement chance from ReplacementAccentComponent to ReplacementAccentPrototype

About the PR

title
fixes #27902
Why / Balance

issue
Technical details

Media

[ ] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

:cl:

fix: Fixed bug with pathological liar and zombie accents.

Update brench from master, pls


Discontinuity in FollowJointTrajectory Velocity in ROS 2

Hi Everyone,
I’m currently working on controlling a UR5e robot using ROS. Initially, I used ROS Noetic (ROS 1), which was quite straightforward. However, with the End-of-Life (EOL) for ROS 1 approaching, we’ve started migrating to ROS 2, which is fine overall.
Here’s the issue I’m encountering in ROS 2 (simulation): I’m sending the robot a series of random trajectories (position and velocity) using an ActionClient. Each trajectory is designed to take 6 seconds to reach its goal, but my goal is to switch trajectories before the 6-second mark. In ROS 1 (Noetic), this was handled smoothly—there was a seamless transition between trajectories, even if the previous trajectory hadn’t reached its goal.
In ROS 2, however, while the position states show good results, the velocity states exhibit noticeable discontinuities. This kind of behavior was not present in ROS 1, where transitions between trajectory commands were much smoother. The following figure illustrates the discontinuity issue I’m facing.

The code that i have used is also provided.
    import numpy as np
    from control_msgs.action import FollowJointTrajectory
    from trajectory_msgs.msg import JointTrajectoryPoint
    import time
    import rclpy
    from rclpy.node import Node
    from rclpy.duration import Duration
    from rclpy.action import ActionClient

  class robot_action(Node):
      def __init__(self):
          super().__init__('ur5e_robotiq_controller')
          self.intialization_robot_control()

      def intialization_robot_control(self):
          # Create action client
          self.ur5e_action_client=ActionClient(self,action_type=FollowJointTrajectory,action_name='/joint_trajectory_controller/follow_joint_trajectory')

          self.create_timer(0.3, self.control_loop_callback)  # Update every 0.1 seconds

      def transitionRobot(self,duration,trajectory):
          # Create points for the trajectory
          self.point = JointTrajectoryPoint()
          self.point.time_from_start = Duration(seconds = (duration[1]-duration[0])).to_msg()
          self.point.positions = trajectory[0:6].tolist()#[0.0, -1.57, 1.57, 0.0, 1.57, 0.0]  # Example joint positions (radians)
          self.point.velocities = trajectory[6:12].tolist()#[0.0, 0, 0, 0.0, 0, 0.0]  # Example joint positions (radians)
          self.point.accelerations =  [0.01, 0.01, 0.01, 0.01, 0.01, 0.01]  # Example accelerations
          # Create ur5e message for transition Robot:
          self.msg_ur5e = FollowJointTrajectory.Goal()
          self.msg_ur5e.trajectory.joint_names = ['shoulder_pan_joint', 'shoulder_lift_joint', 'elbow_joint', 'wrist_1_joint', 'wrist_2_joint', 'wrist_3_joint']
          # self.msg_ur5e.trajectory.header.stamp = Time(sec=0, nanosec=0) #self.get_clock().now().to_msg()

          self.msg_ur5e.trajectory.points=[self.point]
          # Action client

          self.get_logger().info(f"Trajectory joint names: {self.msg_ur5e.trajectory.joint_names}")
          for i, point in enumerate(self.msg_ur5e.trajectory.points):
              self.get_logger().info(
                  f"Point {i}: positions={point.positions}, "
                  f"velocities={point.velocities if point.velocities else 'None'}, "
                  f"accelerations={point.accelerations if point.accelerations else 'None'}, "
                  f"time_from_start={point.time_from_start.sec}.{point.time_from_start.nanosec}"
              )
          self.ur5e_action_client.wait_for_server()
          # self.msg_ur5e.trajectory.header.stamp = self.get_clock().now().to_msg()
          goal_future =self.ur5e_action_client.send_goal_async(self.msg_ur5e)
          goal_future.add_done_callback(self.goal_response_callback)

      def goal_response_callback(self, future):
          goal_handle = future.result()
          if not goal_handle.accepted:
              self.get_logger().info('Goal rejected :(')
              return

          self.get_logger().info('Goal accepted :)')
          self._get_result_future = goal_handle.get_result_async()
          self._get_result_future.add_done_callback(self.get_result_callback)

      def get_result_callback(self, future):
          result = future.result().result
          self.get_logger().info('Result: {0}'.format(result))
          # rclpy.shutdown()

      def feedback_callback(self, feedback_msg):
          self.get_logger().info('Received feedback: {0}'.format(feedback_msg.feedback))
          return

      def control_loop_callback(self) -> None:
              q1 = [-3,-1,1,3,1,-1,-3,-1,1,3,1,-1]
              position = np.zeros(6)
              position[0] = q1[0]
              velocity = np.ones(6)*0.01
              self.transitionRobot([0,6],np.concatenate([position,velocity],axis=0))
              time.sleep(1.5)  # Wait for arm to reach target (2.5s)

              q1 = [-3,-1,1,3,1,-1,-3,-1,1,3,1,-1]
              position[0] = q1[1]
              self.transitionRobot([0,6],np.concatenate([position,velocity],axis=0))
              time.sleep(1.5)  # Pause for 1 second at target

              q1 = [-3,-1,1,3,1,-1,-3,-1,1,3,1,-1]
              position[0] = q1[2]
              self.transitionRobot([0,6],np.concatenate([position,velocity],axis=0))
              time.sleep(1.5)  # Pause for 1 second at target

              q1 = [-3,-1,1,3,1,-1,-3,-1,1,3,1,-1]
              position[0] = q1[3]
              self.transitionRobot([0,6],np.concatenate([position,velocity],axis=0))
              time.sleep(1.5)  # Pause for 1 second at target

              q1 = [-3,-1,1,3,1,-1,-3,-1,1,3,1,-1]
              position[0] = q1[4]
              self.transitionRobot([0,6],np.concatenate([position,velocity],axis=0))
              time.sleep(1.5)  # Pause for 1 second at target

              q1 = [-3,-1,1,3,1,-1,-3,-1,1,3,1,-1]
              position[0] = q1[5]
              self.transitionRobot([0,6],np.concatenate([position,velocity],axis=0))
              time.sleep(1.5)  # Pause for 1 second at target

              # Final pause before next cycle
              time.sleep(0.3)
              self.get_logger().info("Control loop callback executed.")

  def main(args=None):
      rclpy.init(args=args)
      robot = robot_action()

      try:
          rclpy.spin(robot)
      except KeyboardInterrupt:
          pass
      finally:
          robot.destroy_node()
          rclpy.shutdown()

      # Shutdown
      robot.destroy_node()
      rclpy.shutdown()

  if __name__ == '__main__':
      main()

have any of you witness such a behaviour? how to solve this issue?
thanks for the help in advance.
Regards,

I think what you are asking for is a proper replacement of old trajectories? this hasn't been ported to ROS 2 yet https://github.com/ros-controls/ros2_controllers/issues/84

Hi @christophfroehlich, yes are right :(. Anyway thank you for replying me and looking forward to see this working

Hello @abuibaid,
We currently don't have a timeline for this. If you are interested in taking over and please open a pull request. We can get it reviewed and merged.
Thank you

We should put this on the roadmap for next year
On Mon, 30 Dec 2024, 10:53 Christoph Fröhlich, @.***>
wrote:

Closed #1455
https://github.com/ros-controls/ros2_controllers/issues/1455 as
completed.
—
Reply to this email directly, view it on GitHub
https://github.com/ros-controls/ros2_controllers/issues/1455#event-15783572354,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA24PYMH374UGTMUBJZ7KKL2IEQ2NAVCNFSM6AAAAABULDKD76VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVG44DGNJXGIZTKNA
.
You are receiving this because you are subscribed to this thread.Message
ID: <ros-controls/ros2_controllers/issue/1455/issue_event/15783572354@
github.com>


get nodes by type

A small pr to expand getNode capabilities. This was a necessity for me when using sanity singletons, because there is no way to get the gatsby node ID, by getting a singleton by type is trivial.
This should be fully backwards compatible, so only bumping minor.
Gatsby source line reference I used to check if there was more APIs available(absolutely it is):
https://github.com/gatsbyjs/gatsby/blob/150da457b78c7682ff6c8c7e005c412f759705fa/packages/gatsby/src/utils/api-runner-node.js#L188

Thanks for this @roffelsaurus.

@benabel  mate, it seems like you've forgotten "npm run publish" this PR


VOID EVOLUTION SYSTEM

The chapter in about 1370+ is all blank when in the WebView there is already chapters in there please fix this

Duplicate of #785


Transform namespace extended with new functions

New Features

transform

toMap()
toSet()

Stream

toMap()
toSet()

types

RecordKey

Improvements

transform.toIterable() now can also accept records as input.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

19 of 19 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
535

Relevant Lines:
535

💛  - Coveralls


Adding GWAS summary statistics QC as flag to study level QC

I suggest to add the QC flag(s) to study index after GWAS QC.
A bit unclear how it interferes with other steps in GWAS catalog processing tho.

After discussions:

[ ] Add QC flags to study validation
[ ] Add the filtering to fine_mapper based on QC log file


Create caret_xgboost.R

Demo about using caret to tune xgboost for multi-class classfication

There's already a demo similar to this in R/demo. Consider combining both.

Closing this due to inactive status. Feel free to re-open.


Use SourceLinkMap from Microsoft.SourceLink.Tools to implement SourceLink JSON parsing.

Creating and using a source package that includes the implementation is tracked by https://github.com/dotnet/sourcelink/issues/443.
Fixes https://github.com/ctaggart/SourceLink/issues/386.

@ctaggart Please take a look.

/cc  @dougbu

The azure-pipelines failure looks like a build environment issue:
D:\a\1\s\dotnet-sourcelink-shared\SourceLinkMap.cs(117,20): error CS8107: Feature 'default literal' is not available in C# 7.0. Please use language version 7.1 or greater. [D:\a\1\s\dotnet-sourcelink\sourcelink.csproj]

Looks good. I'll probably just stick to AppVeyor to get this out.

I can push a 3.2.0 here next week when you are ready.
https://www.nuget.org/packages/sourcelink/
It would be great if you were to replace this global test tool with one from dotnet/sourcelink in the future.


⚠ SceneTime has degraded performance

In b211cd3, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 1148 ms

Resolved: SceneTime performance has improved in 610410a after 8 minutes.


Dev

Description:

buyables: add Ball of wool
mining: add Gem rocks
mining: set iron and gold to correct xp/ore
craft: crush semiprecious gems when cutting
item: use var for parsed parameter - refactor to save 2 parseInt executions
getOSItem: fix parsing non numbers as numbers - fix that prevents item names that start with numbers from being treated as numbers
cleanString: default to empty str to avoid problems with undefined
alch throw useful error messages - show when an item is untradeable or not found correctly
alch: allow runes to be alched
alchingActivity: allow bryophytas staff in any gear set
calculateMonsterFood: create specialReducers for food reduction - adds a 17.5% reduction when wearing an ely and creates a framework to add other reductions like this to
gearstats: magic -> mage

fixes #458
fixes #528

as ive told you at least 3 times now its not a bug, its a feature.  If you could just tell me why its wrong i would consider changing it

The dev branch became depricated a while ago, i have split all of the PRs left in it back out individually and they now point at master


The URL in the Create a knowledge base step is inappropriate

[Enter feedback here]
Importing the URL "https://docs.microsoft.com/azure/cognitive-services/qnamaker/troubleshooting" listed in the section below into KB creates only one QNA pair. This is an inappropriate URL as an example.

Create a knowledge base

+ Add URL       https://docs.microsoft.com/azure/cognitive-services/qnamaker/troubleshooting|

I suggest changing to a URL like the below.

+ Add URL       https://azure.microsoft.com/en-us/support/faq/

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

ID: dce931c1-ae7e-14a4-707c-dd4b0daeaeaa
Version Independent ID: 451c94ba-5a34-23fa-5f12-ffea66944f70
Content: Manage knowledge bases - QnA Maker - Azure Cognitive Services
Content Source: articles/cognitive-services/QnAMaker/How-To/manage-knowledge-bases.md
Service: cognitive-services
Sub-service: qna-maker
GitHub Login: @nerajput1607
Microsoft Alias: nerajput

@jpwdkblog Thanks for the suggestion. This issue is similar to 66407 I am referencing the issue here so our content team can make this update on all documentation referring to this URL. @nerajput1607 FYI.

Thanks for reporting this. We are doing a fix for this.

duplicate of : https://github.com/MicrosoftDocs/azure-docs/issues/66407

Submitted a fix. Changes should go live in a day.
#please-close


fixed faulty regex on analyze-mediapackage

Closes #4790
fixed faulty regex on analyze-mediapackage
analyze-mediapackage will REPLACE every symbol that doesn't match [^a-z0-9] regex to underscore ("_"): capital letters, plus sign ("+"), etc.
example: analyze-mediapackage on captions/*: captions/vtt+auto -> captions_vtt_auto_exists

Hi @aliyevTU Thank you for contributing to Opencast. We noticed that you have not yet filed an Individual Contributor License Agreement. Doing that (once) helps us to ensure that Opencast stays free for all. If you make your contribution on behalf of an institution, you might also want to file a Corporate Contributor License Agreement (giving you as individual contributor a bit more security as well). It can take a while for this bot to find out about new filings, so if you just filed one or both of the above do not worry about this message! Please let us know if you have any questions regarding the CLA.

I have filled and agreed to CLA. Is it an issue with CLA checking script or do I have to refill CLA?

I have filled and agreed to CLA. Is it an issue with CLA checking script or do I have to refill CLA?

It's neither.  But Apereo has not processed it yet. That can be a bit slow at times. Just ignore the test for now and point people to this comment if someone asks about it.

You also don't need to file an issue if you immediately file a pull request for that. Spare yourself the work an just file a pull request.

Looking at the failing test, the behavior seems to be by design. Your patch causes the tests to fail since they expect an underscore instead of a plus sign. I'm also not sure how the workflow conditions handle something like a + in variable names. Does that work?

Looking at the failing test, the behavior seems to be by design. Your patch causes the tests to fail since they expect an underscore instead of a plus sign. I'm also not sure how the workflow conditions handle something like a + in variable names. Does that work?

Of course, every single WOH works with + sign. The thing is that this implementation that I am trying to fix is not only replacing +, but also capital letters. We use + sign on many parts of our different workflows.
For example "analzye-tracks" will leave '+' (and probably other symbols) untouched when creating new workflow variables. Example: track with audio and flavor presenter/trimmed+audio+auph -> presenter_trimmed+audio+auph_audio

Should I also change the tests?

If you think the behavior is a bug, then the test is also buggy and needs fixing. Your current patch cannot be merged like this. It would break Opencast builds like this due to the failing test. Additionally, you need to adopt the workflow operation's documentation, which also states the current behavior. Finally, it would be great if you could put a note in the releasenotes folder. A change like this should be pointed out since many users will need to adapt their workflows due to the change in behavior.

Of course, every single WOH works with + sign.

The question was about workflow conditions specifically. For example, ingesting something like presenter/source+a+b will result in a variable presenter_source_a_b_type right now. That is safe to use in a workflow condition:
- id: inspect
  if: "${presenter_source_a_b_type} == 'Track'"

My question was if this is still true if you allow special characters in variables? Your code would require writing something like:
- id: inspect
  if: "${presenter_source+a+b_type} == 'Track'"

Worse, what if the flavor contains something like }? This would probably fail:
- id: inspect
  if: "${presenter_source}a}b_type} == 'Track'"

That's why I'm wondering if this should really be changed like this. That said, I didn't take a close look at the code or actually tested it.
If you start allowing special characters, I'm also wondering why you are still replacing the / character? If they are not a problem, why not keep all of them?
If, on the other hand, this is really only about the uppercase letters being replaced, I would suggest a change like this instead:
String flavorPrefix = mpe.getFlavor().toString().toLowerCase().replaceAll("[^a-z0-9]", "_");

As we discussed it with @gregorydlogan  at Opencast technical meeting on 28.03.2023:
The main issue is that analyze-track WOH behaves differently to analyze-mediapackage. This discrepancy can create problems for adopters with custom workflows. We as adopter are using + in our flavors without any issue for many years now. I will update the tests and update the PR.

We as adopter are using + in our flavors without any issue for many years now.

This doesn't really answer any of the question from me, does it? The + sign is used in flavors by default. No doubt about that. But you are trying to create variables with arbitrary characters in them. That hasn't anything to do with flavors any longer. Or at least only indirectly. I also don't really understand why this would lead to any error for adopters since the behavior is well-defined.
Is your argument is usability in the sense, that it would be easier or less confusing for users if both workflow operation handler would use the same variable names? If so, I'm fine with adjusting that. But only if you then actually use the same algorithm for generating variable names. Right now, your replacement is generating slightly different variable names.
This is the algorithm used by analyze-tracks:
https://github.com/opencast/opencast/blob/0f6b717aa99866f41c360622361ce5e17f84a64e/modules/workflow-workflowoperation/src/main/java/org/opencastproject/workflow/handler/workflow/AnalyzeTracksWorkflowOperationHandler.java#L160-L163
You also need to update this operation's documentation to reflect the different behavior and should add a note to go into the release notes.

But you are trying to create variables with arbitrary characters in them.
How you came to this conclusion?

I also don't really understand why this would lead to any error for adopters since the behavior is well-defined.
It is clear that you have not understood what the bug is or what the changes I introduced are meant to do. Please attend the technical meeting this week, and I will go over it once again just for you. I already explained everything in detail to @gregorydlogan .

I should likely be at the meeting tomorrow. If I cannot make that, we can hop into a video call anytime, if you think that will help to explain.

Can we get it merged so that I can close this issue also from my internal issue list? @lkiesow will send an email for a video call appointment.

Listing the points from the meeting earlier again.
I'm definitely not opposed to making analyze-mediapackage generate the same variables analyze-trakcs generates.
We just should make sure that people are aware of the change since they may need to adapt their workflows.
Based on this goal and the current state of this pull request, here is a todo list:

[ ] Make sure  analyze-mediapackage actually generate the same variables analyze-trakcs does. For example, given a flavor a/B your code would right now generate variables like a_b_… while analyze-tracks would generate a_B_…. If you want them to work the same, I suggest simply using the same algorithm for both. This is the algorithm used by analyze-tracks:
https://github.com/opencast/opencast/blob/0f6b717aa99866f41c360622361ce5e17f84a64e/modules/workflow-workflowoperation/src/main/java/org/opencastproject/workflow/handler/workflow/AnalyzeTracksWorkflowOperationHandler.java#L160-L163
[ ] You need to update this operation's documentation to reflect the different behavior. Right now, it states e.g. that it would generate a variable like security_xacml_episode_exists=true which (assuming the default flavors) would be security_xacml+episode_exists=true after your patch is applied.
[ ]  You should add a note to go into the release notes. Adopters are using this in its current form at the moment. We should point out that something has changes. See the readme in that folder for details, but essentially, just place a text file with a few lines of explanation in that directory. This should not be long.
[ ] (optional, but would be great) Update this pull request's title and description to reflect your intent (make both operations work alike). That's less important, but would still be great as it can be really useful if you try to find patches in the future and you don't have to dig through a lengthy discussion down here ;-) Also, the Title will be what is shown in the changelogs.

I hope this makes things clearer.

@lkiesow after changing docs, mkdown style makes codeblock properties not render + correctly as in:

How can I fix this?

Updated algo, and docs, added release note. Thanks for tips @lkiesow Happy to be finally be done with this.

@lkiesow you there?


Issue 169 Rolling Window

See issue 169 for details. Fixes bug where RollingWindow[1] gets the wrong value when the Indicator is not ready.

Closed via #171


Confusion about which telegram-mtproto version to use?

Hi there!

Quick question - I do have several problems with telegram-mtproto.
I built myself a shell client based on the blessed ui library, but for some reason I have various different results using the lib.
I started to using the mtproto-fs-storage module to keep auth requests low, everything works fine with the telegram-mtproto@alpha (i guess, version 2.2.2) on the dev mode server, but as soon as I go to the productive server I do get various problems regarding FLOOD_WAIT and being banned after a couple of minutes for 24h. I even added a couple of wait and sleep methods between each of the mtproto calls (+ I only issue one after the other to ensure that I am not flooding the server), still, getting banned regulary.
With the mtproto3 I was not able to login at all to the productive server.

Now this poses the question:
Which mtproto version should we (as developers) use and develop against for now? I know v3 is comming whenever it is stable enough to work with, but does the v2 have such grave bugs that causes me to lose connection with the productive server?

Version     Problem
1           not working
2(.2.2)     working, but getting banned after some minutes
3           cannot login

Thanks, and sorry if I may be rumbling.
- Christian

try 3.1.3

Sadly no success.
Maybe I am doing something wrong?
I added a little test.js, which basically checks if the user is still authed by either calling getWallpapers or account.authorizations.
Expected result: a error to catch
Result: nothing, totally dead after the key exchange.
Also there is no way I could wait until the key exchange finished, that's why I used a async / await sleep function.
Package.json:
  "dependencies": {
    "blessed": "^0.1.81",
    "i18n": "^0.8.3",
    "mtproto-storage-fs": "^0.3.1",
    "npm": "^5.8.0",
    "telegram-mt-node": "^0.9.7",
    "telegram-mtproto": "^3.1.3",
    "webpack": "^4.6.0"
  }

Same issue here.
In my case:
version 2.2.2     It can login with both production server and dev server.
version 3.1.3     It can only login with dev server.
version 3.2.11   It can NOT login with both servers.

In my case too. Currently use 2.x version? but have some bug:
`MT[406] NETWORK_BAD_REQUEST unhandled rejection

Hi.
Which on is the OFFICIAL Telegram MTProto version?
I see several distribiotion of MTProto on the GitHub. Please send me official link.

@venusbahar there is no official


Minimal install for RC4 without middleware fails

I am using the ZendExp rc4. Using (skeleton+installer) with options minimal option, fastroute, zendSM, NoView,Whoops. A Composer server or php dev server on it fails with 404 for the root 'http://localhost:8080/' path. Is it how it has to be - compulsory middleware need? Didnt see any docs on it. A full install option with other above configs work.

If you selected minimal (yes) at the first question, that is what it does. It doesn't add any actions, middleware, templates or routes. If you want something that works out of the box, you should install the full skeleton.

@ganeshkbhat — as @xtreamwayz notes, when you select the minimal install, it essentially only sets up the project structure, but without any middleware defined, or any default assets (CSS, JS, favicon, etc.). This is to allow experienced users to setup a project without immediately needing to remove those items and/or replace them with their own.
A default installation, without selecting "minimal", will install these things, as well as some sample middleware. That's the difference.

Sure. Just downloaded the RC yesterday for creating APIs. Good to put in docs though. I was checking what went wrong until I started digging code internally. Thank you for coming back fast on this. Still digging into the docs and code. Quite some changes to previous zf2 skeleton. One more point, I think it is a good idea to put in docs that if Windows System users are not able to install using the installer ask them to run the CLI in administrator mode. Win systems seem to be blocking the download and setup without admin mode.

Win systems seem to be blocking the download and setup without admin mode.

Strange. I have developed the installer on a windows system an I have had no issues at all. Can you  create a new issue at https://github.com/zendframework/zend-expressive-skeleton/issues. Maybe add some more details so I can have a look at it.

Yes, even I presume it could have been composer installation issue; may be rights sharing for my user. But I cannot find something like this; where composer.bat needed elevated rights. I may be wrong here. I am not able to replicate the issue as well. Lets wait on this. May be it might come up as I start working on projects and do a cache clean during that. If I am able to replicate that I will get in touch with you.


dev: replace precompiles with cairo1_helpers

Time spent on this PR: half hour
Resolves: #908
TODO
@constructor
func constructor{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    owner: felt,
    native_token_address: felt,
    account_contract_class_hash: felt,
    uninitialized_account_class_hash: felt,
    precompiles_class_hash: felt,
    block_gas_limit: felt,
) {

[ ] rename the parameter  precompiles_class_hash to cairo1_helpers_class_hash

Pull Request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[x] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Testing

What is the new behavior?

Does this introduce a breaking change?

[ ] Yes
[x] No

Hi @Eikix ,  I have added the issue link . Please review it


Failed to resolve: im.ene.toro3:toro:<IP_ADDRESS>0003

Failed to resolve: im.ene.toro3:toro:<IP_ADDRESS>0003
Failed to resolve: im.ene.toro3:toro-ext-exoplayer:<IP_ADDRESS>02
Our project not found library on repository. I think this problem occurred after jcenter shutdown.
We are using below version
implementation 'im.ene.toro3:toro:<IP_ADDRESS>0003'
implementation 'im.ene.toro3:toro-ext-exoplayer:<IP_ADDRESS>02'
In project build.gradle
repositories {
maven { url "https://oss.jfrog.org/artifactory/oss-snapshot-local" }
}
How to add these library in our project any suggestion or help.

Does anyone support this project? @eneim ?

@erenbakac @shivprakash86 Jcenter is gone, sadly. And really sorry I haven't had time to support the migration.

we kindly need your support @eneim. I cant build the app that i am working on. Please.

How about using jitpack: https://jitpack.io/#eneim/toro/<IP_ADDRESS>0003 ? And what blocks you from cloning the library locally? It will just like building the library locally.

It worked. Thank you. @eneim


ForceLogin Bugged??

I went to relaunch my chat bot, and he got this error.

I then added the force login to the settings and ran the same, and i got the same message. I logged in to facebook with that account and it was suspicious about that login for some reason. I checked all the login activity and I am unsure why it blocked it as it was always logged in from that area. Anyway i checked it to say it was me and tried again. I removed the force login tried again same message, and tried with force login same message. I am not sure what todo at the moment. Is there a cooldown period in which once you confirm that logon was you it allows logging in from that area again? Thanks

forceLogin can only do so much if the account is temporarily blocked 😛
There are a number of factors that can cause this to happen.  If you describe how you were using the api, there might be some suggestions we can give to avoid it.

I havn't changed how i have used the api. Ive been using it the same code for ages now and havnt modified it in months. I went to edit from refresh tokens for a completely different api. And i go to test it and it blocks it. I very much doubt the api refresh token change was the issue. I have changed the password and confirmed emails etc. But i still get the message. What i think im going todo is leave it 24 hours and try again as i feel maybe there is a cooldown?

On the DOCS it says the force login is meant to accept it. I am just unsure as to why i am able to log on from my local PC and phone but the api doesn't

Ur forceLogin is out of date, just checked

Quite likely.  As I said, it should probably be deprecated.
Unfortunately it is very hard to debug issues with blocking.

As i currently work through a AWS server im going to migrate over to my own physical, so ive installed a virtual desktop which should enable me to do it manually from that as i cant do it from my end as its blocking the servers access without the approval. Im going to close this but ill be sure to comment any further findings to see if the forceLogin can be updated in the foreseeable future.

Sounds good, thanks @bobland1
I've found running on some servers (that sometimes move around) tricky for this reason.

I tried running from a different server, and the error still percists, what is your work arround

We run from a machine that we own.  Seems to work alright for the most part.  Logging in using appstate can also help sometimes.

I can log onto different accounts fine, just seems to be this account when logging in with this api. Not sure what the issue is. I cant get an appstate sadly as i need to login first :D Not sure what todo, anything you would recommend?

It's possible that the account has been flagged in some way.  It's very hard for us to know what facebook is doing to detect automated use of their system (as this api is clearly going against intended use).  Not always much we can do.

Yeah hmm, well we will have to wait aha


⚠ Spryr has degraded performance

In 1434a92, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 5382 ms

Resolved: Spryr performance has improved in c9f490c after 11 minutes.


Paging through submissions list view is broken

Description
Steps to reproduce
https://images.zenhubusercontent.com/302387839/10f8e18b-f4cc-47c7-aafc-edf62e5cdf39/screen_recording_2022_06_22_at_1_40_39_pm.mov

Go to "Results"
Go to "CSV upload history"
Click "Next page" icon
See error

Expected behavior
We expect to be able to see all submissions across all pages of the view
Additional context
This results from a routing conflict between the "submissions list" and "submission detail" views.
The paginated URLs are structured as /results/upload/submissions/:page_num. Subsequently, the “submission detail” endpoint was added at results/upload/submissions/:submission_id. Therefore, the application is trying to parse the page number as a UUID, resulting in a failure.

Looks to me the Submission detail routing is whats broken, I would suggest dropping the 's' from submission route
change results/upload/submissions/:submission_id
to
results/upload/submission/:submission_id


[BottomNavigation] How can I use with Svelte?

I am very new and I am interested to create a mobile application by Svelte NativeScript.
But I don't know how can I use the BottomNavigation.
Is this library support Svelte?

Unfortunately, I would like to have a solution for Svelte as well. As far as I know, since Nativescript 8.0 was released, components BottomNavigation and Tabs are not supported by officials anymore, only by the community. I have already tried to bypass this by using a regular Nativescript and registerNativeViewElement function, however unsuccessfully.

@ohmaha @dnicer3 yes svelte needs a special component for this.
@halfnelson started working on this https://github.com/halfnelson/ui-material-components/commit/904c71ec5cc43f74dd77df99e7ec6f09357c4fdf
@halfnelson what s the status on this?

I got this working on Stackblitz Preview today with help on the NS Discord.
Here's how I set it up.
Install the plugin in package.json
"@nativescript-community/ui-material-bottom-navigation": "^7.0.25"
I'm using that version since a message on Discord said that was the version supported by ns preview
Register the plugin in  app.ts
app.ts
import {
  BottomNavigation,
  TabContentItem,
  TabStrip,
  TabStripItem,
} from '@nativescript-community/ui-material-bottom-navigation';

.....

registerNativeViewElement('bottomNavigation', () => BottomNavigation);
registerNativeViewElement('tabStrip', () => TabStrip);
registerNativeViewElement('tabStripItem', () => TabStripItem);
registerNativeViewElement('tabContentItem', () => TabContentItem);

svelteNativeNoFrame(App, {});

Add the component to your Page.svelte
Page.svelte
<script lang="ts">
let selectedTab = 1

$:console.log({selectedTab})
</script>

<page xmlns:mdt="@nativescript-community/ui-material-bottom-navigation">
<bottomNavigation bind:selectedIndex={selectedTab}>

	<!-- The bottom tab UI is created via TabStrip (the containier) and TabStripItem (for each tab)-->
	<tabStrip>
		<tabStripItem>
			<label text="Home" />
		</tabStripItem>
		<tabStripItem class="special">
			<label text="Account" />
		</tabStripItem>
		<tabStripItem class="special">
			<label text="Search" />
		</tabStripItem>
	</tabStrip>

	<!-- The number of TabContentItem components should corespond to the number of TabStripItem components -->
	<tabContentItem>
		<gridLayout>
			<label text="Home Page" class="h2 text-center" />
		</gridLayout>
	</tabContentItem>
	<tabContentItem>
		<gridLayout>
			<label text="Account Page" class="h2 text-center" />
		</gridLayout>
	</tabContentItem>
	<tabContentItem>
		<gridLayout>
			<label text="Search Page" class="h2 text-center" />
		</gridLayout>
	</tabContentItem>

</bottomNavigation>
</page>

@NoelOConnell, as I said, I have already tried same and anyway I can not make it working... See the code and package below.

@dnicer3 Can you try changing the order that the components are registered. I remember seeing some other issue about the order needing to be correct for tabs.
registerNativeViewElement('bottomNavigation', () => BottomNavigation);
registerNativeViewElement('tabStrip', () => TabStrip);
registerNativeViewElement('tabStripItem', () => TabStripItem);
registerNativeViewElement('tabContentItem', () => TabContentItem);

@NoelOConnell Unfortunately, nothing is changing. (

@dnicer3 I have the plugin installed as a dev dependency. Not sure if that makes a difference.

@NoelOConnell  can you send your link of Stackblitz?

@vallemar here's the playground I'm experimenting with.
https://stackblitz.com/edit/nativescript-stackblitz-templates-gvy41h

@NoelOConnell I have even changed it to devDependencies, but still nothing...

@dnicer3 I've created a bare example that you can use to compare to your own and see if there's any differences.
https://stackblitz.com/edit/nativescript-stackblitz-templates-t1fr9o

@NoelOConnell thank you for assistance, however, mine code is 100% same but not working ))

@dnicer3 Yeah, I tried to run it locally with the emulator and got the same error as you. It works fine in Stackblitz so it's something to do with how the Nativescript Stackblitz has additional dependencies installed.
I looked at the package.json for ui-material-bottom-navigation and saw it has dependencies list.
I updated the package.json to include them and it worked in the emulator locally.
Can you try adding these dependencies.
"@nativescript-community/ui-material-bottom-navigation": "^7.0.34",
"@nativescript-community/ui-material-core-tabs": "^7.0.34",
"@nativescript/core": "~8.4.0",

@NoelOConnell you are the God, thanks. Finally, it's working!


767 preview txt

txt: add previewing capabilities
ipynb: fix to allow preview
release: v1.3.4
closes https://github.com/inveniosoftware/invenio-app-rdm/issues/767

Locally the test suite is failing: some upstream dependency must have changed because even master is failing locally for me. I haven't been able to figure out what caused it.
stacktrace
Built at: 2021-07-27 2:46:10 p.m.
 59 assets
Entrypoint adminlte = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/1.53a3318363302ba9b099.js js/1.53a3318363302ba9b099.js.map js/18.55a34ff4a9d0fe9af446.js js/18.55a34ff4a9d0fe9af446.js.map js/3.0bb500a49bb493ef7b45.js js/3.0bb500a49bb493ef7b45.js.map
Entrypoint base = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/1.53a3318363302ba9b099.js js/1.53a3318363302ba9b099.js.map js/4.841a29ba49e64e3aeb5a.js js/4.841a29ba49e64e3aeb5a.js.map
Entrypoint bottom_css = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map css/bottom_css.492e2c68f4a612c7d4ab.css js/5.4dfb25f6ad1e9dcf2e97.js js/5.4dfb25f6ad1e9dcf2e97.js.map
Entrypoint bottom_js = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/1.53a3318363302ba9b099.js js/1.53a3318363302ba9b099.js.map js/6.4ce5709c37b5583c11a4.js js/6.4ce5709c37b5583c11a4.js.map
Entrypoint d3_csv = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/1.53a3318363302ba9b099.js js/1.53a3318363302ba9b099.js.map js/19.199a9b9d598ec4d635ce.js js/19.199a9b9d598ec4d635ce.js.map js/7.920f6233261fd7527e69.js js/7.920f6233261fd7527e69.js.map
Entrypoint fullscreen_js = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/8.6f8fa405c9b92dec18f5.js js/8.6f8fa405c9b92dec18f5.js.map
Entrypoint i18n_app = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/1.53a3318363302ba9b099.js js/1.53a3318363302ba9b099.js.map js/9.055d8972b3e0f99215e9.js js/9.055d8972b3e0f99215e9.js.map
Entrypoint pdfjs_css = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map css/pdfjs_css.b60fc788589fd4066637.css js/10.b5d17fcb90b3457fe0e9.js js/10.b5d17fcb90b3457fe0e9.js.map
Entrypoint pdfjs_js = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/20.b915cfa9aaa153956f7d.js js/20.b915cfa9aaa153956f7d.js.map js/11.7b3002d856712a9f9153.js js/11.7b3002d856712a9f9153.js.map
Entrypoint previewer_theme = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/1.53a3318363302ba9b099.js js/1.53a3318363302ba9b099.js.map js/2.3d24d88f2936ad04fe7c.js js/2.3d24d88f2936ad04fe7c.js.map js/12.e3a91ff33b6b9109d9f0.js js/12.e3a91ff33b6b9109d9f0.js.map
Entrypoint prism_css = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map css/prism_css.eb55a72049e863c203e9.css js/13.10c46f33162910d7989c.js js/13.10c46f33162910d7989c.js.map
Entrypoint prism_js = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/21.96c4ac61f05ecba4ea47.js js/21.96c4ac61f05ecba4ea47.js.map js/14.9253ad338e0ba7bf67af.js js/14.9253ad338e0ba7bf67af.js.map
Entrypoint simple_image_css = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map css/simple_image_css.8020d52b9ac1ee4abed3.css js/15.666954d18e30ded2b527.js js/15.666954d18e30ded2b527.js.map
Entrypoint theme = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map js/1.53a3318363302ba9b099.js js/1.53a3318363302ba9b099.js.map js/2.3d24d88f2936ad04fe7c.js js/2.3d24d88f2936ad04fe7c.js.map js/16.faf970aec070cd78fdfa.js js/16.faf970aec070cd78fdfa.js.map
Entrypoint theme-admin = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map css/theme-admin.a636f581018272aa9732.css js/17.d9577635f8aa824ef821.js js/17.d9577635f8aa824ef821.js.map
Entrypoint zip_css = js/manifest.9d9943e1341b902db8a3.js js/manifest.9d9943e1341b902db8a3.js.map css/zip_css.ff1aa19166cb32167ba6.css js/22.30e1a6d0ea0519d54d33.js js/22.30e1a6d0ea0519d54d33.js.map
[168] ./js/invenio_theme/admin.js 623 bytes {3} [built]
[173] ./js/invenio_theme/base.js 432 bytes {4} [built]
[174] ./scss/invenio_previewer/bottom.scss 39 bytes {5} [built]
[175] ./js/invenio_previewer/bottom.js 401 bytes {6} [built]
[176] ./js/invenio_previewer/fullscreen.js 1.81 KiB {8} [built]
[177] ./js/invenio_i18n/app.js 414 bytes {9} [built]
[178] ./scss/invenio_previewer/pdfjs.scss 39 bytes {10} [built]
[217] ./js/invenio_previewer/previewer_theme.js 508 bytes {12} [built]
[218] ./scss/invenio_previewer/prismjs.scss 39 bytes {13} [built]
[219] ./js/invenio_previewer/prismjs.js 270 bytes {14} [built]
[220] ./scss/invenio_previewer/simple_image.scss 39 bytes {15} [built]
[221] ./js/invenio_theme/theme.js 1.01 KiB {16} [built]
[222] ./scss/invenio_theme/admin.scss 39 bytes {17} [built]
[223] ./scss/invenio_previewer/zip.scss 39 bytes {22} [built]
[224] ./js/invenio_previewer/csv_previewer/init.js + 2 modules 3.89 KiB {7} [built]
      | ./js/invenio_previewer/csv_previewer/init.js 494 bytes [built]
      | ./js/invenio_previewer/csv_previewer/csv_d3js.js 2.43 KiB [built]
      | ./js/invenio_previewer/csv_previewer/loader.js 985 bytes [built]
    + 218 hidden modules

ERROR in ./node_modules/semantic-ui-less/semantic.less
Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/less-loader/dist/cjs.js):

@import (multiple) '../../theme.config';
^
Less resolver error:
'../../theme.config' wasn't found. Tried - /tmp/tmp1obodous/assets/node_modules/semantic-ui-less/theme.config,../../theme.config

Webpack resolver error details:
resolve '../../theme.config' in '/tmp/tmp1obodous/assets/node_modules/semantic-ui-less/definitions/modules'
  using description file: /tmp/tmp1obodous/assets/node_modules/semantic-ui-less/package.json (relative path: ./definitions/modules)
    aliased with mapping '../../theme.config': '/tmp/tmp1obodous/assets/less/invenio_theme/theme.config' to '/tmp/tmp1obodous/assets/less/invenio_theme/theme.config'
      using description file: /tmp/tmp1obodous/assets/node_modules/semantic-ui-less/package.json (relative path: ./definitions/modules)
        Field 'browser' doesn't contain a valid alias configuration
        using description file: /tmp/tmp1obodous/assets/package.json (relative path: ./less/invenio_theme/theme.config)
          no extension
            Field 'browser' doesn't contain a valid alias configuration
            /tmp/tmp1obodous/assets/less/invenio_theme/theme.config doesn't exist
          .less
            Field 'browser' doesn't contain a valid alias configuration
            /tmp/tmp1obodous/assets/less/invenio_theme/theme.config.less doesn't exist
          .css
            Field 'browser' doesn't contain a valid alias configuration
            /tmp/tmp1obodous/assets/less/invenio_theme/theme.config.css doesn't exist
          as directory
            /tmp/tmp1obodous/assets/less/invenio_theme/theme.config doesn't exist
        root path /tmp/tmp1obodous/assets
          using description file: /tmp/tmp1obodous/assets/package.json (relative path: ./tmp/tmp1obodous/assets/less/invenio_theme/theme.config)
            no extension
              Field 'browser' doesn't contain a valid alias configuration
              /tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config doesn't exist
            .less
              Field 'browser' doesn't contain a valid alias configuration
              /tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.less doesn't exist
            .css
              Field 'browser' doesn't contain a valid alias configuration
              /tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.css doesn't exist
            as directory
              /tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config doesn't exist

Webpack resolver error missing:
/tmp/tmp1obodous/assets/less/invenio_theme/theme.config,/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.less,/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.css,/tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config,/tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.less,/tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.css

      Error in /tmp/tmp1obodous/assets/node_modules/semantic-ui-less/definitions/modules/transition.less (line 19, column 0)
    at /tmp/tmp1obodous/assets/node_modules/webpack/lib/NormalModule.js:316:20
    at /tmp/tmp1obodous/assets/node_modules/loader-runner/lib/LoaderRunner.js:367:11
    at /tmp/tmp1obodous/assets/node_modules/loader-runner/lib/LoaderRunner.js:233:18
    at context.callback (/tmp/tmp1obodous/assets/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
    at /tmp/tmp1obodous/assets/node_modules/less-loader/dist/index.js:62:5
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
 @ ./js/invenio_theme/theme.js 11:0-40
Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/less-loader/dist/cjs.js!node_modules/semantic-ui-less/semantic.less:
    Entrypoint mini-css-extract-plugin = *
       1 module

    ERROR in ./node_modules/semantic-ui-less/semantic.less (./node_modules/css-loader/dist/cjs.js!./node_modules/less-loader/dist/cjs.js!./node_modules/semantic-ui-less/semantic.less)
    Module build failed (from ./node_modules/less-loader/dist/cjs.js):

    @import (multiple) '../../theme.config';
    ^
    Less resolver error:
    '../../theme.config' wasn't found. Tried - /tmp/tmp1obodous/assets/node_modules/semantic-ui-less/theme.config,../../theme.config

    Webpack resolver error details:
    resolve '../../theme.config' in '/tmp/tmp1obodous/assets/node_modules/semantic-ui-less/definitions/modules'
      using description file: /tmp/tmp1obodous/assets/node_modules/semantic-ui-less/package.json (relative path: ./definitions/modules)
        aliased with mapping '../../theme.config': '/tmp/tmp1obodous/assets/less/invenio_theme/theme.config' to '/tmp/tmp1obodous/assets/less/invenio_theme/theme.config'
          using description file: /tmp/tmp1obodous/assets/node_modules/semantic-ui-less/package.json (relative path: ./definitions/modules)
            Field 'browser' doesn't contain a valid alias configuration
            using description file: /tmp/tmp1obodous/assets/package.json (relative path: ./less/invenio_theme/theme.config)
              no extension
                Field 'browser' doesn't contain a valid alias configuration
                /tmp/tmp1obodous/assets/less/invenio_theme/theme.config doesn't exist
              .less
                Field 'browser' doesn't contain a valid alias configuration
                /tmp/tmp1obodous/assets/less/invenio_theme/theme.config.less doesn't exist
              .css
                Field 'browser' doesn't contain a valid alias configuration
                /tmp/tmp1obodous/assets/less/invenio_theme/theme.config.css doesn't exist
              as directory
                /tmp/tmp1obodous/assets/less/invenio_theme/theme.config doesn't exist
            root path /tmp/tmp1obodous/assets
              using description file: /tmp/tmp1obodous/assets/package.json (relative path: ./tmp/tmp1obodous/assets/less/invenio_theme/theme.config)
                no extension
                  Field 'browser' doesn't contain a valid alias configuration
                  /tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config doesn't exist
                .less
                  Field 'browser' doesn't contain a valid alias configuration
                  /tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.less doesn't exist
                .css
                  Field 'browser' doesn't contain a valid alias configuration
                  /tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.css doesn't exist
                as directory
                  /tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config doesn't exist

    Webpack resolver error missing:
    /tmp/tmp1obodous/assets/less/invenio_theme/theme.config,/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.less,/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.css,/tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config,/tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.less,/tmp/tmp1obodous/assets/tmp/tmp1obodous/assets/less/invenio_theme/theme.config.css

          Error in /tmp/tmp1obodous/assets/node_modules/semantic-ui-less/definitions/modules/transition.less (line 19, column 0)
Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/sass-loader/dist/cjs.js!scss/invenio_previewer/bottom.scss:
    Entrypoint mini-css-extract-plugin = *
    [1] ./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./scss/invenio_previewer/bottom.scss 1.12 KiB {0} [built]
        + 1 hidden module
Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/sass-loader/dist/cjs.js!scss/invenio_previewer/pdfjs.scss:
    Entrypoint mini-css-extract-plugin = *
     [2] ./js/invenio_previewer/pdfjs/web/images/texture.png 3.19 KiB {0} [built]
     [3] ./js/invenio_previewer/pdfjs/web/images/loading-small.png 9.68 KiB {0} [built]
     [4] ./js/invenio_previewer/pdfjs/web/images/toolbarButton-menuArrows.png 183 bytes {0} [built]
     [5] ./js/invenio_previewer/pdfjs/web/images/toolbarButton-sidebarToggle.png 339 bytes {0} [built]
     [6] ./js/invenio_previewer/pdfjs/web/images/toolbarButton-sidebarToggle-rtl.png 339 bytes {0} [built]
     [7] ./js/invenio_previewer/pdfjs/web/images/toolbarButton-secondaryToolbarToggle.png 363 bytes {0} [built]
     [8] ./js/invenio_previewer/pdfjs/web/images/toolbarButton-secondaryToolbarToggle-rtl.png 367 bytes {0} [built]
     [9] ./js/invenio_previewer/pdfjs/web/images/findbarButton-previous.png 307 bytes {0} [built]
    [10] ./js/invenio_previewer/pdfjs/web/images/findbarButton-previous-rtl.png 299 bytes {0} [built]
    [11] ./js/invenio_previewer/pdfjs/web/images/findbarButton-next.png 299 bytes {0} [built]
    [12] ./js/invenio_previewer/pdfjs/web/images/findbarButton-next-rtl.png 307 bytes {0} [built]
    [13] ./js/invenio_previewer/pdfjs/web/images/toolbarButton-pageUp.png 367 bytes {0} [built]
    [14] ./js/invenio_previewer/pdfjs/web/images/toolbarButton-pageUp-rtl.png 367 bytes {0} [built]
    [15] ./js/invenio_previewer/pdfjs/web/images/toolbarButton-pageDown.png 359 bytes {0} [built]
    [38] ./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./scss/invenio_previewer/pdfjs.scss 92.3 KiB {0} [built]
        + 24 hidden modules
Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/sass-loader/dist/cjs.js!scss/invenio_previewer/prismjs.scss:
    Entrypoint mini-css-extract-plugin = *
    [1] ./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./scss/invenio_previewer/prismjs.scss 6 KiB {0} [built]
        + 1 hidden module
Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/sass-loader/dist/cjs.js!scss/invenio_previewer/simple_image.scss:
    Entrypoint mini-css-extract-plugin = *
    [1] ./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./scss/invenio_previewer/simple_image.scss 865 bytes {0} [built]
        + 1 hidden module
Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/sass-loader/dist/cjs.js!scss/invenio_previewer/zip.scss:
    Entrypoint mini-css-extract-plugin = *
    [1] ./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./scss/invenio_previewer/zip.scss 1.39 KiB {0} [built]
        + 1 hidden module
Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/sass-loader/dist/cjs.js!scss/invenio_theme/admin.scss:
    Entrypoint mini-css-extract-plugin = *
    [1] ./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./scss/invenio_theme/admin.scss 315 KiB {0} [built]
        + 1 hidden module


Feature/progress bar

Changes: 🌟
This feature (unfortunately) does a couple of things 😅:

Refactor how days are being built and executed
Add progress bar

Refactor build and execution steps
The reason I removed futures in favour of threads is that running and executing each day is CPU bound.
I also slowed down on the parallelism. Now at most 25 threads will be opening files.
Doing some quick and dirty benchmarks I found that the old implementation took 10 seconds for --num-runs 500 while the improved takes 4 seconds.
Progress bar
The progress bar looks cool 😎

Im sure a lot of things are unclear (bad names, unclear functions, etc.) so give me your worst
fixes #44
fixes #43
^ doesn't exactly do what the issue asks, but I think it solves the main problem: the computer being a hostage to tally

:shipit:


Set up Kirat Rai script

"The Kirat Rai script is used to write the Bantawa language in the Sikkim state of India."
The tag seems to be: krai
We need it for that font: https://github.com/google/fonts/pull/8431

[ ] sample text
[x] subset
[x] primary script

cc @simoncozens

Subset was added in: https://github.com/googlefonts/nam-files/pull/21 @garretrieger please confirm the new U16 subsets are wired up with the server and ready to be used.
We actually have Bantawa sample text in bap_Deva. Presumably this can be transliterated.
I'll add script entries for all the U16 scripts.

Confirmed the Kirat Rai subset definitions have been onboarded and are present in all of our services.

Thank you! So all that's left is for me to transliterate the sample text and do another lang release.


Investigate always taking self by value

I don't know whether this will work, but consider:
impl<T> Trait for Impl<T> {
    fn foo(&self) {}
}

vs.
impl<T> Trait for &Impl<T> {
    fn foo(self) {}
}

If the traits always take self by value, it might not be necessary to duplicate the traits when doing dependency inversion, because then we can make a newtype without reborrowing:
struct NewType<'a, T>(&'a Impl<T>);

impl<'a, T> Trait for NewType<'a, T> {
    fn foo(self) { self.0.foo() }
}

The main reason it was necessary to duplicate the trait with the current design, was that it was impossible to make futures implement Send when "reborrowing" for a struct like NewType. NewType had to be passed as a reference into the delegation-target, referencing the value just created on the stack, and things referencing a value owned by the stack (vs. the heap) can't be sent to another thread. If NewType is passed by-value, this restriction is likely lifted.

I tested this and it basically works, but it requires adding a Copy bound for dependencies:
#[entrait(Foo)]
fn foo(deps: &(impl Bar + Copy)) {
    deps.bar();
}

So I don't think this will be worth it.

But of course, the generated traits can be modified to have Copy as a supertrait 😎
If that is done, I think it will work.

Another consequence of this will be that it will be impossible to consume dependencies. But I can't really see any use cases for that, so should be fine.

Yet another consequence (which appears to be a good one) is that one no longer has to write & for deps:
trait Foo: Copy {
    fn foo(self);
}
trait Bar: Copy {
    fn bar(self);
}

fn takes_foo(deps: impl Foo + Bar) {
    deps.foo();
    deps.bar();
}

Have to investigate whether it will be possible to use e.g. tokio::spawn, cloning the underlying deps. Maybe it could be done with a separate trait. trait CloneUnderlyingValue { fn clone(self); }

It appears that it will be very hard to incorporate things like Clone into this reference-based solution. Working with Ts and &self is much easier than working with &Ts and self.

It appears that it will be very hard to incorporate things like Clone into this reference-based solution. Working with Ts and &self is much easier than working with &Ts and self.

Putting this one ice for now.


Changing theme breaks scroll bar

When changing theme from default to fluent, the scroll bar is no longer visible.
Repro

Replace FluentDark with SimpleDark here:

https://github.com/AvaloniaUI/Avalonia/blob/f6376e2ec0e2c143a8de35e8d2cc181b13390301/samples/ControlCatalog/App.xaml.cs#L72

Launch control catalog, a vertical scroll bar should be visible:

Switch to Simple - Dark (will do nothing, as it's already the current theme), then back to Fluent - Dark (now it changes). The scroll bar is not visible (it's in the visual tree, but I think the background is unset so not hit testable as well, scrolling with mouse works as usual):

Is not reproducible now with switching from default to fluent and back.


Add cert install step to the generate lockdown process

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows-iotcore/secure-your-device/SecureBootAndBitLocker.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


docs fix: dates in Recurring Tasks examples

Description
I've changed some of the dates in the examples to make them self-consistent.
I've also added the "assumed date" in one example to make it more immediately understandable.
Motivation and Context
It took me a bit longer to figure out how the recurrence relations work because the examples were a bit confusing to me.
Types of changes

Changes visible to users:

[ ] Bug fix (prefix: fix - non-breaking change which fixes an issue)
[ ] New feature (prefix: feat - non-breaking change which adds functionality)
[ ] Breaking change (prefix: feat!! or fix!! - fix or feature that would cause existing functionality to not work as expected)
[x] Documentation (prefix: docs - improvements to any documentation content for users)
[ ] Sample vault (prefix: vault - improvements to the Tasks-Demo sample vault)
[ ] Contributing Guidelines (prefix: contrib - any improvements to documentation content for contributors - see Contributing to Tasks)

Internal changes:

[ ] Refactor (prefix: refactor - non-breaking change which only improves the design or structure of existing code, and making no changes to its external behaviour)
[ ] Tests (prefix: test - additions and improvements to unit tests and the smoke tests)
[ ] Infrastructure (prefix: chore - examples include GitHub Actions, issue templates)

Checklist

[ ] My code follows the code style of this project and passes yarn run lint.
[ ] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[ ] My change has adequate Unit Test coverage.

Terms

[x] My contribution follow this project's contributing guide
[x] I agree to follow this project's Code of Conduct

Hi @st--
Thank you. Could you describe the changes you actually made please? What was wrong with the old dates and so how did you chose the new ones?

Could you describe the changes you actually made please? What was wrong with the old dates and so how did you chose the new ones?

In some of the examples, the years weren't consistent throughout the example. Maybe this was due to features being added later?
E.g.
https://github.com/obsidian-tasks-group/obsidian-tasks/pull/2601/files#diff-0da6c703d3753dedf34b4c78484d29231f2e9c2173f8e3bdfb6edf2aede66e9bR41-R44
-- [ ] take out the trash 🔁 every Sunday ➕ 2023-03-10 📅 2021-05-02
-- [x] take out the trash 🔁 every Sunday 📅 2021-04-25 ✅ 2023-03-10
+- [ ] take out the trash 🔁 every Sunday ➕ 2021-04-24 📅 2021-05-02
+- [x] take out the trash 🔁 every Sunday 📅 2021-04-25 ✅ 2021-04-24

Previously, it jumped to 2023 for the "marked complete"/"created" date even though the "due date" was living in 2021

https://github.com/obsidian-tasks-group/obsidian-tasks/commit/9e156fdc7d6fb964535d8dbd4817046517761d20#diff-7180dda3f3ee0ae61f9611e70893a879113dfb5d175cc4cce691ecc3b940ced4 was committed on 2023-03-10
and adds the following example:
- [ ] take out the trash 🔁 every Sunday ➕ 2023-03-10 📅 2021-05-02
- [x] take out the trash 🔁 every Sunday 📅 2021-04-25 ✅ 2023-03-10

which uses the commit date for the newly added functionality (completed date of previous occurrence -> created date of new occurrence) but kept the due date from before, which I found rather confusing. So I've just "backdated" the newly added dates in examples.

Super. Thanks for the replies.

Could you describe the changes you actually made please? What was wrong with the old dates and so how did you chose the new ones?

In some of the examples, the years weren't consistent throughout the example. Maybe this was due to features being added later?
E.g. https://github.com/obsidian-tasks-group/obsidian-tasks/pull/2601/files#diff-0da6c703d3753dedf34b4c78484d29231f2e9c2173f8e3bdfb6edf2aede66e9bR41-R44
-- [ ] take out the trash 🔁 every Sunday ➕ 2023-03-10 📅 2021-05-02
-- [x] take out the trash 🔁 every Sunday 📅 2021-04-25 ✅ 2023-03-10
+- [ ] take out the trash 🔁 every Sunday ➕ 2021-04-24 📅 2021-05-02
+- [x] take out the trash 🔁 every Sunday 📅 2021-04-25 ✅ 2021-04-24

Previously, it jumped to 2023 for the "marked complete"/"created" date even though the "due date" was living in 2021

I think the years were not consistent because it was trying to make the point that however late you complete a task that does not have when done, the new date is calculated from the previous due date.

I think the years were not consistent because it was trying to make the point that however late you complete a task that does not have when done, the new date is calculated from the previous due date.

I don't think so - the part where the year had jumped to 2023 only addresses whether a creation date is added when completing a recurrence.
The documentation of when done vs default is further below (where there were also some inconsistencies that I removed), and has explicit discussion of the dates in the surrounding text that also make me believe my changes are how it ought to be (given the surrounding explanation).

Setting to draft status any PRs which are not currently mergable, but will be useful in future.
I want to write some tests to confirm these changes, and ideally machine-generate the recurring tasks examples.


Blur Gif

The generated gif looks so blur, how can I fix it?

Hi,
By default not the original screen size is captured:
_width = _camera.pixelWidth / 4;
_height = _camera.pixelHeight / 4;

Please change the above settings in Recorder.cs file in order to improve the quality. Take in mind that changing these values will affect the final gif size.

Thanks for your reply, already found it.


2.X&3.X CN triggers

ahhh，I don't know why the build was failed.

for t8 line 97 you have a " ' "  to much at the end of the variable
t9 line 121: there is a space before the comma(at the end of the line) which needs to be removed
dun_scaith line 169: remove the empty line
shatter line 41: closing bracket has 2 spaces to much (allign it with the cn)

for t8 line 97 you have a " ' " to much at the end of the variable
t9 line 121: there is a space before the comma(at the end of the line) which needs to be removed
dun_scaith line 169: remove the empty line
shatter line 41: closing bracket has 2 spaces to much (allign it with the cn)

Thanks very much,all fixed.

Thanks! If you didn't know, you can run npm run lintfix and npm run test locally to see the same errors that the bot would give you.  https://github.com/quisquous/cactbot/blob/master/CONTRIBUTING.md#build-problems also tries to explain the process to get to the build error page where you can see the errors that Akurosia listed.

https://github.com/quisquous/cactbot/pull/1288
If you don't know how to do it, I invite you to read it all on this post. @quisquous  helped me a lot to install and understand how to do it locally.


contrib/analyze-local-image pollutes /tmp

As os.Exit() in go skips all deferred instructions, the statement defer os.RemoveAll(path) on line 116 gets executed only when our image has visible vulnerabilities.
So almost every time this tool is used the temporary directory /tmp/analyze-local-image-* remains.

Good catch!