CI:move travis to action

Codecov Report

Merging #2485 (5ee78aa) into main (ece8a44) will decrease coverage by 0.02%.
The diff coverage is n/a.

:exclamation: Current head 5ee78aa differs from pull request most recent head ff75134. Consider uploading reports for the commit ff75134 to get more accurate results

@@            Coverage Diff             @@
##             main    #2485      +/-   ##
==========================================
- Coverage   61.70%   61.68%   -0.03%
==========================================
  Files         137      137
  Lines       25568    25577       +9
==========================================
- Hits        15778    15777       -1
- Misses       7948     7957       +9
- Partials     1842     1843       +1

Impacted Files
Coverage Δ

pkg/vfs/reader.go
80.29% <0.00%> (-2.56%)
:arrow_down:

pkg/gateway/gateway.go
44.87% <0.00%> (ø)

pkg/chunk/disk_cache.go
81.79% <0.00%> (ø)

pkg/meta/redis.go
71.79% <0.00%> (+0.04%)
:arrow_up:

pkg/meta/sql.go
66.09% <0.00%> (+0.09%)
:arrow_up:

pkg/meta/tkv_mem.go
88.43% <0.00%> (+0.57%)
:arrow_up:

cmd/gateway.go
87.14% <0.00%> (+0.88%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Corber not removing old assets

I noticed this when doing multiple builds for our cordova app (an ember app).  When it builds, it fingerprints the assets.  Then when they are copied over using the build-task, it keeps the old files.  I have had to manually remove the old assets in my framework.js, but it seems like this should not happen.

This is the line in question: https://github.com/isleofcode/corber/blob/master/lib/tasks/bash-build.js#L19

Thanks for the report. Patching.

Fixed in 1.3.2 :)


Change autounique to support Integer and String implementations

Originally reported on Google Code with ID 101

Int use 1,2,3,4...
String use a,b,c..aa,bb,...

autounique blah;
The above code should now default to String not Integer.
See the implementation for Unique and build on top of that.
Also extend the implementation to support derived mechanism for more complex autounique.
autounique x = { moreComplexCalculation(); }

Reported by @umple on 2011-06-24 14:54:06

I am lowering the priority of this. Seems interesting, but there are more important issues


nbind fails to throw an Exception for wrong parameter type

I actually expect this test to pass:
test('newWindow - throw if width is not a number', t => {
	const err = t.throws(() => new libui.UiWindow('Test window', 'some text', 600, true));
	t.true(err instanceof Error);
});

because UiWindow constructor expects an int as second argument, but the code is not hrowing any error

Currently it doesn't check types of numeric arguments:
https://github.com/charto/nbind/blob/cf4c5f78/include/nbind/v8/BindingType.h#L61
The justification was that such errors don't cause a crash, and ideally in the future the JavaScript code can be statically type-checked using TypeScript if the programmer cares about validity. Automatically generating TypeScript definitions from C++ code is in the roadmap.
Omitting the checks avoids a performance penalty. On Node.js it's probably nonexistent but on asm.js nbind currently calls compiled functions directly and adding type checks requires an extra wrapper doing comparatively heavier operations if the code is otherwise just dealing with integers. For the sake of equivalent results between platforms, the checks for numbers and booleans are always disabled. The intention is to check all other types however.
If this causes problems, I could reconsider.

Long story short, in a future version if you use TypeScript, that code wouldn't compile.

If this causes problems, I could reconsider.
It's not a big problem, but it could be nice if nbind could provide such check.
Maybe it could be executed only if current target is node?

That makes sense, especially now that the other test also turned out to be Node-specific. I'll add it then.

I saw you started implemented nullable reference using policies (c++ attributes?)
Even if I didn't fully understood the code, it seems like a power and flexible abstraction.
I wonder if this same abstraction could be used to implement type checking in customizable way.

Yes it can, I hadn't thought of that yet! So, I'll work on closing this ticket as well. The nullable thing should already work on Node.js but there's still problems with Emscripten.

Great! I'll start a new branch on libui-node that start uses new features on nbind v0.3

This should work on Node.js in the v0.3 branch. Emscripten support is still missing. See test/Strict.cc.

Seems to work only with static methods. This code:
class Strict {
public:
	int testInt(int x) { return(x); }
	static std::string testString(std::string x) { return(x); }
	static const char *testCString(const char *x) { return(x); }

};

NBIND_CLASS(Strict) {
	method(testInt, nbind::Strict());
	method(testString, nbind::Strict());
	method(testCString, nbind::Strict());
}

doesn't compile, I get these errors:
nr build --silent
make: ingresso nella directory "/mnt/TEAM_XG1/parro-it/Scrivania/repos/libui-node/build"
  CXX(target) Release/obj.target/nbind/src/UiRadioButtons.o
In file included from ../src/UiRadioButtons.cc:33:0:
../src/UiRadioButtons.cc: In instantiation of ‘BindInvokerStrict<Bound>::BindInvokerStrict() [with Bound = Strict]’:
../src/UiRadioButtons.cc:60:1:   required from here
../../nbind/include/nbind/nbind.h:49:35: error: no matching function for call to ‘nbind::BindDefiner<Strict>::method(nbind::Strict, int (Strict::*)(int))’
 #define method_2(name, boundName) definer.method(boundName, &Bound::name)
                                   ^
../../nbind/include/nbind/nbind.h:21:25: note: in expansion of macro ‘method_2’
 #define VA_CONCAT(A, B) A ## B
                         ^
../../nbind/include/nbind/nbind.h:23:38: note: in expansion of macro ‘VA_CONCAT’
 #define VA_SELECT_HELPER(name, argc) VA_CONCAT(name ## _, argc)
                                      ^
../../nbind/include/nbind/nbind.h:24:30: note: in expansion of macro ‘VA_SELECT_HELPER’
 #define VA_SELECT(name, ...) VA_SELECT_HELPER(name, VA_EXPAND(VA_SIZE(__VA_ARGS__)))(__VA_ARGS__)
                              ^
../../nbind/include/nbind/nbind.h:51:21: note: in expansion of macro ‘VA_SELECT’
 #define method(...) VA_SELECT(method, __VA_ARGS__)
                     ^
../src/UiRadioButtons.cc:61:2: note: in expansion of macro ‘method’
  method(testInt, nbind::Strict());
  ^
In file included from ../../nbind/include/nbind/nbind.h:8:0,
                 from ../src/UiRadioButtons.cc:33:
../../nbind/include/nbind/BindDefiner.h:126:15: note: candidate: template<class ReturnType, class ... Args, class ... Policies> nbind::BindDefiner<Bound>& nbind::BindDefiner<Bound>::method(const char*, ReturnType (*)(Args ...), Policies ...) [with ReturnType = ReturnType; Args = {Args ...}; Policies = {Policies ...}; Bound = Strict]
  BindDefiner &method(
               ^
../../nbind/include/nbind/BindDefiner.h:126:15: note:   template argument deduction/substitution failed:
In file included from ../src/UiRadioButtons.cc:33:0:
../../nbind/include/nbind/nbind.h:49:35: note:   cannot convert ‘nbind::Strict()’ (type ‘nbind::Strict’) to type ‘const char*’
 #define method_2(name, boundName) definer.method(boundName, &Bound::name)
                                   ^
../../nbind/include/nbind/nbind.h:21:25: note: in expansion of macro ‘method_2’
 #define VA_CONCAT(A, B) A ## B
                         ^
../../nbind/include/nbind/nbind.h:23:38: note: in expansion of macro ‘VA_CONCAT’
 #define VA_SELECT_HELPER(name, argc) VA_CONCAT(name ## _, argc)
                                      ^
../../nbind/include/nbind/nbind.h:24:30: note: in expansion of macro ‘VA_SELECT_HELPER’
 #define VA_SELECT(name, ...) VA_SELECT_HELPER(name, VA_EXPAND(VA_SIZE(__VA_ARGS__)))(__VA_ARGS__)
                              ^
../../nbind/include/nbind/nbind.h:51:21: note: in expansion of macro ‘VA_SELECT’
 #define method(...) VA_SELECT(method, __VA_ARGS__)
                     ^
../src/UiRadioButtons.cc:61:2: note: in expansion of macro ‘method’
  method(testInt, nbind::Strict());
  ^
In file included from ../../nbind/include/nbind/nbind.h:8:0,
                 from ../src/UiRadioButtons.cc:33:
../../nbind/include/nbind/BindDefiner.h:140:15: note: candidate: template<class MethodType, class ... Policies> nbind::BindDefiner<Bound>& nbind::BindDefiner<Bound>::method(const char*, MethodType, Policies ...) [with MethodType = MethodType; Policies = {Policies ...}; Bound = Strict]
  BindDefiner &method(
               ^
../../nbind/include/nbind/BindDefiner.h:140:15: note:   template argument deduction/substitution failed:
In file included from ../src/UiRadioButtons.cc:33:0:
../../nbind/include/nbind/nbind.h:49:35: note:   cannot convert ‘nbind::Strict()’ (type ‘nbind::Strict’) to type ‘const char*’
 #define method_2(name, boundName) definer.method(boundName, &Bound::name)
                                   ^
../../nbind/include/nbind/nbind.h:21:25: note: in expansion of macro ‘method_2’
 #define VA_CONCAT(A, B) A ## B
                         ^
../../nbind/include/nbind/nbind.h:23:38: note: in expansion of macro ‘VA_CONCAT’
 #define VA_SELECT_HELPER(name, argc) VA_CONCAT(name ## _, argc)
                                      ^
../../nbind/include/nbind/nbind.h:24:30: note: in expansion of macro ‘VA_SELECT_HELPER’
 #define VA_SELECT(name, ...) VA_SELECT_HELPER(name, VA_EXPAND(VA_SIZE(__VA_ARGS__)))(__VA_ARGS__)
                              ^
../../nbind/include/nbind/nbind.h:51:21: note: in expansion of macro ‘VA_SELECT’
 #define method(...) VA_SELECT(method, __VA_ARGS__)
                     ^
../src/UiRadioButtons.cc:61:2: note: in expansion of macro ‘method’
  method(testInt, nbind::Strict());
  ^
../../nbind/include/nbind/nbind.h:49:35: error: no matching function for call to ‘nbind::BindDefiner<Strict>::method(nbind::Strict, std::__cxx11::string (*)(std::__cxx11::string))’
 #define method_2(name, boundName) definer.method(boundName, &Bound::name)
                                   ^
../../nbind/include/nbind/nbind.h:21:25: note: in expansion of macro ‘method_2’
 #define VA_CONCAT(A, B) A ## B
                         ^
../../nbind/include/nbind/nbind.h:23:38: note: in expansion of macro ‘VA_CONCAT’
 #define VA_SELECT_HELPER(name, argc) VA_CONCAT(name ## _, argc)
                                      ^
../../nbind/include/nbind/nbind.h:24:30: note: in expansion of macro ‘VA_SELECT_HELPER’
 #define VA_SELECT(name, ...) VA_SELECT_HELPER(name, VA_EXPAND(VA_SIZE(__VA_ARGS__)))(__VA_ARGS__)
                              ^
../../nbind/include/nbind/nbind.h:51:21: note: in expansion of macro ‘VA_SELECT’
 #define method(...) VA_SELECT(method, __VA_ARGS__)
                     ^
../src/UiRadioButtons.cc:62:2: note: in expansion of macro ‘method’
  method(testString, nbind::Strict());
  ^
In file included from ../../nbind/include/nbind/nbind.h:8:0,
                 from ../src/UiRadioButtons.cc:33:
../../nbind/include/nbind/BindDefiner.h:126:15: note: candidate: template<class ReturnType, class ... Args, class ... Policies> nbind::BindDefiner<Bound>& nbind::BindDefiner<Bound>::method(const char*, ReturnType (*)(Args ...), Policies ...) [with ReturnType = ReturnType; Args = {Args ...}; Policies = {Policies ...}; Bound = Strict]
  BindDefiner &method(
               ^
../../nbind/include/nbind/BindDefiner.h:126:15: note:   template argument deduction/substitution failed:
In file included from ../src/UiRadioButtons.cc:33:0:
../../nbind/include/nbind/nbind.h:49:35: note:   cannot convert ‘nbind::Strict()’ (type ‘nbind::Strict’) to type ‘const char*’
 #define method_2(name, boundName) definer.method(boundName, &Bound::name)
                                   ^
../../nbind/include/nbind/nbind.h:21:25: note: in expansion of macro ‘method_2’
 #define VA_CONCAT(A, B) A ## B
                         ^
../../nbind/include/nbind/nbind.h:23:38: note: in expansion of macro ‘VA_CONCAT’
 #define VA_SELECT_HELPER(name, argc) VA_CONCAT(name ## _, argc)
                                      ^
../../nbind/include/nbind/nbind.h:24:30: note: in expansion of macro ‘VA_SELECT_HELPER’
 #define VA_SELECT(name, ...) VA_SELECT_HELPER(name, VA_EXPAND(VA_SIZE(__VA_ARGS__)))(__VA_ARGS__)
                              ^
../../nbind/include/nbind/nbind.h:51:21: note: in expansion of macro ‘VA_SELECT’
 #define method(...) VA_SELECT(method, __VA_ARGS__)
                     ^
../src/UiRadioButtons.cc:62:2: note: in expansion of macro ‘method’
  method(testString, nbind::Strict());
  ^
In file included from ../../nbind/include/nbind/nbind.h:8:0,
                 from ../src/UiRadioButtons.cc:33:
../../nbind/include/nbind/BindDefiner.h:140:15: note: candidate: template<class MethodType, class ... Policies> nbind::BindDefiner<Bound>& nbind::BindDefiner<Bound>::method(const char*, MethodType, Policies ...) [with MethodType = MethodType; Policies = {Policies ...}; Bound = Strict]
  BindDefiner &method(
               ^
../../nbind/include/nbind/BindDefiner.h:140:15: note:   template argument deduction/substitution failed:
In file included from ../src/UiRadioButtons.cc:33:0:
../../nbind/include/nbind/nbind.h:49:35: note:   cannot convert ‘nbind::Strict()’ (type ‘nbind::Strict’) to type ‘const char*’
 #define method_2(name, boundName) definer.method(boundName, &Bound::name)
                                   ^
../../nbind/include/nbind/nbind.h:21:25: note: in expansion of macro ‘method_2’
 #define VA_CONCAT(A, B) A ## B
                         ^
../../nbind/include/nbind/nbind.h:23:38: note: in expansion of macro ‘VA_CONCAT’
 #define VA_SELECT_HELPER(name, argc) VA_CONCAT(name ## _, argc)
                                      ^
../../nbind/include/nbind/nbind.h:24:30: note: in expansion of macro ‘VA_SELECT_HELPER’
 #define VA_SELECT(name, ...) VA_SELECT_HELPER(name, VA_EXPAND(VA_SIZE(__VA_ARGS__)))(__VA_ARGS__)
                              ^
../../nbind/include/nbind/nbind.h:51:21: note: in expansion of macro ‘VA_SELECT’
 #define method(...) VA_SELECT(method, __VA_ARGS__)
                     ^
../src/UiRadioButtons.cc:62:2: note: in expansion of macro ‘method’
  method(testString, nbind::Strict());
  ^
../../nbind/include/nbind/nbind.h:49:35: error: no matching function for call to ‘nbind::BindDefiner<Strict>::method(nbind::Strict, const char* (*)(const char*))’
 #define method_2(name, boundName) definer.method(boundName, &Bound::name)
                                   ^
../../nbind/include/nbind/nbind.h:21:25: note: in expansion of macro ‘method_2’
 #define VA_CONCAT(A, B) A ## B
                         ^
../../nbind/include/nbind/nbind.h:23:38: note: in expansion of macro ‘VA_CONCAT’
 #define VA_SELECT_HELPER(name, argc) VA_CONCAT(name ## _, argc)
                                      ^
../../nbind/include/nbind/nbind.h:24:30: note: in expansion of macro ‘VA_SELECT_HELPER’
 #define VA_SELECT(name, ...) VA_SELECT_HELPER(name, VA_EXPAND(VA_SIZE(__VA_ARGS__)))(__VA_ARGS__)
                              ^
../../nbind/include/nbind/nbind.h:51:21: note: in expansion of macro ‘VA_SELECT’
 #define method(...) VA_SELECT(method, __VA_ARGS__)
                     ^
../src/UiRadioButtons.cc:63:2: note: in expansion of macro ‘method’
  method(testCString, nbind::Strict());
  ^
In file included from ../../nbind/include/nbind/nbind.h:8:0,
                 from ../src/UiRadioButtons.cc:33:
../../nbind/include/nbind/BindDefiner.h:126:15: note: candidate: template<class ReturnType, class ... Args, class ... Policies> nbind::BindDefiner<Bound>& nbind::BindDefiner<Bound>::method(const char*, ReturnType (*)(Args ...), Policies ...) [with ReturnType = ReturnType; Args = {Args ...}; Policies = {Policies ...}; Bound = Strict]
  BindDefiner &method(
               ^
../../nbind/include/nbind/BindDefiner.h:126:15: note:   template argument deduction/substitution failed:
In file included from ../src/UiRadioButtons.cc:33:0:
../../nbind/include/nbind/nbind.h:49:35: note:   cannot convert ‘nbind::Strict()’ (type ‘nbind::Strict’) to type ‘const char*’
 #define method_2(name, boundName) definer.method(boundName, &Bound::name)
                                   ^
../../nbind/include/nbind/nbind.h:21:25: note: in expansion of macro ‘method_2’
 #define VA_CONCAT(A, B) A ## B
                         ^
../../nbind/include/nbind/nbind.h:23:38: note: in expansion of macro ‘VA_CONCAT’
 #define VA_SELECT_HELPER(name, argc) VA_CONCAT(name ## _, argc)
                                      ^
../../nbind/include/nbind/nbind.h:24:30: note: in expansion of macro ‘VA_SELECT_HELPER’
 #define VA_SELECT(name, ...) VA_SELECT_HELPER(name, VA_EXPAND(VA_SIZE(__VA_ARGS__)))(__VA_ARGS__)
                              ^
../../nbind/include/nbind/nbind.h:51:21: note: in expansion of macro ‘VA_SELECT’
 #define method(...) VA_SELECT(method, __VA_ARGS__)
                     ^
../src/UiRadioButtons.cc:63:2: note: in expansion of macro ‘method’
  method(testCString, nbind::Strict());
  ^
In file included from ../../nbind/include/nbind/nbind.h:8:0,
                 from ../src/UiRadioButtons.cc:33:
../../nbind/include/nbind/BindDefiner.h:140:15: note: candidate: template<class MethodType, class ... Policies> nbind::BindDefiner<Bound>& nbind::BindDefiner<Bound>::method(const char*, MethodType, Policies ...) [with MethodType = MethodType; Policies = {Policies ...}; Bound = Strict]
  BindDefiner &method(
               ^
../../nbind/include/nbind/BindDefiner.h:140:15: note:   template argument deduction/substitution failed:
In file included from ../src/UiRadioButtons.cc:33:0:
../../nbind/include/nbind/nbind.h:49:35: note:   cannot convert ‘nbind::Strict()’ (type ‘nbind::Strict’) to type ‘const char*’
 #define method_2(name, boundName) definer.method(boundName, &Bound::name)
                                   ^
../../nbind/include/nbind/nbind.h:21:25: note: in expansion of macro ‘method_2’
 #define VA_CONCAT(A, B) A ## B
                         ^
../../nbind/include/nbind/nbind.h:23:38: note: in expansion of macro ‘VA_CONCAT’
 #define VA_SELECT_HELPER(name, argc) VA_CONCAT(name ## _, argc)
                                      ^
../../nbind/include/nbind/nbind.h:24:30: note: in expansion of macro ‘VA_SELECT_HELPER’
 #define VA_SELECT(name, ...) VA_SELECT_HELPER(name, VA_EXPAND(VA_SIZE(__VA_ARGS__)))(__VA_ARGS__)
                              ^
../../nbind/include/nbind/nbind.h:51:21: note: in expansion of macro ‘VA_SELECT’
 #define method(...) VA_SELECT(method, __VA_ARGS__)
                     ^
../src/UiRadioButtons.cc:63:2: note: in expansion of macro ‘method’
  method(testCString, nbind::Strict());
  ^
nbind.target.mk:183: set di istruzioni per l'obiettivo "Release/obj.target/nbind/src/UiRadioButtons.o" non riuscito
make: *** [Release/obj.target/nbind/src/UiRadioButtons.o] Errore 1
make: uscita dalla directory "/mnt/TEAM_XG1/parro-it/Scrivania/repos/libui-node/build"

If I make testInt method static, it compile

It was required to pass a name string before the policy list (causing your errors about converting nbind::Strict to const char*), but that requirement is now gone. There was also another problem with non-static methods which is fixed.

Also done on Emscripten target now and waiting for release.

Works like a charm @jjrv, thank you! The issue could be closed for me.


Proposal: Add Clojure's thread-left (->>) as function

What I propose is a deviation from Clojure's macro. The function should pass the first value to the rest of the functions as it where composed from left to right; functions must be unary.
Example:
// thread :: (x, (a -> b), (b -> c), ... (o -> p)) -> p
let thread = (v, ...fns) => {
  return fns.reduce((acc, f) => f(acc), v)
}

thread(4, inc, add(2)) // 7

It looks very close to pipe, so, anyone can argue that similar result can be achieved with pipe or compose. But the problem it addresses (regarding all the functions that Ramda offers) is not about function nor features but code structure. I find it more readable in cases when pipe is needed in a not poin-free-style code, in other words, when using pipe or compose and call the resulting function immediately after the function composition.
A simple example of above could be pipe(f, g)(a) it could read as compose this functions, execute passing 'a'. The previous example could look trivial and easy to deal with, but the the things starts to get harder when dealing with large compositions. The same code could be written in terms of thread as thread(a, f, g) which I read like pipe 'a' though the rest of functions or execute this pipeline starting with 'a'. Noticeably, the second way looks more declarative than the former.
Furthermore, this thread function is a good complement for pipe, ifElse, cond or any other high order function. Lets take a look at the following two examples:
// with pipe
thread(4, pipe(inc, add(2)))

// with cond
thread(n, cond([
    [gt(__, 0), always(1)],
    [lt(__, 0), always(-1)],
    [T, always(0)]
]))

While I think I understand your rationale, my first instinct is :-1: on this.
Ramda is designed around functional composition with parameter order chosen to make such composition easier.
This proposal is aimed at a very different style of coding than Ramda is built around.  Do note that there are proposals to add this to the language as an operator.  (I'm on my mobile so won't look them up but just look for the proposal for the pipeline operator, ¦>.)
To me
thread(x, f, g)

is less readable than
g(f(x))

so I'm afraid I don't see the point.

Function composition is easy with Ramda but  when calling the result of that composition inline we have to use ()() syntax, example:
pipe(
   someFunc1,
   someFunc2,
   someFunc3(),
   someFunc4(a, b),
   someFunc5(c),
   someFunc6)(x)

Notice passing x at the end of the function
Now with thread:
thread(x,
   someFunc1,
   someFunc2,
   someFunc3(),
   someFunc4(x, f),
   someFunc5(s),
   someFunc6)

To me ... is less readable than ...

The example of above with plain JS:
someFunc6(
  someFunc5(x)(
    someFunc4(x, f)(
      someFunc3()(
        someFunc2(someFunc1())))))(x)

With just f and g should be readable anyways but if the last snippet is more readable for you I can understand that in the end of the day I'm just a mortal-Ramda-user but you are not ;)

Do note that there are proposals to add this to the language as an operator.

Yes, I'm aware. First to say is that it is still in proposal state AFAIK. Second, I don't accept it as a valid point since ifElse could be easily replaced by ()=>?: (arrow function + ternary op) but the proposal of arrow functions and currently its adoption should not be -actually isn't- a valid argument to trim down some Ramda functions or features. So, I should not be acceptable against a proposal either.

Funny, I was just thinking in proposing the very same thing. But now that I read @CrossEye's response, it is clear that it is not in Ramda's data last style.
However I think thread is indeed very helpful in terms of code readability, and I can see numerous use cases for it.
It would be nice to have in Ramda just to not have to import something else with it, and also to make it available to Ramda's userbase, which I think would also have a lot of use for it.
IMHO the question would be: are those reasons enough?

This proposal should be compared in the side of call and apply instead of in pipe/compose. It could be useful when combined with converge for example:
converge(thread, [identity, f, g])

I'm still not convinced.  My f/g  note was mostly in response to your initial example.
I do find this:
add(2, inc(4))

easier to read than this:
thread(4, inc, add(2))

But that is only part of it.  Ramda to me is all about being able to break things down into simpler and simpler functions.  So if 'increment-and-add-2` is a meaningful concept to me, I want to pull that into it's own function with
const addTwoToInc = compose(add(2), inc)

and then later use that with
addTwoToInc(4)

(and if the composition is too long for a single line, I'd usually switch to pipe.)
While I agree that  the x is hard to spot here:
pipe(
   someFunc1,
   someFunc2,
   someFunc3(),
   someFunc4(a, b),
   someFunc5(c),
   someFunc6)(x)

I also find it hard to spot here:
thread(x,
   someFunc1,
   someFunc2,
   someFunc3(),
   someFunc4(a, b),
   someFunc5(c),
   someFunc6)

Perhaps that's because I've been trained by using pipe for quite some time.
But I have much less trouble spotting it in either this:
pipe(
   someFunc1,
   someFunc2,
   someFunc3(),
   someFunc4(a, b),
   someFunc5(c),
   someFunc6
)(x)

or, even better, this:
const someCombinedFn = pipe(
   someFunc1,
   someFunc2,
   someFunc3(),
   someFunc4(a, b),
   someFunc5(c),
   someFunc6
)
someCombinedFn(x)

I'm sorry for the confusion.  I certainly wasn't trying to suggest that the existence of a language-level proposal would preclude Ramda adopting its own function.  Many, many Ramda functions have similar behaviors to Javascript operators or built-in functions and methods.  I simply wanted to point out to you that you may get a similar behavior from the language itself soon enough.  For the same reasons I discuss here, I don't find much of interest in that proposal.

I also really don't understand the example
converge(thread, [h, f, g])

Which, supplied x for a parameter would return
g(x, f(x, h(x)))

Is there something special about this I should recognize?

Finally, to @diegovdc:

It would be nice to have in Ramda just to not have to import something else with it, and also to make it available to Ramda's userbase, which I think would also have a lot of use for it.
IMHO the question would be: are those reasons enough?

My answer to that is: no, that is not enough.  There are many things that might be nice to have in Ramda.  Some of them fit with our philosophy but do not seem common enough to include in the library.  (See the Cookbook for examples.)  Others, like this one, don't really fit the philosophy.  Even if they address a common need, they are hard to square with the rest of the library.

add(2, inc(4))

I actually find  2 + (4 + 1) or 7 even easier to read.
More seriously, this discussion has not yet mentioned the simple property that makes the proposed thread function readable: you can read it left-to-right and top-to-bottom without having to visually scan the expression to find where to start.  You simply start with the value being transformed and then apply operations to it one-by-one until you reach the end.
pipe is great when you want to introduce a name for the function, but often you don't.  Being able to program without having to name to things unnecessarily for "readability" is a feature rather than a bug.  I often refactor code from using my equivalent of thread to using pipe and vice versa.
The examples are also misleading in that the functions being used are often much more complex expressions than simple names (higher-order functions given lambda expressions) and then it becomes much more difficult to visually scan the expression to find the point from which it all begins.
BTW, the idea can be dated at least as far as 1994 and has been independently discovered many times.

I agree 100% with @polytypic:

pipe is great when you want to introduce a name for the function, but often you don't.

With such pipe sequences like given above, the data flows not left to right or top to bottom but makes a crazy jump from behind before entering the pipeline. Therefore I usually prefer compose unless the sequence is too long.
The proposed thread (Btw. I don't like that name at all) sequence would be consistent to other functional pipes in my code E.g.
fetch(url)
.then(JSON.parse)
.then(queryDb)
.then(postResult);

Bacon.fromEvent(button, 'click')
.throttle(2)
.flatMap(getUserPermission)
.filter(isOk)
.onValue(sendRequest);

But of course it may be just syntactic sugar.

First of all, I don't want to imply some implacable opposition to this.  I find no need and see it as somewhat contrary to the spirit of Ramda, but it's not some horrible mismatch either.  And as others join in requesting it, it seems more likely than with just a single voice.
But I'm still opposed, for several reasons.  First, I want to change pipe/compose at some point, to get rid of the only variadic functions in the library.  They would be much the same, only requiring a list of functions rather than separate arguments.  So adding another one seems backward.  This is minor, though, because we could do the same with thread.
But assuming we do that, and we'd call it like thread(4, [inc, add(2)]), we have a mismatch with the way pretty well all Ramda functions work.  Some people call this "data-last", but I tend to think about it as ordering the parameters from least likely to change to most likely to change.  Pretty well all functions that return a non-function value work this way.  thread, by necessity, could not.

BTW, the idea can be dated at least as far as 1994 and has been independently discovered many times.

Yes, I'd seen the MSDN/Isabelle article before, although not the other one.  The idea is straightforward, and fairly obvious.  My main question is whether it's a good fit for Ramda.  I'd like to hear from others on the core team about this.  What do you think, @buzzdecafe, @davidchambers, @raine, @paldepind, @TheLudd, @kedashoe, @Bradcomp, @asaf-romano, @scott-christopher?

@CrossEye: FWIW, there are still a number of other variadic functions to purge: allPass, anyPass, both, either, ifElse, cond,  call, complement, lift(!), memoizeWith, nthArg, partial, partialRight, tryCatch, unapply, and maybe some more i missed. I agree we should get rid of 'em.
I don't have a particularly strong feeling on this proposal. I am inclined to agree with you @CrossEye, that it would be something of an odd fit. Also, as we approach 1.0, I am daydreaming about the many functions I would like to remove for the next version.  That makes me disinclined to add any new functions at this point.

On my part, I agree with @CrossEye. I don't think it's something necessary to add to Ramda.
As a variadic function I think it's weird. I don't like that the first parameter is privileged, and I can't think of a good way to curry it (I know that compose and pipe aren't curried either). Like, what happens if we pass in a single parameter?
It's better with an array as the second parameter, but then it really does seem like the parameter order is flipped from what you would expect.
Lastly, we now have R.applyTo, which is basically the same thing, and makes thread trivial to implement.
R.applyTo(
  4,
  pipe(
    inc,
    add(2)
  )
)

@buzzdecafe: I was thinking about functions for which the number of parameters is not fixed, not those that accept variadic functions.  We cleaned up useWith and converge so that they take lists of functions; I would like to do the same for pipe and compose, although this is not at all urgent.  The question of not even accepting variadic functions as parameters is much broader, and much more difficult.
@Bradcomp: wow, I'd already forgotten that one!  Yes, while that's not quite as convenient as thread, it's pretty simple.

@Bradcomp : Didn't know about R.applyTo. Nice! Thank you!

[@CrossEye] others join in requesting it, it seems more likely than with just a single voice

Not everyone spends time in discussions here, but some of my colleagues familiar with Clojure have told that having equivalent of Clojure's ->> is something they'd really like to have.  (Personally I already use a seq function that does the same thing as the proposed thread.)

[@Bradcomp] Like, what happens if we pass in a single parameter?

That is simple: thread(x) = x.
thread is actually better behaved than Ramda's pipe, which doesn't have zero. You can't say applyTo(2, pipe()), but you can say thread(2).

[@CrossEye] we have a mismatch with the way pretty well all Ramda functions work [...]
[@Bradcomp] I can't think of a good way to curry it [...]

I think there is misunderstanding as to the purpose and utility of thread.  It is a notational convenience for consuming Ramda style data last functions.
As an aside, it is really frustrating to see people talking about the concept as "composition".  It is not an introduction form.  It is an elimination form.
(|>): x -> (x -> y) -> y

It takes a value of type x and an abstraction of type x -> y and eliminates the abstraction.  That is what I mean when I say the thread operation is for consuming Ramda style data last functions.
The codebase of the project I'm currently working on has lots of uses of pipe where the constructed composition is just immediately used:
const fb = R.pipe(
  R.foo( /* Written on separate lines, because these are */ ),
  // ...
  R.bar( /* often long expression spanning multiple lines. */ )
)(x)

A function like thread would make all of those a bit easier to read.  Not to mention that operationally using pipe like that makes little sense, because it amounts to creating (allocating) a composed function, using it once, and then throwing it away.
Perhaps |> makes it to JS eventually, but, in the meanwhile, I recommend using something like thread to consume Ramda style data last functions.

@polytypic:
I don't dispute the usefulness, only whether it's a good fit for Ramda.  Ever since we removed installTo, back in #834, we have been able to say "No Ramda functions modify user data."  It's nice to be categorical like that.  I would like to be able to say "All Ramda functions of more than one parameter are curried".  It's just cleaner.  It makes it easier to describe how the library works, and to explain its place in the JS world.  But this function, even if changed to thread(x, [list, of, ..., functions]), would not be curried appropriately in Ramda.  I simply don't like those sorts of caveats.

Not to mention that operationally using pipe like that makes little sense, because it amounts to creating (allocating) a composed function, using it once, and then throwing it away.

This is the most compelling point, and it also applies to the suggestion from @Bradcomp above with applyTo.
I know mine is not the only way people work with Ramda; it's clearly different from that of several people writing here.  I rarely use any of Ramda's combining operators (pipe, compose, converge, lift, useWith, et. al.) to directly create values.  I almost always use them to create reusable functions.  Perhaps if I worked this way more often it would seem logical to me to include the function.  But I would still be loathe to say, "All Ramda functions, except thread,...".  And that's my biggest sticking point.

But this function, even if changed to thread(x, [list, of, ..., functions]), would not be curried appropriately in Ramda. I simply don't like those sorts of caveats.

Why not? Is applyTo not curried appropriately?

But this function, even if changed to thread(x, [list, of, ..., functions]), would not be curried appropriately in Ramda. I simply don't like those sorts of caveats.

Why not? Is applyTo not curried appropriately?

I think it is.  The semantics of applyTo involve specifically starting with a value and applying a function to it.  With this, the parameter more likely to change is actually the function.
But thread doesn't come across that way to me.  While it is perfectly usable, the partial application of thread(x) does not seems to me to have those same connotations.  Maybe I'd find it more likely with a different name, I don't know.

The semantics of applyTo involve specifically starting with a value and applying a function to it. With this, the parameter more likely to change is actually the function.

I don't understand the distinction.. can't we say "The semantics of thread involve specifically starting with a value and applying one or more functions to it"

Maybe I'd find it more likely with a different name, I don't know.

I call if flush in my ramda utils to keep with the plumbing theme :)

I don't understand the distinction.. can't we say "The semantics of thread involve specifically starting with a value and applying one or more functions to it"

Well, of course you can say whatever you want.  But to me that doesn't at all sound like what "thread" would mean.  But I suppose that's all my own issue.  I certainly don't have an internal model of what juxt should mean.

Naming it flush makes it fit better in Ramda IMO.
flush :: a -> [(a -> b), (b -> c), ...., (d -> e)] -> e
let flush4 = flush(4)
flush4([inc, add(2)]) // 7

[@CrossEye] I would like to be able to say "All Ramda functions of more than one parameter are curried".

I sympathize with that goal.  I've spent a large chunk of my career writing ML and I appreciate functions with simple signatures.  However, it is painfully obvious to me that JS (like Lisp style languages) is not ML and the ergonomics are quite different.  In JS libraries I've authored, I've used both "template object" based functions (like R.evolve) and variadic functions (like R.pipe), because the alternative of building such functions from parts, like one would have to do those in ML, would just be cumbersome in JS.  While doing so I have always thought about the algebraic properties of such functions.  As a simple example, the astute reader should notice that L.choices forms a semigroup (over optics in read-direction) and L.choice is an extension of said semigroup to a monoid with zero.  In a way I don't think of such variadic and template based functions as functions per se.  I think of them as notations for the associated algebraic operations and in this particular case the underlying binary operation is also provided as L.orElse (albeit in a flipped form for practical reasons that I'm sure you can spot).
So, how about not calling the proposed thread a "function" and referring to it and other operations like it with some other technical term?  This way documentation could be clear about the distinction and one could indeed say that "All Ramda functions [snip] are curried".
Speaking of variadic functions and algebraic properties, while I find that pipe (and compose) in Ramda actually usually does what I want, its algebraic properties are not so nice.  It doesn't have an identity element (pun intended) due to the special treatment of the first argument to pipe.
I would also like to add that, IMO, changing a variadic function to instead take an array doesn't improve things radically.  What it mainly does is that it makes the syntax of applying such functions more verbose.  At the same time it doesn't make it really simple to access the underlying algebraic operations, because you need to do so indirectly by operating on an array of things.  It would likely be better to provide both a variadic function and the associated binary operation (which should agree, unlike with compose and o).

[@kedashoe] I call if flush in my ramda utils to keep with the plumbing theme :)

🤣

So, how about not calling the proposed thread a "function" and referring to it and other operations like it with some other technical term? This way documentation could be clear about the distinction and one could indeed say that "All Ramda functions [snip] are curried".

That sounds like playing games.
I don't mean this to be simple wordplay.  I really do want to have consistency across Ramda functions.  The "of more than one parameter" was just a way of saying "all functions where it makes sense", as there's no reason to curry functions of one parameter (even though we do!)
But, as I said, my main objection to this lies in the internal consistencies of the library, not in some major objection to the function itself.  That I wouldn't find much need for it myself would not make me want to exclude something that has a large fan-base.  But I would want to include it only if it also seems to fit with the design of Ramda.  Even when requiring the functions to be supplied in an array, it still feels to me like a mismatch.  But there are several people arguing for it, including core team member @kedashoe, which should help.

At the same time it doesn't make it really simple to access the underlying algebraic operations, because you need to do so indirectly by operating on an array of things.

Again, that is not really the goal.  Ideally, one should be able to simply intuit how to use a Ramda function.  Internal consistency across the library is an increasingly important factor for me.

(which should agree, unlike with compose and o).

Are you referring to the fact that f and g have to be unary, as is o(f, g), or is three some more serious concern?

That sounds like playing games.
I don't mean this to be simple wordplay.

More like the opposite of that: clearly differentiating between (curried) functions with simple fixed-arity signatures and functions with more complex signatures.

there's no reason to curry functions of one parameter

Indeed.

Ideally, one should be able to simply intuit how to use a Ramda function.

Based on what information?
The name?
The complete signature?
Are you seriously suggesting that adding one more bit of information (variadic or not) to the already quite complex signatures of Ramda functions (that include arbitrary overloading, object templates, type class constraints, n-ary functions that are sometimes curried and sometimes not, variadic functions(!), can sometimes act as transducers, and more) completely breaks down the ability to intuit how Ramda functions work?

Are you referring to the fact that f and g have to be unary, as is o(f, g), or is three some more serious concern?

That is what I'm referring to.  Quite simply, compose(f, g) is not equivalent to o(f, g).  What could be more serious than that?  From an algebraic point of view it would make sense to have compose(f, g, h) to be equivalent to o(f, o(g, h)) and also to o(o(f, g), h).  It would also make sense to have compose() to be equivalent to identity.  Unfortunately none of that is the case.

Are you seriously suggesting that adding one more bit of information (variadic or not) to the already quite complex signatures of Ramda functions (that include arbitrary overloading, object templates, type class constraints, n-ary functions that are sometimes curried and sometimes not, variadic functions(!), that can sometimes act as transducers, and more) completely breaks down the ability to intuit how Ramda functions work?

Zing! that one stung

Ideally, one should be able to simply intuit how to use a Ramda function.

Based on what information?

Knowledge of what the function does.  The point was that if you're familiar with Ramda idioms, and you want to remember how to use the function filter, you would simply know that the predicate must be supplied first and the filterable data last.  This does not, of course, tell you what filter does.  But if you don't know that, you have to start elsewhere anyway.  That's why I'm hesitant to include a function where that intuition is wrong.  This is one place where Ramda has been very consistent.

Are you seriously suggesting that adding one more bit of information (variadic or not) to the already quite complex signatures of Ramda functions (that include arbitrary overloading, object templates, type class constraints, n-ary functions that are sometimes curried and sometimes not, variadic functions(!), that can sometimes act as transducers, and more) completely breaks down the ability to intuit how Ramda functions work?

I'm suggesting that we simplify as much as we can.  AFAIK, we only have two functions right now which are variadic, pipe and compose.  (There are many others which accept variadic functions, but that's a whole other story.)  I would like to change those to take a list of functions, and certainly don't want to add any more.  Post 1.0, I would like to consider making all our functions, and all the functions we accept unary.  The point is that I want to keep simplifying, and a function that behaves differently from everything else doesn't seem the way to do that.

Quite simply, compose(f, g) is not equivalent to o(f, g).  What could be more serious than that?  From an algebraic point of view it would make sense to have compose(f, g, h) to be equivalent to o(f, o(g, h)) and also to o(o(f, g), h).  It would also make sense to have compose() to be equivalent to identity.

I actually want to address all of this.  I was wondering, though, if you saw any functions f and g that would work with o(f, g) that would work differently with compose(f, g).  That would concern me a lot more.  That there are functions that will work with compose and not o doesn't bother me much, as compose is meant to work with JS's variadic functions.  (And I don't mean could you invent one.  Obviously with arguments, it's easy enough to create such.  I simply would like to know if there are real-world scenarios to be concerned about?)

@CrossEye
By reshaping it to drive :: a -> [(a -> b), (b -> c), ..., (d -> e)] -> e would make it Ramda philosophy compliant? I think it does. In this way it is composable, and it can replace pipe in many cases.
// 1. waiting for a list of unary functions
drive(obj)

// 2. waiting for the first param
drive(__, [pick(['a', 'b']), sum])

// 3. shining!
drive(obj, [pick(['a', 'b']), sum]

drive works much better to me as a name for this than thread.  I'm not sure why.  And yes, I think that passing the functions as a list makes it much less objectionable.  I don't think the extra brackets are a large burden.  In fact, I want to introduce them in pipe and compose too at some point.
I would not have a major objection to this proposal.  If people wanted to argue for thread instead of drive based on prior art, I would certainly be willing to listen.  But with drive, my objections seem to clear.

The drive function can be easily implemented as:
const drive = R.reduce(R.applyTo)

Repl
Maybe it should be added to the cookbook.

what's the final decision on this? Added nowhere?

Added to Cookbook.


[FLINK-22645][sql-parser] "ALTER VIEW" DDL for Flink dialect

What is the purpose of the change
This introduces the ALTER VIEW DDL statements
ALTER VIEW … RENAME TO …
ALTER VIEW … AS …

to the (regular) Flink dialect. Previously, they were only part of the Hive dialect. The syntax follows that of the Hive dialect and is also in line with the syntax for tables.
Brief change log

Added DDL to the SQL parser using existing infrastructure from the Hive dialect

Verifying this change
This is mostly covered through existing tests, but Flink dialect test cases for the new syntax, specifically, have been added.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented? docs

@twalthr I've added a couple of IT test cases for it as well now.


Is there any support of composeP and pipeP?

I use "@types/ramda": "0.0.11" and I see no composeP or pipeP. I would like to write point-free functions with promises. Just composeP and pipeP does it less pain.

Hey! We've yet to push proper typings to DefinitelyTyped; could you please try using types/npm-ramda over @types/ramda?

Now it looks like
"devDependencies": {
    "@types/ramda": "github:types/npm-ramda"
  }

Now all is working! Thanks for tip about pipeP.

No worries; glad to hear!


JS Phishing Detection

Here are some JS functions to call out a phishing link. There's more to come!

will do

You can check now

@steffigeorge Mention is Issue no

Done


Can't save settings if "Enable Header Parsing?" is disabled

Craft: <IP_ADDRESS>
Doxter: 3.4.9

I will look into this shortly

@jsunsawyer This should be addressed in the latest release, but I haven't done extensive testing yet.


Raspberry Pi Install Error (Anyone Else Experiencing Down Server?)

When trying to run the command:
sudo apt-get install libavahi-compat-libdnssd-dev
I get a time our error, is there anywhere else to get this from?
0% [Connecting to mirror.sjc02.svwh.net (<IP_ADDRESS>)]
Thanks!

What error are you getting?
Sent from my iPhone

On Mar 18, 2017, at 11:28 AM, erfinb<EMAIL_ADDRESS>wrote:
When trying to run the command:
sudo apt-get install libavahi-compat-libdnssd-dev
I get a time our error, is there anywhere else to get this from?
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

i@OfficeHomebridge:~ $ sudo apt-get install libavahi-compat-libdnssd-dev -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libavahi-client-dev libavahi-common-dev libavahi-compat-libdnssd1
libdbus-1-dev
The following NEW packages will be installed:
libavahi-client-dev libavahi-common-dev libavahi-compat-libdnssd-dev
libavahi-compat-libdnssd1 libdbus-1-dev
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 340 kB/402 kB of archives.
After this operation, 1,160 kB of additional disk space will be used.
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main libavahi-compat-libdnssd1 armhf 0.6.31-5
Could not connect to mirror.sjc02.svwh.net:80 (<IP_ADDRESS>), connection timed out [IP: <IP_ADDRESS> 80]
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main libdbus-1-dev armhf 1.8.22-0+deb8u1
Unable to connect to mirror.sjc02.svwh.net:http: [IP: 2606:c680:0:b:3830:34ff:fe66:6663 80]
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main libavahi-client-dev armhf 0.6.31-5
Unable to connect to mirror.sjc02.svwh.net:http: [IP: 2606:c680:0:b:3830:34ff:fe66:6663 80]
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main libavahi-compat-libdnssd-dev armhf 0.6.31-5
Unable to connect to mirror.sjc02.svwh.net:http: [IP: 2606:c680:0:b:3830:34ff:fe66:6663 80]
E: Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/a/avahi/libavahi-compat-libdnssd1_0.6.31-5_armhf.deb  Could not connect to mirror.sjc02.svwh.net:80 (<IP_ADDRESS>), connection timed out [IP: <IP_ADDRESS> 80]
E: Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/d/dbus/libdbus-1-dev_1.8.22-0+deb8u1_armhf.deb  Unable to connect to mirror.sjc02.svwh.net:http: [IP: 2606:c680:0:b:3830:34ff:fe66:6663 80]
E: Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/a/avahi/libavahi-client-dev_0.6.31-5_armhf.deb  Unable to connect to mirror.sjc02.svwh.net:http: [IP: 2606:c680:0:b:3830:34ff:fe66:6663 80]
E: Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/a/avahi/libavahi-compat-libdnssd-dev_0.6.31-5_armhf.deb  Unable to connect to mirror.sjc02.svwh.net:http: [IP: 2606:c680:0:b:3830:34ff:fe66:6663 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

This has nothing to do with homebridge, your apt source is broken. Check here


navi --tldr not working even with rust client tlrc

hi
Describe the bug
navi --tldr says :

    Note:
    Please make sure you're using a version that supports the --markdown flag.
    If you are already using a supported version you can ignore this message.
    The tldr client written in C (the default one in Homebrew) doesn't support markdown files, so navi can't use it.
    The client written in Rust is recommended. The one available in npm works, too.

So I installed tlrc, expecting it to work. but it doesnt have a --markdown flag.
To Reproduce
Steps to reproduce the behavior:
brew install navi
brew install tlrc
navi --tldr docker

Expected behavior
According to the hint message navi --tldr should be supported but it is not. Please consider to change the hint text.
Versions:

OS: [e.g. macOS, WSL ubuntu, ubuntu] : debian bookworm, navi 2.23.0 & tlrc (v1.9.2 (implementing the tldr client specification v2.2))  installed through homebrew
Shell Version [replace this text with the output of sh --version]: GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)

Additional context
thanks

Same issue with v2.23.0

Regarding tealdeer it was supposedly fixed in #873, where the config option was added, however this commit was added in January this year, while the last release of navi was December last year, so the fix isn't out yet, sadly.
Well, unless you build your version of navi from the master branch.

Hi, in that case i'm happy to consider this issue as resolved if the docs make it a bit clearer which tldr client to install, which is what I tried to do with pr #916  .
thanks

Regarding tealdeer it was supposedly fixed in #873, where the config option was added, however this commit was added in January this year

This is still the case 1 year since the fix and surprisingly confusing to debug. I recommend reopening the issue until the next release and package managers like Homebrew are updated.
Furthermore assuming tealdeer really is the recommended client shouldn't client.tealdeer also default to true? Or preferably client.format_flag to --raw with a note about --markdown for the Node client 🧠


Additional notes on stanzas to add to README, edge cases for symmetric axioms and GCIs

I suggest adding something like this to the end of the README
### Stanza edge cases.

Note that OWL does not prioritize the directionality of some symmetric axiom types - for example, when you have a disjointness axiom or equivalence axiom connecting two named classes. In this case, the stanza is chosen arbitrarily.

E.g. in an ontology that has `A disjointWith B` we get:

ex:B|ex:B|rdfs:label||B||
ex:B|ex:B|owl:disjointWith|ex:a|||
ex:B|ex:B|rdf:type|owl:Class|||
ex:a|ex:a|rdfs:label||A||
ex:a|ex:a|rdf:type|owl:Class|||

This means that the convenience query shown above does not reliably fetch all axioms for a class - e.g. in the above querying on A would not get the disjointness axiom

Additionally, the stanza name may not be meaningful for GCIs. For example, given an axiom:

develops-from some (part-of some B) DisjointWith develops-from some (part-of some A)

i.e.

   <owl:Restriction>
        <owl:onProperty rdf:resource="http://example.com/develops-from"/>
        <owl:someValuesFrom>
            <owl:Restriction>
                <owl:onProperty rdf:resource="http://example.com/part-of"/>
                <owl:someValuesFrom rdf:resource="http://example.com/B"/>
            </owl:Restriction>
        </owl:someValuesFrom>
        <owl:disjointWith>
            <owl:Restriction>
                <owl:onProperty rdf:resource="http://example.com/develops-from"/>
                <owl:someValuesFrom>
                    <owl:Restriction>
                        <owl:onProperty rdf:resource="http://example.com/part-of"/>
                        <owl:someValuesFrom rdf:resource="http://example.com/a"/>
                    </owl:Restriction>
                </owl:someValuesFrom>
            </owl:Restriction>
        </owl:disjointWith>
    </owl:Restriction>

we get:

owl:disjointWith|_:riog00000011|owl:disjointWith|_:riog00000013|||
owl:disjointWith|_:riog00000013|owl:someValuesFrom|_:riog00000014|||
owl:disjointWith|_:riog00000014|owl:someValuesFrom|ex:a|||
owl:disjointWith|_:riog00000014|owl:onProperty|ex:part-of|||
owl:disjointWith|_:riog00000014|rdf:type|owl:Restriction|||
owl:disjointWith|_:riog00000013|owl:onProperty|ex:develops-from|||
owl:disjointWith|_:riog00000013|rdf:type|owl:Restriction|||
owl:disjointWith|_:riog00000011|owl:someValuesFrom|_:riog00000012|||
owl:disjointWith|_:riog00000012|owl:someValuesFrom|ex:B|||
owl:disjointWith|_:riog00000012|owl:onProperty|ex:part-of|||
owl:disjointWith|_:riog00000012|rdf:type|owl:Restriction|||
owl:disjointWith|_:riog00000011|owl:onProperty|ex:develops-from|||
owl:disjointWith|_:riog00000011|rdf:type|owl:Restriction|||

in this case, to fetch all axioms for class ex:a or ex:B we need to iteratively query to walk up the graph

Good edge case. Thanks!

I tried this locally and got the same output. I'm surprised that the stanza is being set to "owl:disjointWith". It should be
"_:riog00000011" because that's the top-level node. So I think there's a bug.
But even so, your point stands about the stanza not capturing this.


Thoughts on how to make it more obvious you're in an editable standard now? Shading / header / transition experience?

After making a copy of a standard, it wasnt immediately obvious this was theirs to edit. It's a pretty quick transition. Any ideas how to make it more obvious this is yours?

I added this little label that says "My Work Schedule"

Also, the pencils help


Replace translation system

The current one is simply horrible to manage. Unfortunately I have no idea yet what I should do instead. I don't want any user-facing strings in code, which disqualifies most popular existing systems.

Well, it's better now. Translation stuff is now generated during compilation through a .json. It should be fairly simple to convert that data to another format if needed in the future.


typo LinearRring -> LinearRing

Coverage remained the same at 80.252% when pulling e09b30192ab13f513b7607de8c84c3bbaa5d379b on kannes:patch-2 into c6053d0efc90e43fccecfa5bf734bfc8935b772b on Toblerity:master.

Coverage remained the same at 80.252% when pulling e09b30192ab13f513b7607de8c84c3bbaa5d379b on kannes:patch-2 into c6053d0efc90e43fccecfa5bf734bfc8935b772b on Toblerity:master.

Coverage remained the same at 80.252% when pulling e09b30192ab13f513b7607de8c84c3bbaa5d379b on kannes:patch-2 into c6053d0efc90e43fccecfa5bf734bfc8935b772b on Toblerity:master.

Coverage remained the same at 80.252% when pulling e09b30192ab13f513b7607de8c84c3bbaa5d379b on kannes:patch-2 into c6053d0efc90e43fccecfa5bf734bfc8935b772b on Toblerity:master.

Calm down, coveralls!

Thanks!


Missing Dockerfile for Grafana-Renderer?

hello,
im trying to understand the usage of grafana-renderer found in the helm chart. I believe it is disabled by default but i also do not understand the usecase
i also could not find the dockerfile for the supposed image, and the image uploaded is over a year old on ghcr so i was not sure if something like this is maintained and if i should be using the image
thanks !

Hi @Shamim56 ,
The Grafana renderer can be used to render Grafana dashboards and send it as a notification.
The implementation of it can be found here:
https://github.com/robusta-dev/robusta-puppeteer
This action for example uses it: https://github.com/robusta-dev/robusta/blob/b2348bb346e34e05a9d44b376f4a47241441061d/playbooks/robusta_playbooks/deployment_status_report.py#L44
The typical use case is sending some Grafana dashboards after a deployment was created
Does that help?

Yes it makes sense now, thank you. I think that link for the implementation is private, it returns a 404

you're right @Shamim56
I made it public


Bugfix scaling units

(fix #64)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

37 of 37 (100.0%)  changed or added relevant lines in 4 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.01%) to 80.735%

Files with Coverage Reduction
New Missed Lines
%

src/qa4sm_reader/plotter.py
3
81.86%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
1683

Relevant Lines:
1982

💛  - Coveralls

Also, the last box plot above doesnt look very nice

Also, the last box plot above doesnt look very nice

true but thats that plot looks the same with another unit

Also, the last box plot above doesnt look very nice

true but thats that plot looks the same with another unit

that doesn't make it look any nicer ;)

can be my next task :)


Support custom mountpoints under /var (COMPOSER-2301)

This PR adds initial support for specifying custom mountpoints while creating a disk image.  We define a new mountpoint policy internal to BIB, separate and more restrictive than the ostree mountpoint policies in osbuild/images.  The rules are:

/ and /boot are supported for modifying their size.
Custom mountpoints under /var that do not become symlinks to other paths are supported.
/var itself is not.

The combination of 2. and 3. isn't directly supported in our policy checkers, so instead the policy in this PR initially allows for /var and its subdirectories, but then makes an explicit check that /var itself isn't in the custom filesystems in the blueprint.
Btrfs subvolumes are not supported because they are mounted with the parent disk at the location where they are created, so it is not possible to run bootc install to-filesystem with an empty root fileystem (see also https://github.com/osbuild/images/pull/846).  Since mountpoints cannot be created at paths that will contain data on or before first boot, a workaround for this would be to create subvolumes on first boot (manually or otherwise).  We could enable this with firstboot scripts if necessary.
The discussion in #579 should provide further context for the limitations.

The error messages we test for will change once https://github.com/osbuild/images/pull/853 is merged and pulled in here, but we can deal with that separately if this gets merged first.

I think everything's sorted now.

IOW it'd be helpful I think if the PR included changes to the docs in this repo at least.

I've updated the README with information on the new customizations.

It seems some unit test is failing so I won't appove just yet but it looks very close.

Yeah, I spotted those too but was waiting for the full result to address them (running locally was taking too long last night and I had to stop).  I'll get to them now.

It seems some unit test is failing so I won't appove just yet but it looks very close.

The issue was the fallback logic for the root filesystem type in cross-arch builds.  I made some changes to the internal logic there, making it an error if it's not set from outside the Manifest() call.  I think I prefer the explicitness.

I think this change stands alone and makes sense on its own; but we did also discuss supporting fully custom toplevel mount points like /data or whatever - is that a followup?
There's also the case for e.g. /mnt (a default empty toplevel directory)

I think this change stands alone and makes sense on its own; but we did also discuss supporting fully custom toplevel mount points like /data or whatever - is that a followup?

Yes, after our discussion in #579, I decided the quickest way to get something working is this.  Top-level mounts will need to be handled differently (.mount units?), so once we figure all that out, we can have it work the same way for everything.

Needs a bit more work for fs type handling and cross-arch builds.

The new commits (last 3) add tests as well as a behaviour change: All filesystems now inherit the type from the rootfs.  This includes /boot, which so far was always ext4 even when / was xfs.
The new commits also fix the cross-arch scenario by "forcing" ext4 regardless of the selected rootfs type.  The commit messages have more details.

I applied @mvo5's patch for splitting out the PT handling and adds tests.
I also rebased on main and resolved the conflicts.

It fails right now with:
____ test_image_boots[quay.io/centos-bootc/centos-bootc:stream9,raw,arm64] _____
...
            # NOTE: xfs filesystems are ~40 MiB and ext4 ~26 MiB smaller than the partition - reduce minsize by 100 MiB
            minsize -= 100 * 2 ** 20
>           assert minsize < mountpoint_sizes[mountpoint]
E           assert<PHONE_NUMBER> <<PHONE_NUMBER>

test/test_build.py:483: AssertionError

in

It fails right now with:
____ test_image_boots[quay.io/centos-bootc/centos-bootc:stream9,raw,arm64] _____
...
            # NOTE: xfs filesystems are ~40 MiB and ext4 ~26 MiB smaller than the partition - reduce minsize by 100 MiB
            minsize -= 100 * 2 ** 20
>           assert minsize < mountpoint_sizes[mountpoint]
E           assert<PHONE_NUMBER> <<PHONE_NUMBER>

test/test_build.py:483: AssertionError

Yup, that size comparison isn't great.  Was a bad idea to just take a chunk out of the expected size and call it a day.  I dropped the check and we can replace it with something a little smarter (see last commit), but I think we should leave that for another PR.
The partition sizing is either way tested at the manifest level.  The boot test now checks that all mountpoints exist when the system is booted.

Thanks, this is fine! We could look into cleaning up the commit history a bit, but it's probably fine as is.

It did get a bit long, I agree.


Verify that firewall is still there when reconciling infrastructure.

Closes #15.
I added a validation section if the firewall still exists and belongs to this cluster in the infrastructure reconciler.
This change would cause re-creation of cluster firewalls because I added a machine tag used for identifying if a firewall belongs to a cluster or not.

In the delete Firewall actuator we should check for machineID and ProjectID and probable ClusterTag as well

Added the find request to the delete reconcile algorithm as well.

I would say... let's just try it out and fix if there are issues.


onUpdate (and onCreate) function triggered when document is written for the first time

[READ] Step 1: Are you in the right place?
[REQUIRED] Step 2: Describe your environment

Operating System version: MacOS Mojave 10.14.4
Firebase SDK version:
Python:
firebase-admin==3.1.0; google-api-core==1.14.3; google-api-python-client==1.7.11; google-cloud-core==1.0.3; google-cloud-firestore==1.5.0
Node:
"firebase-admin": "^8.0.0"; "firebase-functions": "^3.1.0"
Library version: _____
Firebase Product: Firestore; Functions

[REQUIRED] Step 3: Describe the problem
When using Python Firestore client (Admin SDK) to add (collectionRef.add) a document to a collection both onUpdate and onCreate function triggers are called. Only onCreate should be called.
Note: node Admin SDK produces expected result in functions.
Steps to reproduce:

Write and deploy 2 Firestore functions:  onCreate and onUpdate
Add document with data to a collection
Check functions logs and see that the onCreate function was called as well as the onUpdate

Relevant Code:
Functions index.js:
const functions = require("firebase-functions");

exports.onNewMessageLength = functions.firestore
  .document("messages/{messageId}")
  .onCreate((snap, context) => {
    console.log("Data: ", snap.data());
    return 0;
  });

exports.onUpdatedMessageLength = functions.firestore
  .document("messages/{messageId}")
  .onUpdate((change, context) => {
    console.log("Data: ", change.after.data());
    return 0;
  });

Note:  https://github.com/firebase/firebase-functions/issues/571
Python:
import firebase_admin
from firebase_admin import credentials
firebase_admin.initialize_app()
from google.cloud import firestore
db = firestore.Client()
db.collection('messages').add({'message':'Hello from Python'})

Result: logs show both onCreate and onUpdate are called.
The outcome of the equivalent Node app seems to be correct. Only onCreate called as documented.
Node:
var admin = require("firebase-admin");
var serviceAccount = require(<PATH_TO_FILE_WITH_JSON>)
admin.initializeApp({credential: admin.credential.cert(serviceAccount), databaseURL:<DB_URL>})
const dbfs = admin.firestore();
dbfs.collection('messages').add({message:'Hello from Node'})

Result: only onCreate is called

Please report all Functions-related issues in the Functions repo.


Understanding Clair's Workflow

Hi,
I'm trying to understand all the operations done during the analysis process with Clair for my university studies.
I found in Slides and Videos of Events valuable allies to achieve this knowledge, but i have a missing blind spot of what happends when Worker passes the tarball of layers to the detectors. How do they extract the information? Do they mount layers somewhere to do the thing?
I searched this in old PRs but i didn't find nothing so specific.

Hi,
Layers are just tarballs. Clair extracts the files required for parsing features in memory and stores them in a map. These files are used to determine the namespaces within an image and the features installed in that image.

closing due to inactivity


Trigger events when users click list items

"Would it be possible to trigger an event like qualitySelected when a user click on the menu list item?
It could be useful to track users' preference among the listed choices."
https://github.com/jfujita/videojs-http-source-selector/issues/18

Could you explain it more precisely? With any image like where should the event get triggered?

Could you explain it more precisely? With any image like where should the event get triggered?

Not sure what you mean by image?
It should be triggered somewhere in this function and pass the currently selected option.
https://github.com/FreeTubeApp/videojs-http-source-selector/blob/43e03b62706912ed3ede9c971e47a4468f0c7197/src/components/SourceMenuItem.js#L29
Here's an example of how videojs triggers events:
https://github.com/silvermine/videojs-quality-selector/blob/a40e9a680382023bdde8b240e3093142b905343f/src/js/components/QualityOption.js#L40


Adjusted dotrc creation process

I noticed on my systems (all Fedora 30) that the dotrc creation is bugged and fails because it does not create the ~/.config/dot directory, and therefore cannot copy the example dotrc to ~/.config/dot/dotrc.
I added two functions and variables to common.sh:

tp_green and tp_red: similarly to tp_bold, these change the foreground colors to green and red, respectively, through tput setaf #.
grn_ and rd_: again, similarly to bd_, these can be quickly used to adjust echo text and then reset to defaults, all through tput.

In dot_config.sh, I adjusted the process for copying the dotrc file. In the original process, the script would echo the command that was to be executed before proceeding to execute it.
I have adjusted this to use printf to allow the newline to be dropped, then used the newly created functions mentioned above to clearly show the outcome of the command. In between, I added a couple if statements to test for the file and directory, and abort in the case of any failures.

@nsstrickland
Thank you for your pull request and sorry for the late response.
Almost all changes is OK for me, but to avoid namespace pollution,
Chane the function cleanup_namespace like:
cleanup_namespace() {
  unset -f dotbundle get_fullpath path_without_home path_without_dotdir
  unset -f __confirm prmpt bd_ grn_ rd_ dot_usage parse_linkfiles $0
}

Sorry for my late response, as well! Added both functions to cleanup_namespace().

@nsstrickland
Thank you !


Transform maxclauses fix

Issue #, if available:
Description of changes:
Refactored Transform job to be able to limit amount of modified buckets being processed at a time.
Also added capping of pageSize so that we don't trip that maxClause exception.
CheckList:

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #477 (dce28b9) into main (307ed55) will increase coverage by 0.13%.
The diff coverage is 87.69%.

@@             Coverage Diff              @@
##               main     #477      +/-   ##
============================================
+ Coverage     75.69%   75.82%   +0.13%
- Complexity     2460     2468       +8
============================================
  Files           314      315       +1
  Lines         14456    14505      +49
  Branches       2236     2244       +8
============================================
+ Hits          10943    10999      +56
+ Misses         2253     2245       -8
- Partials       1260     1261       +1

Impacted Files
Coverage Δ

.../org/opensearch/indexmanagement/util/IndexUtils.kt
77.63% <ø> (ø)

...earch/indexmanagement/transform/TransformRunner.kt
78.69% <85.71%> (+0.68%)
:arrow_up:

...ndexmanagement/transform/TransformSearchService.kt
68.33% <87.50%> (+0.51%)
:arrow_up:

...anagement/transform/TransformProcessedBucketLog.kt
93.33% <93.33%> (ø)

...ndexmanagement/transform/model/ExplainTransform.kt
50.00% <0.00%> (-28.58%)
:arrow_down:

...nt/indexstatemanagement/model/destination/Slack.kt
55.55% <0.00%> (-22.23%)
:arrow_down:

...ansform/action/explain/ExplainTransformResponse.kt
79.31% <0.00%> (-6.90%)
:arrow_down:

...anagement/indexstatemanagement/model/Transition.kt
61.64% <0.00%> (-4.11%)
:arrow_down:

...gement/transform/model/ContinuousTransformStats.kt
70.37% <0.00%> (-3.71%)
:arrow_down:

...arch/indexmanagement/rollup/RollupSearchService.kt
57.40% <0.00%> (-3.71%)
:arrow_down:

... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Some high level comments:

Want to confirm is the root cause of this max clause tripping problem this getQueryWithModifiedBuckets populating too many filter queries when there are too many modified buckets?

Since we are now paginating one execution of continuous transform, do we also need to change this line: +1 on pageProcessed. e.g. Say the page size specified by user is a large number like 10000, it seems we have to cap it to a smaller value like 500 when executing the transform iteration, then page processed will +1 after 20 iterations. What do you think? @petardz


[FEATURE REQUEST] VS Code workspace at repository's root level / multi-root workspace

Is your feature request related to a problem? Please describe.
VS Code has two kinds of workspaces: Single-folder and Multi-root (see docs).
Epiphany currently uses only the Single-folder type, which is located in core\src\epicli sub-directory. Settings from it are applied to devcontainer and are present after opening this folder. However, Epiphany repo contains also directories and files at the root level (e.g. docs, tools, changelogs) so developer has a need to work at the root level as well but there is no workspace (settings) defined at that level. VS Code will create .vscode directory after changing settings but there is no such folder in Git repo.
As workaround developers have their own settings - so there is no standard rules to follow (e.g. for Markdown extension).
Describe the solution you'd like
Introduce Multi-root workspace.

Multi-root workspaces allow you to configure multiple distinct folders to be part of the workspace. Instead of opening a folder as workspace, you will open a .code-workspace JSON file that lists the folders of the workspace.

Describe alternatives you've considered
Add/move workspace at the root level.
Additional context
We also need to improve the structure of directories (simplify). This will be done in separate task (after #2533).

DoD checklist

[ ] Changelog updated
[ ] COMPONENTS.md updated / doesn't need to be updated
[ ] Schema updated / doesn't need to be updated
[ ] Feature has automated tests
[ ] Automated tests passed (QA pipelines)

[ ] apply
[ ] upgrade

[ ] Idempotency tested
[ ] Documentation added / updated / doesn't need to be updated
[ ] All conversations in PR resolved
[ ] Solution meets requirements and is done according to design doc
[ ] Usage compliant with license
[ ] Backport tasks created / doesn't need to be backported

I feel this has been all addressed with the major workspace overhaul we did for 1.3 so closing this.


[base] Add status_t for universal status reporting

status_t is modelled after absl::Status and uses the same error
categories.

Ok status codes can carry any positive integer value from [0 .. INT_MAX].
Error status codes carry the error code, the module id that
created the error (the first 3 letters of the filename) and a
parameter in the range [0 .. 2047] that, by default, is the
source line number in the module that created the error.
A nonstandard printf specifier %r prints out a text representation
of the status value.

The c++ standard is changed from c++14 to gnu++14.  The preprocessor
macro magic used to create the error values is not turned on by
-std=c++14 (ie: this change needs the comma elision behavior of
##__VA_ARGS__).  Lamentably, standard c++20 replacement __VA_OPT__(,)
does not work when -std=c++14.
Signed-off-by: Chris Frantz<EMAIL_ADDRESS>

Alphan suggested that the cryptolib might also want to standardize on these error codes.

Yep, we've talked about it before and that's the plan as far as I'm concerned :slightly_smiling_face:

The c++ standard is changed from c++14 to gnu++14. The preprocessor
macro magic used to create the error values is not turned on by
-std=c++14 (ie: this change needs the comma elision behavior of
##__VA_ARGS__). Lamentably, standard c++20 replacement __VA_OPT__(,)
does not work when -std=c++14.

We can also change it to c++20 if you want (fwiw I'd prefer that over gnu++14).


Fix help

Signed-off-by: Josh Soref<EMAIL_ADDRESS>

/assign @munnerz

fwiw, this is not actually final, as there's a typo in the implementation, which I'll fix shortly...

/ok-to-test
/lgtm
/approve
Thanks for this!


Service sec

Description
improve the service section  and content
(issue)
#145  , level3 , gssoc extd , enhancement

Could you please add the "Hacktoberfest-accepted" label .This will ensure my contributions are counted towards Hacktoberfest.

Type of Change

make navbar of service Responsive of active link
form for booking mui ( pop ups)
improve the contents such as
pink cab
normal city travels
special occasions
hourly rentals
app specification
24/7
footer with link

stack

HTML,CSS,JS,MUI,animations,verification for mui
used gif , img , icon

screenshots

@Web-Dev-Learner
This is having some conflicts, resolve and then recreate the PR

Admin please assign me this task and I'll improve it .....

https://github.com/07sumit1002/CabRental/pull/315

I have completed the work related to service section on the improve-cab-service branch.

All checks have passed successfully.

There are no conflicts with the base branch.

The workflow is awaiting approval.

Could you please review and approve the workflow, and merge the PR

https://github.com/07sumit1002/CabRental/pull/202

screenshots


V2 Ideal Image functionality

🐛 Bug Report
The Ideal-Image plugin is not currently functioning as described on the documentation page. It does display an LQIP placeholder image, as described, but the various sizes of the image are not generated or used. The plugin does some processing as the filesize of the image changes (increases slightly), but it does not resize the images. The React Ideal Image library that I think this is based on is outstanding, so it'd be lovely if we can get it up and running.
Have you read the Contributing Guidelines on issues?
Yes
To Reproduce
I had an (unrelated?) issue getting it to work on codesandbox. The plugin had trouble resolving. Here's the codesandbox demo.
Instead, I spun up a vanilla site and created a nearly identical test hosted on github.
test code: https://github.com/ionic-team/docusaurus-test/blob/main/src/pages/test.tsx#L25-L48
source image: https://github.com/ionic-team/docusaurus-test/blob/main/static/img/open-graph.png
processed image: https://github.com/ionic-team/docusaurus-test/blob/gh-pages/ideal-img/open-graph.11d76e2.1200.png
(Write your steps here:)

Clone https://github.com/ionic-team/docusaurus-test
npm i && npm run build && npm run serve
visit http://localhost:3000/test

Expected behavior

(Write what you thought would happen.)
You would expect each test image to be resized according to their description, many using the srcset img attribute to allow for different images at different screen sizes.
Actual Behavior

(Write what happened. Add screenshots, if applicable.)
The images used are full sized and only slightly different filesize than the original image. In fact, despite the many tests, only one png and one jpg are generated.
Top: original image. Bottom: slightly modified but still full-sized image

Full-size image used when it should be smaller

Your Environment

Public source code: https://github.com/ionic-team/docusaurus-test
Public site url: http://docusaurus-test.ionic.io/test/
Docusaurus version used: 2.0.0-alpha.70
Environment name and version (e.g. Chrome 78.0.3904.108, Node.js 10.17.0): Safari 14.0.3, node 14.12.0
Operating system and version (desktop or mobile): Mac OS 11.2 Beta

Reproducible Demo
If possible, use https://new.docusaurus.io to create a CodeSandbox reproducible demo of the bug.
http://docusaurus-test.ionic.io/test/
(Paste the link to an example repo, including a docusaurus.config.js, and exact instructions to reproduce the issue.)
https://github.com/ionic-team/docusaurus-test
https://github.com/ionic-team/docusaurus-test/blob/main/docusaurus.config.js

Hi,
I'm not too familiar with this plugin of our codebase and the original author is not there anymore.
Will have to retro-engineer bit all this a bit to understand what is happening, particularly as we seem to be using a fork https://github.com/endiliey/react-ideal-image)
We use it on Docusaurus site Showcase and it seems to actually resize images:
https://v2.docusaurus.io/showcase

And I also see that the smaller size of 640px is used if I simulate a 300px width mobile device (not much more, probably because of my retina screen at it may try to download x2 images?).
It does not seem to use srcset in our site showcase, but there's a srcset prop according to the doc here: https://github.com/endiliey/react-ideal-image
Maybe it's just a lack of documentation?
Note you probably know this already but this plugin only works for the production build, so the codesandbox may not be the most convenient way to debug this.

I don't have too much bandwidth currently to investigate this, unfortunately.
It is a plugin, so this means if you really need something right now, you could try to build your own solution.

Thanks,
We have a ways to go in migrating our current site over, and this is a feature not implemented in our current site either. So fixing it means an SEO gain, but nothing is lost without it. An alternative approach would be to use an image processor proxy like Imgix. In the next few weeks, I'll evaluate whether it'd be better/faster for us to get this working or just use a proxy. Thanks and keep up the great work!

@perrygovier it's probably not obvious from the documentation, you should configure the plugin behaviour in docusaurus.config.js, not via props of Image component. See the Docusaurus config as an example:
https://github.com/facebook/docusaurus/blob/c8cf48a355b01356c0be541a4c16a1907ad0bc3a/website/docusaurus.config.js#L139-L147

Ah, that makes a lot of sense. Thanks!


Prevent sentry reporting while developing

Using yargs to parse build arguments, we can leverage esbuild to replace placeholder text. Only the release script will supply the needed flag for the real value to be inserted.

We can actually remove it from the userscript builds, it gets intentionally left out of those currently Sentry was getting too many errors from other userscripts.


Custom building package with different path

Hello, folks
Currently I have an unconventional folder structure that looks like this:
...
project/
    └───src/
        └───backend/
            └───project/
                 │   file1.py
                 │   ...
        └───frontend/
            └───project/
                 │   file.js
                 │   ...
...

Was wondering if there is a way to specify the src/backend/project as project when building the package as it happens when its just src/project? I was able to build the thing by specifying project.name = "backend.project", but it ends up creating a package named backend.project which is fine, but the imports of course will be messed up. So I assumed that specifying tool.flit.module.name = "project" would sort of fix the problem. Package would be "misnamed", but everything else would remain the same, but it doesn't as it breaks with:
Traceback (most recent call last):
  File "path_to_module", line 5, in <module>
    from project.manage import main
ModuleNotFoundError: No module named 'project.manage'

Meaning that that tool.flit.module.name does not work as intended (at least for this case). Am I missing something? Apparently flit only accepts 2 layouts src/project or project with no workarounds?

Sorry, there's no way to configure it for that precise situation. Flit expects your Python package (project/ containing .py files) to be either in the same directory as pyproject.toml, or in a src/ subdirectory. Those are the only possibilities it checks.
It doesn't insist that pyproject.toml is in the repository root directory, though - so you could have something like:
project/
    └───src/
        └───backend/
            │   pyproject.toml
            └───project/
                 │   file1.py
                 │   ...

Then you'd run flit from inside the backend directory.
I'm going to close this because I don't plan to implement more config around this - Flit aims for simplicity over supporting all possible cases.


DocViewer does not have a construct or valid call signatures

I am following the documentation and importing DocViewer like so:
import DocViewer, { DocViewerRenderers } from '@cyntler/react-doc-viewer'

const Component: React.FC = () => {
  return {
     <DocViewer/
          documents={[uri: <http>, fileType: 'pdf']}
          pluginRenderers={DocViewerRenderers}
     >
  }
}

I get the following error:

When I try to do module augmentation, this error goes away:

However this results in this error:
`Uncaught SyntaxError: ambiguous indirect export: DocumenViewe;
How can I solve this?

Same here, any solutions ?

Same here, any solutions ?

Hey, I got it to work using this:
`
import DocViewer, { DocViewerRenderers } from '@cyntler/react-doc-viewer';
import { type DocViewerProps } from<EMAIL_ADDRESS>const DocumentViewer = DocViewer as unknown as React.FC;
// Some react code

`
Hope this helps.


Heroku One Click deploy added

Notion card
Summary
The user can deploy the Miru app in Heroku by clicking on a single button.
Preview

Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to
not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?

Checklist:

[ ] I have manually tested all workflows
[ ] I have performed a self-review of my own code
[ ] I have added automated tests for my code

@akhilgkrishnan Can you add a preview video to the PR? We can attach it to the readme.MD as well


Build fails with Java > 8

With Java 11 I see for example
[ERROR] Failed to execute goal de.empulse.eclipselink:staticweave-maven-plugin:1.0.0:weave (default) on project annotation-tool-impl: Execution default of goal de.empulse.eclipselink:staticweave-maven-plugin:1.0.0:weave failed: An API incompatibility was encountered while executing de.empulse.eclipselink:staticweave-maven-plugin:1.0.0:weave: java.lang.ExceptionInInitializerError: null
[ERROR] -----------------------------------------------------
[ERROR] realm =    plugin>de.empulse.eclipselink:staticweave-maven-plugin:1.0.0
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/home/jules/.m2/repository/de/empulse/eclipselink/staticweave-maven-plugin/1.0.0/staticweave-maven-plugin-1.0.0.jar
[ERROR] urls[1] = file:/home/jules/.m2/repository/org/eclipse/persistence/org.eclipse.persistence.jpa/2.6.4/org.eclipse.persistence.jpa-2.6.4.jar
[ERROR] urls[2] = file:/home/jules/.m2/repository/org/eclipse/persistence/javax.persistence/2.1.1/javax.persistence-2.1.1.jar
[ERROR] urls[3] = file:/home/jules/.m2/repository/org/eclipse/persistence/org.eclipse.persistence.asm/2.6.4/org.eclipse.persistence.asm-2.6.4.jar
[ERROR] urls[4] = file:/home/jules/.m2/repository/org/eclipse/persistence/org.eclipse.persistence.antlr/2.6.4/org.eclipse.persistence.antlr-2.6.4.jar
[ERROR] urls[5] = file:/home/jules/.m2/repository/org/glassfish/javax.json/1.0.4/javax.json-1.0.4.jar
[ERROR] urls[6] = file:/home/jules/.m2/repository/org/eclipse/persistence/org.eclipse.persistence.jpa.jpql/2.6.4/org.eclipse.persistence.jpa.jpql-2.6.4.jar
[ERROR] urls[7] = file:/home/jules/.m2/repository/org/eclipse/persistence/org.eclipse.persistence.core/2.6.4/org.eclipse.persistence.core-2.6.4.jar
[ERROR] urls[8] = file:/home/jules/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[project>org.opencast.annotate:annotation-tool-api:0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
[ERROR]
[ERROR] -----------------------------------------------------
[ERROR] : NullPointerException
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <args> -rf :annotation-tool-impl

I made CI use Java 8 for now: bd47f08545f8e3ce29642dbf6083ae9c0d5f0f0b
But in the long run, we need to fix this.

Should be fixed in 5f674fbd8d3190bcdd536ebb95d41570619cca99


Can winappdriver access dyalog apl based elements/applications.

I would be working on application based on c# and dyalog apl. I wanted to know if winappdriver can access dyalog apl application

Does inspect show the UI elements?

I am working on setting up inspect.exe.
I wanted to know if there is any prior experience or documentation regarding dyalog apl elements with winappdriver.

if you can get the elements in inspect.exe, you can use WAD.
There is no documentation

You can also use WinAppDriver UI Recorder to inspect the elements of your application. It can be downloaded from the releases section of this repository. No installation needed, just unzip & use.

closing issue as i am using inspect exe and as per anunay1, no documentation is present.


Increase column width when listing releases

After #1560 was merged, names of releases can now be up to 53 characters long, up from 14 previously. When listing releases, the maximum column width is 30 characters, meaning it's not possible to get the full name of releases using the full available length.
This change just increases the maximum column width to 60, to allow for longer release names.
PS.
I'm working on getting a CLA signed by my employer, even if it does seem a bit silly for such a small change. :)

This change is

I messed up when trying to fix incorrect email, I'll give it another go with correct email from the start.


Testing pre-push hooks with Graphite

#2324  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @sgrimm and the rest of your teammates on  Graphite


Create prometheus.md

Description of the change

Checklist
Please make sure that the proposed change checks all the boxes below before requesting a review:

[x] I have reviewed the guidelines for contributing to this repository.
[x] The preview looks fine.
[x] The tests pass.
[x] The commit history is clean and meaningful.
[x] The pull request is opened against the main branch.
[x] The pull request is no longer marked as a draft.
[x] You agree to license your contribution under the MIT license to Spacelift (not required for Spacelift employees).
You have updated the navigation files correctly:

[ ] No new pages have been added, or;
[x] Only nav.yaml has been updated because the changes only apply to SaaS, or;
[ ] Only nav.self-hosted.yaml has been updated because the changes only apply to Self-Hosted, or;
[ ] Both nav.yaml and nav.self-hosted.yaml have been updated.

If the proposed change is ready to be merged, please request a review from @spacelift-io/solutions-engineering. Someone will review and merge the pull request.
Spacelift employees should request reviews from the relevant engineers and are allowed to merge pull requests after they got at least one approval.
Thank you for your contribution! 🙇

@adamconnelly Let me know if my updates resolved the issue to merge.

@adamconnelly Let me know if my updates resolved the issue to merge.

The nav changes look good, thanks.
I think we still need to figure out what's happening with this comment though: https://github.com/spacelift-io/user-documentation/pull/348#discussion_r1352876756.
If you want to merge as-is, I think we should remove those points, otherwise the docs page is going to look really weird. What's the plan, are you wanting to merge this as a placeholder page, and then someone else picks it up to finish, or are you wanting those sections filled out before the change is merged and goes live?

@adamconnelly I removed the bulleted points for now.


Issue170 page toc overflow

Description
Introduces a new grid layout class called .d-gl-aside to accommodate "[sidebar] [main] [sidebar]" layouts. It also removes dozens of the explicit character unit width declarations (d-w75ch), which caused an issue in which main content would overflow beyond its parent container. This should fix #170
Because of how CSS grid targets, I also needed to move the TOC aside to be a sibling of main and nav.
In an effort to improve responsiveness, this PR also adds md:d-d-block to the element with the CSS Grid class. This makes the main content area a full-width block element at 640px and below.
In truth, I would prefer not to stop using CSS Grid at certain breakpoints and instead just change the grid-template-areas, but I can't figure out how to do so with this immutable utility class approach.  If there's a better way to do this, I'm all-ears.
Before

After

Pull Request Checklist

[ ] Ask the contributors if a similar effort is already in process or has been solved.
[X] Review the contribution guidelines.
[ ] Use staging as your pull request's base branch. (All PRs using production as its base branch will be declined).
[X] Ensure all gulp scripts successfully compile.
[X] Update, remove, or extend all affected documentation.
[X] Provide a description what is being changed, extended, or removed.
[X] Link to any issue(s) this request is resolving.
[ ] Ensure no private Dialpad links or info are in the code or pull request description (Dialtone is a public repo!).
[X] Request a review from Drew Chandler, Joshua Hynes, or Ted Goas.

Obligatory GIF

@dialpad-drew I'm not sure we would use this class beyond this documentation site. Anywhere else in the product that we have a similar three column layout, the right sidebar acts more as a drawer that opens, closes, or expands over content. I wonder if the responsive display classes would solve this problem better. 🤔

@dialpad-drew I'm not sure we would use this class beyond this documentation site. Anywhere else in the product that we have a similar three column layout, the right sidebar acts more as a drawer that opens, closes, or expands over content. I wonder if the responsive display classes would solve this problem better. 🤔

Gotcha and fair point. I think the commit I just pushed accomplishes essentially the same thing I was going originally going for without adding any additional classes. I'm not sure I see a way to do this using grid-area and grid-template-areas without adding more classes, so I went with a more generic 12-col approach.
Also, was there a reason the left nav had an explicit width declaring with inline styles (width: 28rem set at nav.html:2)? I had to remove that because it was cramping the layout's fluidity by overflowing into the main content.

@dialpad-drew My only comment on this is that I feel the left sidebar should have a max width. Is there a layout where we could something like:
[ Sidebar minmax(min-content, 30rem(??))] [ Main 1fr ] [TOC minmax(min-content, 21.6rem??)]

This is also something we can clean up later as we deal with the making the header responsive.

@dialpad-drew My only comment on this is that I feel the left sidebar should have a max width. Is there a layout where we could something like:
[ Sidebar minmax(min-content, 30rem(??))] [ Main 1fr ] [TOC minmax(min-content, 21.6rem??)]

This is also something we can clean up later as we deal with the making the header responsive.

I'm sure there could be. I'm confused, though, because the instructions were "no more CSS."

@dialpad-drew My only comment on this is that I feel the left sidebar should have a max width. Is there a layout where we could something like:
[ Sidebar minmax(min-content, 30rem(??))] [ Main 1fr ] [TOC minmax(min-content, 21.6rem??)]

This is also something we can clean up later as we deal with the making the header responsive.

I'm sorry, man, but I'm not sure what you want. It kinda feels like we're going back and forth here. Since it's going to take you 90 seconds versus me a half-hour, do you mind just committing and pushing the change you hope to see?