[Question] How to make reaction faster?

I love the package but the background jobs are being process after the view is being send to the frontend which makes it very strange for the user.
So if we have a website with posts. Each post have love and hate reaction. If the user clicks to add a new reaction because this reactions are processed in the background the user needs to wait few seconds which is not possible in some cases or not good.
@cybercog Can you explain how to deal with this?
The easiest way is to specify queue which to process this reactions.

It is a good question, @vlados!
You can create the endpoint POST /reactions which will be responsible for reacting to the reactables.
If there is no exception raised from reactTo method - then you can return 201 Created status code and instantly increment counter on the frontend. In other cases don't increment counter but display error if there is a need.
If QUEUE_CONNECTION is defined in .env file - counters & totals will be updated on background. More details about it could be found in Aggregation Queue section of the documentation.

One more possible way:
Add listener which will await for Cog\Laravel\Love\Reaction\Events\ReactionHasBeenAdded event and will dispatch broadcasting event via websockets. Then your users will receive changes in realtime.
And await for Cog\Laravel\Love\Reaction\Events\ReactionHasBeenRemoved event when you want to broadcast reaction removal.

Yes, so basically to fake it on the frontend until is done on the backend and with websockets to update it when is done.
I was thinking something like that but I wanted to ask if there is more cleaver way to do it

If you will update counter on response with 2xx status code it's not a fake really. Unless there is no exception thrown you may be sure that reaction was added or removed successfully. You just can't say that nobody else added or removed reaction between your click and getting response.

I'm closing this issue. Feel free to continue conversation here if you'll find more optimal approach or there is anything missing in this thread.

Well done, a nice implementation.
I was wondering, how can I access the reaction data in my event handler? It's throwing the following error:
Cannot access private property Cog\Laravel\Love\Reaction\Events\ReactionHasBeenRemoved::$reaction

@jtomek Have you tried $event->getReaction() method?

So I updated from v5 to v8 today. It's brilliant from the logic perspective. But so so hard to use ...
Do I really have to do this to get likes and dislikes from an event?
$interactions = [
      'likes' => $event->getReaction()->getReactant()->getReactable()->viaLoveReactant()->getReactionCounterOfType('Like')->getCount(),
      'dislikes' => $event->getReaction()->getReactant()->getReactable()->viaLoveReactant()->getReactionCounterOfType('Dislike')->getCount()
    ];

Usually I'm firing broadcasting events and intercepting them on frontend to increment\decrement counters.
If you really need to have aggregated values your code could be optimized a bit:
$event->getReaction()->getReactant()->getReactionCounterOfType(ReactionType::fromName('Like'))->getCount(),

Thank you. I didn't think of intercepting single events. Maybe that's easier. I'll look into it.
I have also encountered another problem with events, can you please help?
I implemented a custom toggle logic based on your suggestion in https://github.com/cybercog/laravel-love/issues/117.
$userReactrer = auth()->user()->viaLoveReacter();

if ($request->type === 'like') {

    // Remove own dislike
    if ($userReactrer->hasReactedTo($model, 'Dislike')) {
        $userReactrer->unreactTo($model, 'Dislike');
    }
    if ($userReactrer->hasReactedTo($model, 'Like')) {
        $userReactrer->unreactTo($model, 'Like');
    } else {
        $userReactrer->reactTo($model, 'Like');
    }
} else {

    // Remove own like
    if ($userReactrer->hasReactedTo($model, 'Like')) {
        $userReactrer->unreactTo($model, 'Like');
    }
    if ($userReactrer->hasReactedTo($model, 'Dislike')) {
        $userReactrer->unreactTo($model, 'Dislike');
    } else {
        $userReactrer->reactTo($model, 'Dislike');
    }
};

This is firing two events. Although on the background, it's working great; my problem is that it's not counting the totals in my events right. I'm getting weird numbers, sometimes it even increases the wrong reaction type.
I thought of delaying it could help, but am not sure how to implement it. Or maybe I need to be more cleaver on the frontend.
Could you please help?

Yeah, it looks right, because counters recounting is starting on background after ReactionHasBeenAdded & ReactionHasBeenRemoved events dispatch. If you will do it instantly - it will be too "expensive" operation.
You could ignore persisted counters and compute those values manually inside of the controller, but it will work only for small projects.
If there is an ability to use broadcasting events - you'd better use them instead of relying on counters. Counters are required to quick load initial data.


docs/blankslate.md: grammar: remove errant word

Howdy—thanks for the pull request, @cvrebert!
Before we can merge your changes, we need you to review our Contributor License Agreement (CLA). We think of CLAs as an open source software license between you and the project, letting us and other users know that we have permission to use the code you contribute.
At the bottom of the pull request, you'll see the note about a failed test. Just click the Details link, review the CLA, and sign off at the bottom.
Questions? Just holler—I'm here to help :).
<3

@mdo Ah, it's like back in the day with Bootstrap's haunt script. :laughing:
I accepted the CLA.

:D


Evaluation of YOLOX with eval_script

This issue has two parts. For the first I propose a solution but include it here incase my proposed solution effects part 2.

Error in eval script when using anchor free mode.
Bad/erroneous results from evaluation

Part 1
When running the eval_func.py with the --use_anchor_free_mode flag the following error is raised.
>>>> Using anchor_free_mode decode_predictions: {'aspect_ratios': [1], 'num_scales': 1, 'anchor_scale': 1, 'grid_zero_start': True}
Traceback (most recent call last):
  File "./eval_script.py", line 154, in <module>
    run_coco_evaluation(
  File "/home/lookdeep/gits/keras_cv_attention_models/keras_cv_attention_models/coco/eval_func.py", line 216, in run_coco_evaluation
    pred_decoder = DecodePredictions(input_shape, pyramid_levels, **ANCHORS, use_object_scores=use_anchor_free_mode)
TypeError: __init__() got an unexpected keyword argument 'aspect_ratios'

The issue lies in DecodePredictions (keras_cv_attention_models/blob/main/keras_cv_attention_models/coco/eval_func.py#L27) whereby anchor-free keyword arguments are not specified.
Can be fixed with
diff --git a/keras_cv_attention_models/coco/eval_func.py b/keras_cv_attention_models/coco/eval_func.py
index faafb7a..414e3ee 100644
--- a/keras_cv_attention_models/coco/eval_func.py
+++ b/keras_cv_attention_models/coco/eval_func.py
@@ -24,7 +24,7 @@ class DecodePredictions:
     >>> # bboxes = array([[0.433231  , 0.54432285, 0.8778939 , 0.8187578 ]], dtype=float32), labels = array([17]), scores = array([0.85373735], dtype=float32)
     """

-    def __init__(self, input_shape=512, pyramid_levels=[3, 7], anchor_scale=4, use_anchor_free_mode=False, use_object_scores="auto", aspect_ratios=[1], num_scales=1, grid_zero_start=True):
+    def __init__(self, input_shape=512, pyramid_levels=[3, 7], anchor_scale=4, use_anchor_free_mode=False, use_object_scores="auto"):
         self.pyramid_levels = list(range(min(pyramid_levels), max(pyramid_levels) + 1))
         self.use_object_scores = use_anchor_free_mode if use_object_scores == "auto" else use_object_scores
         if use_anchor_free_mode:

Part 2
When attempting to evaluate yolox_s_coco.h5 I get poor results which don't line up with inference results. E.g.
CUDA_VISIBLE_DEVICES='0' python ./eval_script.py -d coco -m $HOME/.keras/models/yolox_s_coco.h5 --use_anchor_free_mode
... [stderr excluded]
>>>> COCO evaluation: coco/2017 - anchors: {'pyramid_levels': [3, 5], 'use_anchor_free_mode': True}
>>>> Using input_shape (640, 640) for Keras model.
>>>> rescale_mode: torch
>>>> Using anchor_free_mode decode_predictions: {'aspect_ratios': [1], 'num_scales': 1, 'anchor_scale': 1, 'grid_zero_start': True}
... [stderr excluded]
loading annotations into memory...
Done (t=0.82s)
creating index...
index created!
Loading and preparing results...
Converting ndarray to lists...
(195236, 7)
0/195236
DONE (t=1.39s)
creating index...
index created!
Running per image evaluation...
Evaluate annotation type *bbox*
DONE (t=23.52s).
Accumulating evaluation results...
DONE (t=3.52s).
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.000
 Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.000
 Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.000
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.000
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.000
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.000
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.000
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.000
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.000
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.000
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.000
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.001

Part 1 Ya, it's used to be an issue, fixed 11 days ago update coco training usage. :)
Part 2 Currently eval_script.py for coco is specifically set default behavior for matching efficientdet results. I need some tests for yolox / yolor evaluation method and fix it. May be related with the default nms_method / nms_mode / nms_topk listed in coco#evaluation.CUDA_VISIBLE_DEVICES='1' ./eval_script.py -m yolox.YOLOXTiny -d coco --use_anchor_free_mode
# Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.261
# Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.398
# Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.279
# Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.112
# Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.284
# Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.405
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.241
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.388
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.413
# Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.196
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.456
# Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.604

This is a result testing YOLOR_CSP, which is also lower than official reported:
CUDA_VISIBLE_DEVICES='1' ./eval_script.py -m yolor.YOLOR_CSP -d coco --batch_size 2
#  Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.444
#  Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.610
#  Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.483
#  Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.301
#  Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.490
#  Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.566
#  Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.327
#  Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.543
#  Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.586
#  Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.422
#  Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.628
#  Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.711

I don't think it's related with model structure or converted weights though, as it's verified using np.allclose: yolor verification-with-pytorch-version and yolox verification-with-pytorch-version.
Maybe related with image shape scale method or NMS? Not sure. Currently have to add a note in readme.
Have you ever tested yolox model using official pytorch version?

With above 2 commits, yolox evaluation is working correct now. That it's using BGR input format... YOLOXS results also updated in coco#evaluation
CUDA_VISIBLE_DEVICES='1' ./coco_eval_script.py -m yolox.YOLOXTiny --nms_method hard --nms_iou_or_sigma 0.65 --use_bgr_input --use_anchor_free_mode
 # Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.329
 # Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.504
 # Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.349
 # Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.138
 # Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.360
 # Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.499
 # Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.287
 # Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.458
 # Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.486
 # Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.230
 # Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.549
 # Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.692

But yolor still not right, I think maybe realted with its letterbox function, still trying.
CUDA_VISIBLE_DEVICES='1' ./coco_eval_script.py -m yolor.YOLOR_CSP --nms_method hard --nms_iou_or_sigma 0.65 --use_yolor_anchors_mode
# Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.488
# Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.674
# Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.530
# Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.324
# Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.539
# Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.627
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.365
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.592
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.634
# Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.447
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.684
# Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.779

YOLOR evaluation finaly fixed:
CUDA_VISIBLE_DEVICES='1' ./coco_eval_script.py -m yolor.YOLOR_CSP --use_yolor_anchors_mode --nms_method hard --nms_iou_or_sigma 0.65 \
--nms_max_output_size 300 --nms_topk -1 --letterbox_pad 64 --input_shape 704
# Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.500
# Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.686
# Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.544
# Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.340
# Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.551
# Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.643
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.380
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.627
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.683
# Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.529
# Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.735
# Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.817

More compare results can be found coco#evaluation


On stop service [upstart], send TERM sig

After some tinkering, it seems as though on service stop - if you have consul_leave_on_terminate set to true, this is ignored as the service consul stop command sends signal 1, not TERM like consul expects for that config to work.
Additionally, if you attempt to do a consul leave, the agent dies and then upstart attempts to kick it on again, which causes it to rejoin the cluster.  This is not desired (afaik).  This pull request doesnt fix that, however it does allow you to just stop the service and have it leave the cluster cleanly.
I've tested both cases - with consul_leave_on_terminate  on and off.  The behavior seems to work as intended now.  However I'm not sure of the downstream impacts of this so could use your input if you have any.

Realized that the term was default, modified to actually perform a pre-stop action to leave the cluster first.

Thanks!


Import-Package is no longer populated with version numbers with bnd

Expected Behavior
Gradle continues to generate manifest in the same way as 8.1
Current Behavior
Gradle generates jar manifest without version numbers
Context (optional)
No response
Steps to Reproduce
https://github.com/bndtools/bnd/issues/5695
Gradle version
8.2-rc-2
Gradle version that used to work
8.1
Build scan URL (optional)
https://ge.junit.org/s/4etbacry2q3fo/failure#1
Your Environment (optional)
No response

We accepted the change in behavior as explained here.
We're now deferring/avoiding certain configuration that happened incidentally to creating root component metadata. The old behavior was dependent on several things:

iteration order of the configurations in a project
an artifact created by a task
lazy configuration of that task
configuration in the task changing another configuration's attributes


Gas Schedule DGP implementation (Qtum Core / QTUMCORE-60)

Created a new qtum genesis files.
Added qtumMainNetwork.
Created class QtumDGP.
Implemented QtumDGP to qtum.

@designsters Can you rebase this so that it can be merged into master soon?

Please fix this warning:
qtum/qtumDGP.cpp:112:33: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        schedule.tierStepGas = {uint32Values[0], uint32Values[1], uint32Values[2], uint32Values[3],
                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

also these:
test/qtumtests/dgp_tests.cpp:276:71: warning: suggest braces around initialization of subobject [-Wmissing-braces]
EVMScheduleCustom EVMScheduleContractGasSchedule(true,true,true,true,{10,10,10,10,10,10,10,10},10,50,30,6,200,20000,5000,15000,
                                                                      ^~~~~~~~~~~~~~~~~~~~~~~
                                                                      {                      }
test/qtumtests/dgp_tests.cpp:278:72: warning: suggest braces around initialization of subobject [-Wmissing-braces]
EVMScheduleCustom EVMScheduleContractGasSchedule2(true,true,true,true,{13,10,10,10,10,10,10,10},10,50,30,6,200,20000,5000,15000,
                                                                       ^~~~~~~~~~~~~~~~~~~~~~~
                                                                       {                      }
test/qtumtests/dgp_tests.cpp:280:72: warning: suggest braces around initialization of subobject [-Wmissing-braces]
EVMScheduleCustom EVMScheduleContractGasSchedule3(true,true,true,true,{13,13,10,10,10,10,10,10},10,50,30,6,200,20000,5000,15000,
                                                                       ^~~~~~~~~~~~~~~~~~~~~~~
                                                                       {                      }
test/qtumtests/dgp_tests.cpp:350:16: warning: comparison of constant 569 with expression of type 'bool' is always false [-Wtautological-constant-out-of-range-compare]
    if(618 > i > 569)
       ~~~~~~~ ^ ~~~
test/qtumtests/dgp_tests.cpp:352:16: warning: comparison of constant 518 with expression of type 'bool' is always false [-Wtautological-constant-out-of-range-compare]
    if(568 > i > 518)
       ~~~~~~~ ^ ~~~
test/qtumtests/dgp_tests.cpp:354:16: warning: comparison of constant 502 with expression of type 'bool' is always false [-Wtautological-constant-out-of-range-compare]
    if(518 > i > 502) // After initializing the tests, the height of the chain 502
       ~~~~~~~ ^ ~~~

@designsters please also update MAX_BLOCK_SERIALIZED_SIZE and the MAX_PROTOCOL_MESSAGE_LENGTH


We need a way (other than animated GIFs) to show motion on the website

I am documenting animations, so it makes sense to show what the motion looks like in some of the relevant docs.
 I can't scroll them off the screen fast enough. This is not ideal for technical documentation. (I've asked some engineers around here who feel the same way.)
Tao suggested the approach that Material Design uses, which involves JavaScript, I believe. They have a play/pause button that overlays the area.
So, what say you? If we want this sort of feature, I'll need someone to implement it. Or should we display two images - before and after?
I'm open to suggestions! In the short term, I'll stick with images.

What are your requirements? Sounds like:

Ability for the reader to play/pause.
No auto-play. (See above)

Anything else?

Features nice to have from an email discussion:

When the video is paused, show the still image instead of the player control overlay on https://material.io/guidelines/motion/transforming-material.html#transforming-material-radial-transformation
Allow the user to scrub the video
Allow the user to play the video at a slower speed

I wonder if the standard HTML5 video tag can satisfy our needs? https://www.html5rocks.com/en/tutorials/video/basics/

Here is how you can move to arbitrary points in the video (presumably how to move one frame at a time): https://stackoverflow.com/questions/20336955/how-to-step-one-frame-forward-and-one-frame-backward-in-video-playback

This is the behavior that @Hixie suggested:

I would prefer if videos played once when they came fully on screen, then paused until clicked again, at which point they'd play. With a play/pause button and scrub control that showed at the bottom while the mouse was over the image but not otherwise.

@Sfshaza if you can create a single list of requirements that you're looking for, I think we can help you out. :) thanks!

I talked to @sethladd in person, but want to close the loop. For now, I'm using a video that I upload to youtube. I don't love the fact that youtube displays the video in landscape mode, but it works for now. This would be nice to have in the long term, though.

To follow up. Tao suggested that I append "&rel=0" to the URL to suppress the ads shown at the end of the video. I tried that both with a Flutter doc, and with my personal website. In each case, it broke the video.

Issue moved to flutter/website #1841 via ZenHub


Restarting relies on order of environment variables

In the CloudFormation backend, a successful restart relies on environment variables being re-ordered. Instead, we should be able to update a param to trigger a restart of a service.
I think we can do this in two steps:

Change the backend to sort environment variables, then add a Docker label whose value is based on a "Restart" parameter. Changing this value will trigger a new task definition to be created, which will trigger a service restart.
Add a Restart and RestartProcess method to the Scheduler interface that updates these parameters, instead of perform a full Submit.

I've noticed that tests in ./scheduler/cloudformation/template_test.go fail intermittently because of this issue too.

This was fixed in https://github.com/remind101/empire/pull/850


[EGP] Parent chain lag

Hopefully unrelated to #2247 but making a chain of parented objects seems to also lag significantly
Code to reproduce (wire to EGP):
@name ParentLag
@inputs EGP:wirelink
@persist GenID
interval(10)
if(first()|dupefinished())
{
    GenID = 1
}
if(GenID < 512)
{
    EGP:egpBox(GenID, vec2(1, 1), vec2(1, 1))
    EGP:egpSize(GenID, 2)
    EGP:egpParent(GenID, GenID - 1)
    GenID++
}
EGP:egpPos(1, vec2(256, 256) + vec2(sin(curtime() * 32) * 128, sin(curtime() * 42) * 128))

I don't think this is a bug. You'll just need to administrate anyone who does this abusively.


When merging symbols, prefer definitions in files found in compile_commands.json

early_chip_init() function is defined in both files with the same name chip_customization.c, and  two files Store in a different directory aaa and bbb
When click the function early_chip_init()  in bootloader.c to jump to definition, it will jump into a file that is not in the jason database, expecting to jump into AAA but actually jumping into BBB. It only happens if BBB is opened on once ; The Issue is the same whether BBB is opened on before or after AAA
If never opened BBB, can jump to AAA correctly
Logs
ASTWorker building file /boot/bootloader/customization/aaa/chip_customization.c version 1 with command inferred from customization/bbb/chip_customization.c
[/........./boot/bootloader]
System information
ubuntu 20.04 server and windows Visual Studio Code version 1.75
Output of clangd --version:
.vscode-server/data/User/globalStorage/llvm-vs-code-extensions.vscode-clangd/install/15.0.6/clangd_15.0.6/lib/clang/15.0.6
Editor/LSP plugin:
clangd
v0.1.23
LLVM
C/C++ completion, navigation, and insights
Operating system: windows 10

I guess this is a consequence of https://github.com/clangd/clangd/issues/1258

Ok this is related to #1258 and I fully understand the explanations from @sam-mccall , but here we are not really talking about multi projects yet and I am wondering if there can be a way out?
In my use case I explicitly give the compile_commands.json path to the server (--compile-commands-dir option) so I was expecting no heuristic, especially not from files outside its scope. But still, I have the exact same behavior as describe above.
First I just wanted to confirm this is still the expected behavior?
If yes, don't you think this can be improved in this case? (either on server or vscode extension side?)

First I just wanted to confirm this is still the expected behavior? If yes, don't you think this can be improved in this case? (either on server or vscode extension side?)

It would help to have a concrete example that can be played around with locally, to reason about and try to answer these questions.

Sure, here is a basic repo to give a try
After few other trials on my side, it sounds like the issue is slightly different from what was originally stated:
"It only happens if BBB is opened on once; The issue is the same whether BBB is opened on before or after AAA"
Instead, I have:
"It only happens if BBB is opened once and AAA is never opened; No issue if both have been opened, no matter the order."
Here are some clangd logs when this happens:
...
When the server starts and<EMAIL_ADDRESS>is open
...
I[13:39:30.501] clangd version 18.1.3 (https://github.com/llvm/llvm-project c13b7485b87909fcf739f62cfa382b55407433c0)
I[13:39:30.502] Features: windows+grpc
I[13:39:30.502] PID: 32188
I[13:39:30.502] Working directory: c:\Dev\MNASTM\clangd-issue-682
I[13:39:30.502] argv[0]: c:\Users\naudmatt\AppData\Roaming\Code\User\globalStorage\llvm-vs-code-extensions.vscode-clangd\install\18.1.3\clangd_18.1.3\bin\clangd.exe
I[13:39:30.502] argv[1]: --compile-commands-dir
I[13:39:30.502] argv[2]: C:\Dev\MNASTM\clangd-issue-682\build
I[13:39:30.515] Starting LSP over stdin/stdout
I[13:39:30.565] <-- initialize(0)
I[13:39:30.570] --> reply:initialize(0) 5 ms
I[13:39:30.599] <-- initialized
I[13:39:30.614] <-- textDocument/didOpen
I[13:39:30.617] Loaded compilation database from C:\Dev\MNASTM\clangd-issue-682\build\compile_commands.json
I[13:39:30.618] <-- textDocument/documentSymbol(1)
I[13:39:30.618] ASTWorker building file<EMAIL_ADDRESS>version 1 with command inferred from<EMAIL_ADDRESS>[C:/Dev/MNASTM/clangd-issue-682/build]
"C:\\clang+llvm-18.1.6-x86_64-pc-windows-msvc\\bin\\clang.exe"<EMAIL_ADDRESS>-IC:/Dev/MNASTM/clangd-issue-682/./inc -O0 -g -Xclang -gcodeview -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -c "-resource-dir=C:\\Users\\naudmatt\\AppData\\Roaming\\Code\\User\\globalStorage\\llvm-vs-code-extensions.vscode-clangd\\install\\18.1.3\\clangd_18.1.3\\lib\\clang\\18" --<EMAIL_ADDRESS>I[13:39:30.644] --> window/workDoneProgress/create(0)
I[13:39:30.644] Enqueueing 2 commands for indexing
I[13:39:30.645] <-- textDocument/codeAction(2)
I[13:39:30.646] <-- textDocument/documentLink(3)
I[13:39:30.646] <-- textDocument/inlayHint(4)
I[13:39:30.647] <-- reply(0)
I[13:39:30.647] --> $/progress
I[13:39:30.647] --> $/progress
I[13:39:30.649] --> $/progress
I[13:39:30.649] --> $/progress
I[13:39:30.668] --> textDocument/clangd.fileStatus
I[13:39:30.693] Built preamble of size 231600 for file<EMAIL_ADDRESS>version 1 in 0.02 seconds
I[13:39:30.694] --> workspace/semanticTokens/refresh(1)
I[13:39:30.696] <-- reply(1)
I[13:39:30.702] Indexing c17 standard library in the context of<EMAIL_ADDRESS>I[13:39:30.706] <-- textDocument/semanticTokens/full(5)
....
User intereaction => open main.c
....
I[13:46:12.718] <-- textDocument/didOpen
I[13:46:12.720] ASTWorker building file c:\Dev\MNASTM\clangd-issue-682\src\main.c version 1 with command
[C:/Dev/MNASTM/clangd-issue-682/build]
"C:\\clang+llvm-18.1.6-x86_64-pc-windows-msvc\\bin\\clang.exe"<EMAIL_ADDRESS>-IC:/Dev/MNASTM/clangd-issue-682/./inc -O0 -g -Xclang -gcodeview -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -o "CMakeFiles\\app1-sw1.dir\\src\\main.c.obj" -c "-resource-dir=C:\\Users\\naudmatt\\AppData\\Roaming\\Code\\User\\globalStorage\\llvm-vs-code-extensions.vscode-clangd\\install\\18.1.3\\clangd_18.1.3\\lib\\clang\\18" -- "c:\\Dev\\MNASTM\\clangd-issue-682\\src\\main.c"
I[13:46:12.722] <-- textDocument/codeAction(21)
I[13:46:12.724] <-- textDocument/documentSymbol(22)
I[13:46:12.728] --> textDocument/clangd.fileStatus
I[13:46:12.748] Built preamble of size 231800 for file c:\Dev\MNASTM\clangd-issue-682\src\main.c version 1 in 0.02 seconds
I[13:46:12.748] --> workspace/semanticTokens/refresh(2)
I[13:46:12.749] <-- reply(2)
....
User interaction => Go to definition on div(6,3) => leads to opening the wrong file<EMAIL_ADDRESS>....
I[13:47:50.606] <-- textDocument/definition(38)
I[13:47:50.607] --> reply:textDocument/definition(38) 0 ms
I[13:47:50.607] --> textDocument/clangd.fileStatus
I[13:47:50.623] <-- textDocument/documentHighlight(39)
I[13:47:50.623] --> reply:textDocument/documentHighlight(39) 0 ms
I[13:47:50.623] --> textDocument/clangd.fileStatus
I[13:47:50.623] <-- textDocument/codeAction(40)
I[13:47:50.624] --> reply:textDocument/codeAction(40) 0 ms
I[13:47:50.624] --> textDocument/clangd.fileStatus
I[13:47:50.648] <-- textDocument/documentLink(41)
I[13:47:50.648] <-- textDocument/inlayHint(42)
I[13:47:50.648] --> reply:textDocument/documentLink(41) 0 ms
I[13:47:50.649] --> reply:textDocument/inlayHint(42) 0 ms
I[13:47:50.649] --> textDocument/clangd.fileStatus
I[13:47:50.829] <-- textDocument/foldingRange(43)
I[13:47:50.829] --> reply:textDocument/foldingRange(43) 0 ms
I[13:47:50.876] <-- textDocument/codeAction(44)
I[13:47:50.877] --> reply:textDocument/codeAction(44) 0 ms
I[13:47:50.877] --> textDocument/clangd.fileStatus
I[13:47:50.928] <-- textDocument/semanticTokens/full/delta(45)
I[13:47:50.928] <-- textDocument/documentSymbol(46)
I[13:47:50.928] --> reply:textDocument/semanticTokens/full/delta(45) 0 ms
I[13:47:50.928] --> reply:textDocument/documentSymbol(46) 0 ms
I[13:47:50.928] --> textDocument/clangd.fileStatus

I am not familiar at all with the server implementation but to me there is a heuristic issue as long as the server has the compile_commands.json information from the beginning which should allow to link the main.c to the right div.c, no matter what other files have been opened, or no matter if the right file has not yet been opened, WDYT?

Sure, here is a basic repo to give a try

Thanks, this is very helpful.
I can confirm that I see the same behaviour that you describe in the repo's README.
It's not clear to me off the top of my head what is the mechanism that gives rise to this behaviour. It will require some debugging to understand that. I will do that as time permits and follow up here.

Ok, I've debugged this a bit, and I believe I now understand how the observed behaviour arises.
As some background, clangd's symbol index has two parts:

the dynamic index, which is in-memory only, and contains symbols from files opened since clangd was started
the background index, which is persisted to disk, and contains symbols from all files that appear in compile_commands.json

When looking up a symbol in the index, it's looked up in both the dynamic index and the background index. If it's found in both places, the results are merged. During a merge, if both input symbols have a definition location (one of the properties of a symbol), the definition location from the dynamic index is retained in the resulting merged symbol.
So let's consider the scenarios from the example project README:

Scenario 1 is the simplest. The dynamic index does contain any div symbol with a definition. The background index contains the div symbol from<EMAIL_ADDRESS>(since that is the file that was present in the compile_commands.json and thus added to the background index), so the definition in<EMAIL_ADDRESS>is returned.
Scenario 2 is the same as Scenario 1; the fact that<EMAIL_ADDRESS>was opened during a previous clangd session does not matter, since the dynamic index does not persist between clangd sessions.
Next, let's look at the last ("NOK") scenario. The dynamic index contains the div symbol from<EMAIL_ADDRESS>The background index contains the div symbol from<EMAIL_ADDRESS>When the two symbols are merged, the definition location from the dynamic index<EMAIL_ADDRESS>is retained, so that's what we get.
Finally, what happens in scenarios 3 and 4? Here, the copy of the symbol in the dynamic index is itself the result of merging the two instances of the symbol that come from the two opened files. For this merge, it's a matter of luck which location wins. It ends up boiling down to the order of iterating a hashtable where the keys are the full paths of the files. It so happens that for these two filenames<EMAIL_ADDRESS>wins over<EMAIL_ADDRESS>But if I change<EMAIL_ADDRESS>to<EMAIL_ADDRESS>now<EMAIL_ADDRESS>wins consistently, and we get the "undesirable" result regardless of what order the files were opened.

So, to circle back to the original questions:

this is still the expected behavior? If yes, don't you think this can be improved in this case?

The choice to prefer the definition from the dynamic index when merging symbols does seem to be deliberate.
However, I expect it's motivated by a different scenario: one where the dynamic index contains symbols from parsing (a subset of) the same files as the background index, but the dynamic index is newer (e.g. it may reflect file changes that have not been reflected in the background index yet).
Information in the dynamic index conflicting with information in the background index because it's coming from two different files that define symbols with the same name is, I believe, not a scenario that has been designed for at all (as discussed in #1258).
So, I think there may potentially be room for enhancing the symbol merging logic with heuristics related to preferring symbols coming from files in compile_commands.json. It will require some thought in figuring out what exactly the heuristic should be, making sure it doesn't break existing dynamic index use cases, and that it can be implemented efficiently (merging symbols seems like a hot codepath).

@HighCommander4 thank you so much for such analysis !
So first if my understanding is right we can claim current behavior is related to clangd server, not vscode-clangd client: do you confirm ?
Considering, yes, some "undesirable" result do you foresee a way to get rid of with current assets ?
Myself, taking pain to promote a compile_command.json I would, first guess as quick solution, get rid of dynamic index being safe then. Any way to do such ? What could be drawback of disabling dynamic index :

performances issue ?
kind of editor reactivity loss feeling as end user having file content updated while compile_command.json is lagging behind ?
As I could understand merging symbols seems like a hot codepath I may foresee dynamic index enabling / disabling as a possible "quick & safe" first way to overcome issue. I would say as end user I prefer reliable code indexing against performances.

WDYT ?

So first if my understanding is right we can claim current behavior is related to clangd server, not vscode-clangd client: do you confirm ?

Yep.

Considering, yes, some "undesirable" result do you foresee a way to get rid of with current assets ?

Do you mean without changes to the clangd server?
There is a fork of vscode-clangd at https://github.com/eclipse-cdt-cloud/vscode-clangd which has support for using different clangd server instances for different projects (directories) in a vscode workspace.
You may be able to use that to arrange for the<EMAIL_ADDRESS>directory to use its own clangd instance. Then, opening files in that directory will populate the dynamic index of that clangd instance, and not affect in any way the main clangd instance used for main.c.

Myself, taking pain to promote a compile_command.json I would, first guess as quick solution, get rid of dynamic index being safe then. Any way to do such ? What could be drawback of disabling dynamic index :
* performances issue ?

* kind of editor reactivity loss feeling as end user having file content updated while `compile_command.json` is lagging behind ?

As I could understand merging symbols seems like a hot codepath I may foresee dynamic index enabling / disabling as a possible "quick & safe" first way to overcome issue. I would say as end user I prefer reliable code indexing against performances.
WDYT ?

Clangd relies fairly heavily on the dynamic index.
To give one notable example, it uses the dynamic index to provide code completion results even for symbols in the current translation unit (more precisely, for symbols defined in the preamble part of the current translation unit (the included headers), so that it doesn't have to do an O(n) traversal of preamble declarations via the AST).
Even if we narrow in on the go-to-definition feature specifically, clangd relies on the dynamic index for workflows such as the following:

You are writing a new source/header file pair.

The new source file is not reflected in the background index yet, either because you haven't added it to compile_commands.json yet, or because clangd hasn't picked up the change to compile_commands.json yet (it currently only picks that up on a restart).

You perform go-to-def on the declaration of a function you just wrote in the header, and expect it to go to the definition (which you also just wrote in the source file). This relies on the source file being added to the dynamic index.

So, I think that for a solution on the clangd side, rather than disabling the dynamic index altogether, we'll want to change the logic for how information from the dynamic index is combined with information from the background index.

Ok @HighCommander4 thanks one time more taking time for explanations.
I'm aware about https://github.com/eclipse-cdt-cloud/vscode-clangd so I' m getting to get an extra try based on. Possibly it may help but to be confirmed (I'll come back to you) because this fork is about vscode-clangd not clangd server. As we agree on "issue" is part of server ... my fear is despite multi projects capable it may encounter same problematic.
My understanding of https://github.com/eclipse-cdt-cloud/vscode-clangd is to promote capability to support in parallel multiple compile_commands.json having each assigned to a clangd server instance. I've feeling any server instance may be affected by this dynamic index problematic the same.

It should be noted that the same problem exists even when only one index is involved: If you have a complex project with several applications and/or libraries, then symbols with the same name in the same namespace are indistinguishable (trivial example: main). This is difficult to solve in the general case due to the lack of grouping within compile_commands.json.

I'm aware about https://github.com/eclipse-cdt-cloud/vscode-clangd so I' m getting to get an extra try based on. Possibly it may help but to be confirmed (I'll come back to you) because this fork is about vscode-clangd not clangd server. As we agree on "issue" is part of server ... my fear is despite multi projects capable it may encounter same problematic. My understanding of https://github.com/eclipse-cdt-cloud/vscode-clangd is to promote capability to support in parallel multiple compile_commands.json having each assigned to a clangd server instance. I've feeling any server instance may be affected by this dynamic index problematic the same.

I think using eclipse-cdt-cloud/vscode-clangd could successfully avoid the problem.
One way to think about the resulting behaviour is this: if you configure<EMAIL_ADDRESS>to be in a different project than main.c (so it uses a different clangd instance), then whenever you open a file in<EMAIL_ADDRESS>it will be as if you opened the file in a different vscode window. The behaviour when working with main.c will be as if the file in<EMAIL_ADDRESS>had never been opened.

It should be noted that the same problem exists even when only one index is involved: If you have a complex project with several applications and/or libraries, then symbols with the same name in the same namespace are indistinguishable (trivial example: main). This is difficult to solve in the general case due to the lack of grouping within compile_commands.json.

Yes, the general problem here is indeed a hard one. This is the topic of #1258 (and related issues like #1101).
In this issue, I'm trying to brainstorm ways to mitigate a specific subset of the problem (which was raised by @MNASTM), where only one of the definitions is contained in a file found in compile_commands.json, and that's the one that should be preferred over definitions in other files.

I'm aware about https://github.com/eclipse-cdt-cloud/vscode-clangd so I' m getting to get an extra try based on. Possibly it may help but to be confirmed (I'll come back to you) because this fork is about vscode-clangd not clangd server. As we agree on "issue" is part of server ... my fear is despite multi projects capable it may encounter same problematic. My understanding of https://github.com/eclipse-cdt-cloud/vscode-clangd is to promote capability to support in parallel multiple compile_commands.json having each assigned to a clangd server instance. I've feeling any server instance may be affected by this dynamic index problematic the same.

I think using eclipse-cdt-cloud/vscode-clangd could successfully avoid the problem.
One way to think about the resulting behaviour is this: if you configure<EMAIL_ADDRESS>to be in a different project than main.c (so it uses a different clangd instance), then whenever you open a file in<EMAIL_ADDRESS>it will be as if you opened the file in a different vscode window. The behaviour when working with main.c will be as if the file in<EMAIL_ADDRESS>had never been opened.

Yep. Back to be double checked having a try. I agree despite "issue" root source is server contribution (merging indexes), where is maybe not alternative here, acting on client itself (vscode-clangd so) having it "filtering" data sent to server can be the way to go.

Thanks very much for the explanations @HighCommander4.
To summarize we have two tracks to follow here for this "specific subset of the problem" :)

investigate how to improve the logic for how information from the dynamic index is combined with information from the background index.
check what scenario can be solved (or not) by the eclipse fork (I'll do that)

I did some quick tests with the eclipse fork, here is the outcome while trying the multi-projects feature:

this is partially solving the NOK case (redirection goes to right pack but to .h instead of .c)
the OK case is now also redirecting to .h instead of .c
this only work by using multi root workspaces by default

If anyone wants to checkout this branch and have a try?
I might be missing something but to me this is still not expected behavior.
Any chance to investigate on your side the dynamic/background index logic improvement?

I did some quick tests with the eclipse fork, here is the outcome while trying the multi-projects feature:

this is partially solving the NOK case (redirection goes to right pack but to .h instead of .c)
the OK case is now also redirecting to .h instead of .c
this only work by using multi root workspaces by default

If anyone wants to checkout this branch and have a try?
I might be missing something but to me this is still not expected behavior.

In this branch, both libraries have their own workspace and therefore their own clangd instances. This is why navigation to from the application to a definition in the library does not work.
For it to work in the intended way, you'd want the app + the library version it uses to be in the same workspace (so they share a clangd instance) while the other library version is in a different workspace.

Any chance to investigate on your side the dynamic/background index logic improvement?

I've added it to my (very long) list of things to look into, but I really can't promise a time frame for that. At the moment there are some folks who have been waiting for months for me to review some of their patches, I need to prioritize that.

Yes of course, in this case this works, but this way of working is very limiting in terms of package reusability, I think.
Anyway, thanks for your help. Not sure if we can be of any help here, especially if this involved hot codepath you mentioned.
Let me know if the topic comes back to the point anytime.

this way of working is very limiting in terms of package reusability

Could you say more about this?

Not sure if we can be of any help here

A first step which doesn't require writing any code would be to come up with a precise description of how the heuristic should behave. That will inform questions about implementation and performance.
Note that the example projects in the main branch and the eclipse branch differ in an important way:
On the main branch, there is only one compile_commands.json file, and of the two library versions, only one of them has its sources included in the compile_commands.json. Therefore, only one of the library symbols will be included in clangd's background index.
But on the eclipse branch, there are two applications, both have a compile_commands.json, and both include the source files of the corresponding library version. Now, both library sources files are subject to background indexing. If we are working with a single clangd instance, the background index will itself contain a merged symbol, and at merging time we will have chosen one of the two definitions. In this case, the approach discussed above for resolving conflicts between the dynamic index and the background index will not help at all (since the symbol is already merged in the background index). So, if the goal is to get this project setup to work with a single clangd instance (as opposed to the "single compile_commands.json" setup), that will require some new ideas.

So, if the goal is to get this project setup to work with a single clangd instance (as opposed to the "single compile_commands.json" setup), that will require some new ideas.

No this was not the goal at all. Here I was just experiencing eclipse fork as suggested to test multi clang instances. And I agree this is actually solving some caveats with multiple compile_commands.json at some usage conditions (multiple root workspaces) but this is deviating from the original issue.

this way of working is very limiting in terms of package reusability

Could you say more about this?

I thought it was limiting in a way that you say shared libraries should be in the same workspace, and we don't want to duplicate code just to be part of the workspace, right? But I did another test in this branch but only open both apps (app1 and app2 => I push a new apps.code-workspace). In this case pack-divs are not in the workspace so they won't have their own clang instance. But still I would expect to be redirected. Again, this works, and redirection goes to the right pack-div version but still to the .h file...
Being that said, I think we should not mix issues here and leave the multiple compile_commands.json and multiple clangd instances and come back with the original one.
In this single compile_commands.json case, my proposed description would be rather simple, and only rephrase the title that you edited just well
"Always prefer definitions from the background index (more reliable), rather than dynamic index."
My approach might be very naïve, and I am not sure how other use cases may be impacted, also probably performance consideration to be studied. WDYT?

this way of working is very limiting in terms of package reusability

Could you say more about this?

I thought it was limiting in a way that you say shared libraries should be in the same workspace, and we don't want to duplicate code just to be part of the workspace, right? But I did another test in this branch but only open both apps (app1 and app2 => I push a new apps.code-workspace). In this case pack-divs are not in the workspace so they won't have their own clang instance. But still I would expect to be redirected. Again, this works, and redirection goes to the right pack-div version but still to the .h file...
Being that said, I think we should not mix issues here and leave the multiple compile_commands.json and multiple clangd instances and come back with the original one.

Sure. Some final thoughts in this branch of the conversation:

I think, in principle, using different clangd instances for different applications could be a way to overcome limitations of the way multiple definitions are handled by a single clangd instance (including limitations that will not be addressed by the heuristic we're discussing below).
There's no fundamental reason why the set of files managed by a particular clangd instance would need to align with top-level directory / workspace boundaries. (But the eclipse-cdt-cloud plugin may currently require that.)
Getting this to work well in practice would probably require some investigation, and possibly changes to clangd and/or eclipse-cdt-cloud to better accommodate such scenarios.

In this single compile_commands.json case, my proposed description would be rather simple, and only rephrase the title that you edited just well
"Always prefer definitions from the background index (more reliable), rather than dynamic index."
My approach might be very naïve, and I am not sure how other use cases may be impacted, also probably performance consideration to be studied. WDYT?

If we always prefer definitions from the background index, we would be discarding the benefit of the dynamic index in providing results which may be more recent than the background index (e.g. a more recent version of the same file, providing a more accurate definition location that reflects recent changes to that file). I don't think we can do that.
I think our heuristic needs to be more narrowly tailored to the case of definitions in files which are not found in the background index.
Let's introduce some terminology:

let's call a file which is found in the background index a project file
let's call a file which is not found in the background index an external file

Then a potential heuristic could be:

when merging a symbol A from the dynamic index with a symbol B from the background index:
if A's definition is in an external file and B's definition is in a project file, then:

if the file originating the request (e.g. in the case of go-to-definition, the file in which you invoke the operation) is a project file, prefer B's definition
if the file originating the request is an external file, prefer A's definition

This way, go-to-def performed in project files will prefer targets in project files, and go-to-def performed in external files will prefer targets in external files.
Does this behaviour seem reasonable?

There's no fundamental reason why the set of files managed by a particular clangd instance would need to align with top-level directory / workspace boundaries. (But the eclipse-cdt-cloud plugin may currently require that.)

Yes, you are right, see eclipse README:
A central ProjectService is used to identify each project in an open workspace/folder base on a defined ProjectResolution strategy. Adopters can define custom resolution strategies tailored to their needs (configurable via settings)

Does this behaviour seem reasonable?

Sounds good to me yes.

@HighCommander4, have you got any chance to look at project / external files ?
Thanks for update if some.
If helpful, feel free to ask for just in case able to support you a way or another (promoting test case / doing early trial on specific branch / ...). Trying to do the best here, being afraid (pragmatic) unfortunately not being able to contribute to code base itself because looks like real dedicated expertise is must have.

I have not, sorry.
I have a day job and I contribute to clangd in my free time. This seems like a relatively easy win, and is one of (several dozen) issues I'd like to work on at some point, but I'm not really in a position to give time estimates.

I will add, if someone would like to give this a try before I get to it, I'm happy to provide guidance and code review.
As a starting point, I've already written down a fairly detailed description of the proposed solution at the bottom of this comment.


.pdf Samuel Kelsey: Page 2 Address

Not sure if this is related to issue https://github.com/codefordc/districthousing/issues/275 but the current address and previous address are inaccurate as well.
Where it says "current", it actually maps to the address of the landlord of the last previous residence. "previous landlord" maps to the 2nd most recent previous landlord. (in order of: current, previous, 2nd previous)

this is still a problem.

Priority

I think I fixed this. http://districthousing.org:3000/housing_forms/285
LL1NName => LL1Name

Confirmed fixed! Thank you, @thadk!


I don't understand select and include functionality on filters

For example:
If I have a usersWithDrafts query

I would suppose that the result will return the users with the publications that are only drafts, however it returns the users with all the unfiltered publications.

Is it possible to do this ??

This is more of a Nexus thing. You would need to add this in you models:
export const User = objectType({
  name: 'User',
  definition(t) {
    t.model.createdAt()
    t.model.id()
    t.model.name()
    t.model.email()
    t.model.posts({
      filtering: true, // this one
    })
  },
})

And your query would look like this:
query draftts {
  users {
    name
    posts(where: { published: { equals: false } }) {
      id
      published
    }
  }
}

Your resolver does not need to include any extra filters.


quality_control.json needs to be indexed across assets

Is your feature request related to a problem? Please describe.
Now that quality_control.json files are being created I'm seeing two failure modes where the state of the QC gets out of sync across assets. Assume here that there's a primary data asset (raw) and a derived data asset (derived). For context the way QC works is that the AindCoreModel QualityControl is just a bucket with a list of QCEvaluation objects, users append to the list whenever they do some kind of processing that generates qc metrics.

First failure mode happens because we allow users to append QC data to assets after they already exist. If the order of events is: (1) raw asset created, (2) derived asset created, (3) user appends QC data to raw asset, then the derived asset is now out of sync (it should have a copy of the raw QC).
Second failure mode happens if a user creates a derived asset and forgets to copy the original quality_control.json file, then their derived asset will be out of sync (again it should have inherited any raw QC)

Describe the solution you'd like
Using the data_description, the indexer finds chains of assets that were derived from each other and checks that each subsequent asset has all of the QCEvaluation objects in their parent. It's critical that this goes from raw->derived->derived and that the checks don't go backwards (i.e. you have to make the chains in a first pass and then go through each chain,  you can't start from each asset and go back to its raw asset or you get ordering issues).
Describe alternatives you've considered
The QC portal could be responsible for this, but I think that having invisible functionality happening in the background of the portal is a mistake.
Additional context
Link to the QC schema: https://github.com/AllenNeuralDynamics/aind-data-schema/blob/dev/src/aind_data_schema/core/quality_control.py

@dyf suggests to discuss this further


Docker MailServer V2

Here is the list of what should be done in version 2 of this image

[ ] Reduce image size
[ ] Move to Alpine or other lightweight image
[ ] Use encrypted user database + generator from clear password text file
[ ] Move from /tmp folder to /var/docker-mailserver or equivalent
[ ] Rename files (some are .cf, some are not)
[ ] Rename env using convention
[ ] Refactor integration tests workflow in Travis
[ ] Find another project name :blush:
[ ] Create Github organization
[ ] Find 1 or 2 core contributors to help project maintenance

Hi!
Take a look at https://gitlab.martingansler.de/docker/mail
I basically took your postfix configuration and integrated it in an alpine/s6 based image.
Currently it doesn't result in a working server but it should help you figuring out how to start the services etc.
Unfortunately I don't have much time at the moment, so that all I could hack together in the last 30 minutes or so.

The challenge for us if to find a lightweight and secure distro with all our needed packages.
After a first look with @KyleOndy it seems that some packages are not available on Alpine.

Do you remember which ones are missing?

First of all ... what a great project @tomav :)
Really! I'm enjoying using it, while trying to contribute some changes.
One of the key issue is the 'encrypted database': well, I'm currently running a modified docker-mailserver image where all cyrus-sasl and courier-* has been replaced with dovecot: it builds and it WORKS :)
My current implementation:

postfix auth for sending out emails is now based on dovecot (sasl)
imap, pop3 are all served by dovecot, and SSL is configured accordingly to DMS_SSL env
imap, pop3, postfix all use (thanks to dovecot) the same user-database with passwords encrypted
users are still managed via accounts.cf but now the passwords are encrypted
the supported encryption scheme is wide: CRYPT MD5 MD5-CRYPT SHA SHA1 SHA256 SHA512 SMD5 SSHA SSHA256 SSHA512 PLAIN CLEAR CLEARTEXT PLAIN-TRUNC CRAM-MD5 SCRAM-SHA-1 HMAC-MD5 DIGEST-MD5 PLAIN-MD4 PLAIN-MD5 LDAP-MD5 LANMAN NTLM OTP SKEY RPA SHA256-CRYPT SHA512-CRYPT
services startup has been adapted accordingly, of course using the same logic
moreover I've added an option to import (from a volume) the DKIM keys: the idea being I don't want to change my dns at every restart ! It's not a dovecot thing, but I found it useful.

Having to manage a single file for the accounts is considerably simple than my previous patch on a similar subject (not yet merged BTW). Moreover now every auth service in the container use the same DB (well, except for mail relay).
What remains to be done:

I think an overall look at the dovecot configuration is a good idea
integration tests need to be reworked: I've not found the time to do that, but it's needed

Are you interested in this fork ? How do you suggest to contribute (since the lack of the integration tests) ?
Regards.

Hi @00angus, of course we're interested for the v2 milestone.

I've maintained the same architecture you introduced, with the same overall approach... We should however test the config and the security of the solution.
Anyway I've also tested my setup using free online services like checktls.com.

Regarding packages in Alpine, have you thought about building from source? Building on Alpine is a highly suggested route. I'd like to incorporate this project into my services but I am not keen on 600MB images.

Could be more difficult to maintain...

@tomav how do you want to proceed? Would you like to create a new branch, say dovecot, where I can make PR?

@00angus branch will be v2.
Empty branch or from master?

Maybe it's better from master ? My branch is derived from your on master
anyway, with not so much things changed.
They can merge, I think.
Anyway for me is the same.
On Fri, Apr 8, 2016 at 3:12 PM, Thomas VIAL<EMAIL_ADDRESS>wrote:

@00angus https://github.com/00angus branch will be v2.
Empty branch or from master?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-207425866

https://github.com/tomav/docker-mailserver/tree/v2

I would like to see what you have gotten so far with your approach @00angus.

@KyleOndy I'm integrating the latest changes of master-v2 ... and I'll call for a PR.
Anyway CI tests don't work: @tomav do I have to take that into consideration someway when making the PR? Because I don't know in case the Travis-CI get activated if it would build (I don't know how it works).

PR submitted.
The Travis-CI build is started ... If it's going to use the make all command for the build, it could end-up in a green state:
$ make all
docker build --no-cache -t tvial/docker-mailserver:dovecot .

I've changed the makefile to:

comment out fixtures, tests and clean targets from the all rule
give a version to the image, the version being dovecot. This way on the same host I can have two images compiled for courier (v1) or dovecot (v2) at the same time.

Merged https://github.com/tomav/docker-mailserver/pull/123
A v2 tag should appear soon on Docker Hub.
https://hub.docker.com/r/tvial/docker-mailserver/tags/

I'm about to push some enhancements.

Done.
Tests are now a high priority.

Waiting for it :)
We will have to merge some commit, moreover ;)

@00angus the build is now named tvial/docker-mailserver:v2 (from the branch name)

Ok ... then I'd suggest to put somewhere the information that v2 == dovecot
... Readme or something else...
-- Marco
On Tue, Apr 12, 2016 at 9:50 AM, Thomas VIAL<EMAIL_ADDRESS>wrote:

@00angus https://github.com/00angus the build is now named
tvial/docker-mailserver:v2 (from the branch name)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-208762795

Yeah, we'll do that when work will be finished. As you can see at the top of this thread, migration to dovecot is not the only task.

Well, it's only an opinion, but since v2 is downloadable maybe people want
to know what's inside..
But OK, let's wait.
On Apr 12, 2016 12:53, "Thomas VIAL"<EMAIL_ADDRESS>wrote:

Yeah, we'll do that when work will be finished. As you can see at the top
of this thread, migration to dovecot is not the only task.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-208844245

Great work so far!
Did you think about migrating from v1 to v2?
With IMAP you can always just start ab v1 and v2 parallel and copy all messages with your mail client, but maybe there is a better way?
Or is it possible to just use the same volume?

@00angus dovecot uses Mailbox format like postfix no?

@00angus I really don't want to release a new version to quicly.
Tests are disabled right now on this branch and documentation is not up to date.
I think that Clamav doesn't start properly and I haven't tested it myself for the moment.
Of course, code and build are available for testing but really not recommended for production right now.
I should get some time at the end of the week to close some of the tasks but I will need your help, especially on tests regarding dovecot.
If some other guys want to contribute, let me know, let's talk about what are the things to do and how we should do them. I'm open to suggestions.
Thank you.

@tomav I'm not sure that v2 is still working by looking at your recent patches, but I may be wrong.
Because...
 this line of start-mailserver.sh look for a different path from this other one for user config file.
I'll have a closer look at it this afternoon, anyway, and I'll try it out.
I will definitively help on tests.

I missed this line. I'll have a look.

Dovecot uses maildir inboxes, as courier, as for configs.

Haven't tested/used it:
http://wiki.dovecot.org/Migration/Courier

I'm putting my work on the alpine based container on indefinite hold. At this point I can't see it working without jumping through a lot of hoops.
I know image size is important, but perhaps we should get a solid v2, then work to reduce size in v2.x?

I agree. Again we need tests to be sure that nothing breaks on big changes like changing the distribution.
I don't know what is the amount of work... Perhaps the best thing is to have the exact list of packages and see if they exist in stable alpine distro.
I created this file with the v2 packages:
https://docs.google.com/spreadsheets/d/1VFkt-741KVjFqOTpu60Qj--PYEtWHqwYA3SC0DY6TFs/edit?usp=sharing
You should have write access.

@00angus: I just pushed fixes.
Now we have 49 tests, 26 failures.

49 tests, 21 failures

I let you have a check for authentication tests on imap. You have a better dovecot knowledge than me.

BTW, I think you've disabled accounts in postfix, so smtp auth does not work.
No more time for today, let me know if you have suggestion.

I'll have a look but not today as I'm busy. Anyway I'm using in production the dovecot image I PR and it does smtp auth (but I've also custom main.cf ...?).  I'll have a closer look tomorrow.

Could you diff your main.cf?

I'll look at my conf later today... However master.CF should open up
submission port!?
Anyway I'll let you know as soon as I have time to dedicate at the subject.
On Apr 15, 2016 00:10, "Thomas VIAL"<EMAIL_ADDRESS>wrote:

Could you diff your main.cf?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-210176428

49 tests, 12 failures. Better.
Most of remaining tests are related to authentication.
@00angus I'll need your help, I'm not a Dovecot expert.
BTW, /etc/dovecot/userdb contains clear login/passwords.

This all sounds very strange as pwd are taken from accounts.cf, which if
encrypted should remain encrypted.
I'm out of time these days, sorry. But on the WEnd I'll find enough time.
On Apr 15, 2016 21:04, "Thomas VIAL"<EMAIL_ADDRESS>wrote:
49 tests, 12 failures. Better.
Most of remaining tests are related to authentication.
@00angus https://github.com/00angus I'll need your help, I'm not a
Dovecot expert.
BTW, /etc/dovecot/userdb contains clear login/passwords.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-210599909

@tomav I've tried to understand the problems on v2 you have commented here:

smtp auth: is disabled in your version of V2 simply because the main.cf you are ADDing (via Dockerfile) to the image is almost empty, i.e.:
 max_idle = 600s
 readme_directory = /tmp

It cannot works. I'm reverting the configs from my commits, while keeping your dir layout

dovecot userdb: it contains clear password simply because you are providing postfix-accounts.cf that contains clear passwords! You haven't commented the README.md file: is it clear to understand and to follow for setting up the users ? Please let me know :)

I'm trying to understand your recent changes (e.g. which layout for the host volume shared...) and since no docs exist on the tests I'm trying to figure out how they work (i.e. auth login which user and password is using? etc.). Anyway... I'm working on it.

smtp auth: is disabled in your version of V2 simply because the main.cf you are ADDing (via Dockerfile) to the image is almost empty

That's what I found yesterday and pushed. Are you sure you got the updated version?

No - it seems I've fetched v2 a few moments before you pushed, and I started debugging on that version.
Glad to know you worked it out :)

@tomav Can I ask why in the Dockerfile do you need to add "sasl2-bin" package ??
 This is the Cyrus SASL API implementation ...

Testing SASL only. testsaslauthd in part of this package.
If you have other options, let me know. I'd like not to have to install specific binaries for testing.

Ok, I'll let you know.
On Apr 16, 2016 22:46, "Thomas VIAL"<EMAIL_ADDRESS>wrote:

Testing SASL only. testsaslauthd in part of this package.
If you have other options, let me know. I'd like not to have to install
specific binaries for testing.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-210898214

testsaslauthd can safely be substituted with doveadm auth test (parte of dovecot-core) and that's what I've already done in my branch.
I finally managed to have :
49 tests, 2 failures

But I've a question for you @tomav :) since I don't know very much of how the tests work.
The two failures comes from fail2ban checks:

how can fail2ban effectively ban via iptables inside the container if we are not running the mail_fail2ban with the needed privilege?

Even in maste branch the Makefile that startup containers for tests do not add special privilege to that container ... and so I'm surprised that tests are working there. Do you have any idea on that ?
Thanks.

Great news!
I can work on fail2ban if you want. We should not try using <IP_ADDRESS> so I'll do it from another container.
Push your current work and I'll finish fail2ban.

Commit https://github.com/tomav/docker-mailserver/commit/72d72076901ea2e6f4c6d53c46c7a7a03c4cdfa3
Building on Travis...

Works locally, not on Travis. Trying something else.

Done. Your build exited with 0.
https://travis-ci.org/tomav/docker-mailserver/builds/123774801

Good :)

@tomav in the new commits I've found a new file:
target/fail2ban/jail.conf

It seems that the start-mailserver.sh doesn't need any more the fail2ban setup for jail.conf ... what do you think ?

What has been done in start-mailserver.shshould have been done in Dockerfile because it's core configuration. The jail.conf I added is the generated version + a modification regarding backend configuration. I also removed some not usued lines.

In regards to running tests, are you having you docker-compose/yml point to your locally build image? I have having issues getting it to see the local image, docker-compose keeps trying to pull  from docker.io and I get ERROR: Tag V2 not found in repository docker.io/tvial/docker-mailserv.
Can someone share their docker-compose.yml with me?

@KyleOndy it's v2 not V2
https://hub.docker.com/r/tvial/docker-mailserver/tags/

@00angus I think we should add a generator that output the whole line needed that can be added using a redirect to postfix-accounts.cf using:
$ docker run --rm -ti tvial/docker-mailserver:v2 doveadm pw -s MD5-CRYPT -u<EMAIL_ADDRESS>> config/postfix-accounts.cf

What do you think regarding removing the pipe in this file?

We could provide a command, e.g. something like:
<EMAIL_ADDRESS>&& docker run --rm -ti tvial/docker-mailserver:v2 /bin/bash -c "echo ${u}|`doveadm pw -s CRAM-MD5 -u $u`" > config/postfix-accounts.cf

A space instead of a pipe may not be part of the password and username, so probably would be better.

That's it. But I think a generator will be easier.

Ok, but then I'm missing what do you mean with 'generator' :) The above command isn't a sort of a generator?

Perhaps a shell script like the certificate generator. We can start without but I think it will provide more simplicity to generate users.

BTW, My last commits broke the tests. I'm fixing it.

Just forgot to commit a file...

Just for information, I did not have time to check a migration to Alpine.
But a quickly tried cloudgear/ubuntu which allow to save 30MB (only...)

I'm was working on a debian:jessie branch today, but it ended up being larger than the ubuntu:14.04 image.

Migrated my mail server from latest to v2. Everything works as expected so far.

Great!
:)
I've tested mine with several online check tools, but the best way to
improve our configuration is by using it :)
On Wed, Apr 20, 2016 at 9:31 AM, Thomas VIAL<EMAIL_ADDRESS>wrote:

Migrated my mail server from latest to v2. Everything works as expected
so far.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-212298734

Yep. I'm currently working on the README. I'll push something in few minutes.
For those who ask, /var/mail remains the same so you will keep your content when upgraded but we recommend to backup everything before, and we're still in Beta.

v2 is 411.5 MB while latest is 525.3 MB

So now that I've spent a few days hacking at the alpine image, I don't see anyway its going to work.
It seems that alpine:3.3 is based off of busybox, which breaks the test suite since the ps exec doesn't support the proper command line arguments.
Even if we were to rewrite all the tests, alpine doesn't have an init system, so there is no way to start multiple services needed for this container.
Its a shame, it was floating around 130MB before I hit the init roadblock.

@KyleOndy would you mind sharing your progress so far?
I think it should be possible to install ps.
And I also played around a little with s6, a very small init like system.

Let me clean up (a bit) and I'll push it. Full disclosure, it is in rough shape.

As for the init system, normally in a docker container it's not used. But
since we start several services it could be useful. Anyway what if we
script the full command line startup of each service?
Consider the following:

postfix binary self manage the usual stop, reload. That means that on
cmdline or script we can use that method
the same apply to dovecot

BTW as @tomav said, I'm a little bit worried about maintenance of the
image. Would it be still applicable to use a workflow like:

pull image
docker build
docker run
??

Interesting work however and the image size is very... appealing :)
On Apr 21, 2016 23:33, "Kyle Ondy"<EMAIL_ADDRESS>wrote:

Let me clean up (a bit) and I'll push it. Full disclosure, it is in rough
shape.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-213122111

@00angus for a better user experience, keeping pull/run is a better option.
@KyleOndy please push your branch so we'll have a look to see if we can make the necessary effort to make it work, and also check what it means regarding maintenance.

And thank you guys for the work by the way, I don't have a lot of time these weeks.
It's nice to know that some of you are invested in this project.

I agree that the upgrade should be a simple pull/run. It fits the ideology of docker.
It also mean I can keep on using watchtower.

While I think it is good to strive for a small image size, I'm in the opinion that maintainability should be a higher priority.

I do agree, it should work, maintain and upgrade easily, evan if it's 150 additional MB.

https://hub.docker.com/r/tvial/docker-mailserver/tags/
Image is smaller and smaller, just got 25 additional MB free.

7 additional MB removing man pages.
https://hub.docker.com/r/tvial/docker-mailserver/tags/

I plan to release V2 early May.

Good! The image size is more than acceptable.
Anyway... I'm having an hard time let CI tests pass while building an image
locally. I'm working on a minor patch but 2 or more tests keep failing
(fail2ban, opendkim...). I do not understand how on Travis they passed.
On Apr 25, 2016 06:12, "Thomas VIAL"<EMAIL_ADDRESS>wrote:

I plan to release V2 early May.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-214120950

We can talk about that is you want. I'm currently traveling for work so I won't be really available before wednesday, but leave a comment here, I'll try to have a look in the evening.

Added tests for letsencrypt.

docker-slim gave an image of 150MB~ , clamAV is the biggest burden being >100MB, and alpine is not gonna help with virus signatures

If I follow you, an idea can be to add an env variable to disable automatic updates. So freshclam will move out from Dockerfile but I'm not sure that tests still pass without a first update.
Regarding docker-slim, I'll have a look but we need something compliant with docker hub automated builds.

DOVECOT:
By looking at Dockerfile I noticed I made a small error.
The line:

ADD target/dovecot/10-*.conf /etc/dovecot/conf.d/

unfortunately do not add the configuration for mailboxes.conf.
I've changed that, by including 15-mailboxes.conf (altready available in target).
From my checks on my production system it still works, it is only more polished IMHO.
My upcoming PR in including - among other small fixes - also this one.

Will release tonight.

(or in the next minutes)

Dear contributors, v2 is the new master on github and latest + v2 on docker hub.
Legacy version remains available in v1 branch on github & tag on docker hub.
**I wanted to thank all of you for the work on this project.
**
I decided not to change the name of the project for the moment, but have mailody in mind... let me know what you think about it.

Good project and good work. Glad to have contributed and hope to continue.
On May 8, 2016 20:30, "Thomas VIAL"<EMAIL_ADDRESS>wrote:
Dear contributors, v2 is the new master on github and latest + v2 on
docker hub.
Legacy version remains available in v1 branch on github & tag on docker hub.

*I wanted to thank all of you for the work on this project. **
I decided not to change the name of the project for the moment, but have
mailody in mind... let me know what you think about it.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tomav/docker-mailserver/issues/109#issuecomment-217738141


Allows --protocol to be configurable for the mysql cmd

Hi,
Today I ran into an issue that took me hours to figure out. I was trying to use mix ecto.load to load a schema file, after seeing the file's successfully loaded message, I checked the database and saw nothing was imported.
I dug into the code to see what goes behind the scenes of ecto.load, and noticed that it uses the mysql command. So I ran the mysql command manually and it imported correctly.
Then I started debugging what exactly was the command generated by the ecto's mysql adapter. It turns out, the --protocol=tcp part was the culprit. As for my local mysql installation, it uses socket to connect.
I'm not sure why --protocol=tcp was hard-coded, so I'm going to go out on a limb and guess that it was an oversight?
This PR retains the --protocol=tcp behaviour, but allows users to configure it to other values (tcp, memory, pipe, etc).
I couldn't figure out a way to add tests (there are no tests for testing adapter's load/dump behaviour, other than a few for a mocked version) so I'm going to simply make these straightforward changes. Please let me know if you have any suggestions and I'm more than happy to look into it.
Thanks!

Would it be maybe better if we didn't have a repo-wide configuration for this, but instead allowed passing an option to the ecto.load and ecto.dump tasks?
It seems to me a protocol is a fairly "wide" option we might want to use for something - if anything, actually connection to the database daemon via the unix sockets.
It should be also pretty easy to make it a default with mix aliases for tasks.

@michalmuskala The only thing is that this option is mysql specific, and the current options for ecto.load are all non-adapter specific.

Ah you're right. It doesn't make sense to add it there. Could we maybe rename this option to cli_protocol or something similar? What do you think?

Sure thing, updated!

:heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:


Update .openpublishing.redirection.json

Redirect the retired Teams interop documentation to the new Teams coexistence and interop documentation

@kenwith , can you have a look at this?


Monster variants in data that are not SRD content

I have noticed that Djinni data has Variant: Genie Powers, which doesn't seem to be part of SRD, that variant appears in Monster Manual.
From quick search of variant I get 22 hits in monster data, while only 2 hits in SRD for monsters.

Oh you're right. That should get cleaned up. Good catch! Feel free to open a PR if you like.


Cannot use  import {app} from 'electron' from files under src folder

Hi, Thanks for this awesome boilerplate you bring us! I just ran into an issue when I tried to import app from files under the src folder.

The error shows electron' does not provide an export named 'app'

But it works fine from electron/main/index.ts, Does anyone can help me? Thanks!

Seems that render process has to call Electron API via IPC

did you fix it ?  please share it


Refactor attribute processing

Refactoring how an element's attributes are processed into a series of helper functions.

LGTM


How exact have you reproduce the experiment result？

Thank you very much.

Hello. Do you mean the result table of the paper?

Yes, but maybe you can achieve lower score with smaller parameters.

No. I dont experiment yet, using paper data. It is just simple text generator used gpt 2 model.
Do you have a interest in making a reproduction of paper result?
Thanks.

I will try.


⚠ Bofrost.de has degraded performance

In de5bb4e, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 960 ms

Resolved: Bofrost.de performance has improved in e4dc7f6 after 6 minutes.