complex type in API [FromBody] signature incorrectly handled in generated TypeScript as string

Hi,
I'm using:

Swashbuckle package (version 5.6.0) in WebApi 2 .NET project to generate json representation of API -
nswag npm package (version 11.11.3) with swagger2tsclient command to generate TS based on API json representation

nswag swagger2tsclient /Input:swagger.json /Output:src/api.ts /ClassName:{controller}Service /WrapDtoExceptions:true /TypeScriptVersion:2.0 /Template:Angular DateTimeType:Date /GenerateClientClasses:true /GenerateClientInterfaces:true /ImportRequiredTypes:true /BaseUrlTokenName:API_BASE_URL /HttpClass:HttpClient /injectionTokenType:InjectionToken
WebApi controller:
 public async Task<IHttpActionResult> Patch(int id, [FromBody] ComplexType complexType)
 {
       return this.StatusCode(HttpStatusCode.NoContent);
 }

  public class ComplexType
  {
      public int Id { get; set; }
      public string Name { get; set; }
  }

swagger json for this request params is:
"parameters": [
          {
            "name": "id",
            "in": "path",
            "description": "Id",
            "required": true,
            "type": "integer",
            "format": "int32"
          },
          {
            "name": "complexType",
            "in": "body",
            "description": "ComplexType model",
            "required": true,
            "schema": { "$ref": "#/definitions/ComplexType" }
          }
        ],

the problem is that generated typescript code expects complex type as string which isn't right:
patch(id: number, complexType: string): Observable<any> {
generated code also includes TS class definition for ComplexType but as you can see, string type is used instead of ComplexType in TS function parameter
Am I missing something in my setup? do I need to apply some attribute/command switch to ensure generated typescript is using complex type as parameter instead of string?

Everything looks fine to me... can you provide a complete Swagger spec so I can reproduce this?

thanks for quick reply! here it is:
{
  "swagger": "2.0",
  "info": {
    "version": "v1",
    "title": "Api"
  },
  "host": "localhost",
  "basePath": "/Api",
  "schemes": ["http"],
  "paths": {
    "/v1/entities/{id}": {
      "patch": {
        "tags": ["Entites"],
        "summary": "Updates details of the entity for a given entity ID.",
        "operationId": "Entites_Patch",
        "consumes": ["application/xml", "application/json"],
        "produces": ["application/xml", "application/json"],
        "parameters": [
          {
            "name": "id",
            "in": "path",
            "description": "Id of the entity",
            "required": true,
            "type": "integer",
            "format": "int32"
          },
          {
            "name": "updateEntityRequest",
            "in": "body",
            "description": "UpdateEntityRequest model",
            "required": true,
            "schema": { "$ref": "#/definitions/UpdateEntityRequest" }
          }
        ],
        "responses": {
          "200": { "description": "OK", "schema": { "type": "object" } }
        }
      }
    }
  },
  "definitions": {
    "UpdateEntityRequest": {
      "type": "object",
      "properties": {
        "id": { "format": "int32", "type": "integer" },
        "name": { "type": "string" }
      }
    }
  }
}

switching to have application/json first indeed solved it, thanks @RSuter :)

Yep, but it's just a temporary patch until this is fixed...

Release https://github.com/RSuter/NSwag/pull/1325


Always return error when calling API with non-JSON response

$.fn.api.settings.api = {
        'more latest topic': '/topic/more/latest'
    };

Here is the button code
$('.more.topic.button').api({
        method: 'GET',
        action: 'more latest topic',
        data: {
            index: 0
        },
        onSuccess: function(response) {
            console.log(response)
        },
        onError: function() {
            console.log('bad request')
        }
    });

I don't use JSON as response in this sample, just plan text.
When I change response as JSON format, it works well.
screenshot:

You need to specify the data type as text. The default type is json
$('.more.topic.button').api({
        method: 'GET',
        action: 'more latest topic',
        dataType: 'text',
        data: {
            index: 0
        },
        onSuccess: function(response) {
            console.log(response)
        },
        onError: function() {
            console.log('bad request')
        }
    });

http://semantic-ui.com/behaviors/api.html#/settings

@jlukic thanks! it works.


(Final!) refresh of client

Signed-off-by: John Howard<EMAIL_ADDRESS>Hopefully the last refresh before I kill jhowardmsft/opengcs and transition docker over to Microsoft/opengcs instead later this week. Note it's dependent on 34272 which is the rest of docker moving over to lower-case sirupsen\logrus, imminently about to be merged into master there.

@jhowardmsft,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

You might have to git mv the vendor/github.com/Sirupsen folder to be lower case but not sure

Yeah, that's for the server side of opengcs, not the client. There's no vendoring in the client library - the user of the library (docker being the only one currently) is responsible for vendoring which has already been updated :)

Oh. Yuck... I will submit a change for the service side.


[5.1] [ModuleInterface] Propagate availability for synthesized extensions

Cherry-pick of #24753 to the 5.1 branch. Reviewed by @nathawes.
rdar://problem/50748090

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - def7ee6171c214f22cc1a949cd84b719a09af39c

@swift-ci Please test Linux


Updating DockerFile and adding sample for ambassador

Proto needs to be copied for docker to run.
Also, setting some basic variables. And copying data folder with config to the final image.
Adding an Entrypoint for the docker to start.

@Abhishek627 sorry for the delay. I was OOO the last few weeks.
As I see it this PR is solving 3 things:

Fixing the proto issue with the Dockerfile. I am inclined to just get rid of the Dockerfile. I have invested way more time in making sure the entires setup with docker-compose is stable and actually gives a useful setup (with redis included)
Setting up ENV vars in the Dockerfile. I feel similarly about this to point 1.
Adding a config for ambassador. Initially I do not know if we should include ambassador specific stuff in ratelimit, rather than improve ambassador side docs/examples to work with this project. Do you have a preference for putting that here? If we end up putting here I would like to have some documentation around it.

lmk what you think! Thanks for the PR.

@junr03 I understood your reasons for 1 and 2.  For 3rd, I saw too many people asking whether rate limit service can be used with ambassador and thought that it might make sense to include this too, since I made it work for me. I think we can leave it out. Instead, I'll write maybe a medium article about it and you can add it to bottom of the README. Would that be okay ?

https://medium.com/@abhisheksharma_61389/ambassador-lyfts-rate-limit-service-cdf64b4fa371

Thank you so much for writing that @Abhishek627! Awesome, this is going to help a bunch of people.
If you agree with both 1, and 2 do you want to close this PR, or update it to actually deleting the Dockerfile? And do you want to open another PR to link your article? Thanks!

@junr03 I'll close this one and open a new PR with deleting Dockerfile and edited Markdown.


Prometheus crashing on 32bit Arm - tsdb structures not 64bit aligned?

What did you do?
I build prometheus from master, targeting an arm1176jzfshf (RaspberryPi zero W)
What did you expect to see?
I expected it to work. ;-)
What did you see instead? Under which circumstances?
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x97d2a8]
goroutine 206 [running]:
runtime/internal/atomic.goStore64(0x5aca1c4, 0x8, 0x0)
         /usr/lib/go/src/runtime/internal/atomic/atomic_arm.go:144 +0x1c
github.com/prometheus/prometheus/tsdb/chunks.(*ChunkDiskMapper).cut(0x5aca1b0, 0x0, 0x0)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/tsdb/chunks/head_chunks.go:343 +0x114
github.com/prometheus/prometheus/tsdb/chunks.(*ChunkDiskMapper).WriteChunk(0x5aca1b0, 0x1, 0x0, 0x8559439e, 0x172, 0x855ccdde, 0x172, 0x2c385b0, 0x5fbdd40, 0x0, ...)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/tsdb/chunks/head_chunks.go:242 +0xd0
 github.com/prometheus/prometheus/tsdb.(*memSeries).mmapCurrentHeadChunk(0x5dbe000, 0x5aca1b0)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/tsdb/head.go:1988 +0x6c
 github.com/prometheus/prometheus/tsdb.(*memSeries).cutNewHeadChunk(0x5dbe000, 0x855cd5ae, 0x172, 0x5aca1b0, 0x0)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/tsdb/head.go:1962 +0x24
 github.com/prometheus/prometheus/tsdb.(*memSeries).append(0x5dbe000, 0x855cd5ae, 0x172, 0x0, 0x0, 0x119, 0x0, 0x5aca1b0, 0x5c7a0f0)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/tsdb/head.go:2118 +0x3ac
 github.com/prometheus/prometheus/tsdb.(*headAppender).Commit(0x617abe0, 0x0, 0x0)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/tsdb/head.go:1197 +0x1f8
 github.com/prometheus/prometheus/tsdb.dbAppender.Commit(0x2c32620, 0x617abe0, 0x5a7d300, 0x0, 0x21799e0)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/tsdb/db.go:703 +0x24
 github.com/prometheus/prometheus/storage.(*fanoutAppender).Commit(0x5db1560, 0x0, 0x5b2f9b0)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/storage/fanout.go:162 +0x28
 github.com/prometheus/prometheus/scrape.(*scrapeLoop).report.func1(0x5862dd0, 0x2c323a0, 0x5afe2b0)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/scrape/scrape.go:1293 +0x34
 github.com/prometheus/prometheus/scrape.(*scrapeLoop).report(0x5c7b040, 0x4fa38c36, 0xbfaebb5e, 0xf7bcd63d, 0x38, 0x3f255c8, 0x11af903, 0x0, 0x0, 0x0, ...)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/scrape/scrape.go:1311 +0x4b0
 github.com/prometheus/prometheus/scrape.(*scrapeLoop).run(0x5c7b040, 0x77359400, 0x0, 0x77359400, 0x0, 0x0)
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/scrape/scrape.go:986 +0x58c
 created by github.com/prometheus/prometheus/scrape.(*scrapePool).sync
         /opt/yocto/build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/prometheus/1.0-r0/build/src/github.com/prometheus/prometheus/scrape/scrape.go:422 +0x3f8

Environment
yocto poky, dunfell branch, RaspberryPi Zero W

System information:

Linux 4.19.120 armv6l

Prometheus version:
My bitbake recipe isn't populating this yet... but it was built from master @ 6ff4814a492ae6f9e3f5cf7b022a823b631b7a95

prometheus, version  (branch: , revision: )
build user:
build date:
go version:       go1.14.1

Prometheus configuration file:

global:
  scrape_interval: 10s
  external_labels:
    monitor: 'pidroponics-monitor'
scrape_configs:
  - job_name: 'system'
    static_configs:
      - targets: ['localhost:9100']
  - job_name: 'pidroponics'
    scrape_interval: 2s
    static_configs:
      - targets: ['localhost:443']

Fixed in https://github.com/prometheus/prometheus/pull/7365


same size for all popup

it would be nice if the popup could all have the same size. right now, the biggest issue with this size change is that the buttons are not at the same place. users expect the button (at least the OK button) to be at the same place to be able to rapidly clic on it multiple time to validate the remaining screens

note: it seems to already be the case when using chrome, I only have the problem with firefox (can't test on IE/safari right now)


Fixes issue #1438 by adding support for JSON.ParseAsArray(jsonText)

Fixes #1438 by supporting this particular deserialization scenario. I wanted to support IEnumerable but for such general scenario deserialization of collections would require support for Reflection (guess we need to wait for Bridge v2 for that).
Changes proposed in this pull request:

Bridge.merge now has optional parameter(constructor of item prototype)
added JSON.ParseAsArray(jsonText) that is an entry point for "deserialization of array of custom classes"
added Bridge.Compiler.TranslatorTest to verify correctness

I considered modifying JSON.Parse(jsonText) but it would require unsafe casts that's why it is implemented using another method.
As with my former bugfixes - Bridge.Testing is not available so I cannot guarantee it doesn't break anything.

Hi @d-p-y, thank you for this pull request, we will review the changes this week.

Hi Leonid, I found out that my changes broke dictionary enumeration. It is fixed now

Kamil, You are absolutely right. Type constraint is added now.

Hi Dominik, we reviewed and merged this pull request. Thank you for contribution!
Please note, I created a separate issue #1438 to implement the new method JSON.ParseAsArray that is addressed by this pull request. Your original issue #1432 is open, I hope we will fix the original JSON.Parse method at some point.
Many thanks for the test you provided! I just moved it from Compiler tests into Client tests. It is more suitable for Client tests as it can be run and the actual runtime result can be compared to the expected one. We use Compiler tests as there is no difference in runtime results (or very hard to check) but the generated JavaScript matters.

Leonid,
That's fine for me!
Indeed whole issue was about JSON.Parse(string) being able to deserialize arrays. My code is just a working workaround(until we have support for Reflection).
Concerning Compiler vs Client tests - that's fine for me too. I used only available way to test for time being (till Bridge.Test becomes available).
Kind regards
Dominik


No such file or directory "testdata/generated/Metadata.php"

Thanks for stopping by to let us know something could be better!
PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.
Please run down the following list and make sure you've tried the usual "quick fixes":

Search the issues already opened: https://github.com/googleapis/google-cloud-php/issues
Search StackOverflow: http://stackoverflow.com/questions/tagged/google-cloud-platform+php

If you are still having issues, please be sure to include as much information as possible:
Environment details

OS: Shouldn't be OS dependant but ok it is windows
PHP version: 7.4.3
Package name and version: ? what does that even mean?

Steps to reproduce

run in root of nging WWW git clone  https://github.com/googleapis/google-cloud-php.git  which creates WWW/google-cloud-php
CD google-cloud-php then composer update and success complete
copy sample from google-cloud-php/TextToSpeech/src/V1/README.md to sample.php in root of google-cloud-php
navigate to http://localhost/google-cloud-php/sample.php shows error

Code example
<?php
require __DIR__ . '/vendor/autoload.php';

use Google\Cloud\TextToSpeech\V1\AudioConfig;
use Google\Cloud\TextToSpeech\V1\AudioEncoding;
use Google\Cloud\TextToSpeech\V1\SynthesisInput;
use Google\Cloud\TextToSpeech\V1\TextToSpeechClient;
use Google\Cloud\TextToSpeech\V1\VoiceSelectionParams;

$textToSpeechClient = new TextToSpeechClient();

$input = new SynthesisInput();
$input->setText('Japan\'s national soccer team won against Colombia!');
$voice = new VoiceSelectionParams();
$voice->setLanguageCode('en-US');
$audioConfig = new AudioConfig();
$audioConfig->setAudioEncoding(AudioEncoding::MP3);

$resp = $textToSpeechClient->synthesizeSpeech($input, $voice, $audioConfig);
file_put_contents('test.mp3', $resp->getAudioContent());

?>

Error shown on execute
Warning: require(NGINXROOT\google-cloud-php\vendor\composer/../../PubSub/tests/System/testdata/generated/Metadata.php): failed to open stream: No such file or directory in NGINXROOT\google-cloud-php\vendor\composer\autoload_real.php on line 69

Fatal error: require(): Failed opening required 'NGINXROOT\google-cloud-php\vendor\composer/../../PubSub/tests/System/testdata/generated/Metadata.php' (include_path='.;C:\php\pear') in NGINXROOT\google-cloud-php\vendor\composer\autoload_real.php on line 69

@bobsort is the Metadata class included in your installation? I'm not sure why it isn't being found, I just tested on a windows box and the call was successful.
You could try installing without dev dependencies: composer install --no-dev - does that work?

It did work with -no-dev but shouldn't SDK have no dependency to test data?

If you install the package through composer (for example: composer require google/cloud-text-to-speech) as opposed to cloning the repository, then yes, there should be no test dependencies. As to why you received this error, it still isn't clear to me as I'm unfortunately unable to replicate what you've seen.

I figured out the problem just now, the path to file was exceeding 255 character  path length which is not obvious it the error message.
My intention was reducing 127Mb size and 17608 file and 3184 folders to a manageable size. That is why I pull the repo instead.
Since I just needed text-to-speech, after a few modification it is now only 19 files and 3 folders and 43Kb in size


Add support for API calls with non string slice parameters

Thank you for your contribution to Go-AutoRest! We will triage and review it as soon as we can.
As part of submitting, please make sure you can make the following assertions:

[ ] I've tested my changes, adding unit tests if applicable.
[ ] I've added Apache 2.0 Headers to the top of any new source files.
[ ] I'm submitting this PR to the dev branch, except in the case of urgent bug fixes warranting their own release.
[ ] If I'm targeting master, I've updated CHANGELOG.md to address the changes I'm making.

This addresses #207


Made good some translations

supplement:
I think that 'txtStartAt' and 'invalidTime' need to have the information "What is the correct".
So, I added "（秒）" for "(min)", "正の整数で" for "with positive integer".

Thanks!


Dynamic Component Id type

Objective
Currently working with dynamic component ids requires a lot of manual pointer work and unsafe code, which seems unnecessary when dynamic components are registered from known rust code.
Solution
Add a wrapper around ComponentId with a type parameter T to act as a witness that that id corresponds to a component with type T. This allows registering multiple components with the same underlying type, that dynamic queries can access separately in a safe way.

Changelog

added TypedComponentId
added world_id() to all entity cells
added get_dynamic(), get_dynamic_mut(), into_dynamic_mut(), insert_dynamic() as appropriate to entity cells
added init_dynamic_component() to World
added new_dynamic() to ComponentDescriptor

Worth considering, in my prototype I restrict T: Component which lets me choose the storage type from the component without having to specify it manually when creating a new dynamic component. It's such an often overlooked detail it feels weird to me to make people specify it. On the other hand there's definitely value to being able to use any type for the layout, but on the other hand you can always newtype. Restricting T: Component also has the benefit of being more explicit imo.

At least for me one of the key benefits of dynamic components is that they don't require newtyping and new variants can be made on the fly, hence the lack of a Component constraint.

At least for me one of the key benefits of dynamic components is that they don't require newtyping and new variants can be made on the fly, hence the lack of a Component constraint.

I wonder how much more ergonomic that is though, since you have to carry the TypedComponentId<T> everywhere to use them.
Also note that you won't need a newtype for each dynamic component. With a single newtype around e.g. a String you can create as many dynamic components that contain String as you want (as opposed to right now where you need a newtype per-component).

Also note that you won't need a newtype for each dynamic component. With a single newtype around e.g. a String you can create as many dynamic components that contain String as you want (as opposed to right now where you need a newtype per-component).

Taking that to the extreme, you would probably just end up with TableStorageComponent<> and SparseStorageComponent<> newtypes, which should probably just end up as parameters anyway. Unless I'm misunderstanding you (good chance of that tbh). In my experience dynamic components do require the id being passed around, but I don't see a good way to avoid that.

todo:

tests
fix examples/dynamic.rs
link to dynamic.rs from try_insert_dynamic and insert_dynamic doc comment

What is the expected use case here? Untyped components were originally introduced as a way to enable scripting interfaces, but here you have a Rust type. Can you provide a end-user or library use case that requires what are effectively runtime-generated newtype components?

Untyped components were originally introduced as a way to enable scripting interfaces, but here you have a Rust type.

For example if you're implementing scripting using an interpreted language this would let you store multiple components that hold a your_scripting_api::Value

Can you provide a end-user or library use case that requires what are effectively runtime-generated newtype components?
I feel in many use cases for dynamic components we actually do have a known type we want to treat the component as when we access it. As mentioned above many scripting use cases will be defining many of it's components as a shared Value type, but also if you had a simple "Counter" system in a card game where there was a runtime defined set of counters you could put on a certain card entity and you want to be able to query for cards with a given counter on them it could be done entirely safely with an API like this. I think removing the unsafe barrier in as many cases is possible makes it more likely people will actually make use of those features.

My question for this implementation is if we have to check the world id anyway to ensure safety would it be worth it to drop the type wrapper all together and just check whether the type id matches the one you registered it with? That way you can just use component ids everywhere.

What is the expected use case here? Untyped components were originally introduced as a way to enable scripting interfaces, but here you have a Rust type. Can you provide a end-user or library use case that requires what are effectively runtime-generated newtype components?

The author linked this to me when I was asking on the Discord for having dynamic marker types. I would want to make WorldQuery types with this where the component is only relevant for a specific Query.
My library offers a few SystemParams with non-pub Queries in them. Part of the logic requires marker components. But it is impossible for such a component to be unique to every usage of my SystemParam. So I want to use this feature here to newtype () (or maybe non-ZST types) and use it as that unique marker type.
It is still not easy for the SystemParam to learn what the ComponentId of the marker type ended up being. But when my SystemParam initializes it's params, my marker type will have put it's ComponentId in a resource, discoverable by the following logic of the SystemParams init. Once the param knows the ComponentId, it can create Commands that adds and removes them.
Still a bit hacky, probably not what the most obvious use case could be here, but a use case only possible with this.

FYI, I ended up publishing my MVP as bevy_dyn_component. The proposed API is a bit different from this proposal, but has many similarities. The examples highlight one or two potential use cases for this as well, but I think most of them would ultimately be better as relations.

closing, was intended to solve a very niche issue that doesn't exist anymore (at least for me)


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v5.4 to before v5.15",
  "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=99cb0dbd47a15d395bf3faa78dc122bc5efe3fc0",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=74c42e1baacf206338b1dd6b6199ac964512b5bb"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "99cb0dbd47a15d395bf3faa78dc122bc5efe3fc0",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "74c42e1baacf206338b1dd6b6199ac964512b5bb",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "mm, thp: bail out early in collapse_file for writeback page\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.15 by commit 74c42e1baacf206338b1dd6b6199ac964512b5bb, it was introduced in version v5.4 by commit 99cb0dbd47a15d395bf3faa78dc122bc5efe3fc0. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1002194


Add prometheus metrics module

Motivation:
Add prometheus metrics module.
Modification:
Describe the idea and modifications you've done.
Result:
Fixes #.
If there is no issue then describe the changes introduced by this PR.

辛苦解决一下冲突。


Struggling to send first report

Sentinl and Kibana version
6.2.2
Issue description
Trying to create my first report that would look at exception log and send 5 endpoints that have happened the day before
Reproducing the issue step-by-step
I've got the following query which works just fine in Kibana Dev Tools as expected:

{
  "size": 0,
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-1d/d",
        "lt": "now/d"
      }
    }
  },
  "aggs": {
    "URI": {
      "terms": {
        "field": "URI.keyword",
        "size": 5
      }
    }
  }
}

I went to Sentinl app in Kibana and created a new Watcher.
Added a random name and left default schedule of every 5 minutes
Created the following input:
{
  "search": {
    "request": {
      "indices": [
        "error-*"
      ],
      "body": {
        "size": 0,
        "query": {
          "range": {
            "@timestamp": {
              "gte": "now-1d/d",
              "lt": "now/d"
            }
          }
        },
        "aggs": {
          "URI": {
            "terms": {
              "field": "URI.keyword",
              "size": 5
            }
          }
        }
      }
    }
  }
}

Left conditions and transformations empty
Added a Slack Action with defaults
Saved the whole thing.
Tried to execute watcher from UI and got the following exception:
Error: fail to get watcher 73c555c0-28ee-11e8-b3e5-5be74be89621
    at Watcher.<anonymous> (http://lv-elastic1-uk:5601/bundles/sentinl.bundle.js?v=16588:1:280080)
    at tryCatch (http://lv-elastic1-uk:5601/bundles/vendors.bundle.js?v=16588:121:99780)
    at Generator._invoke (http://lv-elastic1-uk:5601/bundles/vendors.bundle.js?v=16588:121:101855)
    at Generator.prototype.(anonymous function) [as throw] (http://lv-elastic1-uk:5601/bundles/vendors.bundle.js?v=16588:121:100064)
    at step (http://lv-elastic1-uk:5601/bundles/sentinl.bundle.js?v=16588:1:276251)
    at http://lv-elastic1-uk:5601/bundles/sentinl.bundle.js?v=16588:1:276412

Expected results vs. actual results
I'd expect this to trigger an alert, however I'm getting an exception
Sample of data
Query response:

{
  "took": 221,
  "timed_out": false,
  "_shards": {
    "total": 10,
    "successful": 10,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1803,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "URI": {
      "doc_count_error_upper_bound": 31,
      "sum_other_doc_count": 1428,
      "buckets": [
        {
          "key": "www.company.com/portal/results",
          "doc_count": 91
        },
        {
          "key": "www.company.com/api/search",
          "doc_count": 90
        },
        {
          "key": "www.company.com/portal/analysis/downloadpdf",
          "doc_count": 75
        },
        {
          "key": "www.company.com/portal/account/login",
          "doc_count": 60
        },
        {
          "key": "www.company.com/portal/analysis/tab",
          "doc_count": 58
        }
      ]
    }
  }
}

Additional details
/etc/kibana/kibana.yml has the following config:

sentinl:
  es:
    host: localhost
    port: 9200
    timefield: '@timestamp'
    default_index: watcher
    default_type: sentinl-watcher
    alarm_index: watcher_alarms
    alarm_type: sentinl-alarm
    script_type: sentinl-script
    results: 50
  settings:
    slack:
      active: true
      username: Sentinl
      hook: 'https://hooks.slack.com/services/remaining_part_of_webhook'
      channel: '#channel'
    report:
      active: true
      tmp_path: /tmp/
      search_guard: false
      simple_authentication: false

Hi @buinauskas the issues appears to be with saving - could you kindly check and append the Kibana logs for your save action? You might have to edit or recreate the watcher to capture those steps - thanks!

@buinauskas Field indices is deprecated, use index in the search query. For example
{
  "search": {
    "request": {
      "index": [
        "error-*"
      ],
...

Let me know.

Changing indices to index and adding a dummy script condition has resolved it:
{
  "script": {
    "script": "payload.hits.total > 0"
  }
}


Reading from Sector Trailer, Key A always return 0x00 00 00...

MFRC522 Library version: 1.4.4
MFRC522 device: MFRC522

When I read from Sector Trailer, the Key A always return 0x00 00 00 00 00 00, but the correct Key A is 0xFF FF FF FF FF FF, is it normal? Only the access bits and Key B return normal.
I have tried several card, the Key A also return 0x00.

Dump returns the raw data. The key is stored in a different way according to the tag specification. Normal mifare card inverts data at some points.


Docker container fails to launch browser on startup.

[x] I am using the latest version of the program.
[x] I have read the Known-issues section and Issues page, and made sure that this problem was not already described elsewhere.

Describe the bug:
After cloning this repository and running docker compose up -d the container errors.
Steps to reproduce the behavior:

Clone this repo
Run with docker compose up -d

Expected behavior:
The container should run the same as when the discord bot is launched with ./CharacterDiscordBot
System Info

Error Log from Container
2023-06-13T02:53:39.082169077Z 02:53:39 Discord     Discord.Net v3.10.0 (API v10) 2023-06-13T02:53:39.102170444Z 02:53:39 Gateway     Connecting 2023-06-13T02:53:40.016599244Z 02:53:40 Gateway     Connected 2023-06-13T02:53:40.514808989Z 02:53:40 Gateway     Ready 2023-06-13T02:53:40.531294496Z  2023-06-13T02:53:40.531329761Z It may take some time on the first launch, because it will need to download a Chrome executable (~450mb). 2023-06-13T02:53:40.531334555Z If this process takes too much time, ensure you have a good internet connection (timeout = 20 minutes). 2023-06-13T02:53:40.531337440Z  2023-06-13T02:53:44.499190902Z Downloading browser... OK 2023-06-13T02:53:44.508381269Z  2023-06-13T02:53:44.508427537Z (If it hangs on for some reason, just try to relaunch the application) 2023-06-13T02:53:44.572651993Z Launching browser... PuppeteerSharp.ProcessException: Failed to launch browser!  2023-06-13T02:53:44.572677338Z    at PuppeteerSharp.States.ChromiumStartingState.StartCoreAsync(LauncherBase p) in /home/runner/work/puppeteer-sharp/puppeteer-sharp/lib/PuppeteerSharp/States/ChromiumStartingState.cs:line 83 2023-06-13T02:53:44.572680548Z    at PuppeteerSharp.States.ChromiumStartingState.StartCoreAsync(LauncherBase p) in /home/runner/work/puppeteer-sharp/puppeteer-sharp/lib/PuppeteerSharp/States/ChromiumStartingState.cs:line 89 2023-06-13T02:53:44.572683276Z    at PuppeteerSharp.Launcher.LaunchAsync(LaunchOptions options) in /home/runner/work/puppeteer-sharp/puppeteer-sharp/lib/PuppeteerSharp/Launcher.cs:line 62 2023-06-13T02:53:44.572685915Z    at PuppeteerSharp.Launcher.LaunchAsync(LaunchOptions options) in /home/runner/work/puppeteer-sharp/puppeteer-sharp/lib/PuppeteerSharp/Launcher.cs:line 95 2023-06-13T02:53:44.572688505Z    at PuppeteerExtraSharp.PuppeteerExtra.LaunchAsync(LaunchOptions options) 2023-06-13T02:53:44.572691198Z    at CharacterAI.Integration.LaunchChromeAsync(String customChromeDir, String customExecPath) 2023-06-13T03:03:34.341988856Z    at CharacterAI_Discord_Bot.Program.LaunchChromeAndSetup(Boolean setup) in /app/Program.cs:line 57

Alright, I'll take a look at it.

I submitted a pull request, check it out.


Attestation minting does not take into account fail TX

I'm submitting a ...

[ ] bug report
[ ] feature request
[ ] support request => Please do not submit support request here, see note at the top of this template.

What is the current behavior?
When a TX fails, the loading does not stop

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
Create an attestation, then try to create another attestation with the same calculation scores, it should fail due to it being exactly the same.

What is the expected behavior?
Loading modal shows that the transaction failed and does not keep loading forever

What is the motivation / use case for changing the behavior?
UX

picking this up


docs: In the example, S3 endpoint should be a gateway, not interface

Description
The documentation implies that the S3 endpoint is an interface, but it's actually a gateway
https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html
Motivation and Context

I spent some time debugging an issue where my ECS Fargate task wasn't able to pull images from S3, and this was the issue.
Breaking Changes

How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects

[ ] I have executed pre-commit run -a on my pull request

the S3 endpoint can be either a gateway endpoint or an interface endpoint. The example is correct as its stated, its just demonstrating the gateway version


WS-164 [Modal Connector] Wagmi and Web3modal error

Type of MR:

[ ] Feature
[x] Fix
[ ] HotFix

Small description:

Use patch releases on @wagmi/core @web3modal/ethereum and @web3modal/html to prevent breaking changes

Checklist:

[x] My code follows the styleguides of the project (successfully pass linters)
[x] I tested my code.
[ ] I commented/docummented my code in a way that complex parts are explained.
[ ] If required, i updated project's README file.
[ ] I added/updated tests that tests my changes in code.
[x] All previous and new tests pass.
[ ] I commit any new dependency.
[ ] I updated UML diagram in confluence if any model was modified in this MR.

Codecov Report

Merging #64 (18bcb4d) into develop (502d940) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff            @@
##           develop      #64   +/-   ##
========================================
  Coverage    99.45%   99.45%
========================================
  Files           38       38
  Lines         1280     1280
  Branches       305      305
========================================
  Hits          1273     1273
  Misses           7        7

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Cannot install sstsne

Hello,
I have been trying to install your repository for Semi Supervised t-SNE and I've been running into an error that prevents me from completing the install.
Here is the error message :
17.36 sstsne/_barnes_hut_tsne.c:25840:13: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘exc_traceback’; did you mean ‘curexc_traceback’? #9 17.36      tstate->exc_traceback = *tb; #9 17.36              ^~~~~~~~~~~~~ #9 17.36              curexc_traceback #9 17.50 In file included from /usr/local/lib/python3.8/site-packages/numpy/core/include/numpy/ndarrayobject.h:21, #9 17.50                  from /usr/local/lib/python3.8/site-packages/numpy/core/include/numpy/arrayobject.h:4, #9 17.50                  from sstsne/_barnes_hut_tsne.c:267:
The same error happens for exc_type and exc_value.
I've tried the install on both Windows 10 and Linux Debian.
My configuration is as follow:

Python 3.7 and 3.8
Cython 0.29.23 and 0.29.24
libgfortran5 amd64 8.3.0-6
libopenblas-base amd64 0.3.5+ds-3
libopenblas-dev amd64 0.3.5+ds-3

Thanks in advance,
Constance

Forcing the regeneration of _barnes_hut_tsne.c on Linux (by removing the file before launching the install) resolved the issue and I was able to complete the install.
From my understanding, this is due to an incompatibility between previous Cython versions (likely used when this repo was made) and newer python version (above 3.7, I think).
Unfortunately, this wasn't enough to solve the issue on Windows, it lead me to another error having to do with external symbols not being properly recognized (in particular cblas_snrm2). I reckon this error is linked to my OpenBLAS install, but I wasn't able to find many leads to resolve it. I found one https://stackoverflow.com/questions/63750020/unresolved-external-symbol-error-when-linking-a-cython-extension-against-a-c-l article where the problem seemed similar enough but I wasn't able to apply it to my problem.
Since I am no longer trying to make it work on Windows, I'll close the issue.

Thanks for reporting this -- I'll be honest this code is not really maintained anymore (the ideas that went in to this got moved over to UMAP which is actively maintained). The dependence on Cython means that the code really needs to be re-cythonized and completely recompiled for any install, and that may be challenging on Windows where compilation is trickier.


Add link to buddylist to guard against contact spoofing

Add link to buddylist to guard against contact spoofing, fixes #412
Tested in Chrome, Firefox, re-ran grunt test
Screenshot:

Couple CSS questions and a small functionality question.

Reviewed files:

src/generic_core/user.ts @ r1
src/generic_ui/polymer/contact.html @ r1
src/generic_ui/polymer/contact.ts @ r1
src/generic_ui/scripts/user.ts @ r1
src/interfaces/ui.d.ts @ r1

src/generic_ui/polymer/contact.html, line 36 [r1] (raw file):
I think we can get rid of the float: right; here since we now have the icon-wrapper with the flex (and therefore also get rid of the inverse in the open-new styling.

src/generic_ui/polymer/contact.html, line 37 [r1] (raw file):
I think it might be better to apply this specifically to .nameRow core-icon.expand (yeah, I know, not a class right now, but I don't have a better way to refer to it).  I think in that case, we could skip having to apply the inverse to the open-new icon.

src/generic_ui/scripts/user.ts, line 103 [r1] (raw file):
Is there a way we can start saving the url to storage so you still have it after restarting uProxy?

Comments from the review on Reviewable.io

Just made those changes, PTAL

Comments from the review on Reviewable.io

Reviewed files:

src/generic_core/user.ts @ r3
src/generic_ui/polymer/contact.html @ r2
src/generic_ui/scripts/user.ts @ r3

Comments from the review on Reviewable.io

This is awesome.
Why don't we display the link when contact is not expanded?

Izzie requested only showing it when expanded, otherwise it adds clutter
and is only really relevant for buddies who you are interacting with
On Apr 8, 2015 5:09 PM, "salomegeo"<EMAIL_ADDRESS>wrote:

This is awesome.
Why don't we display the link when contact is not expanded?
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/pull/1229#issuecomment-91037994.


GSLB: add status information about hosts in host_list

GSLB: add status information about hosts in host_list
The status of a specific host should be added to the host_list hash as it is important information when dealing with GSLB configurations.

Did you have any chance to look at the pull requests?
I would love to see the pull requests merged in order to get rid of my own fork.
Thanks!


Add https support for development

Fixes #95
Changes:

self-signed certs (valid for 10 years)
configure https for livereload (grunt watch related)
configure https for storybook

development will work only on https://localhost:9009

cc @pivnicek @janmichek

There still issue with headers ... I'll keep the certs and revert this :back:

So https will be optional, sorry for bothering.


Vec<Vec<(String, usize)>> panics with unsatisfied trait bounds

Hi everyone. Probably a stupid question but I'm getting this error when trying to return Vec<Vec<(String, usize)>> from a function and then define it as a singleton method:
error[E0599]: the method `call_handle_error` exists for fn item `fn(String, String) -> Vec<Vec<(String, usize)>> {reg}`, but its trait bounds were not satisfied
  --> ext/xre2/src/lib.rs:98:43
   |
98 |     module.define_singleton_method("reg", function!(reg, 2))?;
   |                                           ^^^^^^^^^^^^^^^^^ method cannot be called due to unsatisfied trait bounds
   |
   = note: the following trait bounds were not satisfied:
           `<fn(String, String) -> Vec<Vec<(String, usize)>> {reg} as FnOnce<(&Ruby, _, _)>>::Output = _`
           which is required by `fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: RubyFunction2<_, _, _>`
           `fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: Fn<(&Ruby, _, _)>`
           which is required by `fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: RubyFunction2<_, _, _>`
           `<&fn(String, String) -> Vec<Vec<(String, usize)>> {reg} as FnOnce<(&Ruby, _, _)>>::Output = _`
           which is required by `&fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: RubyFunction2<_, _, _>`
           `&fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: Fn<(&Ruby, _, _)>`
           which is required by `&fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: RubyFunction2<_, _, _>`
           `&mut fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: Fn<(_, _)>`
           which is required by `&mut fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: Function2<_, _, _>`
           `<&mut fn(String, String) -> Vec<Vec<(String, usize)>> {reg} as FnOnce<(&Ruby, _, _)>>::Output = _`
           which is required by `&mut fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: RubyFunction2<_, _, _>`
           `&mut fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: Fn<(&Ruby, _, _)>`
           which is required by `&mut fn(String, String) -> Vec<Vec<(String, usize)>> {reg}: RubyFunction2<_, _, _>`
   = note: this error originates in the macro `function` (in Nightly builds, run with -Z macro-backtrace for more info)

which in my very limited experience meant that there's no way to implicitly transform this rust type into ruby type(might be wrong, please correct me). So I was wondering why does Vec<(String, usize)> is ok but this one is not?

This is a bug in Magnus, looks like I forgot to implement IntoValueFromNative for Vec.
IntoValue is the trait that handles turning Rust types into Ruby types. Ruby types also implement it, just by returning themselves. Vec implements it like:
impl<T> IntoValue for Vec<T>
where
    T: IntoValueFromNative,
{
    ...
}

IntoValueFromNative is a special version of IntoValue that isn't implemented for Ruby types. This is done so you can't return an Vec containing Ruby types, because you shouldn't ever put Ruby types in a Vec, because the GC will lose track of them.
Vec shouldn't blanket implement IntoValueFromNative (because it could contain Ruby types), but it should impl<T> IntoValueFromNative for Vec<T> where T: IntoValueFromNative. I missed adding this impl.
I don't have time to do it right now, but I'll try and get a patch release out this evening with a fix.

I see, makes sense. Thank you for the explanation and for such a swift response. I have some time right now so I will try to do it myself, if I do I'll ping you on a pr. Otherwise feel free to fix 👍

I've put out a 0.6.3 release with this fix.


Icon request: Short.io

URL of site

Short.io: https://short.io / https://app.short.io

Logo resources for the icons

Short.io: https://short.io/favicon-32x32.png / https://app.short.io/settings/logo-square.svg

Note: I included both icons as they are slightly different. You may choose whichever you prefer.

Here you go!
https://github.com/aegis-icons/aegis-icons/blob/master/PNG/Short.io.png


allow type 'unsafe' way to doing es6 style imports

Currently if have an import of a library which doesnt have any type definition, like this:
import {A} from 'randomLib';

Typescript will mark an error saying it cant find randomLib anywhere.
We need some way of telling typescript to suppress the error for this particular import.

I think the solutions and discussion in #2709 covers this scenario.

Though, the way you should be fixing this is by declaring the module itself:
declare module "randomLib" {
    export let A: any;
}

this is not feasible for large projects.
now for every library we want to use we have to manually create the
typedefs.
kinda defeats the whole 'superset of JavaScript' message.
On Tuesday, January 5, 2016, Daniel Rosenwasser<EMAIL_ADDRESS>wrote:

Though, the way you should be fixing this is by declaring the module
itself:
declare module "randomLib" {
export let A: any;
}
—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/6371#issuecomment-169178728
.

--
Prashant

I agree, this is extremely frustrating for people who are migrating.
Tangentially, what libraries are you trying to use that don't have typings?

This came up during the migrate-a-thon as well. The long tail of libraries is surprisingly long.

I don't think #2709 wouldn't be the best fix for this issue. When you've got typings for a library later on, you would need to remove : any from all your files. Declaring a weak version of the library would make it easier to migrate later, but it's too much work to create it. I think an easy way to create declare a module, without saying anything of it's content, would be the best solution. I'm thinking on something like this:
declare module "foo";
declare module "bar";

After declaring these modules in a .d.ts file, you can use these modules like you would expect. All kinds of import statements are allowed (legacy, named and default imports) and you won't get type errors. What does everyone think of this?

+1 to @ivogabe

closing in favor of #6615


Cannot build AOT - 'Illegal state: Could not load the summary for directive CdkTrapFocus'

ng build --prod
ERROR in : Illegal state: Could not load the summary for directive CdkTrapFocus in C:/Users/Tyler/Documents/GitHub/<EMAIL_ADDRESS>

Have you checked this comment?

From looking at this a bit it looks like this might be an issues with your environment's setup.  Were you able to try adding a rootDir to your tsconfig?

Hi @josephperrott, thanks for the reply.
The issue listed above looks like the suggestion is to remove that line, not to add it unless I misunderstood.
Regardless, adding "rootDir": "." or "src" still results in the same ERROR in : Illegal state: Could not load the summary for directive CdkTrapFocus

This is still an issue in 6.0.0
ERROR in : Illegal state: Could not load the summary for directive Dir in C:/Users/Tyler/Documents/GitHub/<EMAIL_ADDRESS>Angular CLI: 6.0.0
Node: 8.11.1
OS: win32 x64
Angular: 6.0.0
... animations, cdk, common, compiler, compiler-cli, core, forms
... http, language-service, material, platform-browser
... platform-browser-dynamic, router

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.6.0 (cli-only)
@angular-devkit/build-angular      0.6.0
@angular-devkit/build-ng-packagr   0.6.0
@angular-devkit/build-optimizer    0.6.0
@angular-devkit/core               0.6.0 (cli-only)
@angular-devkit/schematics         0.6.0 (cli-only)
@ngtools/json-schema               1.1.0
@ngtools/webpack                   6.0.0
@schematics/angular                0.6.0 (cli-only)
@schematics/update                 0.6.0 (cli-only)
ng-packagr                         2.4.2
rxjs                               6.1.0
typescript                         2.7.2
webpack                            4.6.0

https://github.com/angular/angular-cli/issues/10615

Closing this since I believe it is obsolete


Crash on start if multiple shops in the same league defined

Setting the following in Settings.xml:
  <ShopSettings>
    <Shop League="Torment" ThreadId="9999999" ThreadTitle="Shop" />
    <Shop League="Torment" ThreadId="" ThreadTitle="" />
  </ShopSettings>

Results in:
Problem signature:
  Problem Event Name:	CLR20r3
  Problem Signature 01:	Procurement.exe
  Problem Signature 02:	<IP_ADDRESS>
  Problem Signature 03:	54b24d49
  Problem Signature 04:	mscorlib
  Problem Signature 05:	4.0.30319.34014
  Problem Signature 06:	52e0b676
  Problem Signature 07:	21a4
  Problem Signature 08:	a6
  Problem Signature 09:	System.ArgumentException
  OS Version:	6.3.96<IP_ADDRESS>.256.48
  Locale ID:	1033
  Additional Information 1:	a43c
  Additional Information 2:	a43c1ef4eafcc38d80123caef5a0c232
  Additional Information 3:	0e04
  Additional Information 4:	0e04d6d925e2c5bff62e6c76b8b6d0ce

Unfortunately Procurement doesn't support multiple shops for the same league currently, but I do plan on adding support in a future release. Most users either change the setting and bump, or install Procurement to two separate folders.

I understand. I was thinking if there is more than one league detected it would throw a warning to the user instead of a generic crash.
Thanks for all the work, btw :)


docs: explicitly state that processExit fails when exit queue for token is empty

@pgebal what is the status of this one?


No possibility to create a PR for a previous version

Hi,
I'd like to add a version after the 1.1.2, to be able to use the datastax versions 1.2 and 1.3.
As there is no branch linked to this version I can't create this PR.
Is it possible to create it?
Thanks

Hello,
Here is the branch : https://github.com/M6Web/CassandraBundle/tree/1.1
Thank you !
Fabien


Automatically wire active span from opentelemetry api

getActiveSpan is set to optional to avoid breaking changes, discord discussion: https://discord.com/channels/795981131316985866/911666033885061240/1291311027144888383

closing in favour of Tracer.withSpanContext given that active span is not propagated across async


[Outlook] (delegate) Add REST guidance; note message compose conditio…

…ns (#2230)

[Outlook] (delegate) Add REST guidance; note message compose conditions

Update based on initial feedback

Tweak

Update

Clarify

Update based on feedback

Update based on feedback

Swap sections

Docs Build status updates of commit 4dbd0b1:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/outlook/delegate-access.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


ffi not found

I am new to torch and tried install by following the instructions for MacOS. When I lunch a notebook and try to run  require 'image'; I am getting:
/usr/local/bin/lua: /usr/local/share/lua/5.2/itorch/IOHandler.lua:17: module 'ffi' not found:
    no field package.preload['ffi']
    no file '/usr/local/share/lua/5.2/ffi.lua'
    no file '/usr/local/share/lua/5.2/ffi/init.lua'
    no file '/usr/local/lib/lua/5.2/ffi.lua'
    no file '/usr/local/lib/lua/5.2/ffi/init.lua'
    no file './ffi.lua'
    no file '/usr/local/lib/lua/5.2/ffi.so'
    no file '/usr/local/lib/lua/5.2/loadall.so'
    no file './ffi.so'
stack traceback:
    [C]: in function 'require'
    /usr/local/share/lua/5.2/itorch/IOHandler.lua:17: in main chunk
    [C]: in function 'require'
    (command line):1: in main chunk
    [C]: in ?
[I 12:53:39.071 NotebookApp] KernelRestarter: restarting kernel (1/5)

I tried to re-install torchffi. The log says
luarocks --server=https://raw.githubusercontent.com/torch/rocks/master install torchffi
...
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/lib/luarocks/rocks-5.2/torchffi/1.1.alpha-0/lua/torchffi/init.lua
-- Installing: /usr/local/lib/luarocks/rocks-5.2/torchffi/1.1.alpha-0/lua/torchffi/apply.lua
Updating manifest for /usr/local/lib/luarocks/rocks-5.2
torchffi 1.1.alpha-0 is now built and installed in /usr/local (license: BSD)

However I do not see any /usr/local/lib/luarocks/rocks-5.2/torchffi/1.1.alpha-0/lua/torchffi/init.lua.
Also, the FFI github README says that in Torch7 FFI is integrated. Any ideas where the integrated FFI should be installed?

It looks like Torch7 installs with LUA_PATH=$HOMW/.luarocks/share/lua/5.1/?.lua;..., while iTorch looks for /usr/local/lib/luarocks/rocks-5.2. Is there a way to make iTorch look for the lua version that Torch uses?

Is there any solution to the problem?


Application tag in Mainfest interferes with application Manifest

If an Android application is using LiquidCoreAndroid with a configuration of allowBackup=false or supportsRtl=false it will get an error because of contradicting values in the Manufest of LiquidCore.
I don't believe that the <application> tag is necessary for a library and should probably be removed.

This is fixed in v0.6.0.  The <application> tag was added so the instrumentation tests could use HTTP (not HTTPS) for testing.  I moved this to the androidTest/AndroidManifest.xml.


Add possibility to add custom headers from checks

What is the feature?
Currently it is possible to configure custom healthchecks what is pretty nice! In addition it would be nice if a check can
also add custom http header to the response in order to react on them by reading that header from the response
What benefits will this change bring?
You could easly add more information to the response

Hi @timohund,
Thanks for raising an issue. It's great to hear that you like the health-check package! 😄
Can I ask what benefit(s) you think the custom header would have over the current method of returning data from the check when marking it as OK or PROBLEM?
Just in case you aren't aware, you can pass contextual information back when setting the check status. See here: https://github.com/ukfast/laravel-health-check/blob/master/src/HealthCheck.php#L26

@tylerwoonton
Thanks for your quick response. I already saw that it is possible to provide additional context. This could also be used to add information like that, but it requires additional (potentially error prone) json parsing on the client side. So it would be nice for automated monitoring systems to just check the value of an specific HTTP_RESPONSE header.

I think this could be handled in a middleware. I think the use-case is somewhat nice so it shouldn't be enabled by default, but would something like this work for you?
<?php

use UKFast\HealthCheck\Facade\HealthCheck;
use Closure;

class SetHealthCheckHeaders
{
    public function handle($request, Closure $next)
    {
        $response = $next($request);

        HealthCheck::all()->forEach(function ($check) use ($response) {
            $header = "X-{$check->name()}-status";
            $status = $check->status()->okay() ? 1 : 0;

            $response->headers->set($header, $status)
        });

        return $response;
    }
}

So you'll get an X-{check}-response header with a 1 for success or 0 for failure for each check, e.g.
X-redis-status: 1
X-database-status 0

Does that solve your problem @timohund ?

@Gman98ish Yes i think is solves my problem thx

@timohund Do you want to contribute that middleware into the package? We credit contributions in our CHANGELOG.md.

Tagged at v1.4.0
Good suggestion @timohund and thanks for adding @Gman98ish. 👍🏻
https://github.com/ukfast/laravel-health-check/releases/tag/v1.4.0


How to add Themes?

I want change background color of charts? How to add themes?

Charting is provided by the C3js library so you can use its CSS classes to
style your charts.
On Tue, Apr 18, 2017 at 04:05 gkamle<EMAIL_ADDRESS>wrote:

I want change background color of charts? How to add themes?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nicolaskruchten/pivottable/issues/689, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAMbA1QfQZd1KpWFSflVGjlvJM8ZJrJlks5rxG7dgaJpZM4NAAaj
.


Migrate to SubjectTest from base

This PR migrates the tests to use SubjectTest recently introduced in base.

@armiol, @dmdashenkov, PTAL.


Try out cross validation by splitting daywise/weekwise

I think it could be a very good idea to implement cross validation by seperating the dataset daywise or weakwise. By that I mean that the data for every other day/week is put in another bucket. This way each bucket contains data for all buildings, all seasons, all times of day and hopefully all days of week. This could allow for effective stacking using more than 2 buckets.

On eed5f41:
(.venv) ubuntu@energeek:~/ashrae-energy-prediction$ make train MODEL=lgbm MODE=daywise_cv
python3 src/models/train_lgbm_model.py daywise_cv data/processed models/lgbm
Loading processed training data ...
Loading processed training data took 00:00:01
Performing 2 fold cross-validation ...
~~~~ Fold 1 of 2 ~~~~ ...

[25]    train_loss's rmse: 1.48269      eval's rmse: 1.47886
[50]    train_loss's rmse: 1.2605       eval's rmse: 1.25525
[75]    train_loss's rmse: 1.11999      eval's rmse: 1.11426
[100]   train_loss's rmse: 1.05831      eval's rmse: 1.05606
[125]   train_loss's rmse: 1.01097      eval's rmse: 1.01158
[150]   train_loss's rmse: 0.977521     eval's rmse: 0.980313
[175]   train_loss's rmse: 0.954122     eval's rmse: 0.959292
[200]   train_loss's rmse: 0.934399     eval's rmse: 0.941858
[225]   train_loss's rmse: 0.91856      eval's rmse: 0.927296
[250]   train_loss's rmse: 0.905596     eval's rmse: 0.917248
[275]   train_loss's rmse: 0.893096     eval's rmse: 0.906532
[300]   train_loss's rmse: 0.88607      eval's rmse: 0.900675
[325]   train_loss's rmse: 0.881223     eval's rmse: 0.896681
[350]   train_loss's rmse: 0.876148     eval's rmse: 0.893903
[375]   train_loss's rmse: 0.870268     eval's rmse: 0.890323
[400]   train_loss's rmse: 0.865943     eval's rmse: 0.887958
[425]   train_loss's rmse: 0.860454     eval's rmse: 0.884185
[450]   train_loss's rmse: 0.855397     eval's rmse: 0.879762
[475]   train_loss's rmse: 0.851396     eval's rmse: 0.878342
[500]   train_loss's rmse: 0.847979     eval's rmse: 0.876274
Model successfully saved in folder: models/lgbm_daywise_cv
~~~~ Fold 2 of 2 ~~~~ took 00:02:12
Fold summary (Loss):
0|      Eval:   0.880   |       train:  0.841
1|      Eval:   0.876   |       train:  0.848
Average Eval Loss:      0.878
Average Train Loss:     0.845
Performing 2 fold cross-validation took 00:04:40

On 3bb1a7a (2000 rounds):
(.venv) ubuntu@energeek:~/ashrae-energy-prediction$ make train MODEL=lgbm MODE=daywise_cv
python3 src/models/train_lgbm_model.py daywise_cv data/processed models/lgbm
Loading processed training data ...
Loading processed training data took 00:00:02
Performing 2 fold cross-validation ...
~~~~ Fold 1 of 2 ~~~~ ...
 Best iteration is:
[2000]  train_loss's rmse: 0.69529      eval's rmse: 0.793523
Model successfully saved in folder: models/lgbm_daywise_cv
~~~~ Fold 1 of 2 ~~~~ took 00:07:46
~~~~ Fold 2 of 2 ~~~~ ...
 Best iteration is:
[2000]  train_loss's rmse: 0.710636     eval's rmse: 0.791401
Model successfully saved in folder: models/lgbm_daywise_cv
~~~~ Fold 2 of 2 ~~~~ took 00:06:48
Fold summary (Loss):
0|      Eval:   0.794   |       train:  0.695
1|      Eval:   0.791   |       train:  0.711
Average Eval Loss:      0.792
Average Train Loss:     0.703
Performing 2 fold cross-validation took 00:14:48

On e2d9134 (split using month instead of dayofyear):
Adrian@DESKTOP-K32UEUN MINGW64 ~/LMU/WS1920/ilbds/ashrae-energy-prediction (fix/44)
$ python src/models/train_lgbm_model.py daywise_cv data/processed models/lgbm
Loading processed training data ...
Loading processed training data took 00:00:01
Performing 2 fold cross-validation ...
~~~~ Fold 1 of 2 ~~~~ ...

[25]    train_loss's rmse: 1.48051      eval's rmse: 1.54521
[50]    train_loss's rmse: 1.25586      eval's rmse: 1.40638
[75]    train_loss's rmse: 1.1176       eval's rmse: 1.33953
[100]   train_loss's rmse: 1.03564      eval's rmse: 1.31969
[125]   train_loss's rmse: 0.984626     eval's rmse: 1.30295
[150]   train_loss's rmse: 0.95595      eval's rmse: 1.3012
[175]   train_loss's rmse: 0.934982     eval's rmse: 1.30268
[200]   train_loss's rmse: 0.913739     eval's rmse: 1.3054
[225]   train_loss's rmse: 0.898169     eval's rmse: 1.30663
[250]   train_loss's rmse: 0.886509     eval's rmse: 1.31044
[275]   train_loss's rmse: 0.878639     eval's rmse: 1.30992
[300]   train_loss's rmse: 0.871257     eval's rmse: 1.31139
[325]   train_loss's rmse: 0.864032     eval's rmse: 1.31196
[350]   train_loss's rmse: 0.855561     eval's rmse: 1.31945
[375]   train_loss's rmse: 0.845158     eval's rmse: 1.31941
[400]   train_loss's rmse: 0.838405     eval's rmse: 1.32171
[425]   train_loss's rmse: 0.832163     eval's rmse: 1.32233
[450]   train_loss's rmse: 0.827321     eval's rmse: 1.323
[475]   train_loss's rmse: 0.821575     eval's rmse: 1.32262
[500]   train_loss's rmse: 0.817188     eval's rmse: 1.32358
Model successfully saved as: models/lgbm_month_cv/0002.txt
~~~~ Fold 2 of 2 ~~~~ took 00:03:47
Fold summary (Loss):
0|      Eval:   1.377   |       train:  0.821
1|      Eval:   1.324   |       train:  0.817
Average Eval Loss:      1.350
Average Train Loss:     0.819
Performing 2 fold cross-validation took 00:07:44

On e2d9134 (split using weekofyear instead of dayofyear):
Adrian@DESKTOP-K32UEUN MINGW64 ~/LMU/WS1920/ilbds/ashrae-energy-prediction
$ python src/models/train_lgbm_model.py daywise_cv data/processed models/l
Loading processed training data ...
Loading processed training data took 00:00:03
Performing 2 fold cross-validation ...
~~~~ Fold 1 of 2 ~~~~ ...

[25]    train_loss's rmse: 1.5001       eval's rmse: 1.49673
[50]    train_loss's rmse: 1.27301      eval's rmse: 1.26746
[75]    train_loss's rmse: 1.13506      eval's rmse: 1.12985
[100]   train_loss's rmse: 1.06732      eval's rmse: 1.06646
[125]   train_loss's rmse: 1.01931      eval's rmse: 1.02273
[150]   train_loss's rmse: 0.987068     eval's rmse: 0.994034
[175]   train_loss's rmse: 0.962921     eval's rmse: 0.973858
[200]   train_loss's rmse: 0.944167     eval's rmse: 0.957659
[225]   train_loss's rmse: 0.925187     eval's rmse: 0.941918
[250]   train_loss's rmse: 0.91174      eval's rmse: 0.930939
[275]   train_loss's rmse: 0.902094     eval's rmse: 0.922468
[300]   train_loss's rmse: 0.892323     eval's rmse: 0.916221
[325]   train_loss's rmse: 0.884051     eval's rmse: 0.909135
[350]   train_loss's rmse: 0.876764     eval's rmse: 0.904789
[375]   train_loss's rmse: 0.871803     eval's rmse: 0.901269
[400]   train_loss's rmse: 0.866428     eval's rmse: 0.897309
[425]   train_loss's rmse: 0.861395     eval's rmse: 0.894349
[450]   train_loss's rmse: 0.856054     eval's rmse: 0.891475
[475]   train_loss's rmse: 0.849452     eval's rmse: 0.88702
[500]   train_loss's rmse: 0.844547     eval's rmse: 0.884005
Model successfully saved as: models/lgbm_weekofyear_cv/0002.txt
~~~~ Fold 2 of 2 ~~~~ took 00:03:35
Fold summary (Loss):
0|      Eval:   0.895   |       train:  0.817
1|      Eval:   0.884   |       train:  0.845
Average Eval Loss:      0.890
Average Train Loss:     0.831
Performing 2 fold cross-validation took 00:07:21

Score: 1.09
Commit: 797c0f9
Output:
(env)
Adrodoc@DESKTOP-164BSRB MINGW64 ~/devel/python/energeeks/ashrae-energy-prediction (fix/44)
$ python src/models/train_lgbm_model.py daywise_cv data/processed models/lgbm
Loading processed training data ...
Loading processed training data took 00:00:03
Performing 2 fold cross-validation ...
~~~~ Fold 1 of 2 ~~~~ ...
Training until validation scores don't improve for 100 rounds
[25]    train_loss's rmse: 1.32151      eval's rmse: 1.32414
[50]    train_loss's rmse: 1.08457      eval's rmse: 1.08844
[75]    train_loss's rmse: 0.962447     eval's rmse: 0.967271
[100]   train_loss's rmse: 0.891589     eval's rmse: 0.897391
[125]   train_loss's rmse: 0.854718     eval's rmse: 0.861225
[150]   train_loss's rmse: 0.827297     eval's rmse: 0.83435
[175]   train_loss's rmse: 0.809579     eval's rmse: 0.817787
[200]   train_loss's rmse: 0.795607     eval's rmse: 0.8047
[225]   train_loss's rmse: 0.785641     eval's rmse: 0.795862
[250]   train_loss's rmse: 0.77767      eval's rmse: 0.788774
[275]   train_loss's rmse: 0.772449     eval's rmse: 0.783947
[300]   train_loss's rmse: 0.766854     eval's rmse: 0.779439
[325]   train_loss's rmse: 0.762041     eval's rmse: 0.775529
[350]   train_loss's rmse: 0.75777      eval's rmse: 0.771878
[375]   train_loss's rmse: 0.75423      eval's rmse: 0.768768
[400]   train_loss's rmse: 0.751016     eval's rmse: 0.766263
[425]   train_loss's rmse: 0.747273     eval's rmse: 0.763838
[450]   train_loss's rmse: 0.744282     eval's rmse: 0.761365
[475]   train_loss's rmse: 0.741871     eval's rmse: 0.759466
[500]   train_loss's rmse: 0.739725     eval's rmse: 0.757756
Did not meet early stopping. Best iteration is:
[500]   train_loss's rmse: 0.739725     eval's rmse: 0.757756
Model successfully saved as: models/lgbm_daywise_cv/0001.txt
~~~~ Fold 1 of 2 ~~~~ took 00:04:13
~~~~ Fold 2 of 2 ~~~~ ...
Training until validation scores don't improve for 100 rounds
[25]    train_loss's rmse: 1.32464      eval's rmse: 1.32246
[50]    train_loss's rmse: 1.06803      eval's rmse: 1.06518
[75]    train_loss's rmse: 0.960802     eval's rmse: 0.957812
[100]   train_loss's rmse: 0.897601     eval's rmse: 0.894699
[125]   train_loss's rmse: 0.855333     eval's rmse: 0.852574
[150]   train_loss's rmse: 0.825115     eval's rmse: 0.822592
[175]   train_loss's rmse: 0.807008     eval's rmse: 0.805415
[200]   train_loss's rmse: 0.7948       eval's rmse: 0.793684
[225]   train_loss's rmse: 0.785271     eval's rmse: 0.784611
[250]   train_loss's rmse: 0.778533     eval's rmse: 0.778216
[275]   train_loss's rmse: 0.774156     eval's rmse: 0.774082
[300]   train_loss's rmse: 0.770083     eval's rmse: 0.770814
[325]   train_loss's rmse: 0.765386     eval's rmse: 0.767286
[350]   train_loss's rmse: 0.761598     eval's rmse: 0.764303
[375]   train_loss's rmse: 0.758689     eval's rmse: 0.761928
[400]   train_loss's rmse: 0.754728     eval's rmse: 0.75882
[425]   train_loss's rmse: 0.751729     eval's rmse: 0.756766
[450]   train_loss's rmse: 0.749301     eval's rmse: 0.755053
[475]   train_loss's rmse: 0.746799     eval's rmse: 0.753093
[500]   train_loss's rmse: 0.744728     eval's rmse: 0.751501
Did not meet early stopping. Best iteration is:
[500]   train_loss's rmse: 0.744728     eval's rmse: 0.751501
Model successfully saved as: models/lgbm_daywise_cv/0002.txt
~~~~ Fold 2 of 2 ~~~~ took 00:04:17
Fold summary (Loss):
0|      Eval:   0.758   |       train:  0.740
1|      Eval:   0.752   |       train:  0.745
Average Eval Loss:      0.755
Average Train Loss:     0.742
Performing 2 fold cross-validation took 00:08:41
(env)
Adrodoc@DESKTOP-164BSRB MINGW64 ~/devel/python/energeeks/ashrae-energy-prediction (fix/44)
$ python src/models/predict_model.py data/processed lgbm models/lgbm_daywise_cv
Loading testing data ...
Loading testing data took 00:00:09
Loading models in directorymodels/lgbm_daywise_cv
Loading model [1/2] ...
Loading model [1/2] took 00:00:00
Predicting values [1/2] ...
Predicting values [1/2] took 00:10:49
Loading model [2/2] ...
Loading model [2/2] took 00:00:00
Predicting values [2/2] ...
Predicting values [2/2] took 00:10:34
Creating submission file ...
Creating submission file took 00:02:14

Score: 1.08
Commit: 56b987a
Output:
Loading interim data ...
Loading interim data took 00:00:21
Encoding categorical features ...
Encoding categorical features took 00:00:14
Encoding timestamp features ...
Encoding timestamp features took 00:00:15
Taking the log of selected features ...
Taking the log of selected features took 00:00:01
Calculating age of buildings ...
Calculating age of buildings took 00:00:00
Adding Lag Features ...
Adding Lag Features took 00:04:00
Exclude faulty data and outliers ...
Exclude faulty data and outliers took 00:00:13
Sort training set ...
Sort training set took 00:00:02
Dropping specified columns ...
Dropping specified columns took 00:00:28
Save processed data ...
Data successfully saved in folder: data/processed
Save processed data took 00:00:57
Loading processed training data ...
Loading processed training data took 00:00:04
Performing 2 fold cross-validation ...
~~~~ Fold 1 of 2 ~~~~ ...
Training until validation scores don't improve for 50 rounds
[25]    train_loss's rmse: 0.898909     eval's rmse: 0.914794
[50]    train_loss's rmse: 0.691498     eval's rmse: 0.730356
[75]    train_loss's rmse: 0.637632     eval's rmse: 0.702006
[100]   train_loss's rmse: 0.60877      eval's rmse: 0.695357
[125]   train_loss's rmse: 0.585771     eval's rmse: 0.69243
[150]   train_loss's rmse: 0.567892     eval's rmse: 0.690686
[175]   train_loss's rmse: 0.554332     eval's rmse: 0.689905
[200]   train_loss's rmse: 0.542409     eval's rmse: 0.689054
[225]   train_loss's rmse: 0.532515     eval's rmse: 0.688692
[250]   train_loss's rmse: 0.523845     eval's rmse: 0.688662
[275]   train_loss's rmse: 0.517585     eval's rmse: 0.688489
[300]   train_loss's rmse: 0.512071     eval's rmse: 0.688651
[325]   train_loss's rmse: 0.511972     eval's rmse: 0.688657
Early stopping, best iteration is:
[279]   train_loss's rmse: 0.516802     eval's rmse: 0.688453
Model successfully saved as: models/lgbm_daywise_cv/0001.txt
~~~~ Fold 1 of 2 ~~~~ took 00:12:58
~~~~ Fold 2 of 2 ~~~~ ...
Training until validation scores don't improve for 50 rounds
[25]    train_loss's rmse: 0.902826     eval's rmse: 0.910742
[50]    train_loss's rmse: 0.6968       eval's rmse: 0.724548
[75]    train_loss's rmse: 0.642982     eval's rmse: 0.695771
[100]   train_loss's rmse: 0.614028     eval's rmse: 0.689303
[125]   train_loss's rmse: 0.590468     eval's rmse: 0.686764
[150]   train_loss's rmse: 0.572313     eval's rmse: 0.685592
[175]   train_loss's rmse: 0.558238     eval's rmse: 0.685303
[200]   train_loss's rmse: 0.545686     eval's rmse: 0.685209
[225]   train_loss's rmse: 0.535195     eval's rmse: 0.685177
Early stopping, best iteration is:
[190]   train_loss's rmse: 0.551052     eval's rmse: 0.685052
Model successfully saved as: models/lgbm_daywise_cv/0002.txt
~~~~ Fold 2 of 2 ~~~~ took 00:10:52
Fold summary (Loss):
0|      Eval:   0.689   |       train:  0.512
1|      Eval:   0.685   |       train:  0.530
Average Eval Loss:      0.687
Average Train Loss:     0.521
Performing 2 fold cross-validation took 00:24:07
Loading testing data ...
Loading testing data took 00:00:10
Loading models in directorymodels/lgbm_daywise_cv
Loading model [1/2] ...
Loading model [1/2] took 00:00:00
Predicting values [1/2] ...
Predicting values [1/2] took 00:40:52
Loading model [2/2] ...
Loading model [2/2] took 00:00:00
Predicting values [2/2] ...
Predicting values [2/2] took 00:26:32
Creating submission file ...
Creating submission file took 00:02:11

Score: 1.08
Commit: 56b987a (4 splits)
Output:
Loading interim data ...
Loading interim data took 00:00:19
Encoding categorical features ...
Encoding categorical features took 00:00:13
Encoding timestamp features ...
Encoding timestamp features took 00:00:14
Taking the log of selected features ...
Taking the log of selected features took 00:00:00
Calculating age of buildings ...
Calculating age of buildings took 00:00:00
Adding Lag Features ...
Adding Lag Features took 00:03:52
Exclude faulty data and outliers ...
Exclude faulty data and outliers took 00:00:12
Sort training set ...
Sort training set took 00:00:04
Dropping specified columns ...
Dropping specified columns took 00:00:20
Save processed data ...
Data successfully saved in folder: data/processed
Save processed data took 00:00:41
Loading processed training data ...
Loading processed training data took 00:00:03
Performing 4 fold cross-validation ...
~~~~ Fold 1 of 4 ~~~~ ...
Training until validation scores don't improve for 50 rounds
[25]    train_loss's rmse: 0.902037     eval's rmse: 0.913247
[50]    train_loss's rmse: 0.700583     eval's rmse: 0.728445
[75]    train_loss's rmse: 0.651585     eval's rmse: 0.699194
[100]   train_loss's rmse: 0.626167     eval's rmse: 0.691328
[125]   train_loss's rmse: 0.604128     eval's rmse: 0.687378
[150]   train_loss's rmse: 0.588991     eval's rmse: 0.684791
[175]   train_loss's rmse: 0.576523     eval's rmse: 0.683474
[200]   train_loss's rmse: 0.56624      eval's rmse: 0.682713
[225]   train_loss's rmse: 0.55809      eval's rmse: 0.682435
[250]   train_loss's rmse: 0.551392     eval's rmse: 0.682111
[275]   train_loss's rmse: 0.54621      eval's rmse: 0.681761
[300]   train_loss's rmse: 0.541486     eval's rmse: 0.681397
[325]   train_loss's rmse: 0.537353     eval's rmse: 0.681214
[350]   train_loss's rmse: 0.532406     eval's rmse: 0.681317
[375]   train_loss's rmse: 0.528378     eval's rmse: 0.681411
Early stopping, best iteration is:
[333]   train_loss's rmse: 0.536039     eval's rmse: 0.681141
Model successfully saved as: models/lgbm_daywise_cv/0001.txt
~~~~ Fold 1 of 4 ~~~~ took 00:16:04
~~~~ Fold 2 of 4 ~~~~ ...
Training until validation scores don't improve for 50 rounds
[25]    train_loss's rmse: 0.900814     eval's rmse: 0.919951
[50]    train_loss's rmse: 0.69811      eval's rmse: 0.734607
[75]    train_loss's rmse: 0.651037     eval's rmse: 0.706242
[100]   train_loss's rmse: 0.626266     eval's rmse: 0.69908
[125]   train_loss's rmse: 0.605075     eval's rmse: 0.696065
[150]   train_loss's rmse: 0.589626     eval's rmse: 0.694261
[175]   train_loss's rmse: 0.577065     eval's rmse: 0.693548
[200]   train_loss's rmse: 0.566745     eval's rmse: 0.692865
[225]   train_loss's rmse: 0.558332     eval's rmse: 0.692604
[250]   train_loss's rmse: 0.550887     eval's rmse: 0.692806
[275]   train_loss's rmse: 0.544069     eval's rmse: 0.692869
Early stopping, best iteration is:
[228]   train_loss's rmse: 0.557531     eval's rmse: 0.692589
Model successfully saved as: models/lgbm_daywise_cv/0002.txt
~~~~ Fold 2 of 4 ~~~~ took 00:14:20
~~~~ Fold 3 of 4 ~~~~ ...
Training until validation scores don't improve for 50 rounds
[25]    train_loss's rmse: 0.902201     eval's rmse: 0.913927
[50]    train_loss's rmse: 0.70102      eval's rmse: 0.727832
[75]    train_loss's rmse: 0.653383     eval's rmse: 0.699109
[100]   train_loss's rmse: 0.628174     eval's rmse: 0.691736
[125]   train_loss's rmse: 0.606884     eval's rmse: 0.688632
[150]   train_loss's rmse: 0.590357     eval's rmse: 0.686499
[175]   train_loss's rmse: 0.578544     eval's rmse: 0.685369
[200]   train_loss's rmse: 0.568737     eval's rmse: 0.684587
[225]   train_loss's rmse: 0.560655     eval's rmse: 0.684232
[250]   train_loss's rmse: 0.553487     eval's rmse: 0.684103
[275]   train_loss's rmse: 0.548029     eval's rmse: 0.68397
[300]   train_loss's rmse: 0.543154     eval's rmse: 0.683847
[325]   train_loss's rmse: 0.537952     eval's rmse: 0.683754
[350]   train_loss's rmse: 0.534121     eval's rmse: 0.683636
[375]   train_loss's rmse: 0.529791     eval's rmse: 0.683658
[400]   train_loss's rmse: 0.529694     eval's rmse: 0.683653
Early stopping, best iteration is:
[358]   train_loss's rmse: 0.532824     eval's rmse: 0.683603
Model successfully saved as: models/lgbm_daywise_cv/0003.txt
~~~~ Fold 3 of 4 ~~~~ took 00:16:25
~~~~ Fold 4 of 4 ~~~~ ...
Training until validation scores don't improve for 50 rounds
[25]    train_loss's rmse: 0.907008     eval's rmse: 0.89933
[50]    train_loss's rmse: 0.706389     eval's rmse: 0.709517
[75]    train_loss's rmse: 0.657094     eval's rmse: 0.6801
[100]   train_loss's rmse: 0.630601     eval's rmse: 0.672395
[125]   train_loss's rmse: 0.609013     eval's rmse: 0.669061
[150]   train_loss's rmse: 0.592983     eval's rmse: 0.666865
[175]   train_loss's rmse: 0.581018     eval's rmse: 0.665916
[200]   train_loss's rmse: 0.570958     eval's rmse: 0.665448
[225]   train_loss's rmse: 0.561861     eval's rmse: 0.665329
[250]   train_loss's rmse: 0.554569     eval's rmse: 0.665201
[275]   train_loss's rmse: 0.548532     eval's rmse: 0.665073
[300]   train_loss's rmse: 0.543367     eval's rmse: 0.664785
[325]   train_loss's rmse: 0.538667     eval's rmse: 0.664625
[350]   train_loss's rmse: 0.534055     eval's rmse: 0.664755
[375]   train_loss's rmse: 0.530148     eval's rmse: 0.664972
Early stopping, best iteration is:
[339]   train_loss's rmse: 0.536631     eval's rmse: 0.664477
Model successfully saved as: models/lgbm_daywise_cv/0004.txt
~~~~ Fold 4 of 4 ~~~~ took 00:16:26
Fold summary (Loss):
0|      Eval:   0.681   |       train:  0.527
1|      Eval:   0.693   |       train:  0.543
2|      Eval:   0.684   |       train:  0.530
3|      Eval:   0.665   |       train:  0.530
Average Eval Loss:      0.681
Average Train Loss:     0.533
Performing 4 fold cross-validation took 01:03:36
Loading testing data ...
Loading testing data took 00:00:11
Loading models in directorymodels/lgbm_daywise_cv
Loading model [1/4] ...
Loading model [1/4] took 00:00:00
Predicting values [1/4] ...
Predicting values [1/4] took 00:44:31
Loading model [2/4] ...
Loading model [2/4] took 00:00:00
Predicting values [2/4] ...
Predicting values [2/4] took 00:32:47
Loading model [3/4] ...
Loading model [3/4] took 00:00:00
Predicting values [3/4] ...
Predicting values [3/4] took 00:48:01
Loading model [4/4] ...
Loading model [4/4] took 00:00:00
Predicting values [4/4] ...
Predicting values [4/4] took 00:46:32
Creating submission file ...
Creating submission file took 00:02:01

I am closing this issue as it does not seem to improve the public score.


Rework riscv -march and -mabi detection

Currently all the riscv*gc targets use the 'd' double-float ABI, and
soft-float otherwise. There's no need to detect the operating system
type. Fixes #795.
I'm not sure how correct this is. I've checked all the targets on version
1.69.0-nightly (ef934d9b6 2023-02-08) with this script:
rustc --print target-list |
  grep riscv |
  while IFS= read target; do
    rustc --target "$target" --print target-spec-json -Z unstable-options |
      jq --arg name "$target" -r '"\(.["llvm-abiname"]) \($name)"'
  done

Which gives:
ilp32d riscv32gc-unknown-linux-gnu
ilp32d riscv32gc-unknown-linux-musl
null riscv32i-unknown-none-elf
null riscv32im-unknown-none-elf
null riscv32imac-unknown-none-elf
null riscv32imac-unknown-xous-elf
null riscv32imc-esp-espidf
null riscv32imc-unknown-none-elf
lp64d riscv64gc-unknown-freebsd
lp64d riscv64gc-unknown-linux-gnu
lp64d riscv64gc-unknown-linux-musl
lp64d riscv64gc-unknown-none-elf
lp64d riscv64gc-unknown-openbsd
null riscv64imac-unknown-none-elf

Also I'm not sure whether to add tests or not. Please advise on this.

Additional justification for inferring the ABI: https://github.com/riscv-non-isa/riscv-toolchain-conventions#specifying-the-target-isa-with--march

A target -march which includes floating point instructions implies a hardfloat calling convention, but can be overridden using the -mabi flag

Since the Rust target implies -march, it makes sense.
I can add a comment linking to it, if the maintainers are okay with this logic in general.

Can this be revived? As it stands, cc-rs is sort-of useless for embedded RISCV*GC targets (at least without target-specific workarounds similar to mentioned in #795).

Can this be revived? As it stands, cc-rs is sort-of useless for embedded RISCV*GC targets (at least without target-specific workarounds similar to mentioned in #795).

I think it needs to resolve merge conflicts and rebase against main, then I can do another review pass on it

As original author of this PR I'm interested in reviving this

Aaaand, rebased, hope this works.
I haven't added the toolchain convention reference, because it has been removed and it's now only a de facto standard.
Honestly, we should just get the information from rustc itself once it's available...

@NobodyXu I just thought of another solution, can we just delete this section of the altogether and rely on the user to have configured the toolchain correctly or add the options for themselves?

can we just delete this section of the altogether and rely on the user to have configured the toolchain correctly or add the options for themselves?

If it is optional flags that's there to improve performance, then maybe we can do it.
If it is required for it to compile, then I think we should keep it

If it is optional flags that's there to improve performance, then maybe we can do it.
If it is required for it to compile, then I think we should keep it

Unfortunately it is required for correctness :(

What is preventing this PR from being merged as is? Would it introduce any regressions?
It might not be perfect, it might be fragile for some obscure corner cases, but right now cc-rs can't even handle the bog-standard riscv64gc arch on non-standard OSes! In particular, it blocks introducing risc-v support on Redox, at least without forking this crate which is pretty much a non-starter.
Maybe the PR could be merged in (to move the needle in the right direction), and then you guys could continue perfecting it?

What is preventing this PR from being merged as is? Would it introduce any regressions?

we were previously discussing about getting the flags from rustc codebase at build time.

It might not be perfect, it might be fragile for some obscure corner cases, but right now cc-rs can't even handle the bog-standard riscv64gc arch on non-standard OSes! In particular, it blocks introducing risc-v support on Redox, at least without forking this crate which is pretty much a non-starter.

I've posted this on zulip asking for a final review from someone understands riscv before merging in, I'm not very familiar with riscv so I don't know if it'd work/break something.
It would be great if it has CI running for riscv, with that I can merge in with confidence.

I'm still interested in working on this, although I would like some input on what kind of detection is expected here before trying to make up some logic without evidence to back it

I'm still interested in working on this, although I would like some input on what kind of detection is expected here before trying to make up some logic without evidence to back it

cc-rs has an infrastructure to extract information from rustc +nightly -Zunstable-options --print all-target-specs-json.
https://github.com/rust-lang/cc-rs/blob/main/dev-tools/gen-target-info/src/main.rs
Basically you need to modify the main.rs to parse the riscv related target information, and write them to src/target_info.rs as an (sorted) array.
Once you've done that, you'd need to run cargo run on that crate, which will generate an updated src/target_info.rs for you and you can use it in lib.rs, without hardcoding anything.
You'd also need to stage and commit src/target_info.rs as well @dramforever

I'd like to understand a state of things a little better. To give a concrete example, I'm targeting riscv64gc-unknown-redox. This is a non-standard target, using patched Rust, and it uses lp64d abi. cc-rs, as it stands now, instructs gcc to use soft-float abi so everything breaks. The PR, as it stands now, fixes that. Now, I saw several comments here what seems to be quite differing in nature.

we were previously discussing about getting the flags from rustc codebase at build time.

That should work for us I think, and for any non-standard target, including custom json target definitions.
But then the very last comment:

Basically you need to modify the main.rs to parse the riscv related target information, and write them to src/target_info.rs as an (sorted) array.

Seem to indicate an idea of hardcoding options inside cc-rs code, so that wouldn't exactly work for anything not known by stock Rust at the time of generation.
So, assuming we are left to fend for ourselves so to speak... More specifically

If it is non-standard then it would indeed makes more sense to pass them as environment variables.

How one would go about doing it? IIUC right now it is impossible to do because cc-rs would override it unconditionally. Let's say that is changed, so we'd provide CFLAGS="-mabi=lp64d" CXXFLAGS="-mabi=lp64d" (and march to boot) and make it work that way, right?
If so, it would probably be almost fine... Not exactly frictionless, as it would have to be put in bunch of places to make things like CI work; and also they have to be only present for riscv and not other targets. But that should be more manageable than the current approach of adding patches to all those Cargo.toml files.

Basically you need to modify the main.rs to parse the riscv related target information, and write them to src/target_info.rs as an (sorted) array.

Seem to indicate an idea of hardcoding options inside cc-rs code, so that wouldn't exactly work for anything not known by stock Rust at the time of generation.

What I was describing is our build time rustc target info extraction.
In the gen-target-info workspace, we get the flags from rustc, we have a workspace which run rustc and exteact target info to files that are included in cc.
We run this in CI once a week.
however, there's a better option now.
@madsmtm is working on #1225 which would enable cc-rs to use information from cargo environment if present, thus it should fix the custom target use cases.


Material Color -> MapColor

Matches class name to its string.
Adds a tiny bit of javadoc.
This name is a bit more representative of what this class actually does.
It should be noted that the color names are bad/outdated in relation to the material name improvements, but this PR will not be touching those.

But I do? Unless there's some other map in MC I missed.

People occasionally confuse it with java.util.Map java.util.Optional.map java.util.stream.Stream.map etc

I was more thinking of world/level sometimes referenced as maps, but liach has a point too. To specify it's the item, you can just link "map" to the MapItem class

shouldn't this pr find reference to MaterialColor and fix them? i.e. DyeColor#getMaterialColor

Changed the method names - there is a fapi name that needs fixing as well in AbstractBlockSettingsAccessor

Should be a quick fix since we extend AbstractBlock.Settings now in fapi. Should cause no issues updating.

This isnt ready for merge, its a very wide spread change, that will require yet another version of object builders.

Maybe like MapTexture, the texture of a block on a map?

Don't think it is tied to the material, you can have blocks that has a color that is different than the material

You can really just do MapColor or BlockColor imo

After looking at the field Imo we should call it something other than a color. clay is not a color.

As mentioned in the OP, the field names are bad and outdated. They should be ignored for the purpose of this PR.
This class is a wrapper around a list of color values for the purpose of maps. This list is a fixed size, so mods cannot add many more to it.
This PR will not handle the field renames. Will be more work to compile, and have more debate than the materials PR. I won't be doing that either, so someone else can.
MaterialColor makes no sense as the color is dependent on the blockstate.

Shall this pr refactor, it should just refactor fields as well. It is meaningless to split these into two prs that are both refactors. We can bikeshed one bikeshed at once than bikeshed bikes and the shed separately!

Given @dexman545 refuses to refactor the material color field names that he deem broken in this pr, I hereby close this pr. It is meaningless to split such a refactor into two debatable pull requests and introduce extra bikeshedding and migration difficulties.

That shouldn't be a reason to close a PR, unless you've got another PR to fix this, I don't think we should close it.

Since this is a smaller PR, it may make sense to bundle everything together.
However something larger like the past nbt PRs makes no sense to go hunting for every param name whenever it may be unmerged

@dexman545 just clarified that since material colors are just certain rgb colors and they are indeed very hard to name (like clay color doesn't really have a color name), so those field renames aren't made.

The constructor for MaterialColor takes in 2 ints: and index and an RGB value.
Its only usage is in relation to maps and for falling block particles (ie dripping lava).
Block(State)Color works, as this is the color of the blockstate. MapColor also works as it's primary purpose is for maps. MapTexture not so much as this is the color of each "pixel," not really a texture.
As for this being a wide-reaching change, I'm going to have to disagree. The color a mod's block will have on a map is, in most cases, an oversight by mod devs, as the material will provide a default template color for you, and this is the type of thing to get ignored. Also, there are also only 12 available color slots left. The values in this list are immutable, and its size is forced by the constructor (where the MapColor name comes from). Any mods that are adding colors to this are either a handful in number, or have changed the vanilla behavior.  Otherwise, we'd see tons of mod conflicts if this were common. As for mods that make a Material, they are probably using one of the pre-determined colors. In that case, migrateMappings will suffice.
This is what I meant when I said it's just a wrapper for a list: all it has are the RGB color values with named variables to easily pull them without nonsensical int values.
As for renaming the fields, I want that in a separate PR as it will be bikeshed to hell. Everyone sees color differently, and there are several very close colors in this list. The state of the current field names is rather poor. Some of them are named using the material that uses them (the old material names, or strange abbreviations of the material name), the color it actually is, or the block that has the materialcolor.
Want to name them based on the color? No one will agree on the names then. Want to rename them based on the blocks that use them? That leads to issues with things like logs that have two different material colors for verticle and horizontal states. Hex values? Sure, we can all agree on each individual name, but as a whole, they then lose their functionality, especially considering you won't get a nifty color preview to know what it looks like.
There simply isn't a good way to rename them.
The only good field rename would be AIR -> CLEAR/INVISIBLE as it includes glass etc., and is not rendered on the map.
I can update the ones that were named after the material if you want, but that doesn't fix the others.
Here are all the color's hex values, and setup so idea will show you the color on the side: https://pastebin.com/nTXgt3Dr
As an aside: maybe fapi should have something to open up the colors, but again, as no one seems to be adding colors it's probably unneeded. Not to mention, the constructor is private anyways so I doubt anyone has gone through the trouble of opening it just to add a color.

MaterialColor is a bad name for several reasons:

just because Material has a field that uses this doesn't mean this should be named as such (we don't have MaterialPistonBehavior). Whenever this property is queried, it is always via the blockstate, as this is a property that varies based on blockstate, not to mention blocks have entire MaterialColors dedicated to them, and logs have a special helper method to give them two MaterialColors.
MaterialColor means nothing at all. What does that class do? Materials define basic properties for blocks, not their color in any meaningful sense. No other material property is so commonly overridden, or has so many predefined properties used for individual blocks, not materials.
why do blocks get not only a Material, but a MaterialColor? Perhaps because MaterialColor has no meaningful relation to Material
there are more MaterialColors than there are Materials, which is a pretty good indicator that they aren't related in the way the name implies.

This rename will actually clarify what this class is doing, and what the colors actually mean.
As for object builders/fapi block settings, can't the pertinent methods just be deprecated, and properly named ones be added? Most people seemed fine with the rename aside from the fields.

@dexman545 could you resolve the conflict please?

@Yanis48 fixed

Can the outdated tag be removed? This is targeting the 1.17 snapshot.


atlauncher: <IP_ADDRESS> -> <IP_ADDRESS>

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/ATLauncher/ATLauncher/releases.
meta.description for atlauncher is: Simple and easy to use Minecraft launcher which contains many different modpacks for you to choose from and play
meta.homepage for atlauncher is: https://atlauncher.com
meta.changelog for atlauncher is: https://github.com/ATLauncher/ATLauncher/blob/v<IP_ADDRESS>/CHANGELOG.md
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found <IP_ADDRESS> in filename of file in /nix/store/c0jmymm27lzqs63n01al7h1dmci7y1gl-atlauncher-<IP_ADDRESS>

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

atlauncher

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/c0jmymm27lzqs63n01al7h1dmci7y1gl-atlauncher-<IP_ADDRESS> \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A atlauncher https://github.com/r-ryantm/nixpkgs/archive/3a69df5accdb922a83cc0a4767c57e20c989c6e9.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/3a69df5accdb922a83cc0a4767c57e20c989c6e9#atlauncher

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/c0jmymm27lzqs63n01al7h1dmci7y1gl-atlauncher-<IP_ADDRESS>
ls -la /nix/store/c0jmymm27lzqs63n01al7h1dmci7y1gl-atlauncher-<IP_ADDRESS>/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

atlauncher

Maintainer pings
cc @getpsyched for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

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

Hmm, I should probably add something to passthru.updateScript for running pname.mitmCache.updateScript automatically.
Or maybe it was done in this case? I ran it locally and there weren't any updates (as evident by the release notes).

@NixOS/nixpkgs-merge-bot merge


New version: Lenovo.LeAppStore version <IP_ADDRESS>5

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

[x] Does your manifest conform to the 1.4 schema?

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

Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/109288&drop=dogfoodAlpha

/azp run

@wingetbot run

This package's Defender scan is causing the VM to freeze with a small box in the upper corner.

This package's Defender scan is causing the VM to freeze with a small box in the upper corner.

I guess this small box is a window of Microsoft Edge. 🤔