Update kubedns-autoscaler change target

The target was a replicationcontroller but kubedns is currently a deployment

cla signed

ci check this


Updated Starscream.

A hopeful fix for https://github.com/artsy/auctions/issues/410

👍

It'd be good to have a Danger rule that posts the changelogs for changed libs: https://github.com/daltoniam/Starscream/blob/master/CHANGELOG.md


Search genres Film

Reported by Pierre Martin | January 13th, 2011 @ 01:29 AM
Original ticket posted on Github, by meotimdihia
genre is an array of Genre.id
if i only search name but dont search genre : errors: Undefined index: genres
search plugin must have data of all field in $presetVars ?
in the Controller
public $presetVars = array(
    array('field' => 'name', 'type' => 'value'),
    array('field'=>'genres','type'=>'checkbox')
);

in view.ctp
echo $form->input('Film.genres',array('type'=>'select','multiple' => 'checkbox','options'=>array(1=>'adventure',2=>'action')));

Error can be fixed with:
if (empty($this->data['Film']['genres']))
  $this->data['Film']['genres'] = null;

Need more info about errror and how to reproduce it.

Closing this because no more feedback was provided.


Pause instead of cancel

Is it possible to have the failsafe pause the printer instead of cancel the print?  This would allow the user to possibly fix the problem and then continue printing.

You should be able to achieve this by unchecking the 'cancel print' checkbox and using the shell script to fire an API call to the OctoPrint API to pause the print.  I'll look into adding this as a default feature though.

That would be very much appreciated.  Thanks for your good work.


How is the accuracy and memory usage as compared to Faster Whisper?

I am using Faster Whisper and the accuracy for Faster Whisper is supposed to be the same as the OpenAI model. Additionally, the memory usage is much lower than the OpenAI model. How does Insanely Fast Whisper compare on both of those fronts?

Anecdotally, I would say the accuracy is worse. The huggingface implementation, which this uses, applies a stride to the chunks. Meaning, some of the input, is duplicated across multiple chunks. They do this to add context, to compensate for the fact that the batched implementation does not get the context from previous chunk, since they are run in parallel.
The issue with this is, it often results in the same text being repeated multiple times, due to the overlapping chunks. In theory, this is corrected via some heuristics, but in practice, I have not found it to work well.
Also, in the huggingface implementation, they do not apply the hallucination checks to chunks shorter than 30 seconds. And in the case of batch inference, every chunk is 30 seconds or less.
https://huggingface.co/blog/asr-chunking

Haven't found anything for whisper hallucinations so far. And end up writing a simple postprocessing workaround for repeated chunks/hallucinations.
`import json
import sys
def find_identical_rows(file_path, N):
line_positions = {}
# Open the file and read line by line
with open(file_path, 'r') as file:
    for line_number, line in enumerate(file, start=1):
        # Remove any leading/trailing whitespace characters
        line = line.strip()
        if not line:  # Skip empty rows
            # print("EMpty line!")
            continue
        if line in line_positions:
            # print("line is already in the dictionary:", line)
            line_positions[line].append(line_number)
        else:
            # print("line is not in the dictionary:", line)
            line_positions[line] = [line_number]

# print(json.dumps(line_positions, sort_keys=True, indent=4))

# Identify lines that occur more than once and check the distance
identical_rows = []
for line, positions in line_positions.items():
    if len(positions) > 1:
        # print(line, positions)
        for i in range(len(positions) - 1):
            if positions[i + 1] - positions[i] <= N:
                identical_rows.append((line, positions))
                # print("Identical", i+1, positions[i + 1], i, positions[i])
                break

# Print lines that meet the criteria
if identical_rows:
    # print(file_path, "Identical rows with required distance:")
    print(file_path)
    for row, positions in identical_rows:
        print(f"(Positions: {positions}) {row}")
#else:
    #print("No identical rows found with the required distance.")

input_file = sys.argv[1]  # Get the input file path from command-line arguments
find_identical_rows(input_file, 12)
`


New Lotus sighash

This replaces (but not yet renames) the BIP341 sighash introduced two months ago.
It allows smart contracts to more easily access parts of the transaction, e.g. by hashing the inputs/outputs in a merkle tree.

Let's just call it SIGHASH_RHIZOME or SIGHASH_LOTUS_ROOT or something


AppCenter iOS SDK v4.0.0 naming convention

For a public product I think a couple of type names (I only work with Analytics and Crashes, but ServiceAbstract  and ErrorReport also seem to qualify) you've chosen for v4.0.0 of the iOS SDK are too generic and have a potential to create namespace collision issues.
On a project that I work on, I have a protocol named Analytics which defines APIs that multiple analytics SDKs used in my app expose.
This conflicted straight-up with the Analytics class in AppCenter.
I got around it by using the fully-qualified class-name but I think that for a public product, some less generic class names should have been chosen.
This is my opinion, and I am by no means an expert on this topic, but I thought I should share this feedback.

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

ID: 34fd58f9-ea70-d0ba-3348-60ae07299df4
Version Independent ID: 2d6c5944-5b2a-9a1d-f8b4-9f1b0d51bcaa
Content: How to migrate to App Center SDK 4.0.0 and higher - Visual Studio App Center
Content Source: docs/sdk/getting-started/migration/apple-sdk-update.md
Service: vs-appcenter-sdk
Sub-service: app-center-general
GitHub Login: @King-of-Spades
Microsoft Alias: kegr

Hi @amanssharma,
Mentioned names are Swift aliases for Objective-C classes that have "MSAC" prefix that makes it unique. Objective-C doesn't have namespaces, but Swift has another convection, all classes there are in namespaces. It is implicit in Swift, meaning that all types, variables (etc) are automatically scoped by the module. You need to put the package name in front of the class name to resolve the conflict. Something like: YourTargetName.Analytics

Hi @amanssharma,
Mentioned names are Swift aliases for Objective-C classes that have "MSAC" prefix that makes it unique. Objective-C doesn't have namespaces, but Swift has another convection, all classes there are in namespaces. It is implicit in Swift, meaning that all types, variables (etc) are automatically scoped by the module. You need to put the package name in front of the class name to resolve the conflict. Something like: YourTargetName.Analytics


Update system smart-contracts to v1.5.1

Update system smart-contract to version v1.5.1.
To build them, you must use the CDT version 1.4.1 and Cyberway version 1.4.4.
Also changed next methods of token smart-contract: get_supply, get_issuer, get_balance. These methods are made static.

can't build, it requires new cyberway version installed
 Could not find a package configuration file provided by "eosio" with any of
  the following names:

    eosioConfig.cmake
    eosio-config.cmake


🐛 Bug Report: Broken AzureDevOpsEntityProvider ingestion with branch setting since 1.23

📜 Description
AzureDevOpsEntityProvider does not ingest (anymore) if a branch is defined in app-config.yaml
catalog:
  providers:
    azureDevOps:
      yetAnotherProviderId:
        organization: myorg
        project: '*'
        branch: development
        path: /catalog-info.yaml

Works somehow with 1.22. Works with default branch (or without branch setting).
👍 Expected behavior
Ingests entities from a AzureDevOps repo branch
👎 Actual Behavior with Screenshots
AzureDevops ingestion is skipped
👟 Reproduction steps

configure a branch app-config.yaml for catalog ingestion from AzureDevops
start app
ingestion for Azure DevOps always found 0 entities to ingest

📃 Provide the context for the Bug.

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, I don't have time to work on this right now

Hey @djflocko , will it work if you fully qualify the branch name?
For example refs/heads/development

Thanks - I'll be upgrading my instance to 1.23 this week so I'll try to take a look at it.

@djflocko Did you add the branch development as "Searchable Branch" in your Azure DevOps Repository setting? Ref: https://backstage.io/docs/integrations/azure/discovery#installation

@deepan10 I really hadn't set this, but unfortunately it has no effect.
BTW: I use a location kind in the catalog-info.yaml to point to a target in the repo. Works for main but not here - not sure if that's related.
apiVersion: backstage.io/v1alpha1
kind: Location
metadata:
  name: location-abc
  title: abc
  description: A collection of abc entities
spec:
  targets:
    - ./.backstage/components.yaml
    - ./.backstage/systems.yaml

@djflocko
Your app-config.yaml says you are fetching catalog-info.yaml from developement branch. And kept your location kind in catalog-info-yaml to add components.
In this case, if you didn't set the searchable branch, Azure DevOps provider doesn't reach the catalog-info.yaml from your developement branch.
And one more, do you have any rule configured in the catalog as mentioned below?
https://github.com/backstage/backstage/blob/b9d9f4199fe005f1df83b6c03f1d11c9f162a4fd/app-config.yaml#L232-L244

@djflocko Your app-config.yaml says you are fetching catalog-info.yaml from developement branch. And kept your location kind in catalog-info-yaml to add components.
In this case, if you didn't set the searchable branch, Azure DevOps provider doesn't reach the catalog-info.yaml from your developement branch.
And one more, do you have any rule configured in the catalog as mentioned below?
https://github.com/backstage/backstage/blob/b9d9f4199fe005f1df83b6c03f1d11c9f162a4fd/app-config.yaml#L232-L244

I enabled the search option for the branch in ADO, but it had no effect (at least not within 20min - maybe I was too impatient ). Sure, I have the rules to allow these entity types.

@djflocko Can your complete app-config.yaml and catalog-info.yaml I will try to replicate the same.


best way to clean up / stop autosave behavior?

Can you please provide me a code example of how we can clear the timer and uninitiate autosave?


x989 As a PO (Minal) I would like to specify the locations of sections inside a slot on an Visium slide to support lots of small sections for HTA purposes

Visium Slides - TO, LP,
new category of comments to describe section location in the sectioning confirmation page.
Only select one comment.
Only select when there are multiple sections in a slot
'Slot Region' field is mandatory for slots with multiple sections
Comments:
Top Left:
Top Right:
Bottom Left:
Bottom right:
Middle
Top
Bottom
Left
Right"
Notes:
need to look at this and its impact on Cytassist
XXL

Slot region is mandatory when adding multiple sections in a slot; not required when putting a single section in a slot.


Context menu is sometimes obscured by terminal

Does this issue occur when all extensions are disabled?: Yes

VS Code Version:
OS Version: Version: 1.70.0-insider (user setup)
Commit: 3104db414c8fedcf6e4493f14da7df0b7413853a
Date: 2022-07-08T05:20:13.606Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19044

Steps to Reproduce:

Open Terminal and run git diff
In a text editor, click on the margin where you have unstaged changes. The git diff peek opens
In the peek, right click an added region.

See screenshot

/duplicate https://github.com/microsoft/vscode/issues/146638


Avatar mesh not created in the scene

I have downloaded the recent UMA 2 from the Asset Store and all worked great. As soon as I installed Unity 2017.1p5, I get the error:
SkinnedMeshRenderer: Trying to set a mesh ("") that is unfit for use with SkinnedMeshRenderer. Most likely it doesn't have Skin information and/or is only assigned to the renderer during runtime, in which case Unity isn't aware of its use with SkinnedMeshRenderer. Mark the mesh as Readable or assign it to the renderer in the Editor before building.
UnityEngine.SkinnedMeshRenderer:set_sharedMesh(Mesh)
UMA.UMADefaultMeshCombiner:MakeRenderer(Int32, Transform) (at Assets/UMA/Core/StandardAssets/UMA/Scripts/UMADefaultMeshCombiner.cs:96)
UMA.UMADefaultMeshCombiner:EnsureUMADataSetup(UMAData) (at Assets/UMA/Core/StandardAssets/UMA/Scripts/UMADefaultMeshCombiner.cs:44)
UMA.UMADefaultMeshCombiner:UpdateUMAMesh(Boolean, UMAData, Int32) (at Assets/UMA/Core/StandardAssets/UMA/Scripts/UMADefaultMeshCombiner.cs:117)
UMA.UMAGeneratorBuiltin:UpdateUMAMesh(Boolean) (at Assets/UMA/Core/StandardAssets/UMA/Scripts/UMAGeneratorBuiltin.cs:282)
UMA.UMAGeneratorBuiltin:HandleDirtyUpdate(UMAData) (at Assets/UMA/Core/StandardAssets/UMA/Scripts/UMAGeneratorBuiltin.cs:226)
UMA.UMAGeneratorBuiltin:OnDirtyUpdate() (at Assets/UMA/Core/StandardAssets/UMA/Scripts/UMAGeneratorBuiltin.cs:265)
UMA.UMAGeneratorBuiltin:Work() (at Assets/UMA/Core/StandardAssets/UMA/Scripts/UMAGeneratorBuiltin.cs:132)
UMA.UMAGeneratorBuiltin:Update() (at Assets/UMA/Core/StandardAssets/UMA/Scripts/UMAGeneratorBuiltin.cs:97)

Confirmed that this is not caused in 2017.1p4.
Occurs in 2017.1p5 (tested) and 2017.2 b8 (tested)
Downgrading back to 2017.1p4 works fine as a workaround.

Great! I will wait for a fix. Hope it will come soon.
Thanks!

Does anyone know if this still applies to 2017.1 ?

I downloaded the latest non beta version a couple days ago. I think it was
2017 1.1. And it was working, no issue.
On Sep 15, 2017 8:16 AM, "checkpointng"<EMAIL_ADDRESS>wrote:

Does anyone know if this still applies to 2017.1 ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/umasteeringgroup/UMA/issues/33#issuecomment-329812676,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADnmmxv1LxMqnS2hBhL24mSrEedc5FAhks5sipTmgaJpZM4PDYty
.

2017.1 all versions with patches including teh recent one - all seems OK.

Thanks for checking.


Cannot create two instances of Open Hash Map in the same file

When I try to create two instances of Open Hash Map in the same file as per the following file, I get errors on type redefinition whereas I was expected to be able to do it:
typedef struct bar_s {
  unsigned long key;
  unsigned long value;
} bar_t;

#define POTTERY_OPEN_HASH_MAP_PREFIX map_ulong

#define POTTERY_OPEN_HASH_MAP_VALUE_TYPE bar_t
#define POTTERY_OPEN_HASH_MAP_KEY_TYPE unsigned long
#define POTTERY_OPEN_HASH_MAP_REF_KEY(v) v->key
#define POTTERY_OPEN_HASH_MAP_KEY_HASH(x) (x)
#define POTTERY_OPEN_HASH_MAP_KEY_EQUAL(x, y) (x == y)
#define POTTERY_OPEN_HASH_MAP_LIFECYCLE_MOVE(p,q) memcpy(p, q, sizeof (bar_t))

#include "pottery/open_hash_map/pottery_open_hash_map_static.t.h"

#define POTTERY_OPEN_HASH_MAP_PREFIX map_ulong2

#define POTTERY_OPEN_HASH_MAP_VALUE_TYPE bar_t
#define POTTERY_OPEN_HASH_MAP_KEY_TYPE unsigned long
#define POTTERY_OPEN_HASH_MAP_REF_KEY(v) v->key
#define POTTERY_OPEN_HASH_MAP_KEY_HASH(x) (x)
#define POTTERY_OPEN_HASH_MAP_KEY_EQUAL(x, y) (x == y)
#define POTTERY_OPEN_HASH_MAP_LIFECYCLE_MOVE(p,q) memcpy(p, q, sizeof (bar_t))

#include "pottery/open_hash_map/pottery_open_hash_map_static.t.h"

Here are the first errors:
include/pottery/open_hash_map/impl/pottery_open_hash_map_forward.t.h:30:14: error: nested redefinition of ‘enum pottery_ohm_bucket_state_t’
 typedef enum pottery_ohm_bucket_state_t {
              ^
include/pottery/open_hash_map/impl/pottery_open_hash_map_forward.t.h:30:14: error: redeclaration of ‘enum pottery_ohm_bucket_state_t’

I think this is fixed. Looks like I was missing a number of defines for open_hash_map. I have some ideas on how to add better tests for the identifier renaming but I haven't had the chance to implement them yet. In the meantime I added your example as a unit test.
I'm getting some compiler warnings when compiling the latest develop as C++17, so I don't know if the unit tests will pass or not. It might be a new warning introduced by the latest GCC. I'll take a look at it tonight. It doesn't have anything to do with this issue though so your example should work at least.


Support list.imul

Codecov Report

Merging #884 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #884      +/-   ##
==========================================
+ Coverage    63.7%   63.72%   +0.01%
==========================================
  Files          88       88
  Lines       14761    14767       +6
  Branches     3270     3270
==========================================
+ Hits         9404     9410       +6
  Misses       3214     3214
  Partials     2143     2143

Impacted Files
Coverage Δ

vm/src/obj/objlist.rs
74.31% <100%> (+0.3%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 180ec22...9d40a4c. Read the comment docs.

Looks good to me!


Running friendlyhello app on MacOS Sierra does not work as expected

File: get-started/part2.md, CC @johndmulhausen
I'm running MacOS Sierra 10.12.5 with docker installed via Homebrew. I have followed part 1 and part 2 and was about to run the friendlyhello app. According to the documentation I should be able to reach the app at http://localhost:4000 after executing the following command, but it does not work.
docker run -p 4000:80 friendlyhello

However, the command below works:
$ curl $(docker-machine ip default):4000

Hello World!
Hostname: 788cc43b990d
Visits: cannot connect to Redis, counter disabled

I have just started to learn Docker. Based on some Googling this seem to actually be the way Docker works on MacOS. If that's correct, I think a note should be added so others don't get confused.

It would appear that you have created a VM with Docker Machine named default and are using it to deploy. This may be the default setup for Homebrew. However, you should be using Docker For Mac which includes a virtual machine solution built in. Then you won't get this problem. :)


Learning GuideLine

Good day Sir/Maa I am RIghtTech by Name. I am a beginner in Learning ASP. NET but it takes to times to understand from the video at microsoft.com because those video are for experts pls what way can you advise me on how to be expert in the fields. Thanks in anticipation.

Depending on your experience, you will need to learn C# and .NET first (you can't run before you learn to walk). Once you become relatively comfortable then you should start watching/reading tutorials in the technology you're interested in (i.e. ASP .NET). Once you're comfortable following tutorials then try to change something on your own. It all comes down to the experience and determination, there is no really shortcut...
Good luck!
Please let me know if you have any questions


*Seq methods

This was documented, but they don't exist anymore...
Collection Methods and *Seq Methods
There are a number of collection methods provided, such as fold, map, and
filter. These methods assume that they are acting on a
FunPromise<T extends Iterable<U>>, and the type system will ensure that you
are if you're using Typescript: attempts to call those functions on something
that is not Iterable will end up with a return type of FunPromise<never>.
If, however, you circumvent the typing (eg: by using JavaScript to call the
method), then the resolved value of the FunPromise will be cast to an array
using _.castArray from Lodash,
which probably does what you want.
There are also methods whose names end in *Seq. These methods also operate on
a FunPromise<T extends Iterable<U>>. They are functionally identical to their
Seq-less counterparts, but with one additional guarantee: the first element of
the iterable will be forced to resolve and will be processed before ever looking
at the second element, and so on. This may be useful for debugging or other
times when you are particular about making sure one thing works before the next
occurs.

It might be better to implement this as a subclass of FunPromise.


Provides the hostGroup to the special agents

we decided against using a separate field in the CR, because that would let the customer set it in 2 different places (in args and in the new field), which would just introduce more logic trying to make sure that the user doesn't do anything dumb.


KV: Update plan type component

Clarifies that KV is available on all plan types.
There is not a specific “workers_all” or “workers_paid” type — “all” may be confused with zone plans — so this is only an interim fix.
cc @Maddy-Cloudflare @kodster28

I've added new workers_paid and workers_all plan types to the <plan> shortcode/component.


Could you release pretrained models?

Sorry for the late reply. I found our old storage is thrown away, so my checkpoints are also not available.


What privileges exactly Mist Privileged Helper needs?

What privileges exactly Mist Privileged Helper needs to create a bootable installer?
Corporate protection software blocks it:

Any chance I can give permisions manually and re-run the 'Create bootable installer' step again?

Mist requires Full Disk Access, as it has to download + write temporary files to disk.
You can enable this via System Settings:


Docker Example doesn't work

The docker example depends on a parameter that is not specified parameters.cacheImages, and so doesn't work 'out of the box'

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

ID: 77c20289-dab2-7a6e-4f63-4b30eaff2c71
Version Independent ID: d75cc196-90c1-8291-9907-ff405bde4edf
Content: Pipeline caching - Azure Pipelines
Content Source: docs/pipelines/release/caching.md
Product: devops
Technology: devops-cicd-release
GitHub Login: @ramiMSFT
Microsoft Alias: rabououn

There's additional problems with the sample. The docker load command should be:
 docker load -i $(Pipeline.Workspace)/docker/cachedDocker.tar

@AHoran Thanks for the feedback!

@AHoran Thank you for your feedback! The updated content will go live shortly


X.L.Hidden and toggle fullscreen not working properly

Problem Description
full-screen not working with hidden windows
Steps to Reproduce

hide some windows
focus on any window and toggle it full-screen
some hidden window will be toggled full-screen, and toggle again, all the hidden windows are restored.

Expected behavior: the focused window should go  full screen, and toggle again, the hidden windows should remain hidden.
Configuration File
import XMonad.Layout.Hidden
myLayout =
                   mkToggle (NBFULL ?? NOBORDERS ?? EOT) .
                   hiddenWindows $
                   myDefaultLayout
     where
            myDefaultLayout = tall

, ((modMask, xK_f), sendMessage $ Toggle NBFULL )
, ((modMask, xK_x), withFocused hideWindow)

main :: IO ()
main = do
    xmonad $ desktopConfig {
    layoutHook = myLayout
}

Checklist

[x] I've read CONTRIBUTING.md

I tested my configuration

[x] With xmonad version 0.16.999 (commit 33a86c0)
[x] With xmonad-contrib version 0.16.999 (commit 0c6fdf4)

As per the instructions in the issue template

Please include the smallest full configuration file that reproduces the problem you are experiencing:

please try to post "copy pasteable" configuration files:
import XMonad
import XMonad.Layout.Hidden
import XMonad.Layout.MultiToggle
import XMonad.Layout.MultiToggle.Instances
import XMonad.Util.EZConfig

myLayout = mkToggle (NBFULL ?? NOBORDERS ?? EOT)
         . hiddenWindows
         $ Tall 1 (3/100) (1/2)

main :: IO ()
main = xmonad $ def { layoutHook = myLayout }
 `additionalKeysP` [ ("M-f", sendMessage $ Toggle NBFULL)
                   , ("M-x", withFocused hideWindow)
                   ]

The issue here seems to be that hideWindow (as per its documentation) hides windows "from the current layout" and not in general.  The NBFULL toggle, however, just switches to noBorders Full (which is not and really can't be part of the current layout).  In effect, we have changed the current layout and thus the previously hidden windows become visible again.
Indeed, I'm not sure this is "fixable" on the X.L.MultiToggle side because transform—by design—returns a modified layout and does not just execute an action on the current layout.

clear explanation😯 so technically not an issue? any workaround? this fullscreen toogle makes hidden windows meaningless

On Wed, Sep 22 2021 10:58, HALS wrote:

so technically not an issue?

Indeed; at least I think that any potential "fix" would introduce lots
of regressions that really aren't worth it.

any workaround?

You could add noBorders Full to your layout, keep track of the most
recently used single layout in some extensible state and then bind some
key to either switch to noBorders Full or (if already there) toggle
back to the previous layout.  Not sure if there is a more elegant solution


Image creation from latent code

Good paper, thanks for the code.
I want to try a few things in latent code editing, and I'm looking for a way to create an image directly from the latent code. Any help in this regard would be of great help.
Thank you.

You have a loaded generator you can generate the image using something like the following:
images, _ = self.generator([latents],
                                              weights_deltas=weight_deltas,
                                              randomize_noise=False,
                                              input_is_latent=True)

where weight_deltas is the output of the hypernetwork. If you don't have any weight offsets, you can simply set this argument to None.

Thank you.
'weights_deltas=None ' was the difficulty I had. thank you it was a great help


feat(editor): bracket colorization

This is a continuation of #2344 . I open a new PR to make it clearer.

If I understand it correctly, it parses the whole document on every update. I'm concerned about the performance for big documents. Do you think you can change it to only parse the part on the screen?

If I understand it correctly, it parses the whole document on every update. I'm concerned about the performance for big documents. Do you think you can change it to only parse the part on the screen?

Yes and that's my plan for next step. I also roughly tested the current implementation on an M2 mba and in release mode I start experience lagging when the file is ~20000 lines long. Without colorization I can experience the similar lagging at ~30000 lines. I can add a switch to disable colorization beyond 20000 lines or so until I work out the partial update.

Do you think you can change it to only parse the part on the screen?

As bbrabbitt already kinda said, it's much easier said than done, as is explained in this vscode blog post (originally linked to by bbrabbitt).

I can add a switch to disable colorization beyond 20000 lines

This is definitively required but based on the byte size of the file, if vscode can open >15MB single line json files, lapce should also do it, but faster.


Block-Style Interaction?

Hey,
It's a matter of taste, but if I were going to use TextFieldCounter (I'm not, currently), I'd prefer a block for handling when max length is reached.
textField.onMaxLengthCrossed { overLimit in
  submitButton.isEnabled = !overLimit
}

I don't love onMaxLengthCrossed as a name, but I couldn't think of anything better right away, so if you decide to add a block handler, maybe you can think of a better name.
On that note, it seems important to have a notification on the delegate if the max limit is "unreached" as well -- for instance in the block above, to re-enable the submit button.

Hello @geoffreywiseman
It's an interesting approach. Feel free to submit a PR with these changes.


ARROW-16413: [Python] Certain dataset APIs hang with a python filesystem

Did you find out where the code was hanging previously?

The issue was caused by the gil being held?

Basically: the main thread in Python would call Inspect() without releasing the GIL; the Parquet Inspect() implementation would kick off a file read in a background thread and block, waiting for the future to complete. The background thread would try to call into Python to complete the read but would get stuck acquiring the GIL since the main thread was still holding it.
Short term we can release the GIL, longer term it might be nice if we could avoid a background thread for synchronous situations like this.

@github-actions crossbow submit test-conda-python-3.9-dask-latest test-conda-python-3.9-dask-master

I browsed through our dataset python code, and I think there are no other remaining cases where there is filesystem interaction without releasing the GIL.
 It seems that the file listing of the dataset is using file paths relative to the root of the dataset folder (where the _metadata file lives). And thus when trying to read it, it gives a FileNotFound error (since those files are located in some temporary directory, and relative paths don't work).
While if I test this locally, I properly get absolute paths (also when using fsspec). And also with s3 instead of local filesystem (earlier on this PR), the windows tests were passing.
We are already normalizing the metadata path inside ds.parquet_dataset(..) (and inside FileFromRowGroup in C++, where we combine the path defined in the _metadata file with the root path), so my assumption is that this is some issue with the fsspec filesystem on Windows.
So maybe we can skip this test for now for Windows, and open a follow-up JIRA for investigating it further? (and potentially open upstream issue) In practice users shouldn't run into this failure, as internally we translate a local fsspec filesystem to a native one.
The dask integration tests are still failing, because of the test_s3.py tests I added (the moto server timed out). I ensure locally that those are passing now, so this can probably also be done as a follow-up.

Although based on this comment (another parquet_dataset related test, and one that uses a PyFileSystem as well, but wrapping our own LocalFileSystem to add some logging in the middle), it seems we got similar issues in the past, and it might not necessarily be related to fsspec:
https://github.com/apache/arrow/blob/3c3e68c194ca6ac07086ddc1bb44fe153970213e/python/pyarrow/tests/test_dataset.py#L3261-L3264

@jorisvandenbossche what the status of this PR? Do we expect the crossbow builds to pass?

Yes, they should pass now (because I reverted the changes to it, which caused the failures above, see second bullet point in summary at https://github.com/apache/arrow/pull/13033#issuecomment-1116180259). But will trigger them again to be sure.

And if we are fine with skipping the test on Windows for now (see https://github.com/apache/arrow/pull/13033#issuecomment-1116180259), I think this is ready to go.

Should we file follow-up issues for the Windows issues? If there's already a TODO in the code it would be good to link it to a Jira for future investigation

Yes, I will open follow-up JIRAs

As follow-ups, I opened:

[ARROW-16458] [Python] Run S3 tests in the nightly dask integration build
[ARROW-16460] [Python] Some dataset tests using PyFileSystem are failing on Windows


[AutoDiff] improve symbol linkage

Implements most of the symbol linkage design, enough to fix two linker issues: TF-690 & TF-1025. (There are a few other linker issues in JIRA. I'll check later if this fixes any of those).
Specific changes:

Changed the linkage and serialization of witnesses, derivative functions, and closures to match the design.
Made deserialized witnesses from other modules not get emitted into the current module IR, by setting their linkage to public_external, and teaching IRGen not to emit public_external witnesses. (Fixes TF-1025).
Added diagnostic for calling private derivatives from serialized functions (Fixes TF-690).

This PR does not include the following pieces of the design:

Fixing linkage of thunks. I'll do this in a later PR.
The solution to allow closures in differentiable function default arguments (TF-1030).

This seems "dangerous" so I'll run swift-apis and swift-models tests on it. (e.g. without https://github.com/tensorflow/swift-apis/pull/573, swift-apis would fail to compile after this PR).

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow macos


Mepo style for local name of repos

The current default, hard coded in components.yaml, is to have remote repo noted with a @ prefix, e.g.,
ecbuild:
local: ./@cmake/@ecbuild
remote: ../ecbuild.git
tag: geos/v1.0.6
Some of us would much rather have @ as a suffix so that the @ never gets typed because of tab completions. The suggestion is to change the syntax of the components.yaml file to something like:
ecbuild:
local: ./%cmake/%ecbuild
remote: ../ecbuild.git
tag: geos/v1.0.6
where %denotes an external repo.  The following command line option is added to mepo:
-s, --style    naked|prefix/suffix|verbose
allowing the local name to have user selectable styles:
naked:       ./cmake/ecbuild
prefix:       ./@cmake/@ecbuild
suffix:        ./cmake@/ecbuild@
verbose:    ./cmake (repo)/ecbuild (repo)
For convenience, this choice could be encoded in $HOME/.mepoconfig along with other mepo specific aliases.
    Arlindo

@amdasilva How necessary is the verbose method? Passing quoted strings to subprocess to retain the space seems to be quite exciting. Some people say to use shell=True but I really do not want to do that because of security considerations. I'll keep trying to figure it out, but I might have to re-write a good chunk of mepo to support it as we use split a lot.

@mathomp4  can I ask you to elaborate a bit?    Presumably where we use split it is not on spaces, as we currently don't use spaces.    The spaces in this case should all be in the middle of a string and normal operations should not be stripping them.   I suppose the os utilities that construct paths might have a bias against embedded spaces as using them on the command line requires an escape?
I do agree that this seems to be lower priority than the other cases.

@amdasilva   Can we leave the "raw" repo indicator as @ instead of %?    By doing this, we would avoid any need to change the existing fixtures (except AeroApp)?        I suppose it is possible that this change to mepo will allow the older configuration.yaml files to still function, in which case I withdraw my concern.   Otherwise it is a hassle to coordinate the various changes.

@amdasilva Can we leave the "raw" repo indicator as @ instead of %? By doing this, we would avoid any need to change the existing fixtures (except AeroApp)? I suppose it is possible that this change to mepo will allow the older configuration.yaml files to still function, in which case I withdraw my concern. Otherwise it is a hassle to coordinate the various changes.

@tclune @amdasilva Actually, we don't need to change anything at all. I have some code that doesn't care how the components.yaml is set up. This is probably more of a quirk of mepo (and I say requirement) but we know that we are checking out the repo in the last node of the local: key. So, the last node of the value of the local: key is the "location" of the repo. So, I made up some code that can just use that last node and figure things out. Seems to work, though a bit slow.

@mathomp4 can I ask you to elaborate a bit? Presumably where we use split it is not on spaces, as we currently don't use spaces. The spaces in this case should all be in the middle of a string and normal operations should not be stripping them. I suppose the os utilities that construct paths might have a bias against embedded spaces as using them on the command line requires an escape?
I do agree that this seems to be lower priority than the other cases.

@tclune The issue is that mepo current does things like:
    def clone(self, version, recurse):
        cmd = 'git clone '
        if recurse:
            cmd += '--recurse-submodules '
        cmd += '--branch {} --quiet {} {}'.format(version, self.__remote, self.__local)
        shellcmd.run(cmd.split())

We run split on a command string rather than constructing from lists (which gets very tedious and hard to read). I am going to look at rewriting all the places in the code we run shell commands but it is a LOT since mepo is essentially just running shell commands.
 I've looked at quoting with shlex, but it's not doing what I want. I'll keep looking at it, but I am not a real Python guru. I'm trying and I'll keep trying, but spaces in paths look to be fun.

Note also: I know you want a .mepoconfig but that will probably be a separate update. I don't want to do two things at once for this. I'll look at adding the style, first then I'll see what I can do for a mepoconfig.


Add New work ”Intrinsic Evaluation of Unlearning Using Parametric Knowledge Traces“.

Hi, Dear manager,
I would like to know whether you would be willing to add our new paper: Intrinsic Evaluation of Unlearning Using Parametric Knowledge Traces.
We believe that the knowledge vectors we have identified, their verified importance in storing target knowledge, and the corresponding analysis have significant implications for both unlearning and knowledge editing areas. I would suggest placing it under the Analysis Section and Benchmark Section.
Thank you very much for your kindness!
paper: https://arxiv.org/pdf/2406.11614
code: https://github.com/yihuaihong/ConceptVectors
website: https://yihuaihong.github.io/ConceptVectors.github.io

Thank you for your suggestions.
Your work highlights the challenge and importance of erasing learned concepts in LLMs, which has significant implications for both unlearning and knowledge editing areas. We have placed your work under the Analysis Section and Benchmark Section.
If you have any further advice or discussions, please contact us anytime.

Thank you very much! 😀


Update document to 0.0.8

Updates es.weso:document from 0.0.3 to 0.0.8.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "es.weso", artifactId = "document" } ]

labels: library-update, semver-patch

Codecov Report

Merging #49 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master     #49   +/-   ##
======================================
  Coverage    59.4%   59.4%
======================================
  Files          97      97
  Lines        4239    4239
  Branches      182     182
======================================
  Hits         2518    2518
  Misses       1721    1721

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c2ef3ac...3b74141. Read the comment docs.


Add Get Mac Apps instruction

curl -s http://www.getmacapps.com/raw/2c6ni988x | sh

I decided I didn't want to do this


Suggesting a roadmap for v0.1

Hi Laurent
First of all, I wanted to thank you again for making this happen. Given the pace of the developments and I would love to see an amazing NN crate for Rust, below are my suggestions for v0.1 release.

[ ] Improve error handling:

[x] Use failure crate for error handle.
[ ] Less panic and use unsafe_torch_err! more often.
[ ] Handling device errors #16

[ ] Various idiomatic Rust improvements:

[ ] Customizable optimizers #18

[ ] More unit test coverage.
[ ] Improve overall documentations.

[x] For module level docs use //!
[ ] Add doc examples more important methods/functions.
[ ] Cross-reference modules.

[ ] Decouple implementations from codegen.
[ ] Complete tutorials at least as much as the ocaml-torch equivalent.
[ ] Integration with Rust ndarray.
[ ] GPU build and testing:

[x] Local
[ ] CI (no free option)

[ ] Cover as much as PyTorch API as possible. (see how it goes?)

[ ] Linalg ops for dense and sparse tensors.
[ ] Add as much nn ops as possible in nn.
[ ] Initializers.
[ ] Data loading and augmentations.
[ ] Multiprocessing with rayon.
[ ] Distributed (though it's harder).

[ ] Pytorch extensions C++ <--> C <--> Rust
[ ] Subcrate core, vision, model_zoo, ffi inside tch through vitual workspace manifest.

Since you've put a lot of efforts so far and I guess functionality-wise you want to make this crate mimic your other similar projects, please let us know of any other plans to be on the same page.

Thanks for putting this together, indeed there is quite a bit of polishing needed to reach v0.1. To me the most important point is improving tutorials/examples (and documentation). This should help defining the good patterns for the library. I think good starting points are trying to port existing pytorch tutorials or the examples that I've put together in the ocaml version - this includes GAN, RL, finetuning models, etc... I feel that design choices should be defined by usage/feedback - and hopefully the api in its current form could already be used to do pretty nice things.
Currently we have three main examples:

The MNIST examples, with some quickly written tutorial.
The CIFAR example which has quite good performance (~95% accuracy).
The char-rnn example, also with some small write-up.

As per the scope, I feel that torch-sys should be the C unsafe bindings, tch should stay as close as possible to the C++ api but provide a type safe api on top that could be used to build/train most models. There is certainly room for some higher level api that would be better typed and more rust idiomatic, e.g. the type system currently does not provide information on the type of elements in a tensor, the device, the dimensions. It would probably be quite fun to do, but to me it's a bit out of scope for now.
More specific points:

API coverage should be pretty good already (as it's automatically generated), do you have specific points in mind?
GPU training should already work, I'm using it for most examples. We should indeed consider having it supported in CI but I'm not sure if there is some free option for this.
In the ocaml version I implemented most of the vision models that can be found in the python api torch::vision. I'll probably try to add some of these soon - and will provide pre-trained weights so that they can be used out of the box.
Jupyter interaction would be a nice thing to have/experiment with.

I've also posted on users.rust-lang.org to see if we can get more feedback.

I general, I'd like to help make the crate more idiomatic. Several conversions, error handling, more test coverage, Rust ndarray integration (added to the list above) etc. can be improved and I've already started it from the most important ground-level improvements :)

... tch should stay as close as possible to the C++ api

I haven't used the torch C++ API (still unstable I think!). I thought you're targeting more of Python APIs, since this is what people are more interested in and the selling point for Python-DL community to come to Rust could be much greater that C++-Pytorch coming to Rust.

... the type system currently does not provide information on the type of elements in a tensor, the device, the dimensions. It would probably be quite fun to do, but to me it's a bit out of scope for now.

Absolutely! I'm working on this part now along with other idiomatic improvements that I see.

API coverage should be pretty good already (as it's automatically generated), do you have specific points in mind?

Well, comparing to PyTorch Python API there're a lot to be covered, but step by step :)

GPU training should already work, I'm using it for most examples. We should indeed consider having it supported in CI but I'm not sure if there is some free option for this.

Great! yes, CI won't be free AFAIK.

Jupyter interaction would be a nice thing to have/experiment with.

That'd be great to test out and add some tutorials! It seems evcxr is the most promising though I haven't used it.

Re rust ndarray integration, to start with I think it should probably be done in a separate crate that would have dependencies on both ndarray and tch. I would like to only have as few dependencies as possible for now - maybe if the result is small it could be integrated though (or if tch ends up having lots of dependencies anyway).
Re being more idiomatic, that's probably a good goal. Would you have some pointers on what is not idiomatic enough yet ? I already made some change to use the failure crate but there is certainly more that can be done.
Re C++ vs Python, I think it's probably easier to convince C++ people to use Rust than Python folks but that's a minor point. The main point is that as we're binding to the C++ api, it's simpler to mimic this. That being said the two apis are not that different. Happy to know which bits of the python api you're missing the most. On tensor operations I would think that it's already decently covered, same for optimizers, torch::vision I plan to add a bit on this (although I may move it to a separate crate too).
And just to emphasize again: I think that more examples/tutorials would be a great way to show what can be done with this in rust and also give us more insights on how to structure things.
Finally a point I forgot in my previous message is writing extensions. There is a C++ tutorial on how to do this and if it's possible to do it in rust it seems like a nice selling point as it's difficult for python to compete here.

One thing that can help is making tch crate have some sub-crates through workspaces in one repository. This helps with the separation of concerns and some of your legit dependency management concerns. Potentially, we can have a core crate, torchvision crate, later ffi etc. mimicing the PyTorch.

rust ndarray integration, to start with I think it should probably be done in a separate crate that would have dependencies on both ndarray and tch.

Adding some  conversion supports should be enough like PyTorch, Numpy conversions. If you worry about dependencies, it can be behind a features at least.

being more idiomatic, that's probably a good goal. Would you have some pointers on what is not idiomatic enough yet ?

I'll send you a WIP PR soon showing exactly what I mean.

I think it's probably easier to convince C++ people to use Rust than Python folks

In broader scope, yes! I think there're folks (me included) who have already used PyTorch Python but not happy when it comes to type-safety, deployment etc. That was also mentioned by Yann LaCun's in his recent interview about programming language, type safety etc. So my point is this crate has a great potential of adoption by those folks.

And just to emphasize again: I think that more examples/tutorials would be a great way to show what can be done with this in rust and also give us more insights on how to structure things.

Absolutely! I'm 100% with you. Examples/tutorials are great, no doubt.

Finally a point I forgot in my previous message is writing extensions. There is a C++ tutorial on how to do this and if it's possible to do it in rust it seems like a nice selling point as it's difficult for python to compete here.

Sure! that'd be great. I have some idea, though need to test their feasibility first, as it can lead to some new-ish territories.

@LaurentMazare I'm now better familiar with the code base, so just updated the proposed list above. Sorry, if I wasn't specific enough. I started with little stuff to familiarize myself in the meantime.
Please let me know if these're helpful and whether you want me to continue on this.

@ehsanmok Thanks for all your work on this. Overall I feel that it's a bit early days to have that much of a detailed roadmap. I think I need one or two more weeks playing with the library and porting examples to understand better the proper use cases/abstractions.

Closing this as things have diverged substantially since this list was created. I think a lot of the list made it and it's pretty usable right now and up to date with PyTorch v1.1.0 so I'll craft a 0.1 release soonish.

Does tsh-rs support rayon (aka multi-threading) i.e for getting the probability of an image like in the sample from a pre-trained net?
For example can this code (ripped part from the Readme) can run from many threads or does it need a Mutex to wrap the access to resnet?
// Apply the forward pass of the model to get the logits and convert them
// to probabilities via a softmax.
let output = resnet18
.forward_t(&image.unsqueeze(0), /train=/ false)
.softmax(-1);
// Finally print the top 5 categories and their associated probabilities.
for (probability, class) in imagenet::top(&output, 5).iter() {
println!("{:50} {:5.2}%", class, 100.0 * probability)
}
Thanks,
-- Jon.

Going to answer my self here that the answer is no because Tensor is !Sync
https://docs.rs/tch/0.0.8/tch/struct.Tensor.html#synthetic-implementations
Is there any reason not to make it Sync?

I'm not sure there would much to be gained by applying something like rayon on top of a forward pass: the operations there would already be parallelized by the torch c++ api to use all available cores on your machine. As noted in this thread, it could actually get the other way around and harm performance.
As to why tensors are not Sync, an issue is that the aliasing model of pytorch is not properly represented in the rust type system so some storage may be shared between tensors and lead to unsound behavior. In practice this is not much of an issue, but doing more operations across thread is likely to trigger more race conditions (though probably having Send is already an issue here).

I see, thank you for the fast reply :) (I'm new to the ML stuff) I was wondering considering the thread you linked.
If I have a per-trained model for image classifications, then there is no need for me to parallel the work per-image (I have thousands of images i want to classify), instead the parallelism will happen during the classification phase (working with the pre-trained model) did I understand things correct?

I think that's right, all the operations done by your model (matrix multiplications, convolutions, etc) will run in parallel already using all the cores of your CPU (or potentially the execution units of your GPU), and you can also process a large number of images in the same batch to ensure that the overhead of going from an image to the other is not too large.

Thanks! I will give it a try


Add LightOJ as a profile site

Submission retrieval is a bit tedious as it requires logging in as a user which makes a lot of extra requests https://gist.github.com/raj454raj/4cefbc2a58b6a1a26477f284952672a8 .
But even after this, only a list of last 50 submissions can be obtained and hence all the submissions cannot be obtained.


Adds favicon

Proposing favicon image and edited html to include favicon in head so that we can have a hamburger favicon


The latest columns doesnt match the video published

what will be the total price per a day or date range would be from detailed usage report?
((Consumed Quantity) * (ResourceRate)) + (ExtendedCost)
or
just (ExtendedCost)

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

ID: 96771ba5-ef91-ed15-33a3-ff5e5b9e753f
Version Independent ID: de9baa15-55e1-4cb8-32d0-6583a8b5d689
Content: Understand your Azure detailed usage
Content Source: articles/billing/billing-understand-your-usage.md
Service: billing
GitHub Login: @tonguyen10
Microsoft Alias: tonguyen

@alherz can you please follow up on this?

@cwatson-cat unable to resolve @alherz in GitHub or MS GAL. Can you msg me @alherz's alias offline so I can ping him to take action on this pls?


Resume game after leaving page

If you accidentally hit the browser back button or close your browser, and you are the one tallying the game, there is no way to go back and resume a game, or cancel the game.  It just gets stuck, and the only recourse is to delete the game.

Think this is a duplicate of #286 right?

Yes, @aro's comment in #286 would solve this issue as well, so I'll close.


Added support to install istio-v1.5 and delete using istio-demo-auth

This commit is due to revert done in
https://github.com/layer5io/meshery-istio/pull/62
This commit also resolves all CI error messages, including static and
runtime error checks
Signed-off-by: Naveen Jain<EMAIL_ADDRESS>

All tests passed!

Got it Sir @leecalcote

Got it Sir @leecalcote

Thank you, @ashiscs!


RESULT_CANT_CONNECT when using HTTPRequest on localhost

Godot version:
Godot_v3.2.2-stable_x11.64
OS/device including version:
Linux 64bits (Pop!_OS 20.10)
Issue description:
It seem localhost pseudo-domain is not correctly resolved by HTTPRequest node, ending up in a RESULT_CANT_CONNECT error. Using <IP_ADDRESS> instead works fine.
Steps to reproduce:
Considering a http server is running on localhost:8000 (typically using python3 -m http.server)
static func download(url: String):
	var root = Engine.get_main_loop().root
	var http_request = HTTPRequest.new()
	root.add_child(http_request)

	var error = http_request.request(url)
	if error != OK:
		return "Cannot initiate HTTP request %s (error %s)" % [
			url,
			error
		]

	var vars = yield(http_request, "request_completed")
	var http_result = vars[0]
	var status_code = vars[1]
	var body = vars[3]

	if http_result == HTTPRequest.RESULT_CANT_CONNECT:
		return "Cannot reach %s (error RESULT_CANT_CONNECT)" % url
	elif http_result == HTTPRequest.RESULT_CANT_RESOLVE:
		return "Cannot reach %s (error RESULT_CANT_RESOLVE)" % url
	elif http_result != OK:
		return "Bad response from %s (error %s)" % [url, http_result]
	elif status_code != 200:
		return "Bad response from %s (status code: %s)\n%s" % [
			url,
			error,
			body.get_string_from_utf8()
		]
	return "Request succeeded !"

static func main_test():
	# var res = yield(download("http://<IP_ADDRESS>:8000"), "completed")  # Works as expected
	var res = yield(download("http://localhost:8000"), "completed")  # Ends up with RESULT_CANT_RESOLVE error :-(
	print("Result: ", res)

@touilleMan your OS is configured to prefer an IPv6 address when resolving localhost, so Godot connects to [::1]:PORT, instead of <IP_ADDRESS>:PORT. By default though, python only listen to <IP_ADDRESS> (IPv4).
Run python3 -m http.server --bind :: to bind to the IPv6 address.

@touilleMan your OS is configured to prefer an IPv6 address when resolving localhost, so Godot connects to [::1]:PORT, instead of <IP_ADDRESS>:PORT. By default though, python only listen to <IP_ADDRESS> (IPv4).
Run python3 -m http.server --bind :: to bind to the IPv6 address.

The solution, would be Happy eyeballs, see https://github.com/godotengine/godot/issues/36418#issuecomment-589963787

The solution, would be Happy eyeballs, see https://github.com/godotengine/godot/issues/36418#issuecomment-589963787

@Faless thanks for the quick answer ;-)

@Faless thanks for the quick answer ;-)


How to use the codeceptjs APIs in docker

What are you trying to achieve?
I am trying to deploy my codeceptjs tests on docker
What do you get instead?
I cannot run the tests as one of my plugins cannot be loaded as it tries to use the codeceptjs APIs and it cannot include them when running within docker.

Provide test source code if related

At the beginning of my plugin I indicate:
const Container = require('codeceptjs').container;

When I run the tests with the docker container I get the following error:
Could not load plugin foreachAsync from module '/tests/src/plugins/bzlUtils':

I can fix this by replacing the line with:
const Container = require('/codecept/container');
But this means that it will break the tests when I run them locally!
I would like a solution that works both locally and with docker.
Details

CodeceptJS version: 2.6.2
NodeJS Version: 10.19.0
Operating System: Ubuntu 18.04
puppeteer || webdriverio || protractor || testcafe version (if related) None
Configuration file:

exports.config = {
  tests: '../tests/api/*_test.js',
  output: '../output',
  helpers: {
  },
  include: {
    I: '../src/steps_file.js',
  },
  bootstrap: null,
  "mocha": {
    "reporterOptions": {
        "mochaFile": "output/result.xml"
    }
  },
  name: 'test',
  plugins: {
    retryFailedStep: {
      enabled: true
    },
    screenshotOnFail: {
      enabled: true
    },
    foreachAsync: {
      enabled: true,
      require: '../src/plugins/bzlUtils'
    }
  }
}

@lepadellec how is your dockerfile looking like?

Here it is:
FROM codeception/codeceptjs
ENV NODE_PATH=/codecept/node_modules
RUN runuser -l pptruser -c 'npm install --loglevel=warn --prefix /codecept jstoxml'
RUN runuser -l pptruser -c 'npm install --loglevel=warn --prefix /codecept mocha-jenkins-reporter'
RUN runuser -l pptruser -c 'npm install --loglevel=warn --prefix /codecept promise-fs'
RUN runuser -l pptruser -c 'npm install --loglevel=warn --prefix /codecept request-promise'
CMD ["bash", "/codecept/docker/run.sh"]

I think the docker image is probably meant for very isolated, basic tests.
In your case i would just overwrite the default CMD instruction.   You might not need all those extra npm installs either, then.
FROM codeception/codeceptjs

CMD ["npx", "codeceptjs", "run"]


[FEATURE] Document what untriaged label means and what typically happens during triage

Is your feature request related to a problem?
In https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md#triage-open-issues we talk about triaging issues. But what is it?
What solution would you like?
Add to https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md#triage-open-issues. I think we want to say that:

Triage is a regular thing that teams do (with an example like security - provide link - that does it in the open).
All new issues get an untriaged label.
Triage means looking at all issues that say "untriaged" are looked at. Confirmed as valid as feature requests or bugs, belonging to this repo, etc.
Untriaged label removed.
Doesn't mean anyone will ever promise to work on this issue.

@minalsha Are you still working on this? If not, I can make a PR for it.

@joshuarrrr  yes i am on it. Thanks.

In case it's useful, here's how we've expanded the above to be more of a checklist for the Dashboards team. @dblock I've also tried to summarize how I understand the current intent, so please let me know if I've misrepresented or misunderstood anything.
Purpose - The untriaged label and the triage process is a mechanism to ensure community issues are read and assessed by at least one person who is a member of https://github.com/orgs/opensearch-project/teams/triage. At the OpenSearch project level, we also collect metrics using that label across all repositories to measure an improve our responsiveness to community requests.
Checklist

Is this the correct repo for this issue? If not, transfer or request request transfer by tagging @opensearch-project/transfer-request. Leave the untriaged label in place when transfering and add a comment explaining why.
What type of issue is it?
bug
1. Is there enough info to verify or reproduce? Can you reproduce? In either case, add a comment about your assessment. If not, mention the requester and add the needs more info label.
2. Is the bug label appropriate, or would enhancement be more accurate?
3. Search for other similar issues and link as appropriate
4. Add other more specific labels (feature, type of bug, etc.)
enhancement
1. Is the undelying need clearly defined so it can be  prioritized and implemented? If not, mention the requester and add the needs more info label. Add clarifications as necessary in a comment.
2. Search for other similar issues and link as appropriate
3. Add other more specific labels (feature, type of bug, etc.)
If it's not a valid feature request or bug, explain why in a comment and close. Otherwise, make sure there's at least one comment that explains how you triaged it, and remove the untriaged label. (If the issue is actionable and clear, consider adding help wanted or good first issue as appropriate.

FAQ
Should maintainer/regular contributor-created issues be labeled untriaged Generally, no. Only if you're opening an issue in an unfamiliar repo.
Does triaging an issue commit us to working on or prioritizing it? No - it just means that it's a valid issue for this repository.
What if the issue requires visibility from other people (devs, maintainers, product, ux) Different teams will have different processes, but use a label other than untriaged. The Dashboards team is experimenting with the discuss label for his purpose.

I like this. Let's turn it into something org-wide @joshuarrrr?
Couple of thoughts:

The triage team is an internal team that lets org members move issues around. I think we should say "maintainers" and not mention that this team exists in a public document. If GitHub allowed a level of permissions for all org members or all maintainers to transfer issues, we'd get rid of it.
I'd add is asking triage folks to attempt some level of gentle nudging for the next step that the contributor can make themselves, since this is open-source. For example, for a bug I often ask whether the contributor would like to write a unit test that reproduces the issue. If I spot that some data may be missing (e.g. product version), I ask for more data. If the bug was reproduced on an older version, I'd ask to try on a newer one.
For a public doc "we" is "maintainers of the project". I would consider saying what we do rather than what we don't do. For example the maintainer doesn't need to confirm that "this is a bug", but just that "this looks like a bug".

@dblock do you think saying maintainers is too widely scoped? Anyone belonging to the OpenSearch-Project could be a potential for triaging issues no?


[DOCUMENTATION] Fix errors in code examples in tutorial section of documentation

Is your documentation request related to a problem? Please describe.
I found this library interesting and was going through the library code examples where I found a code error in the plotting of interval widths for the section "Estimating the uncertainty with different sklearn-compatible regressors". It uses a variable y_preds which is not defined earlier anywhere in the code. Besides, a few import statements are missing from sklearn methods, I have made the changes. Should I send a PR for the same?
Describe the solution you'd like
The incorrect line of code can be fixed by using y_pis instead of undefined y_preds and using the correct dimensions for the data. The import statements for the missing sklearn methods can be added as well.

Hi Adirtha, thanks for spotting these errors in the documentation ! Feel free to submit a PR fixing these to the master branch with myself or gmartinon as a reviewer.
Thanks !

Thank Vianney, I have added a PR for the issue.  Have mentioned you in the comments.
Thanks!


Categories get rearranged when selected/unselected

Since categories seems to be always ordered by selected -> unselected, when a category is clicked, it jumps into other position.

In other applications of similar interface tags use to stay in place so the current behaviour might be confusing for users.

fixed.


Make HTTP a hidden implementation detail, don't expose it in the public API

Right now, tower-grpc exposes to its users that it uses HTTP in a bunch of places. An example is the tower_grpc::Error::Grpc enum variant, which exposes the http::HeaderMap type from hyperium/http. Another example is the tower_grpc::Response type, which has into_http and from_http methods to convert to and from http::Response values.
I think the tower-grpc API should be changed so that no HTTP specific types are visible to its users. There are both philosophical, practical and experience based reasons for this:
Reasons
Philosophical argument
gRPC is designed as a protocol that is agnostic to its underlying transport. The gRPC over HTTP2 specification document begins with "This document serves as a detailed description for an implementation of gRPC carried over HTTP2 framing."
It can be argued that it's unlikely that users of tower-grpc are going to ever want any other underlying transport, but we don't really know that. In addition, and this is perhaps the stronger reason, gRPC is a useful and easy to reason about subset of HTTP2, which on its own is very complex. By exposing raw HTTP2 constructs to users of tower-grpc, users are unnecessarily exposed to complexities of HTTP2, for little to no benefit.
Practical argument
The direct exposure of HTTP primitives, at least without helpers which don't exist today, makes it difficult or impossible to properly implement some of the gRPC language interop tests.
special_status_message is about sending an error response with Unicode text, which gRPC over HTTP2 requires to be percent encoded. With tower-grpc's current design, this percent encoding has to be done by end user code, which is very error prone and not necessary. All other gRPC libraries handle this automatically. Even without the complication of the percent encoding, requiring the user to know that you should check the "grpc-message" HTTP header to get the error message is a very unintuitive API.
Similarly, for the custom_metadata interop test, the user of the API has to manually do base64 encoding and decoding of custom metadata fields with a "-bin" suffix, which gRPC over HTTP2 requires that the gRPC library does for the user. In addition, tower-grpc does currently not support trailing custom metadata at all because the tower_grpc::Response is just a wrapper around http::Response, which happens to not store trailers (the http library seems to make it possible to read them it's just not stored in that struct).
Placing the burden of percent encoding error messages, base64 encoding some headers, and even just requiring the knowledge that gRPC custom metadata is sent over headers, and what the header name for error messages is, is just not nice. I would even argue that, at least without helper functions, it violates the spec.
Experience based argument
To my knowledge, every widely used gRPC library in existence completely hides HTTP from their users. Custom metadata is transferred with headers but exposed under the name "custom metadata", etc. Also, the data type for storing an error response (the equivalent of tower_grpc::Error) stores only the status code, the error message and the binary error details, not arbitrary HTTP header data. See for example the C++ API: grpc::Status
Because all of the widely used gRPC libraries get away with not exposing low level HTTP2 details to their users, I think it's highly likely that the same will be true for tower-grpc. In fact, just being more similar to the other gRPC libraries is on its own a good reason for this because of the reduced learning curve. (There are ways that tower-grpc is different from other gRPC libraries because it's in Rust, but I don't think this is one of those.)
Proposed changes

Simplify tower_grpc::Error to only store the information that other gRPC libaries store. Don't store HTTP stuff, and don't store prost object or anything else. gRPC specifies how to map HTTP errors and other kinds of errors into this format. Although not strongly typed the gRPC Status type is powerful enough to encode any kind of error. As discussed in #6, doing this would make the API more friendly to use as well because at the moment a server side error is not the same type as a client side error, which causes pain when servers need to propagate errors.

Similarly, hide HTTP types from the tower_grpc::Request and tower_grpc::Response types. Only expose fields in terms of gRPC. This would make the API more similar to the other gRPC implementations, make it easier to understand because users won't have to know the details of the gRPC/HTTP2 mapping, and make it possible to make a more friendly API for custom metadata.

Ping @carllerche, tower-grpc maintainer, and @jtattermusch, creator of the C# gRPC, who might be able to provide insight and/or say I'm wrong.

We should survey what other libs (Go, C++, C#, ...) do in this case. If none of the primary libs provide access to the HTTP types, then it seems fine to encapsulate.
That said, the decision to encapsulate HTTP is separate from providing an API for metadata. We should wrap the HeaderMap with a MetadataMap and provide metadata read / write APIs.
Thoughts?

Encapsulating HeaderMap in a MetadataMap sounds like a reasonable first step. For that we can provide means to convert to/from a HeaderMap.
For tower_grpc::Response it may not make sense to store both the current http::Response and a MetadataMap because then those two objects can have conflicting values for headers. So there it's probably better to break it down and store a MetadataMap and whatever http::Response contains except headers.

tower_grpc::Response does not need to contain the http::Response, it can stick to what it needs.

Did some research on other gRPC libraries:
For grpc-core (C/C++) I'm quite sure that no underlying HTTP types are exposed. I have used it myself and know that API fairly well. For the other ones I read the API docs and could not find any explicit exposure of HTTP except for when servers and clients are fist instantiated. Java specifically can be used with either Netty, okhttp or an in-memory backend so it really can't expose the underlying HTTP library to the user since there isn't a single one. Go has some methods with "Header" in their names but the docs describe them as means of getting custom metadata, not HTTP headers directly.
Details:
Go gRPC:
Server side: Handlers get context.Context and the protobuf object.
Client side: Calls take a context.Context and the protobuf object and are methods on objects of generated types.
The Context has:

https://godoc.org/context#Context
Deadline
Cancellation detection
Untyped “Value” map which contains metadata but also potentially other things. I can’t find any reference to HTTP specific things here but it’s hard to track what this actually has just from docs.

The API docs for Go gRPC https://godoc.org/google.golang.org/grpc does not mention HTTP2 except for:

an experimental method that allows serving gRPC from a Go standard library HTTP server object,
Two methods that allow injecting “Codec”s, for example a JSON parser for parsing when content-type is application/grpc+json. HTTP is mentioned in the docs because it’s connected to the content-type header.

C# gRPC API docs are at https://grpc.io/grpc/csharp/api/Grpc.Core.html
Server side: Handler methods get the protobuf object and a ServerCallContext
Client side: Calls take the protobuf object and are methods on objects of generated “Client” types.
ServerCallContext https://grpc.io/grpc/csharp/api/Grpc.Core.ServerCallContext.html has:

gRPC stuff
RequestHeaders, described as "Initial metadata sent by client.”
ResponseTrailers, described as “Trailers to send back to client after RPC finishes.”
There are hints for how to do buffering when streaming https://grpc.io/grpc/csharp/api/Grpc.Core.WriteFlags.html

So there are HTTP related things but I cannot find any direct HTTP references in the docs there.
Java gRPC docs are at https://grpc.io/grpc-java/javadoc/
Server side: Handlers get the request proto message and an object to reply with.
Client side: Calls take the protobuf object and are methods on objects of generated “Client” types.
gRPC Java has multiple transports implemented: The main Netty based one, an Android client-only implementation based on okhttp and io.grpc.inprocess which is notable because it doesn’t use HTTP.

The Java gRPC library does not expose any Netty or okhttp primitives to the user of the library.

Ok, I would be fine hiding HeaderMap in favor of a MetadataMap.
To avoid having to dup the map, I would have:
struct MetadataMap {
    headers: http::HeaderMap,
}

Then do the metadata conversion on the fly.

Wow, thanks for the in-depth report, awesome! I also think it's fine to start to hide the HTTPness here. An alternative (which I'm not saying is better, just that we should consider) to having a MetadataMap is to just have setters and getters on the Request and Response types themselves.

@seanmonstar it seems like it would be useful to be able to pass the metadata map around, if it is on Request / Response then fns that take it would need to be generic over the body?

I see now that the HeaderMap interface is pretty big. It takes quite a bit of wrapping to wrap all the things, including the iters and all other little details.
I agree with @carllerche in that I think there is merit in being able to pass around a MetadataMap without also passing around the Request/Response.
I've started working on an implementation based on
struct MetadataMap {
    headers: http::HeaderMap,
}

It looks like the variants are:

Header name: ASCII value
Header name + -bin: base64 encoded value.

A possible API: have Ascii and Binary types, kinda like HeaderValue, and set_ascii(name, ascii) and set_bin(name, binary).

@seanmonstar Fyi non-"-bin" fields can have non-ASCII too. The gRPC language interop test suite tests support for sending UTF-8 there, and HeaderValue in the http library allows more than ASCII. It also allows less than ASCII because e.g. newlines are disallowed. gRPC docs ambiguously call these values "string" metadata values.
Here is a potential approach for handling "-bin" fields: MetadataMap would have two sets of accessor methods: One that operates on MetadataStringValues (behaves like HeaderValue) and one that operates on MetadataBinaryValues (allows arbitrary byte strings). Because of covariance/contravariance you would get a quirky interface where you can't always read your writes:

Operation
Methods that return MetadataStringValue
Methods that return MetadataBinaryValue

Read
Ignores or does not allow "-bin" keys
Allows all keys

Write
Allows all keys
Does not allow non-"-bin" keys

Enumerate
Ignores "-bin" keys
Allows all keys

Another option is to have two separate sets of accessor methods with zero overlap. Then, to enumerate all metadata the user needs to enumerate string and binary entries separately. A variant of this option is to also have separate MetadataStringKey and MetadataBinaryKey types that can only be constructed with the right "-bin" suffix (or lack of it). Then the key names can be constructed once and individual metadata accesses don't need to handle name errors.
A third option which is more similar to what other gRPC libs to but that maybe feels un-Rusty is to just ditch type safety and allow all entries to contain binary data and then fail when converting it to a HTTP HeaderMap object.
@seanmonstar @carllerche do you have a preference for what to do here? To me it seems like the second option of segregating the map into effectively two separate parts is a nice way to go because that is probably how people will use it in practice anyway.

@per-gron I am kind of leaning towards just doing runtime checks. Something like:
pub struct MetadataValue {
    is_bin: bool,
    data: HeaderValue,
}

Then have separate constructors:
impl MetadataValue {
    fn string(s: &str) -> MetadataValue { }

    fn bytes(s: &[u8]) -> MetadataValue { }

    fn as_str(&self) -> Option<&str> { }
}

Some questions:
If string values support UTF-8 values, how are they encoded in headers? Perhaps the binary repr is a valid header value?
Can there be both a string and -bin entry for the same name? For example, can the metadata map contain both "foo" and "foo-bin" keys?

string metadata values support all characters that HTTP headers can have, which I think is something like bytes >32 and != 127. gRPC doesn't encode them, they are just raw HTTP headers.
As far as I can tell, nothing prevents having "foo" and "foo-bin". Other gRPC libraries require users to explicitly call the metadata keys "-bin" or non-"-bin".

Hi there, I'm the maintainer of gRPC C# and contributor for other gRPC languages. I just wanted to confirm what @per-gron is saying:

gRPC "metadata" should be agnostic of the protocol and therefore http2 header / trailer types should not be exposed directly to the user. AFAIK all gRPC languages behave that way (C# definitely doesn't expose any HTTP-related types, it uses its own Metadata and Metadata.Entry types, that resemble HTTP2 headers and trailers, but are completely separate types otherwise).
There is some additional functionality for gRPC initial and trailing metadata (such as the binary vs non-binary metadata rules mentioned earlier, upcasing and downcasing logic etc.), which also will be easier to implement with types that are independent from rust http2 library.

to summarize:

there are "initial metadata" for requests, and "initial metadata" and "trailing metadata" for responses. they are basically multi-maps (single "header" can have multiple values, which is the same as in http2). they either support "text values" or "binary values" (based on the name suffix). all of this is necessary to be able to pass our interoperability test suite.

btw, if there's a draft for the tower-grpc public API, gRPC team can help reviewing it.

@jtattermusch Thanks for the thoughts, that makes sense.
As per an API draft, tower-grpc's API is experimental. At some point (soon hopefully), the API will be nailed down a bit more. I will ping you at that point 👍

Phew, the metadata map interface turned out to be a lot bigger than I expected.
I uploaded the PR https://github.com/hyperium/http/pull/278 against hyperium http to be able to fully wrap it.
I also uploaded #92 as a large step towards hiding HTTP types from Tower's public interface. This is an important step towards being able to handle binary metadata fields properly, although it's just a refactoring so far.

@jtattermusch can you provide links to docs or something about gRPC specific upcasing/downcasing rules? I can't find much about it. tower-grpc currently uses hyperium http's header handling which is very careful about http2 conformance, including case sensitivity.

@per-gron  per the gRPC spec, all metadata keys need to be lower-case only: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md    (see "Header-Name"). There rest of the behavior comes from http2 spec:  see summary here: https://blog.yaakov.online/http-2-header-casing/    (all header names must be converted to lower cases before sent on the wire)

@jtattermusch thanks for the info! Hyperium already enforces that all header names are lower case, so I think we're good on that point.

@carllerche Working on making MetadataMap actually automatically encode binary entries. At the moment I'm hacking on a type system based approach rather than your suggested runtime check approach, because 1) with the unsafe transmutes I am not able to store that additional flag with MetadataValue, 2) it seems tricky to enforce the invariants at all times if users start taking MetadataValues from Ascii fields and placing them in entries with -bin keys and vice versa.

@carllerche I don't know if string or binary values are more common. My guess is that string values are more common and binary only used when you need to store richer data, in practice protobuf messages.
I have a wip branch at https://github.com/per-gron/tower-grpc/blob/request-metadata-bin/src/metadata_map.rs in case you want to see the gory details but perhaps that can wait until you actually review that upcoming PR. Quick summary of the approach is:
Have a trait ValueEncoding with two implementations: Ascii and Binary. Those don't really do much on their own but are used with PhantomData in keys and values, so a key will be either MetadataKey<Ascii> or MetadataKey<Binary>, and there is also MetadataValue<Ascii> and MetadataValue<Binary>. The end goal with those is to make it so that all binary metadata values that the user of MetadataMap can get access to are of type MetadataValue<Binary> and the accessor methods on that type will do base64 decoding when it's read and encoding when it's written (so actual in-memory storage of binary entries will be base64 encoded).
To get this, you have get, get_all etc methods on MetadataMap for ascii values and separate get_bin, get_all_bin etc for binary values. get_bin doesn't work for ascii values and vice versa.
There's a lot of details in the implementation of this approach that I'm a bit unsure about. For example, I don't really like that HeaderMap and consequently MetadataMap are a bit panic-prone when you pass strings to insert and append. Also, instead of having MetadataKey<Ascii> vs MetadataKey<Binary> there could be only one type for both, but with more runtime checks instead.

@per-gron Thanks for the summary. I will have to spend some time thinking about the problem before being able to provide additional thoughts...
Regarding HeaderMap panicking, here should definitely be variants for everything on HeaderMap that do not panic.

@seanmonstar I think all the changes proposed in this ticket are done by now. Please reopen if I'm missing something.


⚠ kibana has degraded performance

In f020393, kibana (kibana.daotrunghieu.com) experienced degraded performance:

HTTP code: 200
Response time: 3366 ms

Resolved: kibana performance has improved in 909f8c1.


Update brew-cask.1

The quotes we have are correct.
You should never edit this file directly. It should be generated after editing the markdown version. Please correct that one instead.

Running man brew-cask via the terminal, the quotes appear as ahelpera?

Running man brew-cask via the terminal, the quotes appear as ahelpera?

Ah, you’re right. Still, quotes should be something like "helper" and the fixed file should still be the markdown one.

OK, but how should the quotes be written so that they appear correct in Terminal?

"helper".


feat: allow optional usage of input validation

Description
TRPC has optional input validation and this should be reflected in this generator. This PR simply is an "all or nothing" approach to this as it will apply to all models. In the future this may be possible to toggle per model and action.
References

https://trpc.io/docs/procedures#example-without-input-validation
fixes #70

Hey @arnm
Thanks for the PR!
A few notes before merging:
1- Make sure to disable schemas imports generation inside routers.
2- Would be great to document this new option throughout the README.
3- Can you remove the empty line left after disabling input validation? You can see it in every router operations

Thanks @omar-dulaimi 👍


Resolution of macro derive behavior has been modified on 1.30

Setup
Versions

Rust: 1.30.0-nightly (721913067 2018-08-26)
Diesel: 1.3.2

Problem Description
In the past, the proc_macro! expansion could refer to items, without importing them explicitly again in the source file using this macro.
This behavior is being phasing out and triggers warnings at build time.
See https://github.com/rust-lang/rust/issues/50504
And more explicitly https://github.com/rust-lang/rust/issues/50504#issuecomment-389734217
Steps to reproduce

Switch to an up to date nightly toolchain
Generate a schema through diesel migration run
Build anything using a models.rs with #[derive(Queryable,Debug)].

Output
For table!
warning: cannot find type `table` in this scope
   --> <table_body macros>:165:33
    |
165 | derive ( Debug , Clone , Copy , QueryId ) ] /// The actual table struct
    |                                 ^^^^^^^ names from parent modules are not accessible without an explicit import

For the models
  --> src/models.rs:14:10
   |
14 | #[derive(Queryable,Debug)]
   |          ^^^^^^^^^ names from parent modules are not accessible without an explicit import
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>

Workaround
Invoke cargo or rustc with the RUSTFLAGS="-Aproc-macro-derive-resolution-fallback" environment variable.
For example, RUSTFLAGS="-Aproc-macro-derive-resolution-fallback" cargo check
You can also create a .cargo/config file at project level with the relevant flag:
[build]
#rustflags = ["-Aproc-macro-derive-resolution-fallback"]

Checklist

[ ] This issue can be reproduced on Rust's stable channel. (Your issue will be
closed if this is not the case)

It can't, as it's an upcoming behavior, but perhaps it's pertinent to track it, as it's mature code ready to land to stable at 1.30 release date (currently Oct 25 2018), and to document a workaround.
If not, we can probably close it and reopen at 1.30 release.

This has been fixed by hahttps://github.com/diesel-rs/diesel/pull/1787


[Decorator] Response formatting

@ResponseSet(headers) let you to configure response header from annotation.
@Controller("/calendars")
export class CalendarCtrl {

    @Get("/:id")
    @ResponseSet({"Content-Type": "application/json", status: 200})
    public get(): ICalendar {

        return <ICalendar> {id: request.params.id, name: "test"};
    }
// or
    @Get("/:id")
    @ResponseSet("Content-Type",  "application/json")
    @ResponseSet("status",  200)
    public get(): ICalendar {

        return <ICalendar> {id: request.params.id, name: "test"};
    }
}

Annotation's name is a proposal. If you have a better idea of name, tell-it !

Name proposal :)
Why not name it simply @Headers({ "Content-Type": "application/json", "X-Foo": "Bar" }) or @ResponseHeaders()

ResponseSet just because I use response.set method :)
But ResponseHeaders is fine.
Headers is too confusing between headers sent with the request and the headers sent on the response.

#30


Updated description for startup with docker compose

Missing piece of information when not starting from cloned repository.

Is this common practice to run outside of a repo though? I'd like to keep the README as simple as possible without covering all the possible edge cases.

I thought that this is your intention. Yes it is. Normally if you run a docker container you don't have dependencies to the repro the docker container is orginating from.
@hugomd we could copie the file into the docker of umami and make a shared bind between the two docker containers? Or we could add a page to the documentation? And Like the page in the readme? Because simply running the docker-compose is only right if you check out the repro which shouldn't be necessary for running stuff on docker.
@mikecao should we move this into your documentation like you did for hosting on different plattforms?

@MonksterFX Yes we should have a section in the docs specifically for running Docker and all the various ways to do it. I want to keep the README as barebones as possible.


Explore: Sorting broken

https://github.com/mlcraft-io/client-v2/assets/2017148/a60457cf-0cf5-4916-b1fa-9ace346867fb
User should be able to select multiple order by, "run query" should not run automatically, Please check mlcraft client

closed by #116


refactor(resourcemanager): invokeValidateResourceType only in debug mode

It's considered a smell when invoking virtual methods in constructor (see: https://www.codeproject.com/tips/641610/be-careful-with-virtual-method)
In TrackedResource constructor, virtual method ValidateResourceType is invoked. Although after analysis we think it's OK, we still decided to invoke it in debug mode only, for dev/test purpose. This commit will apply conditional compilation, so that ValidateResourceType will be excluded in release build.

remove general warning suppress in csproj
add conditional compilation and warning suppress for ValidateResourceType inside constructor

resolve https://github.com/azure/autorest.csharp/issues/1627
All SDK Contribution checklist:
This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] Please open PR in Draft mode if it is:

Work in progress or not intended to be merged.
Encountering multiple pipeline failures and working on fixes.

[ ] If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
[ ] I have read the contribution guidelines.
[ ] The pull request does not introduce breaking changes.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

SDK Generation Guidelines

[ ] The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code. (Track 2 only)
[ ] The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK. Please double check nuget.org current release version.

Additional management plane SDK specific contribution checklist:
Note: Only applies to Microsoft.Azure.Management.[RP] or Azure.ResourceManager.[RP]

[ ] Include updated management metadata.
[ ] Update AzureRP.props to add/remove version info to maintain up to date API versions.

Management plane SDK Troubleshooting

If this is very first SDK for a services and you are adding new service folders directly under /SDK, please add new service label and/or contact assigned reviewer.

If the check fails at the Verify Code Generation step, please ensure:

Do not modify any code in generated folders.
Do not selectively include/remove generated files in the PR.
Do use generate.ps1/cmd to generate this PR instead of calling autorest directly.
Please pay attention to the @microsoft.csharp version output after running generate.ps1. If it is lower than current released version (2.3.82), please run it again as it should pull down the latest version.

Note: We have recently updated the PSH module called by generate.ps1 to emit additional data. This would help reduce/eliminate the Code Verification check error. Please run following command:
  `dotnet msbuild eng/mgmt.proj /t:Util /p:UtilityName=InstallPsModules`

Old outstanding PR cleanup
Please note:
If PRs (including draft) has been out for more than 60 days and there are no responses from our query or followups, they will be closed to maintain a concise list for our reviewers.

Pipeline failure in resourcemanager can be fixed by https://github.com/Azure/azure-sdk-for-net/pull/26204
Another failure is due to test time out.
Failed BlobContainerSoftDelete [10 s]
  Error Message:
   Test exceeded global time limit of 10 seconds. Duration: 00:00:10.3285918

add a fix to trim the storage test recording


Fixes #209: CLI option for number of CPUs when creating a new boot2docker VM

This pull request enhances boot2docker init by allowing user to pass --cpus to configure the number of cpus allocated to boot2docker-vm during vm creation.

@SvenDowideit @steeve If this looks good, can we please merge this one ? Also, I would recommend have a similar feature in docker-compose.

Okay, I have addressed your comments.

LGTM
cc @gmlewis @Moghedrin


Give fair warning upfront that this C# is Windows 64-bit only. Or (better) support 32-bit.

Environment data
dotnet --info output:
VS Code version:
C# Extension version:all
Steps to reproduce:
Take on what turns out to be the very difficult challenge of teaching MVC6 and ASP.NET Core to my PolyTech programming class. Spend many hours setting up a virtual machine running Windows 10 32-bit with Visual Studio Code and resources for many good reasons coming from the special challenges of this teaching and learning environment including many many installation failures on student laptops. Get many errors. Click an obscure blue OmniSharp error message in the bottom right hand corner of VS Code. Display happens to mention X64 in an installation error message. Be like a Sherlock Holmes detective and follow the trail to this github site and discover - well scrolled down and therefore obscure - the sad sad information that support for Windows is 64-bit only.
Expected  behavior:
Preferably support 32-bit. Because everything else in this ASP.NET Core ecosystem supports 32-bit. Wide support of OSs is a stated Core aim so this exception comes as a less than obvious surprise.
ALTERNATIVE expected behaviour:  Warn us about 64-bit only - UPFRONT - as in visible when this item appears in the Extensions panel of VS Code. Further suggestion is better indication of error when installing into 32-bit Windows.
Actual behavior:
dotnet run of the "Blogging" example app aka "EFGetStarted.AspNetCore.ExistingDB" results in bright red text giving 608 errors "error NU1001: The dependency ... could not be resolved". See attached screen shots.

I just wanted to let you know that the latest release of the C# extension (1.5.2) supports 32-bit Windows for IntelliSense, go to definition, find all references, and other editor features. The debugger still does not support 32-bit Windows, and that is being tracked with https://github.com/OmniSharp/omnisharp-vscode/issues/844.


Edit data deletes line breaks when saving text

SQL Operations Studio Version: master 55e3947

Steps to Reproduce:

Set up a text cell that contains a line break, e.g. with the following query

update dbo.t1 set content='line
break' where id=1

Open the table in edit data
Edit the cell to change some of its text (but not the newline) and commit the change

Expected behavior: The line break stays as part of the value since it wasn't part of what was changed
Actual behavior: The line break disappears
SSMS's edit data has the correct behavior here

+1.
This bug is more sinister than the repro steps above make it appear. On the edit view, just using the down cursor over a cell that contains line breaks is enough to trigger a save and strip all line breaks. We've had completely unrelated rows corrupted due to someone editing one row, and using the down cursor over a few more rows.

@MaddyDev have you had a chance to look at this bug yet?  It would be great to fix in May.

@kburtram Yes, I'm looking into this. I was able to find the issue but there doesn't seem to be a graceful way to handle this. Still working on it.

@MaddyDev do you have any updated on this issue?  This would be a great task to pickup during committer time.


add compression option to NdarrayCodec() to support Q10.8 encoded fie…

…lds with compression

@rgruener , do you know if there is a way to specify a native parqurt compression algorithm on a per column basis when writing out from spark?

Unfortunately that is not possible, compression is specified on the entire output.

Codecov Report

Merging #119 into master will decrease coverage by 0.09%.
The diff coverage is 66.66%.

@@            Coverage Diff            @@
##           master     #119     +/-   ##
=========================================
- Coverage   81.15%   81.05%   -0.1%
=========================================
  Files          51       51
  Lines        2674     2692     +18
  Branches      391      394      +3
=========================================
+ Hits         2170     2182     +12
- Misses        439      443      +4
- Partials       65       67      +2

Impacted Files
Coverage Δ

petastorm/codecs.py
78.35% <66.66%> (-3.93%)
:arrow_down:

petastorm/workers_pool/process_pool.py
96.29% <0%> (+0.74%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d634789...2c6a694. Read the comment docs.


test: moving the repository over to using mocha + chai for unit testing

🧰 Changes
Because the new CLI package in #398 uses Mocha with oclif Typescript does not like it when @types/jest and @types/mocha are present within the same file tree (see this stackoverflow thread) and it's becoming such a pain in the ass to write any code in the CLI project that I'm just moving this entire repository over to using Mocha + Chai so I can get on with my life.

[ ] api
[x] core
[x] httpsnippet-client-api

🧬 QA & Testing
Do all tests still pass?

moved to #402 402


DataPlug Connection with Home Assistant

Hello and thank you for your great Integration!
When I read about this a couple of months ago, I bought the "DataPlug" to make older models (2013 Audi A1) smarter. I read somewhere, that this would work with this Integration.
Unfortunately I do not understand, how to connect the Audi connect plug and play App with the MyAudi ID, from where this integration gets its data. Do you by any chance know how to make the connection so that I can see my car stats from the Audi DataPlug?
Thank you very much!

Maybe @JoLukas can assist? We seems to use it with the App properly: https://github.com/audiconnect/audi_connect_ha/issues/479