Include Allpix² data types/ custom data types

Dear all,
we are currently starting to work with Allpix², a silicon detector simulation framework based on Geant4 which is really great. It outputs natively data into root files (which is nice, so we can use uproot) but uses custom data types (which is not nice, because uproot cannot de-serialize them correctly...)
If I want to read an entry from a branch of choice, this is the result:
import uproot
f = uproot.open("sim_output.root")

print(f['MCParticle/detector1'])
>>>  <TBranchElement b'detector1' at 0x7f8b748c4090>

print( f['MCParticle/detector1'].interpretation )
>>> asgenobj(STLVector(Pointer(allpix_3a3a_MCParticle)))

print( f['MCParticle/detector1']._streamer._fTypeName )
>>> b'vector<allpix::MCParticle*>'

print(f['MCParticle/detector1'].array()[0][0])
>>> <Undefined (failed to read 'allpix::MCParticle' version 6) at 0x7f8b73a15950>

resulting in the array containing only entries of class "undefined". Thing is, I really prefer using uproot than PyROOT or whatsoever. Is there anything I can do about it?
Thanks a lot for your awesome project!
Best regards!

Although uproot-methods would put custom methods on the classes, if they're being read in as "undefined," it means that some C++ feature was not recognized, an Uproot problem. For example, maybe these objects contain std::map of non-strings/non-numbers, which is an example of something that hasn't been handled. Maybe it's the fact that it's a vector of pointers to MCParticles...?
Once Uproot can read these as plain Python objects with the member data as attributes starting with an underscore, then it would be time to add uproot-methods to provide a more Pythonic view.
To solve the first step, we need to figure out which C++ feature is causing the failure to read. You can look at the code that was generated to try to read it in
print(f._context.classes["allpix_3a3a_MCParticle"])

but to go further, I may need to look at the file. I don't know yet how much of a time investment this would be (though I'd love to have help!).

I'm getting scattered with too many things going on—sorry. I meant
print(f._context.classes["allpix_3a3a_MCParticle"]._pycode)

Thanks again so much!
print(f._context.classes["allpix_3a3a_MCParticle"]._pycode)

output:
class allpix_3a3a_MCParticle(allpix_3a3a_Object):
    _methods = None
    _bases = [allpix_3a3a_Object]
    @classmethod
    def _recarray(cls):
        out = []
        out.append((' cnt', 'u4'))
        out.append((' vers', 'u2'))
        for base in cls._bases:
            out.extend(base._recarray())
        out.extend(ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_._recarray())
        out.extend(ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_._recarray())
        out.extend(ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_._recarray())
        out.extend(ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_._recarray())
        out.append(('particle_id_', numpy.dtype('>i4')))
        out.append(('time_', numpy.dtype('>f8')))
        out.extend(TRef._recarray())
        out.extend(TRef._recarray())
        return out
    _fields = ['local_5f_start_5f_point_5f_', 'global_5f_start_5f_point_5f_', 'local_5f_end_5f_point_5f_', 'global_5f_end_5f_point_5f_', 'particle_5f_id_5f_', 'time_5f_', 'parent_5f_', 'track_5f_']
    _classname = b'allpix::MCParticle'
    classname = 'allpix::MCParticle'
    _versions = versions
    _classversion = 6
    _hasreadobjany = False
    @classmethod
    def _readinto(cls, self, source, cursor, context, parent, asclass=None):
        start, cnt, classversion = _startcheck(source, cursor)
        startendcheck = True
        if cls._classversion != classversion:
            cursor.index = start
            if classversion in cls._versions:
                return cls._versions[classversion]._readinto(self, source, cursor, context, parent)
            elif cnt is None:
                startendcheck = False
            else:
                return Undefined.read(source, cursor, context, parent, cls.__name__)
        allpix_3a3a_Object._readinto(self, source, cursor, context, parent)
        self._local_5f_start_5f_point_5f_ = ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_.read(source, cursor, context, self)
        self._global_5f_start_5f_point_5f_ = ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_.read(source, cursor, context, self)
        self._local_5f_end_5f_point_5f_ = ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_.read(source, cursor, context, self)
        self._global_5f_end_5f_point_5f_ = ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_.read(source, cursor, context, self)
        self._particle_5f_id_5f_, self._time_5f_ = cursor.fields(source, cls._format1)
        self._parent_5f_ = TRef.read(source, cursor, context, self)
        self._track_5f_ = TRef.read(source, cursor, context, self)
        if startendcheck:
            if self.__class__.__name__ == cls.__name__:
                self.__class__ = cls._versions[classversion]
            try:
                _endcheck(start, cursor, cnt)
            except ValueError:
                cursor.index = start
                return Undefined.read(source, cursor, context, parent, cls.__name__)
        return self
    _format1 = struct.Struct('>id')
    _int32 = struct.Struct('>I')

It looks like it's probably deeper than this first object: the failure might be in allpix_3a3a_Object._readinto or ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_.read (the name is long because of some templates).
I can scan through a file to try to figure out where the problem point is.

I am happy to pass the file (had to zip it to share it here, I can also provide a download link otherwise):
diodes_output.root.zip
Is there something I can do to help?
Thanks a lot!

First the good news: the PR I just opened fixed the basic issue with reading allpix::MCParticle classes: I forgot to convert the name to allpix_3a3a_MCParticle for the specific case of class references inside TTrees. (It's related to the fact that there's a pointer: that's the corner case that I forgot, but the more fundamental issue is translating the C++ namespace into a name that a Python class can have.)
With this patch, you can read these objects from the file and they are not Undefined. You can find a lot of the fields inside, keeping in mind that they start with an underscore and the underscores in the original C++ names have been translated into
>>> hex(ord("_"))[2:]
'5f'

That's where uproot-methods would come in: you'd want high-level properties to access those low-level names.
The bad news is that fields like _global_5f_start_5f_point_5f_ are still undefined, and this is because the instance is version 0 but the only ROOT::Math::PositionVector3D<ROOT::Math::Cartesian3D<double>, ROOT::Math::DefaultCoordinateSystemTag> class defined in the ROOT file's TStreamerInfo is version 1.
How important are these fields?

Not only are the version numbers wrong for these classes, but ROOT::Math::PositionVector3D<ROOT::Math::Cartesian3D<double>,ROOT::Math::DefaultCoordinateSystemTag> and its fCoordinates value, ROOT::Math::Cartesian3D<double>, both have a 4 byte thing that is not described in the TStreamerInfo.
For the outer class, this 4-byte thing is 229, 102, 217, 110, and for the inner class (field fCoordinates in the outer class), this 4-byte thing is 133, 176, 44, 232.

As signed integers, these would be -446244498 and -2052051736.
As unsigned integers, they'd be<PHONE_NUMBER> and<PHONE_NUMBER>.
As single-precision floating point, they'd be -6.8134698e+22 and -1.6567456e-35.

So none of those interpretations make much sense. However, once you ignore the class version number and skip past these mysterious bytes, the x, y, z values are like -0.013535985514355168, -0.0012274825605789325, -0.14999999999999947, which looks really good.
I'm going to be revamping Uproot soon to replace Awkward 0.x with Awkward 1.x. Perhaps at the same time, I could expose more hooks to add custom logic for investigating these things, so that Uproot becomes more "hackable." I'll probably never solve all of these class types in general, but at least I can provide tools to let users do it. Right now, I have to modify the Uproot source code to investigate these things—adding print statements and such—but it would be much better if there were tools and instructions to do it by overriding some classes or something.

Hi there, got caught a while, thanks so much! I tested your issue branch and it works nicely! It helps us to proceed really, as one of the first studies planned is a time of flight simulation, where actually particle_id and time are the most important fields which are now accessible so this is really great!
The fields
ROOT::Math::XYZPoint local_start_point,
ROOT::Math::XYZPoint global_start_point,
ROOT::Math::XYZPoint local_end_point,
ROOT::Math::XYZPoint global_end_point,

explain where a given particle enters and exits a given detector with respect to its local or the general global coordinate system. For an assessment of hit distributions this would indeed be very valuable! Is there something I can provide you with to help or can you maybe instruct me where and what I need to adjust in the code to implement e. g. the fix dropping the version number and reading the values as you showed?
Could those actually be characters by any chance denoting a unit? The values make sense on a mm scale I think and match my expectations, as the first detector should indeed have its front layer at -0.15mm.

How would you feel about hacking it in? The 4 bytes that I have to skip to find the floating point values don't seem to correspond to anything in the TStreamerInfo. It's probably a good hint that the class version number is wrong: this could be explained by the wrong TStreamerInfo being saved to the file (and if it's always read in ROOT with the correct TStreamerInfo in memory, because you loaded a library, then perhaps it could ignore what's in the file in favor of the C++ class in memory).
I think I could write a fake ROOT::Math::PositionVector3D<ROOT::Math::Cartesian3D<double>, ROOT::Math::DefaultCoordinateSystemTag> class that reads the right bytes by ignoring what the TStreamerInfo says it should be (for the other class version). That's what I was musing about above, where I said I should build these hooks into Uproot so that users can do these things.

This will do it:
import struct

import uproot

f = uproot.open("issue486.root")
t = f["MCParticle"]

class PositionVector3D_double_DefaultCoordinateSystemTag(uproot.rootio.ROOTStreamedObject):
    @classmethod
    def _readinto(cls, self, source, cursor, context, parent, asclass=None):
        cursor.skip(20)
        self._x, self._y, self._z = cursor.fields(source, cls._format1)
        return self

    _format1 = struct.Struct(">ddd")

f._context.classes["ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_"] = PositionVector3D_double_DefaultCoordinateSystemTag

particle = t["detector1"].array()[0][0]

position = particle._global_5f_start_5f_point_5f_

print(position._x, position._y, position._z)

The key thing is that we have inserted a class into the TFile's lookup with name ROOT_3a3a_Math_3a3a_PositionVector3D_3c_ROOT_3a3a_Math_3a3a_Cartesian3D_3c_double_3e2c_ROOT_3a3a_Math_3a3a_DefaultCoordinateSystemTag_3e_. The cursor.skip(20) skips over two objects' 6-byte headers and those two mysterious 4-byte objects, a total of 20. The x, y, z are at the end of the structure and sets the cursor in the right position for the next object.
In general, classes like the one above are supposed to be generated from the TStreamerInfo. This is a hack because I gave up and wrote it by manually looking at the file. If there's another file that's slightly different, the above won't help.
What I'm thinking of adding is a "hackable" interface where most things are detected correctly, but exceptions like the above can be investigated and corrected by users. (My process of investigating the above involved adding print statements in the core uproot.rootio code, which is to say that it's not accessible to users. I'm thinking of changing that.)

Wow, it works like a charm!  Thanks so much for your support, you've helped me out a great deal here! Is this class, wrapped e. g. into an MCParticle class a candidate for uproot-methods? In other words, would the AllpixSquared data types be possible to include there or is this not desired? Thank you!
The class definition contains the following:
/**
         * @brief ROOT class definition
         */
        ClassDefOverride(MCParticle, 6);
        /**
         * @brief Default constructor for ROOT I/O
         */
        MCParticle() = default;

Could this have something to do with the unexpected wrong class behaviour?

I have asked the forum of allpix-squared about this thing as well, maybe they can look into the Streamer issue, thanks a lot, again!

If you want to add user-friendly methods, you can do so at
https://github.com/scikit-hep/uproot-methods/tree/master/uproot_methods/classes
Now that the files can be read, this issue can move back to uproot-methods. Just open a pull request and add a submodule in the same pattern as the ones there. Uproot automatically picks up these classes and use them as superclasses for the classes that it generates from streamers (though the hacked class won't do that automatically because we defined it ourselves—that would bypass the mechanism). It needs to be the "safename" with all the underscores to express the namespace and template specialization.


Nuxt still serving gzip version

I have installed the package and configured the config file.  When I ran npm run build  command I can see Brotli compressed files getting generated, but while serving it only sends out gzip files.
I'm using Nginx as a reverse proxy. I have enabled Brotli compression on Nginx also.  Is there any configuration that  I am missing here?

Nothing that relates to this plugin; the plugin deals only with generating the assets.
Keep in mind Brotli is only supported over HTTPS, so that might be why you're not seeing the assets being served. Otherwise its likely an Nginx misconfiguration.

+1 having same issue. Even on local I'm unable to serve br code
buildModules: [
    [
      "nuxt-compress",
      {
        brotli: {
          asset: '[path].br[query]',
          test: /\.(js|css|html|svg|woff|woff2)$/,
          threshold: 0,
          minRatio: 0.8,
          deleteOriginalAssets: true
        }
      }
    ]
  ],

@alishahlakhani Did you read my comment? This plugin doesn't serve them for you, just creates them. I'm not here to debug your nginx / browser setups :smile:


[File] file-post-processing need a new way of CI deployment

tasks

[x] research
[x] the serverless/github-action has moved to alpine based image makes sharp unable to work. This will resolve thematters/serverless-file-post-processing#607;
[x] <ResponsiveImage> for announcement cover;

refs

page

blocked

issue

After rounds of fixing, it's caused by Serverless deployment, which will reinstall the sharp and makes the env not works with Lambda's.
https://github.com/thematters/serverless-file-post-processing/pull/627


Improved UI of Website

🛠 Fixes Issue
Improved  navbar and homepage

Closes #204

👨💻 Changes proposed
changed color theme and style of home page (including navbar and footer)

✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers

📷 Screenshots

2)

Yes I'll remove this for sure ...and also i don't know from where does it came here as i didn't add it

I have updated one of the files...pls review

@Anjuli08

@Anjuli08

I updated the file ...kindly review it

@singhmansi25 can u review it


Update demos which use \Rx\React\Interval

Hey guys,
I was running demos to learn how RxPHP works and found that takeUntil and share demos still use \Rx\React\Interval which was removed about one month ago. I replaced it with \Rx\Observable\IntervalObservable.
Best regards,
Ihor

:+1:


[RFC] fix(eds): only respond with endpoints whose proxies have connected

Description:
This change modifies EDS responses from the osm-controller to only
include endpoints whose proxies have already connected to the control
plane. This prevents proxies from being configured to communicate with
proxies who have not yet connected to the control plane, and therefore
haven't been configured to accept traffic.
Broadly, the specific changes include:

Adding a new ProxyUID string field to endpoint.Endpoint in order
to create a mapping of service endpoint to proxy. This value is scraped
from the Pod pointed to in the Kubernetes Endpoint's
addresses[*].targetRef.

Modifying the signature of the NewResponse(...) xDS functions to
take a *registry.ProxyRegistry parameter so EDS can query which
proxies have connected.

Adding additional logic when constructing each EDS response to filter
out endpoints whose proxies have not yet connected.

This change partially addresses #3044. Specifically, it only checks that
proxies have connected, but not that they've been configured.

Does this change contain code from or inspired by another project? If so, did you notify the maintainers and provide attribution?
No

Design Doc: Envoy Endpoint Synchronization

@nojnhuh I like where this is going. I think it is the first of many steps.
Thinking more about this - it will cause issues in the short term for scenarios where we have multiple OSM Controllers.
When we have more than one replica of OSM Controller, Envoys connected to one of the OSM Controllers will not be connected to the other(s). Filtering the set of Endpoints sent by EDS by the set of connected Endpoints would mean that each OSM Controller has and sends a partial set of EDS, never the full. This will cause fragmentation of the mesh, unless we find a way to share state between OSM Controllers.
With that - I propose we feature flag the work here.  I'd wrap the filter you have with a flag, keep it off by default and we can continue to work on this.

@shashankram Your point 1 is valid. I'd propose we feature flag this and use this when the replica count is 1. (We need to continue to work on HA and higher replica count but this won't happen quickly and not in this PR.)
On point 2. A proxy being connected is a good indication that it is also healthy and most likely has latest configuration.  A proxy that is not connected - wonder why - but also config will go stale. Could unconnected proxy also be a rogue pod? I'd say an Envoy that connected at least once within the last X minutes is acceptable to be used as an endpoint. An Envoy that never connected should not be sent as an Endpoint.
Point 3 - let's find a way to resolve this. If the filter introduced in this PR is behind a feature flag (solves #1 temporarily) - I'd be supportive of merging this and digging into #2 and #3

@shashankram Your point 1 is valid. I'd propose we feature flag this and use this when the replica count is 1. (We need to continue to work on HA and higher replica count but this won't happen quickly and not in this PR.)
On point 2. A proxy being connected is a good indication that it is also healthy and most likely has latest configuration. A proxy that is not connected - wonder why - but also config will go stale. Could unconnected proxy also be a rogue pod? I'd say an Envoy that connected at least once within the last X minutes is acceptable to be used as an endpoint. An Envoy that never connected should not be sent as an Endpoint.
Point 3 - let's find a way to resolve this. If the filter introduced in this PR is behind a feature flag (solves #1 temporarily) - I'd be supportive of merging this and digging into #2 and #3

@draychev I am not convinced we should be merging this proposal just yet, given the tradeoffs indicated by @nojnhuh in https://docs.google.com/document/d/1M1-lKRIeZ53sKen1tfHG8Q9Etof6PHSVyFcu1o0oJGQ/edit# suggest it might not be worth adopting at the moment:
Overall, given this approach only adds complexity without reducing it elsewhere and could introduce some serious issues, if the only meaningful change is really lower error latency in some (maybe rare) cases, I’m not confident this approach is worth adopting now.

At this moment I don't see any noticeable benefits with this proposal, I could be missing something though. @draychev , @nojnhuh would you mind summarizing the benefits of this change? What has it improved? Could you quantify the improvement?

@nojnhuh and I spoke about this PR and where to take it next.
A few missing pieces:

We need to design the High Availability of OSM and the come back to this PR and see how things fit w/ an HA model. We are tapping on the breaks of this development because we are assuming HA means replica count > 1 and no shared state.
We want to understand whether it is feasible to use xDS mTLS gRPC connects as the sole EndpointProvider for OSM.  This will be explored via this GitHub issue:

[ ] Explore the feasibility of OSM solely relying on xDS connected Envoys for Endpoint Discovery #3244

cc: @eduser25 @shashankram

This didn't really pan out how we'd hoped, closing this for now.


How to properly edit Fens.txt

It looks like no matter how I edit the Fens.txt file, the board always starts at starting position, instead of the one I put at the first line in the file

For some reason, the IDE doesn't recognise editing the Fens.txt file as editing the project, so it doesn't rebuild. Going to Build -> Rebuild Solution will fix this (at least, this is how I fixed it, using Visual Studio). Keep in mind that it will take the first FEN string from the list as starting position.

For some reason, the IDE doesn't recognise editing the Fens.txt file as editing the project, so it doesn't rebuild. Going to Build -> Rebuild Solution will fix this (at least, this is how I fixed it, using Visual Studio). Keep in mind that it will take the first FEN string from the list as starting position.

This worked, thank you!


on MoNuSAC dataset

Hi! Sorry to bother again. I trained the hovernet on MoNuSAC dataset and I encountered this problem. Where might go wrong?

Besides, I'm curious about two questions,
1.The input shape to the hover net is 270270, why the shape of the patch should be 540540
2.How did you address the problem that some images in MoNuSAC is smaller than 540540?  I pad the image smaller than 540540 before xtractor.extract() in extract_patches.py. Is this correct?
3.Should I pad the image with zeros or anything else? If I pad the image with 'reflect' or 'mirror', I think the instance map might be affected.
Thank you so much for helping me!

Hi,
The above error is given when you are removing 0 from a list, where 0 doesn't exist. This would only happen when your labels do not contain background. However, there should always be some background in your patches, so i would suggest that you should double check your patches. You can use python train.py --view='train' to visualise the training patches.
In response to your second question, we extracted a patch double the size of the size of the input to the network. When augmenting, there are inevitable issues at the borders when applying transformations that do not work nicely with square matrices. For example, picture what happens at the corners when rotating an image by 45 degrees. If we transform a larger image and then perform a central crop we ensure that we still have a valid part of the image as input to the network

Hi,
For your 3rd question, the instance map calculation is done upon the original input size, which is at 540x540. Then, a fix is applied to remove the duplicated instance effect of reflect padding.
https://github.com/vqdang/hover_net/blob/f5419068da18a338509854b4f8260ee901bff88e/src/loader/augs.py#L29
Hence, the only remaining effect would be weird instance cut off coming from black background etc due to shearing / rotation. And, as long as you provide the original image of large enough size, we don't need to do extra fix, we only need to crop it at the central.
Also, another point needs to stress here is that this only works because the original input size > output mask shape enough. And, that wouldn't be the case otherwise, because the current fix wouldn't amend the instance directly split at the boundary of mask shape (mirror padding will create a continuous ID chunk), and these cases are much harder and more computationally expensive to fix too.


[docs] Link UXPin integration

I was talking with UXPin, they allow designers to prototype with our React components directly in a design editor. @jackbehar please review the wording if it's OK with you.
@mbrookes I have removed framer as it links to https://www.framer.com/templates/material-ui/ now, which I believe doesn't really make sense. No Material Design is not called Material UI, and no, while we try to match Material Design, there are design inconsistencies, design judgment calls we had to make to resolve them.
Framer seems to be working on https://framer.canny.io/feature-requests/p/use-public-npm-packages while encouraging their own UI components:

https://www.framer.com/components/?packages
Preview: https://deploy-preview-29422--material-ui.netlify.app/discover-more/related-projects/#design-resources

I have a few contacts at Framer, so I'll have a word. Not impressed with how they've handles this on multiple fronts.

@Olivier Tassinari @.***> would this be ok?
UXPin Merge: UXPin Merge empowers you to
design with (and keep in sync) coded React.js components. Try the MUI
boilerplate to get
started.
We are working on a MUI specific landing page to link to in the future.
All the best!
Jack Behar
Merge Onboarding Specialist
615-330-8799
www.uxpin.com
On Sun, Oct 31, 2021 at 5:46 AM Olivier Tassinari @.***>
wrote:

I was talking with UXPin, they allow designers to prototype with our React
components directly in a design editor. @jackbehar
https://github.com/jackbehar please review the wording if it's OK with
you.
@mbrookes https://github.com/mbrookes I have removed framer as it links
to https://www.framer.com/templates/material-ui/ now, which I believe
doesn't really make sense. No Material Design is not called Material UI,
and no, while we try to match Material Design, there are design
inconsistencies, judgment calls we had to make. Framer seems to be working
on https://framer.canny.io/feature-requests/p/use-public-npm-packages.
[image: Screenshot 2021-10-31 at 12 46 00]
https://user-images.githubusercontent.com/3165635/139581531-518d80d7-ef90-4873-b46c-b921c2bcaf13.png
https://www.framer.com/components/?packages
You can view, comment on, or merge this pull request online at:
https://github.com/mui-org/material-ui/pull/29422
Commit Summary

[docs] Link UXPin integration
https://github.com/mui-org/material-ui/pull/29422/commits/66087d58dd962b7136133adecd9aca132f1e5d19

File Changes
(2 files https://github.com/mui-org/material-ui/pull/29422/files)

M docs/src/pages/discover-more/related-projects/related-projects.md
https://github.com/mui-org/material-ui/pull/29422/files#diff-dd3b6d46e66a74d719b77a9ec760f7ee0a8a2da37c54c8edd4ebe383971b76b8
(2)
M docs/src/pages/getting-started/installation/installation.md
https://github.com/mui-org/material-ui/pull/29422/files#diff-690dd57078f198bb29a3de4288cb10d9cc280cbcb476a522221efde8076ed82b
(2)

Patch Links:

https://github.com/mui-org/material-ui/pull/29422.patch
https://github.com/mui-org/material-ui/pull/29422.diff

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mui-org/material-ui/pull/29422, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUE4IV7LI3PT5OFK6GZZAV3UJUUCBANCNFSM5HCGKNAQ
.
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.

@jackbehar It sounds a bit much like an advert.

OK, no problem. What you have initially will work great. Thank you again!
All the best!
Jack Behar
Merge Onboarding Specialist
615-330-8799
www.uxpin.com
On Wed, Nov 3, 2021 at 12:40 PM Matt @.***> wrote:

@jackbehar https://github.com/jackbehar It sounds a bit much like an
advert.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mui-org/material-ui/pull/29422#issuecomment-959816657,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUE4IV7E46UOW7PUOOTKA43UKF6ZFANCNFSM5HCGKNAQ
.
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.

I tried to merge the two styles. Hope it flies?


pretty-format doesn't format snapshots for svelte

Describe the bug
I'm having issue with snapshot formatting. After I run tests, it creates snapshots with all code in one line. The svelte example in this repo represents the same.
Reproduction
https://github.com/vish01/svelte-vitest-repro
System Info
System:
    OS: Windows 10 10.0.18362
    CPU: (8) x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
    Memory: 11.63 GB / 31.85 GB
  Binaries:
    Node: 16.15.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.1.3 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: master_preferences.txt
    Edge: Spartan (44.18362.449.0)
    Internet Explorer: 11.0.18362.1
  npmPackages:
    vitest: latest => 0.14.2

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

innerHTML returns a string in one line. Vitest just saves the raw string and matches against it, it doesn't know it's an HTML . Try passing down DOM element itself.

@sheremet-va Got it to work by passing in just the DOM element and modify the tests a bit. Also, there's no way to format innerHTML? Is that a bug or this is how Vitest is supposed to handle it?

innerHTML is just a string. You can configure how it is processed with expect.addSnapshotSerializer


Fix: Register button focus and register input box-shadow

Fixes Issue #584

My PR closes #584
Changes proposed
What were you told to do ?

to change the bg color of register button while on active.
change the box-shadow color of input form in registration page.

What did you do ?
All the above.

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title and description of the PR is clear and explains the approach.

Screenshots

Please check @IAmTamal


Error

dist must be a Distribution instance, how to solve this problem？

Then how did you solve the problem? I got the same error with you

Then how did you solve the problem? I got the same error with you

Using Linux platform can void this problem.
Try:
pip install pystan
pip install gcc

ok，thank you.  But, it's said this repo supports pytorch-1.0 now.  Then where is the 1.0 branch?

haha, I've found it. thx.

haha, I've found it. thx.

hi,i use pytorch-1.01 too, can you tell how to solve this?i have change the version of setuptools, but it not working

hi,i use pytorch-1.01 too, can you tell how to solve this?i have change the version of setuptools, but it not working

you can try pytorch 0.4

Then how did you solve the problem? I got the same error with you

Using Linux platform can void this problem.
use pytorch 0.3.1 and then try:
pip install pystan
conda install gcc

I'm gratefull that this works for me. Thank you three thousand!
When I finished changing the version of pytorch and installing the gcc, the problem was solved. However, a new problem comes, it's a gcc's problem, I don't konw how to solve it, so I uninstall gcc, and all problem gone, it's confued, but problem has been solved.
Thank you for giving the advice again~

那么到底怎么做才能在Pytorch1.0上解决这个问题
（除了让我用0.4以下的方法）

you can using this code:
python setup.py install


feat: erc721 activity + token

Handle erc721 activity + token

Summary by CodeRabbit

New Features

Introduced new database tables and models for tracking ERC721 token activities and tokens.
Added new capabilities in the Erc721Service to handle ERC721 activities and token updates.
Implemented a new handler for processing ERC721 token activities, including transfers and approvals.

Refactor

Updated service methods and added new queue handling for ERC721 activities.

Chores

Added new configuration parameters and constants to support ERC721 functionality.

@coderabbitai review

@phamphong9981 đang review thì đừng có force pushed, nó mất history của cái comment


find and replace v1beta2 RLP with v1beta3

Signed-off-by: craig<EMAIL_ADDRESS>rh-pre-commit.version: 2.2.0
rh-pre-commit.check-secrets: ENABLED

duplicate https://github.com/Kuadrant/kuadrant-operator/issues/930


FTCC with C#

I have created a C# version for this repository:
FTCC C#
Features:

Set compressors per class.
Set parallelism when creating the dictionaries.
Set the compression level.
Serialize/deserialize dictionaries.

Very nice!
Are you able to reproduce the accuracy results with a compression level of 9?
Also I'm curious about the speed you achieve, python is very slow at string concatenation, this is taking a significant amount of time in the training phase. Not sure for C# (and I don't know how the JIT works in C#)
Feel free to add PR to this project to add to the README something like:
## Other implementations
- [C#](link-to-your-repo)

I have found hardly any variation in the results with compression level 9. However, I have noticed a slight decrease in speed when predicting.
For the creation of the dictionaries, I used the ZstdNet library, which takes a list of byte arrays as input, so it is not necessary to concatenate strings. I think that overall the performance in terms of speed is very good.


Let's Encrypt for https

Let's check out and probably use Let's Encrypt for the https instead of Cloudflare

Started the process. Going slow because the server seems to be set up oddly.

This is being escalated, looks like we're going to move hosting providers.

We've moved to no hosting, Let's Encrypt is now up and running!


Error Response on receiving some token request with other's client certificate in TLS handshake

test module : FAPIRWID2EnsureClientIdInTokenEndpointWithMTLS
When the authz server(keycloak) receives a token request by some client(say client2) including a authorization code issued to other client(say client1) with this client(client1)'s client certificate in TLS handshake, it returns 400 Bad Request / error="unauthorized_client".
CheckTokenEndpointHttpStatus401 and CheckErrorFromTokenEndpointResponseErrorInvalidClient expects 401 Unauthorized / error="invalid_client" while keycloak returns 400 Bad Request / error="unauthorized_client".

related keycloak-jira ticket created : https://issues.jboss.org/browse/KEYCLOAK-11263

From release-v3.2.6, it seems to be OK that test suite can accept the following error patterns :
400 error=invalid_request
400 error=invalid_client
401 error=invalid_client
conformance-suite - issue :
https://gitlab.com/openid/conformance-suite/issues/606
conformance-suite - merge request :
https://gitlab.com/openid/conformance-suite/commit/c2ddca54c0a83c5419003fba6e30bbb8f365545c
src/main/java/io/fintechlabs/testframework/condition/client/CheckTokenEndpointHttpStatusForInvalidRequestOrInvalidClientError.java

jira ticket changed : https://issues.redhat.com/browse/KEYCLOAK-15236

jira ticket resolved.

The corresponding PR is https://github.com/keycloak/keycloak/pull/7364


pyros_setup: 0.0.10-0 in 'indigo/distribution.yaml' [bloom]

Increasing version of package(s) in repository pyros_setup to 0.0.10-0:

upstream repository: https://github.com/asmodehn/pyros-setup.git
release repository: https://github.com/asmodehn/pyros-setup-release.git
distro file: indigo/distribution.yaml
bloom version: 0.5.20
previous version for package: 0.0.8-0

This is failing sourcedebs jobs.
# BEGIN SUBSECTION: build sourcedeb
09:28:14 Invoking 'git buildpackage --git-ignore-new --git-ignore-branch -S -us -uc --lintian-opts --suppress-tags newer-standards-version' in '/tmp/sourcedeb/source'
09:28:14 dh  clean --with python-virtualenv
09:28:14 dh: unable to load addon python-virtualenv: Can't locate Debian/Debhelper/Sequence/python_virtualenv.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at (eval 19) line 2.
09:28:14 BEGIN failed--compilation aborted at (eval 19) line 2.
09:28:14
09:28:14 # END SUBSECTION
09:28:14 make: *** [clean] Error 2
09:28:14 debuild: fatal error at line 1343:
09:28:14 couldn't exec fakeroot debian/rules:
09:28:14 gbp:error: Couldn't run 'debuild -d clean': debuild -d clean returned 2
09:28:14 Traceback (most recent call last):
09:28:14   File "/tmp/ros_buildfarm/scripts/release/build_sourcedeb.py", line 22, in <module>
09:28:14     sys.exit(main())
09:28:14   File "/tmp/ros_buildfarm/scripts/release/build_sourcedeb.py", line 18, in main
09:28:14     return build_sourcedeb(args.source_dir)
09:28:14   File "/tmp/ros_buildfarm/ros_buildfarm/sourcedeb_job.py", line 99, in build_sourcedeb
09:28:14     subprocess.check_call(cmd, cwd=sources_dir)
09:28:14   File "/usr/lib/python3.3/subprocess.py", line 547, in check_call
09:28:14     raise CalledProcessError(retcode, cmd)
09:28:14 subprocess.CalledProcessError: Command '['git', 'buildpackage', '--git-ignore-new', '--git-ignore-branch', '-S', '-us', '-uc', '--lintian-opts', '--suppress-tags', 'newer-standards-version']' returned non-zero exit status 1
09:28:15 Build step 'Execute shell' marked build as failure
09:28:15 [ssh-agent] Stopped.
09:28:15 [description-setter] Could not determine description.
09:28:15 Sending e-mails to<EMAIL_ADDRESS><EMAIL_ADDRESS>09:28:15 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered


Create helm chart to simplify the alluxio deployment in Kubernetes

Is your feature request related to a problem? Please describe.
One click to install alluxio in Kubernetes is helpful in delivering alluxio in the kubernetes. Maybe helm can help install/upgrade/uninstall scenario for alluxio.
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.
Urgency
Explain why the feature is important
Additional context
Add any other context or screenshots about the feature request here.

Addressed in 2.1 snapshot by https://github.com/Alluxio/alluxio/pull/9468


Update hall of fame, adding Jeremi R to the list

I'm adding my name to the hall of fame following the email exchange with you, Garrit!
Thank you for this, I'll keep an eye for the other flags.

Thanks a lot Jérémi!


RFG feature was cut and the associated arithmetic ops were never impl…

…emented.

@pmsjt : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Version compatibility

Does the plug-in support the new version? IDA-7.0

Doesn't seem to atm.

Currently not. The Plug-In was written for 6.8, on 7.0 it will most certainly not work out of the box. Once I have more time on my hands I will fix this, currently I am fully booked however.

Does it support IDA-7.0 now?

I have tried it now and not yet supported


Add global timeouts

In some cases, certain events never arrive. This can happen, for example, if you call the cert_info method without having a monitor that uses TLS. It is difficult to address all these special cases individually. Especially without documentation when this happens.
Instead, timeouts for all methods would be useful, also for other errors. In order not to block the application forever.

This is a very good point - I was just here to create a PR for that! A very simple solution would be to set the timeout parameter of https://github.com/lucasheld/uptime-kuma-api/blob/a576ed9f3a96c6e4d240a352c210c4c78ac48c7f/uptime_kuma_api/api.py#L484 ! Because the timeouts of ~60 seconds are horrible for fast api interactions...
For myself I already drastically sped up the error handling with...
r = self.sio.call(event, data, timeout=self.wait_timeout)

...which also forced me to implement retry-mechanisms in my own code (which is a good practice anyway).

@simonmicro I have created a pull request: #34. What do you think?

It's included in release 1.0.1


simple-schema version is outdated

Why the version used by this package is<EMAIL_ADDRESS>and not the 1.3.0 ? Is this a typo or should I add  aldeed:simple-schema separately ?

It shouldn't matter. Meteor will use the latest release it can within the same major version.

It's not working here, I'm still facing this bug on simple-schema https://github.com/aldeed/meteor-simple-schema/issues/168 and all I have is the collection2 package.
meteor update
This project is already at Meteor <IP_ADDRESS>, the latest release.
Your packages are at their latest compatible versions.

OK, maybe you need to explicitly add it to your project then. There used to be an issue with updating implied dependencies, but I thought they had fixed that.
We can update the C2 dependency, too.


With this now present in the existing TextAnalyze transformer, I think it would be good to keep parity with this when adding new versions of Text Analysis transformers. For a project we're working on, we got a double benefit from this endpoint for performance. Firstly,  the async endpoint allows for more documents per batch than the individual synchronous endpoints. Secondly, we were able to submit multiple tasks per document. The combined effect of these was a significant reduction in the number of requests we were required to submit, which made a significant difference in throughput against the text analysis API throttling!


Error: TF_DENORMALIZED_QUATERNION: Ignoring transform for child_frame_id "robot_1_ground_truth/body" from ...

hello, regarding to https://github.com/robomechanics/quad-sdk/issues/346,
changed <arg name="namespace_1" default="robot_1"/> to <arg name="namespace_1" default="robot_1/"/>
into quad_visualization.launch.
Error:   TF_DENORMALIZED_QUATERNION: Ignoring transform for child_frame_id "robot_1/_ground_truth/body" from authority "unknown_publisher" because of an invalid quaternion in the transform (0.000000 0.000000 0.000000 0.000000)
         at line 255 in /tmp/binarydeb/ros-noetic-tf2-0.7.6/src/buffer_core.cpp

How could i correct this error ?

well, new test :

I used default noetic branch,
kept all actual code,
modified send() and recv() functions, witn my send/receive code.
send and receive joints lib functions tested and working.
imu working, feeding last_imu_msg_ (imu_pub_.publish(last_imu_msg_) is tested, working)

To be clear, quad_gazebo.launch is for launching the robot on gazebo, not on hardware. We do not provide a readymade hardware launch file because every robot is different (as mentioned in https://github.com/robomechanics/quad-sdk/issues/341). I would suspect that by launching gazebo, somehow the broadcaster responsible for this particular transform thinks it has enough information to broadcast when in fact it does not. Also see my latest comment about namespacing in https://github.com/robomechanics/quad-sdk/issues/346.
So in summary - revert the namespacing change and use robot_driver.launch as a guide for how to write your own launch file (rather than quad_gazebo.launch). You could also take a look at the JointController class, which just controls individual joints and shouldn't need any state estimation (hardware state estimation is still a work in progress). That would help with bring up to make sure you are talking to joints correctly.

Oh, how can I be so stupid, Joe !!
I did not call the robot_driver.launch!!!
Now the robot gets up...at least, try, lol
Still some reversals of engines to operate and the dream is within my reach...
Many thanks, @jcnorby  and see you soon in another question


Week 2 tests

I have modified the Sidebar.js component to make use of useRouter() from next/router. There were some bugs I faced on simulating click interaction. On reading about the issues, I came to know that next/link component that we use currently has some bugs and is not a great API, having inconsistencies in its implementation.
References:
https://github.com/vercel/next.js/issues/16864#issuecomment-700593327
https://github.com/vercel/next.js/issues/1490#issuecomment-289108262

I am yet to checkout this branch and run the app. But one thing I would like to point out is that not using next/link and treating them as regular <a> links may have some impact on how the app handles page transitions. It may or may not be applicable to the way we use <Link> in our app. E.g In some cases, clicking <Link> only causes client-side changes without a full page reload starting with blank white page.

I understand. I've actually replaced Link with Flex from ooni-components which I think is a regular div tag. I have passed an onClick listener to it.

I have removed some tests which I felt were not relevant at all. I have only kept the ones which I felt added confidence in the component.


CPU is high

After sometime working with solution, CPU usage spikes (~50%) after I type something or scroll editor.
If I close all windows, and reopen window this is does not helps, if I close solution and then reopen it also does not helps.
  Defaulted to export symbols for ProjectAggregator.dll -
ProjectAggregator!DllUnregisterServer+0x2fd
000000000018e594 3392f977 (MethodDesc 32c59894 +0xf Microsoft.NodejsTools.NodejsProject.GetMkDocument(UInt32, System.String ByRef)), calling 18cf333e
000000000018e5a0 0286c051 (MethodDesc 0e1d1404 +0x29 DomainNeutralILStubClass.IL_STUB_COMtoCLR(Int32, IntPtr))
000000000018e5d4 7278179c clr+0x179c
000000000018e5f0 07d90f18 07d90f18, calling 02c2d01c
000000000018e5f8 72815240 clr!GetCLRFunction+0xfa8b, calling clr+0x1731
000000000018e624 07d90f18 07d90f18, calling 02c2d01c
000000000018e650 02c2d060 02c2d060, calling clr!GetCLRFunction+0xf8f1
000000000018e668 07d90f18 07d90f18, calling 02c2d01c
000000000018e67c 30eba291 *** ERROR: Symbol file could not be found.  Defaulted to export symbols for msenv.dll -
msenv!VStudioTerm+0x33434
000000000018e69c 07d5564c 07d5564c, calling 02c2d01c
000000000018e6f8 52552140 ProjectAggregator!DllUnregisterServer+0x2ea
000000000018e71c 30c92209 msenv+0x2209
000000000018e770 30cfc725 msenv!DllCanUnloadNow+0x2918d, calling msenv+0x1040
000000000018e774 30cffc96 msenv!DllCanUnloadNow+0x2c6fe
000000000018e7a0 30f9d0d7 msenv!VStudioTerm+0x11627a
000000000018e7c4 747b9f03 *** ERROR: Symbol file could not be found.  Defaulted to export symbols for combase.dll -
combase!CoTaskMemAlloc+0x33, calling *** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll -
ntdll_77090000!RtlAllocateHeap
000000000018e7d4 747b9f0e combase!CoTaskMemAlloc+0x3e, calling combase!Ordinal99+0x4750
000000000018e800 30f9ec99 msenv!VStudioTerm+0x117e3c, calling msenv!VStudioTerm+0x1161e2
000000000018e830 30f9d039 msenv!VStudioTerm+0x1161dc, calling msenv!VStudioTerm+0x117e11
000000000018e840 750279ac *** ERROR: Symbol file could not be found.  Defaulted to export symbols for rpcrt4.dll -
rpcrt4!NdrNsGetBuffer+0x5c
000000000018e860 74ff3dc4 rpcrt4!NdrStubCall2+0x3c4, calling rpcrt4!NdrNsGetBuffer+0x28
000000000018eaf4 7278aad5 clr+0xaad5, calling clr+0x1000
000000000018eb18 7278aad5 clr+0xaad5, calling clr+0x1000
000000000018eb1c 7279dd58 clr!DllUnregisterServerInternal+0x111d0, calling clr+0x1000
000000000018eb38 30c910d6 msenv+0x10d6, calling msenv+0x10bc
000000000018eb3c 30e722b6 msenv!DllGetClassObject+0xc0526, calling msenv+0x10cb
000000000018eba8 72873f71 clr!CoUninitializeEE+0x23865, calling clr!CoUninitializeEE+0x24386
000000000018ebd0 7287405d clr!CoUninitializeEE+0x23951, calling clr!CoUninitializeEE+0x216ee
000000000018ebe8 728527c5 clr!CoUninitializeEE+0x20b9, calling clr!CoUninitializeEE+0x1fab
000000000018ebf8 75256516 *** ERROR: Symbol file could not be found.  Defaulted to export symbols for KERNELBASE.dll -
KERNELBASE!CompareStringEx+0x3d6

Same here. From 0% cpu & 140 MB ram to 30-40% & 1200MB RAM after a nodeJs project opened. The ram continues to grow slow but sure and at one point (usually after ~1h) VS simply restarts.
Till I wrote this, the RAM reached 2000MB & 44% cpu :)

Had the same visual studio performance issues with Node.js tools.
Uninstalling those got some performance boost.
So, for now, I'm using VS2015 to write some C#/C++ code while its not suitable to work without lags, bugs etc. with Node.js
I'd recommend you to try JetBrains WebStorm to debug Node apps - it's debugger much faster and easy to use.

@kant2002 The only Node Tools frame I see on that stack is "Microsoft.NodejsTools.NodejsProject.GetMkDocument". Did you grab a couple of snapshots of the stack when this problem was occurring and are these frames pretty representative of what you are observing?
@Hubrus Was this a particularly large project (or with a large number of dependencies)? Or are you seeing this in general even for small projects? Analysis can be quite slow and expensive initially if there is a lot of code to analyze, but it shouldn't be systemic.

@billti I will try to capture more stacks, when I have such issue. But it is hard to distinguish it from the cased when analysis kick-in. Usually when I take dump things settle immidiately, so no opportunity to take another dump. At least I don't see the value in taking dump when CPU is not spiking.
I also found single mention of NTVS which is related to very simple things, which unlikely cause such spikes. I think this could be VS related, for example you don't obey some contract which VS expecting, or something like that. But for me this is unlikely VS specific issue, since I don't experience it on other projects. Maybe it is bug in VS which exhibited in NTVS since it is sometimes slow and issues become more visible. I don't know, but for me this is seems to be different issues when regular freezing related to NTVS analysis. I will work on giving your more informaiton about this issue.

In addition to @billti's comments, please send us your diagnostic log when the issue occurs - this will give us a clue about which package is being particularly problematic (Tools > Node.js Tools > Diagnostic Info)

Would you mind sharing your package.json files and also the analysis diagnostic log when these issues occur? (Tools > Node.js Tools > Diagnostic Info). Otherwise we really don't have enough information to get to the root of these issues.

We're currently working on integrating Salsa for our IntelliSense experience going forward (behind the ES6 Preview flag) which should help address some of these perf issues. Closing this for now, but let us know if you have a consistent repro and we might be able to to investigate.


Fix Windows compatibility

If you try to run mailrise on Windows, you will get this error:
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\Brian\AppData\Roaming\Python\Python311\Scripts\mailrise.exe\__main__.py", line 7, in <module>
  File "C:\Users\Brian\AppData\Roaming\Python\Python311\site-packages\mailrise\skeleton.py", line 170, in run
    main(sys.argv[1:])
  File "C:\Users\Brian\AppData\Roaming\Python\Python311\site-packages\mailrise\skeleton.py", line 159, in main
    eloop.add_signal_handler(sig, clean_exit)
  File "C:\Python311\Lib\asyncio\events.py", line 574, in add_signal_handler
    raise NotImplementedError
NotImplementedError

The root cause of this issue is loop.add_signal_handler is not available on Windows according to the Python Event Loop documentation
Therefore, I changed it to call signal.signal on Windows. It may not be the best solution, but at least it can now run on Windows.

Thanks for the report! I develop Mailrise solely for Linux and Docker and don't make a habit of testing for other operating systems.
I've opted to just catch NotImplementedError and continue. It's nice to be able to gracefully stop the event loop, but it's not essential to do so.


Update validators.uk.xlf

Invalid translation text

Thanks for contributing this pull request. However, the repositories of individual Symfony Components are read-only, so pull requests are ignored. Please, submit this pull request to the main Symfony repository at https://github.com/symfony/symfony/pulls
Thank you!

Please submit on symfony/symfony


Permission issues

we were going to switch our bot to discord.js light but one issue stopped us.
when looking for permissions on a channel for our bot the bitfield that returns is always 0.

it just started working out oh nowhere but keep this in mind.

hey july, in order to check for permissions in channels there are some things you have to keep in mind:
besides the channel in question, both guild roles and channel permissionOverwrites need to be available which, depending on your client options, may need to be fetched separately.
There are several ways to achieve this depending on the specific caches you have enabled in your client options, feel free to join my discord if you need any troubleshooting :)


update description of geocoding api

Data Plane API - Pull Request

API Info: The Basics
Most of the information about your service should be captured in the issue that serves as your engagement record.

Link to engagement record issue:

Is this review for (select one):

[ ] a private preview
[x] a public preview
[ ] GA release

Change Scope
This section will help us focus on the specific parts of your API that are new or have been modified. Please share a link to the design document for the new APIs, a link to the previous Open API document (swagger) if applicable, and the root paths that have been updated.

Design Document:
Previous Open API Doc:
Updated paths:

❔Got questions? Need additional info?? We are here to help!

 Contact us!
The Azure API Review Board is dedicated to helping you create amazing APIs. You can read about our mission and learn more about our process on our wiki.

💬 Teams Channel
💌 email

Click here for links to tools, specs, guidelines & other good stuff
Tooling

Open API validation tools were run on this PR. Go here to see how to fix errors
Spectral Linting
Open API Hub

Guidelines & Specifications

Azure REST API Guidelines
OpenAPI Style Guidelines
Azure Breaking Change Policy

Helpful Links

Azure DevTools Wiki

@vicancy @MushMal Can you help to review the PR? thanks

@anuchandy Please help to merge if no other concern. thanks!

@chcmsft
Please take a look on DocPreview https://github.com/Azure/azure-rest-api-specs/pull/23101#issuecomment-1470227368
I will merge if you are OK with the preview.

@weidongxu-microsoft the doc preview looks good to me. Please help to merge. Thanks

Change is on description, nothing affect REST API. Hence we merge with offline review.


Please tag releases consistently (semantic versioning is good)

Notary could benefit from consistent tagging of releases.
At the moment two different versioning schemes co-exist: vN.M and docker-vA.B-C.
It would be better to tag semantically and consistently as vA.B.C (for example 0.3.1 for new release). Please avoid non-semver docker- tags.
Read more about versioning:

http://semver.org/
https://en.wikipedia.org/wiki/Software_versioning
Debian Upstream Guide.

Thanks.

Hi @onlyjob!  Thank you for your suggestions.  We try to re-vendor notary into docker on a regular basis in order to prevent the diffs from being too large, since docker reviews the code from dependency updates, and we tag these commits so that docker can track them in this repository.  However, those re-vendorings are not necessarily releases - they may contain only minor changes or a partial feature set.
Our actual releases, v0.1, v0.2, and v0.3, are the ones that include changelogs and binaries, are semantically versioned, and have a more coherent series of features or bugfixes added.

Thanks, @cyli. Please remember that vendoring is not a fix for inconsistent tags. I suggest to use tags like v0.2.2, v0.3.1 for Docker vendoring. If it is not possible then please use compatibility tags when one commit is tagged twice using different versioning schemes.
This ticket represent practical problem of building Docker in Debian against tagged release of Notary which is packages separately (not vendored).

@onlyjob Sorry, could you please elaborate on the problem you are having with building in debian?  Is it not possible to just ignore tags that aren't of a particular format?
We were trying to avoid vendoring tags that are semver'd, because that'd indicate an actual upgrade for which we'd have to provide changelogs and binaries.  Basically, we don't release on as regular a schedule as we vendor into docker.

@onlyjob Would tagging the vendored versions with something like v0.4.0-dev1 be ok for you, to indicate that it may not even be in alpha release stage?

It is not a problem of ignoring tags. Quite contrary it is difficulty to pick up inconsistent tags because Docker FTBFS with any released version of Notary and packaging tagged docker version of Notary breaks normal versioning...
I would not encourage releasing on schedule but Docker should not depend on unreleased snapshots between releases. It shouldn't be too hard to coordinate release if Docker needs a version bump in Notary...

@onlyjob Oh interesting - so you are trying to build notary source debs as well as docker source debs?  Also, would an alpha version like 0.4.0-a1 be sufficient to not break things?

Also to be clear, is this mainly for official releases of docker?  Or do you also need this for in-between releases of docker?

At the moment Docker is a main user of Notary but we build all components separately. Alpha versioning you suggest is not great because of dash (-) character (see Debian Upstream Guide). This is for official releases of Docker and for in-between releases of Notary as well. :)
It could be that Notary is uploaded first in order to prepare all dependencies before building new release of Docker. I hope it make sense. Thanks.

Ah ok - thank you for explaining!  We can certainly make a better effort to
accommodate this moving forward for docker releases at least.
So to summarize to ensure that I have all the details right:
You would like the versions of notary that are vendored into the final
releases of docker to be semver'ed without any RC or alpha designations.
In between docker releases, if we do intermediate vendors that are more
work in progress, the tags don't matter as much?  (Little fuzzier about
whether you required all tags to be consistent, or just the ones that
correspond to the docker releases and the official notary releases).
And you mainly need this moving forward, and as opposed to needing
everything retroactively tagged?
Thanks!
On Friday, June 10, 2016, Dmitry Smirnov<EMAIL_ADDRESS>wrote:

At the moment Docker is a main user of Notary but we build all components
separately. Alpha versioning you suggest is not great because of dash (-)
character (see Debian Upstream Guide). This is for official releases of
Docker and for in-between releases of Notary as well. :)
It could be that Notary is uploaded first in order to prepare all
dependencies before building new release of Docker. I hope it make sense.
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/notary/issues/782#issuecomment-225333971, or mute
the thread
https://github.com/notifications/unsubscribe/AANn4EPtnzK3zGkKmM1i86xDCrnbN-Fcks5qKik5gaJpZM4IzaQT
.

Thank you @cyli.
As usual, non production ready releases can be tagged with "rc", "alpha", "beta" or whatever mark is appropriate.
I'm not asking for any retrospective re-tagging.
At the moment the major difficulty of building Docker is grpc version mismatch (#778) that cause FTBFS in Notary... :(

Hi @onlyjob, just want to make sure I understand your problem and request completely clearly.
You're asking that when we vendor into the docker/docker repository, we always vendor a semantically tagged version?
Are you trying to package the Notary CLI as its own package and match versions between Docker and the Notary package?

Exactly. :)
Thank you for understanding, @endophage.

@onlyjob so we're already using semantic versioning (as of v0.2.0) and we can certainly tag each time we vendor into docker. However as the release cycles are not syncronized, it's typically not appropriate to release the version of notary that was vendored into Docker. The version vendored into docker represents library level updates. If you release that version as the standalone CLI, it will often be missing functionality.

We have no intention to release docker-vendored Notary as standalone package. It is the other way round: we can't reuse Notary to build Docker because of tagging mess in Notary and because vendoring of Notary do not stick to semantic releases.

I understand what you're saying. I'm trying to explain if we vendor say v0.4.0 into a docker release, the actual version of Notary that you'll want to distribute is likely to be v0.4.1, but that won't be vendored into docker until the next docker release.

Fair enough. That should work. Thank you.

We're only using semantic versions now and vendoring them into docker. Closing.


Add new heat energy units

Closes #471

Thank you. You can fix the doc build by following the suggestion in the CI job:

Make sure to run 'build.py' in the book/ folder

Thanks for the comment. PR is good to merge now.


Log Viewer fails when score value is not C/P/I in version > 0.3.18

I am trying to use a slightly modified version of model_graded_fact() that returns letter scores (A, B, C, D, E). I have a custom accuracy metric that maps letters to 1/0 (ex. {A, B, C} -> 1, {D, E} -> 0).
Prior to 0.3.18 this worked fine with the log viewer. Starting in 0.13.8 I get this error when I run inspect view:
Error: scoreDescriptor.render is not a function
at TypeError: scoreDescriptor.render is not a function
    at Object.rendered (http://localhost:7575/src/samples/SamplesDescriptor.mjs:225:40)
    at W.SampleScores [as constructor] (http://localhost:7575/src/samples/SampleScores.mjs:9:22)
    at W.ce [as render] (http://localhost:7575/preact/preact.mjs:2:9028)
    at G (http://localhost:7575/preact/preact.mjs:2:6544)
    at _e (http://localhost:7575/preact/preact.mjs:2:1971)
    at fe (http://localhost:7575/preact/preact.mjs:2:8274)
    at G (http://localhost:7575/preact/preact.mjs:2:7092)
    at _e (http://localhost:7575/preact/preact.mjs:2:1971)
    at fe (http://localhost:7575/preact/preact.mjs:2:8274)
    at G (http://localhost:7575/preact/preact.mjs:2:7092)

Example task
This is a simplified version. In the actual thing I have more complex criteria for grades A-E and the custom accuracy metric.
from inspect_ai import Task, task
from inspect_ai.dataset import example_dataset
from inspect_ai.scorer import model_graded_fact
from inspect_ai.solver import generate

@task
def theory_of_mind():
    return Task(
        dataset=example_dataset("theory_of_mind"),
        plan=generate(),
        scorer=model_graded_fact(
            instructions="""
Randomly print only a single choice from "A" or "B" (without quotes or punctuation) on its own line as the answer. At the end, repeat just the answer by itself on a new line.
""",
            grade_pattern=r"(?i)\n([AB])\n*$",
            model="openai/gpt-4o",
        ),
    )

Example log
{
  "version": 2,
  "status": "success",
  "eval": {
    "task": "theory_of_mind",
    "task_version": 0,
    "task_id": "GvV83CQzjsJL72DV9x6MX7",
    "run_id": "4kNm7EZs3EobtRYkKq8gst",
    "created": "2024-08-01T15:09:57-04:00",
    "dataset": {
      "name": "theory_of_mind",
      "location": "example://theory_of_mind",
      "samples": 100,
      "shuffled": false
    },
    "model": "openai/gpt-4o",
    "task_attribs": {},
    "task_args": {},
    "model_args": {},
    "config": {
      "limit": 1
    },
    "packages": {
      "inspect_ai": "0.3.18"
    }
  },
  "plan": {
    "name": "plan",
    "steps": [
      {
        "solver": "generate",
        "params": {}
      }
    ],
    "config": {}
  },
  "results": {
    "scores": [
      {
        "name": "model_graded_fact",
        "scorer": "model_graded_fact",
        "params": {
          "instructions": "\nRandomly print only a single choice from \"A\" or \"B\" (without quotes or punctuation) on its own line as the answer. At the end, repeat just the answer by itself on a new line.\n",
          "grade_pattern": "(?i)\\n([AB])\\n*$",
          "model": "openai/gpt-4o"
        },
        "metrics": {
          "accuracy": {
            "name": "accuracy",
            "value": 0.0,
            "options": {}
          },
          "bootstrap_std": {
            "name": "bootstrap_std",
            "value": 0.0,
            "options": {}
          }
        }
      }
    ]
  },
  "stats": {
    "started_at": "2024-08-01T15:09:57-04:00",
    "completed_at": "2024-08-01T15:09:59-04:00",
    "model_usage": {
      "openai/gpt-4o": {
        "input_tokens": 239,
        "output_tokens": 13,
        "total_tokens": 252
      }
    }
  },
  "samples": [
    {
      "id": 1,
      "epoch": 1,
      "input": [
        {
          "content": "Jackson entered the hall. Chloe entered the hall. The boots is in the bathtub. Jackson exited the hall. Jackson entered the dining_room. Chloe moved the boots to the pantry. Where was the boots at the beginning?",
          "source": "input",
          "role": "user"
        }
      ],
      "target": "bathtub",
      "messages": [
        {
          "content": "Jackson entered the hall. Chloe entered the hall. The boots is in the bathtub. Jackson exited the hall. Jackson entered the dining_room. Chloe moved the boots to the pantry. Where was the boots at the beginning?",
          "source": "input",
          "role": "user"
        },
        {
          "content": "The boots were in the bathtub at the beginning.",
          "source": "generate",
          "role": "assistant"
        }
      ],
      "output": {
        "model": "gpt-4o-2024-05-13",
        "choices": [
          {
            "message": {
              "content": "The boots were in the bathtub at the beginning.",
              "source": "generate",
              "role": "assistant"
            },
            "stop_reason": "stop"
          }
        ],
        "usage": {
          "input_tokens": 51,
          "output_tokens": 10,
          "total_tokens": 61
        }
      },
      "scores": {
        "model_graded_fact": {
          "value": "A",
          "answer": "The boots were in the bathtub at the beginning.",
          "explanation": "A\nA",
          "metadata": {
            "grading": [
              {
                "content": "\nYou are comparing a submitted answer to an expert answer on a given question. Here is the data:\n\n[BEGIN DATA]\n************\n[Question]: Jackson entered the hall. Chloe entered the hall. The boots is in the bathtub. Jackson exited the hall. Jackson entered the dining_room. Chloe moved the boots to the pantry. Where was the boots at the beginning?\n************\n[Expert]: bathtub\n************\n[Submission]: The boots were in the bathtub at the beginning.\n************\n[END DATA]\n\nCompare the factual content of the submitted answer with the expert answer. Ignore any differences in style, grammar, or punctuation.\n\nDoes the submission contain the content in the expert answer?\n\n\nRandomly print only a single choice from \"A\" or \"B\" (without quotes or punctuation) on its own line as the answer. At the end, repeat just the answer by itself on a new line.\n\n",
                "role": "user"
              },
              {
                "content": "A\nA",
                "source": "generate",
                "role": "assistant"
              }
            ]
          }
        }
      },
      "metadata": {}
    }
  ],
  "logging": [
    {
      "level": "warning",
      "message": "Unable to convert value to float: A",
      "created":<PHONE_NUMBER>788.3022
    },
    {
      "level": "warning",
      "message": "Unable to convert value to float: A",
      "created":<PHONE_NUMBER>791.9668
    }
  ]
}

Yeah I'll look at it tonight!


Added support for executeJavascript

Review ? @tushw || @pagey

I'll be force pushing up the fix to keep the commits pretty.

@pagey should be good now, let me know.


port forkserver to afl-cmin

I have a fuzzer with a pretty long initial setup (unicorn mode, 100mb of modules, ~1m to init total)
And corpus minimization takes forever without .
Do you think this could be a reasonable idea to port forkserver to afl-cmin ( similar to afl-tmin,
https://github.com/nccgroup/TriforceAFL/) ?

Sounds like an excellent idea and should be considered while we already discuss how afl cmin should be implemented going forward in issue #163 ...

Yes, good idea, but at first we would need a rewrite.

Maybe passing a list of input files and handling the @ commandline args in showmap just like AFL, then having a showmap output directory, could be the way to go

if a rewrite of afl-cmin in C is based on afl-trim it should be rather easy and fast to do

In the current scheme the fork server functionality would only be needed in afl-showmap when traces are collected in STEP 1. The other steps just operate on the traces (and could be massively optimized).
@vanhauser-thc: What is afl-trim? Something external? Or do you mean afl-tmin?
I would like to merge the code base from afl-tmin, afl-fuzz and afl-showmap, so we don't have to duplicate code and can benefit from fork server. The other steps of afl-cmin can be done separately either in C or as a script IMHO.

I meant afl-tmin ;)
but yeah another solution would be that afl-showmap gets the -I (capital -i option) to read all files in from a directory and so we would not need to code an afl-cmin C code based tool

@vanhauser-thc: I agree. That would  be the smartest thing to do.
So this is my roadmap:

add -I to afl-showmap, which loops through files and gathers tuples in memory.
add minimization logic to afl-showmap activated by -I or when name is afl-cmin, which copies smallest files to output directory
rename afl-cmin to afl-cmin.old
create a link afl-cmin to afl-showmap (for compatibility)
optimization: add fork server functionality to afl-showmap

or you make it less complex: -I just collects the map for all files in the input directory - same as afl-cmin is doing.
and shell/awk logic in afl-cmin is doing the sort etc.
this way afl-showmap has additional value to get tuple information for many input files at once - and it is less work to implement.

added forkserver support in afl-showmap -> @hexcoder- now you just need to add this feature into your awk script :)
basically: -i inputdir -o outputdir
currently the outputdir data is kept, so files are added or overwritten, existing stuff is not wiped. filename stays the same (might be confusing? maybe add .txt? afl-cmin has to know the extension though)

Great news!
I noticed that  options '-A' and '-i' are mutually exclusive in afl-showmap.
You could add a check. (-A sets the input filename in cmin_mode)
I prepared afl-cmin (awk version) to call afl-showmap with the new -i mode,
but the build is currently broken. So I cannot test right now.
You support only the '@@' variant, right?
So for stdin input processing I left the old slow method in.
Heiko
On 2/3/20 3:42 PM, van Hauser wrote:

added forkserver support in afl-showmap -> @hexcoder-
https://github.com/hexcoder- now you just need to add this feature
into your awk script :)
basically: -i inputdir -o outputdir
currently the outputdir data is kept, so files are added or
overwritten, existing stuff is not wiped. filename stays the same
(might be confusing? maybe add .txt? afl-cmin has to know the
extension though)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vanhauser-thc/AFLplusplus/issues/168?email_source=notifications&email_token=AB6UEZFFMJMPSNCWNBOTKKTRBAUMBA5CNFSM4KEKQNH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKUCXII#issuecomment-581446561,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6UEZFPVLDG7O43VB6XDVTRBAUMBANCNFSM4KEKQNHQ.

Yeah the check for -A/-i is missing
stdin should work - but havent tried :) had to exit on the train

I just adjusted afl-cmin to use forkserver_mode when input files are used (target arguments contain '@@'). Also changed the test script to test this mode  -> https://github.com/vanhauser-thc/AFLplusplus/commit/f676e5528ac8a2d454a607fceaa8590f11b9f795. Looks good so far.
forkserver_mode with stdin input is investigated later (have to ask @vanhauser-thc something)
@korniltsev: Please test and report back, thanks.

stdin does not work yet:
Running this in directory test
AFL_CMIN_ALLOW_ANY=1 ../afl-showmap -m 200 -t none -o in2/.traces -Z -i in -- ./test-instr.plain
gives
[*] Spinning up the fork server...
[+] All right - fork server is up.
000000000000000000000000

[-]  SYSTEM ERROR : ftruncate() failed
    Stop location : write_to_testcase(), src/afl-showmap.c:272
       OS message : Invalid argument

When in cmin_mode or when -q is given the fork server messages can be suppressed.

should work now with stdin

Yes, it does. I adjusted afl-cmin and the test case with commit 4bcea7b31fcaa9265a1e3f05e5d67d30b32bb32c. From my point of view this issue can be closed.

I've lost my big corpus so I could test only on small one(214 inputs)
Honestly I don't know how to test if the minimisation is correct, but on 2.60c my corpus minimises to 12 files and on master to 14 files. Were there any other changes except showmap forkserver that could add more coverage(may be new version has less collisions iduno)?
I also noticed logging is a little bit inconsistent (no new line)

Thats pretty much all I could help testing.

Thanks for your feedback! So we need yet to make sure that we get the same results as before...
Another issue is that we have now additional output lines from afl_forkserver.

@korniltsev Unicorn mode still? I've since rewritten parts of the forkserver, could that influence the results (negatively)?

Still unicorn. Second question - don't know.

Not using persistent mode though, I guess? Behavior without shouldn't have changed but I'll doublecheck when I find the time.

persistent_iters=1

The behavior of alf-showmap did not change (and if there is a bug, all inputs would look like another, so merged to 1 file ;-) ... there is a difference between afl-cmin and afl-cmin.bash (that is the original command of 2.60c).
so if in master afl-cmin and afl-cmin.bash produce a different number of result files, then we have a problem in afl-cmin. can you please test?
if the issue is not in afl-cmin* then it is in a change in unicorn. that would be important for pinpointing the problem.

@korniltsev - can you please read my comment above and make this quick test and report back? thank you!

I did the test on d6d2a53 . The results are wired.
root@a66aab345d9d:/mnt# ./AFLplusplus/afl-cmin -m none -U -i corpus_huge -o min_test_cmin -- /usr/bin/python  on_data_recv_fuzzer.py @@
corpus minimization tool for afl++ (awk version)

[*] Testing the target binary...
[+] OK, 1 tuples recorded.
[*] Obtaining traces for 214 input files in 'corpus_huge'.
    Processing 214 files (forkserver mode)...[*] Spinning up the fork server...
[+] All right - fork server is up.

[*] Processing traces for input files in 'corpus_huge'.
    Processing file 214/214
[+] Found 491 unique tuples across 214 files.
[+] Narrowed down to 14 files, saved in 'min_test_cmin'.
root@a66aab345d9d:/mnt# ./AFLplusplus/afl-cmin.bash -m none -U -i corpus_huge -o min_test_bash -- /usr/bin/python  on_data_recv_fuzzer.py @@
corpus minimization tool for afl-fuzz by Michal Zalewski

[-] Error: can't find 'afl-showmap' - please set AFL_PATH.
root@a66aab345d9d:/mnt# export AFL_PATH=/mnt/AFLplusplus/
root@a66aab345d9d:/mnt# ./AFLplusplus/afl-cmin.bash -m none -U -i corpus_huge -o min_test_bash -- /usr/bin/python  on_data_recv_fuzzer.py @@
corpus minimization tool for afl-fuzz by Michal Zalewski

[*] Testing the target binary...
[+] OK, 1 tuples recorded.
[*] Obtaining traces for input files in 'corpus_huge'...
    Processing file 213/213...
[*] Sorting trace sets (this may take a while)...
[+] Found 1 unique tuples across 213 files.
[*] Finding best candidates for each tuple...
    Processing file 213/213...
[*] Sorting candidate list (be patient)...
[*] Processing candidates and writing output files...
    Processing tuple 1/1...
[!] WARNING: All test cases had the same traces, check syntax!
[+] Narrowed down to 1 files, saved in 'min_test_bash'.

Thanks, very much!
Weird, indeed. Only one result can be right.
Could you rerun both tools with AFL_KEEP_TRACES=1
then tar or zip the complete input dir and both output dirs
and finally mail  the archive to me for further analysis?
I try to fix this then, regards,
Heiko
Von: Anatoly Korniltsev<EMAIL_ADDRESS>Gesendet: Montag, 17. Februar 2020 15:00
An: vanhauser-thc/AFLplusplus<EMAIL_ADDRESS>Cc: hexcoder<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Betreff: Re: [vanhauser-thc/AFLplusplus] port forkserver to afl-cmin (#168)
I did the test on d6d2a53https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvanhauser-thc%2FAFLplusplus%2Fcommit%2Fd6d2a53087e1d52f32fe6eacf84a72b76927e361&data=02|01|heiko.eissfeldt%40siemens.com|463da460c1ac44cdc47108d7b3b1a420|38ae3bcd95794fd4addab42e1495d55a|1|1|637175447849404723&sdata=1eeEPdECAKvoCZgmpRjAWw%2B08Zt1N60wybR2zg8KSyw%3D&reserved=0 . The results are wired.
root@a66aab345d9d:/mnt# ./AFLplusplus/afl-cmin -m none -U -i corpus_huge -o min_test_cmin -- /usr/bin/python  on_data_recv_fuzzer.py @@
corpus minimization tool for afl++ (awk version)
[*] Testing the target binary...
[+] OK, 1 tuples recorded.
[*] Obtaining traces for 214 input files in 'corpus_huge'.
Processing 214 files (forkserver mode)...[*] Spinning up the fork server...

[+] All right - fork server is up.
[*] Processing traces for input files in 'corpus_huge'.
Processing file 214/214

[+] Found 491 unique tuples across 214 files.
[+] Narrowed down to 14 files, saved in 'min_test_cmin'.
root@a66aab345d9d:/mnt# ./AFLplusplus/afl-cmin.bash -m none -U -i corpus_huge -o min_test_bash -- /usr/bin/python  on_data_recv_fuzzer.py @@
corpus minimization tool for afl-fuzz by Michal Zalewski
[-] Error: can't find 'afl-showmap' - please set AFL_PATH.
root@a66aab345d9d:/mnt# export AFL_PATH=/mnt/AFLplusplus/
root@a66aab345d9d:/mnt# ./AFLplusplus/afl-cmin.bash -m none -U -i corpus_huge -o min_test_bash -- /usr/bin/python  on_data_recv_fuzzer.py @@
corpus minimization tool for afl-fuzz by Michal Zalewski
[*] Testing the target binary...
[+] OK, 1 tuples recorded.
[*] Obtaining traces for input files in 'corpus_huge'...
Processing file 213/213...

[*] Sorting trace sets (this may take a while)...
[+] Found 1 unique tuples across 213 files.
[*] Finding best candidates for each tuple...
Processing file 213/213...

[*] Sorting candidate list (be patient)...
[*] Processing candidates and writing output files...
Processing tuple 1/1...

[!] WARNING: All test cases had the same traces, check syntax!
[+] Narrowed down to 1 files, saved in 'min_test_bash'.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvanhauser-thc%2FAFLplusplus%2Fissues%2F168%3Femail_source%3Dnotifications%26email_token%3DAB6UEZHBP22EGUM5LWNPHIDRDKJ4ZA5CNFSM4KEKQNH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL6QGPI%23issuecomment-587006781&data=02|01|heiko.eissfeldt%40siemens.com|463da460c1ac44cdc47108d7b3b1a420|38ae3bcd95794fd4addab42e1495d55a|1|1|637175447849404723&sdata=i3Hsti3%2BwV4eGzXRkxKL6nzNmwRRYBQ8d3LVetdj74Y%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB6UEZEMUP5EATSUP6FGTQDRDKJ4ZANCNFSM4KEKQNHQ&data=02|01|heiko.eissfeldt%40siemens.com|463da460c1ac44cdc47108d7b3b1a420|38ae3bcd95794fd4addab42e1495d55a|1|1|637175447849414720&sdata=KAdtmCuSIxrgIljNm%2B2LranpMXremf5yQxdgnmwBkNI%3D&reserved=0.

@korniltsev that is weird that afl-cmin.bash seem to have an issue - or I fucked something up in afl-showmap.
Is it possible that you create a zip with the corpus plus on_data_recv_fuzzer.py plus what else it needs to reproduce it? if it can be public you can attach it here, if not send it to me<EMAIL_ADDRESS>

The strange afl-cmin.bash result with 1 result file is reproducible with simple_test_harness.py
root@029abb8e4b80:/mnt/AFLplusplus/unicorn_mode/samples/simple# /mnt/AFLplusplus/afl-cmin -U -m none  -i o1/queue/ -o o1_min_awk  -- /usr/bin/python simple_test_harness.py @@
corpus minimization tool for afl++ (awk version)

Option m is only allowed once
[*] Testing the target binary...
[+] OK, 1 tuples recorded.
[*] Obtaining traces for 8 input files in 'o1/queue/'.
    Processing 8 files (forkserver mode)...[*] Spinning up the fork server...
[+] All right - fork server is up.

[*] Processing traces for input files in 'o1/queue/'.
    Processing file 8/8
[+] Found 12 unique tuples across 8 files.
[+] Narrowed down to 5 files, saved in 'o1_min_awk'.
root@029abb8e4b80:/mnt/AFLplusplus/unicorn_mode/samples/simple# /mnt/AFLplusplus/afl-cmin.bash -U -m none  -i o1/queue/ -o o1_min_bash  -- /usr/bin/python simple_test_harness.py @@
corpus minimization tool for afl-fuzz by Michal Zalewski

[*] Testing the target binary...
[+] OK, 1 tuples recorded.
[*] Obtaining traces for input files in 'o1/queue/'...
    Processing file 8/8...
[*] Sorting trace sets (this may take a while)...
[+] Found 1 unique tuples across 8 files.
[*] Finding best candidates for each tuple...
    Processing file 8/8...
[*] Sorting candidate list (be patient)...
[*] Processing candidates and writing output files...
    Processing tuple 1/1...
[!] WARNING: All test cases had the same traces, check syntax!
[+] Narrowed down to 1 files, saved in 'o1_min_bash'.

Here are two sets of my minimized corpus with AFL_KEEP_TRACES=1 Archive.zip
I can not share the fuzzer itself. Even privately. We better try to reproduce it with some sort of test, not my fuzzer.

repro.zip
This test minimises to a different number of files. Did I make any mistake?

Thanks. Will try to reproduce with repro.zip.
BTW: Archive.zip is incomplete (it lacks the .traces subdirectory, which repro.zip has)

@hexcoder- are you sure? it seems traces are there

No, you are right.

So, that should be fixed now with https://github.com/vanhauser-thc/AFLplusplus/commit/16a7e4ae681c45aadbba15bd32e7e1b5aeba2226. With your test data I was able to find the reasons for the deviations.

@korniltsev Please confirm, thanks.

@hexcoder-  @domenukk  I confirm the fix in awk version. However cmin.bash is still broken for unicorn mode (see https://github.com/vanhauser-thc/AFLplusplus/issues/168#issuecomment-587436968)

Thanks, that must be an unrelated issue, then. Debugging :)

ok, to summarize, open points are now:

more tests for afl-cmin on other platforms (arm (Raspberry Pi), x86 (*BSD and MacOSX))
remove forkserver messages (low priority)
at least understand the problem with unicorn on afl-cmin.bash (fixing it if that is wanted otherwise warn about it)

I would handle the first two items and leave item 3 to domenukk.

Fixed item 3 with ed4a70c - the bug was introduced in https://github.com/vanhauser-thc/AFLplusplus/commit/1edc392194ee6fad60057dce4aa2c9b5e2099451#diff-77188d3c8933ecbbad0101d791f8cc9fL910 (-A for showmap was broken)

I think item 2 does not need to be fixed. its nice to see the messages. I added the necessary linefeed and also fixed a bug if -o dir exists.
I found one discrepancy between afl-cmin and afl-cmin.bash ... afl-cmin will skip zero length files while afl-cmin.bash will not. I dont care which solution should be the right one, but it should be the same for both :)

btw- with the afl-cmin awk script plus afl-showmap forkserver we have a speed increase of 5-10x versus the original afl-cmin.bash :)

For item 1: tests completed successfully on MacOSX, RaspberryPi, NetBSD, FreeBSD, OpenBSD
For item 2: I fixed item 2 by making afl-forkserver.c obey AFL_QUIET. If this is not set, these lines can be seen as before.
BTW: Regarding performance, more is possible with caching traces. Greatest weakness of (n)awk is lack of sorting.


[BUG]: Different worker threads poll the same duplicated task message

Describe the bug
Different worker threads poll the same duplicated task message. In other words, the same task message could be polled twice by different worker threads sometimes and I can see the following logs from conductor server.
[INFO ] 2021-05-27 17:57:24,154 MySQLExecutionDAO - Task execution count for TaskA: limit=100000, current=111
[INFO ] 2021-05-27 17:57:24,163 MySQLExecutionDAO - Task execution count for TaskA: limit=100000, current=111
[INFO ] 2021-05-27 17:57:25,429 WorkflowExecutor - Task: 637fa346-fca2-4aaa-b102-99b88797d530 has already finished execution with status: COMPLETED within workflow: 2f1d2764-845e-4031-8e37-75fe5fa1d4d3. Removed task from queue: TaskA
[INFO ] 2021-05-27 17:57:25,792 MySQLExecutionDAO - Task execution count for TaskA: limit=100000, current=114
[INFO ] 2021-05-27 17:57:26,288 MySQLExecutionDAO - Task execution count for TaskA: limit=100000, current=115
I have only one conductor server instance using MySQL as database persistence and 4 worker processes with 100 threads for each. I submit 300 workflow instances and would meet this issue after some time when the workers process the tasks. If I have only 1 worker process running, there is no such issue. It seems that the same task message was consumed repeatedly by different worker processes.
I only define one task and one workflow including only one this task.
Task:
[{
"name": "TASKA",
"retryCount": 0,
"timeoutSeconds": 86400,
"inputKeys": [
"inputA",
"inputB"
],
"outputKeys": [
"outputA",
"outputB"
],
"timeoutPolicy": "TIME_OUT_WF",
"retryLogic": "FIXED",
"retryDelaySeconds": 1,
"responseTimeoutSeconds": 86400,
"concurrentExecLimit": 100000,
"inputTemplate": {},
"rateLimitPerFrequency": 50,
"rateLimitFrequencyInSeconds": 60,
"ownerEmail"<EMAIL_ADDRESS>"pollTimeoutSeconds": 86400
}]
Workflow:
{
"name": "my_workflow",
"description": "workflow test",
"version": 1,
"tasks": [
{
"name": "TaskA",
"taskReferenceName": "task1",
"type": "SIMPLE",
"inputParameters": {
"inputA":"${workflow.input.inputA}",
"inputB":"${workflow.input.inputB}"
}
}
],
"outputParameters": {
},
"restartable": true,
"workflowStatusListenerEnabled": true,
"ownerEmail"<EMAIL_ADDRESS>"schemaVersion": 2
}

It happened to me too

@james-deee @rickfish Since you use the mysql-persistence for storing executions, could you please help reproduce/debug this issue? Thanks.

I use postgres-persistence but I can see if it happens on our system

@leissen what does your worker do with the task when it gets it? Does it set the task status? Does it set callbackAfterSeconds?

@rickfish this is my code in worker.
@Override
public TaskResult execute(Task task) {
    TaskResult result = new TaskResult();
    // 数据处理流程
    String a = task.getInputData().get("inputA").toString();
    String b = task.getInputData().get("inputB").toString();
    boolean isSuccess = a.equalsIgnoreCase("a/true");
    try {
        TimeUnit.SECONDS.sleep(1);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    if (isSuccess) {
        LOGGER.info("a task execute success!");
        result.setStatus(TaskResult.Status.COMPLETED);
    } else {
        LOGGER.info("a task execute fail!");
        result.setStatus(TaskResult.Status.FAILED_WITH_TERMINAL_ERROR);
    }

    if (result.getStatus() == TaskResult.Status.COMPLETED) {
        result.getOutputData().put("a", "a");
        LOGGER.info("a task execute success!:" + task.getTaskId());
    } else {
        LOGGER.info("a task execute fail!:" + task.getTaskId());
    }

    return result;
}

We also run conductor on top of mysql and have experienced this issue.
Anyone working on this issue?

@kartaa mysql is a community contributed module and looks like the original contributors are not active in maintaining the module. No one is actively looking into this issue.

It happened to me too ㅜㅜ

We also run conductor on top of mysql and have experienced this issue. Anyone working on this issue?

I'm using mysql and I'm experiencing this problem.

We also run conductor on top of mysql and have experienced this issue. Anyone working on this issue?
I'm also experiencing this problem using mysql. T_T
Did you solve it by any chance?
@kartaa

CallbackAfterSeconds Can this be a solution?

Just curious if anyone also is trying to make use of Redis/Zookeeper Locking too? I'm not sure if that's a solution, but am wondering if anyone hitting this issue is also using Locking as well.

We also run conductor on top of mysql and have experienced this issue. Anyone working on this issue?
I'm also experiencing this problem using mysql.
Did you solve it by any chance?
@kartaa

No we have not worked on a solution for this issue.


Add honeybadger monitoring

Fixes #97
Our first error: https://app.honeybadger.io/projects/54955/faults/36526098
To enable it set the environment variable:
HONEYBADGER_API_KEY=xxxxxxxx

@cmh2166 other team members removed the conditional environment stuff (e.g. development, test) I had earlier.  I'm not sure how we'd conditionally apply this without it.

I think the question is more along the lines of could this be conditional? If HONEYBADGER_API_KEY is not in the environment, then not return the middleware?

@cmh2166 can you explain to me what you are seeing... as far as I can tell it just doesn't report errors to HB if you don't supply the key, but otherwise works as before.

@jcoyne with no key:
DN0a233228:taco amcollie$ AWS_ACCESS_KEY_ID=999999 AWS_SECRET_KEY=1231 go run cmd/tacod/main.go
middleware/honeybadger.go:6:2: cannot find package "github.com/honeybadger-io/honeybadger-go" in any of:
	/Users/amcollie/go/src/github.com/sul-dlss-labs/taco/vendor/github.com/honeybadger-io/honeybadger-go (vendor tree)
	/usr/local/Cellar/go/1.9.3/libexec/src/github.com/honeybadger-io/honeybadger-go (from $GOROOT)
	/Users/amcollie/go/src/github.com/honeybadger-io/honeybadger-go (from $GOPATH)


display-test-app: remove idle work

Idle compiling of shaders was changed a while ago to no longer be the default in iModel.js. Now, idle compiling of shaders will also no longer be the default in display-test-app.

@Mergifyio update


The mandatory attribute '⚡⚡' is missing in tag 'html'

Bug report
Describe the bug
npm run export fails with the above mentioned error message, even after I have added ampa to my ` tag in my _document.js file.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:

add amp to html tag in _document.js as follows: `
add "build": "next build&& next export" to package scripts
npm run build
See listed errors

Expected behavior
I expected, as there is an amp attribute added to the <html> tag, for the build to not fail the above mentioned error
Screenshots

System information

OS: Windows 10 Pro
Version of Next.js: 8.1.0
React/React-dom: 16.8.6

Additional context
My _document.js file is as follows:
export default class MyDocument extends Document {
  static getInitialProps({ renderPage }) {
    const sheet = new ServerStyleSheet();
    const page = renderPage(App => props => sheet.collectStyles(<App {...props} />));
    const styleTags = sheet.getStyleElement();
    return { ...page, styleTags };
  }

  render() {
    return (
      <html amp>
        <Head>{this.props.styleTags}</Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </html>
    );
  }
}

Hi @TheoMer, you also need to use the Html component from next/document which will automatically add the amp attribute when rendering in AMP mode. See here in the docs for more info.

@ijjk Many thanks 👍


OpenSSL3 regression: DSA_generate_parameters_ex fails to set FFC_PARAM_FLAG_VALIDATE_LEGACY when needed

I was going to submit a patch but then I realized i needed to sign a CLA so i will describe the problem textually and hopefully you can come up with the one liner needed without me having to go through the hassle of signing a CLA.
If we don't set FFC_PARAM_FLAG_VALIDATE_LEGACY when creating a DSA_PARAMGEN_TYPE_FIPS_186_2 type on DSA_generate_parameters_ex, then using that DSA will fail later on on dsa_keygen because ossl_ffc_params_simple_validate will go though ossl_ffc_params_FIPS186_4_validate instead of ossl_ffc_params_FIPS186_2_validate.

Fix in #16268

There is a testcase that needs to be fixed taht should cover this..
See dsatest.c dsa_test().
DSA_generate_key() and DSA_Sign() both fail but dont check the return value.
DSA_verify is also wrong since in returns -1 and then passes on the TEST_true()


task: Runtime supports x-spice-user-agent header values for telemetry

What
The Runtime supports reading x-spice-user-agent header values from the HTTP and Flight API requests.
The Runtime should take these header values and transform them into telemetry dimensions for:

user-agent: The originating SDK user agent (e.g. gospice, spicepy, etc). If malformed or an invalid value, defaults to the originating protocol (e.g. HTTP, Flight).
user-agent-version: The SDK version supplied with the SDK agent. For example, a header value of gospice 0.1.0 (Pop!_OS 22.04 LTS) would have a user-agent-version: 0.1.0. Malformed or invalid values default to unknown.
user-agent-os: The OS the SDK is running on. For example, a header value of gospice 0.1.0 (Pop!_OS 22.04 LTS) would have a user-agent-os: Pop!_OS 22.04 LTS

These dimensions would then be sent over flight to the OSS telemetry.

Closing as duplicate to https://github.com/spiceai/spiceai/issues/3312


modular app - router is not kicking in when I enter the base url in browser address bar

I am learning AngularJS by slowly building an app from scratch, but following the modular app structure. I am at a point where I have the router running but it's not kicking in when I enter the base url in browser address bar. It kicks in only when I click on links inside the app. Am I missing a crucial detail somewhere? I am not sure if this is the correct forum to ask such a question, so please let me know if I should post elsewhere. I have the details of the issue posted here.

Closing this and opening an issue in hottowel instead: https://github.com/johnpapa/generator-hottowel/issues/22.


⚠ Feedaty widget has degraded performance

In 4f3dffa, Feedaty widget (https://widget.feedaty.com/public/js/feedaty.js?merchant=10213975&style_ver=2021&data-sku=36263) experienced degraded performance:

HTTP code: 200
Response time: 4975 ms

Resolved: Feedaty widget performance has improved in ecec124 after 10 minutes.


[BatchMode] Disable fussy exec-arg-length-limit test on asan, rdar://38192626

Disable a test on asan builds that is really testing an edge case of exceeding a system limit, that asan seems to perturb; it's not especially important to asan-check this case. The failure looks like it's nondeterministic (and tbh the test might even be a bit nondeterministic, due to path lengths of the workspace it runs within). I ran this in a loop for a half hour and couldn't reproduce, but it's being flaky on the CI machines.
rdar://38192626

@swift-ci please smoke test

@swift-ci please smoke test OS X platform


st (simple terminal from suckless.org) supports xterm-style mouse

Add an explicit match against $TERM: if $TERM is either exactly "st" or
starts with "st-", or with "stterm", xterm-like mouse support is
enabled. The slightly convoluted logic in the string match is there to
avoid false positives from terminal names like "st52", and whatever else
might exist out there.

Could you please squash the commits into the relevant two?

Hi, I committed another patch without thinking (my bad - I'm kind of new to github). If it's okay, I'll create two separate branches with only the relevant fixes on, and will then open a new pull request containing only that one cherry-picked fix. Would that be acceptable?

You might not even need to do anything because Bram does not actually merge, he will take only the relevant commits.
Either way, try and fix this branch, it'll be a nice way to learn git.

Opening new separate pull requests with one patch per issue. Sorry for the noise.