U-Boot/Depthcharge as payload with coreboot

Hi Matt,
is it possible to add u-boat/depthcharge as coreboot payload?
after switching to the firmware we can still use the same bootable chromeos kernels.
Can  you look into this? thinbootloader has it also as payload.. and more.
Thanks
Ernst

one can certainly build upstream coreboot with depthcharge as a payload, but I'm not sure why you'd want to offhand. Changing the payload on one of my builds isn't worth the effort when you can just clone my repo and rebuild whatever config you want

It will not be a standard selectable  payload for coreboot? And select the partition of kernel.
it is conveneient for people  who use original / modified   chromeos  kernel and normal linux distribution.
Do you think it is not something you can add in the firmware. People who use original chromeos,  cb-linux/breath or hexdump's imagebuilder and thinking about chnaging firmware can still keep their kernels, system.

closing as this isn't a script issue


fix validation report

After forking skohub-pages and change something,
github actions aborts with validation error:
 ERROR  UNKNOWN

TypeError: Cannot read properties of null (reading 'value')
    at validate (/app/src/validate.js:65:23)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Object.exports.onPreBootstrap (/app/gatsby-node.js:117:9)
    at runAPI (/app/node_modules/gatsby/src/utils/api-runner-node.js:509:16)

I get the same error in the skohub.io instance, see https://skohub.io/build/?id=f1a3c5ff-0fcb-4dc6-9823-8b7ab59ba90a.
Assigning @sroertgen for review.

Thanks for reporting and fixing @thomschke!
@acka47
I stumbled across this by accident as well yesterday and think it has something to do with #284
We now have sh:or statements in our shacl graph for testing the presence of dct:title, skos:prefLabel and dc:title. The same for the description attributes.
The library we are using for doing the shacl validation can handle the validation, but does not give good errors if something goes wrong in these sh:or statements therefore the null statement which you and @thomschke encountered.
This is unfortunate since you also don't get meaningful error messages if one of these attributes is missing. The lib is not returning the correct path to identify the node where an error occured.
The fix provided by @thomschke will help to run vocabs through the pipeline if just a warning occured, but we are getting unhelpful error messages for violations, e.g.
-----------Violation--------------
 Message:  []
 Path:  undefined
 Node, where the error occured:  https://hof-halle-wittenberg.github.io/type/
 Severity of error:  http://www.w3.org/ns/shacl#Violation

(a description is missing in this vocab, but you don't get a good hint from the shacl validation)

I will merge this now, but open an issue to think and discuss about handling the violations


bug: Navigation item remains selected even for the screens which aren't in app

Summary:
bug: Navigation item remains selected even for the screens which aren't in app which leads to confusion as to figure out which screen we are on.
Steps to reproduce:
Open App, Nav drawer, click on Charges (Example). We remain on the Home Screen.
Expected behaviour:
Nav drawer should close with the actual item highlighted.
Observed behaviour:
The wrong item remains highlighted.
Screenshots:
I would work on this.

@naman14 @AbhilashG97 @therajanmaurya Can I go ahead?

I'll be working on it.


Close will not throw FetchException anymore

Close will not throw FetchException anymore if closed before as mentioned here.

@DHosseiny Thanks for this PR but the changes were already in another branch and just pulled.


undefined method `to_sym'

Error when I try to put Hash by :tsearch instead of use plain array without additional customizations.
What did do I wrong and is there any known workarounds?

undefined method `to_sym' for {:tsearch=>{:prefix=>true}}:Hash Did you mean? to_s to_yaml to_set

# controller
def search
      result = User.search_by_login params[:search][:query]

# model
  pg_search_scope :search_by_login, against: [:name, :email],
                                    using: [:trigram, :dmetaphone,
                                            :tsearch => { :prefix => true }],
                                    ignoring: [:accents]

/usr/local/rvm/gems/ruby-2.3.0/bundler/gems/pg_search-e4e2ed236690/lib/pg_search/scope_options.rb:147:in `feature_for'
/usr/local/rvm/gems/ruby-2.3.0/bundler/gems/pg_search-e4e2ed236690/lib/pg_search/scope_options.rb:114:in `block in conditions'
/usr/local/rvm/gems/ruby-2.3.0/bundler/gems/pg_search-e4e2ed236690/lib/pg_search/scope_options.rb:113:in `map!'
/usr/local/rvm/gems/ruby-2.3.0/bundler/gems/pg_search-e4e2ed236690/lib/pg_search/scope_options.rb:113:in `conditions'
/usr/local/rvm/gems/ruby-2.3.0/bundler/gems/pg_search-e4e2ed236690/lib/pg_search/scope_options.rb:103:in `subquery'
/usr/local/rvm/gems/ruby-2.3.0/bundler/gems/pg_search-e4e2ed236690/lib/pg_search/scope_options.rb:170:in `rank_join'
/usr/local/rvm/gems/ruby-2.3.0/bundler/gems/pg_search-e4e2ed236690/lib/pg_search/scope_options.rb:20:in `apply'
/usr/local/rvm/gems/ruby-2.3.0/bundler/gems/pg_search-e4e2ed236690/lib/pg_search.rb:39:in `block in pg_search_scope'
app/controllers/users_controller.rb:80:in `search'

pg_search doesn't support having different types of objects in an Array as the value of :using.
Try this instead:
  pg_search_scope :search_by_login, against: [:name, :email],
                                    using: [
                                      :trigram => {},
                                      :dmetaphone => {},
                                      :tsearch => { :prefix => true }
                                    },
                                    ignoring: [:accents]

@nertzy thanks a lot, could you update documentations part for this?


Option to upgrade packages and reboot if necessary

This will run "apt upgrade" or "dnf upgrade" on the first boot, to make sure that all packages are updated to the latest version.
It adds to the initial startup time and to the size of the diffdisk, so it is better to update the basedisk with a newer cloud release.
But it is a good way to make sure that you start your Fedora with the latest and greatest kernel...
It would be possible to extend the feature to be able to install some missing system packages too.

Don't you want to set package_update as well?

When you select package_upgrade (or packages), the package_update is automatically enabled as well.
So I only think you need to set that, if you want to apt update at boot - but don't want to apt upgrade?
With Fedora it is not needed anyway, because dnf always does update unless you say --cacheonly (-C)

Having the individual setting seems like useless flexibility in the context of Lima.

Mostly I just mirrored the cloud-init configuration. But without it (reboot), you would still run the old kernel...

The documentation is a bit spread out:
#cloud-config
# Update apt database on first boot
# (ie run apt-get update)
#
# Default: true
package_update: false

# Upgrade the instance on first boot
#
# Default: false
package_upgrade: true

# Reboot after package install/update if necessary
# Default: false
package_reboot_if_required: true

https://cloudinit.readthedocs.io/en/latest/reference/examples.html#run-apt-or-yum-upgrade
# Update apt database on first boot (run 'apt-get update').
# Note, if packages are given, or package_upgrade is true, then
# update will be done independent of this setting.
#
# Default: false
package_update: true

Spoke too soon, since package_reboot_if_required unfortunately only works with apt (bug in cloud-init)
It knows that it should restart, but it doesn't do it.
[  155.584749] cloud-init[1039]: You should restart:
[  155.584860] cloud-init[1039]:   * Some applications using:
[  155.585137] cloud-init[1039]:       systemctl restart NetworkManager
[  155.585216] cloud-init[1039]:       systemctl restart chronyd
[  155.585313] cloud-init[1039]:       systemctl restart cloud-final
[  155.585422] cloud-init[1039]:       systemctl restart dbus-broker
[  155.585518] cloud-init[1039]:       systemctl restart sshd
[  155.585591] cloud-init[1039]:       systemctl restart systemd-homed
[  155.585672] cloud-init[1039]:       systemctl restart systemd-journald
[  155.585754] cloud-init[1039]:       systemctl restart systemd-logind
[  155.585836] cloud-init[1039]:       systemctl restart systemd-oomd
[  155.585922] cloud-init[1039]:       systemctl restart systemd-resolved
[  155.586041] cloud-init[1039]:       systemctl restart systemd-udevd
[  155.586176] cloud-init[1039]:       systemctl restart systemd-userdbd
[  155.586343] cloud-init[1039]:   * These applications manually:
[  155.586434] cloud-init[1039]:       (sd-pam)
[  155.586515] cloud-init[1039]:       bash
[  155.586597] cloud-init[1039]:       sleep
[  155.586675] cloud-init[1039]:       timeout
[  155.586868] cloud-init[1039]: Additionally, there are:
[  155.586942] cloud-init[1039]:   - 2 processes requiring restart of your session (i.e. Logging out & Logging in again)
[  155.587114] cloud-init[1039]:   - 1 processes requiring reboot
[  155.587194] cloud-init[1039]: For more information run:
[  155.587278] cloud-init[1039]:     sudo tracer -iat<PHONE_NUMBER>.4121575

    # TODO(smoser): handle this less violently
    # kernel and openssl (possibly some other packages)
    # write a file /var/run/reboot-required after upgrading.
    # if that file exists and configured, then just stop right now and reboot
    reboot_fn_exists = os.path.isfile(REBOOT_FILE)
    if (upgrade or pkglist) and reboot_if_required and reboot_fn_exists:

In DNF it is done by a separate command, called needs-restarting -r.
$ sudo dnf needs-restarting -r
Core libraries or services have been updated since boot-up:
  * dbus-broker
  * glibc
  * kernel-core
  * systemd

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943

So it needs to be patched in cloud-init, i.e. implemented properly in API.

When you select package_upgrade (or packages), the package_update is automatically enabled as well.

I didn't know that, and didn't find it anywhere in the docs. But even if it is, it doesn't hurt to explicitly set it to true when you enable package_upgrade.

# Default: true
package_update: false

This example config contradicts the schema definition:

package_update: (boolean) Set true to update packages. Happens before upgrade or install. Default: false

@afbjorklund writes:

Mostly I just mirrored the cloud-init configuration. But without it (reboot), you would still run the old kernel...

I know, but I don't see the point of importing the complexity into Lima. In lima.yaml we could have
# Update packages from repo after boot
# Default: false
update_packages: null

and if the user sets it to true we include all 3 lines into user-data:
package_update: true
package_upgrade: true
package_reboot_if_required: true

Even if you think package_update isn't needed, it shouldn't hurt to set it. And I would go with the schema definition over a sample config.

In DNF it is done by a separate command, called needs-restarting -r.

Can't we do this in a boot/00-needs-restarting.sh script ourselves?

Sorry, I didn't realize you updated the code as well as added the comments. I've only replied to your comments; haven't looked at the updated code yet.

Can't we do this in a boot/00-needs-restarting.sh script ourselves?

Sounds like a reasonable workaround, should be safe once it is fixed too.

@jandubois renamed to upgradePackages, and added the workaround for Fedora - seems to be working
[anders@lima-fedora lima]$ uname -r
6.6.9-200.fc39.x86_64
[anders@lima-fedora lima]$ rpm -q kernel-core
kernel-core-6.5.6-300.fc39.x86_64
kernel-core-6.6.9-200.fc39.x86_64

The only downside is that it takes the system "slightly longer" to get ready for ssh, since it does the upgrade.
INFO[0010] [hostagent] Waiting for the essential requirement 1 of 4: "ssh"
INFO[0020] [hostagent] Waiting for the essential requirement 1 of 4: "ssh"
INFO[0026] [hostagent] The essential requirement 1 of 4 is satisfied
INFO[0026] [hostagent] Waiting for the essential requirement 2 of 4: "user session is ready for ssh"
INFO[0066] [hostagent] Waiting for the essential requirement 2 of 4: "user session is ready for ssh"
INFO[0106] [hostagent] Waiting for the essential requirement 2 of 4: "user session is ready for ssh"
INFO[0146] [hostagent] Waiting for the essential requirement 2 of 4: "user session is ready for ssh"
INFO[0167] [hostagent] Waiting for the essential requirement 2 of 4: "user session is ready for ssh"
INFO[0176] [hostagent] The essential requirement 2 of 4 is satisfied
INFO[0176] [hostagent] Waiting for the essential requirement 3 of 4: "sshfs binary to be installed"
INFO[0179] [hostagent] The essential requirement 3 of 4 is satisfied
INFO[0179] [hostagent] Waiting for the essential requirement 4 of 4: "/etc/fuse.conf (/etc/fuse3.conf) to contain \"user_allow_other\""
INFO[0179] [hostagent] The essential requirement 4 of 4 is satisfied


Add HTML helper methods for rendering globbed stylesheet & JavaScript references with fallback

Add methods to IHtmlHelper that support rendering HTML for stylesheet links and script blocks with support for globbed file paths and fallbacks. Basically the equivalent of the features of the link and script tag helpers.
Example
@section head {
    @if (HostingEnvironment.IsDevelopment()) {
        @Html.Stylesheet(include: "lib/**/*.css", exclude: "css/**/*.css");
        @Html.Stylesheet(include: "css/**/*.css", exclude: "lib/**/*.css");
    }
    else if (HostingEnvironment.IsProduction()) {
        @Html.Stylesheet(
            href: "//mycdn.com/bootstrap/2.1.0.min.css",
            fallbackHrefInclude: "lib/bootstrap/css/*.min.css",
            fallbackTestClass: "hidden",
            fallbackTestProperty: "visibility",
            fallbackTestValue: "hidden");
        @Html.Stylesheet(href: "css/site.min.css", fallbackHrefInclude: "css/**/*.min.css");
    }
}

@section scripts {
    @if (HostingEnvironment.IsDevelopment()) {
        @Html.Script(src: "lib/jquery/jquery.js");
        @Html.Script(src: "lib/jquery-ui/jquery-ui.js");
        @Html.Script(include: "js/**/*.js", exclude: "lib/**/*.js");
    }
    else if (HostingEnvironment.IsProduction()) {
        @Html.Script(
            src: "//mycdn/jquery/2.1.2.min.js",
            fallbackSrc: "lib/jquery/jquery.min.js",
            fallbackTest: "window.jQuery"
        );
        @Html.Script(
            src: "//mycdn/jquery-ui/1.12.0.min.js",
            fallbackSrc: "lib/jquery-ui/jquery-ui.min.js",
            fallbackTest: "window.jQuery && window.jQuery.ui"
        );
        @Html.Script(src: "js/site.min.js" fallbackSrcInclude: "js/**/*.min.js");
    }
}

I think that if you do this you need to have a firm answer on how they will be sorted.

We have some logic in Bundling & Optimization but before grabbing code we should figure out what we want.

@Eilon they'd be sorted as they're found on disk, hence the example above explicitly added libs first. This is essentially a straight port of what we have for the script & link tag helpers.

What does "as found on disk" mean? As far as I know the file system APIs on Windows don't make any guarantees at all. Not sure about *nix / Mac OS.

@DamianEdwards - do you still want to do this? Or do we want to divest from adding more to HTML helpers?

Nobody has asked for this.


New version: xpipe-io.xpipe version 8.3

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

I submitted this automatically with wingetcreate. Do I need to tick the boxes in the post manually?

Hi @crschnick,

This PR's version number 8.3 has 2 parameters (sets of numbers between dots - major, minor, etc), which is less than the current manifest's version 0.65.2, which has 3 parameters.

Does this PR's version number exactly match the version reported in the Apps & features Settings page? (Feel free to attach a screenshot.)
(Automated response - build 869)

Yeah the ProductCode isn't really necessary here I think

Agreed - my notes say that ProductCode can help when the installed application's ProductCode is different from the installer, and in this case it's only needed in 1 manifest.

Hi @crschnick,

This PR's version number 8.3 has 2 parameters (sets of numbers between dots - major, minor, etc), which is less than the current manifest's version 0.65.2, which has 3 parameters.

Does this PR's version number exactly match the version reported in the Apps & features Settings page? (Feel free to attach a screenshot.)
(Automated response - build 869)
Edit: my automation made an error here:
PS C:\ManVal> winget search xpipe-io.xpipe
Failed when searching source; results will not be included: msstore
Name           Id                      Version Source
------------------------------------------------------
XPipe          xpipe-io.xpipe          8.2     winget
XPipe Portable xpipe-io.xpipe.portable 1.5.3   winget
PS C:\ManVal>

Yes, the versioning scheme was changed. The portable package is a very old one that is no longer maintained.


System.Object not defined or Imported (also Console is nonexistent

Describe the bug
When I try to type Console.WriteLine it gives me an error, pictured below. Yes it's possible to replicate it, I refreshed and caused it again by typing it manually.
(If it helps, I received errors CS0518 and CS0103, though it's in the picture)
Where did this error occur?
https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/intro-to-csharp/index
What kind of error was it?
System failure?
Screenshots

Desktop (please complete the following information):

OS: Windows 10 (Education)
Browser: Chrome
Version 74.0.3729.108 (Official Build) (64-bit)

Thanks, @TheFinalDawn.
Which specific tutorial did you encounter this on? You linked to the index page, which doesn't contain any Try .NET editors.

should work on all of them

I'm not able to reproduce the problem but I might not be looking at the correct page.
The editors on different pages are configured differently so issues like this will not necessarily be consistent across pages.

Odd, It did it the first time but now I can't make it happen again... Must have been something I did on accident


Fix: District selection by map

Description of PR
This will fix the issue related to the district selection on the state map.
Here the mouse enter event is removed and the logic is moved to the click event. So now when a region/district has clicked, the info related that particular area is shown.
Relevant Issues
Fixes https://github.com/covid19india/covid19india-react/issues/2319
Checklist

[x] Compiles and passes lint tests
[x] Tested on desktop
[x] Properly formatted
[x] Tested on phone

Screenshots

Seems to be fixed already


chore (crash): set minifyEnabled to false and update dependencies

I don't know if we had any strong reason to keep minifyEnabled set to true, but it was breaking our build in #1299

@rosariopfernandes I think the build breakage in #1299 is correct. The reason for minifyEnabled: true in this repo is to make sure that Firebase SDKs compile with minification enabled. Sort of a last-resort smoke test.
I think the crashlytics plugin has a bug right now with Gradle 7.

@samtstern that sounds right. Let's wait for an update from the crashlytics team

I think this is no longer needed:
https://github.com/firebase/quickstart-android/pull/1305


Upgrade to 3.7.0

The bindings in the repo are outdated.
I did a bit of work in my fork https://github.com/Soaku/raylib-d/tree/upgrade-3.7.0 but that's just one file, plus I didn't move the rlgl part out, like it has been done in raylib. I might have also missed some changes from before 3.5.0 because I was looking at a diff between 3.5.0 and 3.7.0 and I've noticed there have been a couple of changes.
Because of how many changes there have been done, it might be worth regenerating the files with a binding generator instead, my work is prone to mistakes.

Just a note, I think we should diff between 3.0.0 and 3.7.0 because raylib-d has not been updated since 3.0.0 AFAIK.

Should be much better now, all files have been upgraded to follow what was changed in Raylib (including breaking backward compatibility…).
I've moved some of the custom types such as Bivector2 to raymathext.d so they don't have to be moved back every time the headers are updated.
Some notes:

It might be worth to move the Colors enum to a separate file, dstep doesn't like it. Maybe the --alias-enum-members could help but I haven't looked into it.
I fixed inconsistency regarding spaces before parenthesis in raymath.d. No spaces now.
Some enum parameters in the existing bindings refer to actual enums, not int. I didn't correct this after regenerating the header, so the type information is lost.
I might have overlooked some local changes to raylib.d. It might be worth listing them in a separate file next time…

Passes all unittests and works with all my repos.

Don't have time at the moment to look. Does it have instructions on how it was created and what steps need to be taken to recreate? I definitely want that in there.

Alright, will do. I think I'll also move all the modified types to a separate module (so basic Vector2 etc too) so later regeneration will only involve removing symbols in CLI.
BTW, I've added @nogc nothrow to rlgl and raymath, just like it was done in raylib.d. I think it could also be worth to add @safe to functions with a safe interface, since raylib has quite a lot of them, but that gives more work to do.

Added a generating.md file. Also repeated the process described in it multiple times to make sure everything is in it, looks like I got it right.

Nice!
I wanted to respond to a comment you made, but then removed, and that is about adding @safe attributes. I am firmly against adding @safe to any extern(C) functions that are not written in D (and not marked @safe). Because @safe implies the compiler has checked the code, and this is simply not true for C-compiled functions. It might be reasonable to add @trusted to some functions, but I'm not sure that's appropriate anyway, since that means any changes to raylib need to be audited by us for memory issues.

Also, I didn't touch raygui. I'm interested if someone actually got it working in D, since it's header only, I didn't mess with it much.

This is problematic, but not a deal-breaker. As long as the header-only library works with current raylib, it should be OK (and IIUC, if you can build with tests, it should be correct). However, tracking 2 independent bindings here is kind of difficult.  I would say, let's track raygui manually, and not with a binding generator. An all-header library is going to use more preprocessor features, and make things complicated. I would need someone who uses the raygui portion to help maintain that. It was only added to this binding 18 months ago, and seems to have only one commit.


Enabling Analysis for code native code

Static analysis is a great way for us to catch issues early and during development.
As a min, I think we should do what the Terminal team has.

https://github.com/microsoft/terminal/blob/master/src/common.build.pre.props
https://github.com/microsoft/terminal/blob/master/src/StaticAnalysis.ruleset

we adjusted .NET Code in #910.

lets start low and work our way up.  To me this is something we can move to future iterations as well.

Moving this to 0.19

Lets knock 1 to 2 every iteration.
First up: Runner

Clint: do check list like we did with other chores

Is this still an issue? What needs to be done?

still a thing @jay-o-way.  Since this is c++, not something i can easily do on spare time

@jaimecbernando Is this finished?


Lampho branch - Php version on Laravel-Zero - Initial, progressive upgrade to 5.8

hey @andrewmile
So I was able to start the porting, and left out the recurring runtime option config change in a starting point.
All the rest is working, and left a file, ROADMAP.md that you should go about, left many thought and indications there!
Im at 12% now, will use the rest to scaffold a little more, the interactive options, and if all is found agreed, just small tweaks and tests missing.
Can't wait to hear your thoughts!

I think, best to start, would be cloning the fork on ijpatricio:ijpatricio-lampho-58
And analyse on your editor.
ROADMP.md has instructions and insights.
8% battery :)  Configuration options.. I left them going to the looks of how it could be, but then they just get back to initial screen.
Form here, similar like the one on 5.7, i was thinking making a contract and classes for options, that would change the runtime configs, (perform check is a plus), they would run, and get back to the display of current configuration.
Now it's missing, because all the options will be different, but let's make them show as you mentioned before, showing the evaluation (instead of "false"), and a friendly description.
Phhheeew this was long, hope you made it through!! :)
Let me know your thoughts!!

hey @ijpatricio , nice work!  I just pulled down the branch and gave it a quick run through.  It works and everything looks good so far.  I'll look over this more over the next few days as I have extra time but will give a more detailed review by Friday.
Thanks again! :)

hey @andrewmile !
Sure thing! Glad I can help! :)
Let me know any further feedback after you review.
I'm having an idea for implementation of the options (now without php-console-menu), just not sure if I should push it before you review??
Thanks! :)

Hey @ijpatricio , I've been reviewing the updates today and have some more feedback below for some things that I think will improve the workflow.  Please let me know what you think!
Default Editor
The editor attempts to open with PhpStorm by default. Let’s change the config.editor option to default to false so it can just be set in the user’s config.php.
Default node
Let’s also set the default config.node to false.  This will make the default behavior consistent with the current version of Lambo.
Options for making or editing config.php and after.php
The current version of Lambo supports options for make-config, edit-config, make-after, edit-after.  The make commands will give a “Config already exists." message if the file already exists and the edit commands will create the file if it doesn’t already exist and then open in the editor set in the config or use Vim as a fallback.  What do you think about adding the following commands to keep this same behavior?
- make:config
- make:after
- edit:config
- edit:after
Make customization prompt optional
What do you think about hiding the customization prompt behind a flag so it will only run if the flag is passed in?  I don’t necessarily want to get rid of the customization prompt because I think it can be useful but when I run lambo new app my default expectation is for it to just run its normal process so I mentally pause at the customization prompt.
Adding the following to the signature would mean if I want to run with customization I could just run lambo new app -c.
{--c|custom : Customize config options.}

Then with the above, you could wrap a condition around the PromptForCustomization call like below:
if ($this->option('custom') {
    $this->action(PromptForCustomization::class);
}

Hi @ijpatricio , here's a few more comments below:
CD into new directory
After the new app installation finishes I am left in the same directory I was in when I ran the command.  Can you add an extra action in the handle method to cd into the newly created directory?
Config.php overrides
I created a new file at ~/.lambo/after.php with the following contents in order to open the project in Sublime but nothing happened.  Do I need to format this file differently?
<?php

return [
    'editor' => 'subl'
];

After installation
The current version of Lambo runs an after shell command if it is present at ~/.lambo/after.  The default stub is below:
#!/usr/bin/env bash

# Install additional composer dependencies as you would from the command line.
# echo "
# Installing Composer Dependencies
# "
# composer require tightenco/mailthief tightenco/quicksand

# To copy standard files to new lambo project place them in ~/.lambo/includes directory.
# echo "
# Copying Include Files
# "
# cp -R ~/.lambo/includes/ $PROJECTPATH

# To add a git commit after given modifications
# echo "
# Committing after modifications to Git
# "
# git add .
# git commit -am "Initialize Composer dependencies and additional files."

In the previous PR that there was an after.php file that got merged with config/lambo/after.php but I no longer see that file in this branch.  Is that still a work in progress?  I wonder if it would be just as easy to check for the presence of ~/.lambo/after and run it through $this->shell().  That would allow for backwards compatibility for anyone who has a bunch of things going on in that file.

Hey @andrewmile !! Glad to hear you're enjoying so far! 👍
So, I changed the workflow already (run is the default, -c to config).
Started adding tests.
Added TODOS, where I still did not implement. I would add them here, but that would be crazy to understand. They are all in app/Commands/NewCommand.php
Now i have conditions to work more, at least on the TODOS...And testing.
Not sure when and where you want to chime in, so let me know!
Also shared my feedback about yours 🙌So here goes...

Default Editor
The editor attempts to open with PhpStorm by default. Let’s change the config.editor option to default >to false so it can just be set in the user’s config.php.

Done.

Default node
Let’s also set the default config.node to false. This will make the default behavior consistent with the >current version of Lambo.

Good point. Done.

Options for making or editing config.php and after.php
The current version of Lambo supports options for make-config, edit-config, make-after, edit-after. >The make commands will give a “Config already exists." message if the file already exists and the edit >commands will create the file if it doesn’t already exist and then open in the editor set in the config or >use Vim as a fallback. What do you think about adding the following commands to keep this same >behavior?

make:config
make:after
edit:config
edit:after

I would see this consistently with Lambo now being interactive, so all in one go!
Think with me:

We can lambo new automator to just start the installer (default, or last config, if already set).
Or we can lambo new automator -c to customise.

Now that I have -c and options to decide what to do, why not:

Config as we wish...
Save config, and save after may be options to choose!
If destination file already exists, just warn "Want to override existing config?" In this case, we may even copy the existing file, adding a timestamp, so that no data would be lost inadvertently. Keep last 3 copies.

What do you think?
I'm also ok with making that 4 other commands, what do you think?
Also, speaking of these files. IIRC, files are saved to ~/.lambo
Nowadays, apps like Valet, Yarn and more, are using ~/.config/app so we could have ~/.config/lambo

Make customisation prompt optional
What do you think about hiding the customisation prompt behind a flag so it will only run if the flag is >passed in? I don’t necessarily want to get rid of the custosization prompt because I think it can be >useful but when I run lambo new app my default expectation is for it to just run its normal process so I >mentally pause at the customization prompt.
Adding the following to the signature would mean if I want to run with customization I could just run >lambo new app -c.
{--c|custom : Customize config options.}
Then with the above, you could wrap a condition around the PromptForCustomization call like below:
if ($this->option('custom') {
$this->action(PromptForCustomization::class);
}

This is done already, help me to figure if I understood correctly
lambo new automator -c
Should:
1 - Display current config (maybe we just want to check), Press c to config, or r to run
2 - Display immediately the config (without knowing how it was) ?
Right now is doing option 1.

CD into new directory
After the new app installation finishes I am left in the same directory I was in when I ran the command. >Can you add an extra action in the handle method to cd into the newly created directory?

Yeah, so this will be a struggle. I will have to double check with a friend, just not to give you the bad news right away 😞Well, maybe there's a way. laravel official installer doesnt do it, also laravel-zero does not. I will research a little further and ask opinion, maybe you can do the same?

Config.php overrides
I created a new file at ~/.lambo/after.php with the following contents in order to open the project in >Sublime but nothing happened. Do I need to format this file differently?
 'subl'
];

(...)

In the previous PR that there was an after.php file that got merged with config/lambo/after.php but I no >longer see that file in this branch. Is that still a work in progress? I wonder if it would be just as easy to >check for the presence of ~/.lambo/after and run it through $this->shell(). That would allow for >backwards compatibility for anyone who has a bunch of things going on in that file.

Yeah, this was in 5.7 branch, but with the port to 5.8 being a little progressive, the workflow of those 2 files is still to do. That's a quick one.
Waiting your feedback 😀

Hey @andrewmile
I went ahead, and implemented the interactive option, that in previous version with 5.7 had console-menus, and now it's with native laravel choice, which makes it easier to test.
So please clone from the fork, and try it out. Also added tests. composer test or ./vendor/bin/phpunit
Now it should be very easy to add the missing interactive options, but because I don't know if i will have more time, I decided to commit this and notify you.
Have a good one!

Hey @ijpatricio , this is making some nice progress :)
I like the change you made of defaulting to running the command right away and adding the -c flag.

I would see this consistently with Lambo now being interactive, so all in one go!
Think with me:
We can lambo new automator to just start the installer (default, or last config, if already set).
Or we can lambo new automator -c to customise.
Now that I have -c and options to decide what to do, why not:
Config as we wish...
Save config, and save after may be options to choose!
If destination file already exists, just warn "Want to override existing config?" In this case, we may even copy the existing file, adding a timestamp, so that no data would be lost inadvertently. Keep last 3 copies.
What do you think?
I'm also ok with making that 4 other commands, what do you think?

Yeah I like the idea of being able to edit and save the config from the command line.  I think we could start out with that option and see if it feels like that provides all of the functionality.  If it does, there may not be a need to actually edit the file directly.  So lets go with the edit and save from command line option and then evaluate from there.

Also, speaking of these files. IIRC, files are saved to ~/.lambo
Nowadays, apps like Valet, Yarn and more, are using ~/.config/app so we could have ~/.config/lambo

I like this idea, lets go for it 👍

This is done already, help me to figure if I understood correctly
lambo new automator -c
Should:
1 - Display current config (maybe we just want to check), Press c to config, or r to run
2 - Display immediately the config (without knowing how it was) ?
Right now is doing option 1.

I prefer option 1 as well.

Yeah, so this will be a struggle. I will have to double check with a friend, just not to give you the bad news right away 😞Well, maybe there's a way. laravel official installer doesnt do it, also laravel-zero does not. I will research a little further and ask opinion, maybe you can do the same?

I'll work on this and see if I can come up with something.

@ijpatricio I just created the PR below to the ijpatricio-lampho-58 branch of your Lambo fork in order to add a final action to CD into the new project directory.  Once that PR is merged, the functionality will be present in this PR as well.
I played around with several different options here but landed on creating a change-directory.sh shell script that could be called from PHP with shell_exec.  The new action is ChangeDirectory and gets called after all of the other install actions.
PR: https://github.com/ijpatricio/lambo/pull/2

Hey Andrew!
Cool news!
I'll try it very soon!
Time hasnt been abundant, but as we're so close, we got to push this
forward.
Already made one more menu option, now its easier.. Thought we could split
that..
Im answering, even on mobile, so you dont wait longer, but this next days
ill push more work, and then we do a followup, if u agree, with the purpose
to find the closest way for a first version.
Happy coding!
A sexta, 26/04/2019, 19:02, Andrew Morgan<EMAIL_ADDRESS>escreveu:

@ijpatricio https://github.com/ijpatricio I just created the PR below
to the ijpatricio-lampho-58 branch of your Lambo fork in order to add a
final action to CD into the new project directory. Once that PR is merged,
the functionality will be present in this PR as well.
I played around with several different options here but landed on creating
a change-directory.sh shell script that could be called from PHP with
shell_exec. The new action is ChangeDirectory and gets called after all
of the other install actions.
PR: ijpatricio#2 https://github.com/ijpatricio/lambo/pull/2
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tightenco/lambo/pull/68#issuecomment-487147935, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGGTKY5ALIICLXYRHBMHWZ3PSM7TRANCNFSM4HCNG4UA
.

Hey @ijpatricio , no worries - things have been pretty hectic for me lately as well but I'm going to take some time today to review what is remaining on this :)

Hello Andrew!
Hope you're doing well!
So, in about 2-3 weeks I will have again a little "time to breathe"..
And would love to pickup on this and finish it!
How's things on your end?
Patricio
On Fri, May 10, 2019 at 3:42 PM Andrew Morgan<EMAIL_ADDRESS>wrote:

Hey @ijpatricio https://github.com/ijpatricio , no worries - things
have been pretty hectic for me lately as well but I'm going to take some
time today to review what is remaining on this :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tightenco/lambo/pull/68#issuecomment-491313792, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGGTKY4LMUKANJWVMMPACGTPUWCV3ANCNFSM4HCNG4UA
.

Hi Patricio!  Thanks for checking in on this :)
Things are going well on my end.  I created a new branch from your PR a while back and have made updates to am/laravel-zero-implementation as I have had time available.  Feel free to pull it down and have a look at where things are at.  By the time you start working on it again I'll make a WIP PR with a checklist of outstanding items on this branch.  That way if you want to PR into this new branch we can make updates there and work off of the same list.  How does that sound to you?

So.... this has grown out of control. I say this with love and care but it's so heavy I just can't get a handle on it.
I'm going to start a brand-new install from scratch. I'm going to build it out simply, bit by bit, and I welcome pull requests into it--even if the PRs are direct copies from this branch. I would love that! But I need to get this back to a place where I have a handle on it.
Sorry if this feels like any time was wasted. I hope not!

Eheheh it sure did :)
@mattstauffer
There is absolutely nothing to be sorry about. Personally, it was a great experience, given I have almost no experience in open source, and it was fun. More than that, if you are willing to start from scratch, and accept PR's, count me in!
So please let me know when you do so.
@andrewmile
Time really flies! Hopefully with this new momentum the project will grow!


Removes a string from the output that was affecting the json output f…

…ormat and consequently a prior workaround fix for the same issue.

fix for #125


feat: Update Liquid.Repository with Liquid packages v6.0.0

Fix #129
Replace and close #160

Liquid.Repository needs to be build and deployed first. Then Liquid.Repository.Mongo and Liquid.Repository.EntityFramework will be able to download the new reference from Nuget.


fix(select-builtin): disable highlighting of [n] due to MatchParen

Disable highlighting of numbers in the builtin DressingSelect. (The numbers that are displayed when show_numbers = true).
Context
before:

after:

What is the problem you are trying to solve?
Only a minor aesthetic one. The highlight of matching parentheses is not useful in the selection window.

Sure, LGTM


Set ivar not until initializing an instance of the owning class

Clang reports a (reasonable as I think) warning if you set an instance variable before initializing the instance itself. Hope this fix is ARC-ready.

Thanks :)

Damn it, probably
self.locateMeButton = locateMeButton;

instead of
locateMeButton_ = locateMeButton;

was the correct snippet for ARC? Will it be under-referenced otherwise?

nope, it's a strong variable so everything should be ok.
sent from phone
Am 17.11.2011 um 20:20 schrieb Alex<EMAIL_ADDRESS>
Damn it, probably
self.locateMeButton = locateMeButton;
instead of
locateMeButton_ = locateMeButton;
was the correct snippet for ARC? Will it be under-referenced otherwise?

Reply to this email directly or view it on GitHub:
https://github.com/myell0w/MTLocation/pull/8#issuecomment-2780486


README: commercial support

cc @dasJ does helsinki systems also wants to be mentioned here?

Also cc @zimbatm

@ajs124 do we?

Sure, why not?

indeed


Add lock to Pubsub.execute_command to ensure only one connection is created

Pull Request check-list
Please make sure to review and check all of these items:

[ ] Does $ tox pass with this change (including linting)?
[ ] Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
[ ] Is the new or changed code fully tested?
[ ] Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
[ ] Is there an example added to the examples folder (if applicable)?
[ ] Was the change added to CHANGES file?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.
Description of change
Please provide a description of the change here.

Codecov Report
All modified lines are covered by tests :white_check_mark:

Comparison is base (1032660) 92.40% compared to head (5e9b9f9) 77.68%.

Additional details and impacted files
@@             Coverage Diff             @@
##           master      #19       +/-   ##
===========================================
- Coverage   92.40%   77.68%   -14.72%
===========================================
  Files         119      119
  Lines       30727    30730        +3
===========================================
- Hits        28392    23873     -4519
- Misses       2335     6857     +4522

Files
Coverage Δ

redis/client.py
88.68% <100.00%> (-1.03%)
:arrow_down:

... and 44 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

is it better patch it upstream?

is it better patch it upstream?

it would be best to patch the upstream as well as we can remove this PR once upstream release a new release
Also could you please add a test case for this code (ex. lock is already acquired and trying to acquire a connection doesn't return a new connection)?

@dlunch any update?

Sorry, i was on vacation. i'll add test this week


Paper

add TSM.md(en)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

LGTM


Caching Plugin

It would be great to have a cache plugin - cache on URL + params as keys with a TTL same as varnish/squid..

Thanks, this topic is already discussed in #411 and #412.


Integrate Lucene / Disable OpenNER

Problem to address: We're using OPenNER for our NLP solution for keyword and place detection in Fortis. Through running the pipeline in high volume scenarios, we're noticing the performance of OPenNER ranging anywhere from ~100 - 500ms per event. This is causing the batch runtime to exceed the spark streaming interval, hence fortis crashing after an hour.
Solution: We decided to integrate Lucene as our in-memory search engine for detecting mentioned keywords / places.
Implementation

Add the 3 Lucene core jars dependencies into the Fortis build.
Index initial DStream pipeline events in Lucene.
Build the 2 Lucene search queries off of the geofenced list of places and the watchlist keyword terms. The keyword search should support terms across all supported languages. We should leverage the 30+ available language models that come pre-packaged through Lucene https://lucene.apache.org/core/7_0_0/analyzers-common/index.html .
The results of the Lucene index search should be ranked on search relevancy, weighted by mention count.

Note that Lucene doesn't seem to contain NLP capabilities like Named-Entity Recognition (source) so the results for complex tasks like extracting places may be poorer than via OpeNER since we'll just rely on word match instead of also using statistical/machine-learning features. To my understanding, the analyzers (e.g. for CJK languages) are just concerned with taking a text string and converting it into a word vector.


fix(libsinsp): fix possible segv in parse_connect_exit + cleanups

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug
/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:
ERROR: AddressSanitizer: SEGV on unknown address 0x000000001578 ... The signal is caused by a WRITE memory access. #0 0x56074dd65dc8 in sinsp_parser::parse_connect_exit(sinsp_evt*) /build/falcosecurity-libs-repo/falcosecurity-libs-prefix/src/falcosecurity-libs/userspace/libsinsp/parsers.cpp:3361
Plus refactor few parsers to feature early returns if evt->m_tinfo is a nullptr
Remove some inconsistent debug ASSERT statements
@LucaGuerra quick win when I ran the latest debug build on a test server just to verify if everything is good to go for further testing.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: incertum
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/milestone 0.14.0

Anyone having more context on the failed test sinsp_with_test_input.spawn_process_container? It seems to be a newer test.

LGTM label has been added.  Git tree hash: cf82b23e3aa33678e7b3eb4adde53763d783c133

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, incertum
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP,incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


samples: bluetooth: hci_uart: Improved UART handling

Receiver part reworked to not block in interrupt and rely on assumption
that uart_fifo_read is capable of reading incoming data from the HW.
Transmitter part reworked to use uart_fifo_fill instead of uart_poll_out.
This PR is fixing some issues in current implementation of hci_uart:

use uart_fifo_fill instead of uart_poll_out for sending packets. That improves throughput for drivers which may utilize multibyte transfer
remove blocking in RX uart context: current implementation was spinning and calling uart_fifo_read until requested number of bytes were available in the fifo. That spinning was happening in the uart interrupt context. This method was assuming that uart driver will be able to feed RX fifo inside uart_fifo_read. This is not required by the interrupt driven API thus it maybe that UART is feeding RX fifo from another context, outside uart_fifo_read. This approach was also blocking CPU from handling other same level interrupts. Reworked RX part to resemble h4 implementation where isr terminated when RX fifo is drained and expects that uart isr will be triggered again when new data is available.

Note that there is #26692 which is reworking uart HCI significantly but it relies on other PRs and it is unlikely to be merged in next few weeks. This PR may serve as intermediate solution which removes blockers from the out-of-tree driver i'm working on which supports interrupt driven API but does not feed RX fifo in uart_fifo_read and provides significant throughput improvements when using uart_fifo_fill instead of uart_poll_out.
Signed-off-by: Krzysztof Chruscinski<EMAIL_ADDRESS>

dear reviewers, i'm going for vacation, back on 31.08. Until then I won't be able to respond to comments.

Thanks for this patch! I plan to review it later, but can you first double-check that the transmission of the NOP can be left where it is, before the creation of the tx thread? with the rework I just want to make sure that we won't receive the first commands (which the host sends after receiving the NOP) too early:
https://github.com/zephyrproject-rtos/zephyr/pull/27581/files#diff-4518902872ac572c659d96216b345521R358

i will split it into 2 PRs: RX path and TX path (#27917) to make it easier to review and improve chances that it will make for 2.4.


Edit Disable Debugging section

Just correction for "Disable Debugging" section , as advised in the documentaiton leads to an error as refernced in bleow link:
https://github.com/jamesmontemagno/PermissionsPlugin/issues/5
Solution is
Remove those lines from your AssemblyInfo.cs.
Look for the Android class that has the [Application] attribute above it (in my case MainApplication) and replace that attribute with:
#if DEBUG
[Application(Debuggable = true)]
#else
[Application(Debuggable = false)]
#endif

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

ID: f43472af-a9d3-8bef-0f24-b81f8f6cd2dd
Version Independent ID: 42cfbea5-0b4c-a0a3-4cce-1edf5523f605
Content: Preparing an Application for Release - Xamarin
Content Source: docs/android/deploy-test/release-prep/index.md
Product: xamarin
Technology: xamarin-android
GitHub Login: @davidortinau
Microsoft Alias: daortin

Thanks for submitting an issue and we apologize for the delayed response. The requested updates haven't been made since the creation of the issue, and the timeline for resolution may vary based on resourcing, so the issue is being moved to an internal repo to better track it.


[Help] How do you use modules under src in preload.ts

Describe the problem you confuse

How do I use modules in src in preload.ts

Do it with normally import preload.ts, like standard esm.


How do updated moa/target annotations influence moa/target recall?

A potentially fun analysis would be to evaluate how the different moa/target annotations updated over time (in different CLUE drugs/samples versions) influence moa/target recall.
Essentially, we would setup an eval framework (I imagine there is a traditional moa/target recall eval) where we use the same input profiles and alter the moa/target information as they have been updated over time.
If we see improvement over time this tells us that annotations are improving and, potentially, that there is even more room to improve categorization.

We can do this eval for both Cell Painting and L1000 for the same profile perturbations.
Of course, how the annotations are being updated is extremely important here (i.e. if, for example, the annotations are updated using L1000 assays, then we'd expect moa/target annotations to improve more using L1000 data (and vice versa))
cc @shntnu - I can imagine that this analysis could find a home somewhere in the eval "offshoot" analysis paper (discussed in the context of Pooled CP) for the Drug Repurposing data


Add paused mode back to ChefMaker

This must have got lost in the recent upgrades

@JeffSteinbok very small change for ChefMaker that must have gotten lost in the recent changes


Update Podspecs for the "redundant public"

Hi @cockscomb,
Can you update your Podspecs to include changes of https://github.com/cockscomb/UTIKit/commit/3f39c309e8fa30de9fed819b27e8766eee21cbb2 when update pod ?
Thanks

@arnaudWasappli Hi.
I just released the latest version of UTIKit.
https://cocoapods.org/pods/UTIKit
Sorry for the late release.

Thanks ;-)


Masterlock

This is now ready for review.

Looks good.

Thanks!  I assume OMP will have some feedback over the coming week or so, but I guess we can fix those issues later on, shouldn't hold up this PR from merging as I know that there are pending PRs which depend on this stuff.  Merging now.


Update README.md

Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.
List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] I followed the breaking change policy and added Data Driven Fixes where supported.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Looks like you'll also need to sign the CLA, per the comment above.

If you're good with reverting the "the", I'd be happy to approve a 1-word change!

thank you very much.

To me as a non-native English speaker, what's the difference?

To me as a non-native English speaker, what's the difference?

Sorry @bartekpacia, didn't notice this comment till now!

The word "that" is used to create an essential clause, whereas "which" is used for making a non-essential clause.
The fact that Skia underpins Chrome and Android is good to know, but it could be removed from the sentence and you'd still be able to get the point across.

Had no idea about this concept – TIL. Thanks! :)


Zaps received to coinOS do not show in damus, primall

client initiating action
Placeholder
client receiving or observing action (or lack thereof)
Damus: no zap seen
Primal: no zap seen
timestamp
https://njump.me/nevent1qqswepmnz3rfkwf8xhdcee93h4jylqsa97y8ue38mk2jhkke6jseqdcprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyg8wumn8ghj7mn0wd68ytnhd9hx2qgdwaehxw309ahx7uewd3hkcqgkwaehxw309aex2mrp0yhxummnw3ezucnpdejq96cj7u
what happens
suggestion

CoinOs context https://github.com/coinos/coinos-server/issues/62

the issue is with coinos' lnurl server https://github.com/coinos/coinos-server/issues/63. i just made a PR to fix it https://github.com/coinos/coinos-server/pull/64.

@alltheseas you can close this. Zaps are finally working with coinos lightning addresses!
https://github.com/coinos/coinos-server/pull/64

@SamSamskies lmk if more attention needed

Thank you @asoltys


Help needed

Hi. How can I change the icon of my app (Soube) for a new one that I'm trying to add ?. Thanks

The basics:

fork this repository
in your fork, overwrite the icon file in question. You can do this on the master branch, or a feature branch if you like.
git commit and git push
open a pull request.

You can probably also accomplish all of this using the GitHub web interface.
Here's some info about how to open a pull request:
https://help.github.com/articles/creating-a-pull-request/
And here are some details about submitting apps to this repo:
https://github.com/electron/electron.atom.io/blob/gh-pages/CONTRIBUTING.md#adding-an-app-or-project-to-the-site

Oh I see you already opened a PR: https://github.com/electron/electron.atom.io/pull/560 -- we can get that sorted for you.

Do you want to use the dark version or the transparent version?

oooh thankyou so much for the steps, I will save them as a bible :). Yes @zeke, I'd like the dark version :)


Add Crystal

In https://github.com/travis-ci/travis-ci/issues/4056 @BanzaiMan suggested this community supported languages approach instead.
This PR is an attempt at that.
/cc conscripted from IRC support group @asterite, @jhass, @waj

Whoa! That was quick! Thank you for the PR. I will take a look at this tomorrow.
<3

ping @BanzaiMan

Hi, @will, sorry for the delay.
This PR has been deployed to staging. Go to https://staging.travis-ci.org and set up a repo to use it, and add language: crystal to test it. If the language is not properly detected, it probably means the staging environment is used for something else, and it'll have to be re-deployed.

Well, that didn't work out well :/ https://staging.travis-ci.org/jhass/crystal#L167

OK. The latest version was deployed to staging. Simply rerun the failed build; it should use the latest build script.

Alright, that looks better. Travis ships LLVM 3.4, which is too old for us, we either need a patched 3.5 or 3.6.
Maybe we can just pull it from the qualification branch at http://llvm.org/apt/

For the record, we think the error @jhass is seeing is because of using the compiler itself as the test case. The LLVM version the is statically linked, so the version on travis shouldn't matter.
I have one up here https://staging.travis-ci.org/will/travis-test-crystal/jobs/431005 and it looks like it's working except for the postgres requirement which is out of scope and maybe an issue only on staging?

Yup, strike my last comment, my testcase being crystal itself is what needs a recent LLVM, regular crystal projects don't, sorry for the confusion.

With a proper setup for postgres again, my specs work! https://staging.travis-ci.org/will/travis-test-crystal/builds/431008

Great. Sounds like we are ready to roll this out.
We'll need a PR for document outlining how to use it (a la http://docs.travis-ci.com/user/languages/r/; https://github.com/travis-ci/docs-travis-ci-com/blob/gh-pages/user/languages/r.md). I would also like a few bits about the Crystal language (required) and a thing or two about the community supporters (optional) to add to the blog post announcing the availability.

Plan to push this on 2015-06-29, along with Perl6.

Crystal is a programming language that focuses on developer productivity, type safety, and execution performance. It is statically checked and compiles to native (machine) code. It combines global type inference, compile-time macros, compile-time type introspection, automatic union types, and Ruby-like syntax, allowing quick prototyping and generating efficient computer programs. It provides a Garbage Collector, uses LLVM as its backend, and doesn’t run on a Virtual Machine.

This is slightly edited from @asterite's upcoming talk description but is also a good fit for post I think.

@will Thank you!

Hi, @will,
Does Crystal have a symbol/mascot (not a logotype)?

@BanzaiMan Not a simple picture, as far as I know. I took all the things that make up the logo on crystal-lang.org, and put it into one javascript blob if you're willing to use that. http://codepen.io/anon/pen/dodbQQ

@BanzaiMan @will These are the "official" ones. We'll later put them in the repository or somewhere related to it.

Nice https://travis-ci.org/will/crystal-pg/builds/69019498 working great in prod travis.
Also now that you can test crystal in travis, you should rewrite travis in crystal :)

@will Just tried it and it works perfectly fine :-)


Can we treat ALL computation return types as multi-message (e.g. OneToMany) in the language APIs?

cc @aturley @JONBRWN @jtfmumm @SeanTAllen @slfritchie @dipinhora @nitbix
tl;dr
What would the overhead be, in terms of performance, code complexity, code change, and user ergonomics if we treated ALL computation return types as multi-message arrays in the (non-pony) language APIs?
Background
While in Pony, the difference between a single-message and multi-message is in the return type (e.g. output vs. [output1; output2; ...], with the output signature as (Output | Array(Output) val | None)), in the Python API, and so far also in the Go API Prototype, this distinction is handled by the function name (e.g. compute(...) vs. compute_multi(...)).
From the API perspective, it seems like it would be easier to treat all outputs as Array[Output] val | None, with the single-output case being an array of 1.
For Python, this difference would look like:
Current API:
class MyComputation
    def compute(...):
        # do stuff
        return output1

    def compute_multi(...):
        # do stuff
        return [output1, output2, ...]

Suggested change:
class MyOneToOne
    def compute(...):
        # do stuff
        return [output1]

class MyOneToMany
    def compute(...):
        # do stuff
        return [output1, output2, ...]

Potential Issues

Will this incur a performance overhead?

At the language API interface?
In Wallaroo?

Can we make it easy to identify cases where users accidentally return a list type that is supposed to be a single output (e.g. my_output_list instead of [my_output_list])?
Should we allow users to return non-list types as objects, and handle that as a "clearly, this was meant to be [object]" behind the scenes?

** Potential Benefits**

The ergonomics are simpler on the user side of the API. All return types are multi-message.
The API no longer needs to try and determine the difference between compute_multi and compute.
If all outputs as multi-message outputs, this potentially reduces the number of possible code paths we have to maintain, and test.
At least initially, this can probably be done entirely at either the language API library (e.g. wallaroo.py for Python) or the compiled API (e.g. machida for Python), so it wouldn't require changes to core Wallaroo code.

Yes, there is a performance cost. It will be hit at the Wallaroo level.

I agree with @SeanTAllen about the problems with such a change to non-Pony APIs, but I'll also add that either way I'm against this change at at the Pony API level, since with the Pony API, we use the difference between Out and Array[Out] to distinguish between an output that has type Out: Array[V] and a one-to-many result of type Array[Out].  It sounds like you're only suggesting it for the non-Pony APIs, but just in case.

Ah, I did not think of fractional message tracking!


Mom: Import all the images

There are alot of images in the level assets,. I'm working on it.

It looks like this system is used more heavily for IA also.  I have done the main import but there isn't much audio, and interestingly I can't find a font.

Font Bitmap?

You fix may already resolve this but I wanted to just add another instance of image not loading properly. It should be all symbols and no numbers.

@slycozzolino Did that happen on Android or on your Windows version?

Windows

That is a different issue, I have raised #767 .

Are there plans to add images/textures to the other puzzles aswell?
They are perfectly functional (as is the code puzzle) but having a bit more texture would help with immersion as it does in the official app.

https://github.com/NPBruce/valkyrie/issues/354

Thanks redwolf!


Delayed message delivery doesn't work in Python.

Describe the bug
Messages sent using the Python client, 2.6.3 that specify a value in the deliver_after parameter are delivered immediately to any attached consumer.
To Reproduce
Steps to reproduce the behavior:

Start a consumer in a separate thread that is consuming from a topic
Run the code below to publish messages to the same topic
Observe that the consumer immediate processes the messages that were supposed to be delayed.

Expected behavior
The messages that were sent were supposed to be delivered at a later point in time.
Screenshots
Desktop (please complete the following information):

OS: MacBook Pro
Python3.8
Pulsar-client 2.6.3 (anything higher doesn't work)

Additional context
== = Consumer code =====
client = pulsar.Client('pulsar://localhost:6650')
consumer = client.subscribe(
'persistent://public/default/my-topic',
'my-subscription',
consumer_type=pulsar.ConsumerType.Exclusive,
initial_position=pulsar.InitialPosition.Latest,
message_listener=None,
negative_ack_redelivery_delay_ms=60000)
while True:
msg = consumer.receive()
try:
print("Received message '%s' id='%s'", msg.data().decode('utf-8'), msg.message_id())
if msg.properties() is not None:
print(msg.properties())
consumer.acknowledge(msg)
except:
consumer.negative_acknowledge(msg)
client.close()
=== Producer code =====
client = pulsar.Client('pulsar://localhost:6650')
producer = client.create_producer(
'persistent://public/default/my-topic',
producer_name='delayed-python-producer')
for i in range(10):
producer.send(
('Hello-in-the-future-%d' % i).encode('utf-8'),
properties={"key1": "delayed-5-hours"},
deliver_after=timedelta(hours=5))
client.close()

pulsar.ConsumerType.Exclusive not support delayed message，you can try share mode

The issue had no activity for 30 days, mark with Stale label.


#817 - removing oracle database dependency

This PR is related to https://github.com/apache/incubator-kie-issues/issues/817
Related PR:

https://github.com/apache/incubator-kie-kogito-runtimes/pull/3369

@porcelli I see that rather than removing the Oracle driver, we are completely removing Oracle db support.
To be honest, I would have been more conservative, because there is not actually source code depending on oracle stuff to support oracle (since we are using JPA).
So, It would have been posible to leave references to Oracle and just remove the driver from the repo.

@porcelli
We spent quite amount of time on avoiding code duplication for Oracle and Postgresql and we will have to spent again when in future community ask for oracle support (as they already did in the past, the oracle support, a lot of copy paste from postgres that was later refactor, was added by community folks on their spare time) . I do not really see the problem on just removing the driver and test and keep the source code that does not depend on the driver.

note: community may ask for support and we might not be able to cover the request for legal reasons....
my perspective is to not have unused code left behind just because... that's the value of version control (we can always revert if different interpretation of category X is provided)

Already implemented


Fix pytest deprecation warnings.

The diff is huge because of reformatting. May be worth first merging #846.  But just fixed some deprecation warnings (numpy.product, numpy.math, converting size one array to scalar)  emitted by pytest.

@mpharrigan needs approval


Application state machine

Form answer states rework.

All states/transitions should be handled by state machine.
Removed the withdrawn as duplicated, actually it's on state attribute.
Added proper filters per Admin

That's a partial pr, there are some things to clarify but I would love to push this code (even if not in 100% complete) to collect thoughts from the Michael and avoid a massive PR's.
TODO:

eligibility handing
clarify the year issue
add assessor filters - sep. story
collect feedack from Michael

One note above ^. Other things are good :+1:

@RuslanHamidullin fixed, thanks


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v5.9 to before v5.10.54",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=aa8d3a716b59db6c1ad6c68fb8aa05e31980da60",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ca9ba1de8f09976b45ccc8e655c51c6201992139"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "aa8d3a716b59db6c1ad6c68fb8aa05e31980da60",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "ca9ba1de8f09976b45ccc8e655c51c6201992139",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "xdp, net: Fix use-after-free in bpf_xdp_link_release\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.10.54 by commit ca9ba1de8f09976b45ccc8e655c51c6201992139, it was introduced in version v5.9 by commit aa8d3a716b59db6c1ad6c68fb8aa05e31980da60. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1001246


Get sender address for stateinit

How can i get an address which will be used to send an internal message in Sendbox?

May I know the context for the sender's address?

Sender's address- is an address of a contract, used in a sandbox to send an internal message.

I'll figure it out how should I make it usable in a cell and will update you.

Within the newly introduced logger window, you'll immediately spot the owner's address prominently displayed.

Now we are displaying the connected wallet address even for the sandbox.


Issue/3885 to from int (#3953)

Pull request opened by the merge tool on behalf of #3953

Merged into branches iso4 in 340afb255dc793446fe4d9bd98e34853d88e8634


No way to perform gzip compression with this package?

I don't know if it is just me, but I would find it natural if this package was also performing optional gzip compression. I looked at the SVGO plugins and none of them seem to be concerned with gzipping. Did I miss something?

I don't know. This plugin supports whatever the SVGO API supports → https://github.com/svg/svgo/issues/new


In list of cards, the shadow grows ever longer

node, npm, react-native, react and native-base version
    "native-base": "^2.7.1",
    "react": "16.4.1",
    "react-native": "0.56.0",

Expected behaviour
In a list of cards, all cards have the same shadow thickness, unless otherwise specified
Actual behaviour
The shadow grows for each subsequent card in a list.

Steps to reproduce should include code snippet and screenshot
{_.map(props.content, c => (
  <NB.Card key={c.id} style={styles.menu}>
    <NB.CardItem cardBody button onPress={() => props.open(c)} style={styles.cardItem}>
      <NB.Text style={styles.menuText}>{c.title}</NB.Text>
    </NB.CardItem>
  </NB.Card>
  )}

Is the bug present in both iOS and Android or in any one of them?
This happens in Android. I can't test on iOS on the latest version of NB because the RN 0.56 dependency causes issues with other libs (rn-firebase).
Any other additional info which would help us debug the issue quicker.

@paour

The shadow grows for each subsequent card in a list.

This can be more clear if you share GIF

This effect does not happen only during scroll, all you need is a list of cards. I've annotated the screenshot to clarify.

@paour Can you check this on device?
Simulator / Emulator sometimes render these glitches

Yes, it's the same on-device. Here, in another app on my phone.

Checked this with React Native View, behaves same
          <View style={{elevation: 3, marginBottom: 15, borderWidth: 0.5, borderColor: '#ccc' }}><Text>Text</Text></View>
          <View style={{elevation: 3, marginBottom: 15, borderWidth: 0.5, borderColor: '#ccc' }}><Text>Text</Text></View>
          <View style={{elevation: 3, marginBottom: 15, borderWidth: 0.5, borderColor: '#ccc' }}><Text>Text</Text></View>
          <View style={{elevation: 3, marginBottom: 15, borderWidth: 0.5, borderColor: '#ccc' }}><Text>Text</Text></View>
          <View style={{elevation: 3, marginBottom: 15, borderWidth: 0.5, borderColor: '#ccc' }}><Text>Text</Text></View>
          <View style={{elevation: 3, marginBottom: 15, borderWidth: 0.5, borderColor: '#ccc' }}><Text>Text</Text></View>
          <View style={{elevation: 3, marginBottom: 15, borderWidth: 0.5, borderColor: '#ccc' }}><Text>Text</Text></View>

So it's a RN bug? Sorry I didn't think to check that first!

yes, it is
I will link in the RN issue in a minute

https://github.com/facebook/react-native/issues/20501


⚠ ClamAV has degraded performance

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

HTTP code: 200
Response time: 84 ms

Resolved: ClamAV performance has improved in 4bd577e.


get_resource_allocation_info on complete_job only accounts for 1 type of artifact

There are commands that yield multiple outputs and the complete_job only takes into account the first one, which means that if there are a lot of large resulting artifacts it will not complete on time. One option is to loop over all resource allocations for all artifacts and add the resources; note that this is only an issue with time, not memory.

After a detailed review of the complete_jobs in qiita showed that most of the complete jobs used less than 1G; these are all the complete_job types over 1G:

Thus, the solution to this issue was to make the default to use 4G (accounting for the multi-type artifacts, as shown in the above table) and add specific, smaller allocations for the rest.


Strengthen mutable_set_v5 expect test against timing differences

The internal STM test mutable_set_v5.ml is currently run with --verbose which includes timing (0.0s) and subsequently diffed as an expect test. This creates the possibility of test failures due to a timing difference if it is run on a particular slow (CI) machine.
I just had this happen to me on the CI of an unrelated branch which happened to take 0.1s instead:
https://github.com/ocaml-multicore/multicoretests/actions/runs/6946194440/job/18897107446
STM test exception during next_state sequential failed with Random_next_state_failure as expected
STM test exception during next_state parallel failed with Random_next_state_failure as expected
diff --git a/_build/default/test/mutable_set_v5.expected b/_build/default/test/mutable_set_v5.output
old mode 100755
new mode 100644
index 84ab110..ef19a64
--- a/_build/default/test/mutable_set_v5.expected
File "test/mutable_set_v5.expected", line 1, characters 0-0:
/usr/bin/git --no-pager diff --no-index --color=always -u _build/default/test/mutable_set_v5.expected _build/default/test/mutable_set_v5.output
Command exited with code 1.
File "test/mutable_set_v5.expected", line 1, characters 0-0:
/usr/bin/git --no-pager diff --no-index --color=always -u _build/default/test/mutable_set_v5.expected _build/default/test/mutable_set_v5.output
Command exited with code 1.
+++ b/_build/default/test/mutable_set_v5.output
@@ -1,6 +1,6 @@

random seed: 229109553
 generated error fail pass / total     time test name
-
[ ]    0    0    0    0 /  100     0.0s STM sequential tests
[ ]    0    0    0    0 /  100     0.0s STM sequential tests (generating)
[✗]    2    0    1    1 /  100     0.0s STM sequential tests
+
[ ]    0    0    0    0 /  100     0.0s STM sequential tests
[ ]    0    0    0    0 /  100     0.0s STM sequential tests (generating)
[✗]    2    0    1    1 /  100     0.1s STM sequential tests

 --- Failure --------------------------------------------------------------------

Error: Process completed with exit code 1.

This little PR therefore removes the --verbose option for this expect test.

CI summary for 790cc71:

FP 5.1 triggered a segfault in negative Lin CList int64 test with Effect #394 #416 (bug fixed on trunk)

Out of 63 workflows, 28 succeeded, 34 were canceled, 1 failed with a genuine failure

CI summary for 73d172c:

MinGW bytecode trunk timeout during threadomain #203
MinGW trunk failed - but is missing the relevant CI log!
Cygwin 5.1 / part1 was cancelled
Cygwin trunk / part1 was cancelled
macos-arm64-5.0 found an unexpected counterexample in STM Sys test parallel #359

Out of 63 workflows, 58 succeeded, 2 were cancelled, 3 failed with 1 genuine error, 1 false alarm, 1 unknown (CI flaky)

CI summary for merge to main:

Cygwin trunk / part1 failed with what looks like a network issue: InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
freebsd-amd64-5.1 timed out during 12444.9s Lin Out_channel test with Domain #378

Out of 38 workflows, 2 failed with 1 borderline testsuite/ocaml5 issue, and 1 CI network issue


matrix-synapse-unwrapped: 1.95.0 -> 1.95.1

Diff: https://github.com/matrix-org/synapse/compare/v1.95.0...v1.95.1
Changelog: https://github.com/matrix-org/synapse/releases/tag/v1.95.1
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Tagging as security-relevant because of CVE-2023-43796.


Fix grep matching when uninstalling unwanted deps

exact matching for start and end of line caused versioned packages to not be detected, for example grep ^openssl$ doesn't detect openssl@3

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/membraneframework/elixir?version=dev:a52b308c870c77cf7e69c22386a67d01672cedd2

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/membraneframework/elixir?version=dev:a52b308c870c77cf7e69c22386a67d01672cedd2

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/membraneframework/elixir?version=dev:a52b308c870c77cf7e69c22386a67d01672cedd2

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/membraneframework/elixir?version=dev:b7e8367627045f49b6bde1fa3a6ab8693c221318

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/membraneframework/elixir?version=dev:b7e8367627045f49b6bde1fa3a6ab8693c221318

Your orb has been published to the CircleCI Orb Registry.
You can view your published orb on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/membraneframework/elixir?version=1.4.4


Improve assertions and fix NameTest class

Changed log

Improve assertions about assertDirectoryNotExists and assertDirectoryExists.
Fix namespace for NameTest class.
Add pull_request trigger on GitHub action.
To install latest Psalm version, it should define ^3.7 for psalm dependency.

Thank you


Improve Support For Gradual Monolith Decomposition

Last Issue for the Day! I promise.. Probably.... And it'll be a long one, since it's an entire feature request/handling adjustment.
Plugging in Spring One again, but when I attended the Spring Modulith Deep Dive, I realized that although yes, Spring Modulith helps build more Modular Applications, if applied right it allows you to deconstruct Non-Modular Applications. For those with Medium, this Article  is a real-life example of the approach I'm trying to model.
Poor Monolithic Construction has been a long standing pain for many Java Developers. In some cases you'll be locked into Java 8 and Spring Moduliths can't do anything. However with additional handling from @ApplicationModule you could begin defining domain boundaries. From my perspective this is a perfect way to take a Monolith, isolate a Domain, enforce that isolation with Spring-Modulith, and then either extract it to a Microservice, or move to the next domain. Likewise it provides extensive Automated Documentation along the way to help keep the Architects/Developers feeling better about the isolation efforts due to the nature of Spring Modulith.
Having better/clearer support for this idea of a "partially" modular project would be a great addition to the Project. I admit I haven't reviewed the automatic Documentation to the point where I feel like this is possible, however as someone who wants to decompose their Monoliths, the following would be very nice.
Adjust @ApplicationModule
If @ApplicationModule had a Boolean enforce() default true; attribute, it would let partial modules exist in a more comfortable space. I view this in the same way I view TypeScript's --noImplicitAny, in that seeing it is a red flag, but some projects are in the state where they need the red flag.
Behavior Adjustments
Lets use 3 modules. Assume the full path for @ApplicationModule. These modules exist within a larger project.
@ApplicationModule(enforce=true, allowedDependencies = "inventory, package")
package example.order;
// Uses InventoryService and PackageService, Exposes OrderService

@ApplicationModule(enforce=false)
package example.inventory;
// Exposes InventoryService

@ApplicationModule(enforce=false)
package example.package;
// Exposes PackageService

Now lets view the potential results of the following, using the ApplicationModules Type as a reference
var modules = ApplicationModules.of(Application.class);
modules.forEach(System.out::println);

## example.order ##
> Logical name: order
> Partial Module: false
> Base package: example.order
> Partial Module Imports: inventory, package
> Spring beans:
  + …OrderService
> Leaky Imports:
  + …InventoryService
  + …PackageService

## example.inventory ##
> Logical name: inventory
> Partial Module: true
> Base package: example.inventory
> Spring beans:
  + …InventoryService

## example.package##
> Logical name: package
> Partial Module: true
> Base package: example.package
> Spring beans:
  + …PackageService

In this case we see that each module now includes the following (Only if at least one "partial" module exists)

Partial Module: Inverse Mirror of the enforce Property in @ApplicationModule, it describes that we haven't isolated the entire module's domain, and undefined boundaries might "leak" in through this module.
Partial Module Imports: Any of the allowedDependencies in the @ApplicationModule where enforce is false.
Leaky Imports: Any Imported Beans from Partial Modules, which have the ability to "leak" the unmanaged code.

If Order were to be an allowedDependency for a new Module, OrderService should be considered a Leaky Import, due to Order not being a fully Isolated Module when you review the Dependency chain. However it would not show up in Partial Imports, as it only has beans declared from other ApplicationModules.
I'm not sure how to adjust ApplicationModules.of(Application.class).verify() to reflect this. But I believe the snippet on the left should fail the test if any "partial" modules are detected, or "leaky" beans.
To sum this all up. Current Spring Modulith Behavior should not change. Default Behavior should not allow Partial Modules. This is an explicit "opt-in" sort of feature, which is targeted at Users who can't refactor an entire Monolith, but have a need/drive to isolate 1 or more domains.

Thanks for writing this up. I have to admit that I am a bit lost in the implementation details (annotation attributes, module model output) but I am not quite sure that I understand the conceptual ideas yet. What is a “partial module”? How far would it behave differently than a not-partial (better term needed?) module?
Are you aware of ApplicationModuleDetectionStrategy which allows you to programmatically select application module base packages? It allows you to only return the packages you would want to consider modules. Code living in other packages would not be checked for architectural violations etc.

@odrotbohm Reading this back I will admit the idea is not clear. My fault for not revisiting it later to see if it still made sense when I wasn't in the midst of it.
I've reviewed the ApplicationModuleDetectionStrategy, and it feels like a step towards the idea. The problem is this is less about ignoring/selecting Modules, and more about marking Modules in states of "Purity" or "Cleanliness".
I'll revise the wording by swapping some things around, we'll now have "Clean" Modules, or Modules that have all their dependencies declared and enforced, and "Dirty" Modules, or Modules that might be leaking in other Modules through them, so violations are marked, but not a cause for failure. Not sure what to call modules not enforced by Modulith. Undeclared Modules? Unknown Modules? 🤷🏻♂
Now to reuse my example with the Clean/Dirty Wording instead of Partial

Lets use 3 modules. Assume the full path for @ApplicationModule. These modules exist within a larger project.

@ApplicationModule(clean=true, allowedDependencies = "inventory, package")
package example.order;
// Uses InventoryService and PackageService, Exposes OrderService
@ApplicationModule(clean=false) // clean would be true by default, explicit above for the purpose of the idea.
package example.inventory;
// Exposes InventoryService
@ApplicationModule(clean=false)
package example.package;
// Exposes PackageService

For the output when running ApplicationModules.of(Application.class).forEach(System.out::println);

## example.order ##
> Logical name: order
> Clean Module: false  // Maybe skip this if there are no Dirty Modules? since that would be redundant
> Base package: example.order
> Partial Module Imports: inventory, package
> Spring beans:
  + …OrderService
> Dirty Imports:
  + …InventoryService
  + …PackageService

## example.inventory ##
> Logical name: inventory
> Clean Module: false
> Base package: example.inventory
> Spring beans:
  + …InventoryService

## example.package##
> Logical name: package
> Clean Module: false
> Base package: example.package
> Spring beans:
  + …PackageService

We see that the order module is dirty, because it imports 2 dirty modules. Likewise the inventory and package modules are dirty because we explicitly declare them dirty. The logic being that if I import a dirty module (regardless of how many modules I'm away from it), I'm dirty.
This allows projects to slowly adopt Modulith, while tracking how their dirty modules are being imported across the project This solution is better than the ApplicationModuleDetectionStrategy because instead of ignoring what packages are not part of the Modulith, you're marking what Modules are not being strictly validated, while also noting their use case.
Hopefully the Clean/Dirty wording is clearer than the "Partial". I believe it's better wording since the idea is figuring out what modules are "tracking mud" around the project.

So, now we have attached the clean / dirty labels to modules. What consequences does that have in the context of what Spring Modulith does?

@odrotbohm I understand that the intention is to design a mechanism to gradually transform the existing 'big ball of mud' into a more modular structure.Big mud ball is not a public module.
A one-time refactoring migration is not advisable. The big ball of mud is designated as 'dirty.' Qualified modules are cleaned out from the big ball of mud and labeled as 'clean.' During testing, if clean modules leak into dirty modules, they are marked as damaged. If clean modules do not comply with the rules, an error is reported. A topological diagram can be used to show the modularization process in this way.
// Test: projdct cleanliness x, no error.
example
└── mudball 肮脏的
    ├── entity
    ├── dao
    ├── service
    └── controller

// Test: order is damaged because it is affected by mudball. The cleanliness is x and no error is reported.
example
├── order clean
└── mudball dirty

// Test: order is damaged because it is affected by mudball and inventory . The cleanliness is x and no error is reported.
// The inventory is dirty and violates the xx rules. An error message is reported.
example
├── order clean
├── inventory clean(actually is dirty)
└── catelog dirty

// order is damaged because it is affected by catelog.
// inventory is clean cleanliness x.
example
├── order clean
├── inventory clean
└── catelog dirty

// Test project cleanliness 100 Completed the migration of mud balls to modularization
example
├── order clean
├── inventory clean
└── catelog clean

The English is translated, please forgive me for the wording.

@odrotbohm Sorry for taking so long to reply to this.
I spent several weeks stewing over your comment. Obviously in a Project as large as Spring, Features need purposes beyond "This could be useful", as due to the consumer base and influence Spring has. So I wanted to make sure I thought through this a lot before replying.
And then we had a product launch at work and I forgot to reply till now. 🤦🏻♂
I believe the only impact I concluded it would have in terms of the consumer of the project is usage of @ApplicationModuleTest. Because if there is a Dirty Module, we can't restrict the loading of Modules to have a pure "Vertical" slice, and instead @ApplicationModuleTest is basically @SpringBootTest. Otherwise as noted above me, it's primarily just a built-in tracking strategy for gradual modularization. Instead of manual tracking with an additional ApplicationModuleDetectionStrategy. You could also view it as a ApplicationModuleDetectionStrategy that happens to note down what is being ignored within the main Application Classpath. Which doesn't sound 1/2 bad either.

Thanks, everyone, for their input on this topic. I have a prototype working here that does the following:

Adds an attribute to @ApplicationModule to mark a module as open
Marking a module as open excludes it from checks for cyclic dependencies
References to an open module's internals are allowed. Effectively, all types contained in the module become generally accessible for modules not defining allowed targets explicitly. If they list allowed targets, additional references into open modules are still rejected.

Does that match what you were describing above? For 3., do we need an additional flavor that also drops the violations if a module lists explicit dependencies but refers to an open module without declaring it explicitly?


Unable to sync... anything

Hi,
I'm on Linux and I cannot sync anything...
Is there uninstall docs, I wanna try again but clearing the db you guys probably made in my machine.

Hey @igorgue. Can you try clearing these:
~/.cache/bloop
~/.cache/ai.bloop.bloop
~/.local/share/ai.bloop.bloop

Good shout on uninstall docs. I'll add some - we currently don't have any.

@ggordonhall Clearing those cache paths didn't work for me (mac).

@austinmw On mac the correct path is ~/Library/Caches/ai.bloop.bloop.


Create _2021-10-05-Launch-Announcement-1-1.markdown

Added draft of release announcement for 1.1
TODO

update CLI readme link
update release notes link

Description
Adds a launch blog post for OpenSearch 1.1.
Issues Resolved
opensearch-project#348
By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

@elfisher @stockholmux Any thoughts? I'm sure there are some improvements to made! 😅

@CEHENKLE And let me know if want to see any adjustments!


Add Sinusoidal option for mock data

@ParthivNaresh Great work as usual.

@ParthivNaresh Thanks, I appreciate it


Receive: add per request limits for remote write

Signed-off-by: Douglas Camata<EMAIL_ADDRESS>

[x] I added CHANGELOG entry for this change.
[ ] Change is not relevant to the end user.

Changes
Implement write requests size limits in Thanos Receive.
These limits are applied per request and can be configured with the following
command line arguments:

--receive.write-request-limits.max-size-bytes: the maximum body size.
--receive.write-request-limits.max-series: the maximum amount of series in a
single remote write request.
--receive.write-request-limits.max-samples: the maximum amount of samples in a
single remote write request (summed from all series).

Any request above these limits will cause an 413 HTTP response (Entity Too Large)
and should not be retried without modifications. It's up to remote write clients to
split up the data and retry or completely drop it.
Another limit that was added to control concurrency on the remote write requests:

--receive.write-request-limits.max-concurrency: the maximum amount remote write
requests that will be concurrently processed while others wait.

By default all these limits are disabled.
The flags are also hidden until per-tenant configuration in a file is implemented. A mention that this feature is WIP and might change whenever the per-tenant configuration file lands is present in the Receive docs.
This is a part of the work planned in #5404.
Verification

[x] Added some cases to the Receive's handler tests and they pass.
[x] Running it locally.

Future work

Add support for per-tenant limit configuration

Thx for the review, @fpetkovski. Some comments were taken care off already and I replied to others. 🙇

@saswatamcode I just pushed an update on 58d362b that runs the request limit tests with a 3 node hashring. This should prevent us from changing the batching logic and cause an incoming request that was accepted to hit limits when batched for fanout.
Seems like the fanout requests are now sent via gRPC:

From this part in the handler: https://github.com/thanos-io/thanos/blob/main/pkg/receive/handler.go#L656
It sends this request: https://github.com/thanos-io/thanos/blob/fd275f8ac3d906c4ebb3c3f8be9db8701a71eabd/pkg/store/storepb/rpc.pb.go#L1122
Which ends up calling h.handleRequest: https://github.com/thanos-io/thanos/blob/main/pkg/receive/handler.go#L768

At this point, the limits logic is completely skipped.


Remove old dependency resolution files

I think these are from some old incarnation, surely currently unused.

Oops. I should have rejected this. See #103


Fixing URLSessionNDT7 build issue on Xcode 13 and Xcode 14 😅

So... I got a little carried away and merged https://github.com/m-lab/ndt7-client-ios/pull/85 before testing that it works with Xcode 13. It did not. 😬
Instead of implicitly conforming to Apple's URLSession method (which can break when API changes), we're now explicitly calling URLSession's dataTask method from ndt7DataTask. Tested this change on Xcode 13 and 14. ✅

This change is

@olgagalchenko thinking about this more... let's add @Sendable back to the closure if the code compiles in Xcode 13 and 14. I would need to dig deeper to know for sure but my recollection is that some sendable checking is not fully enabled in Xcode right now. That may explain why we can pass a non-sendable closure to function that expects a sendable closure. It's probably more future-proof to mark this function as @Sendable.

@bachand Agreed! Downcasting ndt7DataTask's completionHandler to @Sendable adds some safety.

I will review tomorrow 👍

I built this branch on Xcode 13.3.1 and Xcode 14 Beta 4. Both builds succeeded!