The name M3x8 would be a screw 3mm in diameter with an 8mm thread pitch.   In the current version this fails with the assertion
"Thread specification is too coarse for the diameter"
Because the threads are going to be deeper than the radius of the screw.   I've beefed up the error handling substantially and reduced the bug count as well, though still more bugs remain, sadly.
Note that I did eventually come to the same conclusion with regards to the anchor for flat heads.  I was wishing for a way to make it so you could have a single angle that was at the nominal length position, but I gave up on that idea.
Flat head height does appear in some of the standards documents.  I think I checked the values at some point, but I don't recall what diameter they used.  For the application of making holes that are oversized you are probably safe with computing the height from the nominal diameter and the "head_size_sharp" value.  (But if your BOSL2 is old you won't have that.)  If you compute relative to "head_size" instead then your countersinks will be too small and I think the screws will stick up.

I implemented a rudimentary side trap and tested it on your example.  I think it works properly.  (Arguably better since it doesn't produce all the z-fighting.)
module nut_trap_side(spec, width, anchor, orient, spin) {
  nutdata = _NutInfo(screw_info(spec));
  nutwidth = struct_val(nutdata,"diameter");
  nutthickness = struct_val(nutdata, "height");
  cubesize = [width+nutwidth/2, nutwidth,nutthickness];
  shift = (cubesize[0]-nutwidth)/2;
  attachable(size=cubesize, offset=[shift,0,0],anchor=anchor,orient=orient,spin=spin)
  {
     left(nutwidth/2) cuboid(cubesize,anchor=LEFT);
     children();
  }
}

module block() {
    difference() {
        hexCyl(id = blockW, h = blockH, tent = blockTent);

        // Remove
        zrot(-60)
        fwd(blockW/2 + tiny)
//        ray_screw_hole(m5x8, anchor = "head", gap = 3, nut = "hex", trap = "side", orient = FORWARD, spin = 90);
        screw_hole("M5,9", anchor = TOP,orient=FORWARD, spin=90)
          position(TOP) down(3)nut_trap_side("M5",10,anchor=TOP);

        zrot(60 + tiny)
        fwd(blockW/2 + tiny)
//        ray_screw_hole(m5x8, anchor = "head", gap = 3, nut = "hex", trap = "side", orient = FORWARD, spin = 90);
          screw_hole("M5,9", anchor = TOP,orient=FORWARD, spin=90)
            position(TOP) down(3)nut_trap_side("M5",10,anchor=TOP);

    }
}

I assumed a square nut when I wrote this code.  I didn't implement the poke hole (which seems like a great idea, if I haven't mentioned that already).   But the positioning works, which seems like the most important thing.

I took a look at ISO-4032 and observe that your size data doesn't match up very well.
https://pppars.com/wp-content/uploads/2021/07/ISO-4032-2012-12.pdf
Then there are "style 2" nuts.  I don't understand what the difference is, but they seem to be thicker (is it just that they are thicker)?
https://pppars.com/wp-content/uploads/2021/07/ISO-4033-2012-12.pdf
These nuts are even bigger.  Grade C?
https://pppars.com/wp-content/uploads/2021/07/ISO-4034-2012-12.pdf
Thin nuts:
https://pppars.com/wp-content/uploads/2021/07/ISO-4035-2012-12.pdf
https://pppars.com/wp-content/uploads/2021/07/ISO-4036-2012-12.pdf
The fine thread nuts seem to match up with ISO 4033..at least spot checked:
https://pppars.com/wp-content/uploads/2021/07/ISO-8673-2012-12.pdf
https://pppars.com/wp-content/uploads/2021/07/ISO-8674-2012-12.pdf
https://pppars.com/wp-content/uploads/2021/07/ISO-8675-2012-12.pdf
ISO likes to make a different document for every variation.   Anyways, looks like work is needed to get the nut database in shape.
It looks like maybe there are thin, normal and thick nuts?  Or maybe there are 4 thicknesses?
There seems to be no ISO standard for square nuts.  There is DIN 557, which specifies some dimensions that are different than hex nut dimensions.

I implemented inline trap, and also came up with the idea of passing the screw diameter down through $screwsize or something along those lines, so you don't have to give that parameter again to the nut trap.
// Module: nut_trap_inline()
// Usage:
//   nut_trap_inline(spec, length|l|heigth|h, [shape], [$slop], [anchor], [orient], [spin]) [ATTACHMENTS];
// Description:
//   Create a nut trap that extends along the axis of the screw.  The nut dimensions
//   will be increased by `2*$slop` to allow adjusting the fit of the trap for your printer.
// Arguments:
//   spec = screw specification
//   length/l/height/h = length/height of nut trap
//   anchor = Translate so anchor point is at origin (0,0,0).  See [anchor](attachments.scad#subsection-anchor).  Default: `CENTER`
//   spin = Rotate this many degrees around the Z axis after anchor.  See [spin](attachments.scad#subsection-spin).  Default: `0`
//   orient = Vector to rotate top towards, after spin.  See [orient](attachments.scad#subsection-orient).  Default: `UP`
module nut_trap_inline(spec, length, shape="hex", l, height, h, anchor, orient, spin) {
  spec = default(spec,$screwsize);
  length = one_defined([l,length,h,height],"l,length,h,height");
  assert(is_num(length) && length>0, "length must be a positive number");
  nutdata = _NutInfo(screw_info(spec));
  nutwidth = struct_val(nutdata,"nutwidth")+2*get_slop();
  default_tag("remove"){
    if (shape=="square")
      cuboid([nutwidth,nutwidth,length], anchor=anchor, orient=orient, spin=spin) children();
    else
      linear_sweep(hexagon(id=nutwidth),height=length, anchor=anchor,orient=orient, spin=spin) children();
  }
}

And in the example:
module clamp() {
    difference() {
        cube([bandH, bandH, 14], anchor = CENTER);

        // Remove
//        up(.01)screw_hole(screwContext, anchor = "gap");
        screw_hole("M3,12",head="socket",counterbore=6,anchor=CENTER)
          position(BOT) nut_trap_inline(l=6,anchor=BOT);

        cube([10, 10, 2], anchor = CENTER);
    }
}

The result of this code is this:

I do suspect that your cross section module might duplicate the function of front_half(), etc.
I've beefed up my side trap to handle poke holes and hex/square, so at this point, the main missing piece is a full scale lookup table for nut properties.

I took a look at the English nut standard a bit.  There is a confusing variety of nuts, but if I compare with what McMaster sells I can sort of identify what's typical.  However, there is the question about whether to size nuts at their standard thickness or at the tolerance extreme.  For width, the nominal size is the extreme, but for thickness, there is a 2-sided tolerance.  My actual nut samples on hand seem are all at or smaller than the nominal size except for a 5/16 jam nut which is .003 over, but still .004 under the max size.  If you make holes at the max size, some of these nuts will be rather loose in the hole.   I don't have any metric nuts, only English, so I can't check what happens there.
I lean towards choosing the nominal thickness for the tables rather than the max, but Ray, you thought that tables should have the extremes.  What do you think?

Sorry I've gone silent for a while. I'm not getting any mail from Github and I don't know why so I just check back here occasionally. It will take me a while to absorb what you've left here.
I looked a little at your example with the hex blocks. The method for positioning the traps seems fiddly and non intuitive.  That makes no sense to me. As I've said before, the custom  anchors I've implemented are what makes using my screw_hole easy. You've never really addressed what you think the anchors aught to be.

In the clamp example, where is the CENTER anchor of a screw hole? I have no idea. Does it include the counterbore? Only the screw part? It seems like it should be the center of the entire screw_hole. This may seem simple and straight forward to you, but you know attachabillity inside and out. I know it pretty well now too. But I suspect that only 10-15% of BOSL2 users use it regularly. No one outside that group would find
screw_hole("M3,12",head="socket",counterbore=6,anchor=CENTER)
          position(BOT) nut_trap_inline(l=6,anchor=BOT);

to make sense, let alone be intuitive.

I do suspect that your cross section module might duplicate the function of front_half(), etc.

Yup, almost exactly. crossSection replaces 6 of BOSL2s calls though. Since I understand anchors now though I'll probably recode it to use anchors instead of "x" and -x" etc. Mostly I would do that to take advantage of spin and orient.

Yes the CENTER anchor of a screw or screw hole is the center of the whole thing.    The TOP anchor is the top of the whole thing.    In the first example (the bottle holder?) I didn't give the screw a head, so TOP is the top of the hole.  It's probably not a bad idea to add more documentation about where the anchors are located.
crossSection replaces six calls?  I'm guessing it actually replaces one call, namely half_of().  Does it do anything that half_of() does not?  The six calls you are replacing are just convenience  shorthands that pass through to half_of().  I think the half_of calls may predate attachments and anchoring, though.  Maybe they need to be updated.
Positioning things in BOSL2 is based on the attachment system.  So the argument that we should try to make some special less flexible scheme for users who don't understand attachments doesn't really make sense to me.   To me your system is actually more obscure and harder to understand.  I don't know what "gap" means unless I read the manual.   And right now I do not know what "gap" means if I choose a flathead screw---and neither of the possible answers really makes sense with the word "gap".  But since attachment stuff is universal, I don't have to understand a special extra parameter.   If you want the trap 8 units below the head you just put it 8 units below the head.  If instead you want it up from the bottom of the screw you can do that.  As I mentioned earlier, you also have the option with the attachment scheme of positioning a trap relative to some model feature and then placing the screw through the trap.
I'm pondering the idea of adding an anchor point 1mm or 2mm below the bottom of the trap to make it easy to put the trap up from the bottom of the screw hole.  How much hole extension do you usually use beyond the trap?
I have, since my last post, implemented a nut_info() function that works for English nuts.  It accepts a shape argument for "hex" or "square" and a thickness arg that can be "thin", "thick" or "normal".  Or you can give an actual thickness.  I used the nominal thickness values, not the extreme tolerance limits on thickness.    I ignored "heavy" nuts and "fine" nuts.  ASME puts everything in one document, which was a little easier to digest than ISO's system of having six or more documents.   I have not tried to digest the ISO stuff.  I'm hoping there will also be a clear-cut thin, normal and thick size so the same terminology works.  The lack of any square ISO standards makes it harder to figure out what to do there.   In English standards, the square nuts were the same dimensions at small sizes (<1/4") but different dimensions at larger sizes when compared to hex nuts.

https://youtu.be/iR6OBlSzp7I?t=516  He shows in his study that screwing into unthreaded hole works, and is reasonably strong, but he doesn't recommend it because of the extra stress it creates in the part.  FYI.

I saw another idea I saw to reduce the stress is to screw the screw into a hexagon shaped hole: the extra material can squeeze into the corners.

Positioning things in BOSL2 is based on the attachment system. So the argument that we should try to make some special less flexible scheme for users who don't understand attachments doesn't really make sense to me. To me your system is actually more obscure and harder to understand. I don't know what "gap" means unless I read the manual. And right now I do not know what "gap" means if I choose a flathead screw---and neither of the possible answers really makes sense with the word "gap". But since attachment stuff is universal, I don't have to understand a special extra parameter. If you want the trap 8 units below the head you just put it 8 units below the head. If instead you want it up from the bottom of the screw you can do that. As I mentioned earlier, you also have the option with the attachment scheme of positioning a trap relative to some model feature and then placing the screw through the trap.

The reason gap is important is that you are attaching 2 shapes together using the screw. You need n mm of material in the first piece and m mm in the second piece. Usually n == m. Gap is simply n+m. In almost every design I have done with screws, the interface between the 2 pieces is the location I know best and can determine most easily. The two pieces are squeezed together between the head and nut. The important spots are the bottom of the head and top of the nut. The amount of head above the bottom and the amount of screw and nut below the top of the nut are non-critical. There just needs to be room for them.
The bottle cage holder is an exception because one piece being attached is a bottle cage and not being modeled. It is a 1 mm bit of aluminum. So in the design the hole is positioned so that the bottom of the head is at the surface or a little above it.

I saw another idea I saw to reduce the stress is to screw the screw into a hexagon shaped hole: the extra material can squeeze into the corners.

Probably a good idea.

https://youtu.be/iR6OBlSzp7I?t=516 He shows in his study that screwing into unthreaded hole works, and is reasonably strong, but he doesn't recommend it because of the extra stress it creates in the part. FYI.

Thanks, good video. I did not know about threads inserts. I doubt I'll ever have an application that requires them though. Everything i make is something I use somehow and they rarely involve much stress. I'll continue to use the unthreaded holes because in my applications there doesn't seem to be an issue. Plus I am usually using M3 screws so the radial stress is minimal.
The most recent example is a set of battery dispensers that fit together and hold AA, AAA and CR123 batteries. I create the whole model then split it in half using crossSection, print the 2 halves and the screw them together with M3,8 screws. Each half is easy to print. Near zero overhangs.

We evidently have very different ideas about how to design things.  I would say that if you are attaching things together, the two things are probably not the same size.  The natural choice is not to anchor under the head but to anchor at the top of the head and make a counterbore for the head, assuming there's room for that.   Centering the screw at the joint surface seems very unlikely to make sense, unless your screw is exactly the right size, and both sides are big enough to contain half the screw, or the assembly is symmetric.  And it might result in a deep counterbore, which can be annoying to use in practice.  And the positioning requirements would tend to be driven by whatever screws I have on hand.
My battery holder is entirely plastic, held together by sliding dovetails which wedge in place, and it prints without support.
https://www.printables.com/model/115498-wave-fifo-battery-holder
My other two part models I have glued together, either by designing them to assemble or by using the partitioning module to jigsaw cut them.   I don't foresee a need for those threaded inserts, but it's nice to be aware that they exist.

Nuet catches and tap holes are now implemented.


ami amazon-eks-node-1.26-v20230526 is remains NotReady on EKS 1.26.4

What happened:
amazon-eks-node-1.26-v20230526 ami-077f0926a1e86b272 is not getting added in EKS cluster 1.26.4.
Karpenter tried to scale up, but the nodes are NotReady.
What you expected to happen:
The node should be added normally in EKS 1.26.4
How to reproduce it (as minimally and precisely as possible):
Deploy karpenter on EKS 1.26.4 ,and Karpenter polls controller.provisioner.cloudprovider	discovered ami	{"commit": "698f22f-dirty", "provisioner": "default", "ami": "ami-077f0926a1e86b272", "query": "/aws/service/eks/optimized-ami/1.26/amazon-linux-2/recommended/image_id"} , the ami ami-077f0926a1e86b272 is not adding.
Anything else we need to know?:
Failed to get lease: leases.coordination.k8s.io
Environment:

AWS Region: us-east-1
Instance Type(s): m5.xlarge
EKS Platform version (use aws eks describe-cluster --name <name> --query cluster.platformVersion): eks.2
Kubernetes version (use aws eks describe-cluster --name <name> --query cluster.version): 1.26
AMI Version: ami-077f0926a1e86b272
Kernel (e.g. uname -a):
Release information (run cat /etc/eks/release on a node):

Debugging more
/close

/clodes

Apologies, the Issue is something to do with Permissions. iamidentitymapping


Belkin android app does not play well with others...

I don’t know when this started, but I just realized that the Belkin app wreaks havoc on my system when I use it to test the remote feedback.  This wasn’t always true.  Just looking at the upnp chatter, I think it is canceling all the subscriptions for anyone else, and possibly worse.  This took me days to realize that it was the Belkin app because, like I said, this is new.
There are better android alternatives for testing, anyway.

Closing until it's more widely reported as an issue. I'm not sure what we can do about it anyway.


Build doric for scala 2.11

As asked in #184 this thread is a list of all neaded for milestone Doric for scala 2.11
Pending tasks to migrate doric to scala 2.11 (spark 2.4 at least)

[x] Delete newtype #204
[x] Have spark-fast-tests build for scala 2.11 https://github.com/MrPowers/spark-fast-tests/pull/106
[x] Modularize Doric column to have a common interface that abstracts its use fro the cats version(no needed, look next)
[x] Cats imports must be ok #206
[x] Review methods that are not in spark 2.4

Doric 0.0.4 will have spark 2.4.x support (from 2.4.1 to 2.4.8) for scala 2.11


Bad call to matchesSelector (second arg empty string)

DOM exception in call to Element.prototype.matchesSelector (or whatever flavor gets selected there).
Because the second argument is an empty string.
This line:
https://github.com/cyclejs/cyclejs/blob/0789c082266326bf74211e6658b1cb9da6b19ed4/dom/src/matchesSelector.ts#L16
Notice that the commit above many not be correct because there are no tags (probably since multi-package repo).
Code to reproduce the issue:
git clone, git checkout repro.0, npm i, npm run dev and then try the demo of the click sink of the link component. Try to click on the link.
For reference, this is the commit:
https://github.com/mightyiam/cyclejs-web-components/commit/6071ba61ff9caeaa15a7acee24b11ddaf257f396#diff-799846bd6de8d46b58d81c5f7d164aecR31
Versions of packages used:
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>

Here's a reproducible example that @Frikki made a few months back
https://esnextb.in/?gist=4d38605258041d71702b65107a194b61

This is now fixed in @cycle/dom v21 :tada:


SAMZA-1786: Introduce metadata store abstraction.

As a part of SEP-11, this patch adds MetadataStore interface to store task and container locality in both yarn and standalone deployment models. Please refer to SEP-11 for more details.
Few important points to note:

As a part of this changes, LocalityManager/TaskAsssignmentManager alone will be updated to use this interface(subsequently in upcoming future RB's other util classes will be moved to use this interface as well).
In an immediate followup RB, ZkMetadataStore(storing metadata information in zookeeper) will be added. It will be used in standalone to read/write locality(through LocalityManager & other standard util classes).
In future, ExecutionPlan, streamGraph and other job related metadata can be stored in any custom store through the same abstraction.

Testing:

Added unit tests for new classes introduced in the patch(Fixed the existing unit tests in LocalityManager/TaskAssignmentManager).
All the changes in the patch were validated with test jobs in samza-hello-samza(https://github.com/apache/samza-hello-samza).
LinkedIn testing job(maes-tests-host-affinity) was verified with these changes to validate if things work end-to-end.

@prateekm @xinyuiscool @sborya
Please take a look when you get a chance.

cc @rayman7718, in case you have any feedback on the MetadataStore interface from the perspective of a diagnostics data store.

@shanthoosh : Would be preferable to structure the metadata store API to have string keys and byte-array values. Strings offer you nice properties around equality and prefix-checks.


Update CI

Add separate lint and test-only npm scripts
Update CI to run lint once and then run tests on matrix

Closes #18

Hm.. strange, standard is passing locally but failed on CI.. will take a look

I wasn't rebased on latest upstream. Linting on master is failing

:tada: This PR is included in version 0.1.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 0.1.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


SetApiVersion before auth causes permission denied error

You must be little bit more specific with this... which game are you trying to connect ? which dedicated server version ?
For tm2020, it works just fine with the latest dedicated server.
Starting Trackmania date=2024-03-18_16_00 git=126882-1ec72453936 GameVersion=3.3.0...

This is from my little nodejs script, based on the example in the readme.md file - works just fine

This should work fine.

You must be little bit more specific with this... which game are you trying to connect ? which dedicated server version ? For tm2020, it works just fine with the latest dedicated server.
Starting Trackmania date=2024-03-18_16_00 git=126882-1ec72453936 GameVersion=3.3.0...

That's the version I'm using
WARN[0000] /root/docker-compose.yml: `version` is obsolete
trackmania-1  | Starting Trackmania date=2024-03-18_16_00 git=126882-1ec72453936 GameVersion=3.3.0...
trackmania-1  | Configuration file : dedicated_cfg.txt
trackmania-1  | Loading system configuration...
trackmania-1  | ...system configuration loaded
trackmania-1  | Loading dedicated server configuration...
trackmania-1  | ...Dedicated server configuration loaded
trackmania-1  | Connecting to master server...
trackmania-1  | ...OK
trackmania-1  | Listening for xml-rpc commands on port 5000.

game version doesn't matter b/c there is no game connecting at this point

latest evo docker image


Update vendor/hackclub to latest commit

This pull request updates the vendor/hackclub submodule to the latest commit.

Once tests pass, I'm going to go ahead and merge this myself because I'm the only FTE on this project.
 Please continue to assign pull requests to me.


[RFC] make UpdateInterface() declarative

make UpdateInterface() declarative
And add interface_id to identify interfaces.
UpdateInterface() is using bitwise operation which is
too lowel and it doesn't support remove&add IPs at the
same grpc request. So it is changed to declarative way.
On declarative way, the agent should roll back when failed.
Rolling back can also fail again, the runtime need to know
the final result of the interface in this case, so the API
also returns the interface regardless its success or not.
Signed-off-by: Lai Jiangshan<EMAIL_ADDRESS>

I'm already not a huge fan of the current interface update mechanism as I think it should simply pass an Interface and expect the agent to be smart enough to make it the interface end state. i.e. it should not expect the runtime to know which fields to change and which to not change.
This change makes it more complex imo, for the only benefit of being able to remove and add IPs in one shot. So for me, either we keep the current update interface API intact or we simplify it to have a stateless runtime.

I can change the pr to declarative with return return. WDYT @sameo ?

That would look much better imho.

@sameo @laijs this sounds good to me too, but please let's make sure we all agree (cc @WeiZhang555  and @mcastelino) about this. Otherwise, we'll end up going back and forth on our agent implementation.

@sboeuf we need more people to know the changes and make a vote.

First, I'm not against the declarative API (related: https://github.com/kata-containers/agent/issues/19), what I want is a stable and reliable API. That meas for a delarative UpdateInterface API, if you send  a command to agent like Please update the interface A, add IP b and c, delete IP d, and update its name to E, it will complete this command as a whole or failed as a whole.
I hate so much about half successful APIs, such as you send the request to agent, and agent tell you Oh, I have successfully added IP b and c for you, but I failed to delete IP d, so that's all, you got a new interface with additional IP b and c with its name unchanged, or what's worse, the agent told you Sorry, I failed to do you command, but please, guess what you got? I won't tell you, hahaha
We do need delcarative APIs absolutely, but we should do better. Our current APIs apparently aren't good enough now.
check my previous comments: https://github.com/kata-containers/agent/pull/43#issuecomment-349509414

Hello, I update the pr
make UpdateInterface() declarative
And add interface_id to identify interfaces.
UpdateInterface() is using bitwise operation which is
too lowel and it doesn't support remove&add IPs at the
same grpc request. So it is changed to declarative way.
On declarative way, the agent should roll back when failed.
Rolling back can also fail again, the runtime need to know
the final result of the interface in this case, so the API
also returns the interface regardless its success or not.

@WeiZhang555

why name can't identify an interface

It can, but from the runtime it's hard to predict what is going to be the interface name inside the vm, while the MAC address is a unique identifier across the VM boundary.

@sameo Do you mean that we can leave name field empty when AddInterface and let runtime generate a predefined name for it?
I’m ok with using Mac as identifier, but in my thought, mac or name can meet same problem, they both can be given by user or generated randomly by runtime, and they both can be updated (mac maybe doesn’t need to be updated, not sure)

@mcastelino Once we change the interface_id with a MAC, would you be ok with that PR?
@laijs Do you mind changing interface_id to MAC address?

@sameo @mcastelino  @WeiZhang555 the only constraint with MAC address is that it MUST be unique inside a level-2 network. What if there are two NICs and each belongs to a different level-2 network. Their MAC address and other NIC properties are assigned by higher level network components. There is no guarantee that their MAC addresses must be different. If that is possible, we cannot use MAC address to identify a NIC.

@bergwolf I think we only need to make sure MAC is unique inside same VM,  and that’s easy to do from runtime level.

@WeiZhang555 It is possible that MAC is assigned by high level network components. How can a runtime make sure MAC is unique inside the same VM?

@bergwolf by reporting error when this happens, runtime should deny the operation when MAC is conflict. This can be a limitation rule

@WeiZhang555 Yes it can. But then we assume the upper layer network component should handle the error case of duplicating MAC addresses and retry with a different MAC address, which is confusing because MAC is simply an attribute of a NIC and (to the network component's knowledge) the MAC is not duplicated inside the level-2 network at all.

@sameo @mcastelino  As I'm also not sure if we will have a scenario that allows two interface having same MAC in single VM, maybe we should keep something like a link ID as identifier?
For example
$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
7938: veth760c9c2@if7937: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master docker0 state LOWERLAYERDOWN mode DEFAULT group default
    link/ether 6e:30:a8:f5:77:4b brd ff:ff:ff:ff:ff:ff link-netnsid 0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:0a:f7:92:80:17 brd ff:ff:ff:ff:ff:ff
7939: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master docker0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 7a:62:bb:79:5a:b2 brd ff:ff:ff:ff:ff:ff

We keeps the link ID such as 7938 or 2 as interface identifier, so in this case we don't have the unique MAC limitation any more.
What's your idea?  @sameo @mcastelino

@WeiZhang555 @bergwolf

As I'm also not sure if we will have a scenario that allows two interface having same MAC in single VM

AFAIK several interfaces with the same MAC can only be supported if they're in different broadcast domains. I can't see how we would ever want to support that in the same VM, in a container/Kubernetes context. I feel we're trying to find a solution for a non existing problem here.


Ancestors-fn support for clojurescript

The ancestors-fn option isn't handled on clojurescript side.
The fix is very simple changes to create-get-alphas-fn and assemble-session as far as I can see.
PR to follow.

Thanks for the PR! Assuming this is working in your project I'll go ahead and merge it.
Normally I'd like to add unit tests, but we're pretty weak there on the ClojureScript side in general. Hopefully we can improve test coverage here as part of the jump to reader expressions in Clojure 1.7...but until then I'm willing to merge this as it is assuming it's gone through at least some test.

I've tested it in my code and it works and is lightly tested but I'd understand wanting more thorough testing.

The change is simple enough and doesn't break anything on my end, so I'm happy to go ahead and merge it. We're going to take a pass through the ClojureScript code and try to port most of the Clojure tests over, at which point this will get covered.
Thanks for the contribution!


URGENT: Endless back-ups

Since a few days, the tool creates backups endlessly every few minutes. The Progress bar starts and starts and starts. How can I avoid this?

I deleted the One Drive Folder, stopped and started the add-on. No change, issue persist. May the following log lines help to fix the issue?
12/15/2024 07:06:48 [19] Info: Fetching Local Backup (Slug:1e2afdf0)
12/15/2024 07:06:48 [24] Info: Backup (1e2afdf0) fetched successfully
12/15/2024 07:06:49 [31] Info: Starting file upload. (Size:442296320 bytes. Attempt: 1/3)
12/15/2024 07:08:46 [32] Info: Upload completed successfully
12/15/2024 07:08:46 [29] Warning: Unrecognized file found in backup folder : 2024-12-14 01_00_00.tar
12/15/2024 07:08:46 [29] Warning: Unrecognized file found in backup folder : 2024-12-15 01_00_00.tar
12/15/2024 07:08:47 [29] Warning: Unrecognized file found in backup folder : 2024-12-14 01_00_00.tar
12/15/2024 07:08:47 [29] Warning: Unrecognized file found in backup folder : 2024-12-15 01_00_00.tar
12/15/2024 07:09:49 [31] Warning: Unrecognized file found in backup folder : 2024-12-14 01_00_00.tar
12/15/2024 07:09:49 [31] Warning: Unrecognized file found in backup folder : 2024-12-15 01_00_00.tar
12/15/2024 07:09:49 [32] Info: Found 1 backups to upload.

Hi,
No, I'd need to see 2 cycles for backups from the logs to see what's happening. It would also help setting the logging level to Verbose.
There is a new version though addressing a few issues that might be applicable to you published in the preview channel (version 2.3.8). Please try and install that version and if the problem persists, share the logs.

Thx a lot for responding. Admittedly however, I am not an HA "expert" and have no glue, how to update to 2.3.8.
I may patiently wait for the official release, except you take your valuable time to teach me how to update. Best, Uwe

It's very similar to the installation you had to do for the release channel. You can find the instructions in the Installation Instructions


Gulp Issue

Trying to run gulp --production after running npm install and bower install but it looks like my gulp task is not working properly as my public directory is not being created.

I have to run gulp with sudo due to permission issues on my raspberry pi running raspbian and other software I have running on the pi. Shouldn't make a difference in my opinion though, but correct me if I'm wrong on this.

Don't think this is a Koel issue per-se.

@phanan can you please explain why this isn't 'Koel Issue per-se'? I'm try to run the build script as outlined in the installation documentation and yet it's not resulting as it should according to the documentation. There is no output showing any errors that I can use to debug the issue, therefore it IS a Koel issue.

I'm try to run the build script as outlined in the installation documentation and yet it's not resulting as it should according to the documentation.

I don't recall documenting a sudo anywhere. If your environment is set up in a way that you need to rely on sudo, I'd say something is definitely wrong from the start.

There is no output showing any errors that I can use to debug the issue, therefore it IS a Koel issue.

Koel is built on top of a lot of other packages and libraries, one of which is Gulp and Laravel's Elixir, which in turn relies on Node/npm. If your installation of Node/npm is not working with Gulp/Elixir for whatever reason, I'd suggest you to explore and fix from there, not from Koel itself. As a matter of fact, I can't support you on this even if I had enough time, simply because I'm not a Gulp/Elixir/Node expert.

@phanan thanks for the expanded reply. Yes there is no sudo in the documentation, it's due to the fact I'm running the software on raspberry pi Linux software. I'll will look further into this issue myself


open as floating window

can you open Carbon as a floating window similar to telescope or fzf?

Not natively as in, there is no :Fcarbon command to spawn a floating instance, that said, this can easily be achieved by making a floating window yourself, making that the current window, and then executing normal! Carbon to show Carbon in your newly created floating window.
Is this something you would be willing to try to do yourself and potentially create a PR for it?

Hello @juantascon, I've added a new Fcarbon command which will now spawn a floating window. See :h Fcarbon for more information.


fix broken links to python and java endpoints doc

Due to an error on the travis.yml your PR is failing the tests. Could you pull from upstream and retry?
Thanks
Francesc

@campoy You know you can accept the PR without tests failing. There is literally 0 chance that updating links in a README will cause Travis to fail. The diff will be applied cleanly, the end :smile:

My goal was to get @jittuu to get a message asking him to sign the CLA.
But I can also ask it directly:
@jittuu, could you please sign this CLA https://cla.developers.google.com/
Thanks

Fancy :grin:

@campoy signed! :)


Binary Ninja: diverging instructions not being treated as such

Instructions such as ret are being treated as if they flow into the next instruction.
Instruction::Instruction automatically sets FLAG_FLOW if next_instruction is valid.  In the IDA exporter, next_instruction is chosen by looking for xrefs from the current instruction, so diverging instructions would have next_instruction == 0, which is invalid, causing FLAG_FLOW to not be set.  But in the Binary Ninja exporter, we just have:
  // TODO(cblichmann): Is this always the case in Binja?
  const Address next_instruction = address + instruction.length;

So it always gets set.
The code does already check for regular control flow later on, so it might be easiest to just reset FLAG_FLOW at that point:
--- a/binaryninja/main_plugin.cc
+++ b/binaryninja/main_plugin.cc
@@ -245,7 +245,9 @@ void AnalyzeFlow(
   if (has_flow) {
     // Regular code flow
     entry_point_manager->Add(instruction->GetNextInstruction(),
                              EntryPoint::Source::CODE_FLOW);
+  } else {
+    instruction->SetFlag(FLAG_FLOW, false);
   }

   const std::vector<BinaryNinja::ReferenceSource> xrefs =

This should be fixed now. Thanks for the report.


Proposed Addition for Increased Stacks on Reapply

Proposal done by @wozaiha , this pull request aims to make this a part of the MyStatus so you can select how many stacks are reapplied. My server and Client are ready to update when this is merged and updated, so there is no concern for any API version updates.

yeah looks fine, if it breaks its on you


Logging errors in a structured format

Description of change
Adds --event-log-directory CLI flag. If specified all of the logs originating from mountpoint_s3::logging::event_log will be written as \n-separated json's in this file. We do this logging in fuse_error! and fuse_unsupported! macros for failed fuse operations.
Note that the application log will also contain an additional log line per failed fuse operation with TRACE level even if the feature flag / cli option are not provided.
Relevant issues: https://github.com/awslabs/mountpoint-s3/issues/721
Does this change impact existing behavior?
If compiled without event_log feature flag there should be no changes to existing behaviour.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).

This will be addressed later.


Uibuilder fast follows

This PR refactors portions of uibuilder plugin to be more consistent with amplify-cli codebase standards.

Codecov Report

Merging #9207 (554601f) into master (4c12eb1) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9207   +/-   ##
=======================================
  Coverage   55.36%   55.36%
=======================================
  Files         887      887
  Lines       50331    50331
  Branches    10869    10869
=======================================
  Hits        27866    27866
  Misses      20393    20393
  Partials     2072     2072

Continue to review full report at Codecov.

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

Explanation on adding cp ../node_modules/typescript/lib/*.d.ts node_modules/typescript/lib/ to end of pkg-prune:
Codegen uses typescript virtual filesystem in order to support emitting type declarations of generated components. When the typescript virtual filesystem is initialized it looks for a list of typescript files based on the compile options used. See here: https://github.com/microsoft/TypeScript-Website/blob/v2/packages/typescript-vfs/src/index.ts#L204
Some of these files are .d.ts. It appears that typescript requires these .d.ts files in order to emit type declarations.
Error: File '/**/node_modules/typescript/lib/lib.d.ts' was not included into executable at compilation stage. Please recompile adding it as asset or script.

Originally pkg-prune removed all .d.ts file before creating the executable. Now pkg-prune will restore .d.ts files only in pkg/node_modules/typescript


Identity Access Management in SAP S/4HANA Cloud

Create a new tutorial for IAM in S/4HANA Cloud. Similar to https://github.com/SAP-samples/teched2023-DT167/tree/main

Are you referring to a specific tutorial?  Documents in the SAP-samples organization are not tutorials.

I dig a little digging and our usual sources for creating tutorials do not have this in their scope.  This would have to come out of security, with whom we do not typically receive content.  Might I suggest trying to ask about this in the SAP Community with for Application developers or with the respective product group?


Improved documentation.

Checklist

[1 ] Used a fork of the feedstock to propose changes
[1 ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[1 ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[1 ] Ensured the license file is being packaged.

This repairs the  display of the bages.
@conda-forge-admin please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Can't change the capitalized title

Hello,
First of all you make a great work, the theme is very clean ...
I'm tryiing to change how the title are displayed, but i'm not used to handle CSS. I prefer that the in the title not every word are capitalized. Could you help me please ? Thanks

Hi,
The layout templates is using the titlefunction to render h1 titles capitalized: https://github.com/humboldtux/startbootstrap-clean-blog/search?utf8=✓&q=<h1>{{+title+.Title+}}<%2Fh1>&type=Code
It might not be a good decision as it's not really flexible.
You have two options:

In your Hugo site, create a layout dir with all the previous template defining the h1 element, and remove the title function.
Wait a little i work on this, and push a commit :smile:

I think the second option will be the best for me ;-)

Hi @jflehe, i've changed the templates, tell me if it's ok for you.

Hi @humboldtux, it's fine, it work very well.
Thanks.

De rien :smile:


[BUG]: Provider produced inconsistent result after apply when changing the description of a subaccount

Is there an existing issue for this?

[X] I have searched the existing issues

What version of Terraform are you using?
1.5.2
What type of issue are you facing
bug report
Describe the bug
Changing the description of a btp_subaccount from Managed by Terraform! to Managed by Terraform changed! results in the following error when running terraform apply:
btp_subaccount.seoul: Modifying... [id=343cdaeb-215e-47e0-a009-eabbd9dce399]
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to btp_subaccount.seoul, provider "provider[\"registry.terraform.io/sap/btp\"]" produced an unexpected new value: .description: was cty.StringVal("Managed by
│ Terraform changed!"), but now cty.StringVal("Managed by Terraform!").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

Expected Behavior
The description should be changed or the provider should report that update is not yet implemented.
Is there documentation on which actions are already supported for which resource type?
Steps To Reproduce

Create a btp_subaccount with a description
Change the value of description
Run terraform apply

Add screenshots to help explain your problem
No response
Additional context
No response

Thanks for bringing this up. Issue is reproducible.
Here sample setup:
provider.tf:

terraform {
  required_providers {
    btp = {
      source  = "sap/btp"
      version = "0.1.0-beta1"
    }
  }
}

# Please checkout documentation on how best to authenticate against SAP BTP
# via the Terraform provider for SAP BTP
provider "btp" {
  globalaccount = "ticrossa"
}

main.tf:
resource "btp_subaccount" "test_subaccount" {
  name        = "My TF Project"
  description = "My TF Project - renamed"
  subdomain   = "my-project"
  region      = "us10"
  labels      = { "Org" : ["my-org"] }
}


[Issue-853] WIP - Updating user index view to boostrap 4

Resolves #853
Description

Type of change
Updating view to use Bootstrap 4
How Has This Been Tested?
WIP
Screenshots
WIP

Solid! :+1:


Open results next to current tab

Add-on version: 1.1.1
Browser: Firefox Developer Edition 55.0b6 (64-Bit)
Currently a new tab at the end of the tab bar will be opened for image results. It'd much more handy to have them open next to the current tab.

Thank you for the suggestion! I added in in 1.2.0 and will upload it to AMO and Opera Store now, you just need to wait for the approval process.

Thanks, that was quick! Works already.


Regression: problem with some zip : ZipCoder MALFORMED

Describe the bug
A regression with version 8.0.2 has been found. Some zip throws java.lang.IllegalArgumentException: MALFORMED
This is the exact same symptoms than old issue "#12 Problem with some zip-files"
The files in the ZIP contains special characters like é (French accentuated e), ' (single quote) and - (dash)
It was working with version 7.4.4
Version of dependency-check used
The problem occurs using version 8.0.2 of the maven plugin
Log file
[INFO] Analysis Started
[WARNING] An unexpected error occurred during analysis of '/work/jenkins/workspace/****.zip' (Archive Analyzer): MALFORMED
[ERROR]
java.lang.IllegalArgumentException: MALFORMED
    at java.util.zip.ZipCoder.toString (ZipCoder.java:58)
    at java.util.zip.ZipInputStream.readLOC (ZipInputStream.java:300)
    at java.util.zip.ZipInputStream.getNextEntry (ZipInputStream.java:122)
    at org.owasp.dependencycheck.analyzer.ArchiveAnalyzer.extractArchive (ArchiveAnalyzer.java:582)
    at org.owasp.dependencycheck.analyzer.ArchiveAnalyzer.extractFiles (ArchiveAnalyzer.java:457)
    at org.owasp.dependencycheck.analyzer.ArchiveAnalyzer.extractAndAnalyze (ArchiveAnalyzer.java:295)
    at org.owasp.dependencycheck.analyzer.ArchiveAnalyzer.analyzeDependency (ArchiveAnalyzer.java:277)
    at org.owasp.dependencycheck.analyzer.AbstractAnalyzer.analyze (AbstractAnalyzer.java:131)
    at org.owasp.dependencycheck.AnalysisTask.call (AnalysisTask.java:88)
    at org.owasp.dependencycheck.AnalysisTask.call (AnalysisTask.java:37)
    at java.util.concurrent.FutureTask.run (FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624)
    at java.lang.Thread.run (Thread.java:750)
[INFO] Finished Archive Analyzer (2 seconds)

To Reproduce
Steps to reproduce the behavior:

Create a ZIP file with files having characters é (French accentuated e), ' (single quote) and - (dash)
Run analysis

More likely you're suffering from an intentional change referenced in the release notes:

ArchiveAnalyzer will now correctly throw an exception if it cannot open an Archive (https://github.com/jeremylong/DependencyCheck/pull/5371).

I don't think. I reverted to version 7.4.4 and there is no warning:
15:33:12 [INFO] Analysis Started
15:33:14 [INFO] Finished Archive Analyzer (2 seconds)
15:33:14 [INFO] Finished File Name Analyzer (0 seconds)
15:33:17 [INFO] Finished Jar Analyzer (2 seconds)
....

The error would have been in the debug log - not output to the console.

I'm seeing something similar in the gradle plugin, when scanning a zip file embedded in a war file. Is there a way to suppress this or configure it to ignore the nested zip file so the scan completes and reports other issues it might have discovered?

It should still complete scanning. if the plugin is failing the build you can set the failOnError=false.

See https://jeremylong.github.io/DependencyCheck/dependency-check-gradle/configuration.html


Fix perfect_odometry rosbag

Proposed changes
Fixes #232.
This patch fixes message timestamps and starting time in the rosbag to match the header stamps recorded with sim time.

The contents of the messages were not altered.
The storage backend was changed to mcap.
The last messages where there was a collision against one of the walls were deleted.

Type of change

[x] 🐛 Bugfix (change which fixes an issue)
[ ] 🚀 Feature (change which adds functionality)
[ ] 📚 Documentation (change which fixes or extends documentation)

Checklist

[x] Lint and unit tests (if any) pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation (if appropriate)
[x] All commits have been signed for DCO

@glpuga Good catch! I originally tested on Rolling.
I reverted to using sqlite3 instead of mcap so no need to add extra dependencies.

I looked into the results of the beluga_benchmark that run on top of this. The data gathered looks good and can be plotted just fine for beluga_amcl, but nav2_amcl seems to be crashing right after starting.
This can be duplicated by running:
colcon build
source install/setup.bash
cd src/beluga/beluga_benchmark/docs/reports/2023-06-03
mkdir test
cd test
ros2 run beluga_benchmark parameterized_run 250 300 400<PHONE_NUMBER> 2000 5000 10000 20000 50000<PHONE_NUMBER>00 --params-file ../beam_params.yaml --package nav2_amcl --executable amcl
cd -

Nothing is left on the logs to indicate why nav2_amcl is giving up.

@glpuga I can reproduce the error in Humble, but everything works fine in Rolling. More investigation is needed.

@glpuga I think the failure is most likely related to what @ivanpauno found here: https://github.com/Ekumen-OS/beluga/pull/117#issuecomment-1442370024
I don't know how we ended up re-enabling recovery_alpha_fast and recovery_alpha_slow for benchmarks, and how that worked in the past, but we have two alternatives:

Benchmark using Rolling where the nav2_amcl bug was fixed.
Benchmark with adaptive recovery disabled.

Any of those options is unrelated to this PR.


C++ compilation doesn't pick up file changes when VFS retention is enabled

This is mostly about CppLanguageIncrementalCompileIntegrationTest on Windows.
See for example https://e.grdev.net/s/5xl6eviwy3s46/tests/failed.
I added some extra logging to those tests, so it shows that the project directory has been watched, though the changes in a subdirectory (e.g. src/main/headers) haven't been reported.
Other logs show Couldn't start watching errors, even though they report file changes later.

cc: @gradle/build-cache

See https://github.com/gradle/gradle/issues/12179 for the Couldn't start watching errors.

Duplicate of https://github.com/gradle/gradle/issues/12162.


Feature/od coverages

extending the range of propagated photons (the OD has wavelength-shifting plates, so we want to keep photons down to 200 nm even though the PMTs cannot directly see them)
storing photon wavelength information
allowing different Tyvek reflectivity values in different OD sections (top / bottom / barrel and inwall / outwall)
allowing different 3 inch PMT properties (Hamamatsu vs NNVT, as these are the two candidates we still have for HK)

Can I please please please request that you answer these comments from the website, rather than replying to email? It gets very mangled when not using the website. Another benefit of doing it on the website is that you'll be able to implement the suggestions I made with a click of a button (just remember to git pull from your branch afterwards!)

I guess it's a matter of taste. For me the website is more cumbersome, and also I do not want to change the code online, I want to change it in the terminal and then check that it works! Anyway, I'll reply here.

* WCTE needs fixing. It currently won't run at all

I added back the PMT option for WCTE. Is WCTE really using PMT3inchR14374 ? I find it strange because those are the ones we plan to use in the FD OD and I never knew it was going to be the same model (don't the WCTE use flat face 3 inch? the OD ones are hemispherical)

* There are changes for IWCD, even in the ID-only geometry. Is this expected?

No. What changes?

* There are changes for the FD, even in the ID-only geometry. Is this expected?

No. What changes?

Another comment is that the official FD geometry we use is HyperK_HybridmPMT_WithOD_Realistic. This is an improvement on the old HK FD geometries in that
* There are significantly fewer (I think zero) overlaps / gaps in the geometry

* The number of PMTs, and their positions, are laid out according to integration diagrams

  * mPMTs are laid out correctly, rather than in stripes
  * This is not perfect, as the number of PMTs can differ by a few. But it is signicant improvement on the previous way

Sorry, I did not know about this realistic geometry thing. But how do we know it works better? Has it been checked? I have never seen any report about this in the OD group.

I added back the PMT option for WCTE. Is WCTE really using PMT3inchR14374 ? I find it strange because those are the ones we plan to use in the FD OD and I never knew it was going to be the same model (don't the WCTE use flat face 3 inch? the OD ones are hemispherical)
PMT3inchR12199_02 is the default option for WCTE in older version. Now we have switched to PMT3inchR14374_WCTE, which is based on PMT3inchR14374 with updates in time and charge response. But IWCD OD is still using PMT3inchR14374

Actually the ID-only stuff has been fixed with your recent batch of commits. But, there are still differences in the IWCD+OD output, specifically the geometry: OD barrel PMT positions in IWCD+OD, only at a specific y value. I don't understand why this happens... @kmtsui any thoughts on this?

The old OD PMT placement code (line 1492 of src/WCSimConstructCylinder.cc) places the PMTs in top and bottom endcaps alternately, while the new one finishes top cap first then to bottom cap.

Sorry for the late reply, been a busy week.
I agree realistic isn't the greatest name. The idea behind this was to
provide one last geometry update to WCSim that had an up to date number of
mPMTs included as the default values in the old one had not been updated in
a while and had almost an order of magnitude higher number than the latest
estimates.
The code was designed to be as encapsulated as possible so that it could be
ported over to GHOST relatively easily when required, and could easily be
extended in the future to allow individual PMT placement tweaks. This is
the reason we first place arrays of dummy pmts before looping through at
the end and placing the actual PMT logical volumes.
The positions of the OD pmts are based on the pattern given by the
integration group that appeared to give roughly the correct total number of
planned OD pmts suggested at the time.
Since the idea was the geometry was being completely restructured to
prepare for ghost, we did simple tests at the time to verify that the
number of photons in each portion of the geometry looked sensible given the
reduction in photo coverage suggested by the integration group. It wasn't
really possible to cover all possible physics use cases for all groups at
the time so I've been waiting for feedback by users on whether there are
any problematic areas.
Purely coincidentally Liz Kneale noticed a bug just this week where the OD
pmt+plate objects were flipped in space due to the way the logical volumes
are setup for that PMT type, so clearly those initial tests didn't provide
full coverage of use cases. This has been fixed in the recent pull request.
With regards to Tom's suggestion, the OD group could use the old geometry
for studies, but the new "realistic"/"integration" geo uses the materials
and pmts directly from the other WCSim loaders. So it should be able to
automatically pick up new wavelength shifter definitions or place new PMT
geometries by simply replacing the PMT selection strings or upgrading these
to macro commands.
In addition if you need a way to vary the OD coverage, we could do this by
just modifying the nested replica "stampers" in the definition itself. So
you reduce the total coverage by a percentage in each pattern, and then
this new pattern gets duplicated around the entire barrel.
There is already an example doing this using a periodic throw (every 100th
PMT is thrown away for example) as we needed something like this to test
how the drop in number of photons made sense with reduced coverage, so all
you'd need is a more sophisticated way to decide which pmts to keep and
throw away.
Both of these options I'd be happy to add to the new geo if the OD group
could provide some feedback on specific requirements and validation tests
they need between the old and new geometry.
On Fri, 25 Oct 2024, 02:10 Tom Dealtry, @.***> wrote:

@.**** commented on this pull request.
In include/WCSimDetectorMessenger.hh
https://github.com/WCSim/WCSim/pull/468#discussion_r1815861020:

G4UIcmdWithADouble* PMTODPercentCoverageTop;

G4UIcmdWithADouble* PMTODPercentCoverageBottom;
G4UIcmdWithADouble* PMTODPercentCoverageBarrel;

Ahh sorry. I was under the impression that the PMT positions were
finalised now. Since it effects e.g. how detector construction shifts are
planned
I suppose what this means then is we need to keep two versions of the FD
geometry

HyperK_HybridmPMT_WithOD_Realistic which is used for most studies,
and official MC productions
HyperK_HybridmPMT_WithOD which is used only by the OD group for some
dedicated studies

Do note that there are typically geometry overlaps/gaps with this
geometry that can effect results

In both instances, the OD group should provide default options for their
parameters
Thinking about it, yeah I agree "realistic" is premature. It is a massive
improvement on the old geometry (recall Menai's mPMT plot fig 1 here
https://wiki.hyperk.org/pub/HyperK/TechNote0075/Tech_Note_HK_Data_Rate.pdf),
but with a long-term view it "based_on_Autumn_2023_integration_diagrams" is
more accurate.
Anyway... it's the last planned HKFD geometry in WCSim. So I think we
can live with this name
—
Reply to this email directly, view it on GitHub
https://github.com/WCSim/WCSim/pull/468#discussion_r1815861020, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AEEEHYKTSFXM7DJWQPUPGZDZ5GK7XAVCNFSM6AAAAABL4R3Y26VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGOJTHE2TQMRTGI
.
You are receiving this because you were mentioned.Message ID:
@.***>


Appstudio update test-component-pac-selz

Pipelines as Code configuration proposal

Pipelines as Code CI/test-component-pac-selz-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
35 seconds
init

✅ Succeeded
28 seconds
clone-repository

✅ Succeeded
3 minutes
build-container

✅ Succeeded
1 minute
sanity-inspect-image

✅ Succeeded
3 minutes
clair-scan

✅ Succeeded
1 minute
deprecated-base-image-check

✅ Succeeded
31 seconds
sbom-json-check

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
25 seconds
sanity-optional-label-check

✅ Succeeded
23 seconds
sanity-label-check

✅ Succeeded
11 seconds
show-summary

Pipelines as Code CI/test-component-pac-selz-on-pull-request has successfully validated your commit.


Call for maintainers

This repository is now unmaintained. If you are interested in assuming maintainership, please comment on this issue or email me directly.

Hey - I am interested, I am trying to port Plato (or something like it) to es6, so maybe I can help a little. https://www.npmjs.com/package/es6-plato

I Jared, I may be interested in undertaking this task 👍

Hi Jared,
Do this mean you're continuing to maintain this repo ? 😃

Indeed. Recently had the itch to hack on this again and have had the benefit of getting some space away for a while. Was hesitant at first to remove the "unmaintained" from the project title at first, but after landing the significant refactor to the syntax modules, the path forward is quite a bit clearer.

Nice one 👍
Do shout up if you need any assistance

Hi :) Is the repo still maintained? a dependency update would be nice


Downloading posters

When i try to download posters from my favorite movie list i cant seem to download some of them like,
Batman v superman dawn of justice and some others, i have tried to get all the poster links for the poster i cant download and all off the links seem to fail for some reason.
(Came a cross another bug: only applies for the wonder woman poster so far)
When i download the wonder woman poster i don't get the English poster but in some other language.

Are you successfully getting the image id's and giving them to the image url ... builder?

        var mov = client.GetMovieAsync(297762, "en").Result;

        var urlB = client.GetImageUrl(client.Config.Images.PosterSizes.Last(), mov.BackdropPath);
        var urlP = client.GetImageUrl(client.Config.Images.PosterSizes.Last(), mov.PosterPath);

I've tried the above, and I get these two respectively:

http://image.tmdb.org/t/p/original/6iUNJZymJBMXXriQyFZfLAKnjO6.jpg
http://image.tmdb.org/t/p/original/imekS7f1OuHyUP2LAiTEM0zBzUz.jpg

.. although it's hard to tell if they're english... I suppose the title is the same in a lot of places :)

Thanks hacker-man!
When i could not download some posters in the first place i tried to get all the poster links for each movie hoping it would find at least one downloadable image, but instead i got like 35 to 216 failed attempts (WebExceptions) to download one of the posters using .Net WebClient.
Thanks it works now 👍 (Great library)

Do you know where you went wrong?.. I'd be happy to update documentation etc. :)

This what i was using when i started using the library and to me i thought this should just work,
but i failed like i said above on some movies.
var request = client.AccountGetFavoriteMoviesAsync().Result.Result;

foreach(var movie in request)
{
var uri = client.GetImageUrl("w500",movie.PosterPath);
}

It's odd.. Given that w500 is in the list of accepted poster sizes (I assume it is), every poster should have that size present..
It could be an issue on TMDb's end.

I must say I have had strange issues with posters before. Leave this issue open I will check my own logs and see if I can reproduce your issue and narrow down the possible error. (won't be for a few days though)

Well after i implemented
var mov = client.GetMovieAsync(297762, "en").Result;

var urlB = client.GetImageUrl(client.Config.Images.BackdropSizes.Last(), mov.BackdropPath);
var urlP = client.GetImageUrl(client.Config.Images.PosterSizes.Last(), mov.PosterPath);

it has been working fine but now a few days later its back again, i think u where wright that it might be on the side of Themoviedb.org.
Here is a list of movies on which my application failed to download the poster's in case you want to try it out. #(These where just to test my Favorite Movies list on Themoviedb.org)#
Hellboy II: The Golden Army
Alien: Covenant
Avengers: Age of Ultron
Batman v Superman: Dawn of Justice
Kingsman: The Secret Service
Star Wars: The Force Awakens
Thor: The Dark World

I tried just now with Thor (76338):
Thor: The Dark World, Backdrop: w300: OK
Thor: The Dark World, Backdrop: w780: OK
Thor: The Dark World, Backdrop: w1280: OK
Thor: The Dark World, Backdrop: original: OK
Thor: The Dark World, Poster: w92: OK
Thor: The Dark World, Poster: w154: OK
Thor: The Dark World, Poster: w185: OK
Thor: The Dark World, Poster: w342: OK
Thor: The Dark World, Poster: w500: OK
Thor: The Dark World, Poster: w780: OK
Thor: The Dark World, Poster: original: OK

Avengers (99861)
Avengers: Age of Ultron, Backdrop: w300: OK
Avengers: Age of Ultron, Backdrop: w780: OK
Avengers: Age of Ultron, Backdrop: w1280: OK
Avengers: Age of Ultron, Backdrop: original: OK
Avengers: Age of Ultron, Poster: w92: OK
Avengers: Age of Ultron, Poster: w154: OK
Avengers: Age of Ultron, Poster: w185: OK
Avengers: Age of Ultron, Poster: w342: OK
Avengers: Age of Ultron, Poster: w500: OK
Avengers: Age of Ultron, Poster: w780: OK
Avengers: Age of Ultron, Poster: original: OK

I'm really not seeing what you are.
Code for reference.
        var mov = client.GetMovieAsync(99861, "en").Result;

        foreach (string size in client.Config.Images.BackdropSizes)
        {
            var url = client.GetImageUrl(size, mov.BackdropPath);
            var resp = new HttpClient().GetAsync(url).Result;

            Console.WriteLine($"{mov.Title}, Backdrop: {size}: {resp.StatusCode}");
        }

        foreach (string size in client.Config.Images.PosterSizes)
        {
            var url = client.GetImageUrl(size, mov.PosterPath);
            var resp = new HttpClient().GetAsync(url).Result;

            Console.WriteLine($"{mov.Title}, Poster: {size}: {resp.StatusCode}");
        }

I am using this and for some reason it got the error back, might be in my code because i tried the above code before trying to download the poster and i got the same result like you did but when i try to download an poster some of them fail, going to spend a lot of time to figure out why this is happening.
            using (var web = new WebClient())
            {
                try
                {
                    var movie = _tmDb.GetMovieAsync(item.Id, "en").Result;

                    foreach (var size in _tmDb.Config.Images.PosterSizes)
                    {
                        var uri = _tmDb.GetImageUrl(size, movie.PosterPath);

                        web.DownloadFile(uri, TempDataDirectory + movie.Title);

                        break;
                    }

                    return true;
                }
                catch (Exception e)
                {
                    if ( e is WebException )
                    {
                        Console.WriteLine(e.Message);
                    }
                    return false;
                }

just in case you need something to clean the names
    /// <summary>
    /// Removes all invalid characters from a path/file name string and returns the cleaned string value.
    /// All invalid characters are simply removed, no new characters are inserted
    /// </summary>
    /// <param name="path">string to rid of invalid characters</param>
    /// <returns>cleaned string</returns>
    public static string RemoveInvalidCharacters(string path)
    {
        return System.IO.Path.GetInvalidFileNameChars().Aggregate(path, (current, invalidCharacter) => current.Replace(invalidCharacter.ToString(CultureInfo.InvariantCulture), ""));
    }


Big increase in latency around the time the new server joins the cluster and starts serving queries

The following image is from a server getting killed, then restarting and rejoining the cluster a minute later.
The graph shows QPS

and here's latency:

Latency spikes to timeouts around the time the server dies and then once again once the server starts serving queries.

Hey @hristo-stripe , could you share a few more details?

Does this always happen, or was this a one off?
Which metrics are these exactly - server side (for the exact server in question) or broker side?
Could you attach some other metrics such as partial responses, timeouts for all the servers?
Any logs you can share from around the incident? Why was the server killed? Was there some ongoing issue on the server (OOM, expensive query/hot segment) that already caused resource constraints, resulting in the queries being served from a bad server before it was actually killed and took segments offline? Because afaik, as soon as the segment gets marked ERROR/OFFLINE, the query won't be routed to it.


[carry 13231 ] DOCS: Added support for arch s390x for Ubuntu, RHEL and SLES

carry of https://github.com/docker/docker.github.io/pull/13231; second commit contains the updates
closes https://github.com/docker/docker.github.io/pull/13231

whoops. wrong repo


ch01-01 minor edit

I am not sure if the error is intentional, but I made a correction to hello_world.cairo printing Hello, World! instead of Hello, Scarb!.

Maybe the 'Hello Scarb!'.print() is the mistake here. Hello, World appears all over the document instead of Hello, Scarb!


volumes2movie: replaced depreciated movie2avi with writeVideo

Here's a small change to a file in extrafunctions, mostly to try out as my first pull-request but also because the code was using a depreciated Matlab function and was crashing on us.

@jones-michael-s, Would not the code crash on earlier MATLABs? Which is the earliest version of MATLAB, which has videoWriter?

Hi Tibor (that was quick!). Mathworks says writeVideo was introduced in R2010b -- I don't know if you're supporting aa before that version. I could change the code to wrap movie2avi in a try-catch and push a new version?

I do not think we should go back that far! THank you for checking it.
I am merging.

Could you also observe my PR, too?

I read the pull request and don't have any comments at the moment -- is there any further action I should take?

You could merge it, then.
Vale,
Tibor
Auer, Tibor M.D. Ph.D.
Research Fellow in MRI
Department of Psychology
Royal Holloway University of London
Egham Hill
Egham
TW20 0EX
United Kingdom
<EMAIL_ADDRESS>+44-1784-27-6594
<EMAIL_ADDRESS>Tibor.Auer<EMAIL_ADDRESS>[royalhollowaylogo]https://www.royalholloway.ac.uk/psychology/home.aspx
From: Mike Jones<EMAIL_ADDRESS>Sent: 15 May 2017 15:45
To: rhodricusack/automaticanalysis<EMAIL_ADDRESS>Cc: Auer, Tibor<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Subject: Re: [rhodricusack/automaticanalysis] volumes2movie: replaced depreciated movie2avi with writeVideo (#108)
I read the pull request and don't have any comments at the moment -- is there any further action I should take?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/rhodricusack/automaticanalysis/pull/108#issuecomment-301497292, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEl8qZLYUgj6pIMMUs6mMjzpzzH-ggmgks5r6GT1gaJpZM4NbMPy.


Improve notice description #392

closes #392
Summary:
This PR provides support to improve notice descriptions
Expected behavior:
To be updated
Please make sure these boxes are checked before submitting your pull request - thanks!

[x] remove line separator in notice descriptions
[x] Run the unit tests with gradle test to make sure you didn't break anything
~[ ] Format the title like "Fix #<issue_number> - " (for example - "Fix #1111 - Check for null value before using field")~
[x] Linked all relevant issues
~[ ] Include screenshot(s) showing how this pull request works and fixes the issue(s)~

@maximearmstrong  note that notice memory consumption tests fail on CircleCI (for 1000 and 10000 notices) but they pass locally and in Github Actions.

I actually remember that we did not want these tests to be hardware dependant, but the experience shows different behavior in Circle CI and GitHub actions. I'll add this subject to the next technical meeting agenda: do you think tha we should run test with different thresholds depending on whether CI is GitHub Actions or Circle CI? @maximearmstrong  @fabrice-v

@lionel-nj I don't think we should run different tests (thresholds) depending on which CI runs the code. This being said, what makes tests fail on Circle CI? Is it the SAFETY_BUFFER_FACTOR that is not high enough or is it failing before assertion? If the problem comes from the safety threshold, I suggest increasing it. If not, we should investigate what fails. If we consider keeping both GitHub CI and Circle CI in the future, one option would be to disable that test on Circle CI as it could be linked to its memory consumption. CC @fabrice-v

@lionel-nj I don't think we should run different tests (thresholds) depending on which CI runs the code. This being said, what makes tests fail on Circle CI? Is it the SAFETY_BUFFER_FACTOR that is not high enough or is it failing before assertion? If the problem comes from the safety threshold, I suggest increasing it. If not, we should investigate what fails. If we consider keeping both GitHub CI and Circle CI in the future, one option would be to disable that test on Circle CI as it could be linked to its memory consumption. CC @fabrice-v

Actually these failures are totally random so I could not determine the source of the the failure. As you can see:

1 job that fails: https://app.circleci.com/pipelines/github/MobilityData/gtfs-validator/393/workflows/8ecd5f22-3a14-427f-8977-4c5e92959a66
successful re-run of the same job: https://app.circleci.com/pipelines/github/MobilityData/gtfs-validator/393/workflows/0c684c9b-cab2-43cc-b451-b3dc976ea801

It is also to note that even bumping the threshold did not stop this job from failing.

To answer your question, from what I witnessed the tests fail at the assertion steps, which leads me to think that the thresholds was not sufficient. However, the same tests pass locally and on GitHub and I doubt that we should continue to extend these thresholds, otherwise we would not be testing thoroughly


Blur Dom Loading

Blur Dom Loading  and percentage loading process using html CSS /assign

/assign

@Ayush7614  bro please assign me the issues its been so long now


Improve Quaternion Euler Precision

Summary
Changes Quaternions to use double precision under the hood when specifically working with Euler angles to improve precision/numerical stability.
Why?

Wobbly/broken editor rotation gizmo.
While working on implementing a gizmo system for my editor I spent quite some time struggling with why rotations would degenerate and eventually break. After double and triple checking my math, I finally noticed that round-tripping an Euler value can change as much as 0.1 degrees!
Floats vs Doubles
I know we typically prefer floats for performance reasons, but I'd argue that here correctness/precision would be preferred.
My Workaround

Nice and stable rotation gizmo.
I've worked around this by using a helper class to get/set euler angles instead of using the Quaternion instance methods. But being a good open source citizen I thought I'd contribute my findings.

@tommyettinger I really appreciate your feedback! The thing I'm currently trying to figure out is what is an acceptable epsilon of error for a series of rotations. Thoughts on that?

I'm going to guess that 0.0001 would be a good starting point -- Quaternion currently fails at that level of strictness (20x higher error), so even passing with one rotation would be an improvement. Passing with 3 rotations, one after the next, would show that the error isn't accumulating rapidly, and doing more would be nice to ensure that normal usage won't get noticeably bad.
The build check failed, so I'll look into this. It is likely to just be a formatting issue, and that can be resolved by running the spotlessApply task -- see the docs, it's a quick and simple step. https://libgdx.com/dev/contributing/#formatting

Thank you for the recommendations! 👍
I noticed the build was failing. It was a spaces vs tabs issue. I also noticed that spotlessApply adds an undesirable line break to the comments following setting the Quaternion component values
// cos(yaw/2) * sin(pitch/2) * cos(roll/2) + sin(yaw/2) * cos(pitch/2) * sin(roll/2)
Which I'd prefer to keep as they were useful in my understand of what was going on there.

I think there's a way to tell spotless to ignore a span of code; I think it is ```
// @off
codeThatYouWant = toNotBeFormatted(); // this should stay on one line
// @on
I've seen this in a few places in the code, but it isn't especially common, so I could be misinterpreting what it does.

The CI is failing I think as soon as it checks with Spotless, and we don't yet have a way to automatically run Spotless on PRs. I think once your tabs/spaces changes are committed and any complaints Spotless has about comments are silenced by `@off`, CI should run just fine.  I'll try to check back often to get the CI to run when you make your changes. You should also be able to run the tests from source using the info on the main site, https://libgdx.com/dev/from-source/ . You should only need to fetchNatives once, and then there's different tasks for different tests (I just run them from IDEA, whatever IDE you use should have an option to run various tests).

No sweat. Again thanks for your help, I'll ping you when I think it's ready for a run. 👍

I decided to look into just how much precision could be improved in MathUtils.atan2() -- it turns out, a lot. Testing against your original round-trip code, I can finally get that to pass the test with an epsilon of 0.0001, using an approximation of atan2() and no other changes. The approximation is pretty much exactly the same speed as the current MathUtils.atan2() (within a tenth of a nanosecond per call, and within the margin of error) on my laptop running Java 8 (HotSpot). That means it's about 4x faster than Math.atan2() (14.6 ns vs. 60.4 ns, so still very small times), at least on Java 8. I'm sure that the accumulating error matters more for quaternions, though, so we probably do still want Math.atan2() in Quaternion.
My code is based on another section from that 1955 RAND Corp study on digital approximations, this time sheet 11 (the fourth-fastest) instead of the one I've used before, sheet 9 (which was the second-fastest). I tried sheet 9 here and it did improve error, but not nearly enough -- the error was -5.00103 instead of MathUtils' -5.0020123. With sheet 11, I initially got the roll correct but then failed on the yaw, until I started doing my intermediate calculations with doubles. Thanks so much for recommending that, it was the last piece in the puzzle!
I don't think I'll add my code to this PR, because I still think sheet 11 isn't precise enough for multiple rotations, and Math.atan2() is the best way. I'll put a few versions forward in another PR, I think, and let other contributors gauge how much they need precision vs. speed. The speed difference is certainly smaller than the precision difference, though.

@tommyettinger I've added a test that performs a 4 degree yaw rotation 90 times and validates that we are back to 0 (within the epsilon of course). Does this seem reasonable a test?
I've also noticed that the current implementation is susceptible to Gimbal lock (which is why my gizmo goes crazy in the gif), which is why I'm avoiding setting the pitch. I have a fix for this, but that will be a separate PR.

I think that test sounds OK, but would it be the same complexity to do the test for each angle (once for roll, once for pitch, once for yaw)? Seems like each one of the axes has different code that could have issues, and we certainly want to check all of the axes. Ideally we could test a sequence of more-varied rotations that we know would result in a return to the initial state, but this is more work (unless there's some source that lists example rotations like that?). Using the "simple solution" of just replacing MathUtils.atan2() with (float)Math.atan2(), I tried running the test with the 4-degree yaw rotation 90 times, and that passed, but 4-degree pitch rotations did not. Roll was fine, though. It seems like pitch is substantially less accurate than the other angles. I don't know if the more significant changes in this PR will let the pitch rotation pass tests.
Gimbal lock comes with the territory for Euler angles, I don't know of a way to avoid it in this scenario. There's some famous anecdote about the Moon lander and how, because they still wanted to use Euler angles, it had a button to reset the rotation in case of gimbal lock. Quaternions can still get gimbal lock, I believe, but not commonly.

Removed the multiple rotation test in favor of keeping the tests simple and to the point.

Could increasing the Sin LUT size by a factor of 4 significantly help? Keep in power of 2 to make use of bit shift addressing. Is currently 16384 elements (2^14). As a comparison, the hilarious amount of decompiled Minecraft Java MathHelpers show 65536 elements (2^16). Basic memory allocation would be 65536 x 32 bits = 0.26 MB.
I see that exact results are set for 4 cardinal directions of Sin (and Cos by extension) and that's great but shouldn't we include 8 cardinal directions and 30°/60° exact results in the private class Sin static block?

Oh wow, this has been open for a year now. MathUtils.atan2() has better precision in the current code than it did when this PR was first entered, but I think we figured out that even casting Math.atan2() to float introduces enough error to cause problems. I really have no idea what a good solution is for quaternions, since they seem so incredibly sensitive to error building up...

If your code uses a value related to Trigonometry like Sin or Cos, then you should stay with Float if you can.  Java had that problem about 4 years ago.  The problem lingers due to a Pointer problem with C++.  If you have a Float, use a Pointer to convert to some compatible other number value, and convert back to Float, then you will see a loss in value accuracy.  It easy to find.
Very Bad Example:
Float value > Pointer integer > different Float value
Very Bad Result:  You will get a loss of accuracy.  If you can not test to the millionth digit or even infinity, then your test case is bad.  Go try BigData.  You will find your fix I think.

I've looked into this a little more since 2022, and my conclusion is that the getRoll(), getPitch(), and getYaw() methods become unusable if gimbal lock occurs, for any level of precision. A solution that works some of the time is just to modify those three angles separately from the Quaternion, and never modify the Quaternion except via setEulerAngles() . This is not suitable in the general case, but for some usage it could be helpful. Using axis-angle form would be an alternative that doesn't seem to struggle with gimbal lock.
I really looked around for any working implementations of getPitch(), getRoll(), and getYaw(). I didn't find any satisfactory ones, even in large game engines (though I didn't look at all of them). There's some webpages linked on Wikipedia's Euler Angles article(s) that give a very cursory glance through the methods, and if they do mention gimbal lock, it's generally given in a broken link. I'm not convinced that libGDX is currently implementing gimbal lock handling correctly for those three methods, because I'm not sure it can be implemented correctly.


Switch license to MIT-0

Closes #240.

This change is

Hello @yf225, @cjds, and @adeeb10abbas.  Thank you for your past contributions to the drake-external-examples project (#106, #181, and #244)!
To make it easier for Drake's users to take advantage of these examples, I'd like to re-license this repository from the BSD-3-Clause license to the MIT-0 license.  With the old license, users are required to preserve the examples' copyright notices in their own project, leading to a extra boilerplate and hassle.  With the new license, users would not be required to copy over those comments when bootstrapping their build system.
As past contributors to this repository, I'm seeking your approval of this license change.  Kindly please reply to this pull request, stating whether or not you approve of this change.  Your approval would effectively re-license your contribution under the new terms.

@jwnimmer-tri sounds good to me! Happy to help/contribute :)

Sounds good to me too, thanks!

I went back through the @cjds contribution and it was only https://github.com/RobotLocomotion/drake-external-examples/commit/95a34660d85c2a3c2788c4866da63badfb238eff.
I'll check whether or not any copyright there has bled into other files, and for now plan to switch everything except that contribution to MIT-0.

Yay, and GitHub already noticed!

@sherm1 sorry for the late reply. Haven't been monitoring GitHub off late. Happy to contribute as well if applicable

Thanks, Carl -- much appreciated. cc @jwnimmer-tri


INPUTS/OUTPUTS title updates 3

Docs Build status updates of commit cf6b94e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Get-HybridConfiguration.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-HybridMailflow.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-HybridMailflowDatacenterIPs.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IPAllowListConfig.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IPAllowListEntry.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IPAllowListProvider.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IPAllowListProvidersConfig.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IPBlockListConfig.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IPBlockListEntry.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IPBlockListProvider.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IPBlockListProvidersConfig.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IRMConfiguration.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-ImapSettings.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-InboundConnector.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-InboxRule.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IntraOrganizationConfiguration.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-IntraOrganizationConnector.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-JournalRule.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-LinkedUser.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-LogonStatistics.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-MailContact.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-MailDetailDlpPolicyReport.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-MailDetailTransportRuleReport.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-MailFilterListReport.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Get-MailPublicFolder.md
:white_check_mark:Succeeded
View (exchange-ps)

This comment lists only the first 25 files in the pull request.
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


CiscoSEG Parser Optimization Regarding IcM 355468251

Required items, please complete
Incident 355468251 : [CRI]<PHONE_NUMBER>008506 - Connector are not displaying and stuck in loading state
Change(s):

See guidance below

Reason for Change(s):

See guidance below

Version Updated:

Required only for Detections/Analytic Rule templates
See guidance below

Testing Completed:

See guidance below

Checked that the validations are passing and have addressed any issues that are present:

See guidance below

Guidance <- remove section before submitting

Before submitting this PR please ensure that you have read the following sections and filled out the changes, reason for change and testing complete sections:
Thank you for your contribution to the Microsoft Sentinel Github repo.

Details of the code changes in your submitted PR.  Providing descriptions for pull requests ensures there is context to changes being made and greatly enhances the code review process.  Providing associated Issues that this resolves also easily connects the reason.

Change(s):

Updated syntax for XYZ.yaml

Reason for Change(s):

New schema used for XYZ.yaml
Resolves ISSUE #1234

Version updated:

Yes
Detections/Analytic Rule templates are required to have the version updated

The code should have been tested in a Microsoft Sentinel environment that does not have any custom parsers, functions or tables, so that you validate no incorrect syntax and execution functions properly.  If your submission requires a custom parser or function, it must be submitted with the PR.

Testing Completed:

Yes/No/Need Help

Note: If updating a detection, you must update the version field.

Before the submission has been made, please look at running the KQL and Yaml Validation Checks locally.
https://github.com/Azure/Azure-Sentinel#run-kql-validation-locally

Checked that the validations are passing and have addressed any issues that are present:

Yes/No/Need Help

Note: Let us know if you have tried fixing the validation error and need help.

References:

Guidance for Detection checks
General contribution guidance
PR validation troubleshooting

Hi @v-rucdu, please provide your feedback. Thanks

Hello @v-rucdu please look into this

Hi @v-rucdu, could you please provide your feedback. Thanks

Hi @v-rucdu, could you please provide your feedback. Thanks

Hi @v-rucdu, please look into this. Thanks

Hi @v-rucdu, could you please provide your feedback. Thanks

Hi @v-rucdu, please look into this and provide your feedback. Thanks

Hello @v-rucdu, please provide your feedback on this. Thanks

Hi @v-rucdu, please look into this and provide your feedback. Thanks


Added satnav

I have added a definition for the satnav routing library that I hope you will accept.

@DotNetNerd Thanks mate!
via: http://bower.io/search/?q=satnav

My pleasure..


Error Encountered When Loading Meta-Llama-3-8B Model

Hello,
First, thank you for maintaining such an excellent repository! I have been using the code from Bergeron and appreciate all the hard work that has gone into it.
Issue:
I am attempting to perform inference using the meta-llama/Meta-Llama-3-8B model. However, when I try to load the model as the primary model, I encounter the following error:
>>> python evaluate.py respond "mundane" --primary 'meta-llama/Meta-Llama-3-8B' --secondary 'meta-llama/Meta-Llama-3-8B'

The token has not been saved to the git credentials helper. Pass `add_to_git_credential=True` in this function directly or `--add-to-git-credential` if using via `huggingface-cli` if you want to set the git credential as well.
Token is valid (permission: fineGrained).
Your token has been saved to ###
Login successful
[ INFO Bergeron @ 16:59:11 ] Begin respond at 2024-08-04 20:59:11.199571 UTC
[ INFO Bergeron @ 16:59:11 ] Primary model: meta-llama/Meta-Llama-3-8B
[ INFO Bergeron @ 16:59:11 ] Secondary model: meta-llama/Meta-Llama-3-8B
[ INFO UniversalModels @ 16:59:11 ] Setting random seed to 62
FutureWarning: `resume_download` is deprecated and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
  warnings.warn(
Loading checkpoint shards: 100%|██████████████████| 4/4 [00:04<00:00,  1.13s/it]
The tokenizer class you load from this checkpoint is not the same type as the class this function is called from. It may result in unexpected tokenization.
The tokenizer class you load from this checkpoint is 'PreTrainedTokenizerFast'.
The class this function is called from is 'LlamaTokenizer'.
You are using the default legacy behaviour of the <class 'transformers.models.llama.tokenization_llama.LlamaTokenizer'>. This is expected, and simply means that the `legacy` (previous) behavior will be used so nothing changes for you. If you want to use the new behaviour, set `legacy=False`. This should only be set if you understand what it means, and thoroughly read the reason why this was added as explained in https://github.com/huggingface/transformers/pull/24565
Traceback (most recent call last):
  File "/mnt/j/My Drive/Bergeron/evaluate.py", line 532, in <module>
    raise e
  File "/mnt/j/My Drive/Bergeron/evaluate.py", line 529, in <module>
    main()
  File "/mnt/j/My Drive/Bergeron/evaluate.py", line 501, in main
    main_model = load_main_model(args.primary, args.secondary, action, model_src)
  File "/mnt/j/My Drive/Bergeron/evaluate.py", line 399, in load_main_model
    return Bergeron.from_model_names(primary_model_name, secondary_model_name, primary_model_src=model_src, secondary_model_src=model_src)
  File "/mnt/j/My Drive/Bergeron/src/framework/bergeron.py", line 57, in from_model_names
    primary = Primary.from_model_name(primary_model_name, model_src=primary_model_src)
  File "/mnt/j/My Drive/Bergeron/src/framework/primary.py", line 28, in from_model_name
    return cls(p_model_info)
  File "/mnt/j/My Drive/Bergeron/src/framework/primary.py", line 15, in __init__
    self.model, self.tokenizer = pretrained_from_info(model_info)
  File "envs/hug/lib/python3.10/site-packages/universalmodels/interface.py", line 166, in pretrained_from_info
    return model, model_info.tokenizer_class.from_pretrained(model_info.pretrained_model_name_or_path)
  File "envs/hug/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2089, in from_pretrained
    return cls._from_pretrained(
  File "envs/hug/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2311, in _from_pretrained
    tokenizer = cls(*init_inputs, **init_kwargs)
  File "envs/hug/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 169, in __init__
    self.sp_model = self.get_spm_processor(kwargs.pop("from_slow", False))
  File "envs/hug/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 196, in get_spm_processor
    tokenizer.Load(self.vocab_file)
  File "envs/hug/lib/python3.10/site-packages/sentencepiece/__init__.py", line 961, in Load
    return self.LoadFromFile(model_file)
  File "envs/hug/lib/python3.10/site-packages/sentencepiece/__init__.py", line 316, in LoadFromFile
    return _sentencepiece.SentencePieceProcessor_LoadFromFile(self, arg)
TypeError: not a string

Steps to Reproduce:

Clone the Bergeron repository: git clone https://github.com/matthew-pisano/Bergeron.git
Navigate to the cloned directory: cd Bergeron
Install the required dependencies: pip install -r requirements.txt
Load the meta-llama/Meta-Llama-3-8B model for inference using the provided scripts:
python evaluate.py respond "mundane" --primary 'meta-llama/Meta-Llama-3-8B' --secondary 'meta-llama/Meta-Llama-3-8B'.

Minimal Step to Reproduce.
from dataclasses import dataclass
from transformers import LlamaTokenizer, LlamaForCausalLM

from universalmodels import ModelInfo, pretrained_from_info, model_info_from_name, ModelSrc

@dataclass
class model_info:
    pretrained_model_name_or_path = "meta-llama/Meta-Llama-3-8B"
    model_src = ModelSrc('auto')
    model_class = LlamaForCausalLM
    tokenizer_class = LlamaTokenizer
    model_task = "conversation"
    _fp_precision = 16

model_name = "meta-llama/Meta-Llama-3-8B"
model, tokenizer = pretrained_from_info(model_info(), )

Please let me know if there are any workarounds or additional steps I can take to resolve this issue. I'm looking forward to your guidance and help.
Thank you!

Update: Duck tape patch
In interface.py line 167, modify the code:
# return model, model_info.tokenizer_class.from_pretrained(model_info.pretrained_model_name_or_path)
model = AutoModelForCausalLM.from_pretrained(model_info.pretrained_model_name_or_path, torch_dtype = "auto").to('cuda')
tokenizer = AutoTokenizer.from_pretrained(model_info.pretrained_model_name_or_path, torch_dtype = "auto")
return model, tokenizer

But I guess it still loads the model 3 time

Update: Bug Fix
In interface.py line 118, modify the code:
tokenizer_class = LlamaTokenizer if target_model_name.startswith("meta-llama/Llama-2") else AutoTokenizer
model_class = LlamaForCausalLM if target_model_name.startswith("meta-llama/Llama-2") else AutoModelForCausalLM


E2E not working in demo

Cypress before fails CypressError: cy.visit() must be called with a string as its 1st argument.
Cypress.env('VUE_DEV_SERVER_URL') is undefined.
Perhaps you missed to commit your env files ?

Hi @HZooly,
We migrated vue-tour to Vue CLI 4 and migrated the landing page used for the e2e tests out of the master branch. In the process we no longer use the env variable VUE_DEV_SERVER_URL so this issue should be resolved.


chat transfer v2

when transferring the chat, one of the same is created.
chat transfer not complete

Hi @omar0928 can you provide more details? I'm not following what you're saying.


add and default to iOS 10.1, fixed a report generation issue and added more logging

Coverage remained the same at 23.457% when pulling 74a60b529da70063090e9450cfa9aa5e883f4786 on appersonlabs:master into f869fc0569e7494586b2ce0a543392939ef2e5e4 on eridem:master.

Coverage decreased (-0.05%) to 23.409% when pulling f97666003b96d4479c651d0fdc12267f165028b8 on appersonlabs:master into f869fc0569e7494586b2ce0a543392939ef2e5e4 on eridem:master.

Thanks

Matt, we cannot merge this one if the coverage decrease. Please check Coveralls for more info.

Coverage decreased (-0.05%) to 23.409% when pulling f97666003b96d4479c651d0fdc12267f165028b8 on appersonlabs:master into f869fc0569e7494586b2ce0a543392939ef2e5e4 on eridem:master.

@eridem where should I increase coverage? None of my changes are really testable

You are right. Closed.


change back to process.versions.node

Which problem is this PR solving?
Addresses https://github.com/open-telemetry/opentelemetry-js/pull/3698#discussion_r1184985236

Codecov Report

:exclamation: No coverage uploaded for pull request base (esm-support@6a052b1). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 1788089 differs from pull request most recent head 33fea4a. Consider uploading reports for the commit 33fea4a to get more accurate results

@@              Coverage Diff               @@
##             esm-support      #10   +/-   ##
==============================================
  Coverage               ?   92.79%
==============================================
  Files                  ?      273
  Lines                  ?     7962
  Branches               ?     1658
==============================================
  Hits                   ?     7388
  Misses                 ?      574
  Partials               ?        0


Bluetooth/BLE Support in CYW43

In the release for the Pico w, it was mentioned that WiFi is supported immediately and Bluetooth will be available soon after release.
It's now over 6 months since the release of the Pico w and there are no mentions of Bluetooth or BLE in this issue tracker or the CYW43 issue tracker.
It's Bluetooth going to happen on the Pico W, or is there some sort of hardware limitation preventing it from being possible?

It's being worked on internally, and is fairly close to release. I can't give an exact timeline, but I'd expect it to be fairly soon, certainly Q1.


Fix for group module selectors when bar is vertical

I noticed that #880 didn't seem to work when the bar was in vertical mode, and it looks like that was because the boxes were being re-assigned after adding the selectors, so I moved the selectors to just after the re-assignment, so now they should work in either mode :)

Thanks!