NTR: histone H2B conserved C-terminal lysine ubiquitin ligase activity

As the modifications will move from BP to MF, I need an MF term to describe
the activity corresponding to this process:
GO:0071894    histone H2B conserved C-terminal lysine ubiquitination
Definition
A histone ubiquitination process in which a ubiquitin monomer is added to a conserved lysine residue in the C-terminus of histone H2B. The conserved lysine residue is K119 in fission yeast, K123 in budding yeast, or K120 in mammals.
histone H2B conserved C-terminal lysine ubiquitin ligase
standard def,
here is one reference PMID:17363370

We need to review annotations - I dont see any ubi ligase annotated, so we need to decide where to rehouse the existing annotations https://docs.google.com/spreadsheets/d/1RWOBUXZSc8FUmASFsBQ03XE1k73Wm9ypFmiB4ivsVgQ/edit#gid=0

Quite a lot of these are ligases that will go to the new  MF term.
DTX3L, ring finger protein 8, E3 ubiquitin-protein ligase BRE1A &B,ring finger protein 40
(and the associated conjugating enzymes).
Others are scaffolds for these complexes.
Some appear to be indirect phenotypes, and most likely already have appropriate annotation to describe a role in heterochromatin assembly or similar..= The process therm that I used which probably applies to most of these is
GO:0048096 (chromatin-mediated maintenance of transcription)
which was recently renamed to
GO:0045815    epigenetic maintenance of chromatin in transcription-competent conformation
but I don't know if this is the correct term here.
this process  correlate with increased RNA polymerase II levels at repeat elements embedded within heterochromatin domains causing heterochromatic derepression.
@colinlog  is this the correct process for this modification?

No, GO:0045815 is the euchromatin term that will describe the H3K36me3 (and
in some instance H4K20me and H3K79me2/3 regions) that are transcribed. Also
FACT (SSRP1, SPT16) and PAF1 (BRE1 CTR9 PAF1, ... )will belong there.
For "this process correlate with increased RNA polymerase II levels at
repeat elements embedded within heterochromatin domains causing
heterochromatic derepression" the RITS complex and others will link to
HP1/SWI6 GO: GO:0031507heterochromatin assembly. Sometimes the H3K9me2/3
and sometimes H3K27me/23 types will be involved. There may be one MF that
contributes to both GO"0031507 and GO:0048096, but the latter is definitely
a euchromatin process that correlates with the active (H3K27ac) and latent
(H3K4me1) transcription marks. Whenever you have H3K36me3 marks in the
transcribed region, you also have the H3K4me3 and H2BK123ubi marks at the
then active promoters, together with the H2A.Z variant, in varying
proportions.  At those regions also H3.3 variant is found. And, at these
promoters the 4 MFs we will create for SNF2-type ATPase enzyme complexes
operate, together with many readers and writers of acetylated histones of
which a select set of these protein complexes harbour histone chaperone
RBBP4/7 also known as RBAP46/48 or MSI1 in plants and in S.c and S.p HAT2.
Those two (RBBP4 and RBBP7) contribute to GO:0048096 (euchromatin) and to
GO:0031507 (heterochromatin). They are parts of many complexes by virtue of
binding nucleosomes. They contribute to both the coTF dbTF coactivator and
co-repressor MF, from different complexes.
Structurally, "histone H4 adopts a different conformation when interacting
with RbAp46 than it does in either the nucleosome or in the complex with
ASF1, another histone chaperone. Our structural and biochemical results
suggest that when a histone H3/H4 dimer (or tetramer) binds to RbAp46 or
RbAp48, helix 1 of histone H4 unfolds to interact with the histone
chaperone." from PMID:PubMed: 18571423
https://www.rcsb.org/search?q=rcsb_pubmed_container_identifiers.pubmed_id:18571423
.
On Fri, Nov 26, 2021 at 5:37 PM Val Wood @.***> wrote:

Quite a lot of these are ligases that will go to the new MF term.
DTX3L, ring finger protein 8, E3 ubiquitin-protein ligase BRE1A &B,ring
finger protein 40
(and the associated conjugating enzymes).
Others are scaffolds for these complexes.
Some appear to be indirect phenotypes, and most likely already have
appropriate annotation to describe a role in heterochromatin assembly or
similar..= The process therm that I used which probably applies to most of
these is
GO:0048096 (chromatin-mediated maintenance of transcription)
which was recently renamed to
GO:0045815 epigenetic maintenance of chromatin in transcription-competent
conformation
but I don't know if this is the correct term here.
this process correlate with increased RNA polymerase II levels at repeat
elements embedded within heterochromatin domains causing heterochromatic
derepression.
@colinlog https://github.com/colinlog is this the correct process for
this modification?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/geneontology/go-ontology/issues/22138#issuecomment-980116550,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALZVLKGMHH2PKIGO7ZD3NQ3UN6ZU5ANCNFSM5D5REVXQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

So what is the term that should be used? All of my annotations to this  term must be wrong. I thought I checked these to the revised term but they must have been incorrect to begin with, or, the term has changed in meaning?
This is what I have currently:
https://www.pombase.org/results/from/id/50f32fbc-85ec-4bbe-82cc-8c7c4e62b96f
Is it just HULC that need to move?

That list if very fine! All promoter activities. We will add many more.

OK I thought you were saying I had the wrong term here! OK! Let me know which other complexes should definitely be annotated to this term. I can compile the list of  complex->process and check it with the Term Matrix.

Can we add these? Once we have the MFs we can move the existing BP annotations.
Not so many.

NTR: histone ubiquitin ligase activity (H3-K14 specific)
def: "Catalysis of the transfer of a ubiquitin molecule to a histone 2B at the lysine-14 residue.
PMID:34010645
PMID:31468675

Grouping term:
+[Term]
+id: GO:0140852
+name: histone ubiquitin ligase activity
+namespace: molecular_function
+def: "Catalysis of the transfer of ubiquitin to a histone substrate." [GOC:curators]
+is_a: GO:0061630 ! ubiquitin protein ligase activity
+property_value: term_tracker_item https://github.com/geneontology/go-ontology/issues/22138 xsd:anyURI
+created_by: pg
+creation_date: 2022-06-13T10:38:05Z
+id: GO:0140851
+name: histone ubiquitin ligase activity (H3-K14 specific)
+namespace: molecular_function
+def: "Catalysis of the transfer of a ubiquitin molecule to histone 3 at the lysine-14 residue." [PMID:31468675, PMID:34010645]
+is_a: GO:0140852 ! histone ubiquitin ligase activity
+property_value: term_tracker_item https://github.com/geneontology/go-ontology/issues/22138 xsd:anyURI
+created_by: pg
+creation_date: 2022-06-13T10:34:13Z
+

[ ] Need to create the terms for H2A.

[ ] histone H2A-K119 monoubiquitination
[ ] histone H2A K63-linked ubiquitination
[ ] histone H2A-K15 ubiquitination
[ ] histone H2A-K13 ubiquitination

+[Term]
+id: GO:0140862
+name: histone ubiquitin ligase activity (H2A-K119 specific)
+namespace: molecular_function
+def: "Catalysis of the transfer of a ubiquitin molecule to histone 2 at the lysine-119 residue." [PMID:22844243, PMID:25470042]
+is_a: GO:0140852 ! histone ubiquitin ligase activity
+property_value: term_tracker_item https://github.com/geneontology/go-ontology/issues/22138 xsd:anyURI
+created_by: pg
+creation_date: 2022-06-20T12:45:05Z

I believe this is the same as
https://www.ebi.ac.uk/QuickGO/term/GO:0140850
(check the def)
Perhaps it is clearer to call it
https://www.ebi.ac.uk/QuickGO/term/GO:0140850
We need to know if there are other numbering variations, maybe they are only at the end I am not surer. It also depends if people have used the convention of counting  with he methionine removed.

@ValWood

I believe this is the same as
https://www.ebi.ac.uk/QuickGO/term/GO:0140850

It's H2B versus H2A... a bit confusing indeed

right! should the same naming convention be used, or is 2b more conserved in. numbering?


Add appveyor configuration

This adds a configuration script for Appveyor, which runs its CI on Windows machines. This will allow the CI to run Windows-specific tests for issues like #374.
One of the maintainers will have to set up the builds on Appveyor, then add in the webhooks in the settings. I did this for my fork to debug the script, you can see the results in pganssle/arrow#1. I probably would recommend turning off branch builds other than master, since Appveyor can be quite slow and if people are pushing to branches on the crsmithdev/arrow repo, it will build the exact same thing twice, for every push.

Codecov Report

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

@@          Coverage Diff          @@
##           master   #487   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          14     14
  Lines        3189   3189
  Branches      229    229
=====================================
  Hits         3189   3189

Continue to review full report at Codecov.

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

Hey @pganssle we're closing this for now. appveyor has most likely changed since this PR was submitted and arrow's own internal tools (tox, tests, pre-commit) have also changed significantly. We're definitely looking at testing on Windows in the future but currently we're focusing on more fundamental issues with arrow.


Template points to octicons CSS that doesn't exist

The index.html template links to //octicons.github.com/components/octicons/octicons/octicons.css, but the actual CSS file is (I think) here: //octicons.github.com/octicons-logos/octicons-logos.css.

Hmm, the updated link you found only seems to contain the logo icons, not all of them.
I think all of GitHub is transitioning to their SVG-style icons, but the API seems to be lagging behind. Since the Octicons project doesn't have the website source published, it's difficult to find a hosted location.
Anyone know where to get them now?
If not, we might have to vendor in the classic Octicons font until the API renders SVG Octicons.
Thanks for bringing this up, @rcausey.

I ended up downloading and adding the font icons from that project to the project directly. Since they're not really used by GitHub anymore, there's no reliable place to grab them from.
I imagine the API will eventually render SVGs and we can remove them again.
v4.3.0 contains this fix. Be sure to run pip install --upgrade grip. Thanks for opening the issue @rcausey! And for taking a stab at it, @JasonYao!

Great, thanks @joeyespo!


chore(main): release 0.1.11

:robot: I have created a release beep boop
0.1.11 (2023-10-15)
Bug Fixes

try (cc1299d)
webhook url (997b736)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/crea-orkest/crea-public/releases/tag/v0.1.11 :sunflower:


Discount gets applied on cart if condition is "Visible Individually" is set to yes and product added in cart is not visible individually.

Bug report
Title
Discount gets applied on cart if condition is "Visible Individually" is set to yes and product added in cart is not visible individually.
Issue Description
Discount gets applied on cart if condition is "Visible Individually" is set to yes and product added in cart is not visible individually.
Preconditions
1. Commit id -f0e5bfdae76e77dc49c4acce05912c90cb01eecf

Steps to reproduce
1. step1- Create a cart rule by selecting condition Visible Individually
2. step2- Place an order of configurable product an apply coupon code.

Expected result
Discount should not get apply
Actual result
Discount gets applied

Not fixed, still getting this issue


Roll Flutter Engine from be7a039c5451 to fd9e68e74c18 (2 revisions)

https://github.com/flutter/engine/compare/be7a039c5451...fd9e68e74c18
2023-09-18<EMAIL_ADDRESS>[web] ScreenOrientation singleton (flutter/engine#45304)
2023-09-18<EMAIL_ADDRESS>[web] De-singletonize MouseCursor for multi-view (flutter/engine#45295)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC bdero@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


same state machine instance for multiple object instances

In our use case we have many objects that could be handled with the same state machine (e.g. from database queries). Currently a state machine is instantiated for each object which creates (perhaps unnecessary) overhead.
Would it be possible to have a version of the state machine that points self.machine in multiple objects (of the same class) to a single state machine instance?

This is an interesting idea. In theory there's no principled reason why you shouldn't be able to use the same Machine for multiple models, provided you want identical behavior. Right now the only barrier I see to doing that is that we track the current State object within the Machine instance  rather than the model instance. This is actually a design flaw, in my opinion; I think it would be cleaner and more sensible to maintain state only in the model. As it stands we already track the current state name within the model, but not the State instance itself.
This should be easy to fix without breaking the API. Assuming we move all state out of the Machine, we could then modify the initializer to take a list of models rather than just a single model. Any changes applied to the machine (e.g., adding new transitions) would thereafter be applied to all available models. So that would work fine in cases where you have all of your models instantiated in advance of Machine creation. But note that you wouldn't be able to easily add extra models after initializing the Machine. Simply pointing to the right Machine in your models wouldn't give you the desired behavior, since you wouldn't automatically have all the dynamically added triggers and callbacks. For that, we'd need to implement some kind of add_model() method in Machine that re-applies all existing transitions and callbacks. That's also potentially doable, but I'm not sure I want to take that step unless this is going to be a fairly common use case (whereas simply managing multiple existing models should be trivial).
Anyway, thanks for opening this issue. I'll think about it some more, and we should be able to do at least something to accommodate this use case without having to change much.

Thank you for your quick reply. I think having just the state name in the model is not a problem; it is always possible to access the actual state from the model and from a database persistence point of view having just strings for the state is much easier to handle.
After reading some more of the transitions code i think it would be possible to maintain (just extend) the API, and optionally move all methods (callback, triggers) to the state machine itself, by introducing an optional base class for the models. E.g. for triggers something like this:
class BaseModel(object):

    machine = Machine(states, transitions)  # e.g. have one state machine instance for all instances

    def __getattr__(self, trigger_name):  # only called if  trigger_name was not found on the model
        if trigger_name in self.machine.triggers:  # or some such, maybe not even required
            return partial(getattr(self.machine, trigger_name), model=self)
        raise AttributeError

if __name__ == "__main__":
    class SomeMachine(object):
        triggers = ["some_trigger"]

        def some_trigger(self, model):
            print "triggered from "+ type(model).__name__

    class SomeModel(BaseModel):
        machine = SomeMachine()

    model = SomeModel()
    model.some_trigger()

Unfortunately, I don't think it's that simple; the State instance currently stored in machine.current_state is used for a number of things--e.g., to determine whether the requested transition is valid for the current state, or to update the EventData instance passed to callbacks. So if you have just one Machine with a lot of models, you're going to run into serious problems if you want to allow those models to be in different states. To make things work properly given the current code, current_state will need to be a property of the model. And like I said, I think it's a design flaw to maintain individual model states in the Machine class anyway; in my view, the Machine should focus on the transition logic and support as little state as possible. This isn't hard to do, but would require patching most of core.py as well as all of the subclasses in extensions.py, so it may have to wait until I have some time (unless you want to submit a PR for it).

Oh, and just to clarify: having only the state name in the model is fine; like you say, the corresponding State instance can be looked up in the Machine. But that still requires rewriting various parts of the code to access the right State via the current model (which would have to be passed in from the trigger; right now it isn't) rather than directly from self.current_state.

Hi,
interesting thoughts. So the machine would manage the 'ruleset' of valid transitions but the actual state is part of the model. I see how this increases the reuse value. I do have some (initial) questions about the desired behaviour and relationship between model and machine though.

Is a one (machine) to many (models) relationship or a many to many relationship desired?
Should all models provide all triggers registered in the machine or should the event triggers be spread across all models?
If add_transition is executed, should that add the trigger to all models related to the machine instance?
Should the State instances/objects be managed by the machine or also be part of the model?

I would suggest to extend a Event.trigger with a model parameter which is bound with partial during transition creation. This requires that a machine has a list of managed models (if add_transition(s) should be able to register triggers on every model). Some things have to be discussed though (like where to store the state in the model or how to deal with Machine.is_state)
I give it a try if one of you can provide a test case. Just to be sure I try to achieve the right thing :).

@aleneum, agreed, that's exactly the implementation I would go with as well. I've played with this a bit already and have a version of core.py that passes all tests in test_core with machine.current_state completely removed and all references occurring via the model. I'll push the branch shortly for comment. If it looks good, we'd just need to amend the extensions accordingly.

@aleneum: I don't know the code enough to understand the Event.trigger part, but in answer to your questions:

Is a one (machine) to many (models) relationship or a many to many relationship desired?:
I could see a use-case for many to many, but our use-case is one-to-many.
Should all models provide all triggers registered in the machine or should the event triggers be spread across all models?
Preferably all state related data and methods be in the machine, and the triggers possibly be made accessible though a call as in the code in my seconds post, so the model would only contain a string for the current_state and a reference to it's state machine (either on class level, as a property or in its __dict__), the state machine would not need the model beforehand, because the model is passed when a trigger on it is called.
If add_transition is executed, should that add the trigger to all models related to the machine instance?
preferably to the model (reducing overhead)
Should the State instances/objects be managed by the machine or also be part of the model?
They would be constant and part of the machine instance, the current_state string of the model would be they way to access it's State instance.

I just pushed a multiple-models branch that modifies the core Machine instance to handle multiple models. As noted above, right now this only works for models passed in at machine initialization. It will not automatically update new models with existing transitions. We can talk about whether that's worth supporting, but for now I lean towards no.
Right now all changes are completely compatible with the existing API. The one potential sticking point here is that we might want to rename self.model to self.models. Right now, to prevent API breakage, I internally store models in self.models, but define Machine.model as a property that returns a single model if the list has length 1, and the full list otherwise. I'm not thrilled about this, but it seems like the best way to preserve the API, and given that right now probably nobody in the wild is expecting multiple models, it doesn't seem wise to tamper with this.
I also had to remove a test that in my view shouldn't be a supported use case anyway (passing optional arguments with send_event=False when the callback function is not explicitly defined to handle such an argument), as it was interfering with passing the model as the first argument to trigger.
@aleneum, see what you think. If the changes look good, we'll need to similarly update all the extensions etc. A bit tedious, but should be straightforward, I think. @gemerden, assuming you're not using any of the extensions, do you want to test these changes out and see if they work for your use case?

The tests should pass now but there is still some work to do for graphing. Right now, only the last transition executed will be shown in the graph. My plan would be to move the graph instance also to the model so that every model has a separate graph. What do you think?

+1 on moving the graph to the model.

And thanks for fixing all the other modules so quickly!

Graph issues have been fixed and nesting also seems to work. But we might want to extend testing of this feature a bit before calling it stable enough for the master branch.

I guess we can consider this solved with #135. Feel free to reopen this issue if you encounter bugs/limitations or open a new issue.


Possible missing documentation on sap.m.plugins.PluginBase

OpenUI5 version: 1.96.2
Checking the SDK, I could not find any documentation on sap.m.plugins.PluginBase. Is this class regarded as 'internal' the same way e.g 'sap.ui.base.ExpressionParser' is and is the documentation really missing or not planned at all?

Hello @dfenerski
Thank you for sharing this finding. I've created an internal incident<PHONE_NUMBER>. The status of the issue will be updated here.
Regards,
Georgi

The sap.m.plugins.PluginBase is indeed not yet public. We considered to make it public before the last UI5Con, but found too many open questions / restrictions and decided to keep it private for now until we can offer a more appealing solution.


[FEATURE] 是否可以考虑下路由中可以想 laravel 那样动态添加命名空间

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

没有明白您的意思，请在 issue 内容上做详细的描述

请尽量补充一下描述


CNN-static

Hi thank you for shaping with your code.
When CNN-static work correctly, how many performance can we expect to get?
I got good performance of CNN-rand and CNN-non-static which are 88-90% after 5 epochs. However, CNN-static got around 65 after even 50 epochs.
In order to work CNN-static right, should I change some parameters?
If giving advice, I really appreciate you.

CNN-static has inferior performance. Try to increase embedding dimension.

There was a bug with weights embedding. CNN-static does much better, please see updated version.


Initial cmd state

Signed-off-by: Sergey Shlyanin<EMAIL_ADDRESS>Description
Clone cmd-nse-icmp-responder repository content and rename package to nse-istio-proxy.

@edwarnicke Thank you for your comments, I will check everything.

@edwarnicke Let us know if you still have any comments on this then we'll resolve them in separate PR.


Update Dockerfile - Remove unnecessary layers

Description

A clear and concise summary of the change and which issue (if any) it fixes. Should also include relevant motivation and context.
Resolved or fixed issue:
Affirmation

[x] My code follows the CONTRIBUTING.md guidelines

Hi @mohitsaxenaknoldus 👋
Thank you for the PR. 🙌
But I relatively sure that this should not have any effect to the number of layers / size of the resulting docker image.
The commands are only run on a intermediate image in our multi stage build. If you copy them to another stage they are automatically compressed into a single layer for the copy.
In intermediate stages I usually prefer to keep the commands separate to make it easier to identifier which is making problems if something goes wrong.


Rebind base parameter in PredicateBuilder instead of using Invoke

This is untested in this project.. in so far as all I did was change the code and commit it to see if it passes unit tests. It's based on a custom stripped down ExpressionBuilder I wrote earlier this evening.
Unless I have missed something, is there a need to use Expression.Invoke(...) here? All chained expressions will - should - have the same parameter shouldn't they?
Using the RebindParameterVisitor we should then be able to use the PredicateBuilder's predicates within Select, SelectMany and GroupBy selectors.
This, at least, works fine for me. However all I'm using this for is to dynamically filter out certain entities from my context. So there may be some more advanced use cases where this breaks everything!
Something like this contrived e.g.
    IQueryable<Purchase> GetPurchases()
    {
        var customerPredicate = PredicateBuilder.New<Customer>(true);
        var productPredicate = PredicateBuilder.New<Product>(true);

        if (true /* Some Statement */)
        {
            // Demo criteria to filter customers
            var customerIds = new int[] {1, 2};
            customerPredicate = customerPredicate.And(customer => customerIds.Contains(customer.Id));

            var fiveDaysAgo = DateTime.Now.AddDays(-5);
            purchasePredicate = purchasePredicate.And(purchase => purchase.Date >= fiveDaysAgo);
        }

        return dataContext.Customers.Where(customerPredicate).SelectMany(customer => customer.Purchases.AsQueryable().Where(purchasePredicate));
    }

Feedback please!

Unsure why appveyor hasn't update this commit, but it did pass all tests.

There are conflicts on this PR. @EdwardBlair could you fix that please?
I believe this is the correct approach, as replacing the parameters is much simpler than invoking and then bypassing the invoke via the query expander.

Thanks, updated 😄

For https://github.com/scottksmith95/LINQKit/commit/8b10932a12a97d78d013d3d4525eaf833290a4fa ?
No, I haven't. That's because I was calling the wrong base method in my overridden one -- a typo, not really something that should go wrong otherwise.
I can't do if you'd like!

New NuGet uploaded to https://www.myget.org/F/linqkit/api/v3/index.json
Please test, and if this is ok, I can publish to NuGet.org

@EdwardBlair Did you have time to test this?

I downloaded the package from myget and tested it in linqpad. Works as expected:
Account.Where(PredicateBuilder.New<Account>().Or(acc => acc.Id < 1).Or(acc => acc.FirmId > 4))

This throws with 1.1.8 but works with 1.1.9.

OK. I will publish to NuGet.


Parsing of search result ASN.1 objects

Warren,
Thanks for merging in my implementation of the StreamTransformer that converts bytes into LDAPMessages. The previous implementation assumed all the bytes of an entire ASN.1 object was available when the handleData method was called, but there is no guarantee that would be the case. In particularly, that was not true when I tried to connect to a TLS/SSL secured OpenLDAP server (the handleData method got called with the very first byte, and then called again later with the rest of the object).
What do you think about these things to be done:

I'm finding that LDAP search operations are quite unreliable, usually resulting in the application hanging. I think certain ASN.1 objects returned by a search are not being parsed/handled. This requires some low level work at the byte-level; possibly fixes in asn1lib too. Having said that, I've found the other operations (e.g. create, delete and modify) to work without problems so far.

Relating to item 1, if there are more results than the requested limit an exception is still thrown. I'm thinking that, if you asked for a maximum of 5 results and you got 5 back (even though there is more available in the directory) the search operation should not throw an exception.

For testing, we should define what entries are expected in the LDAP directory. Is there a desire to keep the existing tests working, or can we change them to work with a well defined test directory? I'm thinking of putting together instructions for a base-line deployment of OpenLDAP (which people can create easily in a virtual machine running CentOS) and making sure the integration tests work with that. Then we have a repeatable environment to start tackling item 1.

They claim the Dart formatter (dartfmt or ⌘-Shift-R in the Dart Editor) is better. Shall we run it on all the code to get them all into a consistent and repeatable style?

Hi Hoylen
I apologize that I have no time these days to  make improvements to dartdap.
I think all of your suggestions sound great.
Perhaps the best thing would be if I make you a co-contributor to the project. Then you can make direct commits.  Does that work for you?

Warren,

I think all of your suggestions sound great.
Perhaps the best thing would be if I make you a co-contributor to the project. Then you can make direct commits. Does that work for you?

Yes, that would work.
One of the things that should be done is to publish a new version to publ.dartlang.org (the current one there is the old 0.0.4). I’m not sure if permissions need to be given there. I’ll give it a go (probably in a few month’s time, to give Dart 1.9.x time to get widely deployed) and contact you if I run into problems.
Hoylen
http://www.hoylen.com

On the ASN1 parsing - the new transformer code has a lot of ASN1 specific knowledge. Is it possible to use any of the methods in the asn1 library instead? Or perhaps add some  utility methods in that library? It seems to me that any knowledge of ASN1 encoding should be encapsulated in the asn1 lib...
If there are not enough bytes to make a valid ASN1 message - can we detect that by just saying anything less than say 20 bytes (what would the shortest possible LDAP message ever be?) - then just put those bytes on the not processed queue and exit the do loop.  That might be simpler than trying to parse the asn1 header bytes? I guess it has to cover all contingencies.

I can't see any method in asn1lib that was suitable, since they all appear to deal with complete ASN1 objects.
I agree that adding ASN1 encoding related knowledge to asn1lib would be better. Essentially using the code in lines 38-68 from ldap_transformer.dart. Maybe putting that check into all of the "fromBytes" constructors for all the different ASN1 objects. Those constructors could throw a new incomplete-message exception if not enough bytes had been passed to them. You'll need a unique exception for it, so that the transformer can catch it and wait for more bytes to arrive.
I wouldn't hard-code 20 bytes into it, especially if it is going into the asn1lib package: legitimate ASN1 objects could be less than 20 bytes long. Even if we are dealing with only LDAP messages, hard-coding 20 bytes would be wrong: for example, if the complete LDAP message was 21 bytes long, trying to parse it when only 20 bytes have arrived in the buffer would still fail.

How would this work as a heuristic:

Look for at least N bytes, where N == the smallest possible message size. If you have less then this - you dont have a valid LDAP message -might as well wait for more bytes ( I'd think N would be at least 10 - but you could in theory make it less).

If you have more than N bytes, then see if you have enough  bytes to make a valid ASN1 object.

The method
var x = ASN1Length.decodeLength(bytes);
x.length - tells you how many bytes the object is. If you have less than x.length bytes - not all of the bytes of the ASN1 object have been sent. So put the bytes on the buffer and wait.

Heuristic
I'm not seeing how the heuristic makes it easier than implementing it correctly. The heuristic still requires handling the fallback case of "then seen if you have enough bytes to make a valid ASN1 object" (which is essentially implementing it correctly).
So just implement it correctly and it's done. That is, I'm saying "if (bytes<N) doA else doB" is better implementation as simply "doB" when the outcome is exactly the same.
The method
The method described currently will not work, because the current implementation of ASN1Length.decodeLength assumes there are enough bytes to specify the length. For example, it currently fails when only one byte (the tag) has been received. If decodeLength was fixed, to detect and signal when there aren't enough bytes to even determine how large the object is, this would work.
This approach does depend on the user of asn1lib to check the length before calling any of the ASN1 object constructors. Depending on humans doing the right thing is always risky! But it is certainly an easier and quicker fix than adding the length check to all of the ASN1 constructors to make them safer to use.
Actually, it could work with the current decodeLength, if the user was prepared to catch a RangeError exception and make an implementation-dependent assumption that it will always means "wait for more bytes to arrive". But without specifying this is the behaviour of the decodeLength method, there is no guarantee to the user that this will always work (e.g. a future implementation of decodeLength might throw RangeError in other situations as well). Better to fix decodeLength to have a well defined behaviour when there are insufficient bytes.
This "fix" to decodeLength could simply be documentation (that throwing RangeError is the guaranteed behaviour). But I still think throwing a special "insufficient bytes" exception is much better, since it is hard to promise that RangeError will never ever be thrown in any other situation.

A useful method for asnlib (read_element?)  would be one that tries to parse a 'partial' block of data, and which tells the caller to read 'n' more bytes. The caller (dartdap) loops (extending the buffer) until read_element returns 0.
read_element would do something like this:

if no data, return 2 (a tag byte, first length byte)
if 2 bytes, look at the first length byte:
** if we have < 0x80 that's the length: return it
** if it is 0x80 we have indefinite length encoding - can't handle that so give up.
** if it is 0x81 we need one more byte for the length: return 1
** if is it 0x82 we need 2 more: return 2
** if it is 0x83 we need 3 more: return 3
** if it is 0x84 we need 4 more: return 4
** otherwise give up
decode the actual length: return it

So in the best case the caller just needs to issue a read for 2 bytes, and another read to get the rest of the element.

Knowing the number of bytes needed would be useful of we are controlling the reading of the bytes from a file.
In the current implementation of dartdap where the bytes come from a stream, we would only need to know if that number is zero or not. Since we can't control how many bytes the stream will give us next.
For safety, the ASN.1 object constructors and/or ASN1Length.decodeLength should still have some well-defined behaviour if the caller forgets to make this check and passes in insufficient bytes. If that happens, then knowing the number of extra bytes needed is optional.
Since constructors can't return another value, maybe the best approach is to define an "insufficient-bytes" exception class that also indicates the number of bytes that is needed -- the best of both worlds. Let's do that... and implement correct handling of multi-byte tags (though this is really a topic for asn1lib rather than dartdap).

OK - does this work?

If you have 1 byte - save it and wait for more (you just have a tag)
If you have at least 2 bytes or more:

Try to decode the length
Be prepared to catch a RangeError (or insufficient bytes as above) exception if the asn1 library can't  decode the length (missing bytes).  If you get this exception, save the bytes and wait for more

If the length decodes OK - then see if your buffer has that number of bytes.  If yes - then decode the ldap message. Save any left over bytes for the next iteration. If you do not have enough bytes, save the current bytes and wait for more.

Concurrent to this the response timeout should kick in if the library does not see a server response.
Does the above work?
The only change that would require is range checking in  decodeLength method in asn1

Chris / Hoylen
I just committed a change to a new branch (ldap-transformer) that I think simplifies things a bit.
The good news is that the asn1lib does not need changing (but I did add a unit test).  The decodeLength method will throw a RangeError when it does not have enough bytes.
Check out the new transformer and let me know what you think

The parsing bug (1) and documented unit test environment (3) have been addressed by today's commit (19 February 2016).
I'll leave this issue open until I've reformatted the code (item 4) and a refactoring of where and when exceptions are thrown (item 2). There seems to be some inconsistencies in where result codes are returned versus where exceptions are thrown.

The exceptions that are thrown have been tided up (item 2), and the code reformatted using the Dart tools  to ensure consistency (item 4), in pull request #11.
Closing this issue since all the items on it have now been addressed.


Link creation not posible in spaces

Describe the bug
Create a link over an item using the direct link button is not posible inside an space. My guess: something related with mandatory password
Steps to reproduce

In oCIS account, open any space that is not Personal
Click on

of any item to create a link.
Actual behavior
Nothing happens. But, opening the 3-dot-button and clicking over Share and then Create Link, it works
Expected behavior
Any user action must be replied with another action. In this case, creating the link or showing the password dialog if that option is mandatory
Additional context
Tested over ocis.owncloud.works:
ownCloud Web UI 8.0.0-alpha.10
index.html-LqZ16May.mjs:1  Infinite Scale 5.0.0-alpha.3+5d00b45b9 Community

@jesmrec thanks for reporting. I could reproduce it.
it's web issue so I move it to web
web send GET https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares?path=%2Ff1&include_tags=false&share_types=3 request instead of POST sharing request
https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares
https://github.com/owncloud/ocis/assets/84779829/3f2de41c-19e0-4a45-86e9-a159f14cae65
it's a gap in test coverage. We have test to quick link in personal space. TODO need to add for project space


reset reason: protocol error

Bug Description
upstream connect error or disconnect/reset before headers. reset reason: protocol error
Gateway:
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  generation: 4
  name: myapp
  namespace: rocketmq
  resourceVersion: "23218819"
  uid: 1c67e3d3-af31-4e62-ab29-c41ba6c49780
spec:
  selector:
    appc: istio-ingressgateway-debug
  servers:
  - hosts:
    - myapp.abc.cowelltech.com
    port:
      name: http2-myapp
      number: 80
      protocol: HTTP2

VirtualService:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  generation: 3
  name: myapp-test
  namespace: rocketmq
  resourceVersion: "23214040"
  uid: c35d0e1a-0d30-41db-b9be-0ef1170773c0
spec:
  gateways:
  - myapp
  hosts:
  - myapp.abc.cowelltech.com
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: myapp
        subset: v1

DestinationRule:
kind: DestinationRule
metadata:
  creationTimestamp: "2021-09-27T10:12:45Z"
  generation: 1
  name: myapp
  namespace: rocketmq
  resourceVersion: "23213260"
  uid: 68e3b959-0948-4f08-a0a4-590ea3f1c77d
spec:
  host: myapp
  subsets:
  - labels:
      app: myapp
    name: v1
  trafficPolicy:
    connectionPool:
      http:
        h2UpgradePolicy: UPGRADE
    loadBalancer:
      simple: LEAST_CONN

Service:
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: rocketmq
  resourceVersion: "23201782"
  uid: 0e23f054-5e09-4405-9115-f1b48acb2c5a
spec:
  clusterIP: <IP_ADDRESS>
  clusterIPs:
  - <IP_ADDRESS>
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - appProtocol: http2
    name: myapp
    port: 8000
    protocol: TCP
    targetPort: 8000
  selector:
    app: myapp
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Version
client version: 1.11.0
control plane version: 1.11.0
data plane version: 1.11.0 (59 proxies)

Client Version: v1.22.0
Server Version: v1.22.0

Additional Information
No response

This general means you are not sending well-formed http requests. Turn on Envoy debug logs to get more info

Any update on this? We are facing the same issue. The upstream connection is getting reset after the response has been started.
[2021-11-07T12:06:36.161Z] "GET /api HTTP/1.1" 200 UPE upstream_reset_after_response_started{protocol_error} - "-" 0 43707 3 2 "<IP_ADDRESS>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36" "4f6928b9-9936-4617-ade1-eb486e2054bf" "demo:9002" "<IP_ADDRESS>:9002" outbound|9002||demo.demo.svc.cluster.local <IP_ADDRESS>:35164 <IP_ADDRESS>:9002 <IP_ADDRESS>:3235 - -

I also meet this issue, what diffrent is that I use http1.1. Here is a service downloading files, when I run it locally, all is right, but in istio, the error occored. upstream connect error or disconnect/reset before headers. reset reason: protocol error

Any update on this ?


The default version specified for the cluster does not support ODF maybe 4.7.40_openshift

In the docs I was exploring the path towards installing the ODF, Deploying OpenShift Data Foundation on VPC clusters  which led me to
https://cloud.ibm.com/docs/openshift?topic=openshift-clusters#clusters_vpcg2
https://cloud.ibm.com/docs/openshift?topic=openshift-templates&interface=ui
https://cloud.ibm.com/docs/openshift?topic=openshift-templates&interface=cli
which led me to this repository.  after this using this repo I went to install ODF and the first command:
modules $ ibmcloud oc cluster addon versions
OK
Name                        Version           Supported Kubernetes Range   Supported Openshift Range
alb-oauth-proxy             1.0.0             >=1.16.0 <1.22.0             unsupported
alb-oauth-proxy             2.0.0 (default)   >=1.19.0                     unsupported
cluster-autoscaler          1.0.3             >=1.17.0 <1.22.0             >=4.3.0
cluster-autoscaler          1.0.4 (default)   >=1.19.0 <1.23.0             >=4.3.0
debug-tool                  2.0.0 (default)   >=1.13.0                     >=3.11.0
hpcs-router                 4.6.0             unsupported                  >=4.6.0 <4.7.0
hpcs-router                 4.7.0 (default)   unsupported                  >=4.7.0 <4.8.0
hpcs-router                 4.8.0             unsupported                  >=4.8.0 <4.9.0
image-key-synchronizer      1.0.0 (default)   unsupported                  >=4.4.0
istio                       1.11              >=1.19.0 <1.23.0             unsupported
istio                       1.10              >=1.18.0 <1.22.0             unsupported
istio                       1.12 (default)    >=1.20.0 <1.23.0             unsupported
openshift-data-foundation   4.8.0             unsupported                  >=4.8.0 <4.10.0
openshift-data-foundation   4.7.0 (default)   unsupported                  >=4.7.0 <4.9.0
static-route                1.0.0 (default)   >=1.14.0                     >=3.11.0
vpc-block-csi-driver        4.1 (default)     >=1.19.0                     >=4.6.0
vpc-block-csi-driver        3.0.1             >=1.15.0                     >=4.3.0
vpc-block-csi-driver        3.0.0             >=1.15.0                     >=4.3.0
vpc-block-csi-driver        4.0               >=1.17.0                     >=4.3.0

This indicates that openshift-data-foundation   4.7.0 (default) requires 4.7.0 but the default in
variable "ocp_version" {
  type        = string
  description = "Specify the Openshift version"
  default     = "4.6.23_1540_openshift"
}

Which no longer exists.  So the latest 4.6 release was chosen (4.6.48_1570)?
And it is not 4.7 so it is not compatible with my original intention of installing ODF.  It seems like 4.7.40_openshift would be a better option?

@powellquiring
Analysing the issue


Android: Initialize mouse mode

All display servers initialize mouse mode to visible which not doing so make things not checking it correcty (specificly the editor)

Thanks!


[FSDE-18245] Migrate Date Picker component to vue documentation

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/1/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/2/. :white_check_mark:

You can check this PRs instance in https://a638b776a49d5ca5dfef3f744bc1002633901162-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-377-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/3/. :white_check_mark:

You can check this PRs instance in https://8001ad251086eecb34ad490b52fd7a3ed4062b20-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-377-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/4/. :white_check_mark:

You can check this PRs instance in https://e102c983f700a9be76d1176af474c9f29d68aa12-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-377-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/5/. :white_check_mark:

You can check this PRs instance in https://54c7c7b5a0607ffe6935db97288942c28d701bf8-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-377-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/6/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/7/. :white_check_mark:

You can check this PRs instance in https://ac812ea8d296bce39f5eacdfc81814842195ff39-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-377-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/8/. :white_check_mark:

You can check this PRs instance in https://ef0108da3bb229e96454c76c7174c1a89bc2f309-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-377-ux-chi.kubeodc-test.corp.intranet/ (internal)

Check each ID in each example and follow the example__component_case convection please.

The CI pipeline has run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/10/. :white_check_mark:

You can check this PRs instance in https://91657bd4ac45cc286f97e384b6a3b338503abea2-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-377-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline has run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/11/. :white_check_mark:

You can check this PRs instance in https://6aa60f584aa6b1d9e3abb47eb1a2c2d5c60295b6-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-377-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline has run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-377/12/. :white_check_mark:

You can check this PRs instance in https://f84c3ffc689df7048deb5e5a0c58e347400adc1c-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-377-ux-chi.kubeodc-test.corp.intranet/ (internal)


Proposal: add customizable app_client_class config value

Here's a solution that could give people the freedom to pull manifest.json files from any external location.
This was heavily inspired by a similar feature in django-webpack-loader: https://github.com/django-webpack/django-webpack-loader/pull/210. It's addressing the same user issue that we have, some people wanted to load their manifests from external urls. Instead of supporting every bespoke source that a manifest.json could be generated from, django-webpack-loader added the ability for users to plug in their own loader classes that had their own retrieval mechanisms.
This PR gives an example of that in test_custom_app_client.py. (Admittedly, this implementation is a little messier than django-webpack-loader, since we have to go through a second static class.)
There are probably ways to make this cleaner. I'm open to any suggestions.
Related: https://github.com/MrBin99/django-vite/issues/105

This worked really well to prove out that we could move from webpack/django-webpack-loader to vite/django-vite. It was smooth sailing with the app_client_class setting override.
As an idea for simplification, if manifest_path was able to discern/check for a URL or Path (or some other combination with a manifest_url setting) would the changes and inclusions for a custom ManifestClient not be required? My understanding is load_manifest in vite-land is always going to be looking for a .json file it is just a issue of where that file lives. ManifestClient would remain part of the library as long it gets pointed to the correct place to look via a setting instead of via inheritance. There is maybe similar arguments to be made with the two get_*_server_url but that might be overdoing it.


Nozzle sends more than 200 time series in a single request

With nozzle built from develop branch and the default metrics_buffer_size set to 200 I am seeing the following errors from Stackdriver:

code = InvalidArgument desc = Field timeSeries had an invalid value: A maximum of 200 TimeSeries can be written in a single request.

I believe this is caused by the fact that metrics_buffer_size limits the number of MetricEvents passed to the metric adapter, however each MetricEvent can have multiple metrics (which share the same labels). As the result, 200 MetricEvents can result in more than 200 TimeSeries in a CreateTimeSeriesRequest.
There should probably be a stricter check that ensures that CreateTimeSeriesRequest always conforms to API restrictions and does not have more than 200 time series.

Great catch. I'll take this one.

The batching should be moved into the MetricAdapter so we can have that stricter check.

Just to add $0.02 here, since you're refactoring this code anyway: IMO the current abstraction provided by MetricEvent is not quite correct, because associating a list of {timestamp, value} Metrics with a label set forces you to jump through some otherwise unnecessary hoops.
I think it would be better to skip having nozzle-specific Metric and MetricEvent structs completely and just use stackdriver protos throughout the nozzle, since that's the representation you need to use eventually. Converting to a slightly different internal representation in one place and then converting to the sd representation later adds unnecessary complexity.

I don't like the complexity and would like to overall simplify this system where possible. We do send messages.MetricEvent to Stackdriver Logging so it's not necessarily in the format we need everywhere, but the stackdriver protos would probably do just fine in the log output even if it's a bit noisy.
You're right that timestamp doesn't at all belong in Metric. I'm making the following moves:

move messages.Metric.EventTime -> messages.MetricEvent.Time
rename messages.Metric -> messages.DataPoint

I'll think more on the proto problem. The plus side today is we don't have coupling between the metric processing/ingestion and the proto format of Stackdriver. A nice seam if we need to upgrade API versions. But this is the Stackdriver Nozzle so coupling doesn't seem unwarranted.

From a brief examination I couldn't see where MetricEvent was sent to SD logging, can you give me a link?
I should have been clearer before, I was strictly talking about using SD protos for the metrics side of things. IMO for logging purposes we'd want to mutate the protos coming from the firehose as little as possible. And FWICS that's what you're doing, translating them into a map[string]interface{} that can be marshalled to JSON, and then using that map as the payload.
As for metrics: no, that's not what I was saying -- the timestamp definitely belongs with the value. The way stackdriver models a timeseries is the way we've done it internally since borgmon days: a timeseries is a list of {timestamp, value} points associated with a single metric name and a key=>value label set. (In fact the metric "name" was just a label with the name "var" in borgmon days.)  This is pretty much the same model that OpenTSDB and InfluxDB (allows a list of values per timestamp), to name two other TSDBs, use.
Your approach associates  >1 metric names and {timestamp, value} lists with a label set, which should be ~fine most of the time but caused the problem with batching being incorrect, because for container metrics you were publishing 6 timeseries per MetricEvent. In general I think you're going to run into these sorts of minor impedance mismatches occasionally when you deviate from the data model that your storage medium is using, which is why I propose the move towards using SD protos as consistently as possible for Metrics.

Here's where MetricEvent is sent to Stackdriver Logging.
When I first implemented sending 'Metrics' to Stackdriver Logging I was writing the payload directly from the firehose to Stackdriver Logging. I backed away from that because the frequency is so high (multiple ContainerMetrics/second for a single instance).
The weird case is is when we take in an events.Envelope that produces several time series (eg cpuPercentage, memoryBytes). When we do that, we have a single MetricEvent with multiple values but the values all share the same {labels, timestamp}
We could change that though. We could treat them all as individual things. Drop MetricEvent, DataPoint and write out a monitoring.TimeSeries for each value here. I can't think of why not to do it beyond pretty formatting in Stackdriver Logging.


docs: improve database

Description
Fixes #6727

add note of dots in database/table/column names
fix RST format

Checklist:

[x] Securely signed commits
[] Component(s) with PHPDoc blocks, only if necessary or adds value
[] Unit testing, with >80% coverage
[x] User guide updated
[] Conforms to style guide

Probably supporting dots is impossible with the current implementation.


Mapzen Android SDK vs Tangram Android SDK

Hi Mapzen!
Right now I'm reading through Tangram ES, the Tangram Android SDK, and the Mapzen Android SDK. I'm noticing a bit of an overlap between the Tangram and Mapzen SDKs. For example, There are Polygon classes that are different but seem to have the same role in both:
https://github.com/mapzen/android/blob/master/library/src/main/java/com/mapzen/android/model/Polygon.java
and
https://github.com/tangrams/tangram-es/blob/master/android/tangram/src/com/mapzen/tangram/geometry/Polygon.java
Could you explain the reason behind this overlap and the overall relationship between these two SDKs? I understand that the Mapzen Android SDK is a wrapper for the Android bit of Tangram ES (the Tangram Android SDK), but I'm not fully clear on the specific intentions of that relationship.
When should I use the straight-up Tangram Android SDK, and when should I use the Mapzen Android SDK?
Cheers,
Nick

Hi Nick!
The Mapzen Android SDK is where you can find all things Android by Mapzen. So, there is the Tangram project but also LOST and on-the-road, two other open source projects we wrote. The Mapzen Android SDK unifies these projects and provides convenience methods for doing actions such as setting api keys (see the documentation here: https://github.com/mapzen/android/blob/master/docs/getting-started.md or use MapView directly), map styles, and map overlay elements.
The Mapzen Android SDK provides access to the underlying Tangram MapController so you can use its advanced APIs directly (see https://mapzen.com/documentation/tangram/android-walkthrough/ and https://mapzen.com/documentation/tangram/Scene-file/) or, if you only need Tangram, you can use its Android SDK instead of the Mapzen Android SDK.

Thanks Sarah, makes sense!


Revert " react-menu | extract the style to an external css"

Reverts kenshoo/react-menu#55
@kenshoo/uiinfra bring back normal styling

This has the BREAKING CHANGE prefix: https://github.com/kenshoo/react-menu/pull/70


Question 1.2 for loop missing a return keyword

function findMissingNumber(arrayOfIntegers, upperBound, lowerBound) {
  // Iterate through array to find the sum of the numbers
  var sumOfIntegers = 0;
  for (var i = 0; i < arrayOfIntegers.length; i++) {
      return sumOfIntegers += arrayOfIntegers[i];  <---- this is the missing return keyword
  }

  // Find theoretical sum of the consecutive numbers using a variation of Gauss Sum.
  // Formula: [(N * (N + 1)) / 2] - [(M * (M - 1)) / 2];
  // N is the upper bound and M is the lower bound

  upperLimitSum = (upperBound * (upperBound + 1)) / 2;
  lowerLimitSum = (lowerBound * (lowerBound - 1)) / 2;

  theoreticalSum = upperLimitSum - lowerLimitSum;

  return theoreticalSum - sumOfIntegers;
}

Hi @misstonbon, from quick glance, it would seem that the function will be exited on the first attempt into the for loop, and the rest of the logic will not be initiated. Are you able to explain why you think a return is missing?

Hello,
I have indicated the missing return keyword above.
Thanks for providing good interview prep questions.


stepper enable/disable

it is handy to turn off the stepper to reposition.  add this to the GUI and make a physical button/switch option.

also handy to turn off the stepper for manual use, my lathe's leadscrew has a handcrank at the opposite end which I do use on occasion, especially since I don't have a carriage lock. Would need a spindle resync, and should probably block the action and throw a warning if a threading mode is active. Also maybe make this a configurable parameter because some drivers are not safe to back-drive very much, high voltages can be generated by the stepper. Most of the nena23 are, but some of the 3d printer based nema17's drivers get really angry.


Fix marshmallow OpenAPI 3.x.x support.

There were some hardcoded variables in flasgger/marshmallow_apispec.py so it won't work with openapi 3.x.x standart correctly even if version was specified for Swagger object and just generated wrong $refs (e.g. #/definitions/... instead of #/components/schemas/..., though the schemas themselves were placed correctly in components/schemas).

Thank you. I will test it in a separate branch first.


examples not work

https://github.com/mozilla/pdf.js/blob/master/examples/components/pageviewer.js
I follow the example in up link.But why I cannot find the pdfjsViewer constructor.
var pdfPageView = new pdfjsViewer.PDFPageView({       container: container,       id: PAGE_TO_VIEW,       scale: SCALE,       defaultViewport: pdfPage.getViewport(SCALE),       // We can enable text/annotations layers, if needed       textLayerFactory: new pdfjsViewer.DefaultTextLayerFactory(),       annotationLayerFactory: new pdfjsViewer.DefaultAnnotationLayerFactory(),     });
Is that mean the examples is not in line with the new version?
Another issue,
pdfjsLib.GlobalWorkerOptions.workerSrc =   '../../node_modules/pdfjs-dist/build/pdf.worker.js';
GlobalWorkerOptions is not defined

That example works for me, and with the (currently) lack of any details it's basically impossible to tell know why you weren't able to get it to work. You'll need to provide detailed information about exactly what steps you took, since otherwise no one will be able to help and the issue will be closed as incomplete.

That example works for me, and with the (current) lack of any details it's basically impossible to tell why you weren't able to get it to work. You'll need to provide detailed information about exactly what steps you took, since otherwise no one will be able to help and the issue will be closed as incomplete.

Most likely you did not run gulp dist-install before opening the example. As indicated above, you'll need to provide more information about the exact steps taken for us to be able to help.


Ortho tiles not showing since 12.0.9 scenery update

Describe the bug
AO tiles not showing
To Reproduce
Steps to reproduce the behavior:
Run as normal
Expected behavior
Tiles load as normal, no tiles loading
Screenshots
n/a
(please complete the following information):

OS: [e.g. Windows 11]
XPlane Version: 12.0.9 RC4 (w Scenery update)
AutoOrtho Version 0.7.1
Filesystem type NTFS

Additional context
Checks complete in log and everything checks out ok
Seems to be 'miss chunk' for each tile in the log

I'm in the same system and X-Plane version and everything works like before. Double-check your AO installation, particularly in your Custom Scenery folder if you miss any z_ao_xx or the yAutoOrtho_Overlays folders. Also, check if you have any interfering custom sceneries/ortho/overlays around the airport/area you are testing.

Hi Sam, I tried what you suggested. The Xplane 12 worked perfectly once but after a restart it again gave errors. The same working perfectly for Xplane 11 but not for 12.

I can confirm ortho works, problems are:
low res/pixelated tiles, would be nice to be able to increase quality
no seasons support
tested multiple times heathrow airport tiles fail to download, doesn't matter what map source


cache-dir on a builder has a 40 GB cache of dart-lang/SDK - how is this possible

File this as an issue with chrome-infrastructure-team, to get their input.
This filled up a 60GB drive, and caused the builder to fail.
Here is the result of df -k -d1 in the cache-dir
...
1013228	cache_dir/chromium.googlesource.com-external-github.com-dart--lang-co19
2965224	cache_dir/boringssl.googlesource.com-boringssl
40016532	cache_dir/chromium.googlesource.com-external-github.com-dart--lang-sdk
45689664	cache_dir

There was already an issue filed about this, and a fix, replacing these machines by others.  The underlying problem was not fixed - this will happen on machines with disks under 100 GB.


Temporary freeze on close

Environment
Windows build number: 10.0.18363.0
Windows Terminal version (if applicable):  0.10.781.0

ssh.exe:  <IP_ADDRESS>

Steps to reproduce

Start ssh.exe against any ssh host
While at the login prompt, simply close the tab

Expected behavior
Tab either closes immediately OR terminal lets me interact with other tabs while waiting for ssh.exe to clean up.
Actual behavior
ssh.exe lingers for about 5 seconds. During these five seonds the terminal window freezes and no interaction with other tabs is possible.
Pressing ctrl+c first will terminate ssh.exe immediately, so the issue doesn't manifest itself then. If I had completed the login first, then I'd also avoid this phenomena.

Thanks for the report! This is a /dupe of #1996, which we have a couple ideas on how to solve. Right now, we're serially waiting for a tab to close in all cases, when we could probably wait only in the full application teardown case (or hand its connection off to a background thread for summary destruction.) We used to murder processes instantly when you closed the tab, but that turned out to be really bad.


[regtool] Add reset values for hwext registers to reg_pkg

The result (for AES) looks like
// Default values for hwext registers
parameter logic [1:0] AES_ALERT_TEST_DEFAULT = 2'h 0;
parameter logic [31:0] AES_KEY_SHARE0_0_DEFAULT = 32'h 0;
parameter logic [31:0] AES_KEY_SHARE0_1_DEFAULT = 32'h 0;
parameter logic [31:0] AES_KEY_SHARE0_2_DEFAULT = 32'h 0;
...

Doing this means that design code can look in FOO_reg_pkg to set its
reset value as declared in the hjson, avoiding needing to duplicate
any constants by hand.
Fixes #5086.

@Jacob-Levy: Does this do what you need?

Yes :)

What is done with multiregs with regards to the "C' defines file?
That's were I got _DEFAULT from... and you can change it to _RESVAL :)

Well, the "default" name comes from the hjson format. But I agree it's not great. I don't have strong feelings: happy with either.
Re multiregs, admittedly I hadn't really thought about this. Unfortunately, doing something nicer is difficult. The problem probably comes from compaction. If I have a multireg that contains a single 16-bit field, has the compact flag set, and has a replication count of 5 then I'll get 3 registers generated. The first two will have 2 copies of the field each and the last will have just one. If the register had reset value 0x1234, the register reset values are 0x12341234, 0x12341234 and 0x00001234, respectively. What should be the reset value? I think I'd probably suggest just generating all three. Code that knows they are all equal can just use MY_BLOCK_FOO_0_DEFAULT or whatever.

What works for the 'C' defines can work for the design part too.

Thanks @rswarbrick and @Jacob-Levy for getting back. I agree, the cleanest solution is to generate all multireg values and then the designer has all the possibilities (as we do already for the C defines - didn't think about that before). The array/loop thing is definitely not an option.
I am fine with this but would prefer the change from _DEFAULT to _RESVAL.

I am fine with this but would prefer the change from _DEFAULT to _RESVAL.

Sounds good to me. Renamed!

Just checked the released 'regtool' and the implementation does not  what I expected..,
The reset need to be per field of each of the register like in the 'C'  define file.
The implementation of the HWEXT is based on each register field.

Also something is not working for generating the 'C' define file...
% ${WA_ROOT}/opentitan/util/regtool.py -T -o ./aes_regs_def.h ../../../opentitan/hw/ip/aes/data/aes.hjson
Traceback (most recent call last):
File "/tanap1/proj_cd14/opentitan/jlevy/ot.work/opentitan/util/regtool.py", line 236, in
sys.exit(main())
File "/tanap1/proj_cd14/opentitan/jlevy/ot.work/opentitan/util/regtool.py", line 228, in main
return gen_ctheader.gen_cdefines(obj, outfile, src_lic, src_copy)
File "/tanap1/proj_cd14/opentitan/jlevy/ot.work/opentitan/util/reggen/gen_ctheader.py", line 103, in gen_cdefines
if 'reserved' in x:
TypeError: argument of type 'Register' is not iterable

In the .hjson the resval are per field and need to stay that way,. BBB_RRR_FFF_RESVAL.
In the bbb_reg_pkg.sv I found BBB_RRR_RESVAL for the full register bits.

Ah, right. Yep, we can do that too. I'll push up a PR to add that information in a minute.

Also something is not working for generating the 'C' define file...

Yeah, that bug is my fault, but it's in the "old-style" C header generation that I'm trying to delete in PR #5184. If that PR doesn't succeed, I'll fix it properly. Anyway, you probably want to run with -D rather than -T.

Field information exposed in PR #5252.

The -T is better option as 'C' define file it term of the information per register...
I wanted to generate the define that has  the  _DEFAULT, which are the fields reset.
They need to be generate as _RESVAL  Verilog parameters format in the package.

I'm sorry, I don't quite understand what you wrote. Aren't you using this in design code? What information do you need that isn't exposed in the (SystemVerilog) package file?

hjson -> -r -> ast_reg_top/pkg.sv
hjson -> -T -> script->  ext_pkg.sv    (Will be dropped once you release your version)

Oh, I see! Cool, the version with fields should be merged in an hour or so. Annoyingly, it's been failing CI because of a transient bug to do with how we run git to find a merge-base.

Will check it as soon as it get released :) Thanks!


Exception: cannot modify header information on order success

When doing a successful payment I get this error message:
report.CRITICAL: Warning: Cannot modify header information - headers already sent by.....
It is caused by this line:
This line: https://github.com/buckaroo-it/Magento2/commit/55c956386b8dc76d56cfe546c92801356c60a047#diff-ce9300638a4365768718bcc7a10fd42951834288566d775b5a9591b6aa275e3cR68
To me it seems as some developer debug code and stops me from returning to the success page of the shop.

Hello @arnoudhgz   .Thank you for your issue. Yes it already fixed https://github.com/buckaroo-it/Magento2/commit/533c1f1c3a5aea9d1d52817f4dcae2933bb8bbfe and prepered to release

@saranchuk-hys thanks!


Extract creation of snitch_all.hpp into Python script

This PR ports the creation of snitch_all.hpp from CMake to Python, so the header can be produced without CMake. This will help adding support for other build system (see #54).

Codecov Report

Merging #55 (758451c) into main (198d5dc) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #55   +/-   ##
=======================================
  Coverage   92.75%   92.75%
=======================================
  Files           2        2
  Lines         994      994
=======================================
  Hits          922      922
  Misses         72       72

Continue to review full report at Codecov.

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


[dv_hmac] little more support on hmac_tx_empty

This assumes tx_empty will trigger only during reg_hash_start and
reg_hash_process
Signed-off-by: Cindy Chen<EMAIL_ADDRESS>

Hi Eunchan,
Sorry the HMAC DV is not that flexible to adopt the fifo_full to fifo_empty change. I made a little bit change and will update again once your RTL spec is finalized.


Implement Groups Create

Reference: https://api.slack.com/methods/groups.create
Acceptance Criteria:

[ ] Spring Slack Client is extended with given method
[ ] Spring Slack Test Client is extended with given method
[ ] JavaDoc/KDoc is added

closed by #296


Create Topic Design

Topics in Agora function much like notes in other App. Work on a design for the page that writes text. Look into the sun editor used by Agora to see its limits in regards to design. Consider custom right click options or / commands for the application.

Completed


Add d3.select().change()

Some common jQuery code:
$("select").change(function(){
 // do something
});

This would be a useful function to add to this library.

I suppose there's already
d3.select("select").on("change", function(){
  // do something
});

But I think the suggestion would still be a slight improvement.

Right !


Fix to support angularjs 1.2.1

Changed to jQuery empty() method to support angularjs 1.2.1

This package is a pure angular implementation and doesn't require jQuery, therefore your fix is not acceptable. Plus PR doesn't properly introduce jQuery into package dependencies, even if it would be acceptable.
@yoavaa


kosmos start not ok yet

multiple types ssh-add

something wrong I would say
too slow

lets do some benchmarking
check init main one of jumpscale there is tooling for it there

I think certain things are happening / waiting too long
with --debug there should be more logging

everything should be logged to console then

Current progress

Fixed redundant calls of ssh-add and similar stuff caused by check function.
Fixed broken socket or inactive ssh-agent.
Now working on kosmos start with different ssh-key than id_rsa


Add a switch to automatically release on every PR

Raising the fix number usually means a bug or security fix and I see no reason to hold back in releasing a NuGet with it. This might differ from one project to another. The best way would be to have a switch for the action to choose whether to automatically release on finishing a PR. Default behavior would be false so the current behavior would not change when updating the action.

Declined. We already get beta builds automatically that way.


Typos in def of GO_0005903 brush border

GO_0005903 brush border
"The dense covering of microvilli on the apical surface of a epithelial cells in tissues such as the intestine, kidney, and choroid plexus; the microvilli aid absorption by increasing the surface area of the cell."
should read
"...on the apical surface of an epithelial cell ..."
Thanks,
Paola

Thanks for reporting this @paola-scibite

Thanks for reporting this @paola-scibite


Automatic opening of latest email

Hiya,
Feature idea:
A toggle for enabling automatic opening of an email. I create the visual design for my emails by using mailcatcher. I have a script that generates and sends my email, then I switch to mailcatcher and look how it looks. I know it's not most complete solution but I have relatively simple stylesheet, so it works good enough for me, switching between console and browser is no issue.
This feature would save a one mouse click since the newest email would be opened. It's a task repeated constantly when designing an email layout. It's almost same as hitting refresh on your browser when developing web stuff.
Here is a mock up of my idea, sorry for elements not aligned perfectly... 😺

Anyway, that's my idea

Duplicate of #266, closing


Update deploy workflow to use environments

We only need one deployment workflow. Delete the beta deployment workflow and update the production workflow to use github environments.

@sblack-usu and @pkdash - The next planned release of the I-GUIDE Platform is targeted for end of July 2024. Is this something we can sort out for a Catalog release at that time since we will need to do a deployment?


Fix pinch zoom layer moving

Old: link
New: link
The src file: link

Fixes #7401
Fixes #7072
Fixes #6395
Fixes #7466
Closes #7073

Maybe fixes issue #6099 but needs tested and then it makes maybe #6126 obsolete
Remaining: #7915
Old:

New:

@Falke-Design There were a few syntax errors in https://github.com/Leaflet/Leaflet/pull/7965#issue-837712011 that would result in some issues not closing once this is merged, and some issues closing that isn't decided yet if they should be. I took the liberty to edit it, I hope you don't mind. 🙏🏼

No I don't mind 😉 I give it up to use the syntax for PRs with multiple issues, because sometimes it worked and sometimes not. In the Repos where I have enough permission I add the issues manually to the linked section and else I go through them after closing. But it worked with your changes, so all is good 😄
I saw already last week that you closed some issues and didn't know that you have permission. Did you get the permission currently or did I just not know that you also have rights? 😄 Anyway nice to have you in the Team 😉

@Falke-Design

I give it up to use the syntax for PRs with multiple issues, because sometimes it worked and sometimes not.

For multiple issues there must be a keyword ("fixes", "closes", etc.) before each issue number, that's all. 😋

nice to have you in the Team

Thanks, @mourner invited me as a collaborator last week.

Manual Test for performance:
it.only("test", function (done) {
			map = new L.Map(container, {
				dragging: true,
				inertia: false
			});
			map.setView([37.8, -96], 4);
			window.map = map;

			L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png').addTo(map);

			for(var i = 0; i < 100; i++){
				L.geoJson(statesData, {
					attribution: 'Population data © US Census Bureau'
				}).addTo(map);
			}

			map.on('predrag drag dragend',(e)=>console.log(e))

			var btn = document.createElement('button');
			btn.style.position = 'absolute';
			btn.style.right = '0';
			btn.innerHTML = 'Run Hand'
			btn.onclick = function (){
				var hand = new Hand({
					timing: 'frame',
					onStop: function () {
						var center = map.getCenter();
						var zoom = map.getZoom();
						console.timeEnd('perf')
						done();
					}
				});
				var mouse = hand.growFinger('mouse');

				// We move 5 pixels first to overcome the 3-pixel threshold of
				// L.Draggable.
				console.time('perf')
				mouse.wait(200).moveTo(200, 200, 0)
					.down().moveBy(5, 0, 20).moveTo(550, 300, 1000)
					.moveTo(200, 200, 1000).up();
			}

			document.body.appendChild(btn)

			var hand = new Hand({
				timing: 'frame',
				onStop: function () {
					var center = map.getCenter();
					var zoom = map.getZoom();
					console.timeEnd('perf')
					done();
				}
			});
			var mouse = hand.growFinger('mouse');

			// We move 5 pixels first to overcome the 3-pixel threshold of
			// L.Draggable.
			console.time('perf')
			mouse.wait(2000).moveTo(200, 200, 0)
				.down().moveBy(5, 0, 20).moveTo(550, 300, 1000)
				.moveTo(200, 200, 1000).up();
		});

@mourner I remove this PR from 1.8.0 because the changes causing visible performance decrease. I tried over the last week different attempts but no one was successfull.

Hi,
Thanks for creating this PR, I recently stumbled across this issue so I thought I'd look into it too.
I'm trying to check out this PR to run some tests with it but I'm not able to get it to run. This is obviously something I'm doing wrong since Malvoz seems to have had success (I also can't seem to get master to run).
My process has been:

Fork Falke-Design's repo.
Clone the repo
npm install; npm run build
Remove dist/ from .gitignore
Push the files back to git
npm install [cloned repo url] or npm install [path to local directory

This builds and launches through web pack fine. However, loading the webpage fails with the error:
Uncaught ReferenceError: leaflet is not defined
    js [leaflet-src.js:14113]()
    js leaflet-src.js:7
    js leaflet-src.js:10
    Webpack 49
leaflet-src.js:14113
    js leaflet-src.js:14113
    js leaflet-src.js:7
    js leaflet-src.js:10
    Webpack 51

The above error occurred in one of your React components:

Lazy
RouteConsumer@http://localhost:3000/js/app.js:12525:7

This corresponds to the line in
  var oldL = window.L;
  leaflet.noConflict = function() {         <--- Here
  	window.L = oldL;
  	return this;
  }
  // Always export us to window global (see #2364)
  window.L = leaflet;

I presume I've just done something stupid when I've build it. Any help would be appreciated! Thanks heaps

-> #8103


New section on patterns

Start a section with "common patterns". These are general architectural patterns with links to useful blogs.

Simple website
Static website
Log processing
Analytics pipeline: Extend data source (e.g. Kinesis) and summarize data in Redshift
High availability (within a region)
Multi-region replication
“serverless” deployment

lambda-chat example

Security and IAM policies
Source-driven infrastructure configuration
A reasonable set of common-purpose buckets, like temp, user, amis, cloudfront content etc.

You might consider adding 'Data Warehouse' to this list - here's my blog post on this.


[STF-01M] Incorrect EIP-3156 Implementation of Flash Loan Fund Acquisition

STF-01M: Incorrect EIP-3156 Implementation of Flash Loan Fund Acquisition

Type
Severity
Location

Logical Fault

SingleTokenFlashloanProvider.sol:L168-L171

Description:
Per the EIP-3156 standard, the lender that implements the SingleTokenFlashloanProvider::flashLoan function MUST pull the tokens from the receiver instead of expecting them as "pushed" from them.
This is explicitly mentioned in the standard's Rationale chapter and specifically its last paragraph as well as the Receiver Specification and Lender Specificaiton chapters.
Impact:
Apart from contradicting the EIP-3156 standard, the current implementation will not utilize the approval it has acquired from the receiver (mandated by the standard) and will result in a revert error when an EIP-3156 flash loan receiver integrates with the contract.
Example:
function flashLoan(IERC3156FlashBorrower receiver, address token, uint256 amount, bytes calldata data)
    external
    nonReentrant
    returns (bool)
{
    SingleTokenFlashloanProviderStorage storage $ = _getSingleTokenFlashloanProviderStorage();
    if (token != _token) {
        revert ERC3156UnsupportedToken(token);
    }

    uint256 balanceBefore = IERC20(token).balanceOf(address(this));
    if (amount > balanceBefore) {
        revert ERC3156ExceededMaxLoan(balanceBefore);
    }

    uint256 fee = amount.mulDiv($.fee, Constants.FEE_PRECISION);
    uint256 minBalanceAfter = balanceBefore + fee;

    IERC20(token).safeTransfer(address(receiver), amount);

    if (receiver.onFlashLoan(msg.sender, token, amount, fee, data) != FLASHLOAN_SUCCESS) {
        revert ERC3156InvalidReceiver(address(receiver));
    }

    uint256 balanceAfter = IERC20(token).balanceOf(address(this));
    if (balanceAfter < minBalanceAfter) {
        revert ERC3156RepayFailed();
    }

    unchecked {
        _flashloanFeeReceived(balanceAfter - balanceBefore);
    }

    return true;
}

Recommendation:
We advise the code to properly pull the amount + fee that was provided to the receiver after the callback, ensuring that the funds are correctly extracted from the receiver.

Since StackVault was the only contract implementing SingleTokenFlashloanProvider and the flashloan functionality has been removed as part of #2, I will remove this class altogether.


Templates do not render Markdown

As the title says.
If a template includes something like [..](...), it just renders the same and does not compile to the expected HTML.

Since the page templates are html files, they are not rendered through the markdown rendering engine. Hence, it is not possible to use markdown in the templates.
Currently, I have no intentions to offer markdown templates, since this would make the rendering process quite complex, I doubt that this is even possible at all (unless you have an idea how to implement this).
However, you can use plain html for static links in the template like:
[text]

In case you want to link to dynamic content, please provide an example what you are intending to do than I can have a look how you could achieve this.

no response from author, closing for now. Please reopen with more details, if you think, there is still an issue.


improve exception safety while handling compile errors

Changelog entry
bugfix: improve exception safety in kqp compile actor
fixes: https://github.com/ydb-platform/ydb/issues/4488
Changelog category

Bugfix

Additional information
...

@nikvas0 yes, thank you, missed that.