fix: rebase error message during conflicts

Description
Updated the error message for rebase during the conflicts state
Fixes https://github.com/appsmithorg/appsmith/issues/24391
Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Chore (housekeeping or task changes that don't impact user perception)
This change requires a documentation update

Testing

[ ] Manual
[ ] Jest
[ ] Cypress

Test Plan
Issues raised during DP testing
Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test

/build-deploy-preview

/build-deploy-preview

/build-deploy-preview

/ok-to-test

/ok-to-test

/build-deploy-preview

/ok-to-test

/ok-to-test sha=4682788

/ok-to-test

/ok-to-test

/ok-to-test sha=4379b0d


Fix pull request #2403 - Hide empty tech nodes

This closes #2403, closes  #2406.
@jyanjyanjyan: let me know if you have more changes to the netKAN file. Btw, should community tech tree be a dependency for this mod instead of a recommendation? Will it work without CCT?

As the mod's thread and KS page both indicate CTT is a recommendation and not a dependency, I think the relationship is correctly set up in this .netkan.
Merging with my thanks.


Relabel API and GUI and improve definitions

Description of the issue
API and GUI are abbreviations and thus not a proper labels
Ideas of solution
API

Relabel API to application programming interface
Add API as alternative label
Improve definition: An ~API (Application Programming interface)~ application programming interface (API) is a software interface allowing two ~S~software applications to communicate with each other.

GUI

Relabel GUI to graphical user interface
Add GUI as alternative label
Improve definition: A ~GUI (Graphical user interface)~ graphical user interface (GUI) is a software interface allowing users to communicate with a software application through a graphical window.

Workflow checklist

[ ] I discussed the issue with someone else than me before working on a solution
[ ] I already read the latest version of the workflow for this repository
[ ] The goal of this ontology is clear to me

I am aware that

[ ] every entry in the ontology should have a definition
[ ] classes should arise from concepts rather than from words

I am fine with the proposals.

Okay, I'll implement.


step 8 failing with Spring Boot 2.1.3

Hi @in28minutes, I've problems trying to running the app with the step mentioned in the video course (step 8), let me to share you the error trace: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'userResource': Unsatisfied dependency expressed through field 'service'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.in28minute.user.UserDaoService' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.in28minute.user.UserDaoService' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
The 'UserResource' class has the @RestController annotation. And the 'UserDaoService' the @Component annotation. So I don't know what's happening, I'll be taking a look to continue with the course.
I really appreciate any help you can provide.
Regards,
Zuriel

Hi @in28minutes I was wrong because I've created another package for my UserDaoService class. So I just need to set @ComponentScan annotation.


Question: Is there a way to instantiate an extern like in the example code without giving _ as a type parameter?

@mbudiu-vmw @jnfoster @ChrisDodd My apologies for pinging you directly on this, but I suspect you are the ones most likely to know the relevant parts of the P4_16 language spec and p4c implementation related to this.  I am marking this as a question because my guess is that the answer for at least some time to come is "that is probably the least hacky way to do what you want for now", and if so, I will simply close this as an answered question issue.
See the definition of the extern object named ExactMatchValueLookupTable in the attached program, and the instantiation of an instance of it named lut1.
If P4_16 had a fancier type system (or maybe it does and I do not know how to express it), I would like to only have type parameters K and V, and then the second parameter of this constructor signature:
ExactMatchValueLookupTable(int size, E const_entries, V default_value);

would be the type "a list of (K,V) pairs", instead of E.
As it is written now, I can compile this with the latest open source p4c, but the only way I have found to avoid syntax errors so far is to declare the extern object with the type parameter E, and then provide the type parameter _ for E when I instantiate lut1.
I am personally OK with doing this, but I agree it feels a little like a workaround.  Dan Talayco was curious if we can do better, either with today's language specification, or with any enhancements that we think might be coming to the P4_16 specification some time in the next few years.
v1model_valuelut_with_const_entries1.p4.txt

One view of the problem is that P4_16 does not have syntax for writing the list type. (The IR node Type_List is used internally in the compiler, but there is no way to get the parser to produce that type from the text of a program -- it's only introduced by the compiler during type checking.)
The language specification says that list expressions have tuple types. So in situations where your code only deals with a single, concrete list (to be clear -- not your situation!), you know the length of the list and can write down a type for it. For example, if you knew the entries would always be a list of length 3, you could write:
tuple<tuple<K, V>, tuple<K, V>, tuple<K, V>>

for its type.
When you write the _ in the declaration of your extern, you're allowing the compiler to infer any type, including all tuple types comprising Ks and Vs (but also all other types -- so this is dangerous!)
A proposed solution would be to add list<T> as a type. Then you could declare the extern as
extern ExactMatchValueLookupTable<K, V, E> {
  ...
    ExactMatchValueLookupTable(int size, list<tuple<K,V>> const_entries, V default_value);
}

One minor detail is that we'd probably want to change the type computed for list expressions. Right now a list gives a "flat" tuple type:
        tuple<bit<8>, bit<8>, bit<8>> t = { 0, 1, 2};

but really we would want the type to reflect the structure of the list. So a value of type
list<E>

should be coerceable to
tuple<E, list<E>>

unless it is empty, in which case it should be coerceable to:
tuple<>

So I'd argue the code above should look more like this:
        tuple<bit<8>, list<bit<8>>> t = { 0, 1, 2};

or even
        tuple<bit<8>, tuple<bit<8>, tuple<bit<8>, tuple<>>>> t = { 0, 1, 2 };

Yes, we do not have list types, so there is no way to declare an object whose value is a list of unknown size of identically-typed values.
Even the internal list type has a fixed length, it does not unify with an arbitrary-length list.
A question is whether we could design the syntax and type system to be flexible enough to allow the standard P4 tables to be declared as extern objects by an architecture. You are moving in that direction.

In the interest of tidying up the set of active issues on the P4 specification repository, I'm marking this as "stalled" and closing it. Of course, we can always re-open it in the future if there is interest in resurrecting it.


OpenIGTLink header version

Hi all,
Running into some problems with Ole and Geir here at project week. The handshaking process to determine the header version when using IO is something we seem to have overlooked.
The intended behaviour in Plus is that it uses the highest header version found in the messages it receives. But it doesn't work. Different parts of Plus seem to be modifying different instances of the class PlusIgtlClientInfo which results in always using the default header version. Even if it did work, this behaviour is problematic. When a client connects, the server starts sending messages right away, but will only start sending messages with the header version required by the client once the first client message reaches the server.
We need a handshaking mechanism to agree on a common header version between the client and the server from the start. The question is whether the handshaking should be implemented at the level of OpenIGTLink or in IO. I, Ole and Geir lean more towards OpenIGTLink.
What do you think?

Andras and I talked about this a while ago. Major points are:

OpenIGTLink is a very lightweight protocol, introduction of v2 header made things more complicated
Backwards compatibility is very important
Handshake mechanism would not be backwards compatible
Application level behaviour is the least impactful to others

So, Plus is supposed to keep track of the highest header version ever received from a client, and respond with that header version. If it's not doing that, it's a bug!
Our vision was that clients would send v1, v2, v3, ...vX STATUS messages until it didn't receive a reply, and thus know the highest capability of the server.
It is asynchronous handshaking at the application level. I am open to revisiting the discussion.
Tagging @lassoan

Yes, there seems to be a bug in PLUS, never sending back v2 headers. I also tried to set ClientHeaderVersion in the PLUS config file, but that won't work either. The only way I find to make PLUS give med header v2 messages is to hardcode this in the PlusIgtlClientInfo constructor: ClientHeaderVersion(IGTL_HEADER_VERSION_2). We cannot seem to find where the bug is located in PLUS, but you may have more success as you are more familiar with the code base.
The handshaking could be made to be kind of backwards compatible. Let's say this is implemented in OpenIGTLink v4. If the other end don't answer to the handshaking, you know it uses OpenIGTLink < 4 (This can default to v1).
If it is out of the question to implement this in OpenIGTLinkIO, it could of course be implemented in OpenIGTLinkIO in the way you describe, but I think we first should consider doing it in OpenIGTLink. Another option is to implement this in OpenIGTLinkIO first, and then move the functionality to OpenIGTLink at a later time.

I have tried to get OpenIGTLinkIO to send OpenIGTLink messages with header version 2, but at it still won't make PLUS send header version 2, I haven't made any pull request for this.

Bug report here
https://github.com/PlusToolkit/PlusLib/issues/374
I'll work on that today.

That's great. I just made another pull request in PlusLib for the OpenIGTLinkIO ultrasound sector meta information: https://github.com/PlusToolkit/PlusLib/pull/375

I can confirm that PlusServer switches to sending the highest known received header version. Can you show me how you get the undesired behavior?

That being said, some messages are hardcoded to be sent as V1 because they are V1 era messages. I am changing this to send the highest known version always.

Plus is correctly recording the highest possible header version a client can support, but only sent the header version according to the IGTL spec.
So, even though a client may have been v2, it would (for example) send IMAGE messages as v1 messages because IMAGE was part of the v1 header.
PR https://github.com/PlusToolkit/PlusLib/pull/376 changes this behaviour and now IMAGE messages are sent with v2 headers.

Thanks Adam!
There is a piece of code that feels suspicious to me in Plus (vtkPlusOpenIGTLinkServer.cxx, line 566):
if (headerMsg->GetHeaderVersion() > client->ClientInfo.GetClientHeaderVersion())       {         client->ClientInfo.SetClientHeaderVersion(std::min<int>(self->GetIGTLProtocolVersion(), headerMsg->GetHeaderVersion()));       }
It seems to confuse protocol version (3) and header version (2).

Hey, good catch. Although it will still work, that's not as intended!


32 basic database functions

closes #32 #48 #51 #52 #61 #62 #58
Follows Database design v4.
Import:
from app.database import database
Initialize:
db = database()
Provides initial access to database (public):

.debug_clear_all() to wipe database
.debug_show_all() to print database in console
node creation (.add_<node_type>_node )
add/modify single property data (.set_<node_type>_property )
create relationship between nodes (according to above design) (.connect_a_->_b )
remove single property (.remove_<node_type>_property )
get single property data from database (.lookup_<node_type>_property )
get list of nodes (.lookup_<node_type>_nodes)
get list of nodes parent to specific node (like list of datasets for a datamodel) (.lookup_<node_type>_nodes_<parent_type>)
delete node(s) (.delete_<node_type>). Can have different functionality depending on node type. Deleting Project deletes more than just Project (results). Deleting dataset only deletes dataset. Deleting model also deletes it's possible dataset.

Returns:

True when query succeeded
False when something went wrong
"data" when getting property data
None when something went wrong (data retrieval)
id_value of node when creating a node
[id, property_name] list when getting list of nodes of certain node_type

example:
.add_global_settings_node()
.set_global_settings_property(property_name, new_data)
.remove_global_settings_property(property_name)
.lookup_global_settings_property(property_name)
.delete_global_settings()

Notes:

When saving datetime to database it needs to be in ISO-format .isoformat()

Deeper example: https://github.com/ProjectCED/CED-LLM/issues/58#issuecomment-2414788302

Latest additions not tested outside of "proper" usage


RFC: Drag targets

Automatically generates TargetFlags and TargetList and manually implements TargetEntry. This follows the same pattern as that used by gdk::RGBA following @EPashkin's advice.
There are a few issues I see here:

The in-memory layout of gdk::RGBA and gdk_sys::GdkRGBA is identical, so casting between them was trivial while I don't believe that holds true for gtk::TargetEntry and gtk_sys::GtkTargetEntry.
I was getting compilation errors when autogenerating functions that tool an array of TargetEntrys so I disabled all functions that do that, though I obviously would like to have them as it includes the functions I want to use.
I'm getting compilation errors for SetValue and SetValueOptional because of the datatype of to_glib_none(), which I didn't get with gdk::RGBA, but I don't know if I even need those traits implemented.

Closes #442.

All of the fields for gdk::RGBA were public, but I don't think we want it for this type. After initialization i don't think these structs are really modified unlike with gdk::RGBA.

If it fields not public we need getters

I'd prefer getters then. It'll allow us to keep full control.

Should I also add 3 getters for all 3 fields (get_target, get_flags, and get_info)?

Should I also add 3 getters for all 3 fields (get_target, get_flags, and get_info)?

Yes please.

I think we're pretty close to a final solution here. I've removed the unnecessary glib::value trait impls, kept the field public in line with the other manually-implemented structs in Gtk, and fixed the ToGlibPtr* impls

Also there are several drag-related methods on Widgets that are blocking on the gdk::Atom in gtk-rs/gdk#145, so I suggest we wait to merge this until after that's merged.

The last thing that needs to be done here is to handle the various drag functions that take an array of TargetEntrys, like WidgetExt::drag_dest_set (which is what #442 actually refers to). The hard part here is converting from a &[TargetEntry] to a &[ffi::GtkTargetEntry] to be passed as a pointer to ffi::gtk_drag_dest_set. What's the correct way to do this conversion as the following is not right:
    fn drag_dest_set(&self, flags: DestDefaults, targets: &[TargetEntry], actions: DragAction) {
        let glib_targets: Vec<ffi::GtkTargetEntry> = targets.iter().map(|e| e.to_glib_none().0).collect();
        unsafe {
            ffi::gtk_drag_dest_set(self.to_glib_none().0,
                                   flags.to_glib(),
                                   glib_targets.as_ptr() as *mut ffi::GtkTargetEntry,
                                   glib_targets.len() as c_int,
                                   actions.to_glib());
        }
    }

See discussion from https://github.com/gtk-rs/gtk/pull/472#issuecomment-287472293 (you first proposed that).

@EPashkin Indeed, and the limited examples I came across online didn't show any examples doing that. I've added another commit making them private and adding getters.

About drag_dest_set you can't collect e.to_glib_none().0 as this momently dropped.
I see this way:  collect stashes
let stashes: Vec<_> = targets.iter().map(|e| e.to_glib_none()).collect();

create empty Vec and use set_len to allocate memory, then iterate stashes and copy field values for all GtkTargetEntrys.
May be there better way but I don't see it now.
Anyway this function need be tested that it really works.
Also all generated code say that it targets: &[&TargetEntry] not sure what really need (it both compiled with same code)

I've done another pass, adding enough functionality here that we can actually implement a complete drag-and-drop example (I'm going to file a PR for the examples repo shortly with WIP examples) so this work can be tested in its entirety. I still don't have everything working, but I think this is pretty close. I think the gdk work with Atoms is the weak link right now.

I'm having trouble trying to use this code and I'm not certain where the error is. If I try and use the new Widget::drag_source_set() function like:
button.drag_source_set(gdk::MODIFIER_MASK,
                       &[],
                       gdk::ACTION_COPY);

I get datatype errors like:
error[E0308]: mismatched types
  --> src/drag_and_drop.rs:18:28
   |
18 |     button.drag_source_set(gdk::MODIFIER_MASK,
   |                            ^^^^^^^^^^^^^^^^^^ expected struct `gdk::auto::flags::ModifierType`, found struct `gdk::ModifierType`
   |
   = note: expected type `gdk::auto::flags::ModifierType`
              found type `gdk::ModifierType`

Anyone have any idea what this is actually saying? If I replace line 18 with gdk::auto::flags::ModifierType, I get auto is a private module. So I'm a little lost here.

It again old manual duplicate https://github.com/gtk-rs/gdk/blob/master/src/enums.rs#L5-L27 that we forgot to remove

No, it something else

Regarding your point of enums, it does seem odd to me that there are two declarations of MODIFIER_MASK:
src/auto/mod.rs:pub use self::flags::MODIFIER_MASK;
src/enums.rs:    pub const ModifierMask: ffi::GdkModifierType = ffi::GDK_MODIFIER_MASK;

For my code above should I have used gdk::enums::modifier_type::ModifierMask?

@Susurrus No gdk::enums::modifier_type must be not used.
Strange, I checked your code on examples/basic and compiles it both nightly and stable

@EPashkin Yeah, looks like I had a bad path in my Cargo.toml. Alright, I'll get back to it, thanks!

IMHO SelectionData::set_text etc. don't need &mut self. While it still don't generate received signal, text changed.
    [[object.function]]
    name = "set_text"
        [[object.function.parameter]]
        name = "selection_data"
        const = true

Also Widget::drag-data-get signal don't need be mut and manual

Looking over the drag signals, I also think Widget::drag-drop needs to be set to inhibit = true, is that correct? I think it's for signals that return gboolean values, yes?

Also Widget::drag-motion I believe

You right for both

Alright, I've updated the code as you've suggested and set those 2 signals to inhibit. Hopefully this is in line with your comments.

Here's an updated version that addresses all of your points.

@Susurrus, rebase this to last master please
I don't see problem with code but way to use D&D still not found and this in WIP state?

Seems I found problem: from_glib_none for boxed types use copy and you don't changed original.
So need use from_glib_borrow on data
    [[object.signal]]
    name = "drag-data-get"
        [[object.signal.parameter]]
        name = "data"
        transformation = "borrow"

By way, drag_and_drop_textview.rs example panic on windows as it produced wrong path
filename: /D:/eap/rust/0/0.txt

From travis error this need skip_assert_initialized!();
$ ./check_init_asserts
src/target_list.rs: new(targets: &[TargetEntry]) -> Self

I think you did it @EPashkin! I've pushed the latest version which makes the examples work for me now. I think this does it!

👍 Thanks, @Susurrus

Awesome! Thanks @Susurrus!


WebCmdlets cleanup HttpStatusCode

PR Summary
Small cleanup of the methods that accept (HttpStatusCode code): IsRedirectCode and IsRedirectToGet

What is the justification for these changes?

The code is more readable, you immediately know what HttpStatusCodes RedirectToGet

The code is more readable, you immediately know what HttpStatusCodes RedirectToGet

Rather less readable. It would make sense for hot path, but it doesn't.
I don't see the benefit of this change.

The change was deemed useless


CASSANDRA-18540 Add a comment about the use of disabled TLSv1.1 with JDK 8 and higher to negotiatedProtocolMustBeAcceptedProtocolTest

Thanks for sending a pull request! Here are some tips if you're new here:

Ensure you have added or run the appropriate tests for your PR.
Be sure to keep the PR description updated to reflect all changes.
Write your PR title to summarize what this PR proposes.
If possible, provide a concise example to reproduce the issue for a faster review.
Read our contributor guidelines
If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:
<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira

Committed


WIP: Restructure Helm related docs

As discussed in #1205 (and #1178), the Helm docs are not as clear as they should be. We have

the flux chart README
a get started doc
an integration doc
an integration requirements doc
(and an example repo)

Almost all in different places.
This PR is a draft of how I'd like to change things:

one doc for the helm operator (Michael seemed to be in favour of this too)
one doc which explains the helm integration
all preferably in the same space

As I don't know all the details, it'd be good if we would review the content as well. I just juggled things around to be more condensed.
Thoughts:

Maybe we can explain the Helm integration in another prominent space where we detail the inner workings of Flux?
Maybe we can just document how to write the CRD in the flux-helm-test repo? That would slim down the docs even further.

Yes, this is definitely needed. I have held off doing it because I'm not sure we have the right design yet. I'm still not sure, but enough people ask about it, that's it's worth doing anyway.

@squaremo Do you want me to file an issue for this?

ideally not flux-helm-test

@squaremo An issue for that too?
I addressed the other remarks so far and wait for Stefan's go-ahead wrt moving some docs out of the chart README.

Thanks for the review.
I'll file separate issues to track the other bits which are still missing.


This should be a package

It would be much better if this is an npm package that exposes a getThemeDefinitions() method. It would also be nice to have helper methods such as injectToTemplate() documented
This way, it is easier to update the main theme and the amount of boilerplate needed to create a new theme reduces drastically

Currently the full repository layout of creating themes has an advantage of creating a boilerplate folder structure for adding non-standard assets such as sticker overrides.
Maybe a createBoilerplateDirectory() would suit that purpose.

An interace I am hoping for is something like
import { getThemes, renderTemplate } from "dokitheme";

const t = fs.readFileSync("template.json");

for (const theme of getThemes()) {
  fs.writeFileSync("out/" + theme.dir + "/" + theme.filename + ".json", renderTemplate(t, theme.variables);
}


Add collateral address check in join federation service

LGTM. The only thing that can go wrong is if the member was previously registered and the node is in IBD. An error may arise due to previously being a member with that address. This can be alleviated by replacing IsCollateralAddressRegistered with CollateralAddressOwner and only raising an error if a different owner is detected.

Perhaps we should add IBD check in the service?

Perhaps we should add an IBD check in the service?
Its another restriction/pain in what the user can do and when but maybe justified...


Issue288

r+ w/ travis fixed

This is passing Travis now, and works well (it drops about ~300K from the size of Brackets, pre gzipping).  I'd love to get some feedback from @busykai before I land, though.

@humphd, this seems about right to me. you are not loading the entire CDT-based LiveDevelopment and test dependencies. could not test the correctness, though, as i don't have a setup, but this is what i was imagining needs to be done to improve the start-up time (+ you found the test part!).

Thanks @busykai, this is helpful.  I'm OK with breaking tests, since they aren't really runnable in browser anyway, and we can/do run them on master.  I'm going to rebase and land this here.


P0591R4 Utility functions to implement uses-allocator construction

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0591r4.pdf

完了


Browser demo

Show how it can be used in a browser.

Two fields for documents
One field for redlisted words
Show input array,  calculation object/array, redlist array and stopword array

Let the fields be pre-filled so you get the hang of it right away. Mix two languages. I.e. English and Spanish. 3 fields to represent 3 documents + redlist. Link in words-n-numbers script.


Extension issue

Issue Type: Bug
Extension Name: vscode-aks-tools
Extension Version: 0.0.8
OS Version: Windows_NT x64 10.0.17763
VSCode version: 1.51.0

:warning: We have written the needed data into your clipboard. Please paste! :warning:

Hi @KYZITEMELOS93 , it looks like the details you wrote into VS Code didn't paste. Could you update the issue with a description and more information please? Thanks

Hiya @KYZITEMELOS93  , thought I might do some end of year clean up seems like the details of the issue didn't come through, and since its more than 1 month I will close this issue for now as there is no actionable item we can investigate, but happy for you/anyone to reopen in case there are more details relevant to this issue. Thanks heaps,
cc: @itowlson

oops sorry I don't remember doing this must have been automatic my apologies!

oops sorry I don't remember doing this must have been automatic my apologies!


_imageLabeler.processImage(inputImage); produce almost the same results with all images.

Describe the bug
I trained my model with approx. 400 images, and run the model on flutter.
But, the model produces almost the same result with all images (such as an image of blank wall, or an image of certain object...).
To Reproduce
I trained 7 categories with approx. 60 images each.
Last tflite training log result accuracy of 0.6.
8/8 [==============================] - 1s 77ms/step - loss: 0.9956 - accuracy: 0.6116 - val_loss: 1.5415 - val_accuracy: 0.3167
I assume the model is not trained enough?? Or am I missing something?
I know it is not enough for the production, but I expected that it can guess better.
Code:
        var inputImage = _inputImageFromCameraImage(currentimage!)!;
        var labels = await _imageLabeler.processImage(inputImage);
        print("labels ${labels.map((e) => '${e.label}: ${e.confidence}')}");

_imageLabeler.processImage log:
flutter: labels (normal20: 3.0371227264404297, normal24: 1.2958755493164062)
flutter: labels (normal20: 3.025402545928955, normal24: 1.2920397520065308)
flutter: labels (normal20: 3.0361475944519043, normal24: 1.2833253145217896)
flutter: labels (normal20: 3.0555901527404785, normal24: 1.2898293733596802)
flutter: labels (normal20: 3.0952048301696777, normal24: 1.2871267795562744)
flutter: labels (normal20: 3.106173038482666, normal24: 1.2843830585479736)
flutter: labels (normal20: 3.178009510040283, normal24: 1.3074455261230469)
flutter: labels (normal20: 3.1779122352600098, normal24: 1.3082518577575684)
flutter: labels (normal20: 3.177504062652588, normal24: 1.3079755306243896)
flutter: labels (normal20: 3.026615619659424, normal24: 1.288081169128418)
flutter: labels (normal20: 3.059936761856079, normal24: 1.2838897705078125)
flutter: labels (normal20: 3.12568998336792, normal24: 1.2795668840408325)

Expected behavior
It should be able to roughly distinguish what the labels are.
Platform (please complete the following information):

OS: iOS
Device: iPhone 11
OS: 16.5
Flutter 3.10.6 • channel stable • https://github.com/flutter/flutter.git
google_ml_kit: ^0.16.2

Make sure to follow this tutorial: https://github.com/flutter-ml/mlkit-custom-model

Thank you for the tutorial!
I could never found it for some reasons.
I'll follow the tutorial and let you know how it goes.

I followed the tutorial (basically copied all lines) and the predictions significantly improved!!
Thank you so much @fbernaly !!
Log:
labels (normal8: 8.861006736755371, normal4: 7.560824394226074, normal2: 5.855652332305908, normal12: 1.419419765472412, normal20: 0.5430938005447388)

Ok, I thought the prediction improved, turns out, it was generating almost same results to all images after all.
I guess my training data is bad.
flutter: labels (normal8: 8.851354598999023, normal4: 8.038700103759766, normal2: 6.131048202514648, normal12: 1.9037384986877441)
flutter: labels (normal8: 9.227707862854004, normal4: 7.298639297485352, normal2: 6.035979747772217, normal12: 1.4222862720489502)
flutter: labels (normal8: 9.335094451904297, normal4: 7.643350124359131, normal2: 6.177713394165039, normal12: 1.5826878547668457)
flutter: labels (normal8: 9.33517837524414, normal4: 7.654670715332031, normal2: 6.25003719329834, normal12: 1.6401894092559814)
flutter: labels (normal8: 8.866486549377441, normal4: 8.136223793029785, normal2: 6.065356254577637, normal12: 1.9531581401824951)


Create Fabric notebook for Parking sensor data standardization step

The steps for data ingestion currently use Databricks (20_standardize.py). This logic needs to be converted for Microsoft Fabric notebook.
DoD:

A Fabric notebook is created with existing data ingestion logic.
Unit testcases are created.
README.md is updated.
Open telemetry added.
Sample data that will be used is created as per existing schema (should be same as existing Databricks sample).

NOTES:

Template file (nb-020-standardize.ipynb) is created as part of #862

If the Lakehouse tables ddls needs to be modified- then these can be done in lakehouse_ddls.yaml followed by execution of nb-010-setup.ipynb

Waiting on #931

@camaderal
Please merge the spike backlog item #926 with this item.


Bit manipulation for rgb/hex conversion

Implement the conversion between rbg and hex with bit manipulation.

This is a test comment from ServiceNow.


Image handling

Hello,
I'm using the version 1.0.0-rc-1 and I would like to have more informations about how to use image handling please, I couldn't find documentation anywhere.
I simply would like to know if I can pass a method that will upload the file to the server and then return the file URL.
How can I do that please ?
Do I have to create a custom component ? If so, why is the image button present ?
Thank you !

Hi Remy,
Images are handled by the underlying Quill instance.
Here are some links to get started:

http://quilljs.com/docs/formats/
https://github.com/quilljs/quill/issues?utf8=✓&q=is%3Aissue is%3Aopen image

Okay but I can add images already thanks to the toolbar, however the image in the HTML has an URL that is far too long.
Ideally I want to handle the file upload by my side, so I would like to know if I can create a custom method that will be called once the user has selected a file and that will simply upload it ?
I've seen an example showing how to create a custom plugin so if there is no easy solution I will have to create a image upload plugin by myself I think


“Sass” is standard in text and headings.

If merged, this commit rectifies the one remaining place where “Sass” is spelled “SASS” in any heading or text.

Thanks!


Look for configuration files in the binary location (vs the current directory)

The fakenet.exe binary looks for the config files/folders in the current directory (the location from which is executed). This breaks the executable if executed from a location that is not where the binary resides in memory:
C:\Users\flare\Desktop > C:\Tools\fakenet\fakenet3.2-alpha\fakenet.exe

  ______      _  ________ _   _ ______ _______     _   _  _____
 |  ____/\   | |/ /  ____| \ | |  ____|__   __|   | \ | |/ ____|
 | |__ /  \  | ' /| |__  |  \| | |__     | |______|  \| | |  __
 |  __/ /\ \ |  < |  __| | . ` |  __|    | |______| . ` | | |_ |
 | | / ____ \| . \| |____| |\  | |____   | |      | |\  | |__| |
 |_|/_/    \_\_|\_\______|_| \_|______|  |_|      |_| \_|\_____|

                        Version 3.2
  _____________________________________________________________
                   Developed by FLARE Team
    Copyright (C) 2016-2024 Mandiant, Inc. All rights reserved.
  _____________________________________________________________

04/12/24 02:26:37 PM [           FakeNet] Could not open configuration file C:\Users\flare\Desktop\configs\default.ini

Would it be possible to change it to look for the config files in the location of the binary? It would make it nicer for user to use fakenet and also simplify FLARE-VM installation code as this is not standard case and we can't use the helper functions we use to install most tools.

Reference: https://github.com/mandiant/VM-Packages/pull/989/files#diff-f4f88ea48ed378986c00cc2fa65f87f437b3754ed8c5111b80dd4cccb8c56450R6

Resolved with https://github.com/mandiant/flare-fakenet-ng/pull/192. Thank you @emtuls and @Donaldduck8 for your contributions.


Add CMake support.

This pull request adds a simple CMake file that can be used to build packmol.

Thank you for your support. Can you briefly explain why is this useful? Does it interfere with the current make protocol?

Sure. The point about CMake is that it's way easier to use than old makefiles. It can do out-of-root builds, and automatically handles dependencies in the sources. For example, most of the existing Makefile consists of manual tracking of the dependencies, which isn't necessary in CMake.
On my computer building the project using the old makefile takes 7.5 seconds, while the CMake build takes only 2 seconds, both run with
$ make -j
The CMake file can coexist with the old makefile. I've now added a script to demonstrate how to build the project using CMake.

Ok, thank you. Merged.

At the same time, apparently it is trying to copy the binary file to /bin. In that case, the user needs root privileges to run the script. Is that what you want? Currently the binary is generated simply within the packmol directory.

Actually, the compile script was missing one line - the installation target should be bin/ by default. I'll prepare another PR to fix this.

But, using the compile script is totally optional - CMake can be run manually as well, the script is just there as an example on how to set the compiler and compiler flags, the target directory etc.


update css for mobile view

Notes for Reviewers
Related with #10705
Signed commits

[ ] Yes, I signed my commits.

🚀 Preview for commit 17293f032dd1eaa968e4f3748d575a7c038f4855 at: https://66157a0d50609f0bcbc23605--meshery-docs-preview.netlify.app

After these changes:

@abhishekmmgn you can make suggested code changes inline of the review.

I added a few more size and padding changes.


Bug: Star us on github button opens profile dropdown instead of redirecting to hot repo

Describe the bug
the Star un on GitHub button is currently triggering the menu dropdown for the user profile at the top right corner of the PrimaryNav component.
Steps to reproduce
here is a video on steps to reproduce
https://www.loom.com/share/8b03f9b3a14144df8dc6074c5bbb64f2
Affected services
hot.opensauced.pizza
Platforms
No response
Browsers
No response
Environment
Production, Development
Additional context
No response
Code of Conduct

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

Contributing Docs

[X] I agree to follow this project's Contribution Docs

.take


Content Security Policy: minor typo correction

As reported in issue ticket #4658 (Typo in documentation):

This text:

Browsers that don't support CSP simply ignores the CSP response headers.

Should probably read:

Browsers that don't support CSP simply ignore the CSP response headers.

Thanks to Caleb Queern (@cqueern) for reporting this minor issue.

Corrected singular 3rd person (ignores) to plural (ignore)
Added missing MarkDown indent marker compatibility spacing (single space after >)
Removed excessive blank lines above the page title line

Closes #4658

#sign-off


Add support for sparse-checkout mode in Git add command to resolve is…

This pull request addresses issue #213677 by adding support for sparse-checkout mode in VSCode's Git integration. The change ensures that when sparse-checkout is enabled, the git add command includes the --sparse flag, allowing files outside the sparse-checkout definition to be properly staged and committed.
How to test?
git clone --no-checkout https://myproject.git or init a new repo;
git sparse-checkout init;
create a new file;
try to stage file with add button on resource state from git extension in source control.
Result: The file should be added to index with no problem!

@microsoft-github-policy-service agree


how to run on windows

i like your app idea i cant seem to find how to run this software on windows .i cant follow through readme file .as i find instructions there not understable for me at least .. Thank you

Click on the releases at the side of the home page. Download the Chess.Book.Study-.msi file. Run the installer


Serene throwing 'Error establishing a database connection' when deployed

Hello there,
I've got a local Serene web app connecting to MySql databases hosted in GoDaddy. Everything works fine when I'm running the web app locally in the debugger, even connecting to the remote databases.
But when I deploy the app to GoDaddy, which is also my hosting provider, when accessing the website I only see the message 'Error establishing a database connection'.

I've tried googling the issue, but most of the results are related to WordPress permalink. Couldn't find anything related to what I'm experiencing.
Any comments will be appreciated.
Thanks,
-Andre.

Check connectionStrings int your web.config

Connection strings are correct in the web.config. As I mentioned, it all works fine when running on the debugger.

The connection string could be different from debugging and deployed version. However, the problem can be either the connection string or the DB server.
There are too few information to understand.

Thanks for your input, @Estrusco.
But yeah, I can connect to the databases using MySql Workbench and the hostname and credentials from the connection strings of the deployed web.config.
Which other information would you need? I'm unsure what else I could try...
Thanks anyways.

I think you should set up some page where you only open a connection standard way. This is not some problem related to Serenity, and i guess there is not much MySql / GoDaddy users that can help you here. So after getting exception details, better ask in their forums.

Could your connection driver somehow be at fault? Is it possible that it is available locally but not on your remote server?


Protobuf changes for protobuf.js instances

Protobuf.js uses prototype object creation which has the effect of
looking up the prototype chain for properties even if the instance
does not have it set.
This requires the use of 'hasOwnProperty()' in some places to
distinguish between the instance and the prototype property.
The library also assigns default values for fields, such as the
empty array or a value of 0. Our parsing would look at presences
to determine if a property was meaningfully set, but now we need to
have additional validation due to the default values set by the
protobuf.js library.

@jlisee

How fast is postProcessProtobuf vs. toObject?
The postProcessProtobuf on average negligible compared to the regular decode(msg).  Where as to toObject()  makes it jump from ~5ms to ~30ms

Do we have good test coverage for this?
I will be looking to verify our coverage for this flow.  I know the round-trip in @xviz/schema is all passing, but that does not cover this. I"ll be adding cases using the @xviz/builder with the ProtobufWriter next

Coverage decreased (-0.5%) to 62.871% when pulling f101ec585fe88277b84d7781227f12569e581411 on tpw/protobuf-perf into 37af2c23b9745af5879a0e3ede408cbe5f661b8b on tpw/protobuf-change-bytes-ui.


refactor: simplify crawlEndFinder

Description
Simplify crawlEndFinder, it seems we can avoid creating promises by using timeouts.
See https://github.com/vitejs/vite/pull/12851 for reference.
The idea is from a discussion with @dominikg. He actually proposed splitting delayDepsOptimizerUntil(id, done) into delayDepsOptimizerUntil(id) + markIdAsDone(id) and call markIdAsDone(id) without a promise during build (using the moduleParsed hook). I tried this but I couldn't make it work (I think it may work in case someone wants to take a look).
But this already is way simpler, we could measure perf too but I don't expect a difference.
This PR also removes ensureFirstRun. It was needed when we were calling delayDepsOptimizerUntil in the transform hook during build, but #12851 moved it to resolvedId so a run should be ensured without this manual trigger.

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[ ] Documentation update
[x] Other

We have a missing test to check if when running pnpm run build on playground/optimize-deps there aren't missing dependencies (an Internal error message will appear in this case). Weirdly, the tests would still pass if this happen, we need to review this.
I pushed 969ff9f (#12868) and de0323f (#12868) anyways so you can see how it would look. There are missing dependencies with these two commits though. I think it may be possible to work this out, but I don't know yet how.
In af366a2 (#12868), I added back the ensureFirstRun guard to make this PR easier to merge now as I think removing it requires more testing (we may be missing another test case too here).
So the PR after af366a2 (#12868) is only a simplication of crawlEndFinder that avoids the Promise.allSettled scheme. I think we can move forward with this one, and we can check in a future PR if we can rework where we do delayDepsOptimizerUntil during build. cc @dominikg you can check the commits above if you wanted to play, the tests will pass but make sure to pnpm run build on playground/optimize-deps

/ecosystem-ci run

50ms (0.5%) improvement on fcp 1k components: https://github.com/vitejs/vite-benchmark/actions/runs/4706700049

@patak-dev I would prefer median more with a simple swipe off the extremely outlier which is easy to be recognized 👀. The downside of mean is it's still easy to be effected to some slight outliner with a vague definition of "extremely outlier" define. After several PR's results, do you also think median is good enough 🤔?

I'm good with using median, and in that case, I don't think we need to remove the outliers, the median would already do itself by choosing the value in the middle. The effect or removing N outliers in both extremes should be a non op

test: check no missing deps in build time adds a check that will fail with the reverted commits 969ff9f (#12868) and de0323f (#12868), and would also have failed (if the log would have been there) with 4.2.1.

Merging so we have a few days to test this one while we are still in beta.


Reuse Fullpage hero on theme2 as much as possible

but I do think we should think about a better way of making these components reusable without requiring quite so much markup and CSS overrides.

Yes - We will need to separate markup from bass- layout classes. I've been wanting to do it for some time.


Mend SCA Parser update

EDIT - I will publish a different PR with multiple Parser files for one Parser similar to Sonarqube structure.  Doing them all in one file is not neat and driving me crazy :).  Code findings in API 3.0 / Platform for Mend, SAST respectively.
Minor Platform SCA and Legacy SCA edits.
Part one of this PR is to update 'Locations' and 'File Paths' to try and manage a cleaner way to extract the Path for legacy Mend SCA format vulnerabilities as mentioned here - https://github.com/DefectDojo/django-DefectDojo/issues/11340
Part two of this PR is to remove Locations from Description in the Mend Platform SCA addition I most recently added in 2.40.0.
EDIT - See Edit statement above, but this 'Part 3' for SAST will be contributed after I refactor the parser to have separate files for each, though still retaining one single Parser option.  Doing this all in one file is not ideal.
Part three of this PR is to add Mend Platform SAST / 3.0 (Code Security Findings / Vulnerabilities) formatted Findings.
The idea is to create one parser that can accomplish:
-Original Mend Parser SCA Findings preservation.  I do not want to update or edit this here much, since people may already be using this in the wild.  Previously I added an edit to the Locations / File Paths, but due to the issue linked above; it may negatively impact teams who have a large list of file paths / locations with their Findings from the Mend Legacy SCA (non-platform) output / legacy 1.0 API formatted output.
-New Platform SCA parser.  This was implemented in my most recent PR affecting Mend parser.py, however an oversight of adding the Filepath to the Description has me wanting to refactor the Location out of the Description, as to not affect deduplication since Description and Title are used.
EDIT - See above Edits, this isn't in this PR at this moment.
-New Platform SAST parser.  This will be the 'meat' and main portion of this PR.  Code SAST Findings in Mend should be able to be identified and structured as a result of changes in this PR.
Checklist
This checklist is for your information.

[X] Make sure to rebase your PR against the very latest dev.
[X] Features/Changes should be submitted against the dev.
[ ] Bugfixes should be submitted against the bugfix branch.
[X] Give a meaningful name to your PR, as it may end up being used in the release notes.
[ ] Your code is flake8 compliant.
[ ] Your code is python 3.11 compliant.
[ ] If this is a new feature and not a bug fix, you've included the proper documentation in the docs at https://github.com/DefectDojo/django-DefectDojo/tree/dev/docs as part of this PR.
[ ] Model changes must include the necessary migrations in the dojo/db_migrations folder.
[X] Add applicable tests to the unit tests.
[X] Add the proper label to categorize your PR.

Extra information
Please clear everything below when submitting your pull request, it's here purely for your information.
Moderators: Labels currently accepted for PRs:

Import Scans (for new scanners/importers)
enhancement
performance
feature
bugfix
maintenance (a.k.a chores)
dependencies
New Migration (when the PR introduces a DB migration)
settings_changes (when the PR introduces changes or new settings in settings.dist.py)

Contributors: Git Tips
Rebase on dev branch
If the dev branch has changed since you started working on it, please rebase your work after the current dev.
On your working branch mybranch:
git rebase dev mybranch

In case of conflict:
 git mergetool
 git rebase --continue

When everything's fine on your local branch, force push to your myOrigin remote:
git push myOrigin --force-with-lease

To cancel everything:
git rebase --abort

Squashing commits
git rebase -i origin/dev

Replace pick by fixup on the commits you want squashed out
Replace pick by reword on the first commit if you want to change the commit message
Save the file and quit your editor

Force push to your myOrigin remote:
git push myOrigin --force-with-lease

To be clear, this is only for SCA and fixing Locations + removing the Library Path from the description to avoid being used in deduplication.
The mentioned SAST changes will be in a future PR after I refactor and clean up this so I can break out a single parser into multiple files, instead of attempting to code everything in one file.

I am testing these changes in my dev stack right now.

After testing import on Legacy SCA and Platform SCA:
Legacy - These changes fix the varchar 4000 issue for the file paths field for legacy SCA vulns, while adding it into steps_to_reproduce successfully.  The file_paths is no longer used for Legacy SCA and can no longer error out on the var char 4000 limit for that field in the DB/model.
Platform - Adding logic for steps_to_reproduce to retrieve the component.path and Transitive dependencies should now include the component -> path as the steps_to_reproduce.  If the library and vulnerability is Direct, then Path is not in the Mend SCA Platform output json file, only for Transitive ones for some reason.  Maybe they (Mend) will update this at some point, but it's still good to gather the component path the vulnerability is in and whenever they get around to adding Direct dependencies with the component path data, it will be available in the Finding in DefectDojo with this parser change.\
I am pretty sure this is the final Legacy / SCA Platform parser change I am setting out to accomplish, before my next PR which will break this out similar to a structure as defined in the sonarqube tool parser.  One parser file to handle the context of multiple schemas is not the cleanest approach, and after talking with my team - we agreed that before I introduce the Platform SAST parser capabilities, it would be best to restructure the Mend parser files to be similar to that of SonarQube and making the logic a bit easier to follow, when broken out.

It's worth noting that in the SCA Platform uploads, some of the json files are missing component -> path and cannot pull the location into steps to reproduce field.  This is a bug with Mend that I am bringing up with their support team, as their Platform UI does not show the location either - whereas their Legacy one does...  This means it's there, just some kind of bug on their backend for providing that Location data into the Platform UI + json output.  Assuming Mend fixes Direct dependencies to have a Location (only works for Transitive, pulling in the Direct dependency via dependencyFile) then the steps to reproduce will eventually start picking up the Locations of Direct dependencies, once Mend identifies a fix.
In a nutshell: if Mend scanned something and identified a library - it has to know where the location is (whether direct match or dep file inclusion).  So by design, that should be included and since it's in the Legacy UI + json, it's possible -- so something in their Platform is broken.

I have just encountered a bug in this parser for some edge cases.  I am looking into it now.  The error / bug mentioned is Internal Server Error, 500, and when I check Logs it's due to impact and Direct / Transitive sometimes being empty with the component -> dependencyType.  I am not sure why this data is missing from Mend, though I have a meeting with them this Friday - so I will bring up this bug and the other one I have mentioned with the missing Locations.
I have a fix being tested for this right now.  I think it's just adding on line 66 a , "" after the node["component"].get("dependencyType") -- since sometimes that is not always populated for each Finding, due to what I just described above.
I'll test on my stack and my imports first, then I'll push the change here.

I can confirm the 500 internal server error no longer occurs with these recent changes.

Just to add - there is a bug with Mend Platform API vs UI showing discrepancies and inconsistencies in the data.  I have raised a support case and it is being worked on by Mend engineering teams.
For example, projects are showing different Findings data between the UI and API.  API has "more" data and Findings compared to the UI which seems to be missing some (unless the API is just wrong and getting data from somewhere else on their backend).
I will follow up either here or in Slack when my support case for data inconsistencies is updated.

@Maffooch I have met with our rep who has escalated the case to engineering internally within the Mend team.  I provided a full recorded screenshare and 2 sample projects showcasing differences between their Mend Platform UI and API and they are aware + working on a fix.  Given the holiday season, I expect a bit of a delay unfortunately.
I'll comment back with their resolution, hopefully it will get fixed quickly.  I will validate our own projects and the integrity of data between UI and API, then verify here.

@testaccount90009 Thank you for your work on this. 😄

TL:DR - They're aware of their inconsistent data which is what caused this issue - I added a check to the parser code to only grab findingInfo -> status == ACTIVE findings.  The parser file for multiple-findings.json contains totalItems = 11, but should only be 5 Active.  I've updated the unit test to reflect that as well.
I will run a test for this fix locally on my dev stack on Monday and confirm if this fixed the issue or not.
Per Mend:  Legacy UI and API show matched and consistent data with no concept of a finding being remediated.  Mend does an override for a scan inventory (though you can specify append) which removes all of the libraries from the inventory and the vulnerabilities related to those libraries.
However... in Mend Platform UI this is also true, but NOT for the API...  The API can return remediated 'LIBRARY_REMOVED' (findingInfo -> status) Findings and vulnerabilities.  Why their UI doesn't show this - no clue.. Why their API docs don't document this - no clue..  Their API and UI are still inconsistent (UI should show remediated Findings then if they're sticking around for history), so I am going to ask Mend to clarify their 3.0 API Documentation, as well as update their UI to show "LIBRARY_REMOVED" Findings as well.
Quite frankly, I'd prefer if their 3.0 Platform API just removed the findings from the json 'getProjectSecurityDependencyFindings' call, but I guess they feel the need to keep those around in the API (but not present them in the UI)...  A head scratcher for sure!

I will test this in my dev stack on Monday, but I believe this is an iteration of the parser that can parse ACTIVE only Findings.  I also updated the unit tests to make sure title was coming across correctly.

@Maffooch I can confirm there are no longer inaccurate / inconsistent entries for Findings that are no longer 'ACTIVE' status from Mend SCA Platform 3.0 API.  With the latest updates and after the response from the Mend team, the parser only retrieves ACTIVE findings and no longer retrieves 'LIBRARY_REMOVED' or other status Findings.


feature-gate simdnoise

Can simdnoise be feature gated in crates/utilities/Cargo.toml?
Cause it does not compile on a M1 Mac. There is a PR for it to be fixed, but it's getting old : https://github.com/jackmott/rust-simd-noise/pull/34
When I try to run cargo test on my M1 I get hundreds of errors like this:
323 | #[target_feature(enable = "sse4.1")]
        |              ^^^^^^^^^^^^^^^^^ `sse4.1` is not valid for this target```

Sure thing! I just pushed a commit for this.


Apply db-sync fix for epoch crash

Can we please get a patch branch created to be able to apply the fix for the broken epoch issue: https://github.com/input-output-hk/cardano-db-sync/issues/398
I've tried changing the docker image for db-sync to 'master' but Hasura isn't able to start up:

When will this problem be fixed,

@CyberCyclone The db-sync error message in that image has nothing to do with that db-sync issue.
However, for that issue, commit a8129c54c7caa663dc8826a33a3655e32579d4d6 of cardano-db-sync is due to be tagged as 6.0.1 RealSoonNow (tm).

@erikd thanks for that.  This was more specifically to do with cardano-graphql and trying to run against the docker file tagged "master" for db-sync. I should have been specific in that the first line in the screenshot says "Remote schema is missing Block" and Hasura doesn't start up.
I have since then tried running the master branch of db-sync with the docker-comose config but postgres isn't populating for some reason so that might be why cardano-graphql isn't able to use db-sync:master yet.

Fix release being prepared in https://github.com/input-output-hk/cardano-graphql/pull/380

Hi guys, I'm using this [0] versions combo (docker images) and tho it works for testnet, I can't get it to work on mainnet cos of this Remote schema is missing Block.
This instance was initially sync using @erikd's temporary fix branch for 6.0.0 and (hasura|graphql)-3.0.0 (which also worked in for testnet deploy); then smoothly upgraded to corresponding 6.0.1 and 3.0.1, but nothing changed :(
Any hint/workaround :D?
[0]
cardano-db-sync-6.0.1
hasura-3.0.1
cardano-graphql-3.0.1


Return results to caller

I made some progress returning result, however, there are a few issues and some work yet to be done.
Problems:

have yet to pass a result to a child presenter via its event sink. The latest commit is a wip attempt at getting this to work
the favorite is not being remembered

Todo:

the current solution still mutates a regular prop in the navigator. Have yet to look at using mutable state

See d18b43b5db91a94faae04df5cc984792d27f6eff for a (somewhat) working solution that passes the result via the screen object

A last thought is I kinda think this star approach isn't the greatest example and that might be making us work against the grain as it's not how we'd actually write a result flow like this. In a normal case, I'd expect starring the pet to just update the PetRepository and not exit the detail view. I think the filters bottom sheet would be a better example.

Totally agree it is a contrived example. It was what came to mind and is the only actual screen to screen navigation available to tinker and explore the problem with. As the sample app is currently constructed, filters won't work as the filter view is a parent of the pet list and technically visible the whole time.
We've talked about having multiple sample apps. I'm wondering if I should abandon this effort, clone the sample, and make filters a standalone screen that we navigate to. This would give us a much better use case and be functionality we'd actually commit. Thoughts?

Closing this experiment. We ended up going a different route


[CT-139] [Bug] Database Error: Failed to Connect

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior

When I try to run dbt locally, I receive this vague error that is difficult to debug. dbt seems to be receiving the information that it expects based on the profiles.yml and dbt_project.yml being read as valid. It errors out at the connection and says it finds an error, but the only error it gives is "Runtime Error/Database Error/failed to connect."
This is confusing and frustrating because the profile that I have provided dbt is identical to the profile I provided to dbt cloud, but for some reason dbt will not run locally with the exact same credentials. The error message is vague and I am not sure what else to do and need help. I have also attached my profile information with the sensitive parts blacked out.

Expected Behavior
I expect a more detailed error when I try to run dbt locally--what about the connection failed? Is the token invalid? is the SQL endpoint invalid? Is the host wrong? Something other than 'failed to connect' and 'check your credentials'. My credentials are identical to dbt cloud, and dbt cloud works fine.
Steps To Reproduce

in the dbt repository, run source ./dbt-env/bin/activate in the terminal
in the top-level folder (dbt), run 'dbt run' in the terminal.
receive the error pictured belo

w

Relevant log output
No response
Environment
- OS:Big Sur 11.6
- Python: 3.9.7
- dbt:1.0.1

What database are you using dbt with?
other (mention it in "Additional Context")
Additional Context
using databricks plugin 1.0.0

@faithlierheimer Thanks for opening this detailed bug report!
The connection that dbt uses to each database is defined in the adapter plugin for that database. That's also where the logic needs to live for more detailed error information, in the event that the connection fails. As such, I'm going to close this issue, since dbt-databricks (not dbt-core) would be the right spot for a related code change. (This repository can be a good place to discuss general-purpose approaches that we might recommend for each adapter plugin to follow / implement themselves, e.g. https://github.com/dbt-labs/dbt-core/issues/3828.)
If your aim is to get help debugging the specific local connection, I'd encourage you to post on StackOverflow, or in the #db-spark-databricks channel in the dbt Community Slack.
If you have a specific request for a code change in dbt-databricks, such as more error message details / error chaining from dependencies, I'd encourage you to re-open a similar issue over there: https://github.com/databricks/dbt-databricks/issues/new/choose

I had the same issue and this is how I fixed it:
https://stackoverflow.com/questions/72291367/can-not-connect-dbt-cloud-or-dbt-core-to-databricks


Remove jQuery from Atom core

This has been a long time coming. I made the early mistake of basing Atom's initial view system, SpacePen, on jQuery, which solves a lot of problems that aren't at all relevant when targeting a single, modern browser engine. Last summer we removed the reliance on jQuery from Atom's public API and setup a pretty complicated layer of shims to keep the old jQuery-based views working through the deprecation period. With that finally behind us, this PR will remove jQuery and SpacePen entirely. We'll need to transition bundled packages away from SpacePen to finally get the benefit of reduced require time by not loading jQuery, but this is a first step.
Some things to note:

Our default tooltips are based on bootstrap, which ships its tooltip support as a jQuery plugin. I reworked their code to remove the dependency on jQuery, which could slightly alter a couple corners of the API. It would be great if people could help me test that the new tooltips work correctly in all cases.
Some of our rarely used global spec helpers have been removed.
The last incomplete step is to switch our test reporter from SpacePen to raw DOM APIs.

I do worry that old packages that depend on jQuery might break in unforeseen ways, since we were augmenting the jQuery that shipped with SpacePen with extra stuff. For example, we had shimmed trigger to run Atom commands, but that no longer works. I'm not totally sure what's going to happen, but most packages developed in newer styles should have nothing to do with this.

Maybe a blog post, linked to on Slack and Discuss, would help raise awareness among package authors to confirm whether this will impact them.

Will those tooltips be created by Blink?
(The same way, or similarly enough?)
If not, disregard this post.
Right now, there's a particularly terrible bug¹ open that would make Atom unusable in Enlightenment.
1: https://code.google.com/p/chromium/issues/detail?id=381732

There are some spurious API-related failures, but our main build is passing, so I'm going to merge this.
@Yomi0 We're still creating the tooltips manually via the DOM... I just ported the Bootstrap code to native DOM APIs. So everything should be okay on that front at least. Happily the next Atom release will be accompanied by a 1-week beta phase we'll be rolling out next week.


Allow the use of categorical data in PyAF

One user pointed out that categorical data cannot be used in PyAF as exogenous variables. Unacceptable ;)

Fixed.


Implement C# lib to communicate through RPC in the Explorer Renderer

Closing in favor of more specific tasks created.


Roll Flutter Engine from 965501a25d92 to 6e5ad11df0d3 (6 revisions)

https://github.com/flutter/engine/compare/965501a25d92...6e5ad11df0d3
2023-08-24<EMAIL_ADDRESS>Roll Skia from 177e8477faf9 to d7d56885a49b (1 revision) (flutter/engine#45078)
2023-08-24<EMAIL_ADDRESS>Reland: [Rasterizer] Make resubmit information temporary (flutter/engine#45037)
2023-08-24<EMAIL_ADDRESS>Add case checking to android sdk cipd upload script (flutter/engine#45063)
2023-08-24<EMAIL_ADDRESS>Roll Skia from<PHONE_NUMBER>89 to 177e8477faf9 (1 revision) (flutter/engine#45076)
2023-08-24<EMAIL_ADDRESS>Turn on the skia_enable_optimize_size flag to save a bit of binary size (flutter/engine#45029)
2023-08-24<EMAIL_ADDRESS>Roll Skia from b17ee34f3378 to<PHONE_NUMBER>89 (1 revision) (flutter/engine#45075)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jimgraham@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

AutoRoller is stopped; closing the active roll.


Yolov4-Tiny: No detections when object is small or large

Hi TNTWEN,
I recently converted a custom yolov4-tiny model and have it converted to IR using this script. I then did a side by side comparison between the darknet model and the converted IR mode. I noticed that the converted model is having trouble detecting my object when I bring it closer to the camera or further away from the the camera. Meanwhile the darknet model has no trouble detect it at all. Do you have any idea why this is the case?

I think I found my problem, I did not change the number of class in the yolov4-tiny.json file.  After I corrected that, it seems to perform better.

Note: the masks values in the yolo_v4_tiny.json should be changed from
"masks": [[3, 4, 5], [1, 2, 3]],
to
"masks": [[3, 4, 5], [0,1, 2]],
Otherwise, the bounding box will be big when the object becomes small

@at1993 Thanks! works like a charm :)


⚠ ClamAV has degraded performance

In d991882, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 69 ms

Resolved: ClamAV performance has improved in d05e464 after 37 minutes.


Refactor license code.

Refractor -

[ ] Avoid duplicate ajax calls and save it in the local $page.props instead.

@NRayya Can you please just test the license feature and make sure nothing it's working fine?


Gpl 426 tag taggable join

Changes proposed in this pull request:

Add a new Taggable concern (currently just included by Ont::Requests)
Add a new TagTaggable join between Tag and Taggable (since a taggable can have many tags, and a tag many taggables)
Test the new models and updated relationships

A few things to think about, but looking good overall. I did notice you have this set to merge into gpl-426-allow-pretagging-samples but I did create a branch that's just called gpl-426. I feel that by having the base branch for an issue just be called by its number, then it makes it clear that is the base branch, and anything with a description in the branch name is work that will be merged into that base branch. What do you think?

A few things to think about, but looking good overall. I did notice you have this set to merge into gpl-426-allow-pretagging-samples but I did create a branch that's just called gpl-426. I feel that by having the base branch for an issue just be called by its number, then it makes it clear that is the base branch, and anything with a description in the branch name is work that will be merged into that base branch. What do you think?

I will remove the branch I created for the same purpose as your gpl-426, and re-target this PR at that branch, maybe not in that order


Allow FreeBSD 12 to build using vendored LLVM

Side note, this would probably have fixed our FreeBSD 11 issues as well.


ew option to allow "example-common" project to not be included in build.

I added a new option BGFX_BUILD_EXAMPLE_COMMON to allow users to opt out of the example-common project from being added to their solutions. It defaults to On to match the default for BGFX_BUILD_EXAMPLES which relies on it.
I created a new option to allow users to continue to use example-common in their project without adding the rest of the examples and to preserve the existing behaviour.
Fixes #224

Thanks for your PR.
It's missing one piece though. Example common is used in the tools (geometryc, geometryv, shaderc, texturev) etc.
I would really like to see this as a cmake_dependent_option too.

I took another look and changed the code to:
cmake_dependent_option(BGFX_BUILD_EXAMPLE_COMMON "Build bgfx example-common project." ON "NOT BGFX_BUILD_EXAMPLES;NOT BGFX_BUILD_TOOLS" ON)
Ideally, that first "ON" should be an "OFF", so if both the examples and tools were off the common project would also be off, but that would change the old behaviour. So, at the moment, people still need to explicitly disable example-common.
Which do you think is the better default?

Makes sense to only compile what's needed.
I think ideally, there shouldn't be an option and cmake should figure it out.
Have you considered using EXCLUDE_FROM_ALL?

Okay, I set it up as a dependent option that only includes example-common if either the tools or examples projects are included in the build.
This produces a minimum set of projects in the solution if those options are disabled.

EXCLUDE_FROM_ALL doesn't do this for you?

Thanks, since I use visual studio for development, I can work around the issue with EXCLUDE_FROM_DEFAULT_BUILD instead, it's more or less the same option.
Even with this, I still end up with an extra project in the solution that isn't needed. It's not a big deal, but it clutters searches and file opening with files that aren't in use in the project.

I see what you mean.


avoid assign shell calls in makefile macros

Issue #, if available:
Description of changes:
:= in makefiles creates a "real" variable who's value is determine at the time of assignment.  = or ?= creates a macro in the makfile who's value is not determined until the time that it is to be used.  We use this intentionally all over to ensure we can set variables during the flow through make targets.  When calling $(shell...) via a macro, make shells out everytime the value is requested.  For something like BASE_DIRECTORY or GIT_TAG this could be a number of times.  This changes as many of the calls to shell as possible to use := instead of =.  There are still some instances throughout the code base of =$(shell ..) which are completely acceptable and necessary.  For example, any time the shell needs the value of a var which may not have been set yet or needs to access the REPO which hasnt been cloned yet.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Are we sure we want to swap out many of the ?= assignments? ?= is useful for parameterizing invocations of make recipes while supplying sane defaults. E.g. make build GIT_TAG="custom-tag-for-hack-build".
Disclaimer: I don't know the (original) intent for many of these Make variables. Perhaps uses of ?= were accidental.

We def will continue to use ?= since we use it all over the place in Common.mk intentionally for its set if not set properties.  This specific usage is mostly likely a hold over from the earliest days of the eks-d makefiles where I do not believe we had specific intention one way or another and were just using ?= everywhere.
That said, your example actually still works as intended without the ?=.  The ?= is more about catching values from Environment vars or in cases where the makefile may have set it previously.  Vars passed to make directly will override variables being set (unless maybe if you use the override directive?).
make build GIT_TAG="custom-tag-for-hack-build" - GIT_TAG from cli arg takes priority
GIT_TAG="custom-tag-for-hack-build" make build or export GIT_TAG="custom-tag-for-hack-build" && make build - GIT_TAG is set to the value from the file.  If the assignment was ?= this syntax would also take priority.

/lgtm


Main-dashboard filter fix

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Fixes main dashboard display filter
What is the current behavior? (You can also link to an open issue here)
displays main dash on empty results
What is the new behavior (if this is a feature change)? If possible add a screenshot.
only displays if results are valid
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
nope

closes #95


[Bug] Stack overflow when miner creates block

🐛 Bug Report
This occurs on the master branch as of whatever was the latest commit on 2020-01-11

The runtime for this wasn't actually 11 hours as seems to be implied by the timing of the log message, the system was suspended for some time between the messages.
Operating System: Linux, Archlinux x86-64
System Specs: Intel i5 dual core, hyperthreading enabled, 16GB ram
Steps to Reproduce
cargo run -- --is-bootnode --is-miner --rpc-password test --rpc-username test --miner-address aleo1438uwm8uxa6kt0vpfz8958vesz2x4ws985ekvqf2uc64dvyzpv9sd7xg3g

Looks like a contributing factor to this is that I forgot to compile/run in --release mode.

I can reproduce this with current master, but it is definitely recommended to run the node in --release mode (which doesn't trigger a stack overflow) instead; it is much faster.

Yes it is definitely much faster! :sweat_smile:
It might be worth trying to increase the stack size for the tokio-runtime-worker thread for debug builds? I'm not sure whether it's possible.

I'm currently looking into ways of mitigating this; I'll advise soon.

Increasing the tokio worker thread stack size from the default 2MiB to 4MiB seems to solve the issue indeed; this might even be preferable for non-debug builds, just to have that extra bit of safety margin.
I'll send a relevant PR soon; I'll try to reduce the strain on the stack too.


compressFirmwareXz: fix links to directories

Description of changes
Only add the .xz suffix to links if link target is a regular file. This breaks if the target is a directory.
Fixes #283005.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

cc @beh-10257

Will this get into unstable repos soon enough or is there a way to test this
Hopefully I can take this in the next two days when I ran
Nix flake update
And thanks

I know this is already approved but its been two days and this is not merged and I guess it will take another two days
After getting merged to be in nixpkgs-unstable
is this in staging or something
How do I add staging as an input using flakes and use linux-firmware from staging
So I can continue nvk testing
Thanks either way

is this in staging or something

no, it would be merged into master first. see the flow of merged pull requests section of CONTRIBUTING.md

How do I add staging as an input using flakes and use linux-firmware from staging

since it's not in staging, you will need to use fpletz's fork
{
  inputs.nixpkgs.url = "nixpkgs/nixos-unstable";
  inputs.nixpkgs-firmware-fixed.url = "github:fpletz/nixpkgs/pkgs/compress-firmware-xz-ln-filesuffix";

  outputs = { nixpkgs, nixpkgs-firmware-fixed, ... }: {
    nixosConfigurations.myHost = nixpkgs.lib.nixosSystem {
      modules  = [
        ./configuration.nix
        {
          nixpkgs.overlays = [
            (_: prev: {
              inherit (nixpkgs-firmware-fixed.legacyPackages.${prev.stdenv.hostPlatform.system}) linux-firmware;
            })
          ];
        }
      ];
    };
  };
}

in the future i would also consider being more patient with merges, 2 days isn't that long :p

is this in staging or something

no, it would be merged into master first. see the flow of merged pull requests section of CONTRIBUTING.md

How do I add staging as an input using flakes and use linux-firmware from staging

since it's not in staging, you will need to use fpletz's fork
{
  inputs.nixpkgs.url = "nixpkgs/nixos-unstable";
  inputs.nixpkgs-firmware-fixed.url = "github:fpletz/nixpkgs/pkgs/compress-firmware-xz-ln-filesuffix";

  outputs = { nixpkgs, nixpkgs-firmware-fixed, ... }: {
    nixosConfigurations.myHost = nixpkgs.lib.nixosSystem {
      modules  = [
        ./configuration.nix
        {
          nixpkgs.overlays = [
            (_: prev: {
              inherit (nixpkgs-firmware-fixed.legacyPackages.${prev.stdenv.hostPlatform.system}) linux-firmware;
            })
          ];
        }
      ];
    };
  };
}

in the future i would also consider being more patient with merges, 2 days isn't that long :p

@getchoo
well since that doesn't work (there are no errors its just that the files haven't changed)
I guess this package doesn't change the linux-firmware package but yeah sorry for not waiting
and I don't know learning how to do this kind of stuff makes it so that I can use it just like I did with arch
anyway thanks anyway

@getchoo Your overlay is actually not correct since this PR changes compressFirmwareXz that is used by the NixOS module merging the firmware packages and not linux-firmware itself.
Merging now myself since this PR got the approval of the derivation's author.

This seems to break the loading of some amdgpu firmware, I'm still investigating.

The offending dmesg line is:
Direct firmware load for amdgpu/psp_13_0_4_toc.bin failed with error -2

Before this change:
   <firmware>/lib/firmware/amdgpu/psp_13_0_4_toc.bin.xz
-> <linux-firmware-20240115-xz>/lib/firmware/amdgpu/psp_13_0_4_toc.bin.xz
-> psp_13_0_11_toc.bin.xz

After this change:
   <firmware>/lib/firmware/amdgpu/psp_13_0_4_toc.bin.xz does not exist
   <firmware>lib/firmware/amdgpu/psp_13_0_4_toc.bin
-> <linux-firmware-20240115-xz>/lib/firmware/amdgpu/psp_13_0_4_toc.bin
-> psp_13_0_11_toc.bin

I see no easy fix other than reversing the logic to check for directories instead.

@NickCao https://github.com/NixOS/nixpkgs/commit/0dfe2e933f4418afdff7e69d1782b1aa86ca8b95#commitcomment-137937208

This broke my amdgpu firmware as well.  We could probably fix it like this:
diff --git a/pkgs/build-support/kernel/compress-firmware-xz.nix b/pkgs/build-support/kernel/compress-firmware-xz.nix
index cfb06a5c0f15..1c8e4df82a2e 100644
--- a/pkgs/build-support/kernel/compress-firmware-xz.nix
+++ b/pkgs/build-support/kernel/compress-firmware-xz.nix
@@ -15,6 +15,12 @@ runCommand "${firmware.name}-xz" args ''
           sh -c 'xz -9c -T1 -C crc32 --lzma2=dict=2MiB "${firmware}/$1" > "$1.xz"' --)
   (cd ${firmware} && find lib/firmware -type l) | while read link; do
       target="$(readlink "${firmware}/$link")"
-      ln -vs -- "''${target/^${firmware}/$out}.xz" "$out/$link.xz"
+      if [ -f "$(readlink -f "${firmware}/$link")" ]; then
+        ln -vs -- "''${target/^${firmware}/$out}.xz" "$out/$link.xz"
+      else
+        ln -vs -- "''${target/^${firmware}/$out}" "$out/$link"
+      fi
   done
+  # find broken symlinks
+  ! find $out -xtype l | grep .
 ''

bonus check for broken symlinks which fails both before (nvidia gsp directory links) and after (firmware bin links) the PR change.

I tried rewriting it in Python: https://github.com/NixOS/nixpkgs/pull/284473

The Python version notably produces no broken symlinks.


Y-Axis Zoom not working in stacked bar chart with positive and negative values in one stack

Description
I am using a stacked bar chart to show two data series. The values of one of them are multiplied with -1 to go into the negative direction of the y-axis. The purpose is to compare two series.
However:
I noticed that the Y-Axis scaling is not working as expected when using a stacked bar chart. When setting stacked: false the Y-Axis works as expected, but this gives not the visualization that I want to get out of the chart.

Steps to Reproduce

Open Codepen: https://codepen.io/Loahrs/pen/BaXbgma
Zoom into [ (x=129, y=81), (x=129, y=-634)]
The Y-Axis won't scale properly.
Remove "stacked: true" from the config
Zoom into [ (x=129, y=81), (x=129, y=-634)]
The Y-Axis is properly scaled in both directions.

Expected Behavior
I would like to have the Y-Axis to scale in the positive and negative range correctly on a stacked bar chart.
Actual Behavior
The Y-Axis is not scaling correctly in both directions,
Screenshots
Non-stacked:

Stacked:

I would expect to see the same Y-Axis that is shown in the non-stacked Version when using a stacked bar chart.
Reproduction Link
https://codepen.io/Loahrs/pen/BaXbgma

I looked a bit deeper into this problem and it seems its this particular line/function:
https://github.com/apexcharts/apexcharts.js/blob/78f5dd510624f932dcc8f2a3cebeda75222a9f7d/src/modules/Range.js#L259
Only for stacked charts new MinMax values are calculated (because of the stacking). But in calculating those values, the whole range of the chart is used. This way the global maximum is used to calculate the maximum of the y-axis.
For the minimum, the value in the relevant window is saved into lowestYInAllSeries in line 256 und reapplied in the next block in line 279 since it's a bar chart.
It seems the function/function call has te be changed in a way to only work with the selected x-axis indices.


Version

Please add the 2021.3.16f1c1,thanks!

Unity 2021.3.16f1 was added to the tpk last year: https://github.com/AssetRipper/TypeTreeDumps/blob/main/Classes/2021.3.16f1.json
If you mean unity chinese encryption, that's different and not something I'm supporting. Can you specify what the issue is? Does it not open at all? Do certain assets not open?

Is this just #251 again? You never uploaded a log in that issue.

Is this just #251 again? You never uploaded a log in that issue.
This is the log.

#00 pc<PHONE_NUMBER>0e063c  /apex/com.android.runtime/lib64/bionic/libc.so (tgkill+12) (BuildId: 2bb0d7188c0db2e8beecb24658ba9d71)
#01 pc<PHONE_NUMBER>6b6534  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#02 pc<PHONE_NUMBER>6b6ab0  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#03 pc<PHONE_NUMBER>1deb64  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#04 pc<PHONE_NUMBER>1de978  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#05 pc<PHONE_NUMBER>2bfa6c  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#06 pc<PHONE_NUMBER>2c0898  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#07 pc<PHONE_NUMBER>2c0a70  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#08 pc<PHONE_NUMBER>1d2558  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#09 pc<PHONE_NUMBER>1d4400  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#10 pc<PHONE_NUMBER>1d41cc  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#11 pc<PHONE_NUMBER>1d4148  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#12 pc<PHONE_NUMBER>24dbb4  /data/app/~~KHauV5L1OYxCgPyiASJung==/com.mis.ww-eYPvXHSiNK38LqQH9E7bcg==/lib/arm64/libunity.so (BuildId: 2370ce2e94fe56e363ccc859c3b876244405e7a1)
#13 pc<PHONE_NUMBER>0f5548  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: 2bb0d7188c0db2e8beecb24658ba9d71)
#14 pc<PHONE_NUMBER>08ef3c  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+68) (BuildId: 2bb0d7188c0db2e8beecb24658ba9d71)

This is a native error which makes it really hard for me to do anything. All I can ask is if you notice any significant changes in the file with a hex editor when saving with UABEA. If that's the case, it might be that the c version of unity adds some extra data I don't handle.


[Kernels]Added cuda kernels for inference, and update Cuda bloom attention

📌 Checklist before creating the PR

[ ] I have created an issue for this PR for traceability
[ ] The title follows the standard format: [doc/gemini/tensor/...]: A concise description
[ ] I have added relevant tags if possible for us to better distinguish different PRs

🚨 Issue number

Link this PR to your issue with words like fixed to automatically close the linked issue upon merge
e.g. fixed #1234, closed #1234, resolved #1234

📝 What does this PR do?
This PR is used to add cuda bloom attention version, you can test it whether it can improve your inference forward process when training.
💥 Checklist before requesting a review

[ ] I have linked my PR to an issue (instruction)
[ ] My issue clearly describes the problem/feature/proposal, with diagrams/charts/table/code if possible
[ ] I have performed a self-review of my code
[ ] I have added thorough tests.
[ ] I have added docstrings for all the functions/methods I implemented

⭐ Do you enjoy contributing to Colossal-AI?

[ ] 🌝 Yes, I do.
[ ] 🌚 No, I don't.

Tell us more if you don't enjoy contributing to Colossal-AI.

To Test it:
git clone --recursive https://github.com/hpcaitech/ColossalAI
cd colossalai/kernel/cuda_infer_kernels
pip install -e .

Then, use this attention(https://github.com/tiandiao123/ColossalAI/blob/cuda-bloom-attention/applications/Chat/coati/models/bloom/cuda_attention_forward.py#L65) to replace your forward


feat(config): introduce deprecation warning handler, fix #1672

Allow passing custom handler for deprecation warnings allowing fine-grained control how these are reported to a user.
This is super important for huge codebases, where simple console.error reporting is not enough. For example, for gradual migration I would like to turn deprecation reports one-by-one, while our codebase is cleaned, making sure they will never appear. Currently this is possible only by hooking into console.error, which is bad, "stringly-typed" and somewhat hard to implement
What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[X] Feature
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[X] No

The PR fulfills these requirements:

[X] It's submitted to the dev branch.
[X] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[X] All tests are passing: https://github.com/vuejs/vue-test-utils/blob/dev/.github/CONTRIBUTING.md#development-setup
[X] New/updated tests are included

If adding a new feature, the PR's description includes:

[X] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Cool. I will release this next Monday. Please wait a bit.


change the color

I can't enter a number from the keyboard to change the color.

thanks for reporting, will take a look asap


lib: config: use official kube pause image from gcr

Signed-off-by: Antonio Murdaca<EMAIL_ADDRESS>
- What I did
- How I did it
- How to verify it
- Description for the changelog

LGTM
/test all

/test e2e_rhel

/test e2e_rhel


book authors not being shown in books view

books view will be removed in upcoming version, PR will close it


Genx mod

I have made changes for columns for network.csv, generators_data.csv, generators_variability.csv, and load_data.csv. I haven't made any changes to the fuels_data.csv dataframe yet.

@aneeshamanocha have you committed changes and pushed them to fork @sambuddhac made? The only changed file in this PR is environment.yml and it looks like the changes are from one of my commits.

Hey @gschivley,  I retried committing changes (now with changes to fuels_data.csv and time_series_mapping.csv). Are the new changes I've made visible now?

@aneeshamanocha Yes, I see the commits now. Is this an ASAP review type of thing? I'm also looking at #115 and doing some other work for the group.

No, not urgent at all. Just wanted to let you know that the updates for
genX modular are ready to go and the PR should be ready.
On Tue, Aug 17, 2021 at 4:13 PM Greg Schivley @.***>
wrote:

@aneeshamanocha https://github.com/aneeshamanocha Yes, I see the
commits now. Is this an ASAP review type of thing? I'm also looking at
#115 https://github.com/PowerGenome/PowerGenome/pull/115 and doing some
other work for the group.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerGenome/PowerGenome/pull/113#issuecomment-900598712,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHYF6VA2KEQLSTVJBMUVVZDT5K7FRANCNFSM5CCUHPTQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

@aneeshamanocha what is the purpose of post_processing.py? Is it supposed to be a script that is used to format inputs for the open-source GenX? All of the other changes seem pretty minor and should be easy to review.

Apologies, that script is for myself and my WECC study. Please feel free to
ignore that, it wasn't supposed to be pushed.
On Tue, Aug 24, 2021 at 3:28 PM Greg Schivley @.***>
wrote:

@aneeshamanocha https://github.com/aneeshamanocha what is the purpose
of post_processing.py? Is it supposed to be a script that is used to
format inputs for the open-source GenX? All of the other changes seem
pretty minor and should be easy to review.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerGenome/PowerGenome/pull/113#issuecomment-904914908,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHYF6VDC6NKFLLY7FHBPUBDT6PXFRANCNFSM5CCUHPTQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.


Feature/encrypt scrubber

Add a way to encrypt the rescue tarball with a public key
@JPWKU @timf

Aside from the decryption procedure that you mentioned is in the works ...  this LGTM.


Add HTTP error TC to processor tests

During the error TC, HTTP error 404 is being injected into every mock HTTP server's response

Coverage remained the same at 77.209% when pulling 4bdc264972ed29aa584d853e330cd59468f146bb on jmedved:contiv-crd into 3d21a5faa433cd97913df4ddc7ca160466a1ed49 on contiv:contiv-crd.


Thoughts around Rotonde

below are various disjointed thoughts on the rotonde project at the moment
part 1

abstract db access from the beginning

(making it easier to transition out of text into something else, should someone wish to)
simply done through wrapper functions: writeToDb(data) - doesn't need to be more complicated

point of focus is communication between nodes

how does it happen
when does it happen
through what means does it happen

discovery isn't important for us to write, use existing means

(social media, website postings, word of mouth)
(alternatively: discovery can occur on node-per-node basis,
you can see nodes that follow this node & are followed by this node)

minimalist, fast, scriptable

---extraneous thoughts---

echoing the early web with everybody creating custom, unique webpages
runnable as an app, in the terminal, as a server
explicitly lacking an authorization system

aim of this idea is to prevent centralization on one node

verifiability?

how do we prevent clone accounts, should we prevent clone accounts?
how do people know i am me, are there other simple mechanisms we can use for this end?
do we even have to write anything ourselves, do we have to care?

if you link your portal, page, profile from your website/social media it doesn't matter

part 2
i think we want to make something as small as possible and work within the
constraints we set ourselves, constraints based on what problems are hard for
us to solve with this tool - and just design around those problems
i think the best way to view all of these preliminary discussions, and whatever
things are in the rotonde repo before dec 1st, as exploring the topic,
generating ideas to find the best ones to run with when we start
i think it would be okay and good if people could browse the protocol, view
other nodes without having a domain or a server
i think offline instances should still be accessible, or rather their content
should still be viewable
i think at the moment there might be many different versions of rotonde
floating around

neauoire added the Fairly Sized Thoughts label 4 hours ago