text:
Discussion copied from scheinerman/Permutations.jl

It seems to me that your AbstractPermutations is not a minimal compatibility package, but a much more extended one representing your idea of how to write permutations.
By the way, I reiterate my opposition to using the term degree for the largest moved point. Exporting this name means in particular that you cannot load simultaneously this package and any package implementing polynomials.
My permutations would not pass your tests, and here are some details.
If I were to use degree for largest_moved_point, I would fail the test where you define the degree of the identity permutation to be 1. Why not 0? As a mathematician, I would have expected you to make a more consistent choice. The fact that for you cycles(identity)=[[1]] is perhaps a consequence but is inconsistent with the printing of identity as ().
I suppose your firstmoved is my smallest_moved_point. Again it should be 0 and not 1 for the identity. The fixedpoints and nfixedpoints seem to operate on 1:degree. This not very useful if you consider permutations in a permutation group of degree n. This is a case where the "implementation detail" of what is the actual length of the internal image vector would be a more pertinent parameter.
My Perms do not pass the test where the constructor taking a Vector{Int} checks its argument for validity. For me this constructor is almost exclusively used when programming some code internal to the permutations package, and does not check in order to be fast. The most common constructor for the user is using the cycle decomposition like Perm(1,2,3)*Perm(4,5) or perm"(1,2,3)(4,5)". It is these last constructors which are checked.
Another divergence is that for you action like 1^p preserves the type of the constant 1. Rather, in my implementation the result is always of what you call the inttype of the permutation. This is both for having this operation as fast as possible and for consistency. For example, the cycles of a Perm{UInt8} are Vector{UInt8}.
The sign function is usual, but not your parity function which could be
omitted. Similarly, for conjugating permutations, the notation a^bfor inv(b)ab is standard, but not overloading for the same purpose the function conj, which could be omitted.
You check that permutations can be hashed, which is indeed useful in order to be able to use them as keys in Dicts. I claim that they should also have an isless method, in order to be sortable (many algorithms are faster using sorting rather than hashing). Lexicographical order of image vectors does fine for isless.
I have much more to say but that's enough for now.

It seems to me that your AbstractPermutations is not a minimal compatibility package, but a much more extended one representing your idea of how to write permutations.

The intention is to create an interoperability package. For this I guess arithmetic, constructors and degree are necessary.
Parsing and IO are just things we all have written (for better or worse) so i thought it might be good to just put it in one common package. For the other functions

order is there so that we all inherit from the same function (in GroupsCore)
permtype and sign are there as they depend only on cycle decomposition (which is already defined for io)
action-related functions are so simple that it felt natural to include them here.

I consider the interface consisting of 3 methods pretty minimal. Do you have a proposal with even narrower set of methods to implement?

By the way, I reiterate my opposition to using the term degree for the largest moved point.

If you read the docstring of degree you'll notice it is not defined as the "largest moved point". It is the minimal n such that p can be regarded as an element of Sym(n) but not of Sym(n-1).

Exporting this name means in particular that you cannot load simultaneously this package and any package implementing polynomials.

Is it exported? As far as I understand, it is not and I don't intend to export it either.

My permutations would not pass your tests, and here are some details.
If I were to use degree for largest_moved_point, I would fail the test where you define the degree of the identity permutation to be 1. Why not 0?

Again, degree is not the largest moved point and since groups have to be non-empty as sets Sym(0) does not seem to be a well defined concept ;). So degree(id)==1 is perfectly consistent with both the docstring and the mathematics.
As written in the docstring, AbstractPermutations operate on a range 1:n
(This is also true for your PermGroups.Perms -- https://github.com/jmichel7/Perms.jl/blob/178dc75304d238901d0717c85d6caf8d7ab72c39/src/Perms.jl#L6). As far as I know 0 does not belong to 1:n so it makes little sense to me to return 0 as a largest moved point. A more appropriate would be to return the empty set, which is usually denoted by nothing in julia. Coincidentally firstmoved(id) does indeed return nothing, for mathematical consistency.
As a side note, according to your definition of action
https://github.com/jmichel7/Perms.jl/blob/main/src/Perms.jl#L412
0^p results in silent out-of-bounds garbage read which you may read as "moving" ;)
(that's of course a joke, but you should rather fix this).

The fact that for you cycles(identity)=[[1]] is perhaps a consequence but is inconsistent with the printing of identity as ().

cycles(id) == [[1]] is perfectly consistent with the definition of degree.
Strictly speaking indeed we should print (1). However you may recall from early pre-algebra classes that it is also customary to write the identity permutation as () ;)
Jokes aside, if this is a serious objection of yours, I'm willing to print (1) if all other objections have been resolved.

I suppose your firstmoved is my smallest_moved_point. Again it should be 0 and not 1 for the identity.

See my comment about above; 0 does not belong to 1:degree(p) and therefore nothing is returned as no points in the range are moved by id (and not 1 as you suggest :). smallest_moved_point makes sense only if the second argument to firstmoved is ordered. If you prefer to use smallest_moved_point in your code you can implement it using firstmoved trivially.
I believe that it makes sense to have a more general building blocks in the interface and let the other packages implement more specialized ones.

The fixedpoints and nfixedpoints seem to operate on 1:degree. This not very useful if you consider permutations in a permutation group of degree n. This is a case where the "implementation detail" of what is the actual length of the internal image vector would be a more pertinent parameter.

I come to conclusion that neither fixedpoints nor nfixedpoints should not have the default second argument as it relies on implicit datum (such as your n stored as a length of images vector). I will correct this soon. It is better to provide explicit ranges (or iterables) to those functions explicitly.
This is supposed to be an abstract interface without implementation details leaking in. No implicitly stored notion of parent group please ;)

My Perms do not pass the test where the constructor taking a Vector{Int} checks its argument for validity. For me this constructor is almost exclusively used when programming some code internal to the permutations package, and does not check in order to be fast. The most common constructor for the user is using the cycle decomposition like Perm(1,2,3)*Perm(4,5) or perm"(1,2,3)(4,5)". It is these last constructors which are checked.

You can write the constructor of your Perm to accept, yet ignore the second argument.
My usage is the opposite: users often define permutations of large objects and want to compute with the resulting (relatively small) permutation groups. Therefore they have neither cycle string available nor is tuple input a viable solution (degrees are often in thousands and more).
We seem to both agree that the validation of user imput is important.
Whenever a permutation is constructed from external data the input should be validated. If the input has already been validated (e.g. these are already constructed permutations), then the validation can be skipped. This is done here e.g. in arithmetic. We seem to agree here.
I believe the best place for doing validation is the default constructor (with a switch). This is where we seem to disagree, correct?

Another divergence is that for you action like 1^p preserves the type of the constant 1. Rather, in my implementation the result is always of what you call the inttype of the permutation. This is both for having this operation as fast as possible and for consistency.

Can you share any benchmarks confirming that this has any performance implications?
For type stability one branch will contain casting to some type anyway.
The rationale for this decision is mathematical.
A group action is a map F : G×Ω → Ω such that for every p ∈ G the restriction of F to {p}×Ω is a bijection (+some conditions).
Therefore if we start with x ∈ Ω, the result x^p must belong to Ω, rather than to some set defined by p.
Preserving the type of x seemed closer to the mathematical definition, especially that 256^one(Perm{UInt8}) should not throw but just return 256.

For example, the cycles of a Perm{UInt8} are Vector{UInt8}.

As far as I know cycles of the example implementation of Perm also should return vectors of UInt8:
julia> p = perm8"(1,2,3)(4,5)"
(1,2,3)(4,5)

julia> typeof(p)
Perm{UInt8}

julia> collect(AbstractPermutations.cycles(p))
2-element Vector{SubArray{UInt8, 1, Vector{UInt8}, Tuple{UnitRange{Int64}}, true}}:
 [0x01, 0x02, 0x03]
 [0x04, 0x05]

The sign function is usual, but not your parity function which could be omitted. Similarly, for conjugating permutations, the notation a^bfor inv(b)_a_b is standard, but not overloading for the same purpose the function conj, which could be omitted.

I have no hard feelings about neither parity or conj.

You check that permutations can be hashed, which is indeed useful in order to be able to use them as keys in Dicts. I claim that they should also have an isless method, in order to be sortable (many algorithms are faster using sorting rather than hashing). Lexicographical order of image vectors does fine for isless.

Please implement a prototype and open a pull request!

I have much more to say but that's enough for now.

Hopefully I addressed all your comments. If you have more please share.

And now the final joke:

If I were to use degree for largest_moved_point, I would fail the test where you define the degree of the identity permutation to be 1. Why not 0?
As a mathematician, I would have expected you to make a more consistent choice.

Do you even remember what you return "for consistency"?
https://github.com/jmichel7/Perms.jl/blob/178dc75304d238901d0717c85d6caf8d7ab72c39/src/Perms.jl#L351C67-L351C67
So much for the "mathematical consistency" ;)
As a mathematician writing code I would have expected you consulting your own code before rising objections :D
Jokes aside: please don't be offended, but also please don't waste my and your time on discussions "for discussions sake". Said that, Let's move to more productive dialogue.

As far as I know 0 does not belong to 1:n so it makes little sense to me to return 0 as a largest moved point. A more appropriate would be to return the empty set, which is usually denoted by nothing in julia. Coincidentally firstmoved(id) does indeed return nothing, for mathematical consistency.

I  would say that both 0 and  nothing are consistent choices, while 1 is not. Historically my functions smallest_moved_point and largest_moved_point  returned nothing for  the identity; I  found one day that  it was  convenient that  largest_moved_point returned  0 since it allowed  to find the  largest_moved_point of a list  l of permutations by maximum(largest_moved_point.(l)). I changed that day largest_moved_point and forgot to change the same day smallest_moved_point. Of course, the fact that these two functions do not do the same thing is a bug that I will fix.

Let's move on to more productive dialogue.

A productive dialogue is when both agree to move their position where they become closer. A point on which I would accept to move is renaming smallest_moved_point and largest_moved_point to firstmoved and lastmoved. They are more Julian names (well first_moved and last_moved would also be Julian). Note that if you change degreeto last_moved, you would recover a lost symmetry between your names.

Let me try to be concise. You commented on several points:

degree vs. largest_moved_point/lastmoved: Since your post above is the third in a row that mixes those two concepts, let me clarify for the third time:

degree(p) is the minimal n such that p can be regarded as an element of Sym(n) but not of Sym(n-1).
I would be grateful if you finally acknowledge that these are different concepts, or explain why do you still think they are the same.

I would say that both 0 and nothing are consistent choices, while 1 is not.

It is terrific, since neither your Perm nor AbstractPermutations return 1 for this case. AbstractPermutations return nothing and Perms used to do so. We can argue if returning 0 (outside of the domain) is really consistent, or is it just convenient (the argument with maximum(...)). The maximum(...) case is however a weak one, as there are much faster (and consistent) ways to write it...

Moreover
3. You raised an issue about naming conflicts, should degree be exported Solved (as it will not be exported)
4. There is still some discussion on whether to validate input in the default constructor. Ongoing (I'd appreciate your comment on what I wrote above)
5. nfixedpoints, fixedpoints (without the default second argument) are more general and no longer clash with your versions which use implicit parent permutation group Ongoing (Do we agree that these definitions don't clash with yours?).
6. typeof(i) == typeof(i^p). Since one conversion has to take place, I consider the example of 256^one(Perm{UInt8}) a strong argument for this solution. Ongoing (If you don't have benchmarks on this I'd prefer to have it Solved).
7. parity and conj can be removed Solved
9. I'm looking forward to your PR on isless! Ongoing
10. Both first_moved/firstmoved and last_moved/lastmoved are fine with me. If we decide for using underscores then [n]fixedpoints should also be renamed (and probably some  others?). Which one do you choose?
And of course we will be printing the identity as (1) when everything is resolved :)

It occurs to me that there is some general misunderstanding what an "interface" really is.
If you implement AbstractPermutation API it does NOT mean that you neither need to

rename any of your functions (e.g. smallest_moved_point), nor
change their semantics, nor
stop using them,
nor finally that you start using the API within your code!!!
Do you understand this?

What it means is that if a user passes your Perms to any external function that uses only the functions derived from the API is going to produce the expected result. That's it.
Therefore I don't understand your opposition to using some names/conventions that DON'T EVEN CLASH with your package.

It occurs to me that there is some general misunderstanding what an "interface" really is.

Well, your repository confuses me on this. There is nothing marked explicitly "AbstractPermutation API", so I looked at the files
src/abstract_perm.jl and abstract_perm_API.jl
thinking  they are the API.  Am I mistaken? It  is not clear if anything is exported  in  your  API.  I  repeat  that  there  should  be  somewhere  an explanation  of the rationale for the various  points of the design to make the  whole thing more convincing. The output of our discussions should help in principle toward that.

If you implement AbstractPermutation API it means that you neither need to
rename any of your functions (e.g. smallest_moved_point), nor
change their semantics, nor
stop using them,
nor finally that you start using the API within your code!!!
Do you understand this?

Yes,  I understand this. But I am only  willing to work with you if you are willing to consider me as an equal partner and not someone who has no right to  give his  opinions. It  should be  possible to  reach consensus on many points,  including the  conclusion that  no consensus  is possible  on some points.  For my part, I invented not much, I mainly am following the design of GAP3/GAP4 for permutations which has been carefully evolved over several years in the beginning of the 90's (not by me).
I discuss now only 2 points since I do not have time to wrtite more tonight.

degree(p) is the minimal n such that p can be regarded as an element of Sym(n) but not of Sym(n-1).
I would be grateful if you finally acknowledge that these are different concepts, or explain why do you still think they are the same.

Can you give me a permutation such that degree(p)!=lastmoved(p) ?
My main objection for degree is that it does not correspond to anything in the  literature or  on internet.  I did not find a notion of degree for individual permutations. There is  a notion of degree for permuation groups, but it does not have the same meaning: it is the cardinality of the set Ω  on which it  operates, but nothing  says that it  has to operate without fixed  points or that the largest integer moved would equal the cardinality of Ω.

Another divergence is that for you action like 1^p preserves the type of

the constant 1. Rather, in my implementation the result is always of what you call the inttype of the permutation. This is both for having this operation as fast as possible and for consistency.
The rationale for this decision is mathematical.
A group action is a map F : G×Ω → Ω such that for every p ∈ G the restriction of F to {p}×Ω is a bijection (+some conditions).
Therefore if we start with x ∈ Ω, the result x^p must belong to Ω, rather than to some set defined by p.
Preserving the type of x seemed closer to the mathematical definition, especially that 256^one(Perm{UInt8}) should not throw but just return 256.

Well,  the rationale  for my/GAP  design is  also mathematical:  I a view a Perm{T}  where  T<:Integer  operating  legitimately  only on sets whose elements  are of type  T. It can  operate on a  value i of type T_1 iff convert(T,i)  does not  error. The  result of  applying a Perm{T} is of course of type T.

Can you share any benchmarks confirming that this has any performance implications?  For type stability one branch will contain casting to some type anyway.

Well, most often I apply a Perm{T} to an integer of type T and there is no conversion. Not very informative, but here is a benchmark:
my Perms:
julia> p=Perm(Int16.(sortperm(rand(1:100,100))));@btime (1:100).^$p;
  92.214 ns (1 allocation: 256 bytes)

your Perms:
julia> p=Perm(Int16.(sortperm(rand(1:100,100))));@btime (1:100).^$p;
  107.326 ns (1 allocation: 896 bytes)

Not  much difference  but the  15% difference  seems to  persist over other
integer types and other sizes of permutations.

Here is a small GAP session
gap> G:=SymmetricGroup(0);
Group( () )
gap> Elements(G);
[ () ]
gap> p:=G.identity;
()
gap> LargestMovedPoint(p);
0
gap> NrMovedPoints(p);
0
gap> Cycles(p); # no cycles
[  ]

SymmetricGroup(0) appears in many places in the mathematics literature.  It is a limit case of an automorphism group
of structures where it makes sense that n can become 0.

Can you give me a permutation such that degree(p)!=lastmoved(p) ?

one(Perm). The first one is 1 in accordance to its definition; the second is undefined/null/fail/not_found as signified by customary nothing in julia.
I believe that GAP convention originates from the the times where functions had to return element of consistent type (so no nothing).

My main objection for degree is that it does not correspond to anything in the literature or on internet.

I hope you realize that is an argument for using it here, since

it won't clash with any of your (or anyone else) definitions,
we are free to define its semantics.

So far I see only opposition of yours, without a single constructive proposal; So let me propose something: how about mindegree (with the same semantics, I want AbstractPermutations be supported on 1:n).

At this point though I'm happy to agree that we disagree on what permutations should be and part our ways.

As for the benchmark: The size difference in allocations suggest that what you are looking at is difference in alloc:
julia> @btime UInt16.(1:100);
  67.981 ns (1 allocation: 256 bytes)

julia> @btime UInt.(1:100);
  89.092 ns (1 allocation: 896 bytes)

~30ns difference; Repeating what you did:
julia> @btime (1:100).^$(Ref(p1));
  75.319 ns (1 allocation: 256 bytes)

julia> @btime (1:100).^$(Ref(p2));
  101.171 ns (1 allocation: 896 bytes)

that is about the same.
And indeed the effect is gone if you write a non-allocating benchmark:
julia> f!(v, p) = (for i in eachindex(v); v[i] = i^p end; v);

julia> v = collect(1:100);

julia> @benchmark f!($v, $p1) # PermGroups.Perm
BenchmarkTools.Trial: 10000 samples with 983 evaluations.
 Range (min … max):  57.266 ns … 390.131 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     62.168 ns               ┊ GC (median):    0.00%
 Time  (mean ± σ):   63.761 ns ±   4.604 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

     ▄▁▃     ▁▆▅▆▄▇▆▇▄          ▁ ▅▆█▅▅    ▁                   ▂
  ▂▆████▆▇▆▆██████████▇█▆█▆█▆██▇████████▅▇▇█▅█▆████▆▆▂▆▄▆▆▆▅▅▅ █
  57.3 ns       Histogram: log(frequency) by time      73.3 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

julia> @benchmark f!($v, $p2) # perms_by_images.jl Perm
BenchmarkTools.Trial: 10000 samples with 984 evaluations.
 Range (min … max):  55.362 ns … 86.663 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     57.278 ns              ┊ GC (median):    0.00%
 Time  (mean ± σ):   57.627 ns ±  1.649 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

      ▂ ▃▅▄█▇▆▇▂▁  ▁  ▁         ▁                             ▂
  ▃▅▆▇████████████▅█▇████▆▆▅▅█▅▇█▇▆▅▆▇▃▆▇▆█▄▁▅▁▄▅▁▄▄▄▅▅▇▆▆▇▆▆ █
  55.4 ns      Histogram: log(frequency) by time      66.4 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

Inspecting the assembly of both functions it turns out that #perms_by_images.jl is actually shorter (and saves at least one jump since it doesn't throw!).

An interface is a minimal set of functions that once implemented correctly allow a much larger code-base to be build around.
The classical interface in julia is AbstractArray which is defined by

subtyping AbstractArray
defining size and
getindex.

Through these few functions many other functions are defined (only using the basic ones + some assumptions e.g. 1-based indexing). These come "for free" to the implementer who can just use them, or overload at will (maintaining the semantics).
This allows to run matrix-matrix products without writing one, but also e.g. an Arnoldi eigensolver which accepts not only Arrays, but also abstract LinearMaps.
MathOptInterface is a different (very elaborate) way of implementing an interface for a (convex) solver so that it can be used seamlessly from JuMP optimization framework.
In the same spirit AbstractPermutations.jl define a minimal (also 3 functions) interface which allows some very basic functionality (firstmoved, order, etc.) but other packages may implement more complex functions such as stabilizer chain computations, backtracking through the sc tree etc. that work for all implementation instances, regardless of implementation details.

If ones uses degree(σ) when needing an integer i such that i^σ != i then this is going to be followed by some code that assumes i is a natural number.
Suppose you use in that code an @inbounds statement because you know σ is not the identity unless you made a mistake.
In case you make a mistake, the inbounds will either result in a segmentation fault which is already quite annoying.
But it could also result in modifying an arbitrary memory which might result in heisenbug that takes hours to debug.
The advantage of nothing is that you will have a nice error with a nice stacktrace which makes is easy to trace down what happens.
Now, I can see that in some other use cases, the same code could just work with 0 so you don't have to make any exception while if it returned nothing, you have to replace this into 0 which can be annoying.
One solution could be to have one function for each use case:

degree would return 0 for the identity element
last_moved is the equivalent of first_moved but in the other direction. For consistency with first_moved, findfirst and findlast, it would return nothing for the identity element. From a readability point of view, from last_moved you would expect to receive a point that is actually moved so 0 feels odd.

By default, the interface could implement degree(σ) = something(last_moved(σ), 0) so that an implementation of permutations don't have to implement both.
What do you think of this, would that suit Chevie ?

The main problem for me is that the identity permutation id keeps behaving as in GAP. That is

cycles(id) is the empty list
id prints as ()  (not consistent since the cycles being empty it should print as the empty string, but this way of printing the identity is traditional)

In GAP there are no two different functions degree and last_moved, there is only the function LargestMovedPoint used everywhere. I really do not like degree since it evokes for me a different meaning, so I will keep using lastmoved (or last_moved?). Having last_moved(id) return nothing instead of 0 may cause errors in my transpiled data, but at least errors easy to find, and which can be fixed as you point out by writing something(last_moved(σ), 0).  But last_moved(id) being equal to 1 would be horrendous (just like the consequences drawn from degree(id)==1 in the current package).

While I am writing, a point I have not yet examined. There is a function called CycleType or CycleStructure which is
related to permtype in AbstractPermutations. But its use determine what it returns which is slightly different from the result of permtype:  cycletype(σ)  returns a partition describing the conjugacy class of σ, and this partition includes the 1s corresponding to trivial cycles. So to make sense this needs a second argument cycletype(σ,1:n) to specify the domain on which σ operates. Here it is useful that the second argument be an arbitrary AbstractVector and not only an integer. For instance, the Weyl group of type B_n has two orbits acting on the roots, and an invariant of a conjugacy class
is the union of the cycletypes on both orbit: you would use cycletype(σ,o_1) and cycletype(σ,o_2)  where o_1 and o_2 are the two orbits.

Yes, this package does not have to mimick GAP. But do you think it is unreasonable that the identity prints as () (I think it did at some stage). And that the identity does not have any (non-trivial) cycle?

I'm just talking about the degree here

You said above

degree would return 0 for the identity element

If that was the case I think I would be fine

Hey guys, I see you have a lot of fun discussing here ;)
@jmichel7 it would be best if you had stated at the beginning that you have 40k lines of GAP3-style code that you carry on your back. That means essentially that you will be unhappy with anything that is not GAP3-compatible because those 40k lines of code fix you in stone.
Since we want to follow julia conventions here (it's a julia package after all) and not just formalize Your GAP3 interface I suggest we settle this discussion and trod along our own paths. I see no need for them to be aligned.
Just to reiterate for future uses: you don't define degree and this package doesn't define largest_moved_point, so there is no technological issue with you adapting the interface.
But I accept that you reject it on ideological grounds and see no further gain to either of  us to continue this discussion.
In the future if users are confused about the incompatibility we can always direct them to read the discussion here.
See also #5.

I do not agree with your summary. I do not reject anything on ideological grounds. But I don't pass your tests.
Some like typeof(x^p)=typeof(x) I could modify my package to pass. But to have identity printed differently than () or
cycles(identity) not being the empty list I cannot modify.
I see that today PermutationGroups prints identity as (). So there is only left cycles(identity) that you decided on
ideological grounds to be (1) which cause a problem.

Thank you for informing about the pull request #5. I will bring my repository in conformity with typeof(i^p)=typeof(i) and
if nothing more changes my problems with the identity permutation are solved.
Then the last obstacle is my that my constructor does not check the input by default. I am not sure what to do about that. I certainly want that in all functions where I define arithmetic on permutations I do not have to write something as cumbersome as Perm(v;check=false)all over the place. For some other types I have an inner constructor like Perm_ which does not check. If I do that in this case  I will have to document and export this inner constructor so that users can use it.

I registered a new version 0.2.10 of my package where

I changed largest_moved_point to last_moved and smallest_moved_point to first_moved
I changed vec to perm
I changed ^ so that typeof(i^p)==typeof(i)
I changed some defaults so that no function in the API depends any more on the length of the internal vector
I did not yet change the default constructor to validate its input

I think you're moving too fast ;) the first version is not yet released!

I think vec (with its meaning) should stay in PermGroups and should not be replaced by perm! The latter is to create the most efficient representation as an AbstractPermutation for low level computations, not a vector. E.g. if you have permutations stored as products of cycles you may want to turn them into e.g. words over a generating set before the schreier_sims. That is what perm is intended to do.

For future: Probably a better definition in the future will be perm(::Function, p::AbstractPermutation) = perm(p) so that we can have the option of fine-grained control over different functions.

For future: As for ^ we might also consider turning this into typeof(i^p) == promotetype(typeof(i), AP.inttype(p)) if it ever creates an issue for us.

For future: We might discuss the validation for the next version (v0.2.0). We can also modify tests and just warn the user that this implementation doesn't validate the input, so should be uses with care.

I thought that perm made sense since the functions in julia dealing with permutations (sortperm, invperm, isperm) use the word perm and consider permutations as vectors of integers.
By the way, I don't have your fixedpoints, but I needed the complement, the moved points, which is traditionally called the support of the permutation.

authors: blegat jmichel7 kalmarek


text:
Serialize with Relationship

I use Relationship in Serialize.
Article Model:
@JsonApi(type = "articles")
public class Article extends Resource {
    public String title;
    public HasOne<Person> author;
}

Person Model:
@JsonApi(type = "people")
public class Person extends Resource {
    public String name;
}

Use Serialize:
Person people = new Person();
people.setId("2");
people.name = "Test2222";

Article article = new Article();
article.title = "Test111";
article.author = HasOne.create(article, people);

Document.of(article);

moshi.adapter(Article.class).toJson(article);

But my result is:
{"data":{"type":"articles","attributes":{"title":"Test111"},"relationships":{"people":{"data": "type": "people", id: "2"}}}}

people.name is not set!

Seems that it works well according to JSON API 1.0. relationships > people is a Resource Linkage not a Resource. BTW, JSON API 1.0 does not support the behavior to create a batch of resource with relationships between them.
And a workaround is to use moshi.adapter(Resource[].class).toJson(new Resource[] { article, people }); and have server support a client generated id. The idea is, add all resources needs to be created to document and use a client generated id to connect each other.

source: gharchive/issue

authors: kamikat mirmousaviii

repo: kamikat/moshi-jsonapi

license: mit

license_type: permissive

license_source: bigquery


text:
L1 Initialize() methods now return Status enum

This will make it easier in the future for drivers to return useful
information about the intialization state of the driver.
Resolves #439 .

Coverage increased (+0.03%) to 72.512% when pulling 817a3be0f916bc6fd4652cffa4038ad8bb25e894 on init-returns-status into 61edfa5854a961aeb287500335318dcfc5c3a1cb on v2.0-beta.

source: gharchive/pull-request

authors: coveralls kammce

license_source: github-api


text:
Add cdnJS install option to readme.md

Add cdnjs install option

Thank you for the PR, I have added unpkg

authors: MonsterDeveloper kamranahmedse

license: MIT


text:
The learning rate decreases after a specific epoch.

From approximately 2000 epoch, it is learned at a fast rate of 5 epoch per second based on RTX3070, and then suddenly the speed drops sharply. I'm train parallel-waveGAN, and I've modified some of the datasets and conf files to replace them with other languages. Starting with 2000 epoch, I start reading SSD like crazy instead of GPU resources. I waited for more than 6 hours, but only five epoch progressed.
Is this intended?
Thank you.
Below is the information about the setting file that I modified.
FILE : conf/parallel_wavegan.v3.yaml
###########################################################
#                FEATURE EXTRACTION SETTING               #
###########################################################
sampling_rate: 16000     # Sampling rate.
fft_size: 400           # FFT size.
hop_size: 160            # Hop size.
win_length: 400         # Window length.
                         # If set to null, it will be the same as fft_size.
window: "hann"           # Window function.
num_mels: 80             # Number of mel basis.
fmin: 80                 # Minimum freq in mel basis calculation.
fmax: 7600               # Maximum frequency in mel basis calculation.
global_gain_scale: 1.0   # Will be multiplied to all of waveform.
trim_silence: true       # Whether to trim the start and end of silence.
trim_threshold_in_db: 60 # Need to tune carefully if the recording is not good.
trim_frame_size: 2048    # Frame size in trimming.
trim_hop_size: 512       # Hop size in trimming.
format: "hdf5"           # Feature file format. "npy" or "hdf5" is supported.

###########################################################
#         GENERATOR NETWORK ARCHITECTURE SETTING          #
###########################################################
generator_params:
    in_channels: 1        # Number of input channels.
    out_channels: 1       # Number of output channels.
    kernel_size: 5        # Kernel size of dilated convolution.
    layers: 30            # Number of residual block layers.
    stacks: 3             # Number of stacks i.e., dilation cycles.
    residual_channels: 64 # Number of channels in residual conv.
    gate_channels: 128    # Number of channels in gated conv.
    skip_channels: 64     # Number of channels in skip conv.
    aux_channels: 80      # Number of channels for auxiliary feature conv.
                          # Must be the same as num_mels.
    aux_context_window: 2 # Context window size for auxiliary feature.
                          # If set to 2, previous 2 and future 2 frames will be considered.
    dropout: 0.0          # Dropout rate. 0.0 means no dropout applied.
    use_weight_norm: true # Whether to use weight norm.
                          # If set to true, it will be applied to all of the conv layers.
    upsample_net: "ConvInUpsampleNetwork" # Upsampling network architecture.
    upsample_params:                      # Upsampling network parameters.
        upsample_scales: [4, 4, 5, 2]     # Upsampling scales. Prodcut of these must be the same as hop size.

###########################################################
#       DISCRIMINATOR NETWORK ARCHITECTURE SETTING        #
###########################################################
discriminator_type: "MelGANMultiScaleDiscriminator" # Discriminator type.
discriminator_params:
    in_channels: 1                    # Number of input channels.
    out_channels: 1                   # Number of output channels.
    scales: 3                         # Number of multi-scales.
    downsample_pooling: "AvgPool1d"   # Pooling type for the input downsampling.
    downsample_pooling_params:        # Parameters of the above pooling function.
        kernel_size: 4
        stride: 2
        padding: 1
        count_include_pad: False
    kernel_sizes: [5, 3]              # List of kernel size.
    channels: 16                      # Number of channels of the initial conv layer.
    max_downsample_channels: 1024     # Maximum number of channels of downsampling layers.
    downsample_scales: [4, 4, 4, 4]   # List of downsampling scales.
    nonlinear_activation: "LeakyReLU" # Nonlinear activation function.
    nonlinear_activation_params:      # Parameters of nonlinear activation function.
        negative_slope: 0.2
    use_weight_norm: True             # Whether to use weight norm.

###########################################################
#                   STFT LOSS SETTING                     #
###########################################################
stft_loss_params:
    fft_sizes: [1024, 2048, 512]  # List of FFT size for STFT-based loss.
    hop_sizes: [120, 240, 50]     # List of hop size for STFT-based loss
    win_lengths: [600, 1200, 240] # List of window length for STFT-based loss.
    window: "hann_window"         # Window function for STFT-based loss

###########################################################
#               ADVERSARIAL LOSS SETTING                  #
###########################################################
use_feat_match_loss: true # Whether to use feature matching loss.
lambda_feat_match: 25.0   # Loss balancing coefficient for feature matching loss.
lambda_adv: 4.0          # Loss balancing coefficient for adversarial loss.

###########################################################
#                  DATA LOADER SETTING                    #
###########################################################
batch_size: 8             # Batch size.
batch_max_steps: 8192      # Length of each audio in batch. Make sure dividable by hop_size.
pin_memory: true           # Whether to pin memory in Pytorch DataLoader.
num_workers: 2             # Number of workers in Pytorch DataLoader.
remove_short_samples: true # Whether to remove samples the length of which are less than batch_max_steps.
allow_cache: true          # Whether to allow cache in dataset. If true, it requires cpu memory.

###########################################################
#             OPTIMIZER & SCHEDULER SETTING               #
###########################################################
generator_optimizer_params:
    lr: 0.0001             # Generator's learning rate.
    eps: 1.0e-6            # Generator's epsilon.
    weight_decay: 0.0      # Generator's weight decay coefficient.
generator_scheduler_params:
    step_size: 3000000     # Generator's scheduler step size.
    gamma: 0.5             # Generator's scheduler gamma.
                           # At each step size, lr will be multiplied by this parameter.
generator_grad_norm: 10    # Generator's gradient norm.
discriminator_optimizer_params:
    lr: 0.00005            # Discriminator's learning rate.
    eps: 1.0e-6            # Discriminator's epsilon.
    weight_decay: 0.0      # Discriminator's weight decay coefficient.
discriminator_scheduler_params:
    step_size: 3000000     # Discriminator's scheduler step size.
    gamma: 0.5             # Discriminator's scheduler gamma.
                           # At each step size, lr will be multiplied by this parameter.
discriminator_grad_norm: 1 # Discriminator's gradient norm.

###########################################################
#                    INTERVAL SETTING                     #
###########################################################
discriminator_train_start_steps: 100000 # Number of steps to start to train discriminator.
train_max_steps: 3000000                # Number of training steps.
save_interval_steps: 5000               # Interval steps to save checkpoint.
eval_interval_steps: 1000               # Interval steps to evaluate the network.
log_interval_steps: 100                 # Interval steps to record the training log.

###########################################################
#                     OTHER SETTING                       #
###########################################################
num_save_intermediate_results: 4  # Number of results to be saved as intermediate results.

FILE : train.log
[train]:   0%|          | 1974/3000000 [08:35<218:49:50,  3.81it/s]
[train]:   0%|          | 1975/3000000 [08:35<217:33:15,  3.83it/s]
[train]:   0%|          | 1976/3000000 [08:35<215:58:02,  3.86it/s]
[train]:   0%|          | 1977/3000000 [08:35<212:03:47,  3.93it/s]
[train]:   0%|          | 1978/3000000 [08:36<206:58:43,  4.02it/s]
[train]:   0%|          | 1979/3000000 [08:36<206:36:10,  4.03it/s]
[train]:   0%|          | 1980/3000000 [08:36<203:47:04,  4.09it/s]
[train]:   0%|          | 1981/3000000 [08:36<202:49:16,  4.11it/s]
[train]:   0%|          | 1982/3000000 [08:37<201:48:36,  4.13it/s]
[train]:   0%|          | 1983/3000000 [08:37<204:30:29,  4.07it/s]
[train]:   0%|          | 1984/3000000 [08:37<214:55:21,  3.87it/s]
[train]:   0%|          | 1985/3000000 [08:37<215:13:26,  3.87it/s]
[train]:   0%|          | 1986/3000000 [08:38<212:16:55,  3.92it/s]
[train]:   0%|          | 1987/3000000 [08:38<213:19:01,  3.90it/s]
[train]:   0%|          | 1988/3000000 [08:38<213:14:45,  3.91it/s]
[train]:   0%|          | 1989/3000000 [08:38<219:15:55,  3.80it/s]
[train]:   0%|          | 1990/3000000 [08:39<222:03:54,  3.75it/s]
[train]:   0%|          | 1991/3000000 [08:39<215:29:35,  3.86it/s]
[train]:   0%|          | 1992/3000000 [08:39<214:56:20,  3.87it/s]
[train]:   0%|          | 1993/3000000 [08:39<217:19:08,  3.83it/s]
[train]:   0%|          | 1994/3000000 [08:40<213:44:15,  3.90it/s]
[train]:   0%|          | 1995/3000000 [08:40<217:45:49,  3.82it/s]
[train]:   0%|          | 1996/3000000 [08:40<211:25:31,  3.94it/s]
[train]:   0%|          | 1997/3000000 [08:41<213:41:09,  3.90it/s]
[train]:   0%|          | 1998/3000000 [08:41<220:40:00,  3.77it/s]
[train]:   0%|          | 1999/3000000 [08:41<213:48:09,  3.90it/s]
[train]:   0%|          | 2000/3000000 [08:41<207:16:31,  4.02it/s]2024-03-01 20:19:54,678 (train:633) INFO: (Steps: 2000) train/spectral_convergence_loss = 0.8977.
2024-03-01 20:19:54,678 (train:633) INFO: (Steps: 2000) train/log_stft_magnitude_loss = 1.1274.
2024-03-01 20:19:54,678 (train:633) INFO: (Steps: 2000) train/generator_loss = 2.0250.
2024-03-01 20:19:54,691 (train:471) INFO: (Steps: 2000) Start evaluation.

[eval]:   0%|          | 0/63 [00:00<?, ?it/s]

[eval]:   2%|▏         | 1/63 [00:01<01:23,  1.35s/it]

[eval]:   3%|▎         | 2/63 [00:01<00:39,  1.56it/s]

[eval]:   6%|▋         | 4/63 [00:01<00:17,  3.39it/s]

[eval]:  10%|▉         | 6/63 [00:01<00:11,  5.04it/s]

[eval]:  11%|█         | 7/63 [00:01<00:09,  5.70it/s]

[eval]:  14%|█▍        | 9/63 [00:02<00:07,  7.04it/s]

[eval]:  17%|█▋        | 11/63 [00:02<00:06,  8.11it/s]

[eval]:  21%|██        | 13/63 [00:02<00:05,  8.76it/s]

[eval]:  24%|██▍       | 15/63 [00:02<00:05,  9.36it/s]

[eval]:  27%|██▋       | 17/63 [00:02<00:04,  9.80it/s]

[eval]:  30%|███       | 19/63 [00:03<00:04, 10.12it/s]

[eval]:  33%|███▎      | 21/63 [00:03<00:04, 10.38it/s]

[eval]:  37%|███▋      | 23/63 [00:03<00:03, 10.38it/s]

[eval]:  40%|███▉      | 25/63 [00:03<00:03, 10.59it/s]

[eval]:  43%|████▎     | 27/63 [00:03<00:03, 10.71it/s]

[eval]:  46%|████▌     | 29/63 [00:03<00:03, 10.85it/s]

[eval]:  49%|████▉     | 31/63 [00:04<00:02, 10.88it/s]

[eval]:  52%|█████▏    | 33/63 [00:04<00:02, 10.85it/s]

[eval]:  56%|█████▌    | 35/63 [00:04<00:02, 10.78it/s]

[eval]:  59%|█████▊    | 37/63 [00:04<00:02, 10.85it/s]

[eval]:  62%|██████▏   | 39/63 [00:04<00:02, 10.92it/s]

[eval]:  65%|██████▌   | 41/63 [00:05<00:02, 10.69it/s]

[eval]:  68%|██████▊   | 43/63 [00:05<00:01, 10.71it/s]

[eval]:  71%|███████▏  | 45/63 [00:05<00:01, 10.82it/s]

[eval]:  75%|███████▍  | 47/63 [00:05<00:01, 10.81it/s]

[eval]:  78%|███████▊  | 49/63 [00:05<00:01, 10.88it/s]

[eval]:  81%|████████  | 51/63 [00:06<00:01, 10.80it/s]

[eval]:  84%|████████▍ | 53/63 [00:06<00:00, 10.81it/s]

[eval]:  87%|████████▋ | 55/63 [00:06<00:00, 10.45it/s]

[eval]:  90%|█████████ | 57/63 [00:06<00:00, 10.39it/s]

[eval]:  94%|█████████▎| 59/63 [00:06<00:00,  9.87it/s]

[eval]:  95%|█████████▌| 60/63 [00:06<00:00,  9.88it/s]

[eval]:  97%|█████████▋| 61/63 [00:07<00:00,  9.80it/s]

[eval]: 100%|██████████| 63/63 [00:07<00:00, 10.21it/s]
[eval]: 100%|██████████| 63/63 [00:07<00:00,  8.59it/s]2024-03-01 20:20:02,036 (train:487) INFO: (Steps: 2000) Finished evaluation (63 steps per epoch).
2024-03-01 20:20:02,036 (train:495) INFO: (Steps: 2000) eval/spectral_convergence_loss = 0.8968.
2024-03-01 20:20:02,036 (train:495) INFO: (Steps: 2000) eval/log_stft_magnitude_loss = 1.0782.
2024-03-01 20:20:02,036 (train:495) INFO: (Steps: 2000) eval/feature_matching_loss = 0.0003.
2024-03-01 20:20:02,036 (train:495) INFO: (Steps: 2000) eval/adversarial_loss = 0.9558.
2024-03-01 20:20:02,036 (train:495) INFO: (Steps: 2000) eval/generator_loss = 5.8318.
2024-03-01 20:20:02,036 (train:495) INFO: (Steps: 2000) eval/real_loss = 0.9558.
2024-03-01 20:20:02,036 (train:495) INFO: (Steps: 2000) eval/fake_loss = 0.0016.
2024-03-01 20:20:02,036 (train:495) INFO: (Steps: 2000) eval/discriminator_loss = 0.9574.

[train]:   0%|          | 2001/3000000 [08:49<2045:52:46,  2.46s/it]
[train]:   0%|          | 2002/3000000 [08:49<1492:52:09,  1.79s/it]
[train]:   0%|          | 2003/3000000 [08:49<1104:55:45,  1.33s/it]
[train]:   0%|          | 2004/3000000 [08:50<841:28:14,  1.01s/it]
[train]:   0%|          | 2005/3000000 [08:50<659:00:50,  1.26it/s]
[train]:   0%|          | 2006/3000000 [08:50<529:23:03,  1.57it/s]
[train]:   0%|          | 2007/3000000 [08:50<430:39:02,  1.93it/s]
[train]:   0%|          | 2008/3000000 [08:51<360:29:24,  2.31it/s]
[train]:   0%|          | 2009/3000000 [08:51<310:20:24,  2.68it/s]
[train]:   0%|          | 2010/3000000 [08:51<277:53:02,  3.00it/s]
[train]:   0%|          | 2011/3000000 [08:51<257:15:52,  3.24it/s]
[train]:   0%|          | 2012/3000000 [08:52<238:30:17,  3.49it/s]
[train]:   0%|          | 2013/3000000 [08:52<225:34:05,  3.69it/s]
[train]:   0%|          | 2014/3000000 [08:52<217:15:40,  3.83it/s]
[train]:   0%|          | 2015/3000000 [08:52<211:46:30,  3.93it/s]
[train]:   0%|          | 2016/3000000 [08:53<212:33:52,  3.92it/s]
[train]:   0%|          | 2017/3000000 [08:53<212:50:07,  3.91it/s]
[train]:   0%|          | 2018/3000000 [08:53<210:23:27,  3.96it/s]
[train]:   0%|          | 2019/3000000 [08:53<205:40:27,  4.05it/s]
[train]:   0%|          | 2020/3000000 [08:54<211:00:50,  3.95it/s]
[train]:   0%|          | 2021/3000000 [08:54<215:25:32,  3.87it/s]
[train]:   0%|          | 2022/3000000 [08:54<209:48:52,  3.97it/s]
[train]:   0%|          | 2023/3000000 [08:54<216:37:54,  3.84it/s]
[train]:   0%|          | 2024/3000000 [08:55<215:56:18,  3.86it/s]
[train]:   0%|          | 2025/3000000 [08:55<209:49:27,  3.97it/s]
[train]:   0%|          | 2026/3000000 [08:55<209:03:39,  3.98it/s]
[train]:   0%|          | 2027/3000000 [08:55<206:11:32,  4.04it/s]
[train]:   0%|          | 2028/3000000 [08:56<208:34:06,  3.99it/s]
[train]:   0%|          | 2029/3000000 [08:56<205:30:16,  4.05it/s]
[train]:   0%|          | 2030/3000000 [08:56<203:14:31,  4.10it/s]
[train]:   0%|          | 2031/3000000 [08:56<202:01:14,  4.12it/s]
[train]:   0%|          | 2032/3000000 [08:57<199:07:56,  4.18it/s]
[train]:   0%|          | 2033/3000000 [08:57<196:14:00,  4.24it/s]
[train]:   0%|          | 2034/3000000 [08:57<194:46:42,  4.28it/s]
[train]:   0%|          | 2035/3000000 [08:57<195:26:53,  4.26it/s]
[train]:   0%|          | 2036/3000000 [08:57<195:11:52,  4.27it/s]
[train]:   0%|          | 2037/3000000 [08:58<194:58:45,  4.27it/s]
[train]:   0%|          | 2038/3000000 [08:58<199:45:30,  4.17it/s]
[train]:   0%|          | 2039/3000000 [08:58<197:02:17,  4.23it/s]
[train]:   0%|          | 2040/3000000 [08:58<195:42:53,  4.25it/s]
[train]:   0%|          | 2041/3000000 [08:59<194:21:01,  4.28it/s]
[train]:   0%|          | 2042/3000000 [08:59<198:10:37,  4.20it/s]
[train]:   0%|          | 2043/3000000 [08:59<201:18:58,  4.14it/s]
[train]:   0%|          | 2044/3000000 [08:59<201:10:17,  4.14it/s]
[train]:   0%|          | 2045/3000000 [09:00<220:58:42,  3.77it/s]  # Start of the problem section.
[train]:   0%|          | 2046/3000000 [09:02<681:41:20,  1.22it/s]
[train]:   0%|          | 2047/3000000 [09:10<2471:23:38,  2.97s/it]
[train]:   0%|          | 2048/3000000 [10:51<27101:07:28, 32.54s/it]
[train]:   0%|          | 2049/3000000 [13:04<52114:33:59, 62.58s/it]2024-03-01 20:32:22,966 (train:1546) INFO: Successfully saved checkpoint @ 2049steps.
Traceback (most recent call last):
  File "/home/EVDA/Vocoder/ParallelWaveGAN/tools/venv/bin/parallel-wavegan-train", line 33, in <module>
    sys.exit(load_entry_point('parallel-wavegan', 'console_scripts', 'parallel-wavegan-train')())
  File "/home/EVDA/Vocoder/ParallelWaveGAN/parallel_wavegan/bin/train.py", line 1541, in main
    trainer.run()
  File "/home/EVDA/Vocoder/ParallelWaveGAN/parallel_wavegan/bin/train.py", line 105, in run
    self._train_epoch()
  File "/home/EVDA/Vocoder/ParallelWaveGAN/parallel_wavegan/bin/train.py", line 346, in _train_epoch
    self._train_step(batch)
  File "/home/EVDA/Vocoder/ParallelWaveGAN/parallel_wavegan/bin/train.py", line 288, in _train_step
    gen_loss.backward()
  File "/home/EVDA/Vocoder/ParallelWaveGAN/tools/venv/lib/python3.8/site-packages/torch/_tensor.py", line 396, in backward
    torch.autograd.backward(self, gradient, retain_graph, create_graph, inputs=inputs)
  File "/home/EVDA/Vocoder/ParallelWaveGAN/tools/venv/lib/python3.8/site-packages/torch/autograd/__init__.py", line 173, in backward
    Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
KeyboardInterrupt

[train]:   0%|          | 2049/3000000 [21:11<516:45:57,  1.61it/s]

Since then, I have been waiting for more than 6 hours, but only 5 epoch progressed.

This is not intended.
Did you check CPU memory usage?
In the config, allow_cache: true will store all data in CPU memory.
Therefore, if the CPU memory is full, the cache will be something problem (e.g., using too much swap instead cpu memory).

I think what you are concerned about is correct.
It is currently operating normally.
Resolved by significantly increasing the virtual memory swap size.
Thank you for your response.

repo: kan-bayashi/ParallelWaveGAN


text:
VFS Inodes

Initial commit for header file for the inodes for the virtual filesystem

Reformatting means changing comment styling (I don't use C++ comments like at all :trollface:) and some whitespaces annoy me a little...

repo: kan-os/kan


text:
Practice Exam 4 Question 37

The correct answer should be A

Using AWS CloudFormation to manage infrastructure as code can help with automation and operational efficiency, which aligns with the Operational Excellence pillar.


text:
Request: See command of task.

I know the whole point of the browser is to not have to deal with the command line but would it be possible to add a button or tab on a task that shows the final command that is sent to rclone? Might help with troubleshooting etc.

This is actually very useful and I use it a lot - as it is already implemented.
Running jobs have “copy rclone command to clipboard” button. Next to cancel one.

On 15 Apr 2020, at 08:52, AplhaSlayer1964 notifications@github.com wrote:

I know the whole point of the browser is to not have to deal with the command line but would it be possible to add a button or tab on a task that shows the final command that is sent to rclone? Might help with troubleshooting etc.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

woops didn't realize it was already implemented! Thanks for letting me know.

It still would be nice to have that feature added to the task list - so I don't have to run the job to know how the command line should look.
Use case: I love the UI to configure tasks. Often I want to have tasks recurring automatically in a cron-job or sth.
My current workaround is:

Create task in RcloneBrowser
Dry run the task
Copy the task command line from the job
Use the command line in a job scheduler.
Optional: delete the task configuration

Another alternative is to have a command line to run tasks, such as rclone-browser run-task my-task-name, which may even work without a UI (so I can actually run it from a cron-job). This would be super useful as I could maintain my rclone scripts in a nice GUI and edit them as needed.

I have added it already in the upcoming release.
It will also have scheduler + option to start RB minimized to system tray... so you will be able to achieve everything without any extra tools.
Would you like to test beta version? If yes let me know what OS you are on and I will do beta release.

@kapitainsky - I would love to test a beta version. I'm running Ubuntu 20.04, and I can also build from git - I've tried rebuilding master and kptsky_experimenting but didn't see any changes from the Ubuntu 1.8.0 release.

https://1drv.ms/u/s!Aq335pidOrBV4IJKtjw8gMzslz_aHQ
contains queueing and scheduler

if you would like newer version compile from kptsky_testing
In general testing branch contains working code, experimenting is my experiments:) - i might not compile or even break things - not recommended. When I am happy that code is working I merge it to testing - then when really happy to main and do release.

I checked the beta version - looks very good.
Notes:

I didn't see an option to copy the rclone command line for the task (not the job).
The new queue and scheduler look like very useful features that a lot of users would enjoy - though for myself I would have liked to be able to schedule jobs without relying on a GUI application running: I would very much like to be able to execute rclone-browser tasks from the command line without a UI, and handle the scheduling myself using facilities already integrated into the operating system, such as SystemD timers.

1. I didn't see an option to copy the rclone command line for the task (not the job).

Still in experimenting. I thought that it will be trivial but turned to require changes in few classes - will be ready in few days - will send you a link with updated beta when I move it to testing.

2. The new queue and scheduler look like very useful features that a lot of users would enjoy - though for myself I would have liked to be able to schedule jobs without relying on a GUI application running: I would very much like to be able to execute rclone-browser tasks from the command line without a UI, and handle the scheduling myself using facilities already integrated into the operating system, such as SystemD timers.

Fully understand - everybody uses it in different way. I have some thoughts about cmd API in the future - but not soon. Now want to finish few more things - especially working on multiselection in remotes - so you could down/upload multiple items in one go. I have limited time and have to prioritise:)

repo: kapitainsky/RcloneBrowser


text:
Swift 2.1 Update

Note* - Quick Select is not working due to the following error:
swapping a location with itself is not supported
Looked into this briefly but couldn't see a quick workaround. The following link seems promising
http://stackoverflow.com/questions/24026510/how-do-i-shuffle-an-array-in-swift

Also took a stab at implementing this for Swift 2.1from  the implementation here both as a generic and as a function: http://rosettacode.org/wiki/Quickselect_algorithm?section=35#Swift
func quickSelect<T where T : Comparable>(var elements: [T], n: Int) -> T {
  var r = elements.indices
  while true {
    let pivotIndex = elements.partition(r)
    if n == pivotIndex {
      return elements[pivotIndex]
    } else if n < pivotIndex {
      r.endIndex = pivotIndex
    } else {
      r.startIndex = pivotIndex+1
    }
  }
}

func quickSelect(n: Int, var arr: [Int]) -> Int {
  var r = arr.indices
  while true {
    let pivotIndex = arr.partition(r)
    if n == pivotIndex {
      return arr[pivotIndex]
    } else if n < pivotIndex {
      r.endIndex = pivotIndex
    } else {
      r.startIndex = pivotIndex + 1
    }
  }
}

for i in 0 ..< 10 {
  let a = [9, 8, 7, 6, 5, 0, 1, 2, 3, 4]
  print("\(quickSelect(i, arr: a))", terminator: "")
  if i < 9 { print(", ", terminator: "") } else { print("") }
}

However the output I'm getting is not correct:
/* Begin Program */
var n: Int
var element: Int
var randomNumbers = [9, -1, 8, 2, 4, 100, -9, 0, 2, 5, 55, 13,74, 3]

n = 3
element = quickSelect(n, arr: randomNumbers)
print("The nth element, (n = \(n)) is: \(element)")

randomNumbers = [9, -1, 8, 2, 4, 100, -9, 0, 2, 5, 55, 13,74, 3]
n = 0
element = quickSelect(n, arr: randomNumbers)
print("The nth element, (n = \(n)) is: \(element)")

randomNumbers = [9, -1, 8, 2, 4, 100, -9, 0, 2, 5, 55, 13,74, 3]
n = 5
element = quickSelect(n, arr: randomNumbers)
print("The nth element, (n = \(n)) is: \(element)")

randomNumbers = [9, -1, 8, 2, 4, 100, -9, 0, 2, 5, 55, 13,74, 3]
n = randomNumbers.count - 1
element = quickSelect(n, arr: randomNumbers)
print("The nth element, (n = \(n)) is: \(element)")

0, 1, 2, 3, 4, 5, 6, 7, 8, 9
The nth element, (n = 3) is: 2
The nth element, (n = 0) is: -9
The nth element, (n = 5) is: 3
The nth element, (n = 13) is: 100

repo: karan/Swift-Algorithms


text:
can fetch but not sync dependency

see error & vendor.json here https://gist.github.com/tejasmanohar/19f14e0cf00c4bc20334ef26d8ebf215
I can govendor fetch testify without cache but can never get govendor sync to like it. Is it due to how they've committed their dependencies? Is this a bug in govendor?

I suspect it is from a bug in a previous version of govendor. Please try to remove and re-add the testify/... packages.

you're right

authors: kardianos tejasmanohar

repo: kardianos/govendor


text:
smscalls: add config block

so that don't have to infer what
to set in your hpi config based
on usage in module

Thanks!

authors: karlicoss seanbreckenridge

repo: karlicoss/HPI


text:
Websocket align fix

here is the error from before the second commit
tmp/http.zig $ zig build test
.....warning: httpz: unhandled exception for request: /fail
Err: error.TestUnhandledError
..............expected 12, found 2

================================================================================
"websocket: upgrade" - TestExpectedEqual
================================================================================
/media/travis/data/Users/Travis/Documents/Code/zig/zig/download/0.12.0-dev.2540+776cd673f/files/lib/std/testing.zig:93:17: 0x10ca11b in expectEqualInner__anon_6808 (test)
                return error.TestExpectedEqual;
                ^
/tmp/http.zig/src/t.zig:12:5: 0x10ca18b in expectEqual__anon_6807 (test)
    try std.testing.expectEqual(@as(@TypeOf(actual), expected), actual);
    ^
/tmp/http.zig/src/httpz.zig:933:5: 0x10caa7c in test.websocket: upgrade (test)
    try t.expectEqual(12, n);
    ^
.............................................................
79 of 80 tests passed

Slowest 5 tests:
  2962.55ms	httpz: router groups
  5203.85ms	httpz: writer re-use
  18999.85ms	response: write header_buffer_size
  26879.47ms	response: writer fuzz
  90680.77ms	response: json fuzz

test
└─ run test failure
error: the following command exited with error code 1:
/tmp/http.zig/zig-cache/o/cdf9fc59df35d7fc512a291787abaa57/test
Build Summary: 1/3 steps succeeded; 1 failed (disable with --summary none)
test transitive failure
└─ run test failure
error: the following build command failed with exit code 1:
/tmp/http.zig/zig-cache/o/8376579579775ee1e93265025a03788b/build /media/travis/data/Users/Travis/Documents/Code/zig/zig/download/0.12.0-dev.2540+776cd673f/files/zig /tmp/http.zig /tmp/http.zig/zig-cache /home/travis/.cache/zig --seed 0x1d7a71c6 test

here is the panic from before either of these commits:
/tmp/http.zig $ zig build test
...thread 430645 panic: incorrect alignment

====== expected this output: =========
HTTP/1.1 404
Content-Length: 9

Not Found␃

======== instead found this: =========
␃

======================================
First difference occurs on line 1:
expected:
HTTP/1.1 404
^ ('\x48')
found:

^ (end of string)

================================================================================
"httpz: no route" - TestExpectedEqual
================================================================================
/tmp/http.zig/src/worker.zig:238:61: 0x14a220d in processSignal (test)
                const conn: *Conn = @ptrFromInt(@as(*usize, @alignCast(@ptrCast(buf[data_start..data_end]))).*);
                                                            ^
/tmp/http.zig/src/worker.zig:132:47: 0x14118fa in run (test)
                        if (self.processSignal(signal)) {
                                              ^
/media/travis/data/Users/Travis/Documents/Code/zig/zig/download/0.12.0-dev.2540+776cd673f/files/lib/std/Thread.zig:411:13: 0x1385083 in callFn__anon_59407 (test)
            @call(.auto, f, args);
            ^
/media/travis/data/Users/Travis/Documents/Code/zig/zig/download/0.12.0-dev.2540+776cd673f/files/lib/std/Thread.zig:679:30: 0x12f26a2 in entryFn (test)
                return callFn(f, args_ptr.*);
                             ^
./nptl/pthread_create.c:442:8: 0x784f86494ac2 in start_thread (pthread_create.c)


text:
Uncaught SyntaxError: Unexpected token export

Expected behaviour
Run a test with es6
Actual behaviour
Getting  Uncaught SyntaxError: Unexpected token export
Environment Details

Karma version: 1.5.0

    preprocessors: {
      '../client/**/*.js': ['babel'],
      'unit/*.js': ['babel']
    },
    babelPreprocessor: {
      options: {
        presets: ['es2015'],
        plugins: ['transform-es2015-modules-umd'],
        sourceMap: 'inline'
      },
      filename: function (file) {
        return file.originalPath.replace(/\.js$/, '.es5.js');
      },
      sourceFileName: function (file) {
        return file.originalPath;
      }
    },

babel-core: "^6.24.0"
node: v7.4.0

@Hosar karma-babel-preprocessor is better place for this issue because I think the problem in babel setup.
Thanks

Ok got it, I'll check on that. Thank you

@Hosar Did you solve the problem?

No feedback in 8 months; closing.

authors: EzraBrooks Hosar maksimr

repo: karma-runner/karma


text:
Better documentation for the plugin API

Hey all, I am writing Suman, which is a test harness like Mocha and Jasmine, but much improved, especially for backend testing. I am looking to run Suman tests in the browser. I am almost there, but I want the Suman test harness to work with Karma. Note that Suman does not use global variables, so I am hoping that Suman can call the Karma API, not the other way around.
I posted this question on SO:
https://stackoverflow.com/questions/46868214/how-do-i-make-a-karma-compliant-test-harness-for-the-browser

My guess is that the Karma test runner does not hook in Mocha and Jasmine, rather the reverse.
so I assume Mocha and Jasmine call something like this:
window.__karma__.testCasePassed(data);
window.__karma__.testCaseFailed(data);
and then Karma will report these events.
I am writing Suman and I want to figure out if I can make Suman Karma compliant.
When I look through the Mocha and Jasmine codebase however, I am not seeing the evidence I am looking for.

My question is - does Karma have some documentation as to how to hook into Karma? I am hoping that Karma has an API that I can call. It would be to my dismay if Karma hooks into Mocha and Jasmine's globals, instead of Mocha and Jasmine calling Karma directly.

I see this:
https://developers.soundcloud.com/blog/writing-your-own-karma-adapter
but it's from 2013, is there something more up-to-date?

Ok it looks like I should follow the examples here:
https://github.com/karma-runner/karma-jasmine
https://github.com/karma-runner/karma-mocha
and I should create:
https://github.com/karma-runner/karma-suman
is that about right? Any advice?

Yes follow the examples.  Advice: think about karma as an orchestrator and transport for a nodejs to browser system. The job of your adapter is to fire the tests and pass the results through the karma callbacks to the reporters. So the interface to karma-runner is very minimal. The test framework and the reporters are more complex that karma.

@johnjbarton thanks, just one question for you
I am looking for more complete documentation on the karma API
https://karma-runner.github.io/1.0/dev/plugins.html
if you look at that link, it only lists the API for the result() call, but I really could use more info on the exact API for the complete(), error() and info() calls.

.complete the client completed execution of all the tests
.error an error happened in the client
.info other data (e.g. number of tests or debugging messages)

AFAIK there is no more information on this API.  The API is not "exact".  Broadly the calls are sent from your framework plugin to a reporter plugin. karma-runner does not care very much what those two ends talk about.  It just not karma-runners business, so does not get involved.
There are some constraints.  For example info info.total should not be null:
https://github.com/karma-runner/karma/blob/de55bc63205c656eb5f5534894aa4ae92228efb8/lib/browser.js#L129
But for the most part the API that matters is the reporter plugin API.
Which of course is also not documented.  I would look at the dots reporter and get your framework to work with it.  Then pick up the reporter you expect your users to use.
I guess the result API is more like
var oneTestResult = {
                description: test.name,
                log: errMsgs,
                skipped: false,
                pending: false,
                success: errMsgs.length === 0,
                suite: [],
                time: test.getElapsedTime()
            };

ahh ok good idea, I will look at the dots reporter

@johnjbarton so once I get karma-suman closer to a production-ready state, is there some test suite I can use to verify the implementation behaves properly? Do you know if there are some good pre-existing tests that I can use to test karma-suman, the way that karma-mocha, karma-jasmine are tested? Thanks.

@ORESoftware I wouldn't expect so: unit test would just involve your karma-suman files and e2e tests would involve passing a suman file to karma in a config and verifying the reporter or log output.  You should be able to find a e2e test to use a a template.

authors: ORESoftware johnjbarton


text:
WARN [launcher]: Launcher "Script" is not registered! karma@canary (v0.9.1)

What is the proper way to make browser scripts work again with karma@canary?
Tried to add karma-script-launcher as a plugin, but it looks like the module does not exists yet.
Thanks.

Karma was actually using karma-chrome-launcher for me. I had to look this module up on Github and the docs showed how to add "Chrome_without_security" in the Karma.conf.js file which fixed it for me.

authors: helzgate mgcrea


text:
Lightweight models for deployment

Currently, the app is running on a public URL http://quest.ms.mff.cuni.cz/rel2text/tabgenie/. However, this version of the app does not have access to GPUs and cannot thus use the model interactively.
Try if some small models (such as T5-small, GPT-2-small or some models adapted for fp16/fp8) could perform inference on CPU in reasonable time to showcase the capabilities of the app.

Solved by tunelling to cluster.
Also, normal-sized models can run on CPU ok-ish.

repo: kasnerz/tabgenie