Seamless-posting

All of the commits related to seamless-posting are now merged into a few, so you should be very comfortable to review changes.
This PR is different to #270 :

embeded is renamed to seamless-posting to avoid confusion, no more embeded now
refactored the new action and adapted the message App and plainpost App to it. Minimal changes were made to history/login/help Apps: I think they need rewrite.
generated HTML are not included, in order to keep the diff clean and easy to review
tests are not included currently

Merging commits is HORRIBLE:

If I forget to pick up something in a commit, then all works after that commit will be reverted, in order to insert the change into that commit.
I cannot compare automatically to see if I missed picking up something: file names are changed, variable names are changed.. a lot of things are changed. branch diff isn't smart enough to detect those changes. The diff result is junk.
SURPRISE! This branch seems to work!

Thanks for breaking things up. Do you generate test coverage with coveralls.io? First step is to make sure we aren't decreasing unit test coverage.

When I click outside the seamless posting form, the posting icon in the chrome context does not change color from green to red in all cases. This means the host page will be able to spoof the posting form. Further, a large proportion of the population is red/green colorblind, which makes people unable to differentiate the red icon from the green icon. I recommend changing the icon to:

green = the user's input will be captured by a chrome context page
gray = the user's content will not be captured by the chrome context page

When the seamless iframe is small (see case 3), the ability to set the expiration time gets truncated. I don't think we need so many options, how about only the three options 1, 7, and infinite.

You removed the context menu?

When posting a status update on FB, everything works as well as one could expect, but immediately after posting another seamless posting form gets injected into the status update box. I would guess you needed to do this to solve the strange behavior of FB's forms, but do you have an easy way to prevent this from happening?

There are numerous failing unit tests.

I just added documentations as comments.
I want to point out that, I refactored (part of) the architecture of a Privly App in this PR, which you may need to take a look especially.
For convenience, I just paste some documentations in the commit here, thus you can learn about the new architecture introduced in this PR:
/**
 * About the MVC architecture of the Privly application:
 *
 *   An interactive Privly application can be splitted into
 *   three parts: Model, View, Controller.
 *
 *   First of all, let's determine different use cases of a
 *   Privly app. Generally, a Privly app has three use cases:
 *
 *   1) show
 *      When the link is embedded into a host page, this
 *      application will be embedded to the host page to present
 *      the content of the link. This is the `show` case.
 *
 *   2) new
 *      When user clicks `new` button in a browser action button,
 *      or in a context menu, or in the Privly navigation bar, this
 *      application will be shown to user, allowing user to create
 *      such kind of content. In this case, it is `new`.
 *      About editing an existing content, it should be categorized
 *      to `new` case. However due to historical issue (?), it is
 *      now charged by the `show` case.
 *
 *   3) seamless
 *      We introduced a new method of creating content: seamless-
 *      posting. For `new` case, the users are creating content in
 *      a saparated, standalone window, and the content is created
 *      when users click 'Save' button. However in `seamless` case,
 *      the users are creating content seamlessly in the host page.
 *      Besides, the content is created once users enter `seamless`
 *      mode, and will be frequently updated or finally deleted.
 *      In short, in `seamless` case, the user is going to create
 *      the content using the Privly App, just inside the host page.
 *
 *   Now let's see what are the MVC of a Privly application.
 *
 *   VIEW LAYER
 *   ==========
 *
 *   The view layer is the user interface layer. Currently we have
 *   three view prototypes: show, new and seamless. Yes as you can
 *   see, these three view prototypes provide templates for the
 *   three use cases. We offer templates for App developers, to
 *   allow faster App development. However those templates are
 *   free to be inherited, extended or overridden so it is still
 *   flexable. For example, our `show` view prototype provides a
 *   textarea for users to input contents. However you can override
 *   that part of the template to allow users dragging image into
 *   it.
 *
 *   Notice that, if your App supports `seamless` view, it should
 *   also provides a `seamless_ttlselect` view, used to display
 *   seconds_until_burn menu for user. If you don't want to change
 *   menu styles, or change menu orders, using our default
 *   prototype is enough for your App.
 *
 *
 *   MODEL LAYER
 *   ===========
 *
 *   The model layer handles such basic tasks below:
 *
 *   - How should the user inputted content in the view layer be
 *     transformed into a Privly structured_content? This task is
 *     used in publishing or editing the content.
 *
 *     Example:
 *     For Plainpost App, no transformations.
 *     For Message App, the transformation is encryption.
 *     For Image App (not existed yet), the transformation is
 *     binary serialization and encryption.
 *
 *   - How should we transform a Privly structured_content to the
 *     content that the view layer can present? This task is just
 *     a reserve situation of the task above. It is used when user
 *     is going to see the content (`show` case).
 *
 *     For example, for Message App, the transformation is decryption
 *     according to the encryption key attached in the link.
 *
 *   - What are the `seconds_until_burn` options for this App? An
 *     app can assign its own seconds_until_burn (aka. TTL, Time
 *     To Live) option items.
 *
 *   Notice that the model part can provide other interfaces as well.
 *   Generally those interfaces are useful in the controller layer.
 *
 *   Also please notice that, generally all interfaces of the model
 *   layer should be async, by returning a Promise which will later
 *   be resolved. The async feature of a model doesn't have much
 *   effect in current Privly Application like Message and Plainpost,
 *   however it does offer developers more flexibility.
 *
 *
 *   CONTROLLER LAYER
 *   ================
 *
 *   Controller layer connects model layer and view layer. It can
 *   offer extra actions for every view layer events, for example,
 *   for a Message App, when a new link is created, we have to concat
 *   the encryption key after the link. Another example is, when
 *   we are presenting the content of a Message App, we should do a
 *   Markdown rendering. This task should also be completed by the
 *   controller layer.
 *
 *   In the Privly application, you needn't explicitly connects
 *   all interface between view and model. You can just pass the
 *   model to the view! The view will call related interface
 *   itself. For a controller, you only need to write initializing
 *   code and write event handlers if you want to change the
 *   default process of a prototype view.
 *
 * For Message App, the controller layer for each view is:
 *   new:       Message/js/new.js
 *   show:      Message/js/show.js
 *   seamless:  Markdown/js/seamless.js
 *   seamless_ttl: Markdown/js/seamless_ttl.js
 *
 */

How do you think of this new architecture?

As pointed out in the documentation, I think "editing a content" should be adapted to the new use-case (currently it is show), what's your idea?

Under the new architecture, I think we can introduce one more view prototype: standalone. This view is especially designed for login, options and history applications. They do not have a new process however they do need to present contents in a saparated and standalone window (tab) like a new process. Thus providing a more generic view prototype for those applications can make the structure better.
standalone: a kind of Application view that is rendered in a standalone tab
new: based on standalone, provides a basic textbox and publish button, for the New xxx action.
show: a kind of Application view that is presented when it is injected into the host page, or when user is directly accessing the link.
seamless: view of the seamless-posting environment.

I think the general outline of your changes is good, and it would help organize things that have been developing for a while. However, I am concerned about refactoring so much as we are coming up on the last phase of the summer timeline. Can you get (at least) the 70 percent code coverage we had previously on unit tests? Otherwise, I can't merge it. We can't backslide on test coverage.
If it is realistic to get to 90 percent coverage (with 70 percent as the minimum), then I will dive into your proposal and make suggestions as necessary.

When the seamless iframe is small (see case 3), the ability to set the expiration time gets truncated. I don't think we need so many options, how about only the three options 1, 7, and infinite.

I think a better solution is to move the menu into the top most iframe, just like embedded-posting does. However I need to find solutions to contact the top most iframe first. currently the message mechanism doesn't allow developer doing this.

You removed the context menu?

Yes, temporarily. This might require some architecture change so I postponed it. Before the end of summer it will be fixed

I ran this on TravisCI and there are a good number of failures, some of them are on Chrome. Here is your coverage data.

Sorry it's my fault. I changed run_each.sh to add essential dependency for testing seamlessPosting but forgot to commit it. I have pushed it now and there should be no errors when running unit test on Chrome.

Running again.

Coverage is currently 67.8, so coverage is still lower.
What is happening with these requests in the build:
WARN [web-server]: 404: /top-expect-404.css
WARN [web-server]: 404: /top-expect-404.js
WARN [web-server]: 404: /injected-expect-404.css
WARN [web-server]: 404: /injected-expect-404.js

They are here:
https://github.com/SummerWish/privly-applications/blob/seamless-posting/shared/test/meta_loader.js

Some issues with this coverage report..

Coverage of view adapters are not included, which will definitely make the coverage higher if it was included.
It seems that, the lower average coverage is caused by my simulation to the shared/javascripts/network_service.js interface in new test cases. Essentially speaking, we got a lower coverage because those part of the code are just not tested formerly. I removed dependencies of calling such kind of code in new test cases, which makes the coverage lower. I think this is not an testing issue introduced in this PR.

Regarding the editing of existing content, I think it would be more intuitive to have the show use case be distinct from the new use case. Instead of lumping the edit functionality into show, I suggest creating an extension of new called edit.  This way show, new, and edit each have a single responsibility.
It's a little more work right now, but it is a lot saner from a design standpoint and wouldn't require every future developer to learn or remember that editing is performed in show.

I don't think we should necessarily add additional view types immediately since the injected "show" endpoint is also the "edit" endpoint. There is going to be confusion regardless.

Could the edit/show issue be addressed by having multiple controllers for the single show view? Admittedly I don't have experience with MVC in the context of a web app, so I don't know if this is against best practices.

I think we can compare privly apps to the MVC design pattern, but we can't directly invoke it. Now that we know how everything can fit together among all the platforms, we could use a "design pattern" doc, but I think that is better to land at v2 and port the existing style first.

The MVC introduced in this PR is in fact a saparation of the model and the view. I was not intended to introduce MVC at the beginning, only wanted to extract a layer which does not involve with any DOM operations and any HTML status, only cares the foundation operations, and could be reuseable across different templates. After I completed extracting, I found that the new architecture is very similiar to the MVC pattern so I use MVC as a name here.

With Rails experience, calling it MVC is confusing, but naming things is hard. I'll see if I can come up with a better name. In the meantime, this is no reason to slow development. I will inwardly think of this as the "new hotness"

I think the core idea of MVC is the separation of operations(model) and user interfaces(view) and using controllers to connect them. After saparation, the presentation and data manipulating are no longer mixed together. What the controller is doesn't matter since as long as we defined model and view, we will know what's the controller. controller just connects them. There always should be something connects the two layers, that's the controller. In this way, common operations are reuseable since they are encapsuled.
This is a kind of design pattern, and as far as I know MVC design pattern matches it best because the role of each part just naturally matches it.. No intention, it just matches.

@irdan I think the story of abstract more is complex..
Currently the model is shared, but templates are not shared. We only need to write once to transform a user inputted content into a Privly json, that's good. But considering a new kind of application that takes images as contents. In the view layer we still need to handle image dragging upload in "edit" view and "seamless" view. Thus we still need to write twice, in order to handle "dragging".
The most ideal situation is, we not only share models, but also share templates. For a template, we only have three different kinds: edit, show and normal (which does not involves with data models, like login).
+ standalone (directly access)
  - view
  - edit
+ embedded (embedded access)
  - view (seamless)
  - edit (seamless)

I do not have a clear idea to achieve "template code" sharing currently, thus I only completed "model" sharing. Maybe when I start to implement the mixed-content Privly application I can figure out a way to share template.

In looking over the files changed, I think I need to see more organization enforcing the separation between model, view, and controller. In Rails these components are separated into different directories. Since we want the views to be at the root of the application's directory, the controllers and models will likely need to be in their own sub directories.
In the old version there was little inheritance, which made it easy to figure out how everything plugged together by viewing the files. I think with the changes you are introducing we need to add more documentation to priv.ly/develop that explains how each of these elements fit together.
One of the reasons I am resisting "MVC" as a label is I am am not clear on the separation between the model/view/controller. Much of the confusion is coming from my Rails programming experience, so many other devs will likely be similarly confused. Are your Model/View/Controllers all Javascript files? In Rails the view is in a templating language. However, since your controllers are not aware of the DOM they apply operations to, I don't see how the view can be in a templating language or in the HTML.

I don't know why you created the shared javascript. Can you add details to the file interview that indicate what you use the file for? It looks like some boilerplate code you use, but I don't know its purpose.

context_mesenger.js

Change line 245 to window.location.href.indexOf("chrome://" + window.location.host + "/privly-applications/") === 0
Does the content script forward PRIVLY_APPLICATION messages to the injected privly apps? If, I don't see where this happens. I don't believe anything uses this at the moment, but it would be good to know.
Coverage needs to improve. You are responsible for the Chrome coverage, while others are responsible for the Safari/Firefox/etc coverage. You will need to mock a few Chrome APIs for this to work.
Implementation looks solid.

glyph.js

This function needs coverage.
Is there a reason you implemented the canvas version of the glyph, aside from it being a more consistent display? It seems like we should deprecate the table version.

host_page_integration.js

Good.

local_storage.js

Good.

meta_loader.js

Good.

network_service.js

Good.
I think most of this code will be replaced by by "models" under your proposed changes? No need to change it for now.

options.js

Good/reviewed previously.

parameters.js

This needs coverage, but it is my responsibility.

storage.js

this should always return undefined for this to mirror the local storage API. The synchronous storage should mirror local storage as closely as possible.

tooltip.js

Coverage is bad, but I think this is my problem.

tests

update this and this. It is critical that we have strong tests for establishing trust in origins.
The tooltip.js suite needs updating, but this is my problem.
The adapters in shared/privly-web are currently not generating coverage information. The regular expression here needs updating. I can do this if you want.

Pages

What is this file? It needs a file overview and it should probably be in the test subdirectory of its current directory.
This needs a @fileOverview saying why it exists and what uses it. No exceptions.
Since I am not getting coverage information for options.js and it is found in runEach.sh, I think there is something wrong with the coverage data on non-shared JS.
Move this file into a testing directory and update its manifest for the build.

General Questions

What is the meaning of ttl? We might need to expand this since it is not immediately obvious.
Which files represent controllers, views, and models are not obvious. They need to be better separated, probably in their own directories.

General Comments
Things are looking very good. You refactored a ton of code and I don't have any huge issues, which is impressive. We just need to get it merged ASAP because the gsoc-develop branch is going to be changing underneath this. I'll review the Message and PlainPost app changes after it is clear where your model/view/controllers are.

event_emitter.js: I don't know why you created the shared javascript. Can you add details to the file interview that indicate what you use the file for? It looks like some boilerplate code you use, but I don't know its purpose.

For emitting events, it is used in Privly App models such as shared/javascripts/privly-web/new.js and shared/javascripts/privly-web/seamless.js. For samples of listening emitted events, see those Privly App controllers, such as Message/js/new.js, Message/js/seamless.js, etc.
Overwriting callback methods are now replaced by emitting events and listening events which could provide more flexibility and readability. For example, in new.js, developers can listen beforeXXX and returns true in the listener callback to disable calling the original function, or returns nothing to continue calling the original function.

glyph.js: Is there a reason you implemented the canvas version of the glyph, aside from it being a more consistent display? It seems like we should deprecate the table version.

It is originally used in embedded-posting, to switch the icon of modal_button (it accepts a data URI to use custom icons). However in seamless-posting, as long as we use a green-lock icon, this function is not used any more.
It's a good idea to replace DOM version glyph with canvas version glyph since we needn't CSS anymore.

context_mesenger.js: Coverage needs to improve.

OK I would improve this soon.

context_messenger.js: Does the content script forward PRIVLY_APPLICATION messages to the injected privly apps? If, I don't see where this happens. I don't believe anything uses this at the moment, but it would be good to know.

Yeah, it forwards messages to both top Privly applications and injected Privly applications. This is heavily used in seamless posting (and embedded-posting), for content scripts to communicate with Privly applications. Background script is a bridge between content script and injected Privly applications.
The reason for using context messenger instead of postMessage is that, context messenger can send messages across iframes. For example:
- TOP
  - A
    - B
      - C

content scripts in C may want to contact Privly applications in an iframe in TOP. In such situation, postMessage is complex.

What is the meaning of ttl? We might need to expand this since it is not immediately obvious.

It is Time-To-Live. TTL are widely used to represent time/seconds until deletion/removal/invalidate. I think it is an equivalent and more familiar name to seconds until burn (however it is less obvious). The meaning of TTL is explained in Message/js/messageApp.js:

What are the seconds_until_burn options for this App? An
app can assign its own seconds_until_burn (aka. TTL, Time
To Live) option items.

I use TTL as an acronym in codes, for example, TTLSelect, getTTLOptions, etc.

Hi, I have rearranged files to match the MVC architecture. Please have a check. You may need to review new changes at a per-commit basis.

You can ignore the Safari issue since that is an infrastructure problem, but there appears to be two small issues with the build found here.


Documentation about realtime shardSpecs

We don't seem to have documentation about shardSpecs, but we should. It should cover:

What shardSpecs are for (replication, scale-out)
How to choose which shardSpecs to use

Any plans for updating docs? From what I understand having shardSpecs defined is a must for multiple realtime nodes ingesting same datasource and Druid is for large data streams. I think it should be documented as soon as possible.

In fact only the requirement @swistakm mentions is documented (http://druid.io/docs/latest/Realtime-ingestion.html) but not any of the types and when you'd use which. I am working on adding some docs around this.

There's a pr for a sharding section for 0.6.x. One for 0.7.x coming up shortly to close this issue.

Fixed by #1042


npm registry 404

is this project ready to be used? i tried to install it but its not on the registry yet.
$ npm install eslint-plugin-bitburning --save-dev
npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/eslint-plugin-bitburning - Not found
npm ERR! 404
npm ERR! 404  'eslint-plugin-bitburning@*' is not in this registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)

I'll look into adding it after work today!
In the meantime you can clone it down and use it locally of course.
On Thu, Feb 3, 2022, 09:54  @.***> wrote:

is this project ready to be used? i tried to install it but its not on the
registry yet.
$ npm install eslint-plugin-bitburning --save-dev
npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/eslint-plugin-bitburning - Not found
npm ERR! 404
npm ERR! 404  'eslint-plugin-bitburning@*' is not in this registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
—
Reply to this email directly, view it on GitHub
https://github.com/paulcdejean/eslint-plugin-bitburning/issues/1, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAPFKJ5S32SUMY544E44UOTUZKQMTANCNFSM5NPKE2RQ
.
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&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Delete dead code

This function is not used

Did we replace this with something else? Just checking that it didn't accidentally fall off

no idea. maybe Tak knows. This is why i put it in a separate diff.

used in clients/web/lib/src/hooks/use-towns-client-listener.ts to let resume sync immediately when the app is brought to the foreground.

used in clients/web/lib/src/hooks/use-towns-client-listener.ts to let resume sync immediately when the app is brought to the foreground.

you are right. sorry i missed that.


Zenity implementation

Use zenity for message dialogs in xdg-desktop-portal backend.
Should unblock https://github.com/rerun-io/rerun/pull/1402

@teh-cmc tested this branch successfully (https://github.com/rerun-io/rerun/pull/1402#issuecomment-1455787882)


Module IDs which is on the left side (TL and BL) gets cut out

Wait a second, isn't it also being cut off when it's on the right side? It looks we need to fix both sides.

huh, i thought right side was fine as well


[WIP] Initial testing of private namespace

added sample (removed attribute names)
fixes #1157

Tests should fail. Still working out some things.


identity server 4 and facebook authorization

Hello,
I need to make backend API with multiple device support and built in identity server for authentication.
I have used local users with passwords and it works fine.
but when mobile clients submit facebook access token to api, I can't generate local access token,
because I don't have passwords for extenran users and can't use 'RequestResourceOwnerPasswordAsync'
method.
can you suggest me any valid solution? is it possible without cookies and how to do it?
thank you

You need to switch to an interactive flow.

This seems to be a general question about IdentityServer - not a bug report or an issue.
Please use StackOverflow for that. This has the advantage that questions and answers can be easily found by search engines, and that there are more people answering questions than just us.
For IdentityServer3
https://stackoverflow.com/questions/tagged/?tagnames=identityserver3&sort=newest
For IdentityServer4
https://stackoverflow.com/questions/tagged/?tagnames=identityserver4&sort=newest
For commercial support options - visit
https://identityserver.io


Extra-zipped files cause issues

Some files get zipped twice when they are archived. These files end up with file extensions such as ".gz.gz" or ".tgz.gz". This causes problems for other steps that want to download files from previous releases to do a comparison, and are not expecting the extra ".gz".
Current example: "diagram-converter" step tries to compare current output to prior output, but fails to download prior output file because it tries to download "diagrams-v75.tgz", but the file in S3 is known as "diagrams-v75.tgz.gz".
This also makes it less convenient to manually view log and data files.
My guess is that this is happening in the cleanUpAndArchiveBuildFiles function. It should be modified to only compress files that are not already compressed.

This seems to affect fireworks-layout as well.


UseDefaultCredentials not being set to false when Credentials supplied

issue is with ConfigureHttpClient method in WebDavClient.cs.
Consider the following code:
 _clientParams = new WebDavClientParams()
            {
                BaseAddress = new Uri(url),
                Credentials = new NetworkCredential() { UserName = "test", Password = "test" },
                UseDefaultCredentials = false
            };
using (var webDavClient = new WebDavClient(_clientParams))
            {
                var result = await webDavClient.Propfind(_fileToGet);
                if (result.IsSuccessful){}
                // continue ...
                else{}
                // handle an error

                return "";
            }

Even though i'm explicitly setting credentials, i must also set UseDefaultCredentials to false for it to auth correctly. If you update this code to remove UseDefaultCredentials=false, you'll get a 403 when trying to .Propfind
I have a branch with fix already, or make the following change to ConfigureHttpClient:
if (@params.Credentials != null)
            {
                httpHandler.Credentials = @params.Credentials;
                httpHandler.UseDefaultCredentials = false;
            }

This is also likely the cause of the other issue reported.

Hi @drbergeron,
I confirm the problem and think the proposed change makes sense.
I'll apply your fix and release a new version.
Thank you for bringing this up!


Fix possible problems when cross compiling

See https://github.com/conda-forge/staged-recipes/pull/26590#discussion_r1631341584

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender


Study stackblitz example from uuv Assistant

useless if uuv assistant uses electron

We choose vercel solution to deploy a demo version


Milliseconds Format String

The formatting section refers to the milliseconds portion as "F", but just going through this, I had to use a lowercase "f"

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

ID: eb41b02f-8fe9-44a1-544f-b6016f1ff4b3
Version Independent ID: 77358796-3ee2-9b86-7e0a-92c60ebc371a
Content: DateTime and DateTimeOffset support in System.Text.Json
Content Source: docs/standard/datetime/system-text-json-support.md
Product: dotnet
Technology: dotnet-standard
GitHub Login: @layomia
Microsoft Alias: laakinri

@CalvinAllen I think it's using "F" because that trims off any milliseconds that are 0. So it's based on the output you want really. I find it more common to omit a millisecond portion if it's 0. If you used "FFF" you would probably always get a millisecond result.
Console.WriteLine(date1.ToString("hh:mm:ss.f", ci));
// Displays 07:27:15.0
Console.WriteLine(date1.ToString("hh:mm:ss.F", ci));
// Displays 07:27:15
Console.WriteLine(date1.ToString("hh:mm:ss.ff", ci));
// Displays 07:27:15.01
Console.WriteLine(date1.ToString("hh:mm:ss.FF", ci));
// Displays 07:27:15.01

https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings#F_Specifier
I'm going to close this issue as I don't think there is anything to correct here 😄 Let me know if you feel otherwise! Cheers!


fix: prevent dynamic field overwrite when building dynamic row

See #399 for context
This should fix the non-deterministic behaviour of dynamic fields; however, the behaviour when the user provides a non-empty dynamic field should be discussed.

Thank you for the contribution, I have a better solution here.  can you help on review this.
https://github.com/milvus-io/milvus-sdk-node/pull/402


use package for data files in SC

@troibe adding the 'siliconcompiler' package in the init just ensures it's registered without the need for us to do it in tons of places once we can transition tools, etc to use them


First version of uninstall scripts

This is the first version of the Cloud Pak for Watson AIOps uninstall script and associated pieces.

Hi Ashish - I feel like we should expand the IAF acronym somewhere... I'm not sure if users will know what IAF is. I don't know if it's appropriate to do this in the README, or maybe just near the top of each file/script?
I think we should probably clean up some of the TODOs in here - if it's something we still plan to do, maybe we could open issues for them? Or if it's something we don't plan to do, we can just delete them? It might make some feel uneasy seeing all the TODOs in the code.

Removed the TODO comments and pushed in this PR


Unhandled Exception: DtlsException: DTLS Handshake has failed.

Bom dia again :-)
Not able to catch DtlsException: DTLS Handshake exception. Here the piece of code in dtls_client.dart
void _performShutdown(Exception exception) {
   final wasInHandshake = inHandshake;
   close();

   if (wasInHandshake) {
     _connectCompleter.completeError(exception);
   } else {
     throw exception;
   }
 }

In fact wasInHandshake in false but event in this situation it should completeError the exception to be able to catch it upwards

Hi! ;) Could you check in which state the connection is when the exception is thrown?

the state is ConnectionState.closed

Speaking of issues: Do you think this one is still relevant? Or has it been resolved by #75?

Hem don't really remember the case when it happened.
For now and with the intensive use of your work, did not see anything pointing to that. So hopefully closed by #75
If something pointing to that will appears in future, I will reopen it. But for now could be closed.

Great, thank you for your feedback :)


about the Resnet architecture

Hello there,
I am recently studying on your code, the outcome of the CNN oriented network is fansinating, but I am wondering if you could show me some clues about the ResNet architecture. Is there any reference? I am currently facing the problem of training loss non-convergence, and I don't know why. Could you please give me more details about your network architecture?

Hi, I didn't try the ResNet architecture. I stopped at the CNN network. So I'm afraid I can't provide much information.

Got it, thanks a lot for your reply~


Workflows are referencing vulnerable actions

Hello, there!
As part of the university research we are currently doing regarding the security of Github Actions, we noticed that one or many of the workflows that are part of this repository are referencing vulnerable versions of the third-party actions. As part of a disclosure process, we decided to open issues to notify GitHub Community.
Please note that there are could be some false positives in our methodology, thus not all of the open issues could be valid. If that is the case, please let us know, so that we can improve on our approach. You can contact me directly using an email: ikoishy [at] ncsu.edu
Thanks in advance

The workflow deploy.yml is referencing action gittools/actions/gitversion/setup using references v0.9.9. However this reference is missing the commit 90150b4 which may contain fix to the vulnerability.
The workflow deploy.yml is referencing action gittools/actions/gitversion/execute using references v0.9.9. However this reference is missing the commit 90150b4 which may contain fix to the vulnerability.

The vulnerability fix that is missing by actions' versions could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider updating the reference to the action.
If you end up updating the reference, please let us know. We need the stats for the paper :-)

@igibek - From this message we replaced the action.


Console number of stored lines

Hello, it would be great to have on option to choose the number of saved lines in the console.
The current number is not suitable for a long work on an analysis as older results get deleted in the output.
Thanks.

Doesn't this work for you?

(Can be found under Settings > Packages > julia-client)

My fault, I have overseen it and thought that the option was gone due to the new console. Works as expected.


Features/benchmarking task

Adds a benchmarking task (multiple choice).
Adds unit tests (900+)
Minor refactoring of some data structures such as REWARD_MODELS registry.
Adds new exception TaskCreationError which is raised if the generated text for a task does not meet acceptance criteria. I see this as a way of doing inline quality control (e.g. catching hallucinations based on heuristics).

I opted for few shot (system) prompting to get the the model to follow the required multiple choice formatting requirements. The reference answer is created during the query as one of the options and is marked with a *. Some examples (from the system prompt) are shown below.
Example 1
What is the capital of Texas?
A. Paris
B. London
*C. Austin
D. Houston
Example 2
Which of the following best describes the primary driving force behind protein folding?
A. Covalent bond formation between amino acids
*B. Hydrophobic interactions between nonpolar side chains
C. Hydrogen bonds between the protein backbone and side chains
D. Ionic interactions between charged side chains
Further information
Seems reasonably stable, and the subnet 1 miner scores indicate that it's decently difficult (bear in mind that they are VERY good at wiki RAG and so this is an open book exam for them). There's also a (simple) path to modulating the difficulty of this by adding a modifier to the generation prompt such as "ask an expert/basic question...".
I do not claim that this is a stable branch. It's just a demo, for now. We need to generate much more data and run a full eval pipeline on results to be sure it's high quality.
Example data: https://smooth-lamprey-680.notion.site/SAMPLE-f06c5b67f2f24e8c9d8514824f692960
Tracked experiment: https://wandb.ai/opentensor-dev/alpha-validators/runs/eeueemz8/overview

GPT-4 Eval Results
The quality of the benchmarking task was evaluated using GPT-4 (tracked experiment ...). I performed 5 evals on each sample, contradiction rates were small/negligible (see last plot).
The two types of evals are:

Whether the multiple choice question is 'good' (BUILTIN::1)
Whether the reference answer is correct (BUILTIN::4)

Conclusions
~90% of the benchmarking questions were good (scored 3+ out of max score 4) and around the same had reference answers that GPT agreed with.
Methodology
I used the following eval prompt:
DEFAULT_EVAL_SYSTEM_PROMPT =  """
You are an AI assistant which judges the quality of other LLM generations.

The user will provide you with a prompt and an LLM completion. Your task is to evaluate the quality of the completion given the user prompt. You can use the following scale: 1 - bad, 2 - ok, 3 - good, 4 - excellent. An excellent completion is one which follows the instruction perfectly. This means: it contains only the requested information and nothing more, it is coherent, convincing and well-written without any unrequested placeholders, tags or otherwise discursive and off topic language or content. Any completion containing artefacts such as system messages (e.g. "Sure, I can do that for you") should be penalized appropriately.

Do not provide any information other than the quality of the completion, expressed as a number between 1 and 4.
"""

Then I prompt gpt-4 to score each of the benchmarking tasks. it's not perfect -- I don't check whether the questions are of educational value for example, and i don't show the block of text that was the basis for the question (the context). These would improve the results, but in terms of the overall instruction following of the LLM (i.e. has it made a decent benchmarking task) the eval results suggest that the data is quite good.
Results

Contradiction Rates

Yeah @dbobrenko i agree that the way we parse the miner responses is currently the most brittle part of the design. I’m happy to choose a different approach for parsing. We could even return raw logits


The minimum required Python version for python-duckdb 1.0.0 may be incorrect

The documents for Python API shows that the minimum required Python version is 3.7.0
However, when I tried to install python-duckdb 1.0.0 in my Conda environment with Python 3.7.12, I encountered the following error:
The following packages are incompatible
├─ pin-1 is installable and it requires
│  └─ python 3.7.* , which can be installed;
└─ python-duckdb 1.0.0**  is not installable because there are no viable options
   ├─ python-duckdb 1.0.0 would require
   │  └─ python >=3.10,<3.11.0a0 , which conflicts with any installable versions previously reported;
   ├─ python-duckdb 1.0.0 would require
   │  └─ python >=3.11,<3.12.0a0 , which conflicts with any installable versions previously reported;
   ├─ python-duckdb 1.0.0 would require
   │  └─ python >=3.12,<3.13.0a0 , which conflicts with any installable versions previously reported;
   ├─ python-duckdb 1.0.0 would require
   │  └─ python >=3.8,<3.9.0a0 , which conflicts with any installable versions previously reported;
   └─ python-duckdb 1.0.0 would require
      └─ python >=3.9,<3.10.0a0 , which conflicts with any installable versions previously reported.

I used below command to install python-duckdb in my Conda enviroment.
conda install python-duckdb=1.0.0 -c conda-forge
So I think the minimum required Python version for python-duckdb 1.0.0 would  be 3.8.0 which should be noted in the document.

We don't maintain the feedstock, please raise an issue here instead: https://github.com/conda-forge/python-duckdb-feedstock


R2X working again

@borcuttjahns this compresses once and then calculates R2X at varying rank. By saving whatever you want after each Pf2 model is fit, you can look at how anything varies with rank.

Ok great! Let's merge this and then I'll add in functionality for factor match score?

Sounds good. Merging @borcuttjahns


access old field and new values in AfterUpdate

I'd like to perform an action when updating a column value (e.g., updating an external resource with the new value) and need access to both old and new values. Is there a way to accomplish this within gorm?
func (f *Foo) AfterUpdate(tx *gorm.DB) (err error) {
        oldValue := ??? // how to get this?
        newValue := f.Field
        return myapi.Something(oldValue, newValue)
}

gorm V2 just can get whether the column change or not，but how to get the old and new value？
thank you


Memory limits in standalone executors

Currently, standalone runners simultaneously run all received jobs at once, ignoring the runtime_memory parameter. This can cause activations to run out of memory if too many activations are run in parallel through a map call. The workers config setting can be used to limit the number of parallel activations started by a FunctionExecutor, but there are two drawbacks - it can't be dynamically changed for each function (unless you modify executor.config directly, which feels like a bad idea), and it doesn't prevent overallocation when multiple FunctionExecutors are running against the same VPC instance.
It would be nice if standalone executor's "proxy" server managed the number of incoming activations to prevent resource overload. Preventing memory overallocation is the most important, because OOMs cause activations to completely fail. It would also be nice if parallelism was limited so that there weren't more activations than CPU cores, because CPU contention can reduce throughput.
There are a couple related ideas I had around memory management in VPCs that may be worth considering:

Setting memory limits for each container in Docker so that the correct process is killed on OOM (instead of the kernel deciding which process to kill), and so that it's easier to find which function has its runtime_memory set too low.
Adding instructions for setting up a swapfile in IBM VPCs so that OOMs are less frequent. I followed these instructions to make a 32GB Ubuntu instance, but it seems the image has no swapfile by default.

I don't have an urgent need for this, but I have several upcoming use-cases that would benefit from it:

I would like to run multiple instances of our pipeline in parallel. This means there will frequently be requests from multiple executors to use the VPC runner at the same time. Fortunately everything will run from one process, so I can use a mutex as a workaround.
I would like to experiment with automatically determining the memory each function needs based on properties about its input data. When the task is greater than 4GB, it'd be most efficient if I could control whether the standalone executor runs e.g. 5x6GB activations, or 3x10GB activations in parallel. This would also benefit from declaring different memory requirements per activation, as these jobs can vary in size significantly.

@kpavel can you check this please?

@LachlanStuart I think we can achieve it by presenting a sliding window of active jobs inside the VPC with FIFO queue of jobs inside proxy.py. At naive approach, window size will be derived from the amount of memory initially available on the machine and expected job size specified by the executor.
Later, the algorithm can be improved to dynamically watching the currently available resources including CPU.
Regarding limiting docker container with max memory:  i think in most usecases, we would like all of the jobs to be completed successfully. Maybe better to maintain sliding window of the running jobs, which in case we detect failing job, instead of failing whole execution put this job back to queue and dynamically decrease the size of the window. Then rerun those that failed.

@LachlanStuart what do you think on the proposal from @kpavel ?

@kpavel The FIFO queue / sliding window approach sounds great, as long as I can control it per-job.

in case we detect failing job, instead of failing whole execution put this job back to queue and dynamically decrease the size of the window. Then rerun those that failed.

Were you thinking about implementing this in the in the Standalone proxy, or in the executor? If it's just for Standalone, I don't think this is needed - I haven't encountered a real-world case of unexpected OOMs (except for the "all jobs at once" issue) in Standalone as there's so much extra memory. However, if it was in the executor, where it would be shared with the Serverless code, then this would be AWESOME. I've had a lot of trouble with OOMs in Serverless, as the memory limits are much lower.

Regarding limiting docker container with max memory: I think in most usecases, we would like all of the jobs to be completed successfully.

That's a good point. I suggested this just so that behavior would be consistent between Serverless and Standalone so that it's easier to switch between them, but if it's possible for both to avoid OOMs with retry logic, that would be a much better approach.

@LachlanStuart if we run many executors from different clients, then we can't use executor to keep queue...unless we have some 3rd party external queue to maintain jobs... or keep it in proxy. I think we need queue only for VPC and in this case we can keep queue inside proxy.
regarding serverless, very soon we have production IBM Code Engine (it's beta now). Lithops supports it, so from your experience it's 0 change of the code, but IBM Code Engine supports up to 32GB of memory and no limit on time...so you will never hit OOM again with Code Engine

@kpavel ^^^

if we run many executors from different clients, then we can't use executor to keep queue...

@gilv I was only suggesting using the executor for the retry-after-OOM logic. I agree that it would be best to handle queueing and the sliding window in the proxy.

@sergii-mamedov FYI. Currently (2.5.0), Lithops already implements a job queue in the master/proxy VM, so if multiple Lithops instances submits jobs to the same VM, now they won't run at the same time, but one after another.

I think you can close this issue "as fixed"


Create MobileNet_V2 model “AttributeError”

Those two lines raise an error :
 from keras.applications.mobilenet_v2 import mobilenet_v2
base_model = mobilenet_v2.MobileNetV2(weights='imagenet', include_top=False)
I get the following error : AttributeError: 'NoneType' object has no attribute 'image_data_format' in
keras_applications\mobilenet_v2.py, line 282,

from keras.applications import MobileNetV2
m = MobileNetV2(weights='imagenet', include_top=False)

This works. It's weird that the imports that you are making are possible. But I think that we shoudn't consider this a bug if users stick to the documentation.

@gabrieldemarmiesse I tried the exact same code and I am getting the below error. I am on Windows 10, using Keras 2.2.2 with Python 3.6.
This is my code -
from keras.applications import MobileNetV2
model = MobileNetV2(weights='imagenet', include_top=False)
Error-
C:\Users\msurya\AppData\Local\Programs\Python\Python36\lib\site-packages\keras_applications\mobilenet_v2.py:310: UserWarning: MobileNet shape is undefined. Weights for input shape(224, 224) will be loaded.
warnings.warn('MobileNet shape is undefined.'
Traceback (most recent call last):
File "keras_mobilenetv2_info.py", line 7, in
model = MobileNetV2(weights='imagenet', include_top=False)
File "C:\Users\msurya\AppData\Local\Programs\Python\Python36\lib\site-packages\keras_applications\mobilenet_v2.py", line 355, in MobileNetV2
expansion=1, block_id=0)
File "C:\Users\msurya\AppData\Local\Programs\Python\Python36\lib\site-packages\keras_applications\mobilenet_v2.py", line 461, in _inverted_res_block
in_channels = inputs._keras_shape[-1]
AttributeError: 'Tensor' object has no attribute '_keras_shape'


Compilation id/hash

The repro feature is a useful way to provide everything needed to repeat a compilation. The -dump-repro-on-error option provides a slang-repro dump file when a compilation fails.
One problematic scenario is when compilation crashes. When this happens the code to dump out the repro is never hit and so no repro is produced.
One idea might be to dump all compilations. This could be achieved by first 'compiling' with code gen disabled. Dumping and then compiling again. This wouldn't work if prior to code gen the crash occurred, but in practice this isn't the common scenario. Then the last repro saved is presumably the one that failed. When compilation happens in parallel this complicates things, because the last compilation may not be the one that failed - so it would be necessary to check 'some' of the latest repros.
The idea here is before compiling being able to produce a hash and/or data (like say the equivalent command line) that uniquely identifies the compilation. If the crash occurs whilst the debugger is attached, a developer can look at the callstack and see what the hash is. They can then restart and have a check for the has before compilation. They could then do a 'no code gen' compile dumping the repro - and in doing so only have to deal with the compilation they care about.
You could also imagine using this mechanism outside of the developer environment. That if we can have a mechanism that can make available the hash of a failing compilation, we could have a command line (or other) option to dump the repro based just on the hash. The hash could also be useful for other scenarios - for example identifying something that is slow to compile, or produces warnings etc.
The difficulty here is how to make available to the user the hash of the failed compile. One straight forward way would be to serialize compilation, and just write out the hashes to a file or the console.
So how might an id/hash be produced? We could hash (in effect) the command line equivalent. If we were using the component system, some more thought might be needed to ensure a hash would be same every run. A hash/id in this scenario:

Can be local to a compilation environment - as it only identifies a compilation on a system
Doesn't need to include source - such as includes/imports
Must produce the same hash/id for each run

One significant issue would be compilations that inject code (say into includes/imports - that aren't seen on 'command line'). In that scenario two compilations - based on their command line parameters could look the same, even though because of the injection they produce different results, and are different compilations so should produce different hash/id.
One way to work around this perhaps would be to push this issue back on the application. That if it is going to inject code, it should produce a hash of all the injected source, and then (for example) define it in a macro that would go on the command line. This implies the injection isn't on demand, and can be known before a compilation.

This sounds really interesting and I do agree that there would be value in the compiler infrastructure being able to produce stable hashes that identify compilation requests.
My naive thought when it comes to the repro system, though, was along the lines of:

Every compile request gets dumped at multiple steps during its compilation (always to the same file), so any time a failure/crash occurs, the most recently dumped state will be in the file. If we use a zip-based container format and design things carefully there is the possibility of writing to the repro file in an append-only fashion (not re-writing data that was already dumped) to avoid the cost of repeated dumping.

When a compilation succeeds, the compiler would automatically erase the associated repro that was dumped, so that the only repros left on disk would be those that were in flight when the process crashed

Such an approach would seem to remove the need to a hash-based multi-pass approach, but maybe there is something naive in what I've described above.
We certainly want and need to start incorporating hashing into more of the compiler logic, since in the long run for things like shader caching we need a way to identify (1) whether the input arguments/configuration for a compile request match a previous request and (2) whether the current state of all the files touched by that request are exactly the same as they were for that previous request.
Naively, such an approach then uses multiple hashes linked together. The user submits a request for some compilation to occur, and the direct arguments to the request (1) get hashed and looked up in a cache. If there is a cache entry for that hash, it would include a list of all the files touched by that request last time it was performed, and their hashes at the time (2). Only on a match between both the (1) and (2) hashes would the compiled outputs for the cache entry be used.
This seems to be a case where it would help for Slang to enforce a more clear separation between the compilation "request" objects and the compilation "result" objects, with each ideally being more-or-less stateless, and a caching layer to map from one to the other. Right now our "request" objects often internally cache the relevant outputs, and that seems to complicate the logic of computing a good hash for them.

We added some caching/hashing. We think some of this might exist. Lets open for what still needs doing, but close this one so what we have is fresh.


Add better return info type rule

Codecov Report
Patch coverage: 97.05% and project coverage change: -1.52 :warning:

Comparison is base (942c6c9) 78.87% compared to head (b4d2302) 77.36%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #820      +/-   ##
==========================================
- Coverage   78.87%   77.36%   -1.52%
==========================================
  Files          18       18
  Lines        8120     8099      -21
==========================================
- Hits         6405     6266     -139
- Misses       1715     1833     +118

Impacted Files
Coverage Δ

src/compiler.jl
79.03% <97.05%> (-0.40%)
:arrow_down:

... and 9 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[mono] Fix Release-MONO configuration mappings in MSBuild.sln

Release-MONO configurations were incorrectly mapped to Release,
which breaks mono build.

This should be harmless, but I didn't try to load it in VS!


add truffle create:migration

Similar to create:contract and create:test but creates a new migration file with the following index number.

:+1: for this. Will go into a future release.


⚠ Bofrost.be has degraded performance

In 751cbf9, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2566 ms

Resolved: Bofrost.be performance has improved in d90ae28.


Response with "alternate" sub status breaks validation

As described in #1, ZBValidateSubStatus is missing new sub statuses, which breaks validation when one of them is included in ZeroBounce response:
Unhandled exception
Traceback (most recent call last):
  File "/opt/app/.venv/lib/python3.11/site-packages/zerobouncesdk/zerobouncesdk.py", line 271, in __request
    response_object = response_class(response)
                      ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/app/.venv/lib/python3.11/site-packages/zerobouncesdk/zb_validate_response.py", line 75, in __init__
    self.sub_status = None if self.sub_status is None else ZBValidateSubStatus(self.sub_status)
                                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/enum.py", line 715, in __call__
    return cls.__new__(cls, value)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/enum.py", line 1131, in __new__
    raise ve_exc
ValueError: 'alternate' is not a valid ZBValidateSubStatus

#1 should fix this kind of error by adding missing definitions. Could you check that out?
Thanks,
Alessio

Hello @pomma89,
The new release handles this problem.

Thank you 👍


error in mc_esm_gearnet

Howdy, thank u for ur awesome work in Enhancing Protein Language Models with Structure-based Encoder and Pre-training. I am running the pretaining experiment now, and I am facing an issue of "Can't find atom_feature in features.atom". I paste the error statement below.

It seems like it cannot recognize the atom_feature: null or bond_feature: null. Do I need to change the source code for implementing these two arguments?
Any help will be grateful!

Hello, thanks for your response. I checked the atom_feature in the config, and it prints None

I also had one question in lazy mode, lazy mode is to load pdb file each time we call get_item function, however, the init will set up the self.data by loading the pickle file, so proteins have already existed in our dataset and taken some CPU memory.

This is weird. Have you faced the same issue when pre-training with GearNet-Edge instead of ESM-GearNet? Could you share the full log file with me?
I'm sorry that I haven't considered the lazy mode for CPU. Typically, we assume there is no .pkl file when using lazy mode. So maybe you can try to remove the .pkl file and the lazy mode should work.


updated to ChatGPT API 4 that uses OpenAI's API

Yes! Let's use API Keys instead 👍

@josephvtesta Thanks for the PR!

@josephvtesta Thanks for the PR!

Absolutely! Thanks for putting this together in the first place.


pnpm i: WARN  Issues with peer dependencies found

I have some issues with pnpm run dashboard:start (see https://github.com/platformatic/platformatic/issues/228), so I have tried to clean my local installation executing some commands as documented in CONTRIBUTING.md:
pnpm run cleanall
pnpm i

but at the end I have got some warnings:
"WARN  Issues with peer dependencies found"
Below the full output:
ricfio@LENOVO:~/projects/platformatic/platformatic$ pnpm run cleanall

><EMAIL_ADDRESS>cleanall /home/ricfio/projects/platformatic/platformatic
> rm pnpm-lock.yaml && rm -rf node_modules && rm -rf packages/*/node_modules

ricfio@LENOVO:~/projects/platformatic/platformatic$ pnpm i
Scope: all 13 workspace projects
packages/db-dashboard                    |  WARN  deprecated<EMAIL_ADDRESS>Packages: +978
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Packages are hard linked from the content-addressable store to the virtual store.
  Content-addressable store is at: /home/ricfio/.local/share/pnpm/store/v3
  Virtual store is at:             node_modules/.pnpm
Progress: resolved 999, reused 977, downloaded 0, added 978, done
. postinstall$ node ./scripts/postinstall.js
[32 lines collapsed]
│ build/assets/forEachState.es.2bb545d4.js      0.22 KiB / gzip: 0.20 KiB
│ build/assets/jump.es.ae3b5de5.js              2.88 KiB / gzip: 1.21 KiB
│ build/assets/mode.es.9fd5aa43.js              0.77 KiB / gzip: 0.51 KiB
│ build/assets/hint.es2.f63e46dc.js             3.06 KiB / gzip: 1.35 KiB
│ build/assets/lint.es2.183e4ef4.js             4.59 KiB / gzip: 2.05 KiB
│ build/assets/mode.es3.11ee0649.js             1.71 KiB / gzip: 0.91 KiB
│ build/assets/mode.es2.9565f44c.js             1.59 KiB / gzip: 0.84 KiB
│ build/assets/codemirror.es.3479d3c3.js        179.60 KiB / gzip: 60.84 KiB
│ build/assets/index.95357877.css               775.49 KiB / gzip: 323.90 KiB
│ build/assets/index.e377d3c1.js                2592.52 KiB / gzip: 772.87 KiB
└─ Done in 27.4s

dependencies:
+ desm 1.3.0

devDependencies:
+ @fastify/pre-commit 2.0.2

 WARN  Issues with peer dependencies found
packages/db-dashboard
├─┬ graphiql 2.0.10
│ └─┬ @graphiql/react 0.13.4
│   ├─┬ @reach/combobox 0.17.0
│   │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ ├─┬ @reach/auto-id 0.17.0
│   │ │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ │ └─┬ @reach/utils 0.17.0
│   │ │   ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ │   └── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ ├─┬ @reach/descendants 0.17.0
│   │ │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ │ └── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ └─┬ @reach/popover 0.17.0
│   │   ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │   ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │   ├─┬ @reach/portal 0.17.0
│   │   │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │   │ └── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │   └─┬ @reach/rect 0.17.0
│   │     ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │     └── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   ├─┬ @reach/dialog 0.17.0
│   │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ └── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   ├─┬ @reach/listbox 0.17.0
│   │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ └─┬ @reach/machine 0.17.0
│   │   ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │   └── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   ├─┬ @reach/menu-button 0.17.0
│   │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │ └─┬ @reach/dropdown 0.17.0
│   │   ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   │   └── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│   └─┬ @reach/tooltip 0.17.0
│     ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│     ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│     └─┬ @reach/visually-hidden 0.17.0
│       ├── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
│       └── ✕ unmet peer<EMAIL_ADDRESS>|| 17.x": found 18.2.0
└─┬ swagger-ui-react 4.13.0
  ├─┬ react-copy-to-clipboard 5.0.4
  │ └── ✕ unmet peer<EMAIL_ADDRESS>|| ^16.0.0 || ^17.0.0": found 18.2.0
  ├─┬ react-debounce-input 3.2.4
  │ └── ✕ unmet peer<EMAIL_ADDRESS>|| ^16.0.0 || ^17.0.0": found 18.2.0
  └─┬ react-inspector 5.1.1
    └── ✕ unmet peer<EMAIL_ADDRESS>|| ^17.0.0": found 18.2.0

Done in 47.9s

This issue occurs after removing of pnpm-lock.yaml file with:
pnpm run cleanall
So can be solved executing:
git restore pnpm-lock.yaml
PS
Is it a good idea remove pnpm-lock.yaml with pnpm run cleanall?

I still have this problem, but I also seen that with a second execution of pnpm i I have no warnings
... however I think that the last behaviour could be due to caching.

Everything works, don't worry too much about this.

I think this issue has been solved, so could be closed.

thx!


🚀 The feature, motivation and pitch
Does vllm have transformers VisionEncoderDecoderModel? We need to do image content recognition
Alternatives
No response
Additional context
No response
Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

No. Encoder-decoder architecture is currently limited to language-only models. We have plans to support it soon since Llama 3.1 uses it.

Sorry, I seem to have misunderstood this model previously. It looks like this model is designed for generic multimodal encoder with generic language decoder, so it should be possible to implement in vLLM now. However, both encoder and decoder components need to be implemented in vLLM first, so it's not nearly as flexible as in transformers.


improve test stability

backport of https://github.com/droolsjbpm/jbpm/pull/368 for 6.3.x

jenkins retest this

Test org.jbpm.test.regression.ParallelAsyncJobsTest.testRunBasicAsync failed three times in a row. I am not sure if it was failing before these changes, but currently it seems that the fails are not intermittent, but rather permanent.

It might be due to an issue after merge as there were some conflicts and I might not cover all things properly. Will look into it
Dnia 19.12.2015 o godz. 12:39 Petr Široký<EMAIL_ADDRESS>napisał(a):

Test org.jbpm.test.regression.ParallelAsyncJobsTest.testRunBasicAsync failed three times in a row. I am not sure if it was failing before these changes, but currently it seems that the fails are not intermittent, but rather permanent.
—
Reply to this email directly or view it on GitHub.

@psiroky I am really lost here... it's certainly something weird going on here... and just noticed that this test was not modified as part of this change.
It clearly checks if there are multiple executor threads running but regardless of what I use to configure it does still use just single thread:
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbpm-pullrequests/87/testReport/org.jbpm.test.regression/ParallelAsyncJobsTest/testRunBasicAsync/
could you let me know how the build works as it seems it might be related to it. Especially parallel builds - are they in separate forked jams or share the same instance?

just noticed it does fail constantly on 6.3.x so not related to this pr ... anyway will try to do some digging why it it's failing on 6.3.x and not on master

@psiroky after 3 days of fighting I decided to ignore this test on 6.3.x. It does work well locally even with exact same maven goals and parameters as on jenkins. Tried that many times. So there is no issue with functionality itself.
I opt at merging this in so we have more stable builds and try to find some time later on to look at this test.
Any objections?

merged into 6.3.x


Issues syncing headers in NavCoin 4.7 core wallet - Win10

Issues syncing blocks in NavCoin 4.7 core wallet. I've left this now for days, since the 3rd of October. Restarting computer doesn't help either. Win10.
Tried a wallet repair no dice.
Downloading the block chain bootstrap file now to try a manual bootstrap (that option is missing under File --> Bootstrap in 4.7).
Wallet sits on this screen, the highlighted block thing changes every now and then, but it never ever finishes:

Error logs are full of this:
2019-10-11 08:39:18 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: b64f26ccf976bcf479b560e0480d5fdfc0d0620521823cf60b1f7bb3524a8d97, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:39:18 ERROR: invalid header received
2019-10-11 08:39:18 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: b64f26ccf976bcf479b560e0480d5fdfc0d0620521823cf60b1f7bb3524a8d97, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:39:18 ERROR: invalid header received
2019-10-11 08:39:18 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: b64f26ccf976bcf479b560e0480d5fdfc0d0620521823cf60b1f7bb3524a8d97, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:39:18 ERROR: invalid header received
2019-10-11 08:39:18 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: b64f26ccf976bcf479b560e0480d5fdfc0d0620521823cf60b1f7bb3524a8d97, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:39:18 ERROR: invalid header received
2019-10-11 08:39:18 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: b64f26ccf976bcf479b560e0480d5fdfc0d0620521823cf60b1f7bb3524a8d97, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:39:18 ERROR: invalid header received
2019-10-11 08:39:28 ERROR: Could not parse price data json 'boost::property_tree::json_parser::json_parser_error'
2019-10-11 08:40:54 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 0d40d1223fcd0d3907d35177144a9ee1eda3c976bdc1eade7bbba08a71d14aad, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:40:54 ERROR: invalid header received
2019-10-11 08:40:54 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 0d40d1223fcd0d3907d35177144a9ee1eda3c976bdc1eade7bbba08a71d14aad, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:40:54 ERROR: invalid header received
2019-10-11 08:44:28 ERROR: Could not parse price data json 'boost::property_tree::json_parser::json_parser_error'
2019-10-11 08:44:38 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: dec6276255a210d6bbb8c9539718d8c3f55bb478cc62e1a48cb441253a0013dc, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:44:38 ERROR: invalid header received
2019-10-11 08:44:38 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: dec6276255a210d6bbb8c9539718d8c3f55bb478cc62e1a48cb441253a0013dc, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:44:38 ERROR: invalid header received
2019-10-11 08:44:38 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: dec6276255a210d6bbb8c9539718d8c3f55bb478cc62e1a48cb441253a0013dc, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:44:38 ERROR: invalid header received
2019-10-11 08:44:38 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: dec6276255a210d6bbb8c9539718d8c3f55bb478cc62e1a48cb441253a0013dc, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:44:38 ERROR: invalid header received
2019-10-11 08:44:38 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: dec6276255a210d6bbb8c9539718d8c3f55bb478cc62e1a48cb441253a0013dc, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:44:38 ERROR: invalid header received
2019-10-11 08:49:28 ERROR: Could not parse price data json 'boost::property_tree::json_parser::json_parser_error'
2019-10-11 08:52:22 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 56dccf3ba334525537592b7c46917cf3f2d41629da4a7878a7a8aea6d42e11cb, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:52:22 ERROR: invalid header received
2019-10-11 08:52:22 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 56dccf3ba334525537592b7c46917cf3f2d41629da4a7878a7a8aea6d42e11cb, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:52:22 ERROR: invalid header received
2019-10-11 08:52:22 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 56dccf3ba334525537592b7c46917cf3f2d41629da4a7878a7a8aea6d42e11cb, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:52:22 ERROR: invalid header received
2019-10-11 08:52:22 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 56dccf3ba334525537592b7c46917cf3f2d41629da4a7878a7a8aea6d42e11cb, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:52:22 ERROR: invalid header received
2019-10-11 08:52:22 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 56dccf3ba334525537592b7c46917cf3f2d41629da4a7878a7a8aea6d42e11cb, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:52:22 ERROR: invalid header received
2019-10-11 08:52:22 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 56dccf3ba334525537592b7c46917cf3f2d41629da4a7878a7a8aea6d42e11cb, time-too-new, block timestamp too far in the future (code 16)
2019-10-11 08:52:22 ERROR: invalid header received
2019-10-11 08:54:28 ERROR: Could not parse price data json 'boost::property_tree::json_parser::json_parser_error'
Debug logs (ignore date difference the logs continue for days as stated, all the same):
f9c10cbd983b33c3f9b263c75e2bc85d2d9941ebc70ec54, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:24:53 ERROR: invalid header received
2019-10-07 13:24:53 ProcessMessages(headers, 83 bytes) FAILED peer=8
2019-10-07 13:24:53 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 2a6176df9513adc0bf9c10cbd983b33c3f9b263c75e2bc85d2d9941ebc70ec54, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:24:53 ERROR: invalid header received
2019-10-07 13:24:53 ProcessMessages(headers, 83 bytes) FAILED peer=9
2019-10-07 13:24:53 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 2a6176df9513adc0bf9c10cbd983b33c3f9b263c75e2bc85d2d9941ebc70ec54, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:24:53 ERROR: invalid header received
2019-10-07 13:24:53 ProcessMessages(headers, 83 bytes) FAILED peer=5
2019-10-07 13:24:54 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 2a6176df9513adc0bf9c10cbd983b33c3f9b263c75e2bc85d2d9941ebc70ec54, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:24:54 ERROR: invalid header received
2019-10-07 13:24:54 ProcessMessages(headers, 83 bytes) FAILED peer=4
2019-10-07 13:25:58 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: bc2619a5b8d190de54f574032e6b79d3ea86c18e929f76ab20baa4ee7d78c361, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:25:58 ERROR: invalid header received
2019-10-07 13:25:58 ProcessMessages(headers, 165 bytes) FAILED peer=6
2019-10-07 13:25:58 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: bc2619a5b8d190de54f574032e6b79d3ea86c18e929f76ab20baa4ee7d78c361, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:25:58 ERROR: invalid header received
2019-10-07 13:25:58 ProcessMessages(headers, 83 bytes) FAILED peer=7
2019-10-07 13:25:58 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: bc2619a5b8d190de54f574032e6b79d3ea86c18e929f76ab20baa4ee7d78c361, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:25:58 ERROR: invalid header received
2019-10-07 13:25:58 ProcessMessages(headers, 165 bytes) FAILED peer=8
2019-10-07 13:25:58 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: bc2619a5b8d190de54f574032e6b79d3ea86c18e929f76ab20baa4ee7d78c361, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:25:58 ERROR: invalid header received
2019-10-07 13:25:58 ProcessMessages(headers, 165 bytes) FAILED peer=3
2019-10-07 13:25:58 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: bc2619a5b8d190de54f574032e6b79d3ea86c18e929f76ab20baa4ee7d78c361, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:25:58 ERROR: invalid header received
2019-10-07 13:25:58 ProcessMessages(headers, 165 bytes) FAILED peer=1
2019-10-07 13:25:58 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: bc2619a5b8d190de54f574032e6b79d3ea86c18e929f76ab20baa4ee7d78c361, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:25:58 ERROR: invalid header received
2019-10-07 13:25:58 ProcessMessages(headers, 165 bytes) FAILED peer=9
2019-10-07 13:25:58 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: bc2619a5b8d190de54f574032e6b79d3ea86c18e929f76ab20baa4ee7d78c361, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:25:58 ERROR: invalid header received
2019-10-07 13:25:58 ProcessMessages(headers, 165 bytes) FAILED peer=5
2019-10-07 13:25:58 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: bc2619a5b8d190de54f574032e6b79d3ea86c18e929f76ab20baa4ee7d78c361, time-too-new, block timestamp too far in the future (code 16)
2019-10-07 13:25:58 ERROR: invalid header received
2019-10-07 13:25:58 ProcessMessages(headers, 83 bytes) FAILED peer=4

I've done the manual bootstrap thing (should I open another issue for the fact that has gone missing from the File menu in this 4.7 wallet?). It is downloading stuff... no longer spamming logs with that timestamp too far in the future message.
Will leave it for the next hour or two and see what happens when it gets to the 98% mark again if it stalls like it has been or of it fixes the issue.

what is your best block hash?

Timestamps too far in the future I think is cause by wrong system time. But
the wallet should have used NTP sync.
So I'm not sure what could have happened with that.
On Fri, Oct 11, 2019, 17:39 alex v<EMAIL_ADDRESS>wrote:

what is your best block hash?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/navcoin/navcoin-core/issues/610?email_source=notifications&email_token=AAIDAKKDTDAMSE6XZOORX2LQOBCW5A5CNFSM4I7XBJ62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA7OXAA#issuecomment-540994432,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIDAKO4POBV7RA4EHVTCO3QOBCW5ANCNFSM4I7XBJ6Q
.

I would look in the log for reasons for rejecting the header/block next to his tip.

Can you upload the debug.log? Or email it to alex?
Also, no you don't need to report the missing bootstrap menu, that was
removed to encourage full syncs.
On Fri, Oct 11, 2019, 17:56 alex v<EMAIL_ADDRESS>wrote:

I would look in the log for reasons for rejecting the header/block next to
his tip.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/navcoin/navcoin-core/issues/610?email_source=notifications&email_token=AAIDAKMKXEVKQJHZ6K57ZMLQOBEV3A5CNFSM4I7XBJ62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA7QC7Q#issuecomment-541000062,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIDAKLVUEW2JS7IDBZY3I3QOBEV3ANCNFSM4I7XBJ6Q
.

Thanks for the replies, the manual bootstrap seems to have fixed it. Very odd.
I did think about system time but that's spot on, synced already. Can close, I guess anyone else with the issue just needs to follow the manual bootstrap process here:
https://info.navcoin.org/navcoin-core/bootstrap-your-wallet/


Implement array_to_string

We need a function similar to Postgres' array_to_string (http://www.postgresql.org/docs/9.1/static/functions-array.html)
@martint @electrum any preferences on the name?

@cberner want to claim this one if no one is looking at it.

No one that I know of :)

@electrum @martint  What do we want array_to_string([1,null,2], '-', null) to return? Is it 1-null-2 OR 1--2?

@cberner an initial version is ready for review.


Fixing version check to handle case without channel or date (ie 0.11.1)

looks like I got another change in this same PR by accident

Ok thanks... funny bug this given the amount of complexity everywhere else, sods law :)
The uploader status to NS stuff is a bit prototypey at the moment and needs a bit more consideration due to many users using multiple uploaders etc. Also the battery charge status notification should default off as there may be issues for some devices that go in and out of 100% all the time while charging and there may be other unknown inconsistencies between android version and brands. I'm also wary of settings overload for users and need to consider these parts too.

Ok I defaulted the System Status messages back off again. I was thinking there could be a setting for each one of those messages and the critical battery low message might be default on?

Added the Uploader USB Errors configuration option and cleaned up the Nighscout advanced preferences :)

I can merge this as is and sure see how it feels. Don't know about moving that TTL item as it's tightly related to keeping alerts/status noise in NS minimal and hopefully a user senses that relationship. But hey-ho it can be adjusted.


use of logger.exception/update exception blocks

          can also do logger.exception

Originally posted by @bbelderbos in https://github.com/BenGriffith/tollway-traffic-cloud-functions/pull/13#discussion_r1569025129


performance with elements inside the video player

Hi, I have a problem with my project.
I'm using the exoplayer engine
PlayerFactory.setPlayManager(Exo2PlayerManager.class)
to play M3U8 hls live.
I have problems playing 1080p videos with android boxes
it happens that when I leave only the GSY player in a blank activity it runs fine, I'm using the Emptyvideo class
now inside an activity where I have
a tablayout inside Emptyvideo and a centralized recycleview
also inside EmptyVideo I get crashes only in 1080p.
is there any way of using Recycleview on top of the videoplayer element?
i auto hide with setAlpha after 6 seconds

I'm not sure what's wrong in your case  , could you provider crash log ?


Please provide rabbitmq.config example of custom configuration

The documentation has a section on configuring the plugin https://github.com/deadtrickster/prometheus_rabbitmq_exporter#configuration
My goal is to configure the plugin to use the rabbitmq node name as the "instance" label, as you hinted in https://github.com/deadtrickster/prometheus_rabbitmq_exporter/issues/23#issuecomment-293649057
From what I understand, we have to configure the rabbitmq_exporter options through the environment of the prometheus application. To configure a custom metrics path I expect to be able to do this:
[
        { rabbit, [
                { loopback_users, [ ] },
                { tcp_listeners, [ 5672 ] },
                { ssl_listeners, [ ] },
                { hipe_compile, false }
        ] },
        { rabbitmq_management, [ { listener, [
                { port, 15672 },
                { ssl, false }
        ] } ] },
        { prometheus, [ { rabbitmq_exporter, [
                { path, "/mymetrics" }
        ] } ] }
].

If I save the above config as "rabbitmq.config" then run:
 docker run --rm -ti -p 15672:15672 -v $PWD/rabbitmq.config:/etc/rabbitmq/rabbitmq.config:ro deadtrickster/rabbitmq_prometheus:<IP_ADDRESS>

Then rabbitmq crashes with the following message:
=CRASH REPORT==== 13-Apr-2017::08:19:05 ===
  crasher:
    initial call: application_master:init/4
    pid: <0.438.0>
    registered_name: []
    exception exit: {bad_return,
                     {{rabbit_mgmt_app,start,[normal,[]]},
                      {'EXIT',
                       {badarg,
                        [{ets,insert,
                          [prometheus_registry_table,
                           {default,prometheus_summary}],
                          []},
                         {prometheus_registry,register_collector,2,
                          [{file,"src/prometheus_registry.erl"},{line,99}]},
                         {prometheus_metric,insert_mf,3,
                          [{file,"src/prometheus_metric.erl"},{line,101}]},
                         {prometheus_http,setup,0,
                          [{file,"src/prometheus_http.erl"},{line,53}]},
                         {prometheus_rabbitmq_exporter,dispatcher,0,
                          [{file,"src/prometheus_rabbitmq_exporter.erl"},
                           {line,11}]},
                         {rabbit_mgmt_dispatcher,
                          '-build_dispatcher/1-lc$^2/1-2-',1,
                          [{file,"src/rabbit_mgmt_dispatcher.erl"},{line,32}]},
                         {rabbit_mgmt_dispatcher,
                          '-build_dispatcher/1-lc$^2/1-2-',1,
                          [{file,"src/rabbit_mgmt_dispatcher.erl"},{line,33}]},
                         {rabbit_mgmt_dispatcher,build_dispatcher,1,
                          [{file,"src/rabbit_mgmt_dispatcher.erl"},
                           {line,32}]}]}}}}
      in function  application_master:init/4 (application_master.erl, line 134)
    ancestors: [<0.437.0>]
    messages: [{'EXIT',<0.439.0>,normal}]
    links: [<0.437.0>,<0.31.0>]
    dictionary: []
    trap_exit: true
    status: running
    heap_size: 1598
    stack_size: 27
    reductions: 170
  neighbours:

What did I do wrong?

You did nothing wrong. It's just the order of config entries what matters. Try place prometheus before rabbitmq_management.

You are right @deadtrickster , let me prepare a PR to include this information in the README.md


Ignore "future" criteria in % calculations, instead of being enough

This will help implement issue #265, because the current method of calculation might mislead some people.

This is done on the server side.  Next up, client side.


Update zio, zio-test, zio-test-sbt to 2.0.2

Updates

dev.zio:zio
dev.zio:zio-test
dev.zio:zio-test-sbt

from 1.0.16 to 2.0.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "dev.zio" }
}]

labels: library-update, early-semver-major, semver-spec-major, commit-count:1

This PR can be the basis for, or else requires, closing #2032

As noted on https://github.com/informalsystems/apalache/issues/2032, we have some dependencies which are not yet stabilized on ZIO2. So we'll hold off on this update for a while yet.


ccmlib/scylla_node: _start_scylla: fix expected bootstrap message

Current message introduced in #225 is not always printed.
For example, in:
https://jenkins.scylladb.com/view/master/job/scylla-master/job/dtest-debug-random/90/artifact/logs-debug.2/1584197488046_replace_address_test.TestReplaceAddress.replace_shutdown_node_test/node4.log
JOINING: Starting to bootstrap is always printed by storage_service::bootstrap
so use it instead.
Signed-off-by: Benny Halevy<EMAIL_ADDRESS>

@fruch please review


[Bug] Unexpectedly removing resources even though the App has re-registered shuffle later.

Code of Conduct

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

Search before asking

[X] I have searched in the issues and found no similar issues.

Describe the bug
Suppose in such a scenario, App is expired due to no heartbeat, so it was added to expired queue and will be removed resources soon. Also At this moment, this app re-registers shuffle. But after re-registering shuffle, the app was removed resources. The following requireBuffer will appear NO_REGISTERED...
Affects Version(s)
master
Uniffle Server Log Output
No response
Uniffle Engine Log Output
No response
Uniffle Server Configurations
No response
Uniffle Engine Configurations
No response
Additional context
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Once the app is marked as unregistered, I think it's acceptable to reject. WDYT? @zhuyaogai

@zuston hi, I don't think so. Let's assume this scenario, there are multi stages(DAGs) in an application. If stage1 requires ShuffleServer1, but stage2 does not require ShuffleServer1, so the resources of ShuffleServer1 will be released after stage1 ends. Due to no heartbeat, ShuffleServer1 will add the application to the expired queue and wait for the resources to be released, but ShuffleServer1 was required again in stage3, then some unexpected problems will occur. But we know that the application is still in progress.

The heartbeat of app with one shuffle-server also will happen in spark driver side.

@zuston If we remove resources after per stage, we use ShuffleWriteClientImpl#unregisterShuffle method which will finally remove related shuffle server.
https://github.com/apache/incubator-uniffle/blob/b4adaa50b7474330ed7723bba3976e090b8bd022/client/src/main/java/org/apache/uniffle/client/impl/ShuffleWriteClientImpl.java#L994
So there is no heartbeat anymore.

@zuston If we remove resources after per stage, we use ShuffleWriteClientImpl#unregisterShuffle method which will finally remove related shuffle servers.
https://github.com/apache/incubator-uniffle/blob/b4adaa50b7474330ed7723bba3976e090b8bd022/client/src/main/java/org/apache/uniffle/client/impl/ShuffleWriteClientImpl.java#L994
So there is no heartbeat anymore.

I think this is right, if the operation of unregister is triggered by spark, it means the data will not be used in the future, the removal is right. Feel free to tell me if I'm wrong.

@zuston hi, I don't think so. Let's assume this scenario, there are multi stages(DAGs) in an application. If stage1 requires ShuffleServer1, but stage2 does not require ShuffleServer1, so the resources of ShuffleServer1 will be released after stage1 ends. Due to no heartbeat, ShuffleServer1 will add the application to the expired queue and wait for the resources to be released, but ShuffleServer1 was required again in stage3, then some unexpected problems will occur. But we know that the application is still in progress.

Let's assume this scenario, there are multi DAGs in a tez application(DAG is executed serially one after another). If DAG1 requires ShuffleServer1, but DAG2 does not require ShuffleServer1, so the resources of ShuffleServer1 will be released after DAG1 ends. Due to no heartbeat anymore, ShuffleServer1 will add the application to the expired queue and wait for the resources to be released, but ShuffleServer1 was required again in DAG3. We assume the following execution sequence.

In DAG2, due to no heartbeat anymore, ShuffleServer1 will add the application to the expired queue, but we know the clearResourceThread thread releases resources serially. If the queue is relatively large, it need to wait for a while.
In DAG3, the ShuffleServer1 is required again which will invoke ShuffleTaskManager#registerShuffle method.
The clearResourceThread thread releases application resources.
In DAG3, shuffle client will require buffer by invoking ShuffleTaskManager#requireBuffer in ShuffleServer1, but it just return NO_REGISTER status code...

But we know that the application is still in progress.

Thanks for your patient explanation @zhuyaogai 👍，got your point and make sense.


feat: add ! into triggerCharacters

Some abbreviations begin with an exclamation mark: https://docs.emmet.io/cheat-sheet/

Thanks @musjj ! Will release this soon.


Add black, isort and pyupgrade to pre-commit

Add black, isort and pyupgrade to pre-commit
All of the changes are automatic, I didn't make any changes except updating pre-commit
Next to add is flake8 but this requires hand-changing code therefore, I wished to do this in a separate PR

Thank you


[v10] Dashboard: Vertical (Normal Mode)

a new interface for vertical orientation, with 800px width

Addressed on latest pull requests by @bamboo3250


Add two new public zng_deflate{Set,Get}Params() functions

These functions allow zlib-ng callers to modify and query the
compression parameters in a future-proof way. When the caller requests a
parameter, which is not supported by the current zlib-ng version, this
situation is detected and reported to the caller. The caller may modify
or query multiple parameters at once. Currently only "level" and
"strategy" parameters are supported. It is planned to add a
"reproducible" parameter, which would affect whether IBM Z DEFLATE
CONVERSION CALL is used.
Passing enum and void * buffer was chosen over passing strings, because
of simplicity for the caller. If strings were used, C callers would have
to call snprintf() and strtoul() for setting and getting integer-valued
parameters respectively, which is quite tedious.
Bulk updates were chosen over updating individual parameters separately,
because it might make sense to apply some parameters atomically, e.g.
level and strategy.
The new functions are defined only for zlib-ng, but not compat zlib.

I'd like to see example buffers both for set and get. I tried to figure it out from the code + comments, but I was not able to figure it out in the short time I have available for that right now.
Things look pretty solid though.

The CI appears to have failed on a POWER machine. I have access to one and I could reproduce the segfault. Debugging...

So far I only managed to figure out that if I take develop branch and add a second test_large_deflate call to example.c, the same problem would occur. Valgrind and ASAN do not see anything, so this is unlikely to be a buffer overrun. Backtrace:
Program received signal SIGSEGV, Segmentation fault.
longest_match (cur_match=40073, s=0x100538b0) at /home/iii/zlib-ng/match_p.h:88
88	    scan_end1 = scan[best_len-1];
(gdb) bt
#0  longest_match (cur_match=40073, s=0x100538b0) at /home/iii/zlib-ng/match_p.h:88
#1  deflate_slow (s=0x100538b0, flush=<optimized out>) at /home/iii/zlib-ng/deflate_slow.c:65
#2  0x00000000100041b0 in zng_deflate (strm=0x3fffffffeed0, flush=<optimized out>) at /home/iii/zlib-ng/deflate.c:1026
#3  0x0000000010001418 in test_large_deflate (compr=compr@entry=0x10040010 "x\001\354̱\t", comprLen=40000, uncompr=uncompr@entry=0x10049c60 "", uncomprLen=uncomprLen@entry=40000)
    at /home/iii/zlib-ng/test/example.c:289
#4  0x0000000010000b14 in main (argc=<optimized out>, argv=<optimized out>) at /home/iii/zlib-ng/test/example.c:552

best_len is 0, which appears to make scan[best_len-1] invalid, but I don't know yet whether this is normal and why this is happening.

@iii-i My wild guess would be that it doesn't have a match yet... Other targets don't cause exception because the contents are not actually accessed, otherwise it would trap on the line that actually tries to dereference the out-of-bound array pointer.

@iii-i My guess is that the p s->match_length returns 2, because the next line (line 58) sets it to 2 (MIN_MATCH=3, 3-1=2).

@mtl1979 thanks, you are right! This is because of compiler reordering. With -O0:
Old value = 2
New value = 0
0x000000001000b2b4 in deflate_slow (s=0x100538b0, flush=0) at /home/iii/zlib-ng/deflate_slow.c:57
57	        s->prev_length = s->match_length, s->prev_match = s->match_start;
(gdb) p s->match_length
$3 = 0
(gdb) p s->prev_length
$4 = 0

@iii-i Now we just need to test there is no regressions if we set best_len to 1 instead of 0...

@mtl1979 Smoke test (while true; do for l in $(seq 1 9); do head -c10000000 /dev/urandom | hexdump -C | ./minigzip -$l | pv >/dev/null; done; done) does not show any problems, and I can run something else that tries different kinds of data, e.g. squash, in addition, but I don't understand the following: wouldn't longest_match start returning 1 instead of 0 if doesn't find anything? Or is the fact that it's called in the first place somehow ensures that some match will be found? Or do returning 0 and 1 mean the same to callers, since both of these values are less than MIN_MATCH?

@iii-i As far as I know it never checks if return value of longest_match() is exactly 0. In case where scan_end and scan_end1 would both be 0, it could confuse the code but as we fool it to think current match is single byte, it should never try to match against string of bytes at same buffer index.

@mtl1979 I let it run overnight, and, unfortunately, it has hit the match[2]? assert.

@iii-i Then the only choice left is early exit if there is no match...

@mtl1979 I got back to working on this today again, and realized that bogus scan_end and scan_end1 cannot lead to the match[2]? assertion error, because what's violated here is "if the first two bytes and the hash match, then the third byte matches as well" assumption, which has nothing to do with scan_end and scan_end1. So I built develop zlib-ng, and the assertion error occurred there as well. I will create a separate issue for this.

@iii-i In the worst case we just need to get rid of that assert and compare all MIN_MATCH bytes... There is possible border case where the hash can be invalid at end of valid input buffer due to hashing always 2 bytes ahead of given memory location.

@mtl1979 In this case scan and match seem to be in the middle of input (s->lookahead == 15490). I've created https://github.com/zlib-ng/zlib-ng/issues/361 for this.

I'd like to see example buffers both for set and get. I tried to figure it out from the code + comments, but I was not able to figure it out in the short time I have available for that right now.

Still waiting for this.

@Dead2 Might this be what you are looking for?

I see it now :)
Please rebase this, so we can see whether travis succeeds this time.

Thanks


Remove underlining from highlighted words in the text

When you hover over words in the Bible text, as well as highlighting the words, they are sometimes also underlined - esp in OT texts.
These underlines should be removed from the hover-over styles, because it is unnecessary, and the underlining makes some languages (such as Hebrew) difficult to read.

NOw fixed


[Bug Report]:  WASM runtime code in Rspack should target es5

System Info
None
Details
Becasue rspack insert runtime need keep es5, avoid break old broswers
Reproduce link
No response
Reproduce Steps
See https://github.com/web-infra-dev/rspack/blob/main/crates/rspack_plugin_wasm/src/runtime/async-wasm-loading.js
https://github.com/web-infra-dev/rspack/blob/main/crates/rspack_plugin_runtime/src/runtime_module/runtime/async_module.js

Closed due to not being sure if it's a bug.


Fix typos found by codespell

About re-use → reuse: reuse is found in all dictionaries, and more importantly, it already occurs > 100 times in the repository, so this is more a question of consistency than correctness.
Not sure about implementor → implementer. Both seem acceptable, but most dictionaries suggest implementer alone or as a first choice (Cambridge, Merriam-Webster) and the Google Books Ngram database suggests that implementer outdistanced implementor around 2000, and curiously even more in American than British English:
https://books.google.com/ngrams/graph?content=implementer%2Cimplementor&year_start=1800&year_end=2019&corpus=en-2019
Checklist

[x] documentation is added or updated
[ ] tests are added or updated

Merged, thanks for the documentation fixes.