Set-Clipboard -AsHtml puts invalid CF_HTML on clipboard with non-ASCII text

Steps to reproduce

Set-Clipboard -AsHtml "abc"
Paste into Word
3) Text appears correctly as: abc
Set-Clipboard -AsHtml "àbc"
Paste into Word
Text appears incorrectly as: ࢣ
Appears CP 1251 text is being put in the CF_HTML, not UTF8.

Expected behavior
Text containing non-ASCII characters should be corrected converted to CF_HTML
Actual behavior
Any characters outside the ASCII range corrupt the HTML placed on the clipboard.
Environment data
> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.14393.693
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.693
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

At this time the Clipboard cmdlets are not compatible with PSCore6 as it depends on a System.Windows.Forms class which isn't part of corefx and would not be cross platform compatible.
I do think the clipboard cmdlets are useful, but should be a separate module that is cross platform compatible which may require different code paths per OS.

@SteveL-MSFT Can you open up this ticket, unless there's already a stub somewhere for a future Clipboard PowerShell module?

@pcgeek86 I think you should open a new issue if you want a clipboard module as this one was for a specific issue


Add setter method for the View.projection_ field.

Is your feature request related to a problem? Please describe.
For a project I need to display the map using the UTM/UPS projection system, and with this system, the projection have to be updated depending on where we are positioned on the map.
So I need to update the ol/Projection given to my ol/View object each time I move on the map, but it's not possible because there is no setter for that field.
The solution I come with first was to recreate a View object with a new projection each time I needed to switch projection, but this added a lot of complexity in my code.
Describe the solution you'd like
To solve this, would it be possible to add a setter for the View.projection_ field, so that there is no need to recreate an instance of View each time I need to switch projection.

It would be possible to add that, but usually it is easier to do what you are currently doing - creating a new View and call map.setView(newView). I don't see how this would be more complex than setting a projection, calculating the new center and zoom, and set the resulting properties on an existing view.

It makes sense to create a new view as center and resolution must also change when the projection changes.  As long as the projections are defined using proj4 and their extents overlap the onChangeProjection function in https://openlayers.org/en/latest/examples/projection-and-scale.html should work for any combination of projections.

It would be possible to add that, but usually it is easier to do what you are currently doing - creating a new View and call map.setView(newView). I don't see how this would be more complex than setting a projection, calculating the new center and zoom, and set the resulting properties on an existing view.

Yeah I didn't explain much. The reason why it's adding complexity is because for this project I'm setting many listeners on the view for different purposes. So any time I'm replacing the old view by the new one I have to unset the listeners on the old one, and reset all of them for the new view. And this has to be done any time we change projection, so with the UTM/UPS system it can be very frequent (nearly every mouse drag).

It makes sense to create a new view as center and resolution must also change when the projection changes. As long as the projections are defined using proj4 and their extents overlap the onChangeProjection function in https://openlayers.org/en/latest/examples/projection-and-scale.html should work for any combination of projections.

This is indeed the work from which one I started.


Added support for Big-Endian platform

Added a macro function to check whether a platform is big-endian or not:
const int _is_bigendian = 1;
#define is_bigendian() ( (*(char*)&_is_bigendian) == 0 )

Modified number of functions in ext/bson.h to handle things differently based on the endianness, with the GCC  __built_bswap32 and __built_bswap64 facilities:

WriteInt32()
WriteInt64()
WriteDouble()
CommitSize()
ReadInt32()
ReadUInt32()
ReadInt64()
ReadDouble()

Hello @christkv , this is a fix to address issue #30, would you have time to take a look? Thanks.


[Bug] Init block not discoverable after sch.blockize

When used on a block with a init statement, blockize creates a separate init block that is not discoverable by any means. This hinders further scheduling, like tensorizing the init block.
Expected behavior
When using blockize on a loop that contains an init statement, the init is moved to a new block <block>_init that should be discoverable with get_block or get_children_blocks on the newly created outer block.
Actual behavior
Init block exists in the TIR module but does not seem to be registered by the schedule. get_block("<block>_init>") fails with InternalError: Check failed: (it != self_->stmt2ref.end()) is false
Stacktrace

Traceback (most recent call last):
File "/home/dev/tvm_upstream/../tvm/playground/blockize_init_bug.py", line 31, in
a_init = sch.get_block("A_init")
File "/home/dev/tvm_upstream/python/tvm/tir/schedule/type_checker.py", line 340, in wrap
return func(*args, *kwargs)
File "/home/dev/tvm_upstream/python/tvm/tir/schedule/schedule.py", line 499, in get_block
return _ffi_api.ScheduleGetBlock(  # type: ignore # pylint: disable=no-member
File "/home/dev/tvm_upstream/python/tvm/_ffi/ctypes/packed_func.py", line 239, in call
raise_last_ffi_error()
File "/home/dev/tvm_upstream/python/tvm/ffi/base.py", line 481, in raise_last_ffi_error
raise py_err
File "/home/dev/tvm_upstream/src/tir/schedule/traced_schedule.cc", line 128, in tvm::tir::TracedScheduleNode::GetBlock(tvm::runtime::String const&, tvm::runtime::Optionaltvm::runtime::String const&)
BlockRV result = ConcreteScheduleNode::GetBlock(name, func_name);
File "/home/dev/tvm_upstream/src/tir/schedule/concrete_schedule.cc", line 321, in tvm::tir::ConcreteScheduleNode::GetBlock(tvm::runtime::String const&, tvm::runtime::Optionaltvm::runtime::String const&)
Array blocks = tir::GetBlocks(this->state, name, gv);
File "/home/dev/tvm_upstream/src/tir/schedule/primitive/get_block_loop.cc", line 46, in tvm::tir::GetBlocks(tvm::tir::ScheduleState const&, tvm::runtime::String const&, tvm::GlobalVar const&)
finder(prim_func->body);
File "/home/dev/tvm_upstream/src/tir/ir/stmt_functor.cc", line 142, in tvm::tir::StmtVisitor::VisitStmt(tvm::tir::BlockNode const)
this->VisitStmt(op->init.value());
File "/home/dev/tvm_upstream/src/tir/schedule/primitive/get_block_loop.cc", line 29, in VisitStmt
void VisitStmt_(const BlockNode* block) override {
File "/home/dev/tvm_upstream/src/tir/schedule/primitive/get_block_loop.cc", line 32, in VisitStmt_
ICHECK(it != self_->stmt2ref.end());
tvm.error.InternalError: Traceback (most recent call last):
5: tvm::tir::TracedScheduleNode::GetBlock(tvm::runtime::String const&, tvm::runtime::Optionaltvm::runtime::String const&)
at /home/dev/tvm_upstream/src/tir/schedule/traced_schedule.cc:128
4: tvm::tir::ConcreteScheduleNode::GetBlock(tvm::runtime::String const&, tvm::runtime::Optionaltvm::runtime::String const&)
at /home/dev/tvm_upstream/src/tir/schedule/concrete_schedule.cc:321
3: tvm::tir::GetBlocks(tvm::tir::ScheduleState const&, tvm::runtime::String const&, tvm::GlobalVar const&)
at /home/dev/tvm_upstream/src/tir/schedule/primitive/get_block_loop.cc:46
2: tvm::tir::StmtVisitor::VisitStmt_(tvm::tir::BlockNode const*)
at /home/dev/tvm_upstream/src/tir/ir/stmt_functor.cc:142
1: VisitStmt_
at /home/dev/tvm_upstream/src/tir/schedule/primitive/get_block_loop.cc:29
0: VisitStmt_
at /home/dev/tvm_upstream/src/tir/schedule/primitive/get_block_loop.cc:32
File "/home/dev/tvm_upstream/src/tir/schedule/primitive/get_block_loop.cc", line 32

Environment
Reproducible on main (d4056ca79571d4265a12beeedd1b1565953df936)
Steps to reproduce
import tvm

from tvm.script import ir as I
from tvm.script import tir as T

@I.ir_module
class Module:
    @T.prim_func
    def main():
        # with T.block("root"):
        A_sum = T.alloc_buffer((1,), "float32")
        A = T.alloc_buffer((1, 16), "float32")
        for nn, ff in T.grid(1, 16):
            with T.block("A"):
                v_nn, v_ff = T.axis.remap("SR", [nn, ff])
                T.reads(A[v_nn, v_ff])
                T.writes(A_sum[v_nn])
                with T.init():
                    A_sum[v_nn] = T.float32(0)
                A_sum[v_nn] = A_sum[v_nn] + A[v_nn, v_ff]

sch = tvm.tir.Schedule(Module)

a = sch.get_block("A")

loop_n, loop_f = sch.get_loops(a)
sch.blockize(loop_f)

print(sch.mod) # <-- A_init exists

a_init = sch.get_block("A_init") # <-- fails with InternalError: Check failed: (it != self_->stmt2ref.end()) is false

Triage

tir:schedule

I think you are supposed to call decompose_reduction before blockize:
import tvm

from tvm.script import ir as I
from tvm.script import tir as T

@I.ir_module
class Module:
    @T.prim_func
    def main():
        # with T.block("root"):
        A_sum = T.alloc_buffer((1,), "float32")
        A = T.alloc_buffer((1, 16), "float32")
        for nn, ff in T.grid(1, 16):
            with T.block("A"):
                v_nn, v_ff = T.axis.remap("SR", [nn, ff])
                T.reads(A[v_nn, v_ff])
                T.writes(A_sum[v_nn])
                with T.init():
                    A_sum[v_nn] = T.float32(0)
                A_sum[v_nn] = A_sum[v_nn] + A[v_nn, v_ff]

sch = tvm.tir.Schedule(Module)

a = sch.get_block("A")

loop_n, loop_f = sch.get_loops(a)

sch.decompose_reduction("A", loop_n)
sch.blockize(loop_f)

init_block = sch.get_block("A_init")

print(sch.mod) # <-- A_init exists

For my usage scenario I need to keep the T.init() statement so decompose_reduction is not an option. Also the fact that the A_init block is present in the associated module but not discoverable through schedule accessors clearly indicates a bug IMO.


Order drawing of actors

Currently, actors are drawn in the order they appear within the room's actor list. We need to be able to set the order of actors (which appear in front of which) in a consistent  and better way.

use this! https://stackoverflow.com/questions/19535644/how-to-use-the-priority-queue-stl-for-objects#19535699


Signature and SLSA attestation for all Carvel artifacts

Describe the problem/challenge you have
Currently, the artefacts produced by the different Carvel projects (binaries, images, bundles) are not signed. It would be nice if they were all signed to help with the implementation of supply chain security practices on the consumer side, requiring verification and provenance attestation of any third-party tool.
More and more cloud native projects started adopting Sigstore for signing and verifying artefacts. It would be great if all Carvel artefacts were signed with Sigstore cosign. There's a "Sigstore Landscape" in the OpenSSF with all the projects using Sigstore. It would be nice to include Carvel there. For GitHub based builds, the official Sigstore GitHub Action to install cosign could be used.
As part of improving supply chain security, SLSA provides a framework to guarantee the integrity of software artefacts, with different levels of compliance.
One of the main concepts introduced by SLSA is the provenance "to trace software back to the source and define the moving parts in a complex supply chain". It's defined as "the verifiable information about software artifacts describing where, when and how something was produced".
It would be a great addition to Carvel if all the project artefacts were not only signed, but also provided with a signed provenance attestation following the standard in-toto format. Such attestation would contain information about how each artifact was built. For GitHub-based builds, there is an attestation generator provided by the SLSA project: https://github.com/slsa-framework/slsa-github-generator.

I've started working on an RFC for this. I will publish a first draft here soon.

Signatures are now implemented for all Carvel artifacts (see https://github.com/carvel-dev/carvel/issues/691).
Next step will be adding SLSA attestations and SBOMs. I'm working on a followup RFC for that.


Guesses not checked against dictionary

In the online version of wordle, you cannot guess non-dictionary words. It would be good to have the cli check to see if a word is in the dictionary before accepting it as a guess.

Might I recommend using Fj00/CEL as a basis for your word list? I've used it for other projects and found it to be helpful. I'll also look back at some of my word game code to remember where I got some of my word lists from.


Update composer php requirement to 5.5 and up

PHP 5.5 is the oldest still supported PHP version. It does not make
sense to support older versions. PHP 7 will be released soon, so let's
start explicitly supporting it.
Fixes #7

52d83053a0d24e1b5d33d6ae72b4648927d59241


Incorrect use of get for a boolean field

Current implementation was failing if the config.ini included an explicit false --it was read as a string and thus a 'false' as a string was getted and it was considered True.
The enabled flag of the daemon was correctly using getboolean already.

Nice one. Thanks!


Lithuania converter

Took over #69 and fleshed it out a bit more.
It's not quite working right yet, as I couldn't get it to remove z-coordinates, which causes trouble for the geoparquet writer. I tried to add some code for shapely to get rid of them, but when I run it says '/Users/cholmes/miniforge3/envs/fiboa/lib/python3.12/site-packages/pyogrio/raw.py:198: RuntimeWarning: driver ESRI Shapefile does not support open option MIGRATIONS' and it doesn't work.
I got things working by just hand-editing the source input file, so was able to debug the next problem I had (casting properly from string to uint32).
I made it so the output filters in the same way that FTW does, but I have an open question for them about rapeseed, which is filtered out but seems like it should be in the dataset? Once I clarify I'll adjust if needed.
It does seem like the source data isn't spatially sorted at all.
I also need to update this to main, as it's still making geoparquet 1.0. I had troubles doing that on my local environment, so going to try on github.

Tried again merging main in locally and got it updated, but I seem unable to figure out how to update the migrate function to work. I'm getting 'convert() got an unexpected keyword argument 'store_collection'' - I tried to remove it but seem to still get the same error (but may be some weird build thing).
Anyways, I think this one is pretty close, but I'd need some help or at least some tips to take it over the line.

I'll have a look

@cholmes 4b49e0b60bc91c07d5435214d4a3fde3789204c4 makes it work, please have a look :-)


ReactSwipableView throws an unsafe-component-lifecycle Warning

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://reactjs.org/link/unsafe-component-lifecycles for details.

* Move data fetching code or side effects to componentDidUpdate.
* If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://reactjs.org/link/derived-state
* Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 18.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run `npx react-codemod rename-unsafe-lifecycles` in your project source folder.

Please update the following components: ReactSwipableView

Not maintained here, see https://github.com/oliviertassinari/react-swipeable-views


suboptimal (?) transition probability metric

Currently, our transition probability is higher for transitions which are close to a straight line. I see a few problems with this:

it's possible that the the wrong transition is favoured. E.g. say I have a candidate which is 100m away, but in exactly a straight line. If I have another candidate which is only 10m away, but slightly off a straight line, then the former will actually be favoured.
shouldn't we be using time, not distance (or at least allow the user to configure this)? The transition probability is meant to indicate the likelihood of transitioning (funnily enough) from one candidate to the next - and personally I think that most people think in times not distances. E.g. if I have two routes and one if 5 minutes faster than another, I'm more likely to take that, regardless of the length of either route. Put another way, changing to time-based transitions would mean that e.g. travelling along highways is more favoured than side roads. Again, we should easily be able to configure this.
I'm not sure we need to scale by the square of the time difference - if this scales all of the probabilities by the same factor, then won't this leave the final viterbi sequence unchanged? We'd probably remove this if we did time-based transitions anyway ...

That all said, I suspect most of these will only have noticeable differences when routing over larger distances (e.g. hundreds of meters).
Thoughts @stefanholder ?

it's possible that the the wrong transition is favoured. E.g. say I have a candidate which is 100m away, but in exactly a straight line. If I have another candidate which is only 10m away, but slightly off a straight line, then the former will actually be favoured.

Not really, because the transition metric also uses the linear distance between both GPS positions (see also the discussion here and below). So the transition metric favors straight connections between both GPS coordinates. This makes sense because people usually don't make detours during a trip.

shouldn't we be using time, not distance (or at least allow the user to configure this)?

We are already computing fastest routes using fastest weighting instead of shortest routes. So in the map matched route, highways are actually preferred over side roads.

I'm not sure we need to scale by the square of the time difference - if this scales all of the probabilities by the same factor, then won't this leave the final viterbi sequence unchanged?

Only the transition metric is scaled by the square of the time difference and this only affects the transition probability but not the emission probability. The intention was to compensate for the fact the non-normalized transition metric is usually larger for larger time intervals between GPS coordinates but in practice this is usually not needed. Hence, I would recommend to use the non-normalized metric instead .

So the transition metric favors straight connections between both GPS coordinates.

Doesn't that illustrate my point? I.e. it favours straight connections, not the shortest/fastest connection. I'd assume that (unless they're particularly concerned about their tyres) individuals take the fastest/shortest route without regard for how straight it is.

We are already computing fastest routes using fastest weighting instead of shortest routes. So in the map matched route, highways are actually preferred over side roads.

Correct - but we compute the transition using distance metrics not time. So, while for a given candidate pair we may (depending on user configuration) pick the fastest route (i.e. highway vs side road), when comparing different candidate pairs (i.e. the transition probability in viterbi), we only use distance (so e.g. a side road may be favoured over the faster highway route).

I would recommend to use the non-normalized metric instead .

OK - but let's continue the discussion above/below first.
As a proposal, what about this? The transition probability is:

higher for shorter routes. If the weighting is 'fastest' (as provided by user) then 'shorter' means 'shorter in time'. If the weighting is 'shortest', then 'shorter in distance'.
lower when the speed (path distance / gpx time diff) significantly exceeds the expected speed limits.
ignored (which tells viterbi no transition is possible) if the path distance exceeds a maximum (provided by user), the path speed (path distance / gpx time diff) exceeds a maximum (provided by user).
ignored or penalised if an inner-link U-turn occurs.

As a proposal, what about this? The transition probability is:
higher for shorter routes.

Hmm, but that's an assumption about the behavior of people, whereas the current transition probability only makes an assumption about how route through road networks look compared to straight lines, i.e. they are similar in length.
That's a rather big theoretical difference. I'm not saying it's a bad idea, I'm just saying it opens up new issues. The argument is the same as with U-turns: People do take unlikely routes, and there's no immediate reason why map-matching should be biased towards 'likely' routes in a behavioral sense.
Maybe my vehicle is a snow plough and passes through all roads with uniform probability.

Maybe what we are doing is wrong and we should completely admit all kinds of U-turns (as we agree, if it's only about distance, entering a link and going right back is continuous with not doing it, it's just epsilon away), and rather do some "behavioral smoothing" as a post-processing step?

(On second thought, maybe the "penalize turns, in general" idea which someone already had would do much the same but easier.)

I just wouldn't think of it as "turns are unlikely", but as "turn instructions in the result must pay rent in increased accuracy."

Maybe a general solution is already to let them specify the costs (time?) for u-turns (at measurements). Avoiding/allowing u-turns inside a route should be considered a separate problem.

I just wouldn't think of it as "turns are unlikely", but as "turn instructions in the result must pay rent in increased accuracy

What do you mean here?

But why? What's the real-world reason why a U-turn at a measurement should be more or less likely than anywhere else? Having that parameter would look like an artifact of the algorithm/implementation. :-(

U-turns for simple A to B routes are often meaningless or should be forbidden because e.g. turn restrictions could be tricked and it is not easy to decide whether a u-turn makes sense or is allowed on a road. (Or to explain it differently: we just have not the necessary data from OSM to judge about this good enough IMO)
And for measurements or 'via point' in general it is a lot more likely to have u-turns at those points because it could be a 'not continuing' route like for GPS traces of taxis picking up passengers and using the opposite direction for the next route.
If we would have good rules (and all the necessary good street data!) when to introduce U-turns in the general routing then probably we could avoid this separate handling and could even derive the more exact place of the happened U-turn instead of assuming this from the measurements (hopefully frequent enough).

Doesn't that illustrate my point? I.e. it favours straight connections, not the shortest/fastest connection. I'd assume that (unless they're particularly concerned about their tyres) individuals take the fastest/shortest route without regard for how straight it is.

Favoring straight connections is equivalent to favoring shortest routes because the linear distance is a lower bound for any path length.

Correct - but we compute the transition using distance metrics not time. So, while for a given candidate pair we may (depending on user configuration) pick the fastest route (i.e. highway vs side road), when comparing different candidate pairs (i.e. the transition probability in viterbi), we only use distance (so e.g. a side road may be favoured over the faster highway route).

When comparing different candidate pairs, we are actually comparing the distances of the fastest routes between the candidate pairs. But I agree that this is somewhat inconsistent. If we have low frequency GPS data and timestamps are given for GPS measurements (which we should not assume in general), we could compute the absolute difference between Path.getTime() of the fastest path and the timestamp difference instead. For high frequency GPS points using shortest paths is sufficient.
Another important point is if/how to normalize the transition metric. In this online map matching paper, the transition metric is normalized with the path length. Another alternative would be to normalize with the linear distance of the candidate pair. Either way, normalizing by a distance instead of normalizing by a time has the advantage that we don't even need timestamps. Before implementing a new transition metric, we should verify its probability distribution empirically as done by Newson & Krumm (Figure 5).

Maybe a general solution is already to let the user specify the costs (time?) for u-turns at measurements.

I agree.

Maybe what we are doing is wrong and we should completely admit all kinds of U-turns (as we agree, if it's only about distance, entering a link and going right back is continuous with not doing it, it's just epsilon away), and rather do some "behavioral smoothing" as a post-processing step?

I think that the (first-order) HMM is a powerful tool, which allows us to try out all kinds of the emission/transition metrics and probability distributions. So far I don't see why we should use any addition processing steps.

though we're limited in that we're currently a first order HMM solved by standard viterbi (i.e. we only know about the previous candidate). If e.g. we were second order (i.e. know two previous candidates) then we could more easily penalize (in a configurable way) U-turns and the like.

IMO a first-order HMM is sufficient to penalize U-turns or other turns but I would be happy to be proven wrong (ideally with a sample GPX trace). Moreover, using directed candidates with a first-order HMM was rather easy to do. For me the complicated part was figuring out how to use the Graphhopper internals. Having said this, I would be happy for any contributions to https://github.com/bmwcarit/hmm-lib.

For me the complicated part was figuring out how to use the Graphhopper internals.

BTW: Thanks for doing the necessary work! And always appreciated to improve stuff or make it more clear :) !

Favoring straight connections is equivalent to favoring shortest routes because the linear distance between A and B is a lower bound for the length of any path between A and B.

I understand that, but it only applies when you're comparing distances between fixed end points A and B. In our case we have a fixed start point but multiple (candidate) end points. See my first bullet point above for an example.

If we have low frequency GPS data and timestamps are given for GPS measurements (which we should not assume in general), we could compute the absolute difference between Path.getTime() of the fastest path and the timestamp difference instead

Except then it may become unrealistic (without traffic data). E.g. if you're on a highway and there's a traffic jam (and hence the time difference is large), it might prefer a longer side road. Again, I still feel the 'safest' is 'favour the fastest candidate pair'. This does fail (as sometimes people take slower routes) but I suspect less so than others. Of course, #89 would help.
As an aside - are we trying to cover the case of no timestamp info? If so, it seems to me it should need a different algorithm - adding timestamp info adds more information, so we should be able to do better than without it (and hence we need different approaches).

Another important point is if/how to normalize the transition metric

I'm still not fully understanding why we need a normalization - is this so that transitions probabilities are always comparable to emission probabilities, regardless of path length? (E.g. if transition was just exp(-a*pathDistance) then for long distances the transition probabilities would effectively be ignored, and it'd only be based on emission probabilities.)
Is it possible to normalize such that all transition possibilities (for a given to/from step pair) sum to one? If we also do the same with emission probabilities, then it might be OK.

So far I don't see why we should use any addition processing steps.

Agreed.

IMO a first-order HMM is sufficient to penalize U-turns or other turns but I would be happy to be proven wrong (ideally with a sample GPX trace)

I still can't figure it out, so I'll have a look at your code, and see if that makes it clearer.
Finally - does it make more sense to put this aside and work on #89 first? Otherwise all we have are our opinions (biased by our use cases etc.). In addition, other work is being doing (e.g. #88) which has changed the transition metric anyway.

In our case we have a fixed start point but multiple (candidate) end points. See my first bullet point above for an example.

The non-normalized transition metric is Math.abs(linearDistance - routeLength), where

linearDistance is the linear distance between the adjacent GPS measurements and hence does not depend on the candidates (note that the linearDistance is computed outside both for loops)
routeLength is the length of the shortest/fastest route between both candidates

Assuming that linearDistance < routeLength, which is usually the case, then for any two candidate pairs the one with shorter route length will have a higher transition probability. The same also holds for the normalized transition metric. This means that in your example the candidate that is only 10m away would be favored.

Except then it may become unrealistic (without traffic data). E.g. if you're on a highway and there's a traffic jam (and hence the time difference is large), it might prefer a longer side road. Again, I still feel the 'safest' is 'favour the fastest candidate pair'.

Not sure if I get your point, but just using the time of the fastest route or the length of the shortest route might also work.

As an aside - are we trying to cover the case of no timestamp info? If so, it seems to me it should need a different algorithm - adding timestamp info adds more information, so we should be able to do better than without it (and hence we need different approaches).

I think that the user should be able to specify if timestamps should be used. In some cases there are just no (correct) timestamps available. The non-normalized metric (see above) actually does not require any timestamps. I don't think that we need a totally different approach if timestamps are available, we can then just perform some addition validity checks. If there are ideas for totally different approaches with timestamps we can try them out with #89.

I'm still not fully understanding why we need a normalization - is this so that transitions probabilities are always comparable to emission probabilities, regardless of path length?

Yes but I would say regardless of the time interval between GPX entries.

Is it possible to normalize such that all transition possibilities (for a given to/from step pair) sum to one?

The problem I see with this is that transition probabilities would be higher for time steps with few transitions and lower for time steps with many transitions. This is bad because transition probabilities of different time steps also need to be balanced.

Finally - does it make more sense to put this aside and work on #89 first? Otherwise all we have are our opinions (biased by our use cases etc.)

Agreed but it was also good to do some brainstorming on possible transition metrics.

note that the linearDistance is computed outside both for loops

Ah, that's the key point I missed - for my use case I've had to use snapped coordinates (for other reasons), so it was my fault all along! I now (finally) see that it's effectively favouring the spatially shortest route between events. Thanks for taking the time to get it through to me.
To your above point about time point - yes, we could use that, but we could also use spacetime distance. So we can give the user options, and use #89 as you say.

I don't think that we need a totally different approach if timestamps are available

My point is that, as a general rule, if you add data to a model, it gets better. So while we can have one model that works without timestamp data, I suspect a model specifically built to include timestamp data may be better.

but I would say regardless of the time interval between GPX entries

This is bad because transition probabilities of different time steps also need to be balanced

Are you saying it would give different results if e.g. the transition probabilities for A -> B were scaled by a factor of a 100 (arbitrarily) vs those from B -> C? I.e. absolute size across different timesteps matters? I had assumed this wasn't the case.

As an aside, I'm having reasonable success with just using a scaled route distance (e.g. routeLength / 10000) as the transition metric.
To be fair, my use case is quite special - I've refactored to route using only real nodes (as mentioned here), and I generally have long separation between events (e.g. kilometres), and my linear distance is between candidates (not GPX tracks, as above). So it definitely won't apply in general. However, it's much less 'noisy' - I was seeing quite a lot of cases where e.g. a long route was preferred instead of the 'obvious' short one, or some silly back-and-forth ones, and they're largely gone.

Are you saying it would give different results if e.g. the transition probabilities for A -> B were scaled by a factor of a 100 (arbitrarily) vs those from B -> C?

I was actually wrong. Transition and emission probabilities for individual time steps can be scaled arbitrarily without changing the Viterbi results. However, this also means that scaling emission/transition probabilities cannot be used to normalize the transition metric. So scaling/normalizing only makes sense for the transition metric itself but not for the transition probability.
Note that subtracting the linear distance from the route length is also a form of normalization and maybe this suffices.

my linear distance is between candidates

You wrote that you just used routeLength / 10000, so why is there linear distance involved?

However, this also means that scaling emission/transition probabilities cannot be used to normalize the transition metric. So scaling/normalizing only makes sense for the transition metric itself but not for the transition probability.

Sorry, I'm not following why we can't just normalize the transition probabilities (for each step), regardless of metric? Actually, should transition/emission probabilities be normalized (i.e. sum to 1) by definition? I'm not an expert, but e.g. the Wikipedia examples use this property. Anyway, the additional benefit of this is that we could (depending how we do it) remove sigma/beta parameters completely. E.g. transition probability for A -> B as
routeLength (A -> B) / sum_over_to_candidates_T(routeLength(A -> T))

And we can easily change routeLength -> routeWeight to allow general weightings. This seems to make a lot of sense to me, though I may be missing something key. And again, there's probably not much point trying until we've got #89 .

You wrote that you just used routeLength / 10000, so why is there linear distance involved?

There isn't - it was more that if I use the existing metric (and linear distance) it doesn't work as well as it does for other matching tasks (where linear distance is that between GPX points).

Sorry, I'm not following why we can't just normalize the transition probabilities (for each step), regardless of metric?

We could do this but this wouldn't change anything. The Viterbi algorithm finds the candidate sequence with highest probability and the probability of a candidate sequence is defined as the product of all emission and transition probabilities on this sequence. If we multiply all transition probabilities for a given to/from time step pair with a normalizing constant then the probability of each candidate sequence is multiplied with this normalizing constant and the order of all candidate sequences from highest to lowest probability stays the same. So the effect of this is similar to multiplying the numerator and denominator of a fraction with the same number.

Actually, should transition/emission probabilities be normalized (i.e. sum to 1) by definition?

We use the Gaussian/exponential distribution to convert the emission/transition metrics to probabilities. Since both these probability distributions have continuous random variables (the metrics), individual emission and transition probabilities (or more precisely probability densities) may even be greater than 1. Another way to see this is that we can have arbitrarily many candidates at each time step by making the search radius bigger and bigger.

I'm not an expert, but e.g. the Wikipedia examples use this property.

Not sure what you mean exactly but the Viterbi algorithm usually just uses maximum and product to compute the probability of the most likely sequence. In my Viterbi implementation I add log probabilities instead of multiplying probabilities for better numerical stability but this is just an implementation detail.

Anyway, the additional benefit of this is that we could (depending how we do it) remove sigma/beta parameters completely.

The purpose of the Gaussian and exponential distribution we use is not just to convert a metric into a normalized number but to model the real distribution of the emission and transition metric. In Newson & Krumm, Figure 5 you can see that the exponential distribution is indeed a good model for our transition metric.

We could do this but this wouldn't change anything.

What you describe is what I was hoping to hear = ) Doesn't it show that there's no need to normalize? That said, I think there is a need to normalize such that emisison and transition probabilities both contribute materially to the result. (E.g. if emission were constantly near 1, and transition near 0.001, then the match could end up similar to standard waypoint graphhoppering.) Hence, if we do normalize, why not use something simple like the sum equals one? Then we can set a single parameter for deciding how much to favour emission versus transition (which currently isn't really possible).

In Newson & Krumm, Figure 5 you can see that the exponential distribution is indeed a good model for our transition metric.

I don't put too much weight in that. They've plotted a contrived variable against another contrived variable (which isn't normalized by time?), and have achieved an approximate alignment. That doesn't say much to me, especially as I'm guessing you can get very similar distributions many different ways. In addition, that only applies for their very specific data set, and one would really need to vary the data sets (and sampling rates) to decide this was best. Finally, we don't actually care about what the best model for transition/emission probabilities is - we care about what gives the best map-matching results. So, we're back to #89 - though discussing this sort of thing beforehand is good.

Hence, if we do normalize, why not use something simple like the sum equals one?

Depends on which sum you want to be equals to one. As I wrote before, making all transition probabilities of each to/from time step sum to one doesn't make sense as it doesn't change the final scoring of candidate sequences.

Then we can set a single parameter for deciding how much to favour emission versus transition (which currently isn't really possible).

Currently, only beta should be used for this. Sigma models the GPS noise and should be adjusted based on the GPS accuracy alone. Hence, we also have only one parameter for balancing emission vs. transition probabilities currently.
I still see you point that you want to have only one parameter left and you're welcome to show with #89 if/how this can be achieved.

As I wrote before, making all transition probabilities of each to/from time step sum to one doesn't make sense as it doesn't change the final scoring of candidate sequences.

That's what I mean = ) But we're repeating ourselves, so yes, let's wait until #89. @karussell is planning to merge map-matching into graphhopper soon, so I'll probably wait for that.


Animated icons not animated in Safari 10.1.2

Hey team, thanks for the great utility! I've noticed that for us the uninstall_animanted.png is not animated in Self Service (our current version is 9.97) or Safari 10.1.2 on macOS Sierra 10.12.6. @rtrouton also tested in Safari 10.1.2 on macOS 10.12.6. The files seem to work fine on Firefox and Chrome. The fact that the files don't work as anticipated in Safari may also relate to them not working as expected in Self Service.

This has been tested and working again in Safari 11 on 10.13.0 GM.

The project is released "as-is" so I'm going to close this bug report.


STOR-858: Bump github.com/openshift/* and k8s.io/*

Bump OpenShift and Kubernetes libraries. @openshift/storage

/hold
/retest

/hold cancel
(tagged the wrong PR)

/label docs-approved
/label px-approved
This is not user-facing change

/label qe-approved

/label qe-approved
CI is green


Add support for using data with pyarrow-backed pandas extension dtypes

In pandas=1.5, pandas added support for using pyarrow-backed extension data dtypes. Using these data types (in particular string[pyarrow]) can lead to large performance improvements in terms of memory usage and computation wall time.
I went to use these new dtypes with xgboost and got a (very informative) error about them not being supported. Here's a minimal reproducer:
import pandas as pd
import xgboost as xgb

df = pd.DataFrame({"name": ["alice", "bob", "rick"], "x": range(3), "y": [1.3, 7.2, 0.6]})
df = df.astype(
    {
        "name": "string[pyarrow]",
        "x": "int64[pyarrow]",
        "y": "float64[pyarrow]",
    }
)

X = df.drop(columns=["name"])
y = df.loc[:, "name"]
dtrain = xgb.DMatrix(X, y)
output = xgb.train(
    {"verbosity": 2, "tree_method": "hist", "objective": "reg:squarederror"},
    dtrain,
    num_boost_round=4,
    evals=[(dtrain, "train")],
)
print(f"{output = }")

which outputs
Traceback (most recent call last):
  File "/Users/james/projects/dask/dask/xgboost-pyarrow.py", line 15, in <module>
    dtrain = xgb.DMatrix(X, y)
  File "/Users/james/mambaforge/envs/dask-py39/lib/python3.9/site-packages/xgboost/core.py", line 620, in inner_f
    return func(**kwargs)
  File "/Users/james/mambaforge/envs/dask-py39/lib/python3.9/site-packages/xgboost/core.py", line 743, in __init__
    handle, feature_names, feature_types = dispatch_data_backend(
  File "/Users/james/mambaforge/envs/dask-py39/lib/python3.9/site-packages/xgboost/data.py", line 957, in dispatch_data_backend
    return _from_pandas_df(data, enable_categorical, missing, threads,
  File "/Users/james/mambaforge/envs/dask-py39/lib/python3.9/site-packages/xgboost/data.py", line 404, in _from_pandas_df
    data, feature_names, feature_types = _transform_pandas_df(
  File "/Users/james/mambaforge/envs/dask-py39/lib/python3.9/site-packages/xgboost/data.py", line 378, in _transform_pandas_df
    _invalid_dataframe_dtype(data)
  File "/Users/james/mambaforge/envs/dask-py39/lib/python3.9/site-packages/xgboost/data.py", line 270, in _invalid_dataframe_dtype
    raise ValueError(msg)
ValueError: DataFrame.dtypes for data must be int, float, bool or category. When categorical type is supplied, The experimental DMatrix parameter`enable_categorical` must be set to `True`.  Invalid columns:x: int64[pyarrow], y: double[pyarrow]

It looks like support for pandas nullable extension dtypes (e.g. Int64, Float64, etc.) has already been added to xgboost (xref https://github.com/dmlc/xgboost/pull/7760, https://github.com/dmlc/xgboost/pull/8480) and it would be great if pyarrow-backed extension dtypes were also supported.

Hi @jrbourbeau , thank you for raising the issue. A quick search didn't return any relevant document for enumerating the types.
https://pandas.pydata.org/pandas-docs/stable/ecosystem.html#ecosystem-extensions
https://pandas.pydata.org/pandas-docs/stable/development/extending.html#compatibility-with-apache-arrow
https://pandas.pydata.org/pandas-docs/stable/user_guide/basics.html#dtypes

Thanks @trivialfis! Yeah, I'm under the impression that extensive documentation around the new pyarrow dtypes is still in development. IIUC I think any pyarrow data type (listed here https://arrow.apache.org/docs/python/api/datatypes.html) can now be converted to a pandas dtype through pd.ArrowDtype.
In [1]: import pandas as pd

In [2]: import pyarrow as pa

In [3]: pd.ArrowDtype(pa.uint8())
Out[3]: uint8[pyarrow]

Also cc @mroeschke who is the expert in on the pandas side

I gained some basic understanding of arrow recently due to work on CUDA IPC with pyspark. I think XGBoost needs a new interface with pyarrow. Will try to build a prototype later.

Hey, out of curiosity, will this be used in dask in recent future, which would be really exciting!

I think XGBoost needs a new interface with pyarrow. Will try to build a prototype later.

Woo! Feel free to ping me into anything if you think it'd be useful

Hey, out of curiosity, is this going to be used in dask in recent future? It would be really exciting!

Yes! We're currently working on improving Dask's support for pyarrow-backed dtypes. FWIW I actually ran across this issue originally using xgboost.dask and a Dask DataFrame with int64[pyarrow], string[pyarrow], etc. data. If you have some examples of where pyarrow-backed dtypes have been / would be useful to you, @mroeschke and I would love to hear about them : )

Hi, I opened a PR https://github.com/dmlc/xgboost/pull/8653 . It's not completed yet since boolean and dictionary are not supported. Please help take a look when you have additional bandwidth.


farnocchia propagator returns NaN for some orbits

I tried to create ephemerides for an orbit that had a very small period (9.3605811e-8s).
import numpy as np; from poliastro.twobody.orbit import Orbit; from poliastro.twobody.propagation import cowell; from poliastro.ephem import Ephem

import astropy.units as u; from poliastro.bodies import Earth; from astropy.time import Time

r = np.array([-500, 1500, 4012.09]) << u.km
v = np.array([5021.38, -2900.7, 1000.354]) << u.km / u.s
orbit = Orbit.from_vectors(Earth, r, v, epoch=Time("2020-01-01"))

tofs = [100, 125, 150] << u.s
# Propagate the secondary body to generate its position coordinates.
rr, vv = cowell(
    Earth.k,
    orbit.r,
    orbit.v,
    tofs,
)

ephem = Ephem.from_orbit(orbit, orbit.epoch+tofs)
print(ephem.rv())

Output
(<Quantity [[nan, nan, nan],
           [nan, nan, nan],
           [nan, nan, nan]] km>, <Quantity [[nan, nan, nan],
           [nan, nan, nan],
           [nan, nan, nan]] km / s>)

For any t < 100 * u.s , the values were non-nan, whereas they start to become nan from the 100s mark.
I initially thought this might be because the period of the orbit is small whereas tof is high. I tried with another orbit, again with a small period of (8.3325481e-5s) but I got a non-nan result:
r = np.array([-5000, 1500, 4012.09]) << u.km
v = np.array([502.38, -2900.7, 1000.354]) << u.km / u.s
orbit = Orbit.from_vectors(Earth, r, v, epoch=Time("2020-01-01"))

tofs = [100, 125, 150] << u.s
rr, vv = cowell(
    Earth.k,
    orbit.r,
    orbit.v,
    tofs,
)

ephem = Ephem.from_orbit(orbit, orbit.epoch+tofs)
print(ephem.rv())

gives
(<Quantity [[  45239.34869765, -288568.58094236,<PHONE_NUMBER>6077],
           [  57799.18822177, -361085.69078418,<PHONE_NUMBER>1732],
           [  70359.02749432, -433602.79905165,<PHONE_NUMBER>1078]] km>, <Quantity [[<PHONE_NUMBER>1, -2900.68443511,  1000.33307316],
           [<PHONE_NUMBER>9, -2900.68435797,  1000.33304546],
           [  502.393567  , -2900.68430656,  1000.33302714]] km / s>)

Also, for an orbit with a period of 1.0245247e-7s, the output values are nan.
Any suggestions on this would be helpful. Thanks!

Hi Yash-10,
I noticed a few things:

I quickly looked at your inputs for your first run, and it seems the total distance of r is smaller (at 4312 km) than the radius of the Earth (which is about 6378km at the equator), which for your second orbit is not the case. Not sure if that is the cause for the error, I am personally not sure what happens if poliastro detects a radius lower than the main attractor's radius. To rule out this maybe you can use the moon as the main attractor for the first case.
I also noticed you orbital periods, after checking your semi major axis, it is negative, which means its a hyperbolic orbit, in other words it does not have an orbital period since it only passes the main object once. I am not sure how you calculated the orbital periods. (I am also not sure what kind of thing you are trying to simulate).

Note: I haven't used poliastro in a while, so I am not an expert on the package.
I hope this helps a bit.

Thanks @WolfsSky for chiming in! Indeed, both orbits are hyperbolic.
In any case, the problem seems to be that, while cowell returns an answer, the default propagator fails beyond a certain point:
In [25]: orbit
Out[25]: 4285 x -4285 km x 104.0 deg (GCRS) orbit around Earth (♁) at epoch 2020-01-01 00:00:00.000 (UTC)

In [26]: orbit.rv()
Out[26]:
(<Quantity [-500.  , 1500.  , 4012.09] km>,
 <Quantity [ 5021.38 , -2900.7  ,  1000.354] km / s>)

In [27]: propagate(orbit, [73] << u.s)
Out[27]:
<CartesianRepresentation (x, y, z) in km
    [(366059.84053624, -210250.93953118, 77036.53364381)]
 (has differentials w.r.t.: 's')>

In [28]: propagate(orbit, [74] << u.s)
Out[28]:
<CartesianRepresentation (x, y, z) in km
    [(nan, nan, nan)]
 (has differentials w.r.t.: 's')>

In [29]: propagate(orbit, [74] << u.s, method=cowell)
Out[29]:
<CartesianRepresentation (x, y, z) in km
    [(371081.20762409, -213151.63704118, 78036.8682027)]
 (has differentials w.r.t.: 's')>

Therefore, let's rule out Ephem from this issue.

Thanks a lot for the thorough debugging @Yash-10 ! Do you know if it does converge increasing the number of iterations? Or does it just diverges?

Interestingly, it does seem to converge (i.e. abs(p-p0) < tol) at the 101th iteration.

The default no. of iterations for _newton_hyperbolic in M_to_F is 100, and so the failure is because it takes just one iteration more!
https://github.com/poliastro/poliastro/blob/069167a111d978f281cee7330fbe8b34c4bc098e/src/poliastro/core/angles.py#L327
So maybe increasing maxiter might be a solution...

Interesting!
Well, the problem here I think is that there will always be an orbit that will not converge. Unless we set maxiter to float("inf") or something like that :) Otherwise, just increasing the number of iterations to 101 seems a bit silly, because we'd be able to find an orbit that would need 102, and so forth.
I see three options:

Increase maxiter to some other finite number. Not a super solid solution, but it doesn't harm.
Set maxiter to float("inf"). A bit dangerous, are we sure that the convergence is guaranteed?
Allow the user to more easily set the maxiter in the farnocchia propagator.

Thoughts?

Well, I recall #1247. It turns out it's a mistake from my side. I reverted to an older commit before that PR, and now I do not get any nan values.
That approach was taken from Vallado (discussion in #1240). Maybe we could work on understanding it better?

Oh, I see. Well, I guess slightly different initial guesses will have slightly different numerical performance. If reverting #1247 fixes this issue, then let's do that and add a regression test, so we don't forget again.
Maybe Vallado didn't test his initial guess with super high eccentricity orbits like this one? And even if they seem rare, I wouldn't be surprised if orbits like this emerge in impact trajectories or things like that.

Closed in #1444.


Expose APIs for customized generation

Export CodeGenerator and modify its APIs to be more direct use friendly. Behavior of CLI generation remains the same.

BTW, it's not necessary to be completed in this PR, but our project is getting more and more complicated, we'd better add more comments for new change. It's quite different from when I worked on it. LOL.


Call find_package(ament_cmake) after project().

To function correctly find_package(ament_cmake) must be called after
project().
Resovles the issue of ament_cmake not being found when building for ROS
2.

@dorodnic this PR fix the ros2 buildfarm issues. Would you please help merge. thanks.


Cannot install superset (Mac 10.14)

Make sure these boxes are checked before submitting your issue - thank you!

[√] I have checked the superset logs for python stacktraces and included it here as text if there are any.

[√] I have reproduced the issue with at least the latest released version of superset.

[√] I have checked the issue tracker for the same issue and I haven't found one similar.

Superset version
Trying to install the latest stable version on Mac OS 10.14 (Mojave).
I previously successfully installed v 25.0 but have had trouble upgrading.
Expected results
Follow instructions here and install: https://superset.incubator.apache.org/installation.html
I previously successfully installed v 25.0 but have had trouble upgrading on the same machine.
Actual results
After running 'pip install superset' seeing this returned at the tail end:
Failed building wheel for cchardet
Running setup.py clean for cchardet
Failed to build python-geohash sasl cchardet
Installing collected packages: idna, six, pycparser, cffi, asn1crypto, cryptography, Werkzeug, click, MarkupSafe, Jinja2, itsdangerous, flask, flask-caching, python-geohash, humanize, isodate, flask-compress, geographiclib, geopy, colorama, future, sqlalchemy, sqlalchemy-utils, pathlib2, docutils, jmespath, python-dateutil, botocore, s3transfer, boto3, pyhive, thrift, sasl, thrift-sasl, vine, amqp, kombu, billiard, pytz, celery, polyline, simplejson, contextlib2, numpy, pandas, chardet, certifi, urllib3, requests, pydruid, unicodecsv, parsedatetime, webencodings, bleach, gunicorn, WTForms, flask-wtf, defusedxml, python3-openid, Flask-OpenID, Flask-SQLAlchemy, Flask-Login, babel, Flask-Babel, flask-appbuilder, pyyaml, jsonschema, jsonlines, ijson, cchardet, linear-tsv, et-xmlfile, jdcal, openpyxl, xlrd, tabulator, rfc3986, tableschema, markdown, tornado, flower, unidecode, python-editor, Mako, alembic, flask-migrate, sqlparse, superset
Running setup.py install for python-geohash ... error
Complete output from command /Users/michaelcurry/Projects/superset/venv/bin/python3.6 -u -c "import setuptools, tokenize;file='/private/var/folders/dx/r2gd9l9d7j19v83wqnnr2j0w0000gn/T/pip-install-nnemd12o/python-geohash/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /private/var/folders/dx/r2gd9l9d7j19v83wqnnr2j0w0000gn/T/pip-record-npgbtk5r/install-record.txt --single-version-externally-managed --compile --install-headers /Users/michaelcurry/Projects/superset/venv/bin/../include/site/python3.6/python-geohash:
running install
running build
running build_py
creating build
creating build/lib.macosx-10.6-intel-3.6
copying geohash.py -> build/lib.macosx-10.6-intel-3.6
copying quadtree.py -> build/lib.macosx-10.6-intel-3.6
copying jpgrid.py -> build/lib.macosx-10.6-intel-3.6
copying jpiarea.py -> build/lib.macosx-10.6-intel-3.6
running build_ext
building '_geohash' extension
creating build/temp.macosx-10.6-intel-3.6
creating build/temp.macosx-10.6-intel-3.6/src
gcc -fno-strict-aliasing -Wsign-compare -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch i386 -arch x86_64 -g -DPYTHON_MODULE=1 -I/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -c src/geohash.cpp -o build/temp.macosx-10.6-intel-3.6/src/geohash.o
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
1 warning generated.
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
1 warning generated.
g++ -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -g build/temp.macosx-10.6-intel-3.6/src/geohash.o -o build/lib.macosx-10.6-intel-3.6/_geohash.cpython-36m-darwin.so
clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
ld: library not found for -lstdc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: command 'g++' failed with exit status 1
----------------------------------------

Command "/Users/michaelcurry/Projects/superset/venv/bin/python3.6 -u -c "import setuptools, tokenize;file='/private/var/folders/dx/r2gd9l9d7j19v83wqnnr2j0w0000gn/T/pip-install-nnemd12o/python-geohash/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /private/var/folders/dx/r2gd9l9d7j19v83wqnnr2j0w0000gn/T/pip-record-npgbtk5r/install-record.txt --single-version-externally-managed --compile --install-headers /Users/michaelcurry/Projects/superset/venv/bin/../include/site/python3.6/python-geohash" failed with error code 1 in /private/var/folders/dx/r2gd9l9d7j19v83wqnnr2j0w0000gn/T/pip-install-nnemd12o/python-geohash/
Steps to reproduce

Tried to upgrade without success
Uninstalled superset
Created new destination to begin installation from scratch : https://superset.incubator.apache.org/installation.html
Got the above error when running 'pip install superset'

Looks like the top two issues here are relevant: https://github.com/hkwi/python-geohash/issues

install error at python 3.6.5
pip install does not work with MacOS Mojave and XCode 10

ensure that xcode command line tools is installed by running
xcode-select --install
also make sure you open Xcode at least once to accept the agreement
finally I suggest using brew to install python 3.3.6 and then creating a python virtual environment to install and run superset within it

Thanks @aboganas for the suggestion.
I updated xcode but I do not think I can downgrade to python 3.3.6 since: "Superset has deprecated support for Python 2.* and supports only ~=3.6 to take advantage of the newer Python features and reduce the burden of supporting previous versions. We run our test suite against 3.6, but running on 3.7 should work as well."
When trying to install from python 2.7 I get this error:
Complete output from command python setup.py egg_info:
Sorry, Python < 3.6 is not supported

----------------------------------------

Command "python setup.py egg_info" failed with error code 1 in /private/tmp/pip-install-MTSX_u/superset/

sorry meant to say 3.6.*
you better rely on virtual environment. try the following
install brew
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
then install pyenv
brew update
brew install pyenv
brew install pyenv-virtualenv

then add to ~/.bash_profile the following
if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
if which pyenv-virtualenv-init > /dev/null; then eval "$(pyenv virtualenv-init -)"; fi

after that install build environment
brew install openssl readline sqlite3 xz zlib
sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /

then install specific python version in the virtual environment
pyenv install 3.6.6
then create a virtual environment
pyenv virtualenv 3.6.6 env
after that activate the newly create env
pyenv activate env
finally inside your active virtual environment you can install superset
pip install superset

Amazing!
I had the same problem, and solved it by your latest reply.
Thanks! @aboganas

Thanks @aboganas I am now seeing a new error:
ModuleNotFoundError: No module named '_scproxy'
Any thoughts?

@PushHandle I had the same question,Could you tell me how to solve the problem?

Thanks! @aboganas

Looks like the top two issues here are relevant: https://github.com/hkwi/python-geohash/issues

install error at python 3.6.5
pip install does not work with MacOS Mojave and XCode 10

What exactly are those issues?

I was able to install on Python 3.6.x with the help of conda. It seems pip does not have an updated geohash lib.
conda install -c conda-forge python-geohash


how to map just derived class properties (and exclude base class)

Hi,
(I'm referring to the 'source' type, I want to avoid mapping all inherited properties from base classes)
I've tried a few things fast, even MapToTargetWith(=> destination) to skip any mapping on the base, but then NoInherit doesn't work (seems) so the derived one is turned off as well (if I'm getting it right).
and btw. Mapster is looking great so far!
Thanks

In general, to ignore members, Mapster supports ignore member by names and by attributes.
TypeAdapterConfig<A,B>.NewConfig().Ignore("Prop1","Prop2");
TypeAdapterConfig<A,B>.NewConfig().IgnoreAttribute(typeof(CustomIgnoreAttribute));

Could you give reason behind and example why you would like to do this?

thanks for your response (and sorry on my slow response),
yes that's what I've done in the end, but I sort of need a more 'generic' solution:

I want to map all the properties of the derived class (on the 'source' side, target isn't important here).
I don't want any base class properties (as some naming/properties could clash w/ the target, resulting in 'silent bugs' which are very hard to catch, we've had those already).
problem is that I don't always know the target properties (or there could be many, think of it as a Db entity, and base classes are not really of interest (for mapping) but could have quite a few properties on their own - which potentially could create issues only.
Of course, I know my base class properties, but e.g. that means Ignoring dozen or so, and we have this pattern repeating over and over with different base classes, so it's becoming tedious.
I just thought you may have some way of doing this easily.
Thanks
P.S. if you need a 'hands on' example I could create one, thought this might be enough, let me know

I see your point. I also would like Mapster to be able to configure by convention rather than config name by name. For now, you could ignore by names. For example:
var props = typeof(Source).GetProperties(BindingFlags.DeclaredOnly | BndingFlags.Public | BindingFlags.Instance).Select(p => p.Name).ToArray();
TypeAdapterConfig<Source, Dest>.NewConfig().Ignore(props);

Thank you for suggestion.

thanks!
I didn't know it could do that (that 3rd overload w/ just names params), it does seem to work fine (just can't apply it to the TypeAdapterConfig<BaseClass, Target>.NewConfig().Ignore(props); (base class) but have to at the derived one directly, complains w/ empty collection 'expressions'),
that should do for me for now, thanks again


CC: Integrate the sign up flow between CC Dedicated and CC Free Tier

Closing, as this is out of date


Implement sendmail

Implemented sendmail as an alternative to SMTP.
A number of gogs users have requested the ability to use sendmail as an alternative to SMTP: https://github.com/gogits/gogs/issues/997
For some users setting up SMTP accounts for gogs is a lot more trouble than it's worth.
To keep this change simple I've not added any addational configuration parameter.  Instead I've reused the SMTP host.  If this contains a "/" then it will be interpreted as the location of the sendmail binary.  This is safe because hostnames can't contain slashes.
Other fields such as username and password will be ignored for sendmail.

I prefer real config options for that.

Beside that the linting fails within Drone.

Okay. I'll take a look and re-submit

Okay. These changes should have addressed previous concerns.

LGTM

LGTM

And maybe we need add some docs for all the new features after it is merged.

@lunny What would the best place to document this be?

send PR to github.com/go-gitea/docs


[besu] certmanager setup for besu

As of now this is valid only for besu network
added the cert manager helm chart
added new filed in network-besu.yaml "issuer: default/letsencrypt"
updated the code to deploy the cert manager and install certificates using cert-manager using letsencrypt CA, this will run only if "issuer: letsencrypt" in network-besu.yaml, else self signed certs will be created as earlier
updated the reset-network.yaml file to delete the certs at the time of network deletion
Reviewed by
@sownak @suvajit-sarkar @jagpreetsinghsasan
Fixes #2036

fixed the commented issues in PR 2187


Make type size smaller in sponsored posts?

I think this might further delineate it from editorial content. What do you think?

Is there a sponsored post online yet? Can you shoot me a link to it for reference?

There are only a couple. Here's a link to my favorite:
http://realpants.com/tag/david-foster-wallace/
On Monday, March 30, 2015, Dylan Kinnett<EMAIL_ADDRESS>wrote:

Is there a sponsored post online yet? Can you shoot me a link to it for
reference?
—
Reply to this email directly or view it on GitHub
https://github.com/real-pants/Real-Pants/issues/69#issuecomment-87884020
.


Error when filtering stats by --tubes

Hi!
I'm trying to filter the stats output by a list of tubes and am getting the following error. Initially I was listing several tubes separated by commas but I realised the same error occurs even with just a single tube.
`beanstool stats --host=xxx.xxx.xxx.xxx:11301 --tubes=dispatcher-fast
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x46664f]
goroutine 1 [running]:
github.com/src-d/beanstool/cli.(*StatsCommand).buildLineFromTubeStats(0xc8200126c0, 0x6316d8, 0x7, 0x0, 0x0, 0x0, 0x0)
/Users/mcuadros/workspace/go/src/github.com/src-d/beanstool/cli/stats.go:76 +0x8f
github.com/src-d/beanstool/cli.(*StatsCommand).PrintStats(0xc8200126c0, 0x0, 0x0)
/Users/mcuadros/workspace/go/src/github.com/src-d/beanstool/cli/stats.go:58 +0x1b5
github.com/src-d/beanstool/cli.(*StatsCommand).Execute(0xc8200126c0, 0xc820013170, 0x0, 0x3, 0x0, 0x0)
/Users/mcuadros/workspace/go/src/github.com/src-d/beanstool/cli/stats.go:36 +0x74
github.com/jessevdk/go-flags.(*Parser).ParseArgs(0xc820078190, 0xc82000a1d0, 0x3, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0)
/Users/mcuadros/workspace/go/src/github.com/jessevdk/go-flags/parser.go:301 +0xa16
github.com/jessevdk/go-flags.(*Parser).Parse(0xc820078190, 0x0, 0x0, 0x0, 0x0, 0x0)
/Users/mcuadros/workspace/go/src/github.com/jessevdk/go-flags/parser.go:175 +0x9b
main.main()
/Users/mcuadros/workspace/go/src/github.com/src-d/beanstool/beanstool.go:21 +0x6d4`

Hi,
I was able to reproduce the issue as well.
Backtrace
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x116d069]

goroutine 1 [running]:
github.com/src-d/beanstool/cli.(*StatsCommand).buildLineFromTubeStats(0xc000080690, 0x11d0e1c, 0x7, 0x0, 0x134c4a0, 0x0, 0xc0000b21e0)
	/Users/ramkumar/go/src/github.com/src-d/beanstool/cli/stats.go:78 +0xd9
github.com/src-d/beanstool/cli.(*StatsCommand).PrintStats(0xc000080690, 0x0, 0x0)
	/Users/ramkumar/go/src/github.com/src-d/beanstool/cli/stats.go:57 +0x277
github.com/src-d/beanstool/cli.(*StatsCommand).Execute(0xc000080690, 0xc000081140, 0x0, 0x3, 0xc000080690, 0x1)
	/Users/ramkumar/go/src/github.com/src-d/beanstool/cli/stats.go:36 +0x62
github.com/jessevdk/go-flags.(*Parser).ParseArgs(0xc0000b0230, 0xc0000880d0, 0x3, 0x3, 0x100d3c8, 0x30, 0x11b2140, 0xc00009e640, 0xc0000c0380)
	/Users/ramkumar/go/src/github.com/jessevdk/go-flags/parser.go:333 +0x80e
github.com/jessevdk/go-flags.(*Parser).Parse(0xc0000b0230, 0x11d0684, 0x4, 0x11d7609, 0x23, 0x0)
	/Users/ramkumar/go/src/github.com/jessevdk/go-flags/parser.go:190 +0x71
main.main()
	/Users/ramkumar/go/src/github.com/src-d/beanstool/beanstool.go:26 +0x43f
exit status 2

I tried to debug this and was able to figure out this issue and a fix.
TheGetStats function returns only the stats of the tubes mentioned when the --tubes argument is passed. However, in line 54 of stats.go, you are trying to print stats for the default tube as well. This results in the nil pointer dereference error.
To fix this, I removed the render statement  and the if statement inside the for loop (line 58) and things seem to work fine.
I have created a pull request with the fix.


Hosting examples on GitHub pages

Fixes #274. Code reviews welcomed.

See the working example for Flexbug#2 in GitHub pages here: https://akaustav.github.io/flexbugs/#flexbug-2

Hey @akaustav, thanks for taking this on, and sorry for the slow reply!
A couple of initial comments:

I think it's OK to have a gh-pages version of the README (especially if it's not being manually maintained by you), but my concern is existing links on the internet will fragment. I'd prefer if there was one clear place to link to, and since GitHub READMEs don't support redirects (as far as I know), then I'd prefer if the current README continues to be the main landing page.
One of the nice things about CodePen was that it allowed people to easily play with the values and see the results. With GitHub pages you can see the values, but you can't easily modify them yourself. Have you considered something like Glitch? It might be just as easy to maintain a single Glitch repo with all the demos in separate folders.

Hi @philipwalton,
My comments are inline:

I think it's OK to have a gh-pages version of the README ...

I only created a GitHub pages version because it was suggested by @mreinstein (see comment) and you seemed open to the idea (your comment).

... (especially if it's not being manually maintained by you), ...

I can confirm that I am NOT manually maintaining the GitHub pages hosted at https://akaustav.github.io/flexbugs. It was created automatically by the existing README.md. I followed this straightforward tutorial. This commit contains the auto-generated one-liner code change which enabled GitHub pages on my fork.

... but my concern is existing links on the internet will fragment.

Just for the sake of clarity, if my PR is merged, I can assure you that the final GitHub pages URL will probably read https://philipwalton.github.io/flexbugs and not https://akaustav.github.io/flexbugs, if that is what you are concerned about. Having said that, the existing README.md is still necessary for that gh-pages homepage to exist. So, existing links on internet should not break (at-least not yet 😉).

I'd prefer if there was one clear place to link to, and since GitHub READMEs don't support redirects (as far as I know), then I'd prefer if the current README continues to be the main landing page.

The real reason for gh-pages is hosting the static HTML files containing the bug and it's workaround. The current README can (and will) continue to be the main landing page. The GitHub pages homepage is merely a side-effect. You can treat it as an auto-generated supplement, if you want to treat it that way. People can still continue to read the description of the bug and it's workaround in the README.md. If you are still concerned, we can try putting up an alternate homepage on gh-pages - something which does NOT reference the README.md file - pretty sure I will find some solutions if I Google-fu.

One of the nice things about CodePen was that it allowed people to easily play with the values and see the results. With GitHub pages you can see the values, but you can't easily modify them yourself.

It does not have to be GitHub pages. It can technically be a bunch of static html or hosted on a service which supports older browsers such as IE 9, 10 and 11 without showing an error message.

Have you considered something like Glitch? It might be just as easy to maintain a single Glitch repo with all the demos in separate folders.

I have heard about Glitch, but not tried it myself yet. But I can certainly give that a shot as long as it supports older browsers where these bugs are prominently reproducible. Or perhaps add onto something which you might have already tried?

Just for the sake of clarity, if my PR is merged, I can assure you that the final GitHub pages URL will probably read https://philipwalton.github.io/flexbugs and not https://akaustav.github.io/flexbugs, if that is what you are concerned about.

I was not concerned about that, I was concerned that an existing link on the internet (e.g. https://github.com/philipwalton/flexbugs/#flexbug-9) would no longer go to a description of that bug. Based on your response, it sounds like the README file will stay as currently structured, which is great.
My other concern is that there'd start to become two URLs for the same bug, e.g.:

https://github.com/philipwalton/flexbugs/#flexbug-9
https://philipwalton.github.io/flexbugs/#flexbug-9

I think this is a problem because if then (in the future) we decide to move off of GitHub pages, then the link in the second bullet above would break. My preference is if the README continues to be the only "landing" page for the list of links, but I think it's fine if where the demos are hosted changes from time to time (hopefully not too much).
I don't have a strong preference between GitHub pages and Glitch, but if we land on using GitHub pages I think I'd prefer that the index page not be just another version of the README. Do you know if that's possible? If it can just link back to the README or display a table of contents for each of the demos that would be my preference.

pardon my ignorance, but isn't glitch another remote hosted service, like codepen?  If that's the case, we're kind of at their mercy to continue supporting ie on their site right?

@mreinstein the part of CodePen that no longer supports IE 11 is their interactive viewer/editor. I was thinking we could use Glitch purely to host the demos, but I guess that's no really much different that using CodePen's debug view, e.g. here's Flexbug 1.1.a in debug mode (which works fine in IE 11):
https://cdpn.io/philipwalton/debug/MYbrrr/xJkjOnLWxXQM
I suppose another options would be to just link to both the interactive CodePen view and the debug view (for IE 11). What do people think of that?

Thanks for clarifying!
For me, the inability to live modify examples while viewing ie is acceptable.
I'm hopeful as time progresses, the number of active flexbugs across browsers will continue to drop. Ideally at some point all that's left is ie related issues.
Assuming that happens, I think the biggest problem to solve is how to make this content viewable for a long time.
Being able to view these bugs in pages that still work in old browsers, and not having them hosted on an external resource are 2 things I think help preserve the viewability of this content. The inability to live modify examples while viewing ie is an acceptable tradeoff.

... e.g. here's Flexbug 1.1.a in debug mode (which works fine in IE 11):
https://cdpn.io/philipwalton/debug/MYbrrr/xJkjOnLWxXQM. I suppose another options would be to just link to both the interactive CodePen view and the debug view (for IE 11). What do people think of that?

@philipwalton - CodePen's debug view requires you to create accounts - and cannot be viewed anonymously. In one of the proposed solutions on issue #274, I mentioned to do the debug mode after creating an account/logging into CodePen. I see the following when I visit the above URL anonymously (in Chrome Incognito mode):

@philipwalton / @mreinstein:
Glitch doesn't support Internet Explorer yet
When I try opening Glitch in IE11 on my Windows 10 laptop, I see this message:

@philipwalton Now that we have established that codepen and Glitch might not work for hosting these IE bugs (because both websites have limited or no support for IE), I have made the following changes in order to proceed with hosting on GitHub pages - hopefully they satisfy your requirements:

The main documentation stays in README.md. There are no secondary documentation on GitHub pages - see: https://akaustav.github.io/flexbugs.
All content inside the src folder have been moved into the docs folder.
GitHub pages now uses contents of the docs folder instead of the contents of the root folder.
For referencing source code on GitHub, we can use relative URLs.
For referencing rendered output on GitHub pages, we will need to use absolute URLs.

@philipwalton So, do you have any thoughts/opinions on the new changes in this PR? Am I clear to s/akaustav/philipwalton/g now?

Yes, I think we're almost good to merge. The main thing I'd like to make sure happens before merging is that we get the right vendor prefixes in case folks are testing these demos in the browsers we say have bugs.

this could help with the prefixing    https://autoprefixer.github.io/

@philipwalton Please review the latest changes and let me know if I can run s/akaustav/philipwalton/g now.

This looks good to me. Thank you!

@philipwalton I have executed s/akaustav/philipwalton/g on this PR. If you'd like to do the honors, this PR is ready to be merged now. Or you could give me the necessary access, and I can change the following settings after merging the PR. After testing, I can open similar PR(s) (directly on this repo, or via a fork) to create the HTML files for the 16 remaining flexbugs and their workarounds.
Steps after merging
After merging, please perform the following steps in your GitHub repository:

Navigate to https://github.com/philipwalton/flexbugs/settings.
Scroll down to the GitHub Pages section.
Set the following values:

Source: master branch /docs folder.
Theme Chooser: Slate theme - Feel free to choose any other theme.
Custom domain: [blank]. Feel free to set a custom domain if you'd like - pretty sure we need to change the URL in README.md files if you decide to use a custom domain.
Enforce HTTPS: Checked and Disabled. Says - required for your site because you are using the default domain.

After these changes, your screen should look similar to the following screenshot:

@akaustav I can definitely give you access (I'm very happy with what you've done so far and the thoughtfulness you've put into your changes). How would you feel about holding off on merging this though until after the rest of the HTML updates?
If not wanting to wait for a back and forth from me. I can give you access now and then you can make the changes needed whenever you have time. How does that sound?

@philipwalton Sounds good to me. Now that we have an agreement on how one example should be done, I can replicate the same for the remainder of the examples in my fork. But here are some problems which I foresee:

[ ] It will be difficult to test with the s/akaustav/philipwalton/g. I will probably need to revert that commit and run that same commit at the end after testing all other examples.
[ ] Unless you have an alternative approach, it might be beneficial if I had debug view access to your pens on CodePen instead of cloning all your pens.

I'll try updating here when I am ready to merge for you to review once before merging, I guess. Feel free to give me access to merge the PR when it is ready.
Side note: I noticed that there are 79 open issues on this repository - oldest one dating back to Jan, 2015. I replied to issue #281 this morning - which was closed quickly. While responding to that issue, I noticed that flexbug 12.1.a (and possibly others) is no longer reproducible in IE11 - example comment here. Do you need help to close out some of those long standing issues?

It will be difficult to test with the s/akaustav/philipwalton/g. I will probably need to revert that commit and run that same commit at the end after testing all other examples.

SGTM

Unless you have an alternative approach, it might be beneficial if I had debug view access to your pens on CodePen instead of cloning all your pens.

Hmmm, I just tried and it doesn't look like there's any way to grant other users access rights. If you know of a way I'd be happy to do that though.

I'll try updating here when I am ready to merge for you to review once before merging, I guess. Feel free to give me access to merge the PR when it is ready.

Sent you an invite earlier this morning :)

Side note: I noticed that there are 79 open issues on this repository - oldest one dating back to Jan, 2015. I replied to issue #281 this morning - which was closed quickly. While responding to that issue, I noticed that flexbug 12.1.a (and possibly others) is no longer reproducible in IE11 - example comment here. Do you need help to close out some of those long standing issues?

Yes, I would love help. I essentially have zero time to maintain this repo, and I would love it if more people from the community got involved. I should probably be more proactive about seeking external contributors (I think it would make sense to do that once this PR lands).

@philipwalton: I have s/philipwalton/akaustav/g temporarily.

Hmmm, I just tried and it doesn't look like there's any way to grant other users access rights. If you know of a way I'd be happy to do that though.

No worries - I will continue to clone your pens for now. Meanwhile, looks like there are more features like Collab Mode and Professor Mode in CodePen Pro for Individuals or Teams which might allow to share pens without redundancy. But, I do NOT think it is worth spending money just for this feature.

Sent you an invite earlier this morning :)
My apologies. I did not realize that you had granted me collaborator access on this repository. I have accepted the access and I can see the "Merge pull request" button now. I am working to include all other flexbugs into my PR at the moment. Rest assured that I will NOT merge until all 17 of them are ready.

Side question: Which merge option do you prefer?

Create a merge commit (default)
Squash and merge
Rebase and merge

On a related note, before I merge my PR, I am also thinking of creating a tag (named, let's say - codepen) from the latest commit on the master branch of this repository, as a backup - just in case we want to refer the original code in CodePen in the future. However, there is no point of this effort if you are planning on deleting your pens on CodePen. Any thoughts?

Yes, I would love help.
I will gladly try helping whenever time permits.

Side question: Which merge option do you prefer?

I prefer a merge commit myself, though I don't care if you prefer a different strategy and want to use the GitHub UI instead of manually squashing/rebasing superfluous commits.
Personally I do all my squashing/rebasing manually, but like I said, I'm open to whatever is easiest for you.

However, there is no point of this effort if you are planning on deleting your pens on CodePen. Any thoughts?

I don't think I'll delete them because I imagine some people might be linking directly to them on the web, and there's no point in breaking those links.

@philipwalton: I apologize, it took longer than I anticipated, but I have finally converted all 17 example bugs and their workarounds into gh-pages. Do you wish to take a final look before I merge this PR into the master branch?
To Do

[x] @akaustav created a tag called codepen - just in case we wish to refer back to the version of README.md which contained links to codepen.io
[ ] @philipwalton to review all changes to this PR since last review and re-approve this PR
[ ] @philipwalton to preview the corresponding README.md in my fork
[ ] @akaustav to fix any issues which @philipwalton finds
[ ] @akaustav to run s/akaustav/philipwalton/g
[ ] @akaustav / @philipwalton to merge this PR
[ ] @philipwalton to enable GitHub pages within repository Settings - @akaustav does NOT have access to the Settings tab yet.

@philipwalton, need your help with this. Please advise.

Hey @akaustav, thanks! I've blocked out some time to take a look at this tomorrow. I'll get back to you after that.

I went through a few of the demos (randomly) and they all look good. I didn't notice anything that is different from the existing demos, so I think it's fine to move forward. If there's anything small that's incorrect, we can always fix it in the future (I'll keep my CodePen demos up for a while).
Also, feel free to add your name to the repo as a maintainer. You deserve credit for all the work you've put into this!

@philipwalton to enable GitHub pages within repository Settings - @akaustav does NOT have access to the Settings tab yet.

Hmm, not sure if that's a permission I can give you (it doesn't look like there's a higher role than "collaborator" for personal repos), but happy to make the change myself.

@akaustav thank you so much for all of this hard work! People like you are what make open source awesome to work with! :)

I went through a few of the demos (randomly) and they all look good. I didn't notice anything that is different from the existing demos, so I think it's fine to move forward. If there's anything small that's incorrect, we can always fix it in the future (I'll keep my CodePen demos up for a while).

Thanks for reviewing this PR and the demo.
I will work on the s/akaustav/philipwalton/g shortly.

Also, feel free to add your name to the repo as a maintainer. You deserve credit for all the work you've put into this!

How do I add myself as a repo maintainer?

Hmm, not sure if that's a permission I can give you (it doesn't look like there's a higher role than "collaborator" for personal repos), but happy to make the change myself.

I just read thru the GitHub docs around Permission levels for a user account repository. I'll let you decide what the best course of action is. The following rules apply to this repository owned by your user account (rules differ for repos belonging to organizations/teams/enterprise):

There are two permissions:

owner
collaborators

There is only ONE owner (However, there is an option to transfer ownership or convert a user account to an organization account).
There can be multiple collaborators.
Only the owner can view and change the settings for the repo.

@akaustav thank you so much for all of this hard work! People like you are what make open source awesome to work with! :)

I appreciate the kind words, @philipwalton.
You have been a great mentor and guide yourself - helping me with most of the decisions on this PR.

How do I add myself as a repo maintainer?

I just meant feel free to list yourself here (if you're comfortable with that):
https://github.com/philipwalton/flexbugs/#acknowledgments

There is only ONE owner (However, there is an option to transfer ownership or convert a user account to an organization account).

Hmmm, if there can only be one owner, then I'll probably keep it as is right now. But if it becomes the case that you're constantly needing to ping me for approvals to change settings like this, then I'll certainly consider transferring at that point.

@philipwalton Also, do you think it is a good idea to keep a backup of the original README.md file with links to codepen.io (perhaps inside a backup folder - like: backup/README.original.md)? Or does the codepen tag suffice?

I think it's fine to just keep what's already in the git history.

@philipwalton Added myself to list of maintainers. If you don't mind quickly checking if the change is fine, then I can go ahead and merge this PR.

ASIDE @akaustav thanks for tackling this stuff. I've been slammed with other work and unfortunately this has taken a back seat.
As always, @philipwalton thanks for keeping the lights on :)

LGTM, thanks so much!

Alright, @philipwalton, I am merging this PR now.
Refer to the comment above about how to enable GitHub pages in this repo.

OK, I turned on GitHub Pages. It looks like it's working, though I still see a 404 for this page (not sure why, everything looks correct): https://philipwalton.github.io/flexbugs/1.1.a-bug.html
Can someone else verify? It may be an issue just affecting me since I went to the URL before enabling GitHub Pages, at which point a 404 would be expected.

Hmmm, when I view it on my phone, everything loads as expected, so I guess it's just an issue on my end.


Skeleton takes space even when it's not shown

Is there an existing issue for this?

[X] I have searched the existing issues

Do you want this issue prioritized?

[ ] Yes, I have sponsored
[x] Not urgent

Current Behavior
Skeleton is taking its defined width and height space even when it's set to show={false}.
In CSS terms it behaves as if its visibility is set to hidden!
Expected Behavior
It should completely disappear from view as if its CSS display is set to none.
Steps To Reproduce
import { StyleSheet, Text, View } from "react-native";
import { Skeleton } from "moti/skeleton";

const Item = () => {
  return (
    <View style={styles.container}>
      <Skeleton
        show={false}
        colorMode="light"
        height={48}
        width={48}
        radius={10}
      >
        <Text>Jack</Text>
      </Skeleton>
    </View>
  );
};

export default Item;

const styles = StyleSheet.create({
  container: {
    minHeight: 125,
    justifyContent: "center",
    alignItems: "center",
    backgroundColor: "#fff",
    borderRadius: 10,
    padding: 10,
    marginBottom: 10,
    shadowColor: "#000",
    shadowOffset: {
      width: 0,
      height: 2,
    },
    shadowOpacity: 0.25,
    shadowRadius: 3.84,
    elevation: 5,
  },
});

Versions
- Moti: 0.26.1
- Reanimated: 3.3.0
- React Native: 0.72.6
- Expo: 49.0.13

Screenshots
No response
Reproduction
Nothing to show.

A common pattern for text skeletons is to show dummy text as a fallback when show is set to true so that it takes up space still


certz2.1/2.2/4.1  needs more specific testcase scenario related to server certificates/trust bundle

Request for more explicit  testcases defining the scenarios related to server certificates:
-The description in the README.md for the certz 2.1/2.2 test requirements are more similar to the certz 1.1/1.2.
-There is a minor difference between the certz1.1/2.1 , where only the server /client certificate loading are in different order.)
-certz 4.1 test coverage also is covered in certz1.1 tests, the description of 4.1 can be further more fine tuned.
Certz1.1/1.2 pull request : https://github.com/openconfig/featureprofiles/pull/2488
Implement code for Certz-2.1/2.2
https://github.com/morrowc/featureprofiles/blob/main/feature/security/gnsi/certz/server_certificates/README.md

Apologies, I don't actually know what you're asking here?
certz-1.1 - "load a client certificate into the client, connect to each gRPC service in turn, verify that the client's certificate is verified by the server."
The different certificates represent those created by specific CertificateAuthority(CA) sets.
Each CA set has a differing number of CAs, their associated public keys are in the trust_bundle files per set of CAs.
The point here is:
"Yes the gRPC service can use the CA trust-bundle required for client-certX, Y , Z."
where the CAs in the trust-bundle are 1, 10, 100, 1000 CAs... 'can the gRPC server traverse a list of 1k CAs in a trustbundle?"
The Certz-2.1 is the reverse of that: "Can the client verify the certificate of the gRPC service?" "Even if the list of CAs in the trust_bundle is 'very long'?"

Certz-4.1 is 'can the server load it's own certificate?' (even if the trust-bundle associated is improbably long)

Hi Chris,

We are aligned with the explanation and the stated intention of the test plan. However, the way Certz-1.1 and Certz-1.2 test cases are written, they are already validating the requirements stated in Certz-2.1 and Certz-2.1, as well as Certz-4.1.
Here is the flow of the Certz-1.1 & Certz-1.2 test script that is being worked through pull/2488 -

Script invoked mk_cas.sh to dynamically generate the client, server and CA certificates .
Client certificates are installed in the controller side. Server and CA certificates are installed on the DUT.
The DUT is configured to setup an mTLS session for any gRPC connection to the device.
Client initiates the gRPC mTLS session, presenting the TLS session during the session establishment.
Server validates the client certificate by traversing the 1, 10, 100, 1000 CA trust bundles - which meets the requirements for Certz-1.1, Certz-4.1.
Server presents its own configured certificate, which the client validates through the trust bundle installed on the client. This meets the requirement for validating the Certz-2.1 server certicate rotation test case.
The negative test case validates all of Certz-1.2, Cert-2.2 requirements as the test installs a client certificate which is created by CA-01, whereas the trust bundle installed on the device belongs to CA-02 as stated in the test. The test validates whether or not a new connection with the incorrect client certificate is unsuccessful, due to which the system rollback to the working certificate set as the Finalize request never makes set. Subsequently, the new connection with the DUT having the certs from CA-01 set must go through.

ok, I don't think it's problematic to have the tests work out that way, and/or to just do a test 2x...
The purpose of the the 1.1 test is really: "Does the client cert work as expected"
The purpose of the 1.2 test is: "yup, trustbundles matter"
Yup, I agree that 4.1 basically says: "Are you sure that the various combinations of certs (client/server) and trustbundles work out correctly (and that you can detect failures of that mesh)"
(yes, loading the certs for 4.1 and testing them is very similar to 1.1 / 1.2 ... does that matter?)


Tour can not follow dynamically loaded components (ie loaded with ComponentFactoryResolver )

When "tourAnchor"s are applied to the templates of dynamically loaded components these anchors do not show up in the anchors list in the tour service and therefor are not navigable by the tour.

Thanks for the bug report.

Did you find anyway to resolve this?

I'm not able to reproduce this bug.
I created a component that has a tourAnchor in it:
@Component({
  selector: 'installation',
  template: `<h2 tourAnchor="installation">Installation</h2>`,
})
export class InstallationComponent {}

And then injected it in another component:
  @ViewChild('installationPlaceholder', { read: ViewContainerRef })
  public installationPlaceholder: ViewContainerRef;

  constructor(private componentFactoryResolver: ComponentFactoryResolver) {}

  public ngOnInit(): void {
    const factory = this.componentFactoryResolver.resolveComponentFactory(InstallationComponent);
    this.installationPlaceholder.createComponent(factory);
  }

After doing this, the installation tourAnchor is correctly registered with the TourService.
How are you dynamically loading components?

I had a similar issue, if i forgot to import the module TourNgBootstrapModule


Do not ask for RPC endpoint again

The app still asks, but there is an improved upgrade flow and with that this will be eliminated.


module definition error provenance

A definition for option `outputs./' is not of type `package'. Definition values:
- In `/nix/store/nj2n...-source/src/evaluator/modules/default.nix'

This error message says just about nothing. We need to improve it, possibly by using _file module attribute.

I think we can close this because evaluators will eventually cease to exist as specific-purpose builtins get removed. Feel free to open new issues if more poor errors show up


Silence miq expression deprecation

Too many deprecations in the log around miq_expression.
Not optimal, but we do not want to address now, these warnings are too intrusive.
/cc @matthewd

@Fryguy @gtanzillo Are we planning on fixing these deprecation warnings? If not, then maybe it is best to just punt for now rather than have every build display these.


Add README

Add the README file explaining the use and the usage.

Hi. So you basically want to beautify the readme, right? Or is there something needed to be added?

@mridulg anything that improves the existing file and makes sense.


Fix prettier when running from docker

yarn run for some reason does not pass --write to the prettier when executed from the docker container.
So instead of #236 I will do this.
/cc @belak, @erayd

The other option would be to include the whole command in the scripts. yarn run prettier-css as an example.

@maximbaz Thanks!


Update the Chinese FAQ to stay in line with the latest.

Mainly break the "what" section into "what" and "why", and updated the "Why did you break with the Node.js version numbering system?" section.

#357 #372 #361

@nodejs/iojs-cn

LGTM +1

LGTM :+1:

Merged, thank you!


include angular using protocol-relative URL

When viewing page using https, some browsers block http content

alternatively, just use https always