Modify the summary section's margin/padding in case of anndata

Currently the summary section of the experiment page looks like this:

We need to remove the margin/padding on the top & left & right of the yellow box and align the text with the contents below.

It should look like this:

The changes in the CSS to create the above layout:

main-content-area : padding: 0; margin-top: 0;
experimentDescription : padding: 0px;
media-object stack-for-small anndata : padding: 0.9375rem;


[Feature Request] Integrate structured output for agent

Required prerequisites

[X] I have searched the Issue Tracker and Discussions that this hasn't already been reported. (+1 or comment there if it has.)
[ ] Consider asking first in a Discussion.

Motivation
Inspired by the recent progress of LLM on structured output: https://simmering.dev/blog/structured_output/. I think it is imporant to support structured output for agents. Here is a rough thought on how this could be look like:
from typing import List, Literal
from pydantic import BaseModel, Field

from camel.agents import ChatAgent

class Entity(BaseModel):
    name: str = Field(description="name of the entity")
    label: Literal["PERSON", "ORGANIZATION", "LOCATION"]

class ExtractEntities(BaseModel):
    entities: List[Entity]

agent = ChatAgent(...)

out_response = agent.step(msg, response_schema=ExtractEntities)
content: ExtractEntities = out_response.msg.content  # This will need message to support different schema

This could be also helpful for the knowledge graph agent as well.
Solution
No response
Alternatives
No response
Additional context
No response

Currently, there are three solutions and three different issues:
Add output schema in init chatagent;
Add output schema as a tool into tools of  chat agent;
Add output schema as parameters in agent step func;
But now there are three problems:
for step 1 init chat agent requires us to customize the OpenAI output schema. However, there are many conflicts with our for original architecture, which requires significant modifications to our existing structure. We discussed this with Zecheng, and it looks very complex.
for step 2 We need to convert Pydantic to a function and then add it as a function tool into chat agent's tools.
for step 3 We need to modify the structure of the step and the openai model run function. Since we use the function call method to implement this, it requires specifying the tools parameter for the OpenAI run, and we also need to modify the chat agent step to help us output the response with the output schema.

@lightaime @Wendong-Fan

finished


[SOS]The version  of 'wdio-sync'' package is old, the hook function 'AfterStep' misses args!

The version  of 'wdio-sync'' package is old.
There are three args, "hook", "step " and "result", when hookRunning.js invokes executeHooksWithArgs in wdio-cucumber-framework.
return _get__('executeHooksWithArgs')(this.config.afterStep, step, result);  //Line 67
But in old wdio-sync package:
var executeHooksWithArgs = function executeHooksWithArgs() {     var hooks = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : [];     var args = arguments[1];
...
The argument "result" will miss!!
Please fix it, thanks.

We use<EMAIL_ADDRESS>in package.json. It is latest version. Check your other dependencies and find how get older version.

Hi, @BorisOsipov
Thank you for replay, but the problem missing argument is still exsit, I think...

@pactera-testing-PanRenping Or maybe describe the issue you ran into, causes you to start investigating wdio-sync\cucumber internals

Hi @BorisOsipov,
Sorry for my late reply.
I did a test on my local.

Download the project git@github.com:webdriverio/cucumber-boilerplate.git
yard install
Realize a function in wdio.conf.js file
afterStep: (step, result) => {   console.log('Result: ' +result);     ... },
Then run the test.
I expect a result of step executed, but the value of the result is undefined, so I try to investigate why the result is missed.

I checked the wdio-sync module installed in my local node_modules directory. The context of code is older than you shared https://github.com/webdriverio-boneyard/wdio-sync/blob/master/index.js#L93
I download the package(https://registry.npmjs.org/wdio-sync/-/wdio-sync-0.7.1.tgz) and checked the context of the index.js are still old style...
I don't know which step I did wrong, please help.
(My real project dependences "wdio-cucumber-framework": "^2.2.2"  in package.json)

The last release contained an update to the wdio-sync package.


Extract target CPU architecture from unikernel binary

Currently, we rely on a non-standard ARCH instruction provided by the user to determine the CPU architecture for the container image.
This could be extracted by reading the ELF header of the unikernel binary, using GetBinaryArchitecture().
To do that, we should iterate over every COPY instruction and find the one that matches the file defined from com.urunc.unikernel.binary LABEL.

It seems bima expects the binary to be in ELF format, which is not always the case (see Unikraft on aarch64, as pointed by @ananos ). As a result, we should first determine the type of the executable file and then according to its format extract the CPU arch. In order to get the format of the binary we can use the filetype package. Then, we need to find a way to read Portable Executable (PE) format files to extract the CPU arch for the binary. I will have soon an implementation.


In Columns default functions are disabled by BigQueryExecutionContext's member get_insert_default

In following code is executed when default values are computed during inserts or updates.
https://github.com/googleapis/python-bigquery-sqlalchemy/blob/45fcad4111b9143fb1b9c309ed2a7578ae05d7a4/sqlalchemy_bigquery/base.py#L126
The default function is not invoked, and it instead returns random values or None if the type is not identified. Removing this implementation resolves the issue.

To solve this issue I had to patch the BigQueryExecutionContext with:
from sqlalchemy.engine.default import DefaultExecutionContext
from sqlalchemy_bigquery.base import BigQueryDialect, BigQueryExecutionContext
class BigQueryExecutionContextPatch(BigQueryExecutionContext):
    def get_insert_default(self, column):
        r = super(BigQueryExecutionContext, self).get_insert_default(column)
        return r

BigQueryDialect.execution_ctx_cls = BigQueryExecutionContextPatch

Thank you @csrocha for bringing up this issue. As commented on line 127, this function is intended for compliance tests only. If you are trying to implement a function that is not yet supported in this library, please open a feature request.
https://github.com/googleapis/python-bigquery-sqlalchemy/blob/83840941503ed8a16215b9a062631aae98d433ee/sqlalchemy_bigquery/base.py#L126-L131


List of known API paths

I noted in a couple comments that if there was a reasonably well-known list of uri paths that the coder app uses when connecting to the backing server, one could configure their frontend proxy to route some of the unused paths to different ports in the container.  This would allow the user to build and create a web app in the app, run it, and then view it directly in the browser at the same domain as the IDE.
For example, if you host your coder instance at ide.mydomain.com/ where requests are normally routed to the container's port 8443, you could configure your proxy to route requests to ide.mydomain.com/web/ to port 8080 in the container, which could be served by a web server running in the coder terminal.
The problem is I don't know what paths are available. (Or even if any paths are available at all -- all paths might be potentially meaningful to vscode internals, I don't even know that much.)  A (semi-)official list of used or open paths would be really helpful.
Here are some of the paths I've noticed that coder definitely does use just by interacting with the app:

/, root obviously, converted into a websocket
Direct assets like /file.png, /git.svg, /service-worker.js, etc
I think I saw some requests to /Resources/*, but I can't seem to reproduce it.

Are there any available paths that coder will never use?  If so, is the list above exhaustive, or are there additional paths that coder uses?

At the moment there is no guarantee that code-server won't use certain paths. The safest thing would be to always give the IDE its own sub-domain or sub-directory.
With that said, I believe this is an exhaustive list as it currently stands:

/
/<asset>
/resource/<path to resource>
/login
/login/<asset>
/tunnel
/ports
/ping
/lib/vscode/<path to asset>
/packages/ide/src/fill/webview.html

Perfect, thank you for this list!

Closing for now. Would be good to document the above at some point.


Unsafe lifetime

Add a new special lifetime, 'unsafe, that implicitly satisfies any constraint, but may only be instantiated within an unsafe context. This lifetime is used in situations where the true lifetime of a value is otherwise inexpressible, and additionally serves as a warning to readers that handling of the value requires special care. As a result, unsafe code is no longer ever required to use misleading "false" or redundant lifetimes, instead clearly stating that the invariants are maintained by custom logic instead of borrowck.
Rendered

I think it's worth considering how this feature interacts with unsafe code guidelines and affects the compiler optimizations (btw, is there any way to mention all the [unsafe code/memory model] group members?). I remember that @nikomatsakis showed that Ref snippet as an example of risk that sufficiently optimizing compiler could move dereference of the value after the drop of the borrow guard. Because of assumption that all the references are valid if they're accessible, they have a dereferencable attribute passed to LLVM (or at least they should). Now, since the 'unsafe lifetime could be shorter than a lifetime of the containing struct, it would make sense for &'unsafe not to have this dereferencable attribute.
I have also a few questions about the detailed design:
In this code, does the r and slice variables have the &'unsafe _ type?
let raw: *const u8;
let r = unsafe { &*raw };
let slice = unsafe { std::slice::from_raw_parts(raw, 5) };

If yes, then what about copy variable in the following code? Does it have the 'unsafe lifetime which is only coerced on the return of the function, or does the lifetime get inferred to be 'a?
pub fn split_at_mut<'a>(&'a mut self, mid: usize) -> (&'a mut [T], &'a mut [T]) {
    let copy: &mut [T] = unsafe { &mut *(self as *mut _) };
    let left = &mut self[0..mid];
    let right = &mut copy[mid..];
    (left, right)
}

I don't think there's any need to omit dereferenceable. The use case for this is situations like Ref/rental/owning_ref where the logical lifetime is dynamic and hence can't be specified in Rust's type system, but the code ensures that the reference is valid whenever it is dereferenced at runtime.

@krdln good food for thought. I'll ponder these some more and update my draft soon, but in the meantime, here are my initial thoughts:
Per snippet 1, I'd say that, no, slice would NOT have 'unsafe lifetime. 'unsafe could never be inferred as a lifetime unless the target of the assignment has been explicitly stated to be of unsafe lifetime. In the absence of such an explicit declaration, standard lifetime inference would ensue, resulting in a compiler error if no suitable concrete lifetime can be found.
For snippet 2, if we assume that the input slice is explicitly of unsafe lifetime, then the compiler is free to choose any lifetime for 'a and coerce it to that, as is currently the case with unbounded lifetimes. Only if the output is also explicitly 'unsafe would it remain unsafe. In short, 'unsafe is eager to decay into a concrete lifetime, as an unbounded lifetime is. I'm not sure if this makes implementation easier or harder though, so perhaps there are overriding considerations that those more familiar with borrowck are aware of.
As for the final example, the chosen lifetime should be 'x. Objects of unsafe lifetime can readily be coerced into objects of any other lifetime, which is both the power and responsibility of it. Instantiating an 'unsafe lifetime is dangerous and must be treated with great care, which is why they would typically be relegated to private struct fields within an unsafe implementation, and exposed only through safe API.
As for optimization, I'm nowhere near an expert on this, so I'll defer to those with experience, but it seems reasonable to me that 'unsafe would inhibit such optimization, since the compiler cannot know the logic that determines its true valid scope. However, remembering that 'unsafe readily decays into a concrete lifetime when it is reborrowed, optimization would still take place within those scopes, since using an unsafe value in such a way is a promise that it will remain safe and valid for the duration of the concrete lifetime into which it was coerced.

Added some detail about what precisely requires unsafe scope. I believe this should enable the scenarios it's intended to without any soundness holes, but it's entirely possible I've missed something.

It seems like what you're looking for is closer to 'self than 'unsafe. If a lifetime is called 'unsafe, it doesn't make much sense to allow it to be dereferenced in safe Rust. Simply requiring unsafe to create the value seems like a weak constraint. If the value were verifiably safe to use, it wouldn't need the 'unsafe name. For instance, in your example where there is RefCell<T> and Ref<'unsafe, T>, the RefCell would be dropped before the reference to it. Safe rust could trivially violate memory safety in the destructor there. As another example, if I created a struct with Vec<T> and &'unsafe T pointing to one of its elements, any &mut self could trivially violate memory safety.
If a lifetime called 'unsafe were to exist, it should not be possible to dereference it in safe Rust, which makes it only marginally different than NonZero<*const T>. Something like 'self could give more semantic information to the compiler to safely express the use cases laid out in this RFC, though there are probably some significant questions around how it would affect drop.

This rfc is weird as fuck, but it seems kind of neat anyway.
I'm not sure if I like it or not.

@sgrif Currently in Rust, you can easily get a reference which requires unsafe to create, but not to dereference. It's just & unsafe { *raw_ptr }. This happily coerces to 'static and can cause violations of invariants in other places in code, just as your &mut Vec example. So this RFC doesn't change the status quo regarding unsafe creation of “safe” references.

If a lifetime called 'unsafe were to exist, it should not be possible to dereference it in safe Rust, which makes it only marginally different than NonZero<*const T>.

If you're proposing 'unsafe to require unsafe block to dereference, it's a totally reasonable alternative (although since it's really simple to create such an „unsafe” reference in Rust, it doesn't really give you more protection). What's important though is that 'unsafe gives you much more than just NonZero<*const T> – it allows you to say: “I have this Struct<'a> from some library and I want all the &'a references inside this struct to behave like NonZero<*const T>”. That's currently impossible to express in Rust (unless you're going to copy all the code and manually change &s to *s).
You're right that in some cases 'self and proper self-referential structs would be a good solution (it's listed as an alternative), but, quoting the RFC:

However, that is a far more complex feature. In the meantime, the presence of this feature enables the implementation of self-referential structs at the library level today, if not with ideal ergonomics.

Also, I guess there are some usecases for 'unsafe that won't be covered by self-referential structs.

@sgrif I went back and forth a bit on whether interacting with a 'unsafe type in any way should require unsafe, instead of just creating one. As @krdln points out, creating an unbounded lifetime from a pointer dereference already establishes precedent here, but I'm open to the compromise of strengthening the constraint. However, it should still be the case that binding a lifetime parameter with 'unsafe should not effect the semantics of the body of the item being instantiated as outlined in the RFC. Further, interacting with a struct that has a private field of unsafe lifetime should not automatically be unsafe either.
But yes, the driving force behind this proposal is to be able to achieve a better API in rental. Currently this is impossible because the struct members I need to store are inexpressible. If there is a simpler, more minimal feature that will allow me to solve this, I'm absolutely open to it, but this proposal is the most limited I could come up with. I didn't just propose ``self` in the first place since that opens questions about existential lifetimes and has a much larger design scope. In the long term I do hope that happens, but this is a problem I've been running into for a while now, and I'm strongly motivated to arrive at a solution.

The concept of 'unsafe seems very similar to 'static (which itself is isomorphic to unbounded lifetimes), but also weirdly different in a few ways.  It does not feel particularly orthogonal to what already exists in the language.
I think the real problem here is that there is no way to tell the borrow checker to just ignore T: 'a constraints.  Adding 'unsafe feels more like a bandaid fix that ends up reinventing most of what 'static already does.
For this, it would be nice to have some way of deferring T: 'a constraints, e.g.
struct WrappedRef<'a, T>(Ref<'a, T> where T: 'a);

This is very much like the implied bounds idea (see also https://github.com/rust-lang/rust/issues/20671).  To an outsider, the T parameter in WrappedRef appears unconstrained.  But when you try to construct it, the compiler does enforce T: 'a as usual:
fn new<'a, 'b, T: 'a>(r: Ref<'a, T>) -> WrappedRef<'a, T> {
    WrappedRef(r) // checks to make sure T: 'a
}

After that, you can transmute WrappedRef<'a, T> to Wrapped<'static, T> freely, because the T: 'a constraint is hidden from sight.  You can then plug this into SelfRefStruct<T> without contaminating T with the T: 'static constraint.
This can obviously allow very dangerous violations of the trait system, but that’s what you get with transmute!

@Rufflewind That's a fascinating idea and worth exploring, but I have reservations. My primary concern is that it involves creating intermediate wrapper types for any type that needs its constraints deferred, since it can't be done generically. I'll have to think more about the implications this would have for rental and how I'd incorporate it, but on first blush it feels like it would generate awkward boilerplate that somewhat obscures the intent. Extracting the proper bounds to attach to the inner field would also be challenging and would almost certainly require a proc-macro. Although, using a proc-macro is on the roadmap anyway.
Personally I feel like 'static and 'unsafe being similar makes them two sides of the same coin. They both represent the safe and unsafe dual of the same concept, as references and pointers are the safe and unsafe dual of indirection. 'unsafe also still serves well as a flashing red warning sign that the type has deferred enforcement of its invariants to logic, while using 'static in that place still represents a "false type" that can't actually exist. One of the goals of this RFC is to eliminate such false types, and allow the field to truly express its nature, instead of relying on a transmute to shoehorn it into a signature that doesn't truly represent its invariants.

In motivation, the workaround of SelfRefStruct makes it sounds like what you want is not 'unsafe, but a "lifetime-of" operator.
struct SelfRefStruct<T> {
    owner: RefCell<T>,
    borrower: Ref<'lifetime_of(T), T>,
}

(Yes I understand that 'self is more appropriate here.)

@kennytm That's exactly what for<'a> Ref<'a, T>  would mean, which is what this RFC wants a simpler version of, AFAICT. Ideally, indeed, 'self (or 'owner, if we did it per-field) would be more appropriate.

@eddyb I did consider suggesting for<'a> as an alternative syntax, but it seemed a little odd to see it outside of trait bounds. If consensus is that it would be more appropriate though, I'm perfectly alright with that. I suppose my point of hesitation was that for<'a> doesn't imply any unsafety in the contexts in which is appears now, so having it do so in other contexts felt misleading, so I went for a more distinct form.

@eddyb I assume for<'a> Ref<'a, T> is just an alternative syntax of Ref<'unsafe, T>. (It looks like an existential lifetime that OP wants to avoid though https://github.com/rust-lang/rfcs/pull/1918#issuecomment-282587806.)
The lifetime_of example is different from this, it extracts the concrete lifetime upper bound of T at monomorphization time, e.g. you cannot assign a &'lifetime_of(&'a u8) T to a &'static T, unlike &'unsafe T.

I would say for<'a> is clearer, because the meaning of 'unsafe can become ambiguous/confusing in some contexts.  Consider say fn(R<'unsafe>): would that mean

for<'a> fn(R<'a>) or
fn(for<'a> R<'a>)?

Whatever choice you pick, it's clear that 'unsafe is inherently a less flexible solution than just enabling for<'a> in types.

I think the idea is that 'unsafe bounds would be confined within structs
and not exposed to users, so it is unlikely that you would have them in a
function signature in the first place.
On Mon, Feb 27, 2017 at 12:31 PM, Phil Ruffwind<EMAIL_ADDRESS>wrote:

I would say for<'a> is clearer, because the meaning of 'unsafe can become
ambiguous/confusing in some contexts. Consider say fn(R<'unsafe>): would
that mean

for<'a> fn(R<'a>) or
fn(for<'a> R<'a>)?

Whatever choice you pick, it's clear that 'unsafe is inherently a less
flexible solution than just enabling for<'a> in types.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1918#issuecomment-282843708, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA9A-mwKwHmhqU_Z-N07_X663n5TG3Cdks5rgzKSgaJpZM4MIGef
.

you cannot assign a &'lifetime_of(&'a u8) T to a &'static T, unlike &'unsafe T.

That's the same for for<'a>: for<'a> &'a &'b u8 would be &'b &'b u8.

I'll admit there is one appealing aspect of the for<'a> option, which is what you can name 'a whatever you want, which could be self-documenting. The example in the RFC could be for<'owner> Ref<'owner, T>, which clearly suggests what's going on, and is a nice approximation of a theoretical eventual "field lifetime" syntax.
I'm not quite 100% convinced yet, and I'll give others a chance to chime in, but I'm getting there. Just to make sure we're all on the same page, the new proposal would be mostly identical to the old proposal except with for<'a> syntax instead of 'unsafe. However, since 'unsafe no longer exists, and I'm not sure how you'd use for<'a> in expression position, perhaps the part about unsafe expressions can simply be removed completely. I'd also remove the portion about legal, unsafe coercions from concrete lifetimes into 'unsafe (now for<'a>)), instead simply requiring a transmute to achieve it. This would now be the only way you can create such a value. In other words for<'a> values may only exist as l-values, and when used in an expression they decay into whatever is appropriate for the expression as an unbounded lifetime.

@jpernst Transmute is not necessary, &* on a raw pointer would do the job.

@eddyb Ah, right, of course. So any situation that can currently produce an unbounded lifetime would be compatible, and transmute for all other cases.

I'd much prefer R<'unsafe> than for <'a> R<'a> from a readability point of view (I see the point that implementation-wise it's a lifetime that can coerce to any other lifetime though). First of all, the for version looks like a totally safe to use type, and I really fail to see here why should the for <'a> R<'a> be different from R<'static> (assuming that R has &-like variance).
The second reason is that I think for <'a> tells the opposite story than the autor wanted to say. I consider R<'unsafe> to be more like
exists<'a> R<'a>

@krdln That's the point, it's unsafe to lift to that (always longer or equal than reality) lifetime.
But I agree it could be misleading as a real valid lifetime.
As for existential lifetimes, they're just as unsafe unless you can link references to their allocations.

'unsafe also has a minor advantage in that it doesn't involve any changes to the type grammar. I'm not sure how big of a deal that would actually be though; likely not too much.

@krdln Although I think existential lifetimes are a great addition by themselves, their semantics are more like raw pointers (safe to construct, unsafe to use).  In fact, I think *const T is approximately equivalent to exists<'a> &'a T.  However, this proposal seems to want "unsafe to construct, safe to use" semantics instead, which would require for<'a>.
(I personally think existential semantics are more appropriate here, as they prevent the dangerous possibility of accidental unification with 'static.)

Removed the section about general coercions into 'unsafe, since regardless of which way this plays out, I don't think that section offers real value. They are still allowed for unbounded lifetimes.

@Rufflewind I'm not opposed to existential semantics in principle, but I'm concerned about the practical design implications. IIRC they've been floated and postponed before, so I'm trying to avoid retreading that ground by sticking as closely to established semantics and precedent as possible. If those familiar with borrowck's implementation and the implications of existential semantics think it's doable, then I'm on board, but for now I'm trying to blaze the shortest, narrowest path to the expressiveness that I'm blocked on.

Just as a note on the impetus behind this RFC: Just today I've fielded another support request for someone using one of my crates who wanted to store some of the structs it provides beside eachother in their own struct. This is currently inhibited by their lifetime parameters, and even rental can't yet solve it for that case, so my motivation remains strong.
I've felt pressure and been tempted to relent and just use reference counting to eliminate the lifetime params, but I really don't want to just toss away a core benefit of rust to fix this issue. I am concerned, however, that this might be silently happening in the ecosystem already. Several APIs either provide RCed alternatives, or are simply just RCed to begin with, to avoid this issue.

@rfcbot fcp postpone
So, I think this RFC is addressing a genuine problem, but I feel like I would rather revisit this syntax when the unsafe-code-guidelines effort has progress a little further. In particular, I feel like some aspects of how unsafe code is written may change, and there may be additional semantics we would like form an &'unsafe T reference that we cannot know at the moment. Therefore, I propose that we postpone the RFC.
I teetered a bit on this proposal, in that I also considered that it might be useful to merge the 'unsafe lifetime but keep it unstable. But I actually don't see what we will gain from experimentation that is not already clear -- and libraries that used it would be nightly only -- hence I think I'd rather just wait.

Waiting for the unsafe code guidelines before stabilization is perfectly reasonable and I support that, but I have one final plea for feature gating this sooner and allowing it to evolve.
The immediate use of this feature will be to prototype a better library-level solution to the self-referential struct problem, and I have a few ideas on that front that I'd like to begin exploring. At this stage I can't fully envision the implications of the API for all scenarios or how it will interact with real world codebases, and there's no way to test it currently since the implementation for the API I'd like to expose cannot be written. I'm willing to follow along with the unsafe guidelines as they evolve and ensure my solution is fully conformant, in the interest of having a viable day 1 solution at such time as whatever final semantic form stabilizes.
Either way, thanks to all for the consideration and discussion of this RFC.

I found another crate that would benefit from this: shawshank
Currently, it uses the type signature struct ArenaSet<O: StableAddress, I = usize, M = HashMap<&'static O::Target, I>>, but the 'static should be an 'unsafe.

My first reaction is "just use 'static to mean this, that's what I do".
My second reaction is "oh, that's kind of gross, I see what the point of this is now".

Would it make sense to at least reserve 'unsafe in the mean time to reduce the risk of future breakage?

@Storryyeller I thought all keywords were reserved in lifetime names, is that not the case?

I didn't realize that. In that case, there's no problem.

Closing as postponed. Thanks @jpernst!


Get AssetHost to connect to AWS from Rancher

Currently this is not happening because reasons.  Work will probably be mostly on Synctree's side.

done


v0.0.1 checklist

Put together a checklist containing everything you feel is necessary for this library's very first pre-release. I know that I want, at the very least, to be able to read and write well-formed CSV files and to be capable of dialect/flavor auto-detection at least 75% of the time. I think it's probably well above that already. I'm not going to require schemas (at least not beyond a rudimentary implementation) or any kind of CSVW compliance. Yet.
Go through whichever of the following don't currently have an associated issue/ticket and create one, then put each item's ticket number before its description.
Note: Another name I was considering for the library was "PHabular" or "PHabulous" because it isn't necessarily only CSV. The scope of the library is more than just CSV import/export. It deals with all tabular data. Think about other names.
v0.0.1 Feature Checklist

[ ] CSVelte\Reader - line iterator class (should this be Parser? I don't think it should. Parser makes CSV sound like some complex format when it's literally the most stupid-simple pseudo-format I can think of)
[ ] CSVelte\Contract\Readable - To be readable by the Reader class, implement CSVelte\Contract\Readable. Write concrete implementations of the most common sources (file, stream, string...)
[ ] CSVelte\Writer - Capable of writing a line at a time or by accepting an iterable and writing a line for each iteration
[ ] CSVelte\Contract\Writable - To be writable by the Writer class, implement CSVelte\Contract\Writable. Write concrete implementations of the most common outputs (file, stream, string, stdout?)
[ ] CSVelte\Flavor - Simple class that dictates the "dialect" or formatting details of a particular file
[ ] CSVelte\Flavor* - Need concrete implementations of the most common dialects: Rfc4180 (Excel), ExcelTab, StandardCSV, StandardTSV, etc. (python's csv module has excel, excel-tab and unix dialects built-in)
[ ] CSVelte\Taster - Automatically detects dialect (tastes flavor) of a CSV data source, given a small sample
[ ] CSVelte\Reader\Row column iterator

v0.0.1 Bug Checklist
Coming soon...
v0.0.1 Task Checklist

[ ] Write documentation, create PDF, text (markdown), and web versions of it (at github.io homepage)
[ ] Put together a script or find a service that will help you with deployments for consistency. I used to use Phing but I'm sure there are endless options for SaaS deployment nowadays
[ ] Update README document to tell users where they can find documentation and what the scope/aim of the library is.

This should actually be v0.1.0 and this is the first of 3 issues exactly like this... lol


feat: add tags

Summary

Add tags.toml
Check all tags in terms are legal, when the -- --check flag is provided
Show tags on static page, each badge is clickable and will filter table to only show rows with the tag
Refactor the js code and move them to separate js files.

Details

demo can be found here: https://antoncoding.github.io/Terms/
both tags.js and seach.js filter the table at the same time, that's why we need an extra filtered class for each row to compound the effect. for example: If you type something in the search bar and then click on one tag, it only shows you rows fitting the search result + filtered by tag.
This will resolve the last checkbox defined in #9

@ChihChengLiang I think it make more sense to have one general --check flag instead of having multiple flags, it suits better into the current main.rs flow and serve the purpose well, that's why i added it this way, but lmk what you think


Add option to make zt and zb commands move cursor to really first and last lines of the window.

The title says it all.

Are you aware that the current behaviour is the default behaviour in vanilla (neo)vim? If want the screen to scroll until the cursor is at the first/last line of the window then you can simply set scrolloff=0.
If I'm missinterpreting the title please explain further what you want.

Yes, it is the default behaviour in neovim. It is written in :help zt.

My scrolloff option is 0.

According to :help zt it should puts current line at top of window

This is true as long as scrolloff=0. Try opening a file with nvim -Nu NONE and then :set scrolloff=5. You'll see that the cursor does not go to the top of the screen if you press zt (unless you are at the top of the file).
Can you please run :set scrolloff=0 and check again if zt/zb bring the cursor to the top/bottom of the window? This issue could be related to #11 somehow.

Yes, it is related to #11 .

set scrolloff? returns 0;
set scrolloff=0 doesn't help;
setlocal scrolloff? retruns -1;
setlocal scrolloff=0 fix the problem;
And the most interesting: :lua print(vim.wo.scrolloff) somewhy retuns 9, which is the root of the problem.

Yes... So I tried to provide a workaround to neovim/neovim#13964 in #11 but it will break when the garbage value of local scrolloff is between 0 and half of the window size. I can't do any better than this until the neovim issue is fixed because I have no way of knowing if you set that local scrolloff=9 or is a garbage value. However, you can fix this by explicitly setting the local scrolloff in your vimrc (setlocal scrolloff=0).

Thank you!


[Feature]: Enhanced Point In Time Recovery for existing databases

Is there an existing issue already for this feature request/idea?

[x] I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

What problem is this feature going to solve? Why should it be added?
Currently, the Point In Time Recovery feature allows for creating a new database from a specific point in time. However, there is a need for the ability to revert an existing database to a previous point in time, without changing its current backup configuration. This feature would be beneficial for users who need to recover data from a specific point in time, but do not want to create a new database or modify the existing backup configuration
Describe the solution you'd like
The solution I propose is to add a new feature to CloudNativePG that allows for reverting an existing database to a previous point in time. This feature would utilize the existing backup configuration to restore the database to the desired point in time.
To automate this process, I suggest adding a new Kubernetes Job resource that can be triggered to perform the point in time recovery. This Job would take the name of the database and the desired point in time as input, and would use the existing backup configuration to restore the database to the specified point in time. The Job would also handle any necessary cleanup or rollback operations in case of failure.
This solution would provide a more efficient and scalable way to recover data from a specific point in time, without requiring any changes to the existing backup configuration. Additionally, automating this process using a Kubernetes Job would provide a more efficient and scalable solution, especially for large databases or clusters.
Describe alternatives you've considered
A more complex alternative approach would be to create a custom Kubernetes operator that can perform point in time recovery on demand. This operator would watch for custom resources that specify the database name and desired point in time, and would initiate the restore process using the existing backup configuration. This approach would provide the most flexibility and automation, but would also require the most development effort.
Additional context
No response
Backport?
No
Are you willing to actively contribute to this feature?
No
Code of Conduct

[x] I agree to follow this project's Code of Conduct

+1


Add image_id to json output

Consumers of the json output, like the atomic cli, need the ID of the
image for the container as well as the name.  Specifically, it is used
to tract "used" and "vulnerable" images.
Signed-off-by: baude<EMAIL_ADDRESS>

LGTM

LGTM

Looks like travis blew up.

Tests pass.


asynlocal: make open_async compatible with fsspec

Closes #24.

cc @vovochka404. Could you please try this and see if works?


UP-4700: Configure PAG caches with TTL of 180 and added JGroups liste…

…ner. Also Added TTL of 8 hours to resource caches.
https://issues.jasig.org/browse/UP-4700

Coverage increased (+0.007%) to 22.878% when pulling 1a0e8b78d17db9ee5268415cad5e29f7b7d05f1c on bjagg:UP-4700_configure-PAG-caches into 47247bdb315d3715b5a9f9c840d25ac87af56332 on Jasig:master.

+1


fix: Indicate this package is for the whole Open edX project

@arbrandes or @brian-smith-tcril is this a change we can make? I was updating https://docs.openedx.org/en/latest/developers/references/legacy_guide/style_guides/sass-guidelines.html to use "Open edX" instead of "edX" (https://github.com/openedx/docs.openedx.org/pull/414) and wanted to match the README on this project... assuming this package is actually used by the whole project

:tada: This PR is included in version 2.3.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add CTDNE (time-based random walk) demo

See #827
I've omitted this notebook from CI for now - I guess I need to add the new dataset in the datasets module? I can do that here or in a separate PR depending on which is preferred for reviewers, but I think the notebook can be reviewed for its general content/workflow regardless.
@habiba-h I kept your approach of comparing biased random walks to temporal walks - there's barely any difference in the performance though 🤷♂
Also added the link prediction utilities directly in the demo - it ended up looking fine I think, so I'll probably close #1020

I can do that here or in a separate PR depending on which is preferred for reviewers, but I think the notebook can be reviewed for its general content/workflow regardless

It'd be good to land this being checked by CI rather than have to add another FIXME. I'd be happy to see the dataset added here or in a separate PR (that lands first).

It'd be good to land this being checked by CI rather than have to add another FIXME. I'd be happy to see the dataset added here or in a separate PR (that lands first).

@huonw I've opened https://github.com/stellargraph/stellargraph/pull/1058 if you're interested in reviewing!

Thanks everyone for the reviews! Will merge once CI passes


shutdown/reboot: provide the ability to easily access the Unified Extensible Firmware Interface

Windows provides shutdown /r /fw /f /t 0 to perform this, and
systemd provides systemctl reboot --firmware-setup for Linux, and
efibootmgf -f is available for BSD.

Consequently, for shims such as https://github.com/adoakley/efi-boot-to-fw-ui to be necessary when utilizing openrc disappoints me. I am unable to recommend some distributions merely because this feature is absent, and this is especially problematic for postmarketOS, because absence of this feature means that no decent replacement to adb reboot bootloader exists.
I am thankful for any assistance.

are you using OpenRC's init, or sysvinit ?

@vapier, I was using whatever PostmarketOS uses. I don't know what that is. I don't have a device with it installed currently to ascertain it.
Do you want me to create a VM and try to ascertain which, or would you rather? I don't know what exactly to search for after configuring the VM.

no need to reinstall.  my point is that if they're using sysvinit, you'd have to put in a request with that project instead.  if they're using OpenRC's bundled init, then it's something we can look at.

@vapier, per https://matrix.to/#/!zpvMifoucHSiUsVFgl:postmarketos.org/$OKfh4lqbxgTGraKh4obtPPhzV6PZWdIaoe7ng0Sh-6k?via=matrix.org&via=kde.org&via=tchncs.de, always OpenRC. I trust Newbyte and the official wiki enough to state this in confidence.

https://github.com/OpenRC/openrc/issues/539#issuecomment-1453572722

@Newbytee, I've been waiting a while for a response...

In which case, @Newbytee, should this be reported to https://bugs.busybox.net/enter_bug.cgi?product=Busybox&component=Standard Compliance?

The answer is that I'm not 100% sure.

https://github.com/OpenRC/openrc/issues/539#issuecomment-1986845118

https://xdaforums.com/t/what-initialization-system-does-postmarketos-use.4660936/post-89389406

https://github.com/OpenRC/openrc/issues/539#issuecomment-1986852664

https://wiki.postmarketos.org/index.php?title=Boot_process&oldid=47210#Overview:~:text=postmarketOS initramfs-,openrc,-LightDM (if%20UI states https://wiki.postmarketos.org/index.php?title=OpenRC&oldid=42949#:~:text=it is the default system in postmarketos - that it is currently OpenRC.

Paraphrased, this Reddit comment explains that the command is:

I was going to tell the guy about that. However, I don't have an account on GitHub after losing my 2FA credentials. In OpenRC, this is how you'd run it, because OpenRC uses elogind:
loginctl reboot --firmware-setup

so I shall close this issue as invalid, for it appears possible, and is outside the remit of this issue (due to using loginctl, rather than the requested reboot and/or shutdown). If I am incorrect, please inform me - I can't test the command myself anymore.


MusicBrainz Picard has wrong Version

Create issues related to the winget.exe client here

Brief description of your issue

Actual Picard Version is 2.6.3, not 2.6.30000.0
Please revert commit 04c47b52ea0729a2400d39ce4474c7999ce0e0f6
Steps to reproduce

PS C:\WINDOWS\system32> winget upgrade
Name               ID                 Version Verfügbar   Quelle
----------------------------------------------------------------
MusicBrainz Picard MusicBrainz.Picard 2.6.3   2.6.30000.0 winget

Expected behavior

Actual behavior

Winget displays Picard as upgradable
Environment
[winget --info]
Windows Package Manager v1.0.11692
Copyright (c) Microsoft Corporation. Alle Rechte vorbehalten.

Windows: Windows.Desktop v10.0.19043.1165
Paket: Microsoft.DesktopAppInstaller v1.12.11692.0
Any other software?

Those changes were made because the MSIX version displays its version as 2.6.30000.0 and not 2.6.3
Adding the .exe installer to the manifest (probably at the very top) and reverting the version back to 2.6.3 should fix it.

This is a huge inconsistency from the developer
MSIX

EXE

We could probably get away with
Publisher: MusicBrainz
PackageVersion: 3.6.3

because of the Wildcard, hopefully Manifest Schema 1.1.0 solves this in another way

I have apparently both installed what I never intended.
Apparently winget evaluates the DisplayVersion in the uninstall hive and ignores the MSIX value.
Imo the inconsistency is in WinGet and you should always stick to the EXE DisplayVersion.

WinGet uses the Metadata the Installer defines in the ARP, the inconsistency is clearly from the Developer as you can see in the Screenshots.

PS C:\WINDOWS\system32> Get-AppxPackage -AllUsers -Name "*Picard"

Name                   : MetaBrainzFoundationInc.org.musicbrainz.Picard
Publisher              : CN=Metabrainz Foundation Inc., O=Metabrainz Foundation Inc., L=San Luis Obispo, S=California,
                         C=US
Architecture           : X64
ResourceId             :
Version                : 2.6.30000.0
PackageFullName        : MetaBrainzFoundationInc.org.musicbrainz.Picard_2.6.30000.0_x64__6cfbg5p5jt8h8
InstallLocation        : C:\Program Files\WindowsApps\MetaBrainzFoundationInc.org.musicbrainz.Picard_2.6.30000.0_x64__6
                         cfbg5p5jt8h8
IsFramework            : False
PackageFamilyName      : MetaBrainzFoundationInc.org.musicbrainz.Picard_6cfbg5p5jt8h8
PublisherId            : 6cfbg5p5jt8h8
PackageUserInformation : {S-1-5-21-3768236630-1315502409-3914677840-1001 [ralfh]: Installed}
IsResourcePackage      : False
IsBundle               : False
IsDevelopmentMode      : False
NonRemovable           : False
IsPartiallyStaged      : False
SignatureKind          : Developer
Status                 : Ok

WinGet uses the Metadata the Installer defines in the ARP, so you should always stick to this value.

Reverting commit 04c47b5 should fix this for now

It will not as i stated in a earlier comment.

So you say 5396ff3 didn't work and  04c47b5 didn't break it? It seems that we have different ideas about working software. Sorry for bothering you.

2.6.3 is the EXE version, 2.6.30000.0 is the MSIX version, you have the EXE version installed, when you do winget upgrade it will not update the software, if you do winget install it will install the MSIX version.

As I understand: There are 2 Picard programs, totally unrelated from a system point of view. They can exist side-by-side with different versions. winget upgrade must not report or even query the ARP-Values (EXE) for the MSIX-Package. This is a serious bug in the code imo. Furthermore I have the strong suspicion, that winget installed the MSIX-Package on my System "upgrading" from 2.6.2 to 2.6.3.
I wonder what the point of packaging the store "Picard" is. They should update automagically, unless i explicitly disable it. Then I wouldn't like it at all if winget would tamper with it.

@rhemberger we've encountered several programs that support side by side install for different versions. Generally an MSI or an MSIX is treated as a single package where the upgrade is only going to upgrade a package rather than install another instance.
The challenge is related to how we can be informed in a manifest when this side by side case exists. We currently attempt to upgrade with the same type of installer. In the case of an .exe supporting multiple versions side by side, we have work coming to help disambiguate what is happening. We also need a good mechanism to inform an user so they can decide if they want to keep the existing version and add the new one, or remove one or more of the existing versions to install only the latest (or the version specified).
I ran into this scenario with Ultimaker.Cura. They do have an MSI for their enterprise customers (not in this repository), but the .exe installers just add the new version. This results in multiple versions on a system, and any of the earlier versions all show an upgrade is available. The challenge here is to understand what the publisher intends, and give the customer the right information to make the informed choice if they wish to override the publishers default intended behavior.

That's not my point. I think Store Apps have their own namespace and you use Get-AppxPackage for queries (or wherever in the registry the information is stored). For classical EXE/MSI you query the ARP-Entries/Registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall etc.


Estimate item views in May

Question originally posed in this thread.
We need to report the following values for May:

total non-unique images viewed
total non-unique items viewed
total non-unique digitised works viewed (where a digitised work is an item or an image, ie the sum of the previous two metrics)

Having validated the methodology using data from April (images, items), we can do the same thing with May (images, items)
But there's a step change in the items counts around 9th May!

It turns out we stopped tracking the source:viewer/paginator tag in this PR before adding in an equivalent source:viewer/scroll event on the 25th. Filtering for viewer/scroll as well gives us this graph:

We should try to find a reasonable estimate of what the values were between the 9th-25th so that we can still report some (caveated) stats.

Naively, I think we can just take the period where no filters are available, and just count the rough share of those events which are usually left after filtering...
Best guess at last source:viewer/paginator event timestamp (t1): May 9, 2023 @ 14:41:10.973
Best guess at first source:viewer/scroll event timestamp (t2): May 25, 2023 @ 15:05:00.491
Number of filtered events before t1: 26,890
Number of filtered events after t2: 23,659
Number of unfiltered events before t1: 209,555
Number of unfiltered events after t2: 214,686
Share of events which are left after filtering:
Before t1: 26,890 / 209,555 = 0.128
After t2: 23,659 / 214,686 = 0.110
Both: (26,890+23,659) / (209,555+214,686) = 0.119
Number of events between t1 and t2: 391,780
(events between t1-t2) * share of events typically discarded: 391,780 * 0.119 = 46,681
Total estimate for May: 26,890 + 46,681 + 23,659 = 97,230


[wip] Host cluster-local-domain-tls on cluster-local gateway with SNI

Changes

Add cluster-local https servers when cluster-local-domain-tls is enabled and a KSVC exists
Uses SNI to host multiple certificates for all cluster-local domain Knative Services

/kind enhancement
Fixes https://github.com/knative/serving/issues/14374
Release Note
net-istio now hosts an additional gateway with TLS for each Knative Service when `cluster-local-domain-tls` is enabled. Note: this is an experimental alpha-feature.

Docs
Will be done once the features is complete
/hold work in progress

Did some testing with Serving @ https://github.com/knative/serving/pull/14610, looks good. Test setup here.
@skonto PTAL. Note: I'm fine with waiting until Serving is merged, then we can add this here and also do the full test-set with with net-istio in Serving.

/unhold
Serving PR has been merged, @skonto PTAL.

As discussed with Reto the landing page of this repo is not ideal. There is no doc explaining what is supported and how. For example here we are moving to a design choice of having one gateway per svc for cluster local stuff but it is not captured somewhere etc. I think we need to spend some time adding content here.

minor comments, LGTM. We can stamp if @dprotaso has no other comments.


is Phone Auth supported on this boilerplate?

Description :-
I have to enable Phone Auth in my app. As per docs, i have to call the below method:
window.recaptchaVerifier = new firebase.auth.RecaptchaVerifier('sign-in-button', {
  'size': 'invisible',
  'callback': function(response) {
    // reCAPTCHA solved, allow signInWithPhoneNumber.
    onSignInSubmit();
  }
});

to generate a 'recaptchaVerifier' which is going to be user the next method as follows:
var phoneNumber = getPhoneNumberFromUserInput();
var appVerifier = window.recaptchaVerifier;
firebase.auth().signInWithPhoneNumber(phoneNumber, appVerifier)//here as '**appVerifier**'
    .then(function (confirmationResult) {
      // SMS sent. Prompt user to type the code from the message, then sign the
      // user in with confirmationResult.confirm(code).
      window.confirmationResult = confirmationResult;
    }).catch(function (error) {
      // Error; SMS not sent
      // ...
    });

but as i call the method 'firebase.auth.RecaptchaVerifier' , it throws an error saying 'document not defined', when i did some research on this, i found that this method need document to look for specified id as mentioned in its first argument.
So how can i use this in React Native App as per my understanding it don't have document to look for.
Help us reproduce - tell us about your environment

i'm using Mac for development.
"name": "StarterKit",
"version": "1.0.0",
Issue is for both iOS and Android

Steps to reproduce

To reproduce the issue, hit below code(as per docs):
    Firebase.auth().useDeviceLanguage();
    let recaptchaVerifier = Firebase.auth.RecaptchaVerifier('sign-in-button', {
      'size': 'normal',
      'callback': function (response) {
        // reCAPTCHA solved, allow signInWithPhoneNumber.
        this.onSignInSubmit();
      }
    });

Expected result

It should ask for captcha verification.
Actual result

It throws an error saying 'Document is not defined'

Hi @paritosh-yadav
I'd suggest checking out an alternative Firebase implementation.
This project uses the official Firebase JS implementation, however for your project, it might be worth looking into something like this one, which states that it supports Phone Auth.
Interested to hear how you go/which direction you go in to get Phone Auth working.


⚠ Bofrost.de has degraded performance

In 33fbddd, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1450 ms

Resolved: Bofrost.de performance has improved in cb61d93 after 13 minutes.


一边标注,一边创建新标签, Create a new label while labeling

一边标注,一边创建新标签
不要返回项目 设置 再增加新的 标签
Create a new label while labeling
Do not return to the project settings and add a new label

You can create a new project yourself,  instead of adding tags to the original

Unknown label.  You  need to add a label to the original project
Because the new project is not sure what labels there are
Instead of letting me recreate a new project
What is required is that during the labeling process:
You can easily add labels
Instead of specifying fixed labels in the project
Because the label is not fixed


don't expose tether anymore

Ref #329

Current coverage is 92.06%

Merging #335 into master will not affect coverage as of f99a93b

@@            master    #335   diff @@
======================================
  Files            9       9
  Stmts          189     189
  Branches        42      42
  Methods         94      94
======================================
  Hit            174     174
  Partial          4       4
  Missed          11      11

Review entire Coverage Diff as of f99a93b

Powered by Codecov. Updated on successful CI builds.

@raptoria, is there a chance you could try this out before we merge it so we can make sure it solves your problem?  I built the branch and pasted the contents of react-datepicker.min.js here: http://hastebin.com/falidujulo.js  If you replace the contents of react-datepicker.min.js with that you should be able to try it out.  Let us know!

It solves the setState error, and works wonderfully in IE10 as well.

Ah yeah, I think datepicker__container got changed to datepicker__tether-element.  Here's the new stylesheet: http://hastebin.com/cuheroyema.css  Let us know if that works.

are you guys going to publish the latest version to NPM? thanx!

Just released v0.21


compare with the code in the original paper

The difference might be because of differences in the way the word embeddings are updated.
Can you make it more specific?

I'm confused about why update word embeddings can cause performance decrease, may be some comparison experiment should be done with original lua code.

Hi @wq343580510 and @ryh95
Got stuck with some other work, did not have time to reply to you guys!
So one of the major differences is that in the original implementation, the embeddings are updated using plain SGD, while the rest of the model is updated using the optimizer. In my implementation, however, I use the same optimizer to update the entire model including the embeddings. This can potentially lead to slight differences across batches and epochs, resulting in different performance.
In the original implementation, this line updates word embeddings, while this line updates the remaining parameters.
Of course, other minor differences might still be present, such as differences in weight initialization. I have tried to use the hyperparameters as specified in the paper, but it is quite possible I missed something! I was trying to implement this model to learn more about dynamic neural networks in PyTorch, and the minor gap in results seemed acceptable to me at the time, so I never investigated further.

Hi @wq343580510 and @ryh95 ,
The original implementation deals with word embeddings by updating them separately using plain SGD, as demonstrated by these lines:

Updating word embeddings
Updating all other parameters

However, as pointed out in another issue #17, the text of the original paper mentions freezing the word embeddings, which I have since incorporated as of this commit which adds the option of freezing the word embeddings during training. This results in a slight improvement to the metrics, and we can now reach Pearson's coefficient of 0.8674 and MSE of 0.2536.
Since we are now within ~0.0005 of the original paper, albeit with a different learning rate, I don't think I would be spending any more time optimizing this further. However, any contributions (PRs/bug fixes) are always welcome and will be merged. :slightly_smiling_face:

Can you please share the arguments namespace for which you got Pearson's coefficient as 0.8674 and MSE as 0.2536 ? In how many epochs did you achieve this? Was the random seed '123' ? Sorry, I am unable to reproduce the your exact result with this code. Any little help will be appreciated! Thank you in advance


Upgrade to Vert.x 4.1.4

Fixes #955

@Sanne Quarkus seems to be still on 4.1.3, any particular reason?

I'm not sure. I suspect the team didn't get to it yet as it was just released :) Let's give them a couple days to test?
But we could merge this if you need it quickly, since there are no code changes it should be easy to override the versions in Quarkus (in worse case); just be careful in tracking 4.1.4 specific funcionality in subsequent patches, in the remote case in which this would need to be reverted.

I prefer to wait for quarkus. This version is needed for #911 and #912 but we haven't a pr yet

Looks like https://github.com/eclipse-vertx/vertx-sql-client/issues/1033 didn't get fixed in 4.1.4, so DB2 "grouped" strategy will still be broken.

Looks like eclipse-vertx/vertx-sql-client#1033 didn't get fixed in 4.1.4, so DB2 "grouped" strategy will still be broken.

That's ok for me. We can focus on MSSQL and we will fix Db2 when we can


Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)

[ ] iOS
[x] Android
[ ] UWP
[ ] watchOS
[ ] tvOS
[ ] Tizen
[ ] .NET Standard

Feature Library

[x] Core
[ ] BluetoothLE
[ ] Beacons
[x] Locations
[ ] HTTP Transfers
[ ] Notifications
[ ] Sensors

Version of Library
<IP_ADDRESS>4-beta
Version of OS(s) listed above with issue
Android 8
Steps to Reproduce

Create few geofences with await _geofenceManager.StartMonitoring(reg);
Set Notify Enter and Exist = True

Expected Behavior
It does not call delegate method until we enter geofence point
Actual Behavior
It calls delegate method with Shiny.Locations.GeofenceState.Exited status for every geofence point that was added

This is simply how some flavours of android behave.  It isn’t anything I’m triggering.

Thanks for quick reply. There is a way to avoid initial trigerring. Here is good explanation https://stackoverflow.com/a/46773123/604790
GeofencingRequest.Builder().setInitialTrigger(NO_INITIAL_TRIGGER)
What do you think?

It isn't that simple.  I need the initial values for checking current state.  I'll look into this for a future release.


Replace string-hash with a Java compatible version

It is faster, removes a dependency that is unmaintained and license-less,
and doesnt make it harder to maintain.
See https://github.com/quicktype/collection-utils/pull/3

I might need some help figuring out the package.in.json and their lock files in build/.

@hansl Could you point me to the corresponding Java code and/or some docs about this hash function?
I'm happy to merge this, but I'll rewrite it to just use the version in collection-utils.
As for the build directory, check out PACKAGES.md.  I think/hope it's up-to-date.

Hi @schani,
I repushed after running those scripts. Not sure why it added a package.json in the build/quicktype-core directory.
For reference on Java String hashCode() implementation, the doc has the algorithm; https://docs.oracle.com/javase/6/docs/api/java/lang/String.html#hashCode(). Using bitwise operation is faster than multiplying.
Please note that this is the same as the string-hash package implementation, except that string-hash uses a start hash of 5381 for some reason (see https://github.com/darkskyapp/string-hash/blob/master/index.js)...

I'm fine with reusing the collection-utils implementation for simplicity. Just release the PR on npm and I'll update this PR to import it from there instead.

@schani Updated. Please take another look.

Done. Nothing to squahs, there's only one commit :)

Thank you!


release tag

would you mind awfully tagging a release. it helps for package building? - thanks
https://help.github.com/categories/releases/

Surprisingly- I've promised myself to get into the habit of tagging at least. I would love to try and retrospectively tag earlier versions too, too, but that could be tricky!
https://github.com/pimoroni/unicorn-hat/tree/v2.0.7
I may be crazy, but I've never been able to find the "Releases" tab or any way to turn it on in GitHub. It would be nice to set up releases and add the pip packages.


Perhaps make an example using error handlers

https://github.com/enonic-playground/demo-lib-static-page/blob/main/src/main/resources/error/error.ts


Unify Therapy Settings copy from the text from IFU-24

This consolidates the Therapy Settings title and descriptiveText into one place, sourced from IFU-24
Note: I moved CorrectionRangeOverrides.swift and TherapySetting.swift into LoopKit, because they seemed generally useful.  I don't feel strongly about that, though, so if you disagree I can move them back.

LocalizedString("Correction range is the glucose value (or range of values) that you want Tidepool Loop to aim for in adjusting your basal insulin."...

This may read more accurately with "Correction range is the glucose value (or range of values) that you want Tidepool Loop to aim for in adjusting your insulin delivery." because Tidepool loop's correction range also affects bolus recommendations. Also helps future proof the description a bit if Tidepool adopts an automated bolus strategy in the future. If you wanted to consider open loop users then it may be even better to use ..."in adjusting your insulin delivery and delivery recommendations."

@Kdisimone Good suggestions!  I will talk to folks internally here to discuss them, and follow up with a PR containing the result of that discussion.  I will be sure to ping you on that PR.  Again, thanks for the suggestions!


Make deserialization stateless w.r.t. instances resolver

Currently the instances resolver used in serialization would "remember" all nodes that it deserializes. I think that is incorrect and it should remember them only during the serialization but it should not affect future deserializations.
Right now to avoid this problem I was reinstatiating the JsonSerialization all the time, and performing a complex setup.

Thank you @enikao and @dslmeinte for the review!


Mousewheel control

Check that this is really a bug

[X] I confirm

Reproduction link
https://codesandbox.io/p/sandbox/2i6lzk?file=%2Findex.html
Bug description
When I use the Mouse wheel control in the vertical slider  it works fine with the mouse wheel but when I want to change slides with my touchpad with two fingers to scroll down it immediately changes 2 or 3 sometimes 4 slides altogether I don't know why but it is so weird
Expected Behavior
it should change one slide when you want to change slides with two fingers using your touch pad .
Actual Behavior
it has a weird behavior it changes two or three sometimes 4 slides together
Swiper version
v9.0.5
Platform/Target and Browser Versions
every browsers
Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a Swiper issue and not a framework-specific issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

this is how touchpad works, was discussed here numerous times


Support patching nixpkgs

Motivation for this change
Sometimes you want to track a specific branch of nixpkgs (like nixpkgs-unstable or some release branch) but you would like to apply some unmerged pull requests or some other patches to that revision.
Note that overlays are not always sufficient in this case because they don't work for NixOS modules and you're forced to duplicate code which already exists in some commit.
In this case you could fork nixpkgs, create a branch based on your desired upstream branch and cherry-pick the commits you need on top of that branch. Then everytime you need to upgrade nixpkgs you rebase your branch on the latest upstream branch that you're tracking. This process works but is a
bit involved and somewhat untransparent.
This PR implements support in nixpkgs for a simpler and more transparent mechanism to apply some patches to an existing revision. First you fetch your desired revision of nixpkgs like for example:
  let
    nixpkgs =
      builtins.fetchTarball {
	url = "https://github.com/NixOS/nixpkgs/archive/86d58407a6bb8ef2e1a58ab50318b149ffd4feda.tar.gz";
	sha256 = "0a2lkvacn78nza9hlmdx9znp1my3c3jf3xyhk9ydw6lxa348b7sl";
      };

Then you import that revision and apply it to a list of patches, for example:
    patchedPkgs = import nixpkgs {
      patches = pkgs : [
	# https://github.com/NixOS/nixpkgs/pull/59950
	(pkgs.fetchpatch {
	  url = https://github.com/NixOS/nixpkgs/commit/1f770d20550a413e508e081ddc08464e9d08ba3d.patch;
	  sha256 = "1nlzx171y3r3jbk0qhvnl711kmdk57jlq4na8f8bs8wz2pbffymr";
	})
      ];
    };
  in patchedPkgs...

Note that patches should be a function from a nixpkgs set pkgs to a list of patch files that can be applied to a nixpkgs directory tree. The pkgs set should mainly be used to get the fetchpatch function from. Note that pkgs is a nixpkgs set for the specified localSystem but without overlays and crossOverlays defined.
Overlays are applied after patching which means you can have overlays which can depend on the patched content.
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on Nix community. There might be relevant details there:
https://discourse.nixos.org/t/support-patching-nixpkgs/2737/1

Some design decisions I took:

I perform the patching as early as possible, right after the Nix version check. So the order of imports is:

./default.nix
./patched.nix
./pkgs/top-level/impure.nix
./pkgs/top-level/default.nix

I think this makes sense because now we can use this patch mechanism to patch the later phases.

I choose to implement this in a separate file ./patched.nix instead of in ./default.nix to separate concerns. However, I also don't mind merging this logic in ./default.nix because then we end up with a single .nix again in the root of nixpkgs which might be nice.

The bootstrapPkgs set, which the user can use to get the fetchpatch function from and which is used to perform the actual patching (i.e.bootstrapPkgs.stdenvNoCC.mkDerivation {...}), is a nixpkgs set configured for the specified localSystem. I think it makes sense to perform all work, including patching, on a builder for the specified localSystem. Although I'm not completely sure about this. Maybe preferLocalBuild = true might even be better here. I appreciate comments on this!

bootstrapPkgs has no overlays defined. This makes it possible to depend overlays on the patched content which I think is way more common than the other way around.

I am using a similar scheme, with nixos-stable as bootstrapPkgs (it was release-17.09 until recent upgrade to 18.09)
let
  bootstrap-pkgs = import (
    # builtins.fetchTarball https://github.com/NixOS/nixpkgs/archive/release-18.09.tar.gz
    ./local-copy-of-release-18.09-for-happy-work-offline
  ) {
    overlays = [
      (self: super: {
        # other `import nixpkgs` have overlay with `inherit bootstrap-pkgs`, so `bootstrap-pkgs` is available everywhere
        bootstrap-pkgs = self;
      })
    ];
    config = { allowUnfree = true;  };
    localSystem = { system = builtins.currentSystem; };
  };
in

The idea is bootstrap-pkgs is used for

downloading and patching nixpkgs.
for the programs which run in buildins.exec so they won't be rebuilt on the evaluation phase when nixpkgs upgrades (there are mostly programs like git --describe making version number for the ssh banner)

As bootstrap-pkgs is less tied to the first task of downloading and pathching nixpkgs, the patching is performed by a generic patching function which is not specialized for patching nixpkgs and can patch any derivation (yes, it is suboptimal and does cp twice (the first time on the unpackPhase), it was a quick hack):
let
  fix = { src
        , name      ? "${src.name}-fix"
        , patches   ? []
        , postPatch ? ""
        }: stdenv.mkDerivation {
    preferLocalBuild = true;
    allowSubstitutes = false;
    inherit name src patches postPatch;
    installPhase = "mkdir $out ; cp -R . $out/";
    dontFixup = true;
    dontStrip = true;
  };
in

The usage is like:
let
  legacy-20190131 = fix {
    name = "legacy-20190131";
    src = fetchFromGitHub {
      owner = "nixos";
      repo = "nixpkgs";
      rev  = "6ad1271a4c285500268f3315f3f519ff6bedb8e5";
      sha256 = "0qnicpc0hx56nw2xxa9l7h7f3rfb63k0zpzch01k433l6hmxvqvz";
    };
    patches = common-patches ++ [
      (fetchurl { name   = "perl-geoip2"; # merged
                  url    = "https://github.com/NixOS/nixpkgs/pull/55229.patch";
                  sha256 = "1jibalwybx35xz2z2rdhy7v03xrjlspwc811jyz5sllzbh90wcjw"; })
      (fetchurl { name   = "network-scripted-dont-resolvconf"; # merged
                  url    = "https://github.com/NixOS/nixpkgs/pull/56682.patch";
                  sha256 = "1dkf7fwzwp412ihsrwazbbav244649rdn3viaf0ng7kl4bcsdzny"; })
    ];
    postPatch = common-postPatch + ''
      # https://github.com/NixOS/nixpkgs/pull/53693#discussion_r249917633 (merged)
      substituteInPlace pkgs/development/libraries/gpgme/default.nix \
        --replace "https://files.gnupg.net/file/data/fehgbjmataj5tc2pnfhj/PHID-FILE-aqck6l4elhw53tjanrie/file" \
                  "https://dev.gnupg.org/rM66376f3e206a1aa791d712fb8577bb3490268f60?diff=1"
    '';
  };

  legacy-20190131-without-meltdown-patches = fix-no-meltdown { src = legacy-20190131; };
...
in

so there is a kind of a library of private "channels" each of them can be assigned to a nixops slave or a test-driver.

@basvandijk Nice to see you standardizing this patching idea you presented at NixCon a while back. I've been happily using that method on my job's nixops nixpkgs repo. I think it is great for encouraging upstreaming of contributions, because the patch is in the same format as whatever should eventually be applied to nixpkgs.
One issue we ran into is that the default fetchpatch implementation strips away information that is necessary for renaming files. ( https://github.com/NixOS/nixpkgs/issues/32084 ) Is that a problem with this implementation?
Our workaround is to use fetchurl on the patches that need to rename files, but I guess that opens us up to some instability that fetchpatch is trying to avoid.

One issue we ran into is that the default fetchpatch implementation strips away information that is necessary for renaming files. ( #32084 ) Is that a problem with this implementation?

@ryantm thanks for pointing me to #32084. Fortunately, this implementation lets the user decide how to fetch patches. So users deciding to use fetchpatch could potentially suffer from #32084. In that case they could fall back to using fetchurl or include patches literally in their repos.

I liked @volth idea of having a separate fix function which applies a list of patches to a source directory. So I added this function to trivaial-builders.nix but gave it the more descriptive name: applyPatches.
I also decided to move the patching code to ./default.nix instead of having it in a separate file. I believe it's a bit cleaner this way.

I'm :-1: on this. It seems very ad hoc and hacky to make Nixpkgs rewrite its own source tree. That's the job of the version management tool (e.g. Git), which can do a much better job of managing sources and patches.
Maybe flakes could provide this functionality (e.g. by having a flake reference like github:NixOS/nixpkgs?patch=./foo.patch) but I'm convinced it's a good idea.

I would like to be able to declare a base version of nixpkgs and a list of patches. Maybe we need to make a separate community tool that makes it easy to do that.
Reasons I like using something like @basvandijk's proposal:

Easy to downstream changes: You can pick patches from unstable to apply to a stable version.
Easy to upstream changes: Changes you make are done as patches (e.g. instead of overrides), so you can easily convert them into a pull request.
You don't have to maintain an internal fork of nixpkgs.

@ryantm I feel that that tool already exists, namely Git. I typically have a branch like local-19.03 containing local / cherry-picked patches that gets rebased on top of nixos-channels/nixos-19.03 periodically. It might be nice if the rebasing were done automatically, though.

@edolstra maintaining the local-19.03 branch you are describing doesn't sound like what I mean when I say "declare". I would like a declarative description of a publicly available version of nixpkgs and a list of publicly available patches. That way I can share this declarative description with collaborators who can each arrive at the same copy of nixpkgs without sharing it directly.
I use this at work to keep the nixpkgs we use for NixOps consistent among all my co-workers.
You may be right that Git is the tool we need to do this! I'll try to look into it some.

The problem with maintaining such a list of patches is that you have to resolve any conflicts manually, e.g. if you try to update the base Nixpkgs version. Whereas with git rebase, you get a more-or-less friendly way to resolve conflicts.

The patching of nixpkgs (or, widely, producing nixpkgs tree using Nix-expressions executed using some "bootstrap" nixpkgs) is very useful for nixops-deployment where different machines need different nixpkgs (KVM-hosts which were not rebooted for years get release-17.03, database servers get kernels without Meltdown patches and older Intel microcode for performance, the laptop get the most recent unstable with all my PRs, etc).
With Git, it would require many branches to support and IFD with bootstrap nixpkgs anyway
for import (bootstrapPkgs.fetchGitLocal { ...}
So, Git is not a alternative solution for the whole thing, it is just an alternative storage for the patches

I do see the usefulness of that, but I think relying on IFD is a bad idea. It would be better to extend builtins.fetchGit / builtins.fetchTarball with a patches argument, e.g.
builtins.fetchTarball {
  url = https://github.com/NixOS/nixpkgs-channels/archive/nixos-19.03.tar.gz;
  patches = [ ./meltdown.patch ]
}

since this does not rely on IFD.

builtins.fetchTarball {
  url = https://github.com/NixOS/nixpkgs-channels/archive/nixos-19.03.tar.gz;
  patches = [ ./meltdown.patch ]
}

since this does not rely on IFD.

But ... Isn't IFD the only meaningful thing what to do with the fetched/patched nixpkgs?
let
  patched-nixpkgs = import (builtins.fetchTarball {
    url = https://github.com/NixOS/nixpkgs-channels/archive/nixos-19.03.tar.gz;
    patches = [ ./meltdown.patch ];
  });
in
  ....

That's not IFD because builtins.fetchTarball is not a derivation :-)

While I understand the need for this feature, as I my-self tried to solved it in the past.
Import-From-Derivation is a banned pattern in Nixpkgs repository.

Then everytime you need to upgrade nixpkgs you rebase your branch on the latest upstream branch that you're tracking. This process works but is a bit involved and somewhat untransparent.

@P-E-Meunier could this be a case where Pijul could help? As a way to add/substract a set of changes on top of a frequently updated repository.

That is indeed the main use case for Pijul. Don't use it for Nixpkgs before the next version, the repository will be huge and slow. However, if all goes as planned, the next version will be competitive with Git on these two things.

I want to do ad hoc patching a lot so I really like the idea here regardless of if it should be used in nixpkgs. I should have found this PR earlier. :)

The solution: https://github.com/NixOS/nix/issues/4433.

The solution: https://github.com/NixOS/nix/issues/4433.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/how-to-try-a-pr/15410/6

This is possible now, see this comment for a example https://github.com/NixOS/nixpkgs/pull/142273#issuecomment-948225922


Improved instructions on how to install GHC

Includes clarification on GHC version to use

This PR is in response to https://github.com/input-output-hk/cardano-node/pull/3118 and supersedes that PR.

bors merge


Update MD file on new branch 2017-11-19_09-27-34

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/content1.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.


Fix options merging

Closes #3

Seems like the fix is done in build file instead of in src/countDown.js

In fact there was no changes in js. Changes in minified file were caused by update of dependencies in build process.
But unfortunately I can't remember what was the problem. Did you find some error? Because reported problem is probably fixed, at least what I tried.

The problem (#3) still occurs, you can't set date using an Object
This doesn't work:
date: new Date(1553468400000),
it works with .getTime()
The problem is here:
https://github.com/Dazix/SimpleCountDown/blob/master/src/countDown.js#L332
both are object


[HUDI-1206]Remove unused variable in Compactor

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request
Remove unused variable in Compactor
JavaSparkContext jssc in Compactor class was not used anywhere, we can remove it.
Brief change log
(for example:)

Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

@yanghua please take a look when free


Fix for issue #39: fix unit test naming scheme

The correct name pattern is *_test.cc, not *_unittest.cc

File naming convention is here:
https://google.github.io/styleguide/cppguide.html#File_Names


Support for dbt 1.5

dbt v1.5 has been released. Placeholder issue to update integration tests to run against the new version and fix any issues.
Looks like model contracts tries to replicate what dry_run.check_columns does but doesn't work for all incremental configurations (Only append_new_columns?) So we will keep this feature in the dry runner for now.

dbt-dry-run will currently raise an ImportError when run with v1.5:
Traceback (most recent call last):
  File "/project/.meltano/utilities/dbt-dry-run/venv/bin/dbt-dry-run", line 5, in <module>
    from dbt_dry_run.__main__ import main
  File "/project/.meltano/utilities/dbt-dry-run/venv/lib/python3.8/site-packages/dbt_dry_run/__main__.py", line 1, in <module>
    from dbt_dry_run.cli import app
  File "/project/.meltano/utilities/dbt-dry-run/venv/lib/python3.8/site-packages/dbt_dry_run/cli.py", line 5, in <module>
    from dbt.flags import DEFAULT_PROFILES_DIR
ImportError: cannot import name 'DEFAULT_PROFILES_DIR' from 'dbt.flags' (/project/.meltano/utilities/dbt-dry-run/venv/lib/python3.8/site-packages/dbt/flags.py)


Add a MAUI target

It is the next evolution of Xamarin.Forms targetting all of .NET. https://github.com/dotnet/maui
We should investigate before the .NET 6 release on how to support it.

Yes, absolutely.
For the time being, I don't think we can do anything about it. MAUI is currently a clone of Xamarin.Forms, and I'm guessing a lot will change until the targeted release of November 2021.
Regarding the "single project - several platforms", I'm hoping the F# tooling in the various IDEs will follow the C# tooling because that will be the major blocking point for a Fabulous.MAUI.
Aside from that, Fabulous is mostly reading to accept a new framework like this one.

An interesting link showing what MAUI could be: https://github.com/dotnet/maui/issues/28

Excited to see how this could influence Fabulous!!
Maybe Fabulous could shift away from having to just clone wrapping forms elements? Go a bit more in the direction of Comet and having it's own syntax.

@PureWeen It will be interesting to see what this restructuring will enable!
Adapting MVVM-focused controls to the MVU style is head-scratching at times...
Comet seems to share a lot of similarities with Fabulous, except that Fabulous don't provide its own abstraction over what a control is. Comet is a lot like Xamarin.Forms on this point.
Fabulous is more akin to a MVU-enabler for existing UI frameworks.
So, depending on the actual implementation of MAUI, I think Fabulous will still need to clone wrap the various controls so we can provide our own syntax and diffing logic, while not having to reimplement all the platform renderers.

Intersting, it seems that peoples are pretty sure that fabulous will implement MAUI. https://github.com/dotnet/maui/discussions/115#discussioncomment-655646

Have any decisions been made on whether or not we are getting MAUI support in Fabulous?

@JustinWick Fabulous will support MAUI. You can see the progress here https://github.com/TimLariviere/Fabulous-new
At the same time, we're completely re-architecturing the internals of Fabulous to enable a bunch of new features (better View API, better performance and many other).
Once we figure out everything, I hope to make a compatibility layer to more easily migrate from Fabulous v1 to v2.
Anyway we're still at a very early stage.
We should be close enough to a stable release when MAUI goes live in Q2 2022
If you want some insights on Fabulous v2:

https://github.com/TimLariviere/Fabulous-new/blob/main/docs/goals-of-v2.md
https://github.com/fsprojects/Fabulous/issues/738

@TimLariviere That is fantastic news!

@TimLariviere .NET MAUI RC2 is released now ; How much work would it take to plug Faboulus on it ?
I admit I don't realize all that this implies !

@JbmOnGitHub Plugging a new framework to Fabulous is pretty straightforward. It's mainly about writing wrappers for the new framework to be usable in the view function. This is time consuming but fairly easy to do.
With MAUI though, there is a difficulty to solve first.
Unlike XF, MAUI gives us interfaces (IButton, ILabel, IStackLayout) so we need to figure out how to implement those to work with Fabulous internals (widgets & attributes).
Once it's done, we will be able to start adding wrappers to all controls and we will release preview versions of Fabulous.Maui.

@TimLariviere The FSharp.Mobile.Templates Readme lists MAUI already as a target. Does this indicate that one can build Fabulous apps with MAUI already, or has it only been added for future use?

@ChristophSchmidpeter You can't use Fabulous with Maui yet.
Support for it is underway in #919, but to be honest there are many issues with Maui right now so it is making it difficult for us.
Regarding the error you're seeing, it has been reported here: https://github.com/fabulousfx/FSharp.Mobile.Templates/issues/21

@TimLariviere Thank you for the info and great to hear that support is already underway :)

Maui is now supported. Please see https://github.com/fabulous-dev/Fabulous.MauiControls


feat(trainer-guide): add class diagram to help trainers explain

Co-authored-by: Florian Gomas

Don't you wanna link the diagram to the trainer's guide ?


Support for hammer.js v2.0.4

[Change] Added support for hammer.js v2.0.4.
[Fixed] Extra commas caused some IE versions to stop code execution.
[Fixed] cropFrame was being left-over when cropbox was removed.

Great work! Thatk you.

Hi, I'd like to note that unfortunately hammer.js v1 will not work anymore (different events), so that might be something to consider. Although, backwards support could be added pretty easily.


Reasoning for purple?

It says here the full reasoning for the purple color would be on GitHub but I can't find it.

As per my understanding purple colour is depicted once you select the Daily layer from the Layer widget on the map. if u turn off the daily layer or change the opacity from the options it will disappear. hope it helps

I'm not sure of the justification for the purple colour - it may occur because of the min and max parameters for the different colour channels. The range is set differently for daily imagery.
https://github.com/bellingcat/sar-interference-tracker/blob/636514257b91afecb67e945705177177aba99ed4/RIT.js#L208

Thank you for your patience in getting an answer! I've spoken to Ollie who developed the tracker, and have a bit more of an explanation (I'll update the README soon):
The monthly and yearly views display composites of multiple SAR images. These composites are made up of multiple SAR images, taken from Sentinel in both ascending and descending parts of its orbit. The red and blue channels are used to represent the SAR images taken in the ascending and descending parts of the orbit, respectively. When the satellite is ascending, the interference causes a red smear at one angle. When the satellite is descending, a blue smear is produced at a different angle. This channel mapping is the cause of the red and blue "x marks the spot" for points of interference.
That mapping is only possible for images that are a composite of multiple passes and you don't get that for the shorter time window of the daily imagery. Instead, the default colour scheme for the daily imagery uses the red and blue channels to represent the returns of different polarizations (VV & VH) of the Sentinal radar. The green channel is used to represent the look angle of the satellite, and so is roughly constant over each image (and at a fairly low level). This is why the Daily imagery looks very different and appears purple.
The choice of colour channel mapping is quite arbitrary, so there is nothing special about the colour purple, that's just what the default mapping results in.
If you are interested, you can see the mapping for the composite images (to RGB channels) being done here (note that vhA_ refers to ascending data and vhD_ refers to descending data):
https://github.com/bellingcat/sar-interference-tracker/blob/636514257b91afecb67e945705177177aba99ed4/RIT.js#L192-L198


Pipeline to compute angular correlation function

Implements the pipeline to compute the angular correlation for a catalog using the natural estimator. Closes #4 and addresses part of #6 (we are just missing the redshift / projected correlation functions).

[X] My PR includes a link to the issue that I am addressing

Code Quality

[X] I have read the Contribution Guide
[X] My code follows the code style of this project
[X] My code builds (or compiles) cleanly without any errors or warnings
[X] My code contains relevant comments and necessary documentation

Codecov Report
Attention: Patch coverage is 85.34483% with 17 lines in your changes missing coverage. Please review.
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Files
Coverage Δ

src/corrgi/alignment.py
100.00% <100.00%> (ø)

src/corrgi/estimators.py
100.00% <100.00%> (ø)

src/corrgi/corrgi.py
91.66% <91.66%> (ø)

src/corrgi/utils.py
88.88% <88.88%> (ø)

src/corrgi/parameters.py
78.12% <78.12%> (ø)

src/corrgi/dask.py
85.45% <85.45%> (ø)


[bug]  sql SELECT via HTTP GET returns always only 20 results

Hi,
thank you for this great DB !!!
sql SELECT via HTTP GET (query) always returns 20 results (even if LIMIT is set ie. 200)
SELECT via HTTP POST (command) and Binary sql select both work fine.
I've tried this on 2.0-M3 and  2.0-rc1

Note that using LIMIT in the SQL part of the URL does nothing, you have to use the / in the end of URL. Where did you specify LIMIT?
This is slightly confusing though. Probably Orient should apply both (if any), the SQL one and then the URL one, like a subquery.

well, i have tried many variations
ie:
http://mylocal.local:2480/query/mydb/sql/select from MyClass/limit 200
response:
java.lang.NumberFormatException: For input string: "limit"
how is the query supposed to be formatted?

Syntax: http://:[]/query///[/][/]
http://mylocal.local:2480/query/mydb/sql/select from MyClass/200
for more info, see:
http://www.orientechnologies.com/docs/last/orientdb.wiki/OrientDB-REST.html#query


add a wmi_exporter node-overview console template

@brian-brazil
This is so the next person who wants a console for Windows nodes doesn't have to write it themself.
Despite #3099, I am unable to find anything on mailing list suggesting that consoles are deprecated, so I believe this is worthwhile. https://groups.google.com/forum/?fromgroups#!searchin/prometheus-developers/console|sort:date/prometheus-developers/VzmcWJKRQxY/mUVBSzVCGQAJ is an older conversation, but I see nothing more recent on the subject.
If the prometheus team does not wish to maintain console templates, but will not be removing them, perhaps the docs could instead point to a separate repo to avoid duplication of effort for those who want to use them.

This should go in the wmi-exporter repository as the decision has already been made that this repository can't contain templates for all possible exporters.

Thanks @simonpasquier, I am closing this and opening a PR over there.


helmUpdate*Dependecies fails with "Error: no cached repository for helm-manager"

Gradle: 7.2
Plugin version: 1.6.1
Helm version: 3.7.0
I'm trying to package a basic chart that depends on bitnami postgresql 10.13.1, this seems to cause the plugin to fail.
Stacktrace:
Error: no cached repository for helm-manager-54d2620bbb6f1bb3f35d4c7f945bfa25077949488dcbb0a4d01c90f2c35baa59 found. (try 'helm repo update'): open C:\Users\jimne\Desktop\My Stuff\k8s-learning\.gradle\helm\cache\helm\repository\helm-manager-54d2620bbb6f1bb3f35d4c7f945bfa25077949488dcbb0a4d01c90f2c35baa59-index.yaml: The system cannot find the path specified.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':helmUpdateMainChartDependencies'.
> A failure occurred while executing org.unbrokendome.gradle.plugins.helm.command.HelmExecWorkAction
   > Process 'command 'helm'' finished with non-zero exit value 1

helm update dependencies and helm package . in the source folder works fine.

Looks like it was caused by not explicitly specifying:
repositories {
    bitnami()
}

Not sure if that's intended or not.

Yes, that's intended -- the plugin won't register any repositories by default so you'll have to add them in your build script.
By default the Helm plugin passes a different cache and config path to helm, in order to keep the Gradle builds as independent as possible from the state of a local Helm installation. That's why calling helm in your source folder works in this case: most likely you had the repository already registered with helm repo add.
You can change this behavior so that Gradle would use the same paths as your local Helm installation by setting the Gradle properties helm.xdgDataHome, helm.xdgCacheHome and helm.xdgConfigHome (best put into ~/.gradle/gradle.properties and not in your project because they're somewhat specific to your local environment).


Node version?

Which node version i need to use?
I have v23.4.0 installed, but i receive errors:
at /root/ComfyUI/node_modules/node-telegram-bot-api/src/telegramPolling.js:106:17
at tryCatcher (/root/ComfyUI/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:547:31)
at Promise._settlePromise (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:604:18)
at Promise._settlePromise0 (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:649:10)
at Promise._settlePromises (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:729:18)
at _drainQueueStep (/root/ComfyUI/node_modules/bluebird/js/release/async.js:93:12)
at _drainQueue (/root/ComfyUI/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/root/ComfyUI/node_modules/bluebird/js/release/async.js:102:5)
at Async.drainQueues [as _onImmediate] (/root/ComfyUI/node_modules/bluebird/js/release/async.js:15:14)
at process.processImmediate (node:internal/timers:511:21)
From: ReinEthernal Command: /s 240 0 start Type: text
Error reading file: TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
at Object.join (node:path:1261:7)
at readJSONFile (/root/ComfyUI/custom_nodes/ComfyUI-TG/nodejs/project/app.js:161:24)
at setCommand (/root/ComfyUI/custom_nodes/ComfyUI-TG/nodejs/project/app.js:431:35)
at TelegramBot. (/root/ComfyUI/custom_nodes/ComfyUI-TG/nodejs/project/app.js:553:4)
at TelegramBot.emit (/root/ComfyUI/node_modules/eventemitter3/index.js:182:35)
at TelegramBot.processUpdate (/root/ComfyUI/node_modules/node-telegram-bot-api/src/telegram.js:709:14)
at /root/ComfyUI/node_modules/node-telegram-bot-api/src/telegramPolling.js:110:22
at Array.forEach ()
at /root/ComfyUI/node_modules/node-telegram-bot-api/src/telegramPolling.js:106:17
at tryCatcher (/root/ComfyUI/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:547:31)
at Promise._settlePromise (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:604:18)
at Promise._settlePromise0 (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:649:10)
at Promise._settlePromises (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:729:18)
at _drainQueueStep (/root/ComfyUI/node_modules/bluebird/js/release/async.js:93:12)
at _drainQueue (/root/ComfyUI/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/root/ComfyUI/node_modules/bluebird/js/release/async.js:102:5)
at Async.drainQueues [as _onImmediate] (/root/ComfyUI/node_modules/bluebird/js/release/async.js:15:14)
at process.processImmediate (node:internal/timers:511:21) {
code: 'ERR_INVALID_ARG_TYPE'
}
TypeError: Cannot convert undefined or null to object
at Function.keys ()
at setCommand (/root/ComfyUI/custom_nodes/ComfyUI-TG/nodejs/project/app.js:445:32)
at TelegramBot. (/root/ComfyUI/custom_nodes/ComfyUI-TG/nodejs/project/app.js:553:4)
at TelegramBot.emit (/root/ComfyUI/node_modules/eventemitter3/index.js:182:35)
at TelegramBot.processUpdate (/root/ComfyUI/node_modules/node-telegram-bot-api/src/telegram.js:709:14)
at /root/ComfyUI/node_modules/node-telegram-bot-api/src/telegramPolling.js:110:22
at Array.forEach ()
at /root/ComfyUI/node_modules/node-telegram-bot-api/src/telegramPolling.js:106:17
at tryCatcher (/root/ComfyUI/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:547:31)
at Promise._settlePromise (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:604:18)
at Promise._settlePromise0 (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:649:10)
at Promise._settlePromises (/root/ComfyUI/node_modules/bluebird/js/release/promise.js:729:18)
at _drainQueueStep (/root/ComfyUI/node_modules/bluebird/js/release/async.js:93:12)
at _drainQueue (/root/ComfyUI/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/root/ComfyUI/node_modules/bluebird/js/release/async.js:102:5)
at Async.drainQueues [as _onImmediate] (/root/ComfyUI/node_modules/bluebird/js/release/async.js:15:14)
at process.processImmediate (node:internal/timers:511:21)
^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^Z
[1]+  Stopped                 python3 main.py --listen <IP_ADDRESS>
(venv) root@sdwebui:~/ComfyUI# node -v
v23.4.0

How this error occurred,
what did you do exactly,
Is this the first time; just after install ?
Join My discord so we can solve it in call if possible.
https://discord.com/invite/UyGkJycvyW

Thank you! Just joined)

The error was not that I thought I had installed the wrong version of node, but that I was running it on a remote lxc container instead of on the local one. To access the download interface I had to go to the container address (i.e. remote-host-ip:4001) and the menu opened. After that it was only necessary to follow further instructions.

Thank you very much @daxcay !