[move-function] Implement move checking for address only lets

This new pass works as follows:

Mandatory Inlining converts builtin "move" to a mark_unresolved_move_addr when inlining the function "_move" (the only place said builtin is invoked). mark_unresolved_move_addr is semantically a copy_addr [init] so we have valid IR.

This is then run through a special checker that
either proves that the mark_unresolved_move_addr can actually be a move in which
case it converts it to copy_addr [take][init] or if it can not be a move, emit
an error and convert the instruction to a copy_addr [init]. After this is done
for all instructions, we loop back through again and emit an error on any
mark_unresolved_move_addr that were not processed earlier allowing for us to
know that we have completeness.

NOTE: The move kills checker for addresses runs after Mandatory
Inlining, but before predictable memory opts and any other memory optimizations on purpose.

@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 5d6c72a258e313c6cde7cf340c925e50a90530f5

Build failed
Swift Test OS X Platform
Git Sha - 5d6c72a258e313c6cde7cf340c925e50a90530f5

@swift-ci test

@swift-ci test

This seems like the best place to put a review of this pass even though it's based on the latest iteration of the code.
Notes on the design description
The generally looks like a great approach from the high level description. It's should be as similar to the value-based algorithm as possible.
The same diagnostic algorithm should be used for moveonly variables and copyable variables that are explicitly moved. The name indicates otherwise. I expected simply a MoveValueCheck.cpp and MoveAddressCheck.cpp.
As discussed offline, the complete form of this diagnostic is equivalent to DefiniteInitialization. DI can insert mark_initialized markers to help you, but that's a pretty big FIXME to call out.
Please check that the design handles all the variations on indirect call arguments. I'm a little concerned that SILGen might emit temporary alloc_stack copies for some things.

semantically this instruction is actually a copy_addr [init]

Why is mark_unresolved_move_addr equivalent to copy_addr [init]? What does the [init] have to do with the move? Do you mean copy_addr [take]?

Then it partitions those uses into three sets:

It all be simpler to understand if you partition uses into two sets: live uses vs. destroys. Then say that some subset of those live uses are "moves".

NOTE: We do not need to check for
moves here since any move in our block would have either resulted in the
destroy_addr being eliminated earlier by the single block form of the
diagnostic and us exiting early or us emitting an error diagnostic and
exiting early.

This is hard to parse. Isn't it just this?
We don't check for moves because a move followed by a destroy
without an intervening init is invalid SIL, caught be the memory
verifier.

NOTE: The reason why we do not track init information on a per block is that
in our dataflow, we are treating inits as normal uses and if we see an init
without seeing a destroy_addr, we will error on the use and bail. Once we
decide to support vars, this will change.

I don't understand what "see an init without seeing a destroy_addr" means. But It seems unfortunate to have an algorithm for addressable variables that doesn't support reinitialization.

NOTE: The reason why we do not track all consuming operations

For moveonly variables, consuming operations will need to be handled just like moves. I'm not sure why the algorithm isn't just designed that way from the start. This whole discussion and design is centered on the mark_unresolved_move_addr opcode. The only thing that's special about that instruction is that it should be treated like a consume even though it's OperandOwnership isn't consuming (yet). I don't think the design should be centered around that operation.

If b is a block associated with one of our converted
mark_unresolved_move_addr, continue.

When you say "continue" here I think you mean "stop".
Notes on the implementation
There are several different data flow algorithms and dozens of data structures, without clear boundaries between them. Each aspect of the pass should be encapsulated into its own internal state distinct from its result that feeds into other aspects:

Gather function uses
Upward liveness data flow
Downward exposed consume data flow
Closure use summary (based on those 2 data flows)
Scanning for local use-after-move
Destroy placement data flow
Diagnostic handling

For each data flow, clearly separate:

Seeding data flow
Basic block summary (based on local scan)
Global data flow propagation
Data flow results

Most of the large functions in this pass are trying to do multiple unrelated things at once and have access to all different pieces of state. These are a ton of data structures across this code. They should all be encapsulated into objects that are each the output of one stage and the input of following stages.

struct GatherClosureUseVisitor : public AccessUseVisitor {

This is easy to understand. But UseState has a large number of data structures that are directly exposed to the entire pass.
Please clarify somehow that UseState is the output of GatherClosureUseVisitor. The only modification to that output is that uses are "cleared" later as they are processed. The UseState and GatherClosureUseVisitor are currently separated by 500 lines of code.
  SmallVector<MarkUnresolvedMoveAddrInst *, 1> markMoves;
  SmallPtrSet<SILInstruction *, 1> seenMarkMoves;
  SmallSetVector<SILInstruction *, 2> inits;
  SmallSetVector<SILInstruction *, 4> livenessUses;
  SmallBlotSetVector<DestroyAddrInst *, 4> destroys;
  llvm::SmallDenseMap<SILInstruction *, unsigned, 4> destroyToIndexMap;
  SmallBlotSetVector<SILInstruction *, 4> reinits;
  llvm::SmallDenseMap<SILInstruction *, unsigned, 4> reinitToIndexMap;
  llvm::SmallMapVector<Operand *, ClosureOperandState, 1> closureUses;
  llvm::SmallDenseMap<Operand *, unsigned, 1> closureOperandToIndexMap;

Should look like
  // definition of this...
  SmallVector<MarkUnresolvedMoveAddrInst *, 1> markMoves;

  // definition of this...
  SmallPtrSet<SILInstruction *, 1> seenMarkMoves;

  // definition of this...
  SmallSetVector<SILInstruction *, 2> inits;

  // definition of this...
  SmallSetVector<SILInstruction *, 4> livenessUses;

  // definition of this...
  SmallBlotSetVector<DestroyAddrInst *, 4> destroys;
  llvm::SmallDenseMap<SILInstruction *, unsigned, 4> destroyToIndexMap;

  // definition of this...
  SmallBlotSetVector<SILInstruction *, 4> reinits;
  llvm::SmallDenseMap<SILInstruction *, unsigned, 4> reinitToIndexMap;

  // definition of this...
  llvm::SmallMapVector<Operand *, ClosureOperandState, 1> closureUses;
  llvm::SmallDenseMap<Operand *, unsigned, 1> closureOperandToIndexMap;

Why do you have both SmallBlotSetVector/SmallMapVector and DenseMap for the same thing?
You can write nullptr into a vector instead of using Blot/MapVector. The null-ness can be hidden behind the API.
I don't know why you need bitsets. But, if you do map instructions to integers, why aren't you just using a single instruction map, a single vector for all uses, and 6 bitsets to represent the sets? Instead of 9 vectors, 9 hashmaps, and dynamically populated bitsets?
None of these data structure details should be exposed. You can add an API inside UseState like:
clearDestroy(Destroy *)
Bitset &getDestroyBits()

static DownwardScanResult
downwardScanForMoveOut(MarkUnresolvedMoveAddrInst *mvi, UseState &useState,
SILInstruction **foundInst, Operand **foundOperand,

APIs like this are hard to make sense of. An analysis function takes some input and produces a result. DownwardScanResult, foundInst, foundOperand, and foundClosureInsts can all be encapsulated in DownwardScanResult.

ClosureArgDataflowState

I could not figure out how the closure analysis fits with the rest of the pass. It seems like exactly the same analysis should run on the main function and on the closure, then two separate pieces of information need to be summarized for the closure:
(1) upward liveness
(2) downward exposed consumes

downwardScanForMoveOut()...
auto iter = useState.reinitToIndexMap.find(&next);
if (iter != useState.reinitToIndexMap.end()) {

Code like this makes the function hard to read. This function doesn't care how the data structure is implemented. It should just ask useState.isReinit(inst).

DataflowState::init() and upwardScanForXXX()...

It might be simpler and more efficient to have a single BasicBlockSet for all blocks with uses (from GatherUses). And have a single upwardScan function that runs for each block initializes the block's data flow summary.

performSingleBasicBlockAnalysis(...

performSingleBasicBlockAnalysis conceptually has nothing to do with global data flow propagation. DataflowState should not be passed to it.

dataflowState.markMovesThatPropagateDownwards.emplace_back(mvi);
// Now scan up to see if mvi is also a use to seed the dataflow. This could
// happen if we have an earlier move.
if (upwardScanForUseOut(mvi, dataflowState.useState)) {
LLVM_DEBUG(llvm::dbgs() << "MVI projects a use up");
dataflowState.useBlocks[mvi->getParent()] = mvi;
}

This upward scan here seems unrelated to the purpose of performSingleBasicBlockAnalysis. All the per-block data flow initialization should be encapsulated in a single place.
Generally, try to avoid conflating the move-as-use vs. the move-as-lifetime-end. Just handle move-as-use as part of the regular use set.

{
auto diag =
diag::sil_movekillscopyablevalue_value_consumed_more_than_once;
StringRef name = getDebugVarName(address);
diagnose(astCtx, getSourceLocFromValue(address), diag, name);
}

Can you centralize all the diagnostics in a single object? Then, instead of passing in address, just pass in the diagnostic handler? The interface can be:
/// True if \p move is exposed at the end of its block without first being destroyed.
bool checkUseAfterMoveInBlock(SILInstruction *move, ErrorHandler &handler) {...}

In DataflowState::process, I can't figure out why bitsets are suddently used here. What does it means to "pair" an instruction, and why we would care about "pairing".

bool DataflowState::cleanupAllDestroyAddr(...

I don't understand why cleanupAllDestroyAddr is a member of DataflowState. It takes 8 arguments. Most of them data structures defined locally then passed around. These should all be encapsulated in a separate data flow algorithm for destroy placement.
It would be really great if each data flow was a separate class that only contained data flow state and data flow logic and produced a data flow result. Nothing else whatsoever. Otherwise I think it's practically impossible to relate the code to the file-level comment that explains the design.


[HACKTOBERFEST 2024] - Semantic HTML Quiz

[!IMPORTANT]
This issue is part of our 2024 Hacktoberfest initiative. If you are interested in working on this issue, refer to our top-level tasks to see if this issue is claimed, or to claim it if it is not.

This issue is to create the Quiz Name quiz.
The file you should be working on is found in /curriculum/challenges/english/25-front-end-development/quiz-name.
All quiz questions need to relate to one of these topics:

Importance of semantic HTML
Importance of having good structural hierarchy
Difference between presentational and semantic HTML
emphasis element
Idiomatic Text element
strong element
Bring Attention To element
description lists
Inline Quotation element
Block Quotation element
Abbreviation element
Address element
<time>: The (Date) Time element
The Superscript element
The Subscript element
The code element
<u>: The Unarticulated Annotation (Underline) element
The ruby element
<s>: The Strikethrough element

[!CAUTION]
Questions which do not fall under these topics will be rejected.

You are welcome to include code blocks in your questions, but please keep them short (four lines or less).
Please do NOT open a pull request until you have completed all questions. Your quiz should have exactly 20 questions.

Thank you for your interest in contributing. This issue will be opened for contribution when Hacktoberfest starts on October 1st.

[!CAUTION]
Pull requests which are created before October 1st will not be eligible for Hacktoberfest. We appreciate enthusiasm, but encourage you to hold off on contributing to this issue until the event has begun.

If you wish to be notified when this issue is opened for contribution, subscribe to notifications:

This issue is now open
If you would like to work on this issue, please leave a comment so we can assign it to you.
Be sure to read our contributing guidelines.

i want to solve issues @naomi-lgbt pls assign me

can i clam this

@ReenaChidrala you are already assigned #56228 - Please leave this quiz for another contributor.

Can you assign to me ?

Can you assign to me this issue?

Hey @naomi-lgbt, I would like to work on this issue, and start my open source contribution with hacktoberfest.
Kindly assign this issue to me, as I have gone through docs too

I want to work on this issue. Could you assign this issue to me?

@naomi-lgbt Can you please assign this to me.

The issue has already please assigned, pelase stop asking


remove vacuum tool and vacuum tool references

Coverage decreased (-0.02%) to 74.366% when pulling e5aeee5f6a81fca013cf9b2bd8c2d9e50d19035b on remove-vacuum-tool into 5fdf7f6355777b4ac7e6195b7787041227394040 on master.


Rather than overload the 3rd argument of addEventListener could we overload the 2nd?

The 2nd argument to addEventListener is an EventListener callback interface.  We could possibly add additional attribute members to this interface.  Eg.
callback interface EventListener {
  void handleEvent(Event event);
  readonly attribute boolean mayCancel;
};

Event registration code would then look like:
element.addEventListener(type, {handleEvent: function(e) {
    ...
  }, mayCancel: false});

This would separate capture from mayCancel but it makes some sense since mayCancel is describing a property of the EventListener.  This would have the benefit of being backwards compatible (although we'd still want to encourage use of a polyfill to prevent accidentally depending on cancelable events).  This would also avoid the need to change any of the language around the capture variable and what constitutes a redundant (and so ignored) event handler registration.  However this seems like it might be an abuse of callback interfaces, is there precedent?

We couldn't do the above as it would be a breaking change due to the definition of single operation callback interfaces, plus we'd need some way to indicate the default value for myCancel.  Maybe:
callback interface EventListenerWithOptions extends EventListener {
  readonly attribute boolean mayCancel;
};
partial interface EventTarget {
  void addEventListener(DOMString type, EventListenerWithOptions callback, optional boolean capture = false);
  void removeEventListener(DOMString type, EventListenerWithOptions callback, optional boolean capture = false);
};

But this still doesn't scale nicely to support other optional options.  Perhaps we could use a dictionary  with a handleEvent callback function member?

Why not go further and make all parameters passed through a dictionary?
target.addEventListener({
    type: "scroll",
    handler: function (e) { ... },
    useCapture: false,
    mayCancel: true
});

This seems tantamount to a full API redesign though, and probably would deserve a new function name too..

Going to close this. Callbacks should be simple functions, the interface callback thing is mostly about compatibility.

SGTM, thanks

Give the ongoing debate here let's hash this out a little further.  Would it really be so bad to have this?
callback interface EventListener {
  void handleEvent(Event event);
  readonly attribute boolean cancel;
  readonly attribute boolean passive;
};

I know callback interfaces have fallen out of favor, but my reading of the WebIDL spec around this suggests that there's nothing really wrong with the above pattern.  Maybe it's a reasonable pragmatic trade off to resolve the dispute in #12 in a way everyone can live with?  We, of course, can still aim to replace addEventListener in the future to get rid of this legacy long-term.  But is there some reason why this design would be really bad?  It's certainly not too ugly from the web dev standpoint.  Eg:
element.addEventListener(type, {passive:true, handleEvent: function(e) {
    ...
  });

Seems nicer to me than:
var supportsPassive = false;
document.createElement("div").addEventListener("test", function(){}, { get passive() { supportsPassive = true }});
element.addEventListener(type, function(e) {
  ...
}, supportsPassive ? { passive: true } : false);

@annevk @domenic @smaug---- @tabatkins @paulirish @jacobrossi @esprehn @grorg @foolip @phistuck @dtapuska

+1
handleEvent will be part of the event listener paradigm until we replace aEL (note a similar behavior exists for handleChange in MediaQueryListener).  So it's seems sensible to me to resolve #12 this way until that time.

So {handleEvent: function(){}} would behave as now, but there could be possibly also passive and capture boolean properties in object passed in?
Or was readonly attribute boolean cancel; on purpose? (I think you mean capture)

So {handleEvent: function(){}} would behave as now, but there could be possibly also passive and capture boolean properties in object passed in?

Right

Or was readonly attribute boolean cancel; on purpose? (I think you mean capture)

Ooops, thanks - fixed.

And to be concrete, I'm also proposing we'd change the existing boolean capture arg to optional and specify that when it's specified it takes precedence over the capture property here.
Alternately I'd be OK omitting a duplicate capture entirely if people would prefer that (though I know Tab and Anne among others would like some path for improving the syntax for capture).

IMO the ergonomics of using the EventListener callback interface for these options is a huge win. It makes for far more predictable behavior for older browsers. And yeah, as the examples in Rick's comment above shows, the code is far more readable.

The current boolean capture (3rd param) is already optional.
I'd prefer to not add capture to this 2nd param approach. There isn't really any need for that, and it just adds compat risk, similar to the 3rd param approach.
Without capture in 2nd param, I'm ok with this approach. Spec'ing it shouldn't be too hard.
The passive property would be read as if the passed object was a dictionary (so read only once when the addEventListener is called), but otherwise 2nd param would work as it works now.

I don't see how this could work. IDL has very precise semantics for dictionaries and very precise semantics for callback interfaces (which are deprecated). I don't see how this works. Dismissing how this is bound as @paulirish did also seems misguided. That would be an actual backwards incompatible change.

To spell it out, the proposed IDL syntax above wouldn't work. Unless WebIDL is changed, the argument would have to be object and everything would have to be done with prose.

Is the one-argument case off the cards?
target.addEventListener({
    type: "scroll",
    handler: e => ...,
    capture: false,
    passive: true
});

As a web developer, if not this approach IMO overloading the 3rd parameter makes most sense. The 2nd param overload looks like a hack: you're starting to spread the event handler options across formal parameters and the options object.

@AshleyScirra yes, that's inconsistent with new Event().

I don't see how this could work. IDL has very precise semantics for dictionaries and very precise semantics for callback interfaces (which are deprecated).

Forget the garbage I proposed in #12 about the 2nd arg as a dictionary.  Here I'm talking only about extending the callback interface (so no change in this from today, etc.).

To spell it out, the proposed IDL syntax above wouldn't work. Unless WebIDL is changed, the argument would have to be object and everything would have to be done with prose.

I'm probably missing something, but reading the [WebIDL definition of callback interface] and associated ES binding, I only see one small problem.  We'd have to change is the definition of single operation callback interface so that my proposed extension to EventListener wouldn't be a breaking change.  Eg. perhaps it's fine to just ignore the attributes, or maybe an extended attribute is needed on the handleEvent operation to mark it as the "single operation".
Perhaps there's also a 2nd issue with correctly supporting the case where passive isn't provided, but from my reading of the spec I think we'd just get the value undefined and could handle that identically to false via prose in the DOM spec.
Is there something else I'm missing for why this wouldn't work by extending callback interfaces?  If there's not something obvious, then we can ask heycam for his input.

There's nothing there that actually gives you access to the values of arbitrary objects members, or mandates they are accessed in a specific order, as is important for dictionaries. There's only two callback interfaces in the platform or so, and neither needs this functionality.

It would be easy to say in prose that when an object is passed to addEventListener, (1) it is converted to some dictionary and .passive is read from it (defaulting to false)
(2) And then the object would be converted to EventListener.

There's nothing there that actually gives you access to the values of arbitrary objects members

Not "arbitrary" but specific attributes appear to be supported.  Eg. there's this describing how arbitrary objects (including their attributes) are bound to callback interfaces:

Any object that is not a native RegExp object is considered to implement the interface.
...
The value of a user object’s attribute is retrieved using the following algorithm:
...

And there's even this example (albeit with a "suggestion" that you prefer using a dictionary because there's no operations here):
callback interface Options {
  attribute DOMString? option1;
  attribute DOMString? option2;
  attribute long? option3;
};

@heycam is there anything wrong with having a callback interface like this?
callback interface EventListener {
  void handleEvent(Event event);
  readonly attribute boolean passive;
};

I know it's a little weird, but (if we could make it a non-breaking change by tweaking the "single-operation callback interface" definition) it would have forwards compat properties that some people REALLY like (#12).

I would do the conversion in 2 steps. There would be dictionary EventListenerOpts { boolean passive = false; } and the existing EventListener. Then change the callback to object? and in prose say that first callback is converted to EventListenerOpts, similar to https://html.spec.whatwg.org/multipage/scripting.html#coerce-context-arguments-for-2d and passive value is read from there. (if .passive getter throws here, we'd pass the exception to caller and abort the algorithm). Then object is converted to EventListener and that part would work as now.

I thought about this a bit and I have these concerns:

This approach is actually backwards incompatible. It's totally legit to pass in your own object as second argument. We are now reducing the number of members you can use there safely. That'll be a continuous hazard going forward as we add more. Worse, we might break actual content, which I think is far worse than the theoretical risk of some site not working until the user updates their browser.
This approach is inconsistent with virtually every other event listener on the platform in that this will not point to the target, ever. That seems like a huge pain when writing reusable code.
This approach makes us store an extra object per listener. That seems suboptimal.

I don't think it's worth pursuing this anymore.

This approach is actually backwards incompatible.

If we restrict this decision to just what to do about passive, this is something we could test concretely.  I suspect the risk of existing callback interfaces having a member named passive is pretty low, but we could find out for sure.
But the argument about it not being a good pattern to build on in the future (the way EventListenerOptions could be) is a good one.

This approach is inconsistent with virtually every other event listener on the platform in that this will not point to the target, ever. That seems like a huge pain when writing reusable code.

Good point.  So in practice people would probably want to write something ugly like this instead:
document.addEventListener(type, {passive: true,
  handleEvent: function(e) {
    (function(e) {
      ....
    }).call(e.currentTarget, e);
  }
});

And I'm sure developers would often forget about the difference in this and so would have subtle bugs by forgetting to accommodate it when upgrading existing code to add passive.

This approach makes us store an extra object per listener.

Good point.  It's common to have thousands of listeners in a frame, so the memory costs are potentially non-trivial.  If this were the only potential deal breaker here I could do some work to quantify it a little better.

I've being using the handleEvent syntax quite a bit for animations (to keep state in the listener this and ease of removal), never had a "passive" property in the 2nd argument, but it seems to me that adding an arbitrary field to the object is not much forward looking: when usage spread people will have all sort of custom properties names and adding new features will be harder than is this time. It should then be instead an "handleEventOptions" object property able containing all possible future options. Or you may overload "handleEvent" to accept an object containing the handler and all the options as properties.
That said with everybody using event delegation won't the optimization be impossible as the not passive form of the listener would anyway be registered somewhere up in the DOM? Wouldn't instead be possible to have the passive behaviour be a property of the listener's target element, set via js or css like "-touch-action" is? Or have a completely new set of events like "touchmovePassive" carrying the behaviour?
If you are to change addEventListener itself, than to me a new 4th boolen seems the least weired way to go, when not present it will just be unoptimized, feature detection on something basic as addEventListener looks as frustrating as detecting attachEvent...

Thanks @RByers for pointing out that I was wrong about the WebIDL spec, it does indeed say things about callback interface attributes. Still, the current set of callback interfaces that may end up as widely implemented parts of the web platform are EventListener, NodeFilter, RTCIdentityProvider and XPathNSResolver, and none of these have attributes, yet.
No doubt this could be made to work, but a few things come to mind as not great:

Anyone who currently uses plain functions would have to keep track of the extra object if they later need to call removeEventListener. Some will likely try to use a new object literal instead.
It wouldn't be a proper dictionary, so if we ever come up with an API for easier feature detection of dictionary members, it wouldn't work here.

When it comes to backwards compat, to be fair the current spec also has risk, in that any code that already passes an object as the 3rd argument will see a change in behavior, from capturing to non-capturing. That's why the risk was measured and EventListenerOptions shipped without passive in M49.

Oh god, why was RTCIdentityProvider introduced? Bah, we really should have named this legacy callback interface.

I was also a bid sad to find it in Gecko's source code. File an issue at https://github.com/w3c/webrtc-pc/issues to see if it's too late?

Filed https://github.com/w3c/webrtc-pc/issues/559.

So with @foolip's two additional points we now have five solid arguments against this approach. Time to close this issue?

Well, 3rd param approach has clear arguments against it too.
So we're still in state "should we change handling of 2nd or 3rd parameter or add 4th".

Well, no, we'd only need to consider 3 or 4 arguments, since 2 clearly doesn't work. I think we've made it sufficiently clear why 4 arguments is not a good idea either, but we can revisit that again I suppose, in a separate thread.

"clearly doesn't work"? I must be missing such argument. It is perhaps suboptimal approach, sure, but so are others too.
(Currently I'm back in favoring 4th param approach. I was hoping some agreement could be achieved with 2nd param approach and I was ok with that, but looks like I was too optimistic.)

Between the this binding issue, and extra difficulty of removal, the 4th arg option seems strictly superior in terms of developer ergonomics than this 2nd arg option .  So unless anyone has any other arguments (@jacobrossi?) I agree we should (again) close this and focus any further debate on just the 4th arg option in #12.

I'm ok with either approach. I prefer the 2nd arg approach as I think the mandated bool in the 3rd arg is more annoying to a dev than learning a different this (it works no differently than handleEvent already does and as @paulirish says, many are already rebinding this anyway) or removing the listener (you can either pass in the same object you gave aEL or just clear handleEvent). But I won't object to the 4th arg approach if there's a consensus that is better.

Based on all the discussion/concerns, it seems the 4th arg option generally better than any sort of 2nd arg option so I'm going to close this issue and continue the discussion #12.


feat: delegate keys should have application identifiers

What is the feature you would like to implement?
Allow applications to add an identifier to delegate keys
Why is this feature important?
Allows applications to parse messages in different ways and prioritize or deprioritize content from certain other applications.
Will the protocol spec need to be updated??
Signer secction will need to be updated
How should this feature be built? (optional)
TBD
Additional context
TBD

Proposed update to SignerAdd message
type SignerAddBody = {
  delegate: string;
  meta?: string; // 25 character limit
}

Does that address this ticket, or are we looking for something more?

some suggestions:

would prefer call it something specific like appId instead of meta, given that its purpose is specific
might be useful to introduce lightweight namespacing syntax which would allow a company to have multiple identifiable apps (e..g purpleapp.ios) (purpleapp.desktop). could be as simple as respecting periods as namespace delimiters and grouping from left to right.
is 25 chars the right size? based on our transport protocol does it make sense to have a rounded byte size?

I was imagining meta could be used for more than strictly an app ID, like how we're adding meta to casts to include arbitrary extra data. It could be:

string with a nickname the user assigns to the key when they create it
string with the name of the app it was created for
Stringified JSON with name and URL of app

No strong opinion about size. Maybe 16 bytes?

moving to 2.1.0 per our discussion

Given we now allow a name in the SignerAdd message, can this ticket be closed?
Or is this referring to a different desired feature?

it's a different feature, but let's close for now. this is the kind of change that should go through the new FIP process.


Add support for thread naming on windows platform

This implements thread naming for windows. So Thread::set_name() and OS::set_thread_name() should work on that platform now.
It is mostly a copy of thread_posix, except I didn't use a designated initializer for PlatformFunctions, since that causes a compilation error. I'm not sure why that even works in thread_posix, since designated initializers apparently are a C++20 feature.

@bruvzg Thanks, I have applied your suggestions. I missed that this is Win10 only.

For the record, your commit seems not to be linked to your GitHub account. See: Why are my commits linked to the wrong user? for more info.

Thanks! Congratulations on your first merged contribution! 🎉


fix: wrong pass through when getUserById()

Fix: https://github.com/casdoor/casdoor/issues/884
passed over should be id?

@imp2002 actually this is not a bug. Plz discuss with me before writing code to save the efforts :)


Refactor test factories to produce minimally viable record

The task is to update the factories so they make a minimally viable record.
E.g., the observation used in tests currently has comments, photos, identifications, a description etc. A minimum viable observation would have none of those though.
If tests need things like an observation with comments or photos, the test should construct them individually.

@jtklein do you have thoughts on which keys should remain in a minimum viable observation? The only key that's required in realm is a uuid, so a LocalObservation factory could be as simple as only having a uuid.
Or we could simplify LocalObservation so it only contains keys with primitive values, but not keys with additional factories (like comments, identifications, taxon, user).
Maybe it would help to have more context on why you think we should simplify factories & how it improves our test suite to construct more complex factories/mocks in individual tests.

This came up during changes to ObsDetails.test.js:
When testing the UI for an observation that has neither photos nor sound (= observation without evidence) I had to do the following:

const mockObservation = factory( "LocalObservation", {
  created_at: "2022-11-27T19:07:41-08:00",
  time_observed_at: "2023-12-14T21:07:41-09:30"
} );
const mockNoEvidenceObservation = factory( "LocalObservation", {
  created_at: "2022-11-27T19:07:41-08:00",
  time_observed_at: "2023-12-14T21:07:41-09:30"
} );
mockNoEvidenceObservation.observationPhotos = [];
mockNoEvidenceObservation.observationSounds = [];

A minimally viable observation would be the one with the least required fields that get's accepted by the API and created. In this specific case, e.g. empty sound and photos would be accepted. I don't know exactly how this minimally viable observation would look like from server specs, i.e. which fields are required and which optional.


[docs] Using consistent models in documentation

Is your feature request related to a problem? Please describe.
The documentation for how to model or create relationships appears to be incorrect or disjointed with previous context from the page.
Given this page: https://docs.permify.co/docs/getting-started/sync-data#more-relation-tuple-examples
In this page the model
entity user {}

entity organization {

    relation member @user

}

entity document {

    relation  owner  @user
    relation  org    @organization

    action view   = owner or org.member
    action edit   = owner
    action delete = owner
}

is used above the section of more relation-tuple-examples but the examples do not relate to that model or the provided model for that example isn't given making the reader scratching their head a bit on the connection.
For instance - further down the page there is the Organization Members are viewer of Repo which presents this API payload
{
    "entity": {
        "type": "repository",
        "id": "1"
    },
    "relation": "viewer",
    "subject": {
        "type": "organization",
        "id": "2",
        "relation": "member"
    }
}

With the caption of

Created relational tuple: repository:1#admin@organization:2#member
Definition: Members of organization 2 are viewers of repository 1.

However, without the model for this example I would say that the API call and the caption are incorrect because it says that the members of Organization 2 should be viewers of repository 1 but it clearly says admin in the caption while the payload says viewer.
Describe the solution you'd like
I think it would benefit the user if the documentation was based around simple and complex models for people to relate to the documentation. Either completely separate pages with the model presented first and a description of the use case or with each example you provide a tab UI component that provides the model, the data, and the api call (or nix the API call except in the API/SDK documentation) or potentially a link to the playground to test the scenario with the relevant data/model attached.
Describe alternatives you've considered
Ignoring the documentation but that isn't as fruitful as trying to seek change :D
Additional context
On a product perspective with IAM space - Documentation, examples, analogies, and content will be the engine to drive successful adoption in larger enterprises who may not be on the up and up of IAM controls. Having documentation, testimonies, and "real life" examples of the permission models with examples that go in depth will drive more people to this over OpenFGA from Auth0 or other solutions that pop up.

Hi @ioneyed, thank you for your feedback. I appreciate you pointing out the error in the tuple repository:1#admin@organization:2#member, it should be repository:1#viewer@organization:2#member.
Regarding the "More Relational Tuples" section, I want to clarify that it was not intended to be a continuation of the previous model, but rather to provide different examples of relational tuples to showcase their structure and potential use cases. However, upon further review and consideration of your feedback, we have decided to do it as you suggested. So we'll connect each relational tuple with its respective model to provide a better understanding of how they are used and make it easier to test them with adding api calls and link with playground.
We plan to implement this change later this week.
Specifications:

Updating the "More Relational Tuples" section with providing a tab UI component for each example model.
Each example Model (tab component) will consist; schema, the data, and the api call (or nix the API call except in the API/SDK documentation) and link with playground.
Fix the issue in the tuple: repository:1#admin@organization:2#member it should be repository:1#viewer@organization:2#member

Hi @ioneyed, I wanted to let you know that we have updated the page at https://docs.permify.co/docs/getting-started/sync-data. We have made changes to the example schema and have related the relational tuple examples with the schema. Additionally, we have added API calls to each tuple and provided a playground link for the entire example.
Moving forward, we are working on a separate page that will provide real-world and more depth examples. We plan to combine this page with the use cases page to provide a better view of what can be achieved with Permify.


Use system's theme as default

Is your feature request related to a problem? Please describe.
Having mine history/cookies erased every new session forces me to set dark theme back/login
Describe the solution you'd like
Odysee should detect using @media (prefers-color-scheme: dark/light) what theme is set on system, and set itself theme accordingly. If mentioned query is unsupported fallback to currently default light theme.
Describe alternatives you've considered
Besides externally stylizing website using some browser plugin, I don't think there is one.
Additional context
None

On login, you're theme should go back to what you had saved. But this is a good idea overall, thank you for the suggestion!


Plugin does not build

The plugin does not build for 4.26, I know that the plugin has only been tested for 5.2 and 5.1. I wanted to see if it is possible to make it work for 4.26.2

Yes it is, in fact a friend of mine is using it in just such a situation.
You will need to make some very minor changes to the code for it to compile however.
These changes are not because of UE framework differences, but rather because of the change in C++ versions supported by the newer UE.
If I recall correctly, there are 2 places code must be changed, and there are both IF statements where a variable is declared inside the if statement brackets.
Simply move the variable outside, before the IF statement and things should be able to compile for UE 4.26/27


$receiver - Add CompanyName?

Hello,
how i can add CompanyName and Street2 to the Receiver?
Thanks

Neither is possible. You will have to rely solely on the "Name2" field.
One thing you could do however, if you have to get the company name and street2 on the label:

put the company name on the "Name" field
put the recipients name on the "ContactPerson" field
put the additional street on the "Name2" field

I've already contacted DHL about this inconvenience, but they do not seem to care.

Hi thanks for your reply.
I don't find the Function for ContactPerson and Name2. I find it only for $sender not for $receiver?
// Mostly used in bigger Companies
$sender->setContactPerson((string) 'Peter Dragicevic');
Can i use this like this:
// Mostly used in bigger Companies
$receiver->setContactPerson((string) 'Peter Dragicevic');
?

Hello,
yes you can use it also on the Receiver-Class. Both classes have the same parent Class SendPerson (https://github.com/Petschko/dhl-php-sdk/blob/master/includes/SendPerson.php)


Fixes #1583 - Enforcing runtime checks for required php extensions

Fixes issue #1583
Changes proposed in this pull request:
Adding runtime checks for required php extension in order to have Cecil working correct

@all-contributors please add @benjaminhirsch for bug and code.


Add integration tests for BTF relocations

I've started to work on https://github.com/aya-rs/aya/issues/412
It's not ready for review yet, but I need some feedback before going on.
For now, I have a test for a moved field inside a struct and an enum change. The integration test works by trying to read a relocatable field from a raw array of bytes. The read data is then sent to userspace using a BPF_MAP_TYPE_ARRAY. The integration_test then asserts the output is consistent with the target BTF instead of the local definition.
Originally I was planning to send the relocatable data structure from userspace into eBPF using a global variable. I discarded that option because I felt it was making things more complicated and harder to understand than just reading the raw bytes.
I thought it would be best to have a test generator (RelocationTest). This is different from the pre-existing integration-test way of doing things: instead of adding a .bpf.c program for each relocation type, we compile the ebpf directly inside the test. The rationale is:

We'll have many tests like these, adding a new eBPF program (and btf definition) for each is verbose
I dislike having the final assert_eq! expectation in a different file from the one where everything is defined.

I think it would make the test cases easier to understand if we included a "run without BTF and make sure the results are different". This is why I added a RelocationTestRunner::run_no_btf(). Unfortunately all these tests are currently failing with a:
Option::unwrap()` on a `None` value', aya/src/obj/btf/relocation.rs:888:33

Let me know what you think.

I've started to work on #412 It's not ready for review yet, but I need some feedback before going on.

Sorry it took a while - holidays and all.
I just skimmed through this and it looks amazing!

Unfortunately all these tests are currently failing with a: Option::unwrap() on a `None` value', aya/src/obj/btf/relocation.rs:888:33

I'm happy to look into this

Marking it as ready for review!
I've never seen some of these tests passing, so take care: some might be wrong.
Many more relocation types are missing, but I think it's better to get these in and fix the issues which are causing them to fail before adding new ones. Hopefully adding new ones is trivial for those working on the actual relocation code.

Unfortunately all these tests are currently failing with a: Option::unwrap() on a `None` value', aya/src/obj/btf/relocation.rs:888:33

I'm happy to look into this

Update: I've debugged this, and it happens invoking run_no_btf(). The reason is that in that case we don't have the target BTF, we only have the local BTF). While some relocation kinds like TypeIdLocal don't require the target BTF, most relocation kinds do require it and should error out gracefully when it's missing. The fix is simple, I'll push it tomorrow.

Thanks for the review and the fixes! The tests are passing now.

Amazing work thank you! 😊


Unable to build mcuboot for b_u585i_iot02a

Describe the bug
Building mcuboot for ST's B-U585I-IOT02A fails.
To Reproduce
Steps to reproduce the behavior:
1.add to \bootloader\mcuboot\boot\zephyr\dts.overlay
&flash0 {
/*
* For more information, see:
* http://docs.zephyrproject.org/latest/guides/dts/index.html#flash-partitions
*/
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
            boot_partition: partition@0 {
                    label = "mcuboot";
                    reg = <0x00000000 0x10000>;
            };
            slot0_partition: partition@10000 {
                    label = "image-0";
                    reg = <0x00010000 0x20000>;
            };
            slot1_partition: partition@30000 {
                    label = "image-1";
                    reg = <0x00030000 0x50000>;
            };
            scratch_partition: partition@70000 {
                    label = "image-scratch";
                    reg = <0x00070000 0x10000>;
            };
    };

};

\zephyrproject\bootloader\mcuboot>west build -p auto -b b_u585i_iot02a boot\zephyr

Expected behavior
Build should be OK.
Impact
Not able to proceed
Logs and console output
-- west build: generating a build system
Including boilerplate (Zephyr base (cached)): C:/OWN/Work/ZEP/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/boot/zephyr
-- Zephyr version: 3.0.0-rc1 (C:/OWN/Work/ZEP/zephyrproject/zephyr), build: v3.0.0-rc1-247-gf86f6e002510
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: b_u585i_iot02a
-- Cache files will be written to: C:/OWN/Work/ZEP/zephyrproject/zephyr/.cache
-- Found toolchain: gnuarmemb (C:/gnu_arm_embedded)
-- Found BOARD.dts: C:/OWN/Work/ZEP/zephyrproject/zephyr/boards/arm/b_u585i_iot02a/b_u585i_iot02a.dts
-- Found devicetree overlay: C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/boot/zephyr/dts.overlay
-- Found devicetree overlay: C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/boot/zephyr/dts.overlay
-- Generated zephyr.dts: C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/build/zephyr/dts.cmake
warning: FLASH_MAP (defined at subsys/storage/flash_map/Kconfig:10) has direct dependencies FLASH_HAS_DRIVER_ENABLED with value n, but is currently being y-selected by the following symbols:

MCUBOOT_DEVICE_SETTINGS (defined at C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/boot/zephyr/Kconfig:656), with value y, direct dependencies y (value: y)Parsing C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/boot/zephyr/Kconfig
Loaded configuration 'C:/OWN/Work/ZEP/zephyrproject/zephyr/boards/arm/b_u585i_iot02a/b_u585i_iot02a_defconfig'
Merged configuration 'C:/OWN/Work/ZEP/zephyrproject/bootloader/mcuboot/boot/zephyr/prj.conf'

error: Aborting due to Kconfig warnings
CMake Error at C:/OWN/Work/ZEP/zephyrproject/zephyr/cmake/kconfig.cmake:272 (message):
command failed with return code: 1
Call Stack (most recent call first):
C:/OWN/Work/ZEP/zephyrproject/zephyr/cmake/app/boilerplate.cmake:544 (include)
C:/OWN/Work/ZEP/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
C:/OWN/Work/ZEP/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
CMakeLists.txt:44 (find_package)
-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' '-DWEST_PYTHON=C:\Python310\python.exe' '-BC:\OWN\Work\ZEP\zephyrproject\bootloader\mcuboot\build' '-SC:\OWN\Work\ZEP\zephyrproject\bootloader\mcuboot\boot\zephyr' -GNinja
Environment (please complete the following information):

OS: Windows 10
Toolchain: GNU Arm Embedded Toolchain Version 10.3-2021.10
commit f86f6e00251066815b0a7a7ad45047b525b3fab9 (HEAD -> main, origin/main, origin/HEAD)

@JiiZR Thanks for raising this. Point is that we still miss stm32u5 flash driver implementation which is required to build MCUBoot.

Ok, thanks for your information.

@JiiZR can you try with the support of flash for stm32u5 https://github.com/zephyrproject-rtos/zephyr/pull/42538
&flash0 is already in b_u585i_iot02a.dts, maybe it could be deleted in the ../bootloader/mcuboot/boot/zephyr/dts.overlay

Hi, here are results:
MCUboot can be compiled and if only primary partition is used then MCUboot jumps to the application blinky. But if swap is requested from second partition then panic is seen. Signing is done with imgtool 1.9.0 and command is:
west sign -t imgtool -- --slot-size 0x20000 --version 1.2.3 --header-size 0x400 --key C:\OWN\zep_u5\zephyrproject\bootloader\mcuboot\root-rsa-2048.pem --pad --confirm --align 8
I also tried align 16 but then magic is generated wrongly to the trailer.
Prints from crash:
*** Booting Zephyr OS build zephyr-v3.0.0-1287-g08f4492d385c  ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x1
I: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: primary slot
I: Swap type: test
D: erasing scratch area
D: initializing status; fa_id=3
D: writing swap_info; fa_id=3 off=0x3fd8 (0x63fd8), swap_type=0x2 image_num=0x0
D: writing swap_size; fa_id=3 off=0x3fd0 (0x63fd0)
D: writing magic; fa_id=3 off=0x3ff0 (0x63ff0)
D: erasing trailer; fa_id=1
D: initializing status; fa_id=1
D: writing swap_info; fa_id=1 off=0x1ffd8 (0x3ffd8), swap_type=0x2 image_num=0x0
D: writing swap_size; fa_id=1 off=0x1ffd0 (0x3ffd0)
D: writing magic; fa_id=1 off=0x1fff0 (0x3fff0)
D: erasing trailer; fa_id=2
D: erasing scratch area
D: writing copy_done; fa_id=1 off=0x1ffe0 (0x3ffe0)
E: panic!

I took a closer look for the mcuboot code and changed this:
\zephyrproj_u5\bootloader\mcuboot\boot\bootutil\include\bootutil\bootutil_public.h
// hack
#define MCUBOOT_BOOT_MAX_ALIGN 16
#ifdef MCUBOOT_BOOT_MAX_ALIGN
....
and then signed apps to slot0 and slot1:
west sign -t imgtool -- --slot-size 0x20000 --version 4.5.6 --header-size 0x400 --key C:\OWN\Work\ZEP\zephyrproj_u5\bootloader\mcuboot\root-rsa-2048.pem --pad --confirm --align 16
And now mcuboot works fine, app from slot1 is updated to slot0 and app boots, so ST drivers are OK.

Thanks @JiiZR for the heads up. I'm closing the ticket.


add option to not sync vm templates

Added an config parameter that allows to skip the sync of VM templates.
Also the skip_vm_comments boolean from the previous PR was quoted, which is fixed here.

very good idea, thank you.
Just wondering. Shouldn't templates be skipped by default? Why would you need to sync templates to NetBox?
Otherwise we could set these option to True by default.

very good idea, thank you.
Just wondering. Shouldn't templates be skipped by default? Why would you need to sync templates to NetBox?
Otherwise we could set these option to True by default.

I also wouldn't know why you want to sync templates into netbox... I wanted to add the setting without changing the default for others, but then again if an existing user still wants to sync them, they can change the default and continue.
I'll set the default to True.

I also wouldn't know why you want to sync templates into netbox... I wanted to add the setting without changing the default for others, but then again if an existing user still wants to sync them, they can change the default and continue.
I'll set the default to True.

done in c632154a3bc06f5212e04d7b8ffdcccafe37d69e

done in c632154a3bc06f5212e04d7b8ffdcccafe37d69e


common actions: remove verbose flag from CI: cargo build

it takes too long to scroll through the verbose output. Has the verbose output ever been useful for diagnosis? In the past 12 months the number of times I've wanted to look at verbose rust compiler output is zero.

fixed


Have FindFiles() take a glob

For symmetry with ListFiles().

Hey @bitfield ! Sorry for the delayed response. Before I start work on this, I wanted to clarify a thing.
Directory structure
root
├─── root_folder1
│    ├─── root_folder1_file1.txt
│    ├─── root_folder1_file2.txt
│    ├─── root_folder1_sub_folder1
│    │    ├── root_folder1_sub_folder1_file1.txt
│    │    └── root_folder1_sub_folder1_file2.txt
│    └─── root_folder1_sub_folder2
│         ├── root_folder1_sub_folder2_file1.txt
│         └── root_folder1_sub_folder2_file2.txt
└─── root_folder2

What is the expected output when I do a FindFiles("/root//root_folder1_sub")?
My understanding is that the glob should be resolved to the actual folder paths, in this case [/root/root_folder1/root_folder1_sub_folder1, /root/root_folder1/root_folder1_sub_folder2] and list all the files under these folders
Output:
/root/root_folder1/root_folder1_sub_folder1/root_folder1_sub_folder1_file1.txt
/root/root_folder1/root_folder1_sub_folder1/root_folder1_sub_folder1_file2.txt
/root/root_folder1/root_folder1_sub_folder2/root_folder1_sub_folder2_file1.txt
/root/root_folder1/root_folder1_sub_folder2/root_folder1_sub_folder2_file2.txt

so the files /root/root_folder1/root_folder1_file1.txt and /root/root_folder1/root_folder1_file2.txt are not printed.
Is my understanding correct?
(sorry for the long file names)

I'm not quite sure what you're asking.

@bitfield I wanted to understand the issue better. When you say that FindFiles() should be able to take a glob, that means,

It needs to take an input with wildcard chars like filepath = /folder1/folder*, and should list all the files recursively in this path.
It needs to take an input without wildcard chars as well like filepath = /folder1/folder2, and should list all the files recursively in this path.
Is this correct?

Correct! Basically, it should be the equivalent of ListFiles with a glob, followed by a FindFiles on all its results! (Maybe we could use this as a test.)

Sweet that clears things up, Thanks!

Hi @bitfield, sorry for the delay. I created a PR to fix this https://github.com/bitfield/script/pull/65. Let me know what you think.

Closed because we don't have a use case for this.

Why don't we have a use case for this? IMO, the most common use case at all is: Execute script on all files found with this filename pattern, and I was recently fighting my way through script to get this somehow worked around.
script.ForAllFiles("**/*.pdf").Exec(...).WriteToFile(<here-I-would-like-to-get-the-filename-of-the-PDF-feed-in)

What about filtering the files with MatchRegex?

A package like this makes sense if it saves my considerable time and brain capacity. Most likely, I could use MatchRegex. However, the use case I stated is so typical that I want to avoid thinking about how to twist it to make it work.
If the package shifts my brain time from thinking about how I would do it in Go to how I would do it using X there is not much gained. And I might be quicker, have fewer dependencies, etc., with plain Go.
Don't get me wrong, I like the approach, but it feels too similar to plain Go. Another example is the stderr issue. That's mostly a showstopper.
When chaining several commands, another omnipresent question is how can I get the output of A as input to B? Like a filename down to the WriteFile(string) call?


KVC can corrupt NSObjects isa & return garbage.

When getting struct (ccColor3B) value with valueForKey: via property's/method name (not via ivar name) - isa pointer can be changed (sic!).
It happens only on iOS device - not on Mac or Simulator.
Detected on iPhone 4 with iOS 4.3.2 & iPod Touch with iOS 4.3.1
Affected:

iPhone 4 with iOS 4.3.2
iPod Touch 4G with iOS 4.3.1
iPad 2 with iOS 4.3.5

Nonaffected:

iPad 2 with iOS 5.0.1

Update: this happens with struct like
{
GLubyte	r;
GLubyte	g;
GLubyte b;
}
but not with
{
GLubyte	r;
GLubyte	g;
GLubyte b;
GLubyte reserved1;
GLubyte reserved2;
}
Probably KVC can get struct with property/method properly only if it's size > 4 bytes.
Bigger, not bigger or equal!

Update: restoring isa can help avoid crashes after using valueForKey: BUT!
value that gets returned can be garbage.

Update: tested on iPad 2 with iOS 5.0.1 - works ok, bug doesn't exist. Updated first post.

Update: tested on iPad 2 with iOS 4.3.5 - affected.

Update: ccColor3B should be 4 bytes under 4.3 simulator to avoid KVC failure.


Custom compass background color

Allow the user to choose the background color of the compass for optimal readability.

I am currently working on this and got a first implementation. I used the Color Picker that was already in the app. It is insufficient I think, as it has mostly bright colors available, which conflicts with the rest of the compass design.
Also there is no way to go back to default with that.
Maybe let me know what you think of this. I pushed it to a branch on my fork, if you wanna take a deeper look.

Hi, thank you for taking a look at this issue.
A few things:

The colors in that picker were chosen to be visible on desaturated surfaces, and therefore should be limited to just the beacons/paths.
I planned on doing more research before this was ready to see what colors would work, unfortunately I don't have the time at this moment to create a list. But a good starting point would be to only allow the selection of desaturated colors such as dark grays/black or light grays/white. This issue was logged out of feedback that a user was having trouble seeing the compass in direct sunlight and wanted a more contrasting background for their screen (white background).
For the colors for this, I would extend AppColors to have a property for isForegroundColor, then update the Color Picker to filter based on it, so you can specify if you want to see foreground or background colors.
The color of the text and outlines on the compass itself should be easily visible (switching between black and white based on the most contrasting color - there's a custom method, something like Colors.mostContrastingColor for that)
As long as the current color is in the list of AppColors and the preference defaults to use that one, I wouldn't worry about the ability to revert to default - the user could always just pick it again
The setting should be on the Navigation > General settings rather than the compass settings and apply to both the RoundCompass and RadarCompass

Thanks for the feedback, I will look into it next weekend!


Support Jaeger tracing backends

At the moment knative only supports tracing to Zipkin backends. It would be good to have more options, e.g. supporting Jaeger tracing backends as well (natively, without the need of external converters etc.)
/area API
/kind feature
Expected Behavior
knative support Jaeger tracing backends.
Actual Behavior
knative only supports tracing to Zipkin backends.
Steps to Reproduce the Problem
n/a
Additional Info
This issue is a follow-up to these issues that have been closed due to inactivity:
https://github.com/knative/pkg/issues/1076
https://github.com/knative/pkg/issues/1077

I think I'd like to support jaeger by exporting Otel traces. Jaeger as of 1.35 can directly receive them.
We do need an OpenCensus => OTel exporter - which seems to have existed before but was removed
I prodded the issue here to see if it's unblocked & possible to add back a tracing bridge
https://github.com/open-telemetry/opentelemetry-go/issues/2808

Note: we want to eventually swap to OTel instead of OpenCensus https://github.com/knative/pkg/issues/855

Sure, sounds like the right move.

/lifecycle frozen


cacheDir in docker-compose.yaml causes cache only in docker container.

if I attach the volume ./cacheDir to /ext as written in docker-compose.yaml, the logs show that goproxy will cache them under the path /go. So I edit docker-compose.yaml, change the line from "./cacheDir:/ext" to "./cacheDir:/go", goproxy write the files to the folder ./cacheDir.

@rosbit Thanks for your report, can you pull a request for this?

seems fix by #103

Thanks


Custom Exceptions.

Make custom exceptions for better error logging.

Closed by #7, forgot to tag it


pithos: add gdk-pixbuf2.0 dependency, update maintainers

Description of changes
This updates pithos to use gdk-pixbuf2.0. Without this package, pithos crashes when trying to load album art (on x11 and wayland). This commit also sets myself as the maintainer. I reached out to the previous maintainer (obadz) over email and he says that he has not used pithos in around 5 years and that the package also crashes on his system. I am a big fan of the pithos project and would be interested in helping to maintain this package.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Does anyone know why the ofborg-eval failed? I am having trouble understanding the error message. Multiple other packages import python3Packages. Thanks in advance!

It's because pythonPackages was set to python3Packages in all-packages.nix: https://github.com/NixOS/nixpkgs/blob/4c5c82e9cdb35494ae243ffe42f156269904d457/pkgs/top-level/all-packages.nix#L32374
If you remove that line from all-packages.nix, ofborg-eval will succeed.

Hmmm, probably you also need to add yourself to maintainers/maintainer-list.nix file (as a separate commit maintainers: add zaporter, just push the commit in this PR) .
Why adding rubyPackages.gdk_pixbuf2 to a python application? Did you try just adding gdk-pixbuf (which is propagated by the former)?

Ahh, sorry! For some reason I missed that part of the documentation. Will do.
Also, I am using the ruby version because the normal one doesn't work. I have spent a fair bit of time digging into this and I've realized that pithos doesn't need rubyPackages.gdk_pixbuf, but its dependency, rubyPackages.gio2.
This led me to look into using the nixpkgs.glib package because that builds gio, however that doesn't work. At this point, I suspect it is because the ruby gio2 package exports the linkable libraries whereas the nixpkgs.glib package doesn't seem to export gio2.so. I will be looking into this more. Right now I am considering three options:

Update the nixpkgs.glib package to include an option to export the gio (and possibly other .so files) so that nixpkgs.pithos can just rely on that.
Create nixpkgs.gio after I rip apart the ruby module and convert it to a nix package
Just keep the ruby import

Unless anyone else has any advice, I will probably look into moving forward with option 2.
Thank everyone for you help! I really appreciate it.


Feat/improve log

Depends on #319. Closes #308.

When I start the node, I expect all CARTESI_ variables to be printed so I can see what was used.
Maybe we should treat all the same and redact what is sensitive data.
Also, why these 2 first lines are different from the following?
node-1  | time=2024-02-15T10:43:08.825Z level=INFO msg="read environment variable" env=CARTESI_LOG_LEVEL value=info
node-1  | time=2024-02-15T10:43:08.825Z level=INFO msg="read environment variable" env=CARTESI_LOG_PRETTY value=true
node-1  | Feb 15 10:43:08.825 INF starting Cartesi Rollups Node version=devel
node-1  | Feb 15 10:43:08.825 INF read environment variable env=CARTESI_HTTP_PORT value=10000
node-1  | Feb 15 10:43:08.825 INF read environment variable env=CARTESI_BLOCKCHAIN_ID value=31337
node-1  | Feb 15 10:43:08.825 INF read environment variable env=CARTESI_CONTRACTS_APPLICATION_ADDRESS value=0x180763470853cAF642Df79a908F9282c61692A45
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_CONTRACTS_INPUT_BOX_DEPLOYMENT_BLOCK_NUMBER value=17
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_BLOCKCHAIN_FINALITY_OFFSET value=1
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_BLOCKCHAIN_WS_ENDPOINT value=ws://devnet:8545
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_BLOCKCHAIN_HTTP_ENDPOINT value=http://devnet:8545
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_FEATURE_HOST_MODE value=false
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_FEATURE_DISABLE_CLAIMER value=false
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_BLOCKCHAIN_IS_LEGACY value=false
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_CONTRACTS_HISTORY_ADDRESS value=0xbCc4067dfdeE8274E531951f0968EC895f397A44
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_CONTRACTS_AUTHORITY_ADDRESS value=0xb090149a3cA43000681B74875500854B54355496
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_CONTRACTS_INPUT_BOX_ADDRESS value=0xCf7Ed3AccA5a467e9e704C703E8D87F634fB0Fc9
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_SNAPSHOT_DIR value=/usr/share/cartesi/snapshot
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_CONTRACTS_APPLICATION_DEPLOYMENT_BLOCK_NUMBER value=17
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_EPOCH_DURATION value=120
node-1  | Feb 15 10:43:08.826 INF read environment variable env=CARTESI_HTTP_ADDRESS value=<IP_ADDRESS>

Also the logs should not print senstitve data like CARTESI_AUTH_AWS_KMS_KEY_ID. (I've changed the key id and put a fake key ID in the logs)
INFO authority-claimer:  INFO log: Starting Authority Claimer (version=1.3.0, git ref=N/A, git hash=N/A) with config Config { authority_claimer_config: AuthorityClaimerConfig { tx_manager_config: TxManagerConfig { default_confirmations: 1, provider_http_endpoint: "https://eth-sepolia.g.alchemy.com/v2/nuDbqy5ApW0s9E9igbuHROSivczxsEAk", chain_id: 11155111, chain_is_legacy: false, database_path: "./default_tx_database", gas_oracle_api_key: "" }, tx_signing_config: Aws { key_id: "2478723487384-752b-4787-bddf-lksdlksldklskd", region: UsEast1 }, tx_manager_priority: Normal, broker_config: BrokerConfig { redis_endpoint: Single(redis://<IP_ADDRESS>:10011), consume_timeout: 5000, backoff: ExponentialBackoff { current_interval: 500ms, initial_interval: 500ms, randomization_factor: 0.5, multiplier: 1.5, max_interval: 60s, start_time: Instant { tv_sec: 100069, tv_nsec: 289874501 }, max_elapsed_time: Some(120s), clock: SystemClock } }, log_config: LogConfig { enable_timestamp: false, enable_color: false }, contracts_config: ContractsConfig { history_address: 76f4dcac0920826541ee718214eee4be07346cee, authority_address: 5827ec9365d3a9b27bf1db982d258ad234d37242 }, genesis_block: 3963384 }, http_server_config: HttpServerConfig { port: 10002 } }

It prints the key_id :
2478723487384-752b-4787-bddf-lksdlksldklskd

Also the logs should not print senstitve data like CARTESI_AUTH_AWS_KMS_KEY_ID. (I've changed the key id and put a fake key ID in the logs)
INFO authority-claimer:  INFO log: Starting Authority Claimer (version=1.3.0, git ref=N/A, git hash=N/A) with config Config { authority_claimer_config: AuthorityClaimerConfig { tx_manager_config: TxManagerConfig { default_confirmations: 1, provider_http_endpoint: "https://eth-sepolia.g.alchemy.com/v2/nuDbqy5ApW0s9E9igbuHROSivczxsEAk", chain_id: 11155111, chain_is_legacy: false, database_path: "./default_tx_database", gas_oracle_api_key: "" }, tx_signing_config: Aws { key_id: "2478723487384-752b-4787-bddf-lksdlksldklskd", region: UsEast1 }, tx_manager_priority: Normal, broker_config: BrokerConfig { redis_endpoint: Single(redis://<IP_ADDRESS>:10011), consume_timeout: 5000, backoff: ExponentialBackoff { current_interval: 500ms, initial_interval: 500ms, randomization_factor: 0.5, multiplier: 1.5, max_interval: 60s, start_time: Instant { tv_sec: 100069, tv_nsec: 289874501 }, max_elapsed_time: Some(120s), clock: SystemClock } }, log_config: LogConfig { enable_timestamp: false, enable_color: false }, contracts_config: ContractsConfig { history_address: 76f4dcac0920826541ee718214eee4be07346cee, authority_address: 5827ec9365d3a9b27bf1db982d258ad234d37242 }, genesis_block: 3963384 }, http_server_config: HttpServerConfig { port: 10002 } }

It prints the key_id :
2478723487384-752b-4787-bddf-lksdlksldklskd

I'm not sure how sensitive the kms key id is here, but I know it's essential for debugging and auditing.

I'm not sure how sensitive the kms key id is here, but I know it's essential for debugging and auditing.

CARTESI_AUTH_AWS_KMS_KEY_ID and CARTESI_AUTH_AWS_KMS_REGION should be redacted according to the Cargo.toml file so, in principle, @oap75 was right. But now you got me questioning it: should we redact it or not?

Also, why these 2 first lines are different from the following?

This and #319 will be rebased on top of #318 after it is merged, so they'll be gone 😉

When I start the node, I expect all CARTESI_ variables to be printed so I can see what was used.

They're currently looking like this (in a local branch):
Feb 15 10:05:52.167 INF Starting Cartesi Rollups Node config.CARTESI_BLOCKCHAIN_BLOCK_TIMEOUT=60 config.CARTESI_BLOCKCHAIN_FINALITY_OFFSET=1 config.CARTESI_BLOCKCHAIN_HTTP_ENDPOINT=http://localhost:8545 config.CARTESI_BLOCKCHAIN_ID=31337 config.CARTESI_BLOCKCHAIN_IS_LEGACY=false config.CARTESI_BLOCKCHAIN_WS_ENDPOINT=ws://localhost:8545 config.CARTESI_CONTRACTS_INPUT_BOX_DEPLOYMENT_BLOCK_NUMBER=17 config.CARTESI_CONTRACTS_APPLICATION_ADDRESS=0x180763470853cAF642Df79a908F9282c61692A45 config.CARTESI_CONTRACTS_APPLICATION_DEPLOYMENT_BLOCK_NUMBER=17 config.CARTESI_CONTRACTS_AUTHORITY_ADDRESS=0xb090149a3cA43000681B74875500854B54355496 config.CARTESI_CONTRACTS_HISTORY_ADDRESS=0xbCc4067dfdeE8274E531951f0968EC895f397A44 config.CARTESI_CONTRACTS_INPUT_BOX_ADDRESS=0xCf7Ed3AccA5a467e9e704C703E8D87F634fB0Fc9 config.CARTESI_EXPERIMENTAL_SUNODO_VALIDATOR_ENABLED=false config.CARTESI_EXPERIMENTAL_SUNODO_VALIDATOR_REDIS_ENDPOINT="" config.CARTESI_FEATURE_DISABLE_CLAIMER=false config.CARTESI_FEATURE_DISABLE_MACHINE_HASH_CHECK=false config.CARTESI_FEATURE_HOST_MODE=false config.CARTESI_HTTP_ADDRESS=<IP_ADDRESS> config.CARTESI_HTTP_PORT=10000 config.CARTESI_LOG_LEVEL=1 config.CARTESI_LOG_PRETTY=true config.CARTESI_EPOCH_DURATION=2m0s config.CARTESI_SNAPSHOT_DIR=/Users/yves/workspace/cartesi/rollups-node/machine-snapshot config.CartesiAuth.Mnemonic=[REDACTED] config.CartesiAuth.AccountIndex=[REDACTED]

@endersonmaia The only change I'm still planning is to change CARTESI_LOG_LEVEL to a string, so it's clearer what it means. Let me know what you think.

When I start the node, I expect all CARTESI_ variables to be printed so I can see what was used.

They're currently looking like this (in a local branch):
Feb 15 10:05:52.167 INF Starting Cartesi Rollups Node config.CARTESI_BLOCKCHAIN_BLOCK_TIMEOUT=60 config.CARTESI_BLOCKCHAIN_FINALITY_OFFSET=1 config.CARTESI_BLOCKCHAIN_HTTP_ENDPOINT=http://localhost:8545 config.CARTESI_BLOCKCHAIN_ID=31337 config.CARTESI_BLOCKCHAIN_IS_LEGACY=false config.CARTESI_BLOCKCHAIN_WS_ENDPOINT=ws://localhost:8545 config.CARTESI_CONTRACTS_INPUT_BOX_DEPLOYMENT_BLOCK_NUMBER=17 config.CARTESI_CONTRACTS_APPLICATION_ADDRESS=0x180763470853cAF642Df79a908F9282c61692A45 config.CARTESI_CONTRACTS_APPLICATION_DEPLOYMENT_BLOCK_NUMBER=17 config.CARTESI_CONTRACTS_AUTHORITY_ADDRESS=0xb090149a3cA43000681B74875500854B54355496 config.CARTESI_CONTRACTS_HISTORY_ADDRESS=0xbCc4067dfdeE8274E531951f0968EC895f397A44 config.CARTESI_CONTRACTS_INPUT_BOX_ADDRESS=0xCf7Ed3AccA5a467e9e704C703E8D87F634fB0Fc9 config.CARTESI_EXPERIMENTAL_SUNODO_VALIDATOR_ENABLED=false config.CARTESI_EXPERIMENTAL_SUNODO_VALIDATOR_REDIS_ENDPOINT="" config.CARTESI_FEATURE_DISABLE_CLAIMER=false config.CARTESI_FEATURE_DISABLE_MACHINE_HASH_CHECK=false config.CARTESI_FEATURE_HOST_MODE=false config.CARTESI_HTTP_ADDRESS=<IP_ADDRESS> config.CARTESI_HTTP_PORT=10000 config.CARTESI_LOG_LEVEL=1 config.CARTESI_LOG_PRETTY=true config.CARTESI_EPOCH_DURATION=2m0s config.CARTESI_SNAPSHOT_DIR=/Users/yves/workspace/cartesi/rollups-node/machine-snapshot config.CartesiAuth.Mnemonic=[REDACTED] config.CartesiAuth.AccountIndex=[REDACTED]

@endersonmaia The only change I'm still planning is to change CARTESI_LOG_LEVEL to a string, so it's clearer what it means. Let me know what you think.

Ok, keep in mind that now, the log is like this:
And since we don't have log level prefix anywhere, it was hard to find the error (I usually filter for err or ERR, for ex.).
CONFIG 2024/02/15 14:37:33 read CARTESI_CONTRACTS_APPLICATION_ADDRESS environment variable: 0x9f12D4365806FC000D6555ACB85c5371b464E506
missing auth environment variables
CONFIG 2024/02/15 14:37:33 read CARTESI_CONTRACTS_INPUT_BOX_DEPLOYMENT_BLOCK_NUMBER environment variable: 3963384

If I got you idea right, you'll put all the config log in a single line, right?
I'd just ask that, if any error is found in any configuration, that we get a single line for it.
And, if we can parse all the config before, and show all the errors, it would be even better. So that I don't get into the loop of fixing one error, and getting another "new" one after the next time I start the rollups-node.
Tell me if you need me to create issues instead of just commenting here.

I'd just ask that, if any error is found in any configuration, that we get a single line for it.

@endersonmaia Got it.

And, if we can parse all the config before, and show all the errors, it would be even better. So that I don't get into the loop of fixing one error, and getting another "new" one after the next time I start the rollups-node.

Yeah, this would be better. We were already discussing how to approach config validation, so your input is valuable.

Tell me if you need me to create issues instead of just commenting here.

The context is the same, so there's no need for new issues. I'll include these modifications here as soon as possible. Thanks for the feedback 😉

I just noticed the datetime lack of pattern:

Feb 15 10:05:52.167
time=2024-02-15T10:43:08.825Z
CONFIG 2024/02/16 01:26:06  (I think this is the current/old 1.3.0 version, and not the don't in this PR)

I suggest stick to ISO 8061 (2024-02-15T10:43:08.825Z this one is great).

I just noticed the datetime lack of pattern:

Feb 15 10:05:52.167
time=2024-02-15T10:43:08.825Z
CONFIG 2024/02/16 01:26:06  (I think this is the current/old 1.3.0 version, and not the don't in this PR)

I suggest stick to ISO 8061 (2024-02-15T10:43:08.825Z this one is great).

Would RFC3339 2006-01-02T15:04:05Z07:00 suffice?

I just noticed the datetime lack of pattern:

Feb 15 10:05:52.167
time=2024-02-15T10:43:08.825Z
CONFIG 2024/02/16 01:26:06  (I think this is the current/old 1.3.0 version, and not the don't in this PR)

I suggest stick to ISO 8061 (2024-02-15T10:43:08.825Z this one is great).

@endersonmaia Would RFC3339 2006-01-02T15:04:05Z07:00 suffice?

Can we remove the timezone and get subseconds? If yes, I'm ok with it.

@endersonmaia we do get milliseconds, but to remove the timezone I would have to write a custom log handler to match the format between the default and pretty log styles (yep, it sucks). That's something that I very much would like to avoid.

I just noticed the datetime lack of pattern:

Feb 15 10:05:52.167
time=2024-02-15T10:43:08.825Z
CONFIG 2024/02/16 01:26:06  (I think this is the current/old 1.3.0 version, and not the don't in this PR)

I suggest stick to ISO 8061 (2024-02-15T10:43:08.825Z this one is great).

@endersonmaia Would RFC3339 2006-01-02T15:04:05Z07:00 suffice?

Can we remove the timezone and get subseconds? If yes, I'm ok with it.

@endersonmaia we do get milliseconds, but to remove the timezone I would have to write a custom log handler to match the format between the default and pretty log styles (yep, it sucks). That's something that I very much would like to avoid.

Maybe it gets this configuration from the OS timezone configuration? If we understand how this works, we can control its behavior.

I just noticed the datetime lack of pattern:

Feb 15 10:05:52.167
time=2024-02-15T10:43:08.825Z
CONFIG 2024/02/16 01:26:06  (I think this is the current/old 1.3.0 version, and not the don't in this PR)

I suggest stick to ISO 8061 (2024-02-15T10:43:08.825Z this one is great).

@endersonmaia Would RFC3339 2006-01-02T15:04:05Z07:00 suffice?

Can we remove the timezone and get subseconds? If yes, I'm ok with it.

@endersonmaia we do get milliseconds, but to remove the timezone I would have to write a custom log handler to match the format between the default and pretty log styles (yep, it sucks). That's something that I very much would like to avoid.

Maybe it gets this configuration from the OS timezone configuration? If we understand how this works, we can control its behavior.

Got a better solution: not using the default logger. I'll have full control over the time format and the only difference is that now CARTESI_LOG_PRETTY only adds color.

Due to the change in scope in #318, #319 has become the new base for this PR.

The code in PR #319 was moved to PR #354, which is now merged. So the main branch is the new base.


Fix TO API tests

There are a couple syntax errors that were introduced in #3452 that are
currently breaking the TO API tests.

What does this PR (Pull Request) do?

[x] This PR fixes #REPLACE_ME OR is not related to any Issue

Which Traffic Control components are affected by this PR?

Traffic Ops

Fixes syntax errors, no documentation needed.
What is the best way to verify this PR?

Run the TO API tests, verify that they pass.
If this is a bug fix, what versions of Traffic Ops are affected?

master (5a471403a42e5380ac91934f72e65c72b26e409b)

The following criteria are ALL met by this PR

[x] This PR includes tests OR I have explained why tests are unnecessary
[x] This PR includes documentation OR I have explained why documentation is unnecessary
[x] This PR includes an update to CHANGELOG.md OR such an update is not necessary
[x] This PR includes any and all required license headers
[x] This PR ensures that database migration sequence is correct OR this PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/3525/
Test PASSed.


potential fix for #80

ref https://github.com/mbraceproject/FsPickler/issues/80
I'm not sure if you even want to enable that scenario, since it may introduce non-determinism, but I think it would make sense ..

@eiriktsarpalis Closing out old issues and PRs to keep the repo in good shape - what do you think of this one?

For context, I am currently running this as a fork in production, otherwise it is impossible (or at least I didn't find another way) to correctly serialize akka.net objects.
The pr was mostly meant as a starting point for a discussion.

@eiriktsarpalis Can we accept this? I approve it but my understanding of the code is not that good

@dsyme Please see my comments in #80

Fixed in FsPickler 4.0

Thanks!
I don't want to be too annoying, but nuget release when? ;-)

Just released
On Sun, 17 Sep 2017 at 01:23 Lukas Rieger<EMAIL_ADDRESS>wrote:

Thanks!
I don't want to be too annoying, but nuget release when? ;-)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mbraceproject/FsPickler/pull/81#issuecomment-330003424,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACrts2-4_MTrR6sKFU1ABJvqU_F0RnBtks5sjGaGgaJpZM4MMepu
.


[Impeller] Brandon's screenshots are showing discretionary ligatures in Wonderous

@bdero 's screenshots in https://github.com/flutter/flutter/issues/128624#issuecomment-1585245234 are showing discretionary ligatures.  It's my understanding that they should not be rendering.  I'm unable to reproduce the problem locally either by running the wonderous app or creating a simple app that turns the ligatures on and off.
It's still uncertain if this is an issue or if @bdero has a local change that is causing the discrepancy.  @bdero can you please give more background to why those are showing up in your screenshots?

gskinner's marketing material as well as their Skia+Impeller bug screenshots show the discretionary ligatures.
Impeller doesn't make decisions about text frame construction. In Flutter, the text shaper (SkParagraph) produces text frames which are then dispatched to Impeller or Skia.
I'm not familiar with the inner workings of SkParagraph, but @jason-simmons might have color to add here.

@bdero what version of wonderous are you running?  I'm running c2be9688db680199edc0d49b1d536ad8bf176987.  It could be they changed the code at some point.

I tried running Wonderous (commit a387ca18db42ff2d593efe918e88b42cf372cec9) with the latest Flutter engine.  I was unable to reproduce this with Impeller on iOS or Android.
If there is a combination of app and engine where these ligatures render with Impeller but not Skia, then I can look into it.

Okay, i just found they they did remove the ligatures in 4fe946e587de4bc9405f392d909f8e9d73408eb6.  That's the explanation.  Thanks, I just wanted to make sure we didn't miss some problem when those screenshots showed up.


tweak cuda/rocm targets

Closes #7955.
@yashk2810  I tweaked the rocm line as well, please review!

python3 build/build.py --enable_cuda
works here:

INFO: Elapsed time: 941.252s, Critical Path: 157.16s
INFO: 11954 processes: 4726 internal, 7228 local.
INFO: Build completed successfully, 11954 total actions
INFO: Running command line: bazel-bin/build/build_wheel '--output_path=/home/skoonce/jax/jax/dist' '--cpu=x86_64'
INFO: Build completed successfully, 11954 total actions
package init file 'jaxlib/xla_extension/__init__.py' not found (or not a regular file)
Output wheel: /home/skoonce/jax/jax/dist/jaxlib-0.1.72-cp38-none-manylinux2010_x86_64.whl

To install the newly-built jaxlib wheel, run:
  pip install /home/skoonce/jax/jax/dist/jaxlib-0.1.72-cp38-none-manylinux2010_x86_64.whl

real    15m57.729s
user    0m14.981s
sys     0m1.706s

Thank you!


how can we override traceId in sleuth version greater than 2.0.0 ?

There is one blog https://blog.michaelstrasser.com/2017/07/using-sleuth-trace-id/#inserting-the-sleuth-trace-id. This explains how to customize traceid before brave library is being implemented. I'm trying to customize traceId in latest spring sleuth(<2.0.0). Please help

Requirement: Instead of randomly generated traceId and SpanId, we need to inject our custom traceId(which will be combination of different available Ids)

The ID needs to be a 64bit or 128 bit number. You can't override it. However, you can use the propagation keys (https://cloud.spring.io/spring-cloud-static/Finchley.SR1/single/spring-cloud.html#prefixed-fields) to propagate the id that in your company is the trace id, and you can modify the MDC to have that value injected.

in super advanced case you can write a FinishedSpanHandler to map normal
ids to custom format to a custom library which isnt normal hex.
however you cant get brave to generate span ids that are different size
than 64bit.
On Wed, 10 Oct 2018, 19:29 Marcin Grzejszczak<EMAIL_ADDRESS>wrote:

The ID needs to be a 64bit or 128 bit number. You can't override it.
However, you can use the propagation keys (
https://cloud.spring.io/spring-cloud-static/Finchley.SR1/single/spring-cloud.html#prefixed-fields)
to propagate the id that in your company is the trace id, and you can
modify the MDC to have that value injected.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/spring-cloud/spring-cloud-sleuth/issues/1106#issuecomment-428537262,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD614P1Ml7FtK6Rfiemnx3cASzMCez1ks5ujdoogaJpZM4XVHkZ
.

thanks

So is there no way to override traceId?
My requirement is that the traceId comes from other service and it is passed agnostic by a kafka message header. I can retrieve this header from the message but I can't override the traceId. I am using @KafkaListener to receive the kafka message and it seems that it can't smoothly decode (parse) the X-B3-TraceId and the X-B3-SpanId as it gives me some errors as soon as the service consumes the message.
I am aware of this issue but it seems that it's not working as expected for me.
I have been looking through documentation and internet code examples but none could provide me any help.
Could somebody tell me what should I do to accomplish it?

Hello, I am trying to override Trace ID. Here is my usecase:
i would like to use my X-Request-ID generated at Nginx Ingress controller on my Kubernetes cluster as X-B3-Trace-ID so that i can trace since request entered Cluster rather than from tomcat using same ID on my ELK Stack instead of multiple IDs for different layers.

@marcingrzejszczak I actually do have a use case where adding a new header doesn't help:
In our project, we have a few different cluster environments, all completely independent of each other. However, people within the project usually tell you the trace id when they encounter a problem, but not the cluster environment it was generated from. So usually my first follow-up question to them is "Which environment?". Otherwise I can't search for logs and investigate the issue. This could be solved if we generated trace ids a little bit less random, for example in one environment, each trace id starts with 0, and the other environment, each trace id starts with 1, and so on. This way I could tell where trace id came from without asking. To make it even worse, sometimes people tell you the wrong environment, because they're confused.
You may ask now why do we have so many environments, but well, that's another story and this can't be changed, but maybe trace ids can. If you agree that this is a valid use case for "influencing" the trace id generation, and if I can support you in implementing something, let me know.

@neiser the approach you discuss is very edge case. I would recommend putting a filter in front of your service if you must do this. use b3 single format and decide however you want, as long as the encoding is valid. ex b3: traceid-spanid where both can be same if 64-bit (16 character) https://github.com/openzipkin/b3-propagation/#single-header
ex one environment leads with all zeros
"b3", "0000000000000000e457b5a2e4d86bd1-e457b5a2e4d86bd1"
ex another environment leads with 1 then all zeros
"b3", "1000000000000000e457b5a2e4d86bd1-e457b5a2e4d86bd1"
this is not me recommending this approach, just for whatever reason you can't use normal propagated "env", "0" extra field, this is better than changing the project to do something weird.

actually all leading zeros would be a bad idea as that would be undifferentiated from a 64bit trace ID.. fixed my comment

Think use case is totally justified, we have loadbalancer which generates traceid, should be able to tell zipkins what to use for trace id? ATM we only have a running POC with zipkins and we have our own libs with filters which capture traceIds and put them into MDC. Sounds like we will have some trouble with this.

It is certainly best to change your LB if possible, to forward a valid B3 header. As it seems you can't..
You can take a look at this and copy/paste the solution into whatever version of Sleuth you want as the code needed is compatible with a long time back. https://github.com/openzipkin/brave/pull/1144
In sleuth 2.2, you would do..
@Bean ExtraFieldPropagation.Factory customPropagationFactory() {
  return ExtraFieldPropagation.newFactory(
      CustomTraceIdPropagation.create(B3Propagation.FACTORY, "my_trace_id"));
}

In Sleuth 3.0, this
@Bean BaggagePropagation.Factory customPropagationFactory() {
  return BaggagePropagation.newFactory(
      CustomTraceIdPropagation.create(B3Propagation.FACTORY, "my_trace_id"));
}

The ID needs to be a 64bit or 128 bit number. You can't override it. However, you can use the propagation keys (https://cloud.spring.io/spring-cloud-static/Finchley.SR1/single/spring-cloud.html#prefixed-fields) to propagate the id that in your company is the trace id, and you can modify the MDC to have that value injected.

Can to tell how to use propagation key??give some examples


How do I rollback Azure Boards to a point in time?

Regarding this section:

Mistakes happen
To protect against accidental deletion of data, either by our customers or by our operation team, we also take point-in-time backups of both the Azure blob and the SQL databases.

How do customers initiate a point in time recovery?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 52eb9f91-b952-afb6-6d17-d7092f46440d
Version Independent ID: bb9113a5-8b8b-b20b-9c6f-09a57f53ba7c
Content: Azure DevOps - Data Protection - Azure DevOps
Content Source: docs/organizations/security/data-protection.md
Product: devops
Technology: devops-security
GitHub Login: @mlearned
Microsoft Alias: mlearned

@successhawk Thank you for the question.
For Azure blob, please refer to Point-in-time restore.
For Azure SQL database, please refer to Azure SQL database recovery.
Otherwise, for additional help, please refer to one of the following support channels:

Azure DevOps community
Azure DevOps support
Azure DevOps on Stack Overflow


Fixes issue #18: timex 3.7 changes meaning of GMT and Etc/GMT

Azure is expecting the x-ms-date header to have the trailing timezone code as GMT.
timex 3.7 requires the timezone code Etc/GMT if we want to keep the polarity of the offset the same.
To fix this, have changed the timezone to be Etc/GMT and String.replace it to GMT.
Also, added a test for the above.

Also, @jakobht Happy to be a maintainer on this project.

Hi. Silly me… the tests failed because of different function signatures in DateTime introduced in Elixir 1.11.
I've updated the versions in .travis.yml and mix.exs but not sure if it needs to be updated anywhere for the Github CI actions to complete. Are you even using Travis? Or is it Github CI/Actions?

@jakobht thank you for the project and David, thank you for the PR
What is the oldest elixir version that you want to support?

In the meantime I have created a PR to the PR: https://github.com/workplacearcade/azurex/pull/1 : Removes timex
@jakobht  Whats your opinion?

Have removed need for timex (thanks @tofran !)
Reverted minimum version of elixir needed to 1.9 for better compatibility
Updated the SharedKeyTest to use 1.9 compatible DateTime fixture


Creating a client using the async await method does not catch error

Here is my test code:
  CDP(async(client) => {
    console.log('SECTION 1');
    throw new Error('test');
  }).on('error', (e) => {
    console.log('SECTION 2');
  };

Output is:
SECTION 1
(node:12320) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: test
(node:12320) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Environment:
OS: Windows 10

$ uname -a
MINGW32_NT-6.2 PHONG-PC 1.0.12(0.46/3/2) 2012-07-05 14:56 i686 unknown

$ node -v
v7.9.0

$ npm ls chrome-remote-interface
f:\www\tmp
`--<EMAIL_ADDRESS>

That's an interesting point, I could catch such exceptions but I don't think it's idiomatic for the observer pattern used by Node.js events. I think that's because it's limited to synchronous code (which is almost never the case), I mean if you replace your listener with:
(client) => {
    process.nextTick(() => {
        console.log('SECTION 1');
        throw new Error('test');
    });
}

There's no way for the library to catch that error.
The proper way is to completely switch to the Promises API:
CDP().then((client) => {
    console.log('SECTION 1');
    throw new Error('test');
}).catch((err) => {
    console.log('SECTION 2');
});

Or, systematically catch errors within your listeners.

@cyrus-and: hm good points. Was hoping to be able to use all async/await lines. Probably possible to do like this?
CDP().then(async(client) => {
    console.log('SECTION 1');
    try {
      await somePromiseCall();
    } catch (e) {
      throw new Error('test');
    }
}).catch((err) => {
    console.log('SECTION 2');
});

Yes, sure that should work. Also FYI you can push this even further and go completely async/await:
async function foo() {
    try {
        const client = CDP();
        console.log('SECTION 1');
        await somePromiseCall();
        any.other.error.is.catched.as.well();
    } catch (err) {
        console.log('SECTION 2');
    }
}

foo();

And you can of course net the try/catch block for finer error handling.


Windows 10 multiple errors

Hi,
I am using Windows 10, 64 bit, with CSR8510 A10 (4.0) dongle.
I have a use case where I write around 12 packets (20 bytes each) on a "WriteWithoutResponse" characteristic back to back. I get myriads of errors like LIBUSB_TRANSFER_STALL followed by a disconnection with LIBUSB_ERROR_NO_DEVICE followed by LIBUSB_TRANSFER_IO.
Things work fine if I add a delay of around 10 milliseconds between the writes.
It also works if I send 10 packets instead of 12 without adding any delay.
Is this a limitation of the CSR dongle or one of the layers above it viz - libusb, node-usb, bluetooth-hci-socket, noble?
Is it possible to tune any parameters to get this working without adding any delays?
Is it a bug in any of these layers?
Side note: same code works on MAC (with built in BLE, no dongle) without any problems.
Regards
Amruta

Is it possible to try it with the dongle on the mac?


Obsidian integration does not work on Windows

Looks like really great extension, but integration with Obsidian doesn't work for me.
The extension downloads page/tab ok, puts it under Download's correct subfolder but it never appears in Obsidian Vault.
I tried relative and full paths in Obsidian integration section with no luck.
Extension v3.2.1, browsers Firefox and MS Edge, os Windows 11.
Is there a way to look at extension's log or console?

+1
Does anyone can show working extension configuration?

Not working for me either

Same here

Same for me, using Brave, using the obsidian Advanced URI from the same browser opens the page fine. I assume I am doing something dim in the configuration, but I can't see what.

I'm using a Symbolic Link to get my clips into my Vault see #213

same with that

Aside from #213 ....
The symbolic link topic was previously well answered ...
https://forum.obsidian.md/t/markdownload-markdown-web-clipper/173/136

Aside from #213 .... The symbolic link topic was previously well answered ... https://forum.obsidian.md/t/markdownload-markdown-web-clipper/173/136

I find out , and It can work normal in windows. When we configurate the obsidian integration in markdownload , we should disable/enable the extension! And Then , We can find the obsidian integration in page context menu!
Quote:
https://github.com/deathau/markdownload/pull/152#issue-1345454036

I find out , and It can work normal in windows. When we configurate the obsidian integration in markdownload , we should disable/enable the extension! And Then , We can find the obsidian integration in page context menu!
Quote:
#152 (comment)

thank you - got it working now without needing a symbolic link.

Please can you screenshot the config? I can find where to enter the config, but could not get it to work

Please can you screenshot the config? I can find where to enter the config, but could not get it to work

Perhaps like me at first, you are not looking in the right place.
I was before looking for ...
Download Selection as Markdown
Download Tab as Markdown
instead one has to use ...
Send Text  Selection as Markdown
Send Tab as Markdown
https://i.imgur.com/GLJZwd2.png

Thanks, I have those but it is still not working for me. I can paste an AdvancedURI url in to the browser and that prompts for access to Obsidian and then opens the note in Obsidian OK.
In MarkDownload, selecting either Send tab or Send selection sometimes prompts for Obsidian access, occasionally opens Obsidian but never has content and I can't find a note anywhere.
I've added the vault name, and tried with the full windows path to the root for Obsidian, and with no path in case it was expecting something relative to the Obsidian root, and with an obsidian folder name. It must be something dim I'm doing, but I can't see it.
Tried Brave and Firefox with the same results.

Ahhh, sods law, having posted, I have just tried with an obsidian folder of "/" rather than blank, and that is now working correctly.

Please can you screenshot the config? I can find where to enter the config, but could not get it to work

Perhaps like me at first, you are not looking in the right place.
I was before looking for ... Download Selection as Markdown Download Tab as Markdown
instead one has to use ... Send Text Selection as Markdown Send Tab as Markdown

Thanks for pointing that out

@RobColes
Hahaha, Robsidian, you really have something
No need for full path, just the folder name

@LakeishaKowalczyk Thanks - that is working for me now (and my ego manages to sneak in everywhere 😁 )

@RobColes Hahaha, Robsidian, you really have something
No need for full path, just the folder name
It doesn't work for me. Instead of creating a note with the {pageTitle} filename it's creating a note with a name from the "Obsidian Folder". Like Robsidian/WebClipFolder.md, Robsidian/WebClipFolder 1.md and so on.

upd2. It's the problem with particular characters (like | ) in the page title.

Right, use this setting in markdownload

@RobColes Hahaha, Robsidian, you really have something
No need for full path, just the folder name

Thanks bro, I also made that mistake.

@RobColes Hahaha, Robsidian, you really have something
No need for full path, just the folder name

i do this,and "send text selection to obsidian",but just the text in Clipboard,nothing occur in obsidian,could you help me please😭

i do this,and "send text selection to obsidian",but just the text in Clipboard,nothing occur in obsidian,could you help me please😭

Have you enabled the advanced uri plugin in obsidian?