TiKV crash with "index out of bounds" (after manual SPLIT TABLE and INSERT)

Bug Report

What version of TiKV are you using?

["Welcome to TiKV"]
["Release Version:   5.0.0-rc.x"]
["Edition:           Community"]
["Git Commit Hash:   a17508c0c3a4ce62d374cf5b185b159501caa1d9"]
["Git Commit Branch: master"]
["UTC Build Time:    2021-03-08 13:25:57"]
["Rust Version:      rustc 1.51.0-nightly (1d0d76f8d 2021-01-24)"]
["Enable Features:   jemalloc mem-profiling portable sse protobuf-codec test-engines-rocksdb cloud-aws cloud-gcp"]
["Profile:           dist_release"]
["memory limit in bytes:<PHONE_NUMBER>2, cpu cores quota: 8"]

What operating system and CPU are you using?

AWS EKS. m5.2xlarge.
Steps to reproduce

create table t1 (id int unsigned not null auto_increment , x int unsigned, primary key(id, x) clustered);
split table t1 between (0,0) and (30000,0) regions 1000;

{ printf 'insert into t1 values '; printf '(1,%d),' {1..30000} | sed 's/.$/;/'; } | mysql

What did you expect?
What did happened?
At first, things looked good. select count(*) returned in a short period of time:
MySQL [test]> select count(*) from t1;
+----------+
| count(*) |
+----------+
|    30000 |
+----------+
1 row in set (0.485 sec)

After checking information_schema.tikv_region_status a couple times to see the activity in the table's regions, I could see that a single region had all the rows, as expected:
MySQL [test]> select * from information_schema.tikv_region_status where approximate_size<>0 and table_name='t1' order by written_bytes desc limit 10;
+-----------+--------------------------------------------------------------------------+--------------------------------------------------------------------------+----------+---------+------------+----------+----------+------------+----------------+---------------+---------------+--
----------+------------------+------------------+-------------------------+---------------------------+
| REGION_ID | START_KEY                                                                | END_KEY                                                                  | TABLE_ID | DB_NAME | TABLE_NAME | IS_INDEX | INDEX_ID | INDEX_NAME | EPOCH_CONF_VER | EPOCH_VERSION | WRITTEN_BYTES | READ_BYTES | APPROXIMATE_SIZE | APPROXIMATE_KEYS | REPLICATIONSTATUS_STATE | REPLICATIONSTATUS_STATEID |
+-----------+--------------------------------------------------------------------------+--------------------------------------------------------------------------+----------+---------+------------+----------+----------+------------+----------------+---------------+---------------+------------+------------------+------------------+-------------------------+---------------------------+
|     17957 |<PHONE_NUMBER>000000FF3300000000000000F8                                     |<PHONE_NUMBER>000000FF335F720400000000FF0000001E04000000FF0000000000000000F9 |       51 | test    | t1         |        0 |     NULL | NULL       |              5 |           110 |       6497853 |
  1860000 |                1 |                0 | NULL                    |                      NULL |
|     17957 |<PHONE_NUMBER>000000FF3300000000000000F8                                     |<PHONE_NUMBER>000000FF335F720400000000FF0000001E04000000FF0000000000000000F9 |       51 | test    | t1         |        1 |        1 | PRIMARY    |              5 |           110 |       6497853 |    1860000 |                1 |                0 | NULL                    |                      NULL |
|     19657 |<PHONE_NUMBER>000000FF335F720400000000FF00000FF004000000FF0000000000000000F9 |<PHONE_NUMBER>000000FF335F720400000000FF0000100E04000000FF0000000000000000F9 |       51 | test    | t1         |        0 |     NULL | NULL       |              5 |           144 |          3394 |          0 |                1 |                0 | NULL                    |                      NULL |
|     18013 |<PHONE_NUMBER>000000FF335F720400000000FF000009F604000000FF0000000000000000F9 |<PHONE_NUMBER>000000FF335F720400000000FF00000A1404000000FF0000000000000000F9 |       51 | test    | t1         |        0 |     NULL | NULL       |              5 |           144 |          3394 |          0 |                1 |                0 | NULL                    |                      NULL |
|     20813 |<PHONE_NUMBER>000000FF335F720400000000FF000013EC04000000FF0000000000000000F9 |<PHONE_NUMBER>000000FF335F720400000000FF0000140A04000000FF0000000000000000F9 |       51 | test    | t1         |        0 |     NULL | NULL       |              5 |           161 |          3394 |
        0 |                1 |                0 | NULL                    |                      NULL |
|       105 |<PHONE_NUMBER>000000FF335F720400000000FF000043BC04000000FF0000000000000000F9 |<PHONE_NUMBER>000000FF335F720400000000FF000043DA04000000FF0000000000000000F9 |       51 | test    | t1         |        0 |     NULL | NULL       |              5 |            93 |          3300 |          0 |                1 |                0 | NULL                    |                      NULL |
|     17413 |<PHONE_NUMBER>000000FF335F720400000000FF00002BD404000000FF0000000000000000F9 |<PHONE_NUMBER>000000FF335F720400000000FF00002BF204000000FF0000000000000000F9 |       51 | test    | t1         |        0 |     NULL | NULL       |              5 |           144 |          2974 |          0 |                1 |                0 | NULL                    |                      NULL |
|     13436 |<PHONE_NUMBER>000000FF335F720400000000FF0000639C04000000FF0000000000000000F9 |<PHONE_NUMBER>000000FF335F720400000000FF000063BA04000000FF0000000000000000F9 |       51 | test    | t1         |        0 |     NULL | NULL       |              5 |           174 |          2970 |
        0 |                1 |                0 | NULL                    |                      NULL |
|     14196 |<PHONE_NUMBER>000000FF335F720400000000FF00002DD204000000FF0000000000000000F9 |<PHONE_NUMBER>000000FF335F720400000000FF00002DF004000000FF0000000000000000F9 |       51 | test    | t1         |        0 |     NULL | NULL       |              5 |           110 |          2952 |          0 |                1 |                0 | NULL                    |                      NULL |
|     20881 |<PHONE_NUMBER>000000FF335F720400000000FF00001DE204000000FF0000000000000000F9 |<PHONE_NUMBER>000000FF335F720400000000FF00001E0004000000FF0000000000000000F9 |       51 | test    | t1         |        0 |     NULL | NULL       |              5 |           195 |          2782 |          0 |                1 |                0 | NULL                    |                      NULL |
+-----------+--------------------------------------------------------------------------+--------------------------------------------------------------------------+----------+---------+------------+----------+----------+------------+----------------+---------------+---------------+--
----------+------------------+------------------+-------------------------+---------------------------+
10 rows in set (0.029 sec)

select count(*) started getting really slow and eventually just returns an error:
MySQL [test]> select count(*) from t1;
+----------+
| count(*) |
+----------+
|    30000 |
+----------+
1 row in set (7.350 sec)

MySQL [test]> select count(*) from t1;
+----------+
| count(*) |
+----------+
|    30000 |
+----------+
1 row in set (35.001 sec)

MySQL [test]> select count(*) from t1;
ERROR 9005 (HY000): Region is unavailable

Meanwhile, all 3 tikv instances have crashed and cannot recover. Logs attached.

Fixed by #9769.


QueueSizeRejectionThreshold is not respected when commands are executed/queued from different threads

According to the document, QueueSizeRejectionThreshold is an artificial maximum queue size at which rejections will occur even if maxQueueSize has not been reached. But when I try to call command.queue()/execute() from multiple threads, the "queueSizeRejectionThreshold" does not seem to take effect.
Here is the code to reproduce it,
    @Test
    public void shouldThrowRejectedException()  {

        final int threadPoolCoreSize = 2;
        final boolean fallBackEnabled = false;
        final boolean circuitBreakerEnabled = false;
        final int executionTimeoutInMilliseconds = 15000;
        final int maxQueueSize = 20;

        HystrixCommand.Setter setter = HystrixCommand.Setter.withGroupKey(
        		HystrixCommandGroupKey.Factory.asKey("TEST"))
                .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
                                .withCoreSize(1)
                                .withMaxQueueSize(10)
                                .withQueueSizeRejectionThreshold(3)
                )
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                        .withExecutionTimeoutInMilliseconds(executionTimeoutInMilliseconds));

        ExecutorService tp = Executors.newFixedThreadPool(20);
        for(int i = 0; i < 10; i++) {
            HystrixCommand cmd = new HystrixCommand(setter) {
                @Override
                protected Object run() throws Exception {
					System.out.println(Thread.currentThread().getName() + " starts work " + new Date());
					Thread.sleep(5000);
					System.out.println(Thread.currentThread().getName() + " finnish work " + new Date());
					return null;
                }
            };

            tp.submit(() -> {
            	try {
            		System.out.println("start queuing");
            		cmd.queue();
            	}catch (HystrixRuntimeException ex) {
            		System.out.println(" "+ex.getMessage() + ex.getCause().getClass());
            	}
            });
        }

        try {
		Thread.sleep(60_000);
	} catch (InterruptedException e) {
		e.printStackTrace();
	}
    }

I would expect 6 commands will be rejected, but I got none rejected exception thrown.
I am using version 1.5.11.

you need add
Thread.sleep(500);
before
tp.submit()


Widgets

Problem

We don't have widgets.
We don't see all our installed packages on the home screen.
We don't have a Launch button in the appstore for launching a package that we just installed.

Solution

Add widgets.
Show installed packages on the home screen.
Add a Launch button to the appstore.

Docs Update
We don't mention in the Book that apps have to message homepage:sys in order to show up there - I'm not sure that writing a whole page about this is in-scope, especially given that we need this out ASAP.

[x] Save app favorites in localStorage instead of sessionStorage
[ ] Make widgets smaller and change labelling
[ ] Disable mouse behavior for un-UI-ful apps

A few more comments:

Let's change the Settings app to say "System Settings" and change the icon so it's not a gear (or change the widget settings gear). We can't have two gears that mean different things.
Spacing is off in this picture. It's crowded. Either we need something that adjusts for screen size (best if you can do it), or we need to develop for default mac laptop size.
New order is this: Favorited Apps, Widgets, and below a collapsible "All Installed Apps" section. Favorited apps can stay there (updated from what Ben said above).
In the App Store, all apps should have a default icon like the one on the homepage if they don't specify an image

This is very close, nice work

@jtneev @dr-frmr

[x] Appstore icons will be color dots when image is unset
[x] Components are generally smaller and look better on default screens
[x] "All apps" really does show all apps, and it expands upwards from the bottom in a drawer that is hidden by default
[x] Widget settings button in upper right, using a wrench-and-screwdriver icon instead of gear
[x] Widgets are now above "All Apps"


Only report error message if no runtime available

What happened:
vagrant@bootstrap:~$ sudo crictl images list
WARN[0000] image connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/
crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead.
ERRO[0000] unable to determine image API version: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dia
ling dial unix /var/run/dockershim.sock: connect: no such file or directory"
IMAGE                      TAG                 IMAGE ID            SIZE
docker.io/library/ubuntu   16.04               b6f5076524258       46.5MB
docker.io/library/ubuntu   18.04               ad080923604aa       26.7MB

What you expected to happen:
Only report error message if no runtime available.
How to reproduce it (as minimally and precisely as possible):
crictl with containerd
Environment:

Container runtime or hardware configuration: containerd
OS (e.g: cat /etc/os-release):

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.7 LTS
Release:        16.04
Codename:       xenial

Kernel (e.g. uname -a): Linux bootstrap 4.4.0-210-generic #242-Ubuntu SMP Fri Apr 16 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Others:

@k82cn thank you for reporting the issue, are you planning to work on a fix for it?

@k82cn thank you for reporting the issue, are you planning to work on a fix for it?

I'm ok with that :)

https://github.com/kubernetes-sigs/cri-tools/issues/893

/remove-lifecycle rotten


streaming audio transcription with kaldi

Hello,
I recently tested if SEPIA and Rhasspy might fit my needs to replace snips in my home automation setup. Comparing the performance of kali STT, both use the same zamia i think, SEPIA is a lot faster. I asked Florian from SEPIA and he says:

The SEPIA STT server is doing streaming audio transcription meaning the audio file is already transcribed while the user is still speaking.

From what I saw in the Rhasspy logs, it starts transcribing after the voice command is finished.
Is it possible to improve Rhasspy that way?

You're correct. Rhasspy waits until the entire voice command is recorded before starting transcription. This was originally done as a way to increase the accuracy of Pocketsphinx; it does better when it receives a full "utterance" upfront.
Now that Rhasspy has embraced Kaldi for STT, it's time to take advantage of its streaming capabilities. The ground work for this is being laid in the rhasspy-asr-kaldi service, which uses a C++ Python extension to communicate directly with Kaldi (rather than a shell script). A slight tweak to this script should allow for streaming audio, so expect this is the near future!

15 minutes ago I was reading Kaldi documentation regarding streaming features...
And it's already here, awesome =)

Preliminary support for Kaldi streaming is now in the rhasspy-asr-kaldi library. Once I get this moved back into the main Rhasspy app, I'll let you know :)


API fails after long uptime

This is a bit of a tricky issue to troubleshoot so far, but I want to open this issue to track it.
@bsansouci can you post the stacktrace you got?

{ [Error: getaddrinfo ENOTFOUND 0-edge-chat.facebook.com 0-edge-chat.facebook.com:443]
  cause:
   { [Error: getaddrinfo ENOTFOUND 0-edge-chat.facebook.com 0-edge-chat.facebook.com:443]
     code: 'ENOTFOUND',
     errno: 'ENOTFOUND',
     syscall: 'getaddrinfo',
     hostname: '0-edge-chat.facebook.com',
     host: '0-edge-chat.facebook.com',
     port: 443 },
  isOperational: true,
  code: 'ENOTFOUND',
  errno: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: '0-edge-chat.facebook.com',
  host: '0-edge-chat.facebook.com',
  port: 443 }

I think the best shot at fixing this issue will be implementing #161, so we'll close this bug for now.


Truncated Dates (bday / without years) are not parsed

Using truncated representations of dates for birth date is often good practice as noted in the vcard spec _http://microformats.org/wiki/h-card#dt-bday_

"--12-28"
Apart from citing parecki's birthday from the public h-card (send him much gifts) I'll look into it now for a fix [problem is in the intermediate step we would have to use the year 9999 and replace it afterwards, one reason why I am using a format like in my nlp module ].
Feel free to look into the following PR ...

The problem is that it is invalid in JS then.
Maybe we should omit the replace in line 989 and parse it with year '9999' then ...

I corrected the PR so that it would be always this year if the date without year is still happening this year and next year if not ...


KinematicBody2D can't move while it stack by another KinematicBody2D with zero velocity

Godot version
3.5 stable
System information
Win10, Core I7-9700,RTX2080
Issue description
I want to clone the NES game Chip 'n Dale- Rescue Rangers.
Every thing is just fine. But there is some problem found.

The KinematicBody2D on left， we call it K1，right we call it K2.
While K1 jump on K2 , it can move on top of K2.
While K1 is moving on top, K2 can move normally to.
But something bag is come while K1 just stand on top of K2 with zero velocity(just stop), then K2 can't move any way.
I thought while collision count is more than 2, the slide is not work correctly.
Steps to reproduce
just look description.
Minimal reproduction project
No response

well，I think i have figure out.
The problem is is was appling gravity every _physic_process.
func _physics_process(delta:flaot):
        ...
        velocity.y += self.default_gravity*gravity_scale*delta
        velocity = character.move_and_slide(velocity,Vector2.UP)
        ...

and it stuck while other kinematicbody2d stack on top.
I make it only apply gravity while on floor.
func _physics_process(delta:flaot):
        ...
       if not is_on_floor():
            velocity.y += self.default_gravity*gravity_scale*delta
            velocity = character.move_and_slide(velocity,Vector2.UP)
        ...

and it works.

Closing, as this is expected behavior when gravity is constantly applied (even when on floor).


Choose a pipeline for mlflow runs

Description
I have been working with kedro for a long time now, tried to make it a standard for ML projects in our team, I had to use mlflow inside the nodes first, then the hooks came out which was a great feature. Now that we have kedro-mlflow, I juste read about it a bit, and in your example you did not specify which pipeline should trigger the mlflow start experiment.
Context
I think it is very important, because as you know, in a real project there is a lot of pipelines from data preparation to statistical modeling. We should only use mlflow for the training part.
Possible Implementation
Unless I missed something in the documentation, the easiest way to do it in my opinion is to inherit from the MlflowNodeHook, MlflowPipelineHook classes to specify which nodes and pipelines should trigger the mlflow experiment launch. Is there an easier way through the yaml files or the pipelines definition ?
PS: Thank you for this amazing framework 👍

Hi @NoMoreFriends, thanks for your feedback!
To be honest, this is a very common feature request. There are several reasons I did not implemented it yet, some "philosophical" and some "technical".
"Philosophical" reasons
As you mention, machine learning projects always have several pipelines, and some are hardly related to the "training" part.
A common workflow is to have:

An "etl" applications which creates "instances" (e.g. a pandas.DataFrame which contains several examples of the "business object" your ml applications will handle (for example a picture, an iris flower description, a movie review...) and "labels".
A "ml" application which takes the instances as input and return predictions
An "user oriented" applications which takes instances and your ML model and "consumes" it to make some actions

In your Kedro project, these different applications are themselves divided into several pipelines:

the "etl" might be have a pipeline to create the training dataset (becase you extract a given period in the past) and another to create the "live" data for prediction
the "ml" has at least a "training" and an "inference" pipeline, and maybe some other pipelines to explain the predictions (with shap values, activation maps...), one to monitor predictions...
the "user" app is sometimes partly develop by the datascientist (a shiny / dash / Tableau/ streamlit dashboard to demonstrate the value for instance), and will likely be outsourced to a third party (the responsibilty of using the model will likely belong to the "real" business app)

While designing the model, the 3 apps falls under the development of the data scientists because he/she needs to iterate fast. In production, these apps will be orchestrated / scheduled independently and sometimes (often?) a different team will be responsible for each app (a team for the etl and a team for the user app?).
It turned out that many users who asked for "disabling" mlflow automatic versioning in their datascience projects finally acknowledged that it is useful to at least version parameters for all the apps and not only the ml ones. Typical example when this is needed for reproducibility includes:

the etl app creates the training dataset with a SQL request over a time period. During experimentation, the model is trained with different time period (to check stability for instance): if the period parameter is not recorded, it is very hard to remember on which training dataset a given model was trained.
the user app shows the results of several models (for A/B testing) and you want to version the predictions to comapre the results depending on users actions.

These two use cases are no longer prevalent in production because you will likely not change the trainnig dataset definition often, and versioning predictions will no longer be the responsibility of the data scientist. Moreover, you have better tools to handle such uses cases (e.g. DVC for the first, Elastic/Kibana for the second) but mlflow can handle it as well.
As a consequence, I often figured out that in experimentation phase it is often useful to version all runs (and not costly at all if you version only parameters and not data, while lack of versioning may be hurtful), while in production these will be different projects (I mean, different Kedro projects, with different ProjectContext, and likely orchestrated by another tool like airflow), and you can just ignore kedro-mlflow for the projects which do no need it.
Technical reasons

Until today and the PR #91, kedro-mlflow was not able to make the 2 mlflow hooks interoperate easily. You need to access the name of the current run anywhere you make an mlflow call (like logging), because if you don't, mlflow will automatically start a new run with a default local configuration (and create a mlruns folder in your working directory). Not starting the run in MlflowPipelineHook is not enough to avoid mlflow logging.
If a user make a call to mlflow inside a node (and the plugin is totally unaware of it - this should never happen in the final version of the plugin, but a few use case are notcovered by the plugin yet), mlflow will use its default configuration and completely mess things up. Forcing the configuration is a "safety guard".

Design decision and plugin roadmap
Despite above reasons, I totally acknowledge that you sometimes need / want to turn off mlflow logging and you may have some pipelines that do not require mlflow at all. Above all, many users require this feature request and @takikadiri insist that it is very useful for transition to production. As a consequence, we plan to add this feature in a near future (i.e. within few months). However, I have not defined yet what is the best way to do so.
First, I think that versioning must be activated by default (after all, this is why people install kedro-mlflow). We wil provide an opt-ou strategy rather than an opt-in strategy. This means we will provide a list of pipelines to exclude rather than a list of pipelines to include in mlflow versioning.
Second, we should define how to parameterize run versioning deactivation. The **mlflow.yml is a good candidate, but it is becoming overcrowded.
disabled_pipelines: # find a  better name
    - pipeline1
    - __default__

Another (or complementary) possibility would be to use extra run params to enable deactivate at run time. Something like:
kedro run --pipeline=my_pipeline --no-mlflow

but it will be hacky while https://github.com/quantumblacklabs/kedro/issues/382 is not solved.
Short term solution
Unfortunately, I don't have an easy solution to opt out only some pipelines. You can inherit from the two hooks as you suggest, but you will have to manage carefully configuration retrieval. If you're in a hurry, feel free to open a PR.
You will need to:

add a key in the mlflow.yml
update framework/context/config KedroMlflowConfig to manage this new key
update the hooks:

Before this line :
https://github.com/Galileo-Galilei/kedro-mlflow/blob/e8f9f09d01cca9a6b9f99006ad482988319bb297/kedro_mlflow/framework/hooks/node_hook.py#L77
Add:
config = get_mlflow_config(self.context)
# not sure where the current running pipeline name is stored
if context.pipeline_name not in config.disabled_pipelines:
   <rest of the code>

And do the same in the MlflowPipelineHook.

Hi @NoMoreFriends,
sorry for the long radio silence. The functionality described in this issue is partially implemented in the PR #184.
You can add the following key in your mlflow.yml:
disable_tracking:
  pipelines:
    - pipeline_to_disable

Some disclaimers:

it will turn off automatic parameters logging as well as catalog logging (Mlflow<Artifact|Metrics|Model>DataSets) from kedro-mlflow , but if you have added mlflow code inside your own code (e.g. add mlflow.log_metric in one of your node) mlflow will open a new run by default in a mlruns folder at the root of your project (mlflow does not support tracking deactivation).
This is only compatible with kedro>=0.17.1.
It is not possible yet to add the --no-mlflow flag in the cli, but it may become availble in future kedro version since the kedro team has introduced the abilities to override the run command in their develop branch but it is not released yet.
It lacks some tests and documentation, so I will not released the feature before weeks, but feel free to try it out and give feedback!


Can't debug nodemon twice

Debug a nodemon config like this:

{
    "type": "node",
    "request": "launch",
    "name": "nodemon",
    "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/nodemon",
    "program": "${workspaceFolder}/out/app.js",
    "restart": true,
    "console": "integratedTerminal",
    "internalConsoleOptions": "neverOpen"
},

Press stop
Start debugging again
"There is already a debug configuration "nodemon" running"

Thanks for the nice steps, I can reproduce it.
After debugging the problem here is that on stop the debug adapter send a onDidTerminateDebugge with the event.body.restart so we try to restart and fail which leavs the session in a bad state.
So when vscode sends a terminate or disconnect request to debug adapter the debugee exit event should not contain the restart inside the body.
Forwarding to @weinand and @roblourens to potentially fix this on the extension side.

It seems like the DA might not be handling terminate/disconnect correctly, but it works in 1.28 and nothing has changed in the DA. Did anything change with how those events are sent?

@roblourens it migth be that before we were not keeping inactive session which we do now as part of the refactoring to show multiple debug consoles.
Anyways this refactoring seems to have uncovered an issue on the adapter side. Let me know if this can not be fixed on the adapter side and if that is the case I can try to find some solution on the vscode side

Yeah I need to fix it on the DA side. But I'm confused, the terminate request doesn't seem to work in 1.28. The DA sends supportsTerminateRequest but this.raw.capabilities.supportsTerminateRequest is false in debugSession.terminate...?

I thought that Live Share issue was fixed? Very frustrating when debugging this stuff.

This is a different issue when the program terminates cleanly, it's not the typical nodemon scenario, tbh I think this scenario has never worked quite right.
We can tell that nodemon is not going to restart when we get to here: https://github.com/Microsoft/vscode-node-debug2/blob/master/src/nodeDebugAdapter.ts#L307

Actually, I don't think I want to change this. You can still restart debugging if you change the program again within 10s. If you wait more than 10s, the DA times out and you can press F5 again. I am not sure how to improve this because the DA doesn't have anything to attach to when the app is not running, and we don't have UI or a concept of the DA waiting forever for nodemon to start again... I don't remember users complaining about this either, so I'm leaving it alone.


[REQUEST] Gain new module at 100 Rare Metals

Once the player collects 100 rare metals, a module should be given to the player. They will be able to select it in the select 1-of-3 module screen. The fact that 100 rare metals translates to getting a new module should be conveyed, for example; the rare metal counter appears along with a notice of "you can now craft a module!" and the rare metal counter resetting to zero. Something similar can also be done.

Task Estimation (time): 2-4
Does this issue address a risk? No this is more a game balance thing I think
Risks: I haven't touched any of these systems before!! 8D
Risk Resolution: Will flail in chat as normal.


Mentorship requests: add Long/Short term option and creation date

Dependency
It's not really a dependency, but #93 and #91 change the code in the same area and you would need to solve conflicts. I would wait for them to be merged.
Accept/Reject request do not update the lastUpdateDate field.
Problem
There is the option to offer long or short term mentorships. Part of the application already has this, but the request for mentorship does not. There is no creation date either, only last update date.
Feature Description
Update the flow adding the booleans for long/short term, and creation date:

xata (add two boolean columns for long/short term, and creation date) in the tupuapp/xata/schema.yaml for requests, and relationships tables (similar to users.mentor)
RequestModal (add two switches long/short, send values to request.js)
request.js save long/short term boolean values to the request
acceptMentorship.js endpoint (createRelationship, updateRequest, and send email notification), update the lastUpdateDate field, and the long/short term booleans.
rejectMentorship.js endpoint (updateRequest, and send email notification), update the lastUpdateDate field.
cancelRequest.js endpoint (updateRequest, and send email notification)

Screenshot

Depends on:

[x] https://github.com/tupuio/tupuapp/pull/93
[x]  https://github.com/tupuio/tupuapp/pull/91

Regarding about the usage of switch components: Can both options be on or off in the same time? Can user have bothe long term and one time option selected at the same time?

Regarding about the usage of switch components: Can both options be on or off in the same time? Can user have both long term and one time option selected at the same time?

Thanks for your first contribution!
Well, ideally we could have two different boolean values: one mentor could be up for both, only for long, or only for short.
Alternatively, it could be an Enum with three different options.
The important thing is to update accordingly the whole flow after this.
The Xata schema has currently two booleans in the mentor preferences/settings:
https://github.com/tupuio/tupuapp/blob/cd9abf43ddf2642842c8d577a8163cf2690f7499/xata/schema.yaml#L38-L41
The request should have these two fields as well, when created (you can add the two columns in the schema.yaml file for the requests table).
In a followup ticket, the request, when accepted, should also get these two fields, and the relationship table should have accordingly two new columns with the values updated. I don't remember if the follow up ticket is already there, let me check.

xata (add boolean column, creation date)
RequestModal (add switch long/short, send it to request.js)
request.js save it to the request
acceptMentorship.js endpoint (createRelationship, updateRequest, and send email notification), update the lastUpdateDate field.
rejectMentorship.js endpoint (updateRequest, and send email notification), update the lastUpdateDate field.
cancelRequest.js endpoint (updateRequest, and send email notification)

the dependencies are resolved as the PR was merged, all good.

We also have a question related to the boolean field long/short term. What is the expected design for the database? Should it be one column, long_term: true (and we assume that short_term is false), or should it be 2 columns, one for each?

I think we went for two columns. They can be both true at the same time. Off at the same time? Maybe not, otherwise there would be no mentorship option I guess.

@raluka I'm reviewing this ticket now. It was OK as it was before: only one boolean long/short. This is about when a Mentee is asking for a mentorship, therefore should choose among long or short term. Sorry about this. I was not on this since more than a month. I am updating again the ticket. If you already worked on it, it's ok. It does not hurt to give both options to the Mentee.

@raluka The ticket is updated.
NB. Usually I add the columns in the xata dashboard while developing, because the changes to the tupuapp/xata/schema.yaml as far as I remember will be actionated when merged to main.

Hi @lorepirri , thank you for taking the time to revisit the ticket, and update it accordingly.

one could add a single [switch for long term] in my opinion, as you wish


[Feature Request]: align loader-runner with Webpack

What problem does this feature solve?
In the previous version of Rspack, webpack's loader-runner is a simple customized implementation for working with a simple scenario without features for pitch-loader. We should refactor this to a full-port of loader-runner in order to support full-functionalities. Builtin loader should also be considered in this scenario.
What does the proposed API of configuration look like?
See: https://github.com/webpack/loader-runner

closed with #2808


v5

Still very much a WIP.
I'm still deciding how I want to handle the transition from v4 to v5 - this will most likely break all plugins that integrate with LPs native API. I'm considering supporting both on different branches for a little while.

Maybe have an update with the v4 api and announce the breaking changes before updating at a later date?
Also what are the changes in general?

I have two suggestions for v5:

Change the server context on the bungee/velocity version to proxy and the world to server. This will simplfy working with per server groups. (If you want I will turn this into a full blown suggestion issue with my full reasoning and all)
Add a new messaging-service: auto and use it as the default. It will behave like none behaves right now (do nothing if no SQL storage is being used and behave like sql when it is). none should always do nothing. And let's get rid of nosql.

I don't quite see an actually good reason for the first idea, so explaining it in more detail and especially why it would be useful would be great.
From what I understand is the reason why context is server and world on both proxy and server-level simplicity.
Instead of having a separate context thing you have to remember, you can just use and apply the same context in the same way: Server is entire server/proxy, world is a specific world/server.
Again I personally would like some more explanation why this should be changed like that.

Alright. The explanation is pretty straight forward:
Per server ranks/permissions/meta
With the current system to assign a group that works per server on the backend servers and the proxies you either have to assign the group twice with different contexts, which is terrible for consitency and maintenace, or use a helper group, which inherits the same group twice for different contexts.
So to simplify this I'm suggesting that server reffers to the same thing: The backend server the player is on.
This make assigning per server things in a network super easy. And you don't have to worry about mainting separate contexts and other shenanigans.
I think it's clear why I'm suggesting this for v5. But to make sure we're all on the same page, this would be a breaking change. So a major update is the right place for that.

I can see what the issues are and can agree that in this case a seperate proxy context for the proxy would make sense.

finally more simplified api

I've a rather strange request for version 5...
A track system for only prefixes. So if you join like a Creativeplots server with Tiers from I Till X people can get promoted but only the prefix wil be update. So example the default prefix and track starts with I and i promote the prefix so it will be II and again III and on and on... You get the point.

Isn't that already possible with the current system, by using two tracks instead of one?
My idea would be the following, I'm just describing it with the groups one, two and three, but I hope you understand me:
Tracks

prefixes_tiers
-- prefixes_one -> prefixes_two -> prefixes_three
tiers
-- one -> two -> three

Groups

prefixes_one
-- With permissions:
-- prefix.1.&7one

prefixes_two
-- prefix.2.&7two

prefixes_three
-- prefix.3.&7three

one
-- group.prefixes_one

two
-- group.one
-- group.prefixes_two

three
-- group.two
-- group.prefixes_three

Then by setting up prefix stacking it should be possible to have only have the prefixes changed by promoting on prefixes_tiers and promoting "normal" including the prefixes on tiers
Testing
I am currently not able to test this out, but I'll leave a response here (editing this comment), telling if I made it or not

Current state: Not tested out

Wouldn't it be a good idea to rephrase those flag-names?
They sound a bit weird and Imo overcomplicated.
Ideas of new query param names:

INCLUDE_NODES_SET_WITHOUT_SERVER -> INCLUDE_NODES_WITHOUT_SERVER
INCLUDE_NODES_SET_WITHOUT_WORLD -> INCLUDE_NODES_WITHOUT_WORLD
APPLY_PARENTS_SET_WITHOUT_SERVER -> APPLY_PARENTS_WITHOUT_SERVER
APPLY_PARENTS_SET_WITHOUT_WORLD -> APPLY_PARENTS_WITHOUT_WORLD

tl;dr remove the SET part since it seems a bit redundant and makes the flags look a bit weirder.
Just a suggestion tho.

Wouldn't it be a good idea to rephrase those flag-names?

Point taken - I've changed them, although they've now ended up even longer 😅

I think I'm nearing completion with the API side of things.
Breaking changes to the plugin will come later, my focus currently is getting the API to a state where I'm happy with it, and yeah, nearly there.
I'd welcome any API related suggestions anyone has at this stage.
This will probably be our very last chance to make changes.

I've hidden the non-API related comments for now, they probably belong in new issues. :))

Point taken - I've changed them, although they've now ended up even longer 😅

Much clearer that way 👌

I'm still deciding how I want to handle the transition from v4 to v5 - this will most likely break all plugins
Maybe just deprecate the old api?

I'd keep the old API in the plugin jar (and make it functional by delegating the calls to the new API) and of course have it deprecated .
I'd keep that for at least 5.0, maybe even 5.1.

It's quite tricky, there is a lot of stuff that would require proxying.
It's a lot of work for me to try and support this.

What alternative is there?
Breaking it completely will make server owners an plugin authors equally mad.

I thought we discussed this once where we came to the idea of making an update on the resource pages and inform about the future change of the API to V5 which will break most if not all plugins using the LuckPerms API and that the devs should update their plugins asap.

I also want to bring that up again, because I think it got forgotton or overlooked over the commits made.

Wouldn't it be a thing to rename getBytebin() and bytebin to getBytebinClient() and bytebinClient respectively for consistency?

Not super important Andre :p

I thought we discussed this once where we came to the idea of making an update on the resource pages and inform about the future change of the API to V5 which will break most if not all plugins using the LuckPerms API and that the devs should update their plugins asap.

The main issue with this approach is that plugins can't support both versions of the API. Or at least not easily. And this is a burden I don't think that should be put in the hands of plugins devs, even if it is possible.

I don't see a reason as to why we should keep this tho...
LuckPerms is not like spigot where people still use older versions (or to be more exact: Where they shouldn't use older versions)
LP is compatible with all major versions of Spigot and people should update it anyways so keeping support for an old, worse API version shouldn't be encouraged.
If LP updates then people should update for the simple reason of security and performance improvements... And the same goes for the devs

As long you will take the support for both angry server owners complaining that the new update broke their other plugins (and therefore they will stay on v4) and the plugin devs why the API was broken completely so they now need to deal with angry server owners themselves, etc.
At least make the read-only part of the API working. That'll satisfy at least 90% of public plugins.

We can't satisfy everyone or else there wouldn't be people on the Discord or in the issues requesting stuff like GUI integration or web editor changes.
When we announce that a breaking change to the API will be launched soon (and provide a way to already use it), then we can already cover a big amount of devs and owners with this...
The people that don't care and won't update basically didn't do that anyway in the past.
Again: I don't see an actual reason why v4 should be kept, even as a read-only thing.
This is not Spigot where it makes sense that 1.8.8 still exists (even tho it shouldn't). Staying with a newer version of LP is almost a requirement now because of previously mentioned reasons (bug fixes and other improvements)
I seriously can't see why there should be any remaining thing for the v4 API once this version here is launched... If you have any actually good reason then please be so nice and elaborate it.

You tell that to my 2 year old still perfectly fine working plugin.
I hope you also are aware that devs sometimes abandon plugins. Meaning they never will get updated. But they still work. And then LP throwing backwards compatibility in the trash will make everyone happy because now the server admins have a broken plugin (with possibly no reasonable alternative) that would work if the LP API wouldn't have been broken.
And yes. I do think LP should accept the fact that is has become standard. And therefore needs to be fairly conservative when breaking the API.
The 4.0-4.4 updates did a great job of that. A plugin written for API 4.0 still works flawlessly with version 4.4. And sure. While full backwards compatibility might not be possible without a massive effort some basic backwards compatbility is pretty much expected.
On the same note, everything that ends up no longer being supported should throw a nice exception that essentially tells the server admin to ask the plugin dev to update to the latest version of the API.

It's funny how you explain PermissionsEx in a nutshell here... Are (not anymore) abandoned plugin that still works fine... Until stuff breaks.
And what will people do when that happens? They search for an alternative. In most cases when a plugin gets abandoned can you expect someone else to take this plugin and update it as a fork.
This essentially happened with LWC, LightAPI and not to forget Essentials to mention a few.
An abandoned plugin shouldn't be supported and used anymore and LuckPerms shouldn't encourage this through its API or we have another case of PEX-like people complaining that it works "just fine" despite being god knows how old...
But after all, is this Luck's decision.
And I'm off to bed now.

I'm gonna stand ground though. I won't be taking any of the "my stuff isn't working anymore" support cases. And there will be tons.
And adding backwards compatibility hardly ever is a bad thing. Especially for popular things and when doing so is easy.

I might be a bit late, but it would be nice to have node related events trigger on servers after a network sync
Currently adding a node to a user on a bungee server and then doing a network sync does not trigger the event on the client servers.

About which event, in particular, are you talking?

About which event, in particular, are you talking?

Events in the me.lucko.luckperms.api.event.node package. I tried with the NodeAddEvent.

https://github.com/LuckPerms/extension-legacy-api
Bridge from API v4 --> v5, so existing plugins coded against older versions of LuckPerms will continue to work.
Currently supports everything (read/write etc), with the one big exception of event listeners - that will probably come later though.

How exactly would this jar be added?
Would it be added into an extension folder or similar? Or would it be just put into the plugins folder?

Into an extension folder. Reason being: I don't want to clutter the main plugin with legacy compatibility code.

I assume it's now ready for release?


error。

Windows environment can't  installed properly

Have you try to install using the Burp Store inside the Extender Tab inside Burp Suite? It should work.
Manual installation wasn't tested on windows like explained on the Wiki page. But the error here maybe make sure the requirements.txt doesn't have any space or special characters that might be copied by error.

No update, but should be fixed using burp store (in extender tab) inside Burp Suite.


Experiment with merging for embedding models

We could merge a mistral-e5 (or the new improved version) onto the Danish Munin model.
@x-tabdeveloping

Maybe we should wait with this until the legal issues get resolved (?)

Maybe we should wait with this until the legal issues get resolved (?)

Feel free to write me on slack regarding this, I will leave it out of this issue though.
I have added a few models to run experiments on:
Two models merged using the adapter layer from mistral-e5:

https://huggingface.co/KennethEnevoldsen/munin-neuralbeagle-7b-e5
and one with munin

I will also create a direct merge between mistral-e5 and munin.
We should also get the embeddings of pure munin as a baseline.

We did so in #163, though they weren't highly promising


only set google analytics in prod env

dev 环境下设置analytics是否有意义？

Current coverage is 96.29%

Merging #614 into master will increase coverage by +0.32% as of c5f03af

@@            master    #614   diff @@
======================================
  Files          101     119    +18
  Stmts         4277    4669   +392
  Branches         0       0
  Methods          0       0
======================================
+ Hit           4105    4496   +391
  Partial          0       0
- Missed         172     173     +1

Review entire Coverage Diff as of c5f03af

Powered by Codecov. Updated on successful CI builds.

没必要，不影响，Google 分析的 key 是分环境的，这里价格判断多余。
同时不应该让 development, production 具有不同的代码，这回造成上线出问题的风险，例如某天这个调用 Setting.google_analytics_key 要报错了，开发和测试环境无法发现。


Injecting Props With a HOC does not work with functional stateless component

This code works on https://flow.org/try but does not work when MyEnhancedComponent is imported elsewhere.
import * as React from 'react';

function injectProp<Props: {}>(
  Component: React.ComponentType<Props>,
): React.ComponentType<$Diff<Props, { foo: number | void }>> {
  return function WrapperComponent(props: Props) {
    return <Component {...props} foo={42} />;
  };
}

// This works in flow.org/try but not if MyEnhancedComponent is imported from another file.
const MyComponent = (props: {a: number, b: number, foo: number}) => null;

// class MyComponent extends React.Component<{
//  a: number,
//  b: number,
//  foo: number,
// }> {}

const MyEnhancedComponent = injectProp(MyComponent);

// We don't need to pass in `foo` even though `MyComponent` requires it.
<MyEnhancedComponent a={1} b={2} />;

When I switched https://github.com/este/este to PureComponent (for another reason), Flow HOC example seems to work.

Test case. If I will rewrite https://github.com/este/este/blob/master/components/Auth.js component to functional stateless, then where Auth is imported, it does not work.

@steida does following work better:
  Component,
): React.ComponentType<$Diff<React.ElementConfig<Component>, { foo: number | void }>> {
  return function WrapperComponent(props: React.ElementConfig<Component>) {
    return <Component {...props} foo={42} />;
  };
}

It's slightly unintuitive, but you should use either ElementProps or ElementConfig to retrieve the component props: https://flow.org/en/docs/react/types/#toc-react-elementconfig

@villesau Yep, this works! Thank you.
@calebmer How we can help with docs updating?

@villesau Btw, why no ElementProps by default? Is there any drawback?

@steida Normally you might not want to enforce passing default props to the connected component. ElementProps and ElementConfig are otherwise the same, but ElementConfig marks default props as optional.

Btw, with Flow 0.72, we can not use * anymore. Because http://github.com/este/este is using PureComponents, I don't care.

These import related issue should be fixed long time ago


CAPZ: Allow overriding kustomize component path

This PR adds the ability to locally override the path for Kustomize components within a CAPI provider repository.
This is required for https://github.com/openshift/cluster-api-provider-azure/pull/322 so that the Azure Service Operator's Deployment arguments can be overridden to ignore handling CRDs.
Adding that modification directly in the Go code here would create a tighter coupling between this repository and the CAPZ one, and would be less flexible for future scenarios.
Also added a README file to explain some assumptions in the code base and document overriding the Kustomize component path.

Files generated with this code on my local machine can be seen in this commit: https://github.com/openshift/cluster-api-provider-azure/pull/322/commits/5cb8769053b6629d2d38b3bde30099060438c712

/retitle OCPCLOUD-2642: manifests-gen: Allow overriding kustomize component path


Anti-alias AOT borders

Microsoft PowerToys version
"0.62.0"
Running as admin

[X] Yes

Area(s) with issue?
Always on Top
Steps to reproduce
The corners seem to be not smooth.
✔ Expected Behavior
Smooth corner
❌ Actual Behavior
Corners do not smooth.
Other Software
No

Can you be a bit more specific?

Can you be a bit more specific?

Don't know if the screenshot is clear.

Do you mean the pixels or something else?

Yes, the round corners seem a little jagged.

Not solved in v0.75.1
There's a gap too.

@SeraphimaZykova something for you, maybe?


Is there an example for nextjs?

Hi!
I would love to try esbuild-loader with nextjs. Do you know any examples for a working configuration of nextjs with esbuild-loader?

Hello,
I've tried to configure esbuild with nextjs and got some success. Here's the config.
const {
  ESBuildPlugin,
  // ESBuildMinifyPlugin
} = require('esbuild-loader');

const tsconfig = require('./tsconfig.json');

module.exports = {
  webpack: (config, { webpack, dev }) => {
    if (!dev) {
      config.plugins.push(
        new webpack.ProvidePlugin({
          /**
           *  Not sure why, This increases bundle size
           * when you would think the oposite would be true!
           */
          // __jsx: ['react', 'createElement'],
          // __fragment: ['react', 'Fragment'],
          React: 'react',
        }),
      );
      config.plugins.push(new ESBuildPlugin());
      const convertToESBuild = (obj) => {
        if (obj.loader === 'next-babel-loader') {
          return {
            loader: 'esbuild-loader',
            options: {
              loader: 'tsx',
              target: 'es2017',
              tsconfigRaw: tsconfig,
              // jsxFactory: '__jsx',
              // jsxFragment: '__fragment',
            },
          };
        }
        return obj;
      };

      const rule = config.module.rules[0];
      if (rule) {
        if (Array.isArray(rule.use)) {
          rule.use = rule.use.map((e) => {
            if (typeof e === 'object') {
              return convertToESBuild(e);
            }
            return e;
          });
        } else {
          rule.use = convertToESBuild(rule.use);
        }
      }

      /**
       *  Not sure why, but ESBuildMinifyPlugin makes the bundle larger.
       *
       * With Default Minimization:
       * Main Bundle: 239 KB
       * Largest Page: 122 KB
       *
       * With ESBuild Minification:
       * Main Bundle: 664 KB
       * Largest Page: 132 KB
       *
       * Probably a configuration error.
       */

      // // Remove Default TerserPlugin
      // config.optimization.minimizer.shift();

      // // Add ESBuild Minify
      // config.optimization.minimizer.unshift(
      //   new ESBuildMinifyPlugin({
      //     target: 'es2017',
      //     minify: true,
      //   }),
      // );
    }
    return config;
  },
};

As you can notice, this is only for prod. In dev, the compilation works fine, but next router breaks.
Haven't quite figured out how to configure Minimizer yet.
Config inspired from #62

Hello,
I've tried to configure esbuild with nextjs and got some success. Here's the config.
const {
  ESBuildPlugin,
  // ESBuildMinifyPlugin
} = require('esbuild-loader');

const tsconfig = require('./tsconfig.json');

module.exports = {
  webpack: (config, { webpack, dev }) => {
    if (!dev) {
      config.plugins.push(
        new webpack.ProvidePlugin({
          /**
           *  Not sure why, This increases bundle size
           * when you would think the oposite would be true!
           */
          // __jsx: ['react', 'createElement'],
          // __fragment: ['react', 'Fragment'],
          React: 'react',
        }),
      );
      config.plugins.push(new ESBuildPlugin());
      const convertToESBuild = (obj) => {
        if (obj.loader === 'next-babel-loader') {
          return {
            loader: 'esbuild-loader',
            options: {
              loader: 'tsx',
              target: 'es2017',
              tsconfigRaw: tsconfig,
              // jsxFactory: '__jsx',
              // jsxFragment: '__fragment',
            },
          };
        }
        return obj;
      };

      const rule = config.module.rules[0];
      if (rule) {
        if (Array.isArray(rule.use)) {
          rule.use = rule.use.map((e) => {
            if (typeof e === 'object') {
              return convertToESBuild(e);
            }
            return e;
          });
        } else {
          rule.use = convertToESBuild(rule.use);
        }
      }

      /**
       *  Not sure why, but ESBuildMinifyPlugin makes the bundle larger.
       *
       * With Default Minimization:
       * Main Bundle: 239 KB
       * Largest Page: 122 KB
       *
       * With ESBuild Minification:
       * Main Bundle: 664 KB
       * Largest Page: 132 KB
       *
       * Probably a configuration error.
       */

      // // Remove Default TerserPlugin
      // config.optimization.minimizer.shift();

      // // Add ESBuild Minify
      // config.optimization.minimizer.unshift(
      //   new ESBuildMinifyPlugin({
      //     target: 'es2017',
      //     minify: true,
      //   }),
      // );
    }
    return config;
  },
};

As you can notice, this is only for prod. In dev, the compilation works fine, but next router breaks.
Haven't quite figured out how to configure Minimizer yet.
Config inspired from #62

I would also love to see an example with Next!

I would also love to see an example with Next!

Tried out a config based on your attempt @kuasha420 - noticed some CSS issues, namely styles coming from styled components. We use a mix of styled components as well as SCSS modules. Have you noticed any styling issues when comparing the build output from esbuild-loader vs the standard config?

I've also tested a similar config, but when built, getServerSideProps does not seem to be running when navigating to a SSR'd page via next router — but reloading or navigating directly to that pages URL causes it to run correctly. Did you test any SSR data-fetching pages?

I've also tested a similar config, but when built, getServerSideProps does not seem to be running when navigating to a SSR'd page via next router — but reloading or navigating directly to that pages URL causes it to run correctly. Did you test any SSR data-fetching pages?

I also experienced same behavior. My next step is to try swc and see if that's any different there.

I don't have any experience with Next.js, but I can try taking a look if one of you wants to provide a minimal reproduction repo.
Pure speculation but I also worry that replacing next-babel-loader might not be a good idea since it might not be identical to babel-loader and could be applying custom presets integral to Next.js.

I can try taking a look if one of you wants to provide a minimal reproduction repo.

I've modified the Next.js starter slightly here to demo the issue. In dev, you'll see that getServerSideProps works on page load and on router navigation. However after you yarn build and yarn start, you'll see that getServerSideProps only runs on page load.

Thanks @tdjsnelling
I added a Next.js example here: https://github.com/privatenumber/esbuild-loader-examples/tree/master/examples/next
Hope that helps.
Closing this as I think it's addressed but will re-open if there's anything more to do.

Thank you for sharing that! Do you have a confidence level for the stability of it? As in, do you think it’s safe to ship in production Next apps?

Every Next.js app is configured and used differently so I can't speak to that.
I don't know anything about your code, so even if I said I was confident, that won't mean much in the context of your app. You'll have to do your own due diligence of thorough testing to develop confidence.
If you run into any issues with the recommended Next.js configuration, let me know and I can try to help.

The example seems to not work anymore in Next.js 11. Cannot set property 'loader' of undefined

@hyoretsu You should skip the loader patch for test: /.m?js/ pattern.

To make it work with webpack 5 in nextjs 11 you must update those lines
https://github.com/privatenumber/esbuild-loader-examples/blob/8ddf91b7d67e38237dc68008452b7af570be50da/examples/next/next.config.js#L24
with
  if (jsLoader) {
    jsLoader.use = {
      ...jsLoader.use,
      loader: 'esbuild-loader',
      options,
    }
  }

To make it work with webpack 5, u can use replace next lines
https://github.com/privatenumber/esbuild-loader-examples/blob/8ddf91b7d67e38237dc68008452b7af570be50da/examples/next/next.config.js#L17
with
  if (jsLoader) {
    jsLoader.use = {
      ...jsLoader.use,
      loader: 'esbuild-loader',
      options,
    }
  }

I highly discourage  anyone to use example above in real projects. You should find a better and more reliable way to maintain your webpack config.
I was really amazed by how built time reduced, tho.

I can't make this work with Next 13
TypeError: Cannot read properties of undefined (reading 'useSourceMap')
    at /next/node_modules/.pnpm/esbuild-loader@4.0.0_webpack@5.88.2/node_modules/esbuild-loader/dist/index.cjs:192:40
    at _next3 (eval at create (/next/node_modules/.pnpm/next@13.4.12_@babel+core@7.22.9_react-dom@18.2.0_react@18.2.0_sass@1.64.2/node_modules/next/dist/compiled/webpack/bundle5.js:13:28867), <anonymous>:19:1)
    at eval (eval at create (/next/node_modules/.pnpm/next@13.4.12_@babel+core@7.22.9_react-dom@18.2.0_react@18.2.0_sass@1.64.2/node_modules/next/dist/compiled/webpack/bundle5.js:13:28867), <anonymous>:54:1)

"esbuild-loader": "^4.0.0",
"next": "^13.4.12",
"typescript": "^4.9.5",
"webpack": "^5.88.2"

next.config.js
/* eslint-disable @typescript-eslint/no-var-requires */

const { EsbuildPlugin } = require("esbuild-loader");

function esbuildMinify(config, options) {
  const { minimizer } = config.optimization;
  const terserIndex = minimizer.findIndex((minifier) => minifier.constructor.name === "TerserPlugin");

  minimizer.splice(terserIndex, 1, new EsbuildPlugin(options));
}

function esbuildLoader(config, options) {
  const { rules } = config.module;
  const rule = rules.find((rule) => rule.test?.test(".js"));

  if (rule) {
    rule.use = {
      ...rule.use,
      loader: "esbuild-loader",
      options,
    };
  }
}

const path = require("path");
const withPurgeCSSModules = require("next-purge-css-modules");

/**
 * @type {import('next').NextConfig}
 **/
const nextConfig = {
  reactStrictMode: true,
  compress: true,
  images: {
    unoptimized: true,
  },
  exportPathMap: function () {
    return {
    };
  },
  purgeCSSModules: {
    content: path.join(__dirname, "src/**/*.{js,jsx,ts,tsx}"),
  },
  experimental: {
    optimizeCss: true,
  },
  modularizeImports: {
    "@mui/icons-material": {
      transform: "@mui/icons-material/{{member}}",
    },
  },
  webpack: (config, { webpack }) => {
    config.plugins.push(
      new webpack.ProvidePlugin({
        React: "react",
      })
    );

    esbuildMinify(config);
    esbuildLoader(config, {
      loader: "tsx",
      target: "esnext",
    });

    Object.assign(config.resolve.alias, {
      react: "preact/compat",
      "react-dom/test-utils": "preact/test-utils",
      "react-dom": "preact/compat",
    });
    return config;
  },
};

const withBundleAnalyzer = require("@next/bundle-analyzer")({
  enabled: process.env.ANALYZE === "true",
});
module.exports = () => {
  return withBundleAnalyzer(withPurgeCSSModules(nextConfig));
};

This issue was closed 3 years ago. If you need help, please ask a question in Discussions or Next.js's repo.


Add support for list values in tags in Span and SpanCustomizer

Currently, Span and SpanCustomizer support tags with String, boolean, long and double values. OpenTelemetry additionally supports lists of those four types. This feature request proposes adding support for lists of these types to Micrometer.
Unfortunately, it seems that Brave doesn't support lists. One solution would be to concatenate the lists to a String.

I'm not sure there is a huge concern from the point of view of the tracing library (as you said we can concatenate) but for me the big question is the backend (this is a concert for the OTel SDK too): what happens if your backend does not support lists for tag values (I would assume that most of them don't)?
OTLP supports array for attribute value but there are exporters that don't (e.g.: Zipkin).
Also, I don't see this (see Span):

OpenTelemetry additionally supports lists of those four types

Do you mean this or something else?
<T> Span setAttribute(AttributeKey<T> key, T value)

I guess right now you can do a String.join, what difference do you have on the backend side if you use a single concatenated String instead of a List?

what happens if your backend does not support lists for tag values?

For example the OtelToZipkinSpanTransformer creates a comma separated string.

Do you mean this or something else?

Exactly this. The usage would be for example:
.setAttribute(AttributeKey.stringArrayKey("example"), List.of("a", "b", "c"))

what difference do you have on the backend side if you use a single concatenated String instead of a List?

Grafana Tempo has experimental support for vParquet4, which also adds support for searching through arrays.

Makes sense, do you want to open a PR for this?
I think it would be really similar to this change: https://github.com/micrometer-metrics/tracing/commit/0faf66fb75c9f6df0a197336271b50bfd8da6551

I'm curious if anyone has a need for this. We've held off on allowing multi-value tags in metrics (I think at the time only Datadog supported them), and so I'm curious why there would be any more need for it in tracing. Can anyone share some real world examples of what they (would) use it for?

Unfortunately, it seems that Brave doesn't support lists. One solution would be to concatenate the lists to a String.

This sort of highlights the peril of introducing this. What's the expectation on querying a backend for multi-value tags that are a concatenated string because the format or backend don't support multi-value tags? Suddenly some tag values may have structure and no longer be opaque, but existing single-value tags might contain commas that aren't indicative of a multi-value tag.


Allow unique fontFamilyName

This pull request allows you to specify a unique fontFamilyName that's independent of the filename.
We ran into wanting this over at https://github.com/primer/octicons/pull/91
fontFamilyName should just fall back to font so it shouldn't break anything if fontFamilyName isn't set in the options.
Am I missing anything?

Does it work with the node engine? And please also check Travis CI logs.

This should be in better shape, @sapegin. Any other feedback? Any other noob moments? :smile:

Cool, thanks!


tally method in array

create method that counts all the elements in an array a and returns a hash with their counts.
$array = @('abc','ff','abc','abc','ff','r')
$array.tally()
abc ff r
3   2  1

You can use Group-Object cmdlet.


Corrected self.resource.working always being set to false

The api health checks were not working. I just commented out the self.resource.working = false; on the success callbacks, I retained those lines in the error/failure callbacks.

Hi Joemar.
This status indicates when the api is being used. When it is no longer being used, it again becomes false. For example, if you use a ng-show with "loading excited," it will only appear when it are actually being used.

Ok, I understand your explanation. I was thinking that an API health check should show it is "working" by default unless an error is found. Your design is that is "not working" by default unless you use it and found it working.

OK. My goal for this status "working" is to show the User that your request is still in progress.  For example, the User clicks a save button, while the api is working on the process of saving, a message or carrying animated is shown. This is my purpose.

Ok. So, we are actually talking about different things here. I thought the API checking you implemented is for the purpose of a general API health check (something like this: https://dev.twitter.com/overview/status). So, in fact, your "working" status is more of an indicator of progress of every api request. That's fine. I will probably just roll own my own API health check. Thanks for the replies.


Documentation: Interop with non-react-reason components

Thanks for the module!
One of my requirements is to interop well with a preexisting components library written in standard ReactJs, transpiled with Babel, linked with Lerna in our monorepo.
It took some difficulty to work out how to do that with this library, so I wanted to share.  Now, admittedly, I'm new to react-reason so this might be a bad pattern. But it compiles cleanly and works:
module type T = {
  let make: {. "message": string} => React.element;

<EMAIL_ADDRESS>  external makeProps:
    /* Type the props for your imported component here. */
    (~message: 'message, ~key: string=?, unit) => {. "message": 'message} =
    "";
};

<EMAIL_ADDRESS>external component: (module T) = "undefined";

module Lazy: T = {
  include (val component);
  /* make sure your import()ed component is a default export! */
  let make =
    ReLoadable.lazy_(() => DynamicImport.import("@internal/a-component"));
};

Note the final let default = make; in the module definition does not seem to be necessary with this pattern, as you can see by the generated bs.js:
// Generated by BUCKLESCRIPT VERSION 5.0.4, PLEASE EDIT WITH CARE

import * as React from "react";

var make = React.lazy((function (param) {
        return import("@internal/a-component");
      }));

var Lazy = /* module */[/* make */make];

export {
  Lazy ,

}
/*  Not a pure module */

Happy to include a PR with derived documentation, if you think it helpful, and I'd love any suggestions on how to use less boilerplate.

After some iteration I realized there are some helpers to more idiomatically generate the code I was writing manually above.
Now my files take the form:
module type T = {
<EMAIL_ADDRESS>  let make: (~name: string) => React.element;
};

<EMAIL_ADDRESS>external component: (module T) = "undefined";

module Lazy: T = {
  include (val component);
  /* make sure your component is a default export! */
  let make =
    ReLoadable.lazy_(() => DynamicImport.import("@internal/a-component"));
};

Which begs the question:  How does one write their own [bs.XXXX] annotation (macro? not great with the terminology yet).

Hi.
From what I see, this concerns JSX v3.
Feel free to make a pull request for documentation update 👍  .
I will work on a similar pattern for JSX v2 component (import non-ReasonReact component).
About macro, i think you can't write your own [@bs] macro (bound to compiler ?). Hard to find info on this :/ . Maybe PPX (bound to user ?) will fit your use case : https://github.com/shrynx/awesome-ppx-reasonml

Yeah, I'll put the ppx idea on a shelf for now,  It seems like PPX are a
bit discouraged by the reason docs.  Docs PR when I get a minute.
On Thu, Jun 13, 2019, 2:17 PM Meillet Robin<EMAIL_ADDRESS>wrote:

Hi.
From what I see, this concerns JSX v3.
Feel free to make a pull request for documentation update 👍 .
I will work on a similar pattern for JSX v2 component (import
non-ReasonReact component).
About macro, i think you can't write your own [@bs https://github.com/bs]
macro (bound to compiler ?). Hard to find info on this :/ . Maybe PPX
(bound to user ?) will fit your use case :
https://github.com/shrynx/awesome-ppx-reasonml
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kMeillet/reason-loadable/issues/79?email_source=notifications&email_token=AATQYQ5UN243K5ZD7ZUJAKTP2KMLFA5CNFSM4HX3EZD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXUYIQI#issuecomment-501843009,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATQYQ46OQRHO3LE7L2BN6LP2KMLFANCNFSM4HX3EZDQ
.

I wrote the documentation about this problem, if you think you have to add more information do not hesitate to do a PR.
https://github.com/kMeillet/reason-loadable/commit/5d232510c633c34c4a28b01b3eca953096376f01

Thanks! Sorry I forgot about this.


Rescaling image from 0..1 to -1..1

Is it possible to modify the code so the normalized pixels are in range -1..1?
I started to do it myself, but then stopped at
def rgb2ycbcr(img, only_y=True):
    '''same as matlab rgb2ycbcr
    only_y: only return Y channel
    Input:
        uint8, [0, 255]
        float, [0, 1]
    '''

won't it ruin the logic of the transformations?

Hi @t-martyniuk
It is better to rescale the images after converting to torch tensor, i.e., performing it after these lines:
https://github.com/xinntao/BasicSR/blob/71635757505ef113bfba029441a4e35e59994a86/codes/data/LRHR_dataset.py#L120-L121

should I substitute the line 66 in codes/utils/util.py as well? (function tensor2img)
       img_np = (img_np * 255.0).round()
to
       img_np = ((img_np + 1.) * 255.0 / 2.).round()

@t-martyniuk
You can set the argument min_max=(-1, 1) in
https://github.com/xinntao/BasicSR/blob/71635757505ef113bfba029441a4e35e59994a86/codes/utils/util.py#L44-L51

ok, thank you very much
in the end, I changed only

min_max parameter to (-1, 1) in tensor2img function
added
       img_HR = 2 * img_HR - 1
after  img_HR = torch.from_numpy(np.ascontiguousarray(np.transpose(img_HR, (2, 0, 1)))).float()
(the same for img_LR) in LRHR_dataset.py
(and in LR_dataset.py as well)

thank you for assistance!


UI/UX Improvements

@cweijan I think we need newer node version on the CI.
https://tailwindcss.com/docs/upgrading-to-v2#upgrade-to-node-js-12-13-or-higher


Golint issues and CI

Issues reported by golint, excluding missing documentation.
u@x61s ~/g/s/z/sound> golint ./... | grep -v "exported"
cae.go:20:5: error var ChannelAlignmentError should have name of the form ErrFoo
duplex.go:37:5: error var FrameAlignmentError should have name of the form ErrFoo
duplex.go:37:38: error strings should not be capitalized or end with punctuation or a newline
freq/i.go:25:9: if block ends with a return statement, so drop this else and outdent its block
freq/t.go:41:10: if block ends with a return statement, so drop this else and outdent its block
freq/t.go:139:1: receiver name s should be consistent with previous receiver name f for T
ops/copy.go:26:21: error strings should not be capitalized or end with punctuation or a newline
ops/join.go:75:26: error strings should not be capitalized or end with punctuation or a newline
ops/mix.go:15:26: error strings should not be capitalized or end with punctuation or a newline

Preferably, Travis-CI could be configured for each project to do these checks, and others.
For an example configuration file, see https://github.com/mewmew/mips/blob/master/.travis.yml which handles:

build status
test case status
race detection status
golint status
code coverage update via Coveralls
GolangCI metalinter status
CodeClimate status

Yes, all this is being worked on, CI needs to be set up.  It's a bit trickier to do than other projects I'm aware of for the sio to run tests (any ideas there?)
I haven't used CodeClimate before, and it looks commercial to me.  We will add at least builds, tests, race where appropriate.  The others are more cosmetic and I've no experience with CodeClimate to get a feel of what it's worth,  so let's wait a bit for them to see.

Yes, all this is being worked on, CI needs to be set up. It's a bit trickier to do than other projects I'm aware of for the sio to run tests (any ideas there?)

Running the tests on Linux should be rather straight forward on Travis CI. Just apt-get the alsa dependencies if needed, and then go test as usual. For an example on installing dependencies on Travis, see https://github.com/mewspring/e/blob/master/.travis.yml
With regards to testing on Mac, I can't offer any help. Sorry.

I haven't used CodeClimate before, and it looks commercial to me. We will add at least builds, tests, race where appropriate. The others are more cosmetic and I've no experience with CodeClimate to get a feel of what it's worth, so let's wait a bit for them to see.

Haha., yeah. Skip CodeClimate. It definitely feels commercial. I only recently tried using it, and it did report some places in the code that could be cleaned up. But GolangCI metalinter is good too, and open source for that matter.
What I'd recommend is:

build status: go install
test status: go test
test coverage: Coveralls.io (also drone.io and others, drone required more permissions on GitHub so I decided to use Coveralls for my personal projects.)
race detection: go test -race, especially since sound.Pipe permits concurrent use.
golint; and GolangCI metalinter.

For a quick howto on using adding Coveralls test coverage for Travis CI: see https://github.com/decomp/decomp/issues/4#issuecomment-62314749

Thanks for the pointers
For questions regarding testing sio, I was referring the to the output being actually listened to and sound actually generated for capture.  I have no idea how cloud CI might do that.  I am not sure what sound devices ALSA will find either.

For questions regarding testing sio, I was referring the to the output being actually listened to and sound actually generated for capture. I have no idea how cloud CI might do that. I am not sure what sound devices ALSA will find either.

Haha, yeah. That is a good point, seems quite difficult to test audio output; as if you emulate the output device, then perhaps the emulator works but the drivers (or libraries) for the real hardware doesn't.
Sorry for the misunderstanding :)

Closing as at least basic travis-ci is set up and lint cleanups incorporated. We can refine the CI over time.

Sounds good.


Few Problems related to INC2004642

User was able to submit request without a PI or Access type.
I was able to do it without a PI on test with a create account.
This was for: Add Account To Group
But... Looking at the group for that account, it is {
"uid": 1359144,
"gid": 1359144,
"groups": [
"ecl243grp"
],
"shell": "/bin/bash",
"ensure": "present",
"storage": {
"zfs": false,
"autofs": {
"nas": "nas-12-3",
"path": "/nas-12-3/adamgrp/5/"
}
}
}
Account email starts with tburnha
And that group isn't in the DB

Group ecl243grp doesn't have any sponsors, so it's not supposed to be synced to Hippo.

PI was a field requested by only one cluster. To avoid cluster-specific customization, we made that an optional input. Should we instead make it required for all clusters or add another cluster configuration option?
As currently structured, it wouldn't make sense to have Access Type as an option when adding an account to another group. Access Type is account-specific in Hippo, not group-specific. Is that wrong?
Another problem with Access Type is that it's not synced from Puppet, and I'm not sure if there is an obvious way to do that. Until that's possible the only thing we could do is pull AccessType from QueuedEvent once it is marked as completed, just like we do with SshKey. But that still leaves us with the problem of having no AccessType info for accounts that were created outside of Hippo.


Expose TestUtil.withoutJavaLogging

Extract this workaround from ScaldingJobSpec into TestUtil, so that other projects can use it.

Pointless because (I just realised) TestUtil is not published in any artifacts.
Leaving this open as a reminder to submit a PR to thermometer instead.

Actually, in its current state I don't think this is suitable for inclusion in thermometer. It needs more work to figure out how to suppress just the parquet logs, rather than everything. (c.f. https://github.com/Parquet/parquet-mr/issues/425)


Added Softmax GAN

The paper came out today (4/20).

It's hard to stay updated! Thanks for the addition :D


Incorporate documentation sprint into master

+1 -- this documentation is a big step forward, and while it's not perfect, having it all in master will avoid drift and will make it easy to make incremental improvements. Thank you @reece .
Note to reviewers: you can ignore the diffs in doc/src/schemas/*.rst, since those are all auto-generated from .avdl files. We hope to get rid of the need to check them in at all when we switch to proto.

Is there a link to the current output? It would be nice to have a quick look before voting.

@jeromekelleher I should have noted that in the PR. Yes, built here: http://ga4gh-schemas.readthedocs.org/en/documentation/.
0cbc2e8c in the docs footer is the commit hash of the documentation branch head at https://github.com/ga4gh/schemas/tree/documentation.

Wow, this is awesome!
+1e6

+1 this is fantatstic

+1 - great work all. FYI, I'm happy to merge this topic branch as is - squishing it down to a single commit may require something like this:
http://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit
and I'm not sure that's necessary here - but please chime in if you want to see a squish like this happen.

This looks like +4.
@diekhans, I think we're waiting to hear whether you feel strongly about squishing or not. If not, we merge immediately. If so, I think Maciej volunteered to be the squisher.

Reece Hart<EMAIL_ADDRESS>writes:

This looks like +4.
@diekhans, I think we're waiting to hear whether you feel strongly about
squishing or not. If not, we merge immediately. If so, I think Maciej
volunteered to be the squisher.
—
Reply to this email directly or view it on GitHub.*

I don't think squashing is appropriate here --- we'd lose the contributions from a whole bunch of different people. The history is a little messy, but that's the nature of doc updates.
I say we merge as-is.

Went with the no squish route after talking it over further with Mark. Lots and lots of thanks again to all the people involved in the documentation sprint!

On Wed, Nov 25, 2015 at 12:11 PM, Maciek Smuga-Otto <
<EMAIL_ADDRESS>wrote:

Went with the no squish route after talking it over further with Mark.
Lots and lots of thanks again to all the people involved in the
documentation sprint!

Yippee! Great to have this in!  Thanks everyone!

Awesome! Thank you everyone. Looks like the documentation branch is ready to retire -- who wants to do the honors?

On Fri, Nov 27, 2015 at 5:34 AM, David Glazer<EMAIL_ADDRESS>wrote:

Awesome! Thank you everyone. Looks like the documentation branch is ready
to retire -- who wants to do the honors?

There are five outstanding PRs against the documentation branch that we
should resolve before closing:
https://github.com/ga4gh/schemas/pulls?q=is%3Aopen+label%3ADocumentation+is%3Apr
Anyone know the status of these?

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Update documentation branch  https://github.com/ga4gh/schemas/pull/456
https://github.com/ga4gh/schemas/pull/456#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
#456 opened 21 days ago by wbrockman
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Awbrockman

18 <https://github.com/ga4gh/schemas/pull/456>

+1

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Draft release notes for version 0.6.
https://github.com/ga4gh/schemas/pull/449
https://github.com/ga4gh/schemas/pull/449#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#449 opened 24 days ago by hjellinek
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Ahjellinek

9 <https://github.com/ga4gh/schemas/pull/449>

+1

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Initial commit of RNA API design documentation
https://github.com/ga4gh/schemas/pull/435
https://github.com/ga4gh/schemas/pull/435#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#435 opened on Oct 7 by saupchurch
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Asaupchurch

0 <https://github.com/ga4gh/schemas/pull/435>

+1

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
First draft of a streaming protocol specification for the GA4GH API
https://github.com/ga4gh/schemas/pull/431
https://github.com/ga4gh/schemas/pull/431#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#431 opened on Sep 30 by diekhans
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Adiekhans

22 <https://github.com/ga4gh/schemas/pull/431>

+1

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Added descriptions of error conditions
https://github.com/ga4gh/schemas/pull/422
https://github.com/ga4gh/schemas/pull/422#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#422 opened on Sep 22 by hjellinek
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Ahjellinek

9 <https://github.com/ga4gh/schemas/pull/422>

+1

documentation branch removed
David Glazer<EMAIL_ADDRESS>writes:

Awesome! Thank you everyone. Looks like the documentation branch is ready to
retire -- who wants to do the honors?
—
Reply to this email directly or view it on GitHub.*

Opps, I deleted too soon.
However, documentation label doesn't mean documentation branch.
There are RNA one was just for review

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Update documentation branch  https://github.com/ga4gh/schemas/pull/456
https://github.com/ga4gh/schemas/pull/456#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
#456 opened 21 days ago by wbrockman
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Awbrockman

18 <https://github.com/ga4gh/schemas/pull/456>

+1

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Draft release notes for version 0.6.
https://github.com/ga4gh/schemas/pull/449
https://github.com/ga4gh/schemas/pull/449#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#449 opened 24 days ago by hjellinek
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Ahjellinek

9 <https://github.com/ga4gh/schemas/pull/449>

+1

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Initial commit of RNA API design documentation
https://github.com/ga4gh/schemas/pull/435
https://github.com/ga4gh/schemas/pull/435#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#435 opened on Oct 7 by saupchurch
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Asaupchurch

0 <https://github.com/ga4gh/schemas/pull/435>

+1

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
First draft of a streaming protocol specification for the GA4GH API
https://github.com/ga4gh/schemas/pull/431
https://github.com/ga4gh/schemas/pull/431#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#431 opened on Sep 30 by diekhans
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Adiekhans

22 <https://github.com/ga4gh/schemas/pull/431>

+1

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Added descriptions of error conditions
https://github.com/ga4gh/schemas/pull/422
https://github.com/ga4gh/schemas/pull/422#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#422 opened on Sep 22 by hjellinek
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Ahjellinek

9 <https://github.com/ga4gh/schemas/pull/422>

+1

Reply to this email directly or view it on GitHub:
https://github.com/ga4gh/schemas/pull/504#issuecomment-160175016

On Fri, Nov 27, 2015 at 5:34 AM, David Glazer<EMAIL_ADDRESS>wrote:

Awesome! Thank you everyone. Looks like the documentation branch is ready
to retire -- who wants to do the honors?

There are five outstanding PRs against the documentation branch that we
should resolve before closing:
https://github.com/ga4gh/schemas/pulls?q=
is%3Aopen+label%3ADocumentation+is%3Apr
Anyone know the status of these?

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Update documentation branch https://github.com/ga4gh/schemas/pull/456
https://github.com/ga4gh/schemas/pull/456#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
#456 opened 21 days ago by wbrockman
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Awbrockman
18 https://github.com/ga4gh/schemas/pull/456
+1
** this is the is it ReST discussion; there was never any resolution as to `why' it isn't ReST.

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Draft release notes for version 0.6.
https://github.com/ga4gh/schemas/pull/449
https://github.com/ga4gh/schemas/pull/449#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#449 opened 24 days ago by hjellinek
<https://github.com/ga4gh/schemas/issues?q=
is%3Apr+is%3Aopen+author%3Ahjellinek>
9 https://github.com/ga4gh/schemas/pull/449
+1
*** this is not against documentation branch

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Initial commit of RNA API design documentation
https://github.com/ga4gh/schemas/pull/435
https://github.com/ga4gh/schemas/pull/435#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#435 opened on Oct 7 by saupchurch
<https://github.com/ga4gh/schemas/issues?q=
is%3Apr+is%3Aopen+author%3Asaupchurch>
0 https://github.com/ga4gh/schemas/pull/435
+1
** PR is only for review

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
First draft of a streaming protocol specification for the GA4GH API
https://github.com/ga4gh/schemas/pull/431
https://github.com/ga4gh/schemas/pull/431#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#431 opened on Sep 30 by diekhans
https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen+author%3Adiekhans
22 https://github.com/ga4gh/schemas/pull/431
+1
*** PR only for review, not against documentation branch

https://github.com/ga4gh/schemas/issues?q=is%3Apr+is%3Aopen
Added descriptions of error conditions
https://github.com/ga4gh/schemas/pull/422
https://github.com/ga4gh/schemas/pull/422#partial-pull-merging
Documentation
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3ADocumentation
in progress
https://github.com/ga4gh/schemas/issues?q=is%3Aopen+label%3A"in+progress"
#422 opened on Sep 22 by hjellinek
<https://github.com/ga4gh/schemas/issues?q=
is%3Apr+is%3Aopen+author%3Ahjellinek>
9 https://github.com/ga4gh/schemas/pull/422
+1
*** this we should merge into master.

Actually, I don't think
https://github.com/ga4gh/schemas/pull/422 is ready to merge
either.  Issues with HTTP codes that need resolved.
We should create tickets to continue working on this (although there
might be some already)


:technologist:x.x.x: Fix qualityCheck of script

Codecov Report

Merging #54 (2c69a33) into main (25d2755) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.
@@            Coverage Diff            @@
##              main       #54   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           16        16
  Lines           96        96
  Branches         3         3
=========================================
  Hits            96        96

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Add 'String() string' to Pattern

I added a String() string method to Pattern so you can use c.Env[web.MatchKey].(web.Match).Pattern.String() to get the human-representation of a route, which you can use for debugging.
This is similar to mux.CurrentRoute(req).GetName() with gorilla.Mux.

All built-in patterns support fmt.Stringer already, and I'm very reluctant to add extra compatibility-breaking methods to the public API here. Are you having difficulty placing patterns into fmt-like loggers? Could you accomplish this same thing with an (admittedly ugly) type assertion? (I'd recommend the fmt option though, especially for debugging)

That's valid, thanks for the quick response!