text:
Question: Can mixins output anything other than property/value pairs?

Can I set a return value as a color?  As in:
.myselector {
   border: 1px solid .custommixin(@colorValue);
}

Just wondering in response to another user's issue regarding color functions: https://github.com/cloudhead/less.js/pull/488

Oh I see, no. But you can do..
.myselector () {
  @return: 2px;
}

.class {
  .myselector;
  border: @return solid red;
}

pretty ugly though.

Ah, of course. It might be nice to have a returned value for custom color functions (and other custom value functions) when mixin guards are in place.  @return could be a reserved variable for LESS. As you say, it's a bit ugly to just have a mixin do nothing but variable assignment when it's called.
Would be nicer to see the first example I posted supported at some point.  The rationale being that you have spin, lighten, darken, etc functioning as built-in mixins, so the logic for return values is already there in LESS, it would just be opening up the door for custom mixins.

Not I think that programming said functionality is easy mind you, just that it would empower people to extend the logic a bit.

yes, true, but I also like how it currently is, where the 'functions' are all javascript..

Couldn't variables accept arguments the same way mixins do? My usecase would be for instance:
@boxGlow(@spread: 5px, @color: #f00): inset 0 0 @spread @color;
.myselector {
   box-shadow: 1px 1px 1px #000, @boxGlow(2px, #00f);
}

It's also fairly analogous with JavaScript where functions live in regular variables.

@cloudhead: If I spent some time implementing that feature (I haven't looked at the Less source yet, so I can't promise anything), would you be willing to add it if the code is good enough?

less-plugin-functions

less-plugin-functions

Wow. Nice! Really, the only thing I'd improve syntax-wise if this is moved to core, is turning the outer block into @functions and probably dropping the leading period on the mixin declarations for consistency with how these functions are used at call sites (namely; also without the leading period, as real Less functions).
E.g.
@functions {
    foo(@x) {
        return: @x * 2;
    }
}

This still leaves the issue of having functions/mixins assignable to variables and passable as parameters, so that they can be used as lambda delegates. But this right here is already a very nice way to segregate 'computation' mixins from 'render' mixins.

Wow. Nice! Really, the only thing I'd improve syntax-wise if this is moved to core, is turning the outer block into @functions and probably dropping the leading period on the mixin declarations for consistency with how these functions are used at call sites

Yeah, we should respect this from @cloudhead :

Mixins are mixins, we must not conflate their usage with functions.

Defining a function as ".foo" by putting it in ".function" and then calling it with "foo" doesn't really make sense as a syntax.
@rjgotten The one suggestion I would make to your syntax is to not make functions plural, even if there is more than one function in the function block. Seems more Less/CSS consistent.
@function {
    foo(@x) {
        return: @x * 2;
    }
}

Also, as sugar:
@function foo(@x) {
     return: @x * 2;
}

I assume that these functions simply get added to the Less function registry as normal JS functions that evaluate a Less expression?

@rjgotten @matthew-dean :  Lovely syntax, I'd been pondering how one could "nicely" add functions to less for a while.  That syntax seems clear, intuitive and unambiguous.
One question though - is the return: part necessary?

One question though - is the  return:  part necessary?

Hmm, how do you return a value w/o writing a return statement?

Hmm, how do you return a value w/o writing a return statement?

The function could simply be an expression.
@function foo(@x) { @x * 2  }

That might actually be cleaner. So, basically, the function could be a way of abstracting expressions that evaluate to a value, instead of a block of prop / value pairs. I agree, the return: property seems like kind of a hack of the language.

Reopening since it seems like we're reconsidering this as a possibility.

@cloudhead Or maybe we really should listen to @cloudhead and create a new ticket? (Probably it was my mistake of linking instead of creating a new one... I guess I've just missed the actual reason it was closed)...

foo(@x) { @x * 2  }

Oh, no:
foo(@x, @y) {
    @z + y
    @z: pow(@x, @y);
    @x * @z + y
}

There's reason while almost every other language has a return keyword.

Yes, if you wanted to have multiple expressions in a function, then that syntax wouldn't work. You're arguing against something I didn't propose. You asked how one would have a function without a return statement, and here's how:
@function foo(@x, @y) {
   pow(@x, @y) * pow(pow(@x, @y), @y)
}

Not sure about the {} braces if it was just an expression, but yes, it could be done. SHOULD it be done is another question. And yes, we could create a new issue about functions. Whatever makes sense to you.
A different idea just popped into my head. I happen to be working on a legacy VBScript app, and the return value is assigned to the function name. This might make more sense in the context of "assigning" a value (if you wanted multiple expressions), since return: is kind of stretching the concept of a return expression. As in:
@function foo(@x, @y) {
    @z: pow(@x, @y);
    @w: pow(@z, @y);
    foo: @z * @w;
}

That way, it's not a "magic" property, but an actual assignment of value to the function.

And maybe a single expression evaluation could be sugar? Best of both worlds? Brevity and flexibility?
@function foo(@x) { foo: @x * 2;  }
// same as
@function foo(@x) { @x * 2;  }
``

As much as I dislike "automatic return" in Ruby and Groovy, this is one place where it may be nice - that being said, I'm not really opinionated either way about it, I just like few keywords LESS has.  Given the time I've wasted debugging Grails code where bugs were caused by someone accidentally returning a value where they didn't want to, I see (and somewhat agree with) your reasoning for keeping some kind of explicit return syntax.  I like that VB-syntax idea (never thought I'd say those words...).
My current use case was for a tacky little "web 2.0" gradient generator:
@function web2-control(@direction, @start, @end, @split: 50%, @spread: 5%) {
    return: linear-gradient(@direction, @start 0%, @start ((@split-@spread)), @end ((@split+@spread)), @end 100%)
}

.stupid-button {
    background: web2-control(to bottom, white, darken(skyblue, 10%));
    &:hover {
        background: web2-control(to bottom, white, skyblue);
    }
}

Judge the problem, not the intent of the code haha :)

@battlesnake It's funny, your linear-gradient example is the kind of thing that I was thinking about as far as a good use case. There are times when returning a prop/value pair is cludgy when you want to operate on a portion of a value, especially when the values themselves accept multiple values. Other examples would be the transform syntax. Sometimes mixins aren't a perfect fit.
And yes, VBScript isn't my favorite either, but a good artist pulls inspiration from everywhere. :-)

foo: @z * @w; That way, it's not a "magic" property, but an actual assignment of value to the function.

It's still the same "magic property". Difference in charcode values between f``o``o and r``e``t... won't make any logical shift (not counting that if function name overlaps with some existing property it becames another point of a reader confusion... Also count a duty to rename foo to bar each time when you copy some snippet from one function to another. So personally I can't see what could be wrong with return... It's just a "set the return value" identifier.)
As for making it optional. OK, I see now what you mean... Well, yep, this is one of those... ah, never mind: just -1 :)

I wanted the same style of linear gradient for buttons in any state, just with colour or brightness changed, so:
@primary: red;
@contrast: 10%;

@light: lighten(@primary, @contrast);
@dark: darken(@primary, @contrast);
@lighter: lighten(@primary, ((@contrast*2)) );
@darker: darken(@primary, ((@contrast*2)) );

@button-normal-bg: web2-gradient(to bottom, @light, @dark);
@button-hover-bg: web2-gradient(to bottom, @lighter, @primary);
@button-down-bg: web2-gradient(to bottom, @darker, @primary);

I'm leaning more towards the return: value syntax now - but for the one-liners, could we take on an OpenSCAD syntax like:
@function square(@x) = @x * @x;

So we make the return explicit there too by using an = and ; instead of braces.
Or to be more CSS-like:
@function square(@x) : @x * @x;

Using colon instead of equals symbol.

It's still the same "magic property".

Er, it isn't, since return is a made-up property, and foo is defined by the user, but okay. I'm not that attached to it. I just kinda wish that return didn't look like a property, and then isn't. But other than assigning to the function name, I don't have a better proposal.
@battlesnake The second option would be my preference. That makes more sense. I still wonder if single line expressions might be preferable for language simplicity. Functions could always be chained (the resulting value sent to another function).
So, I don't know. Defining a syntax for another multi-line block to output just a single value seems.... I don't know, Less already has so many. Are there really many real-world examples where a multi-line function is needed? The multi-line example was still solvable in a single line. And, if indeed, there's some need to build a complex, multi-line function, would that not be better served by an inline plugin? As far as the Less language, the need for a return statement just feels like a bad omen to me.
So, are there really real-world cases where:
a) you want to evaluate an expression,
b) it's too difficult or complex to do it in a single line (or by chaining functions)
c) it can't be in a JS plugin
?

oneliners
I still can't see any reason why I'll be forced to write
... (@a + @b + @c) * (@a + @b + @c) ;
instead of normal:

@x: @a + @b + @c;
return @x * @x;

would that not be better served by an inline plugin?

Here's simple example to illustrate how easy Less functions can kick JS functions for many use-cases (actually always unless it's about performance or some functionality that simply does not exists in Less itself),
(artificial)  Less function (less-plugin-functions format) to return a squared opacity/alpha of a color:
.function-sqralpha(@c) {
    @a: alpha(@c);
   return @a * @a;
}

Now the code necessary to do same in JS:
functions.addMultiple({
    "test-transitive" : function(c) {
        var a = c.alpha; // no guaranty this internal stays the same, but there's no easy way to reuse built-in Less function here
        //
        return new tree.Dimension( "transitive" ); // Dimension? some kind of quantum mechanics?
    }
});

And in fact the more complex (in regards of involving more and different in, intermediate and out Less value types, built-in functions resuse etc.) the function becomes the more pain it's to write in JS.
So to be honest for me the recent ideas look ehm, ... I'm not even sure... strange? :)

@matthew-dean : OpenSCAD only allows single-line functions I think, but you can get the same capability of muilti-line functions by using let blocks in OpenSCAD.  It is also a declarative language.

@seven-phases-max I'm still skeptical, and I feel like the burden of proof is on the multi-line examples. That said, return @x * @x; feels better than return: @x * @x, because it's more logically clear that the function is receiving / returning the value, rather than being assigned to a property that does...something.
But a return statement feels less and less like Less every passing moment.
As to this:

I still can't see any reason why I'll be forced to write
... (@a + @b + @c) * (@a + @b + @c) ;
instead of normal:

@x: @a + @b + @c;
return @x * @x;

The question is better stated: what is the compelling reason to add more syntax to the language just to split that expression onto two lines? The burden should be to prove a more verbose syntax with extra keywords is necessary, not the other way around. There's nothing "normal" about it, as it doesn't exist yet. And it's still not close to a real-world example. @battlesnake's example was still only a single-line expression.
@function {
    web2-control(@direction, @start, @end, @split: 50%, @spread: 5%):
        linear-gradient(@direction, @start 0%, @start ((@split-@spread)), @end ((@split+@spread)), @end 100%);
}

I like the idea of functions, but it would be disappointing if we added something heavier to the language than was absolutely needed / useful. We already have 3 types of blocks that "do things": mixins, classes/ids than can be "evaluated" and imported into scope (which makes them sort of non-parameter mixins, but they are somewhat different), and detached rulesets. If you add a functions block, all of these definitions have inconsistent syntax from each other. A mixin isn't defined with an @ keyword but a function is. A detached ruleset block is assigned with a colon (and must terminate with a semi-colon), but a mixin block isn't.
I think this should take a step back and look at the syntax as a whole. A @function syntax with a return statement may be okay, but I don't see the logical alignment between all parts of Less and this syntax. And is there logical alignment between Less functions and plugin functions? Somewhere it feels to me like we're missing some cohesion. Do you know what I mean?

That is, just consider how this looks for a moment:
.class {
  prop: val;
}
.class(@x, @y) {
  prop: @x * @y;
}
@class: {
  prop: val;
};
@function class(@x, @y) {
  return @x * @y;
}

I know that a function must be specially defined to distinguish between other blocks, but maybe that's the problem. If function says @function then mixin should say @mixin. Adding just one puts the parts of evaluated blocks in disagreement. So I'm kind of a :-1: if this is going to be the case.

@matthew-dean  I'm a bit lost then. So how exactly
@function web2-gradient(@direction, @start, @end, @split: 50%, @spread: 5%)
    return: linear-gradient(@direction, @start 0%, @start ((@split-@spread)), @end ((@split+@spread)), @end 100%)
}

instead
@function web2-gradient(@direction, @start, @end, @split: 50%, @spread: 5%) {
    return: linear-gradient(@direction, @start 0%, @start ((@split-@spread)), @end ((@split+@spread)), @end 100%);
}

solves all that problems you mentioned? Maybe then it would make sense to start with @function itself and not with {}? I did not comment @function (did you forget it who suggested @function above? :) initially just because my opinion about it as radical as always (so now it will start another syntax fight :):
to be honest personally I'd be more happy with either .function .foo, function foo, function:foo or finally foo:function (weird but at least follows :extend). Adopting Sassish way of using @at-rule syntax for new Less "directives" seems to be just too late for Less even if potentially it's indeed much less CSS-conflicting as anything else.

but I don't see the logical alignment between all parts of Less and this syntax

? So you don't really see any similarity between Less mixins and (whatever syntax) functions? I can guess many users do not understand parametric mixins at all thinking of them as some kind of a primitive "CSS-properties-batch" only, but in this particular function/mixin context, hmm...
Either way:
less-plugin-function does the whole thing in ~50 lines of code (if I remove all the plugin specific hacks) exactly because it does reuse existing core code for parsing and evaluating mixins. Providing all those documented features (you're not obligated to use) for free.
So considering this, now I only wonder how:
.class {
  prop: val;
}
.class(@x, @y) {
  prop: @x * @y;
}
@class: {
  prop: val;
};
@function class(@x, @y) : @x * @y;

can be potentially better to justify most likely more bloating implementation (+ new parsing code) to provide more limited functionality?

I like the return:  syntax - since everything that isn't a block is still a key:value pair.
Having no prefix for function names would be consistent with the current state of LESS, i.e.
color: darken(@base, 10%);
background: checkerboard(1em, lighten(@base, 20%), white);

Having no prefix for JS functions, while requiring a prefix for functions supplied in the actual LESS code seems somewhat backwards.
I personally don't see any use for multi-line functions, but I may be having a "who needs >640k of RAM" moment here.
If there was a demonstrable need for multi-line functions in future, after we had adopted the @function name(params) : expression; syntax, we could always permit it by using SCAD-style let blocks:
@function multi-line-thing(@a, @b, @c) :
    let { @sum : @a + @b + @c; @product : @a * @b * @c; @mean : @sum / 3; }
        @sum / @product ~", " @mean;

Variables in such blocks are scoped to the expression following the block only, they don't leak out to parent scope.

Everything is ruleset-like, including functions, which just look exactly the same as mixins. Really, when boiled down, the sole discriminators are that mixins can set CSS properties and that functions have to have a return statement. (You cannot and should not do both.)
So why not just rely on that behavior directly?
E.g.
.mixin(@a, @b) {
  value : @a @b;
}
.func(@a, @b) {
  return @a @b;
}

Then let the compiler figure out at the call site whether it is calling a mixin or a function and raising an exception if one or the other is used in an inappropriate context.
Alternatively, if exceptions aren't your thing:

Define the CSS output of a function called as a mixin as an empty ruleset.
Define the function return value of a mixin as the collated ruleset of all its applied CSS properties and nested rulesets, returned as a detached ruleset.

Hmm polymorphism...  it makes sense I guess, mixins can't appear on the right-hand side of a colon and functions can only appear there.  As long as we ensure that errors are raised if one is used in the wrong place, using mixin syntax for functions seems ok.

Really, when boiled down, the sole discriminators are that mixins can set CSS properties and that functions have to have a return statement.

This is what I was getting at. Should we create a new ruleset type that has a different method of "define"?
But... I also agree with this:

Having no prefix for JS functions, while requiring a prefix for functions supplied in the actual LESS code seems somewhat backwards.

I've always felt that the requirement that a mixin be prefixed with . or # is ugly and annoying. (See the first part of: https://github.com/less/less.js/issues/1342.) It's also strangely arbitrary that only two out of three types of common selectors can be converted to mixins. That's only relevant here if we allowed mixins to return values.
However, there is some reasoning to have a separate type, since function vars should not be imported into the caller scope, and functions should not have guards, as it's hard to intuit what that would even mean. So there are other differences other than being able to return values.
I'm not necessarily against @function, obviously I endorsed it earlier in the thread. I'm just wondering how this all fits together, and I want us to be cautious. Note that my criticism is not to turn us away from using any one thing; it's to make sure we're asking all the necessary questions and thinking critically.
Even CSS breaks it's own rules sometimes, and contains things like having the vertical-align property cause two entirely different behaviors. So, Less can create new conventions as well. I just want to help make sure any new solutions keep Less easy, intuitive, conservative, and concise.

I'm a fan of limiting to single-line expressions, but if it seems too arbitrary and restrictive to others, then the multi-line form that seems most clear probably is indeed:
@function {
  foo(@a) {
    return @a;
  }
}
// and
@function foo(@a) {
  return @a;
}

Maybe the best argument for a dedicated "define" is that, different from mixins, a function definition can't or shouldn't appear multiple times (in the same scope). So they're more like @plugin functions in that regard. So, because the properties are different enough from mixins (private vars, single definition, return statement), maybe co-opting mixins just wouldn't work.

Why not allow literal javascript inside less? Basically, it'll allow you use all javascript features inside CSS to create functions. Example:
function abs(a) { return Math.abs(a); }

.test { attribute: abs(-5px); }

Note two things:

Function are literal javascript. It can be recognized by something like: "function /\w+/ ..." and stopped by last "}". The problem is identify where "{" start and where "}" ends. Because we can have some internals structures, like if, for, etc.
I don't thinked about how parameter will be passed to function. For instance, what javascript will receive if I pass 5px? And about pass less functions, like abs(convert(5px, pt))?

@rentalhost
First of all, inline javascript statements are allowed in the less.js implementation:
div {
    @x: -10.5;
    width: unit(`Math.abs(@{x})`, px);
}

Secondary, Less is designed as a CSS superset, and CSS has very few to do with C-like languages and JavaScript in particular. Thus direct JavaScript statements like function abs(a) {return Math.abs(a);} not just confusing and inconsistent there, but also directly conflicting with native language Less/CSS syntax.
So tow basic reasons why a code like should never be recommended to use and a JS-like syntax are to never be cnsidered when designing Less syntax are obvious:

Inline javascript statements require underlying JavaScript environment for the compiler (e.g. such statements will never be supported in PHP or C# or whatever else ports of Less. This is basically spoils the very purpose of the Less itself which is designed as a platform/environment agnostic self-contained language).
Fundamental "types / language entities" of CSS and JS are simply orthogonal at best and yet again directly conflicting at worst. As you already noticed yourself, there's no way for JavaScript to directly support values like 5px, red, url(//foo/icon.png) and so on and so on.  So to pass CSS values and statements to "literal javascript" you will have to provide an intermediate syntax and conversion facility to merge those orthogonal things in the same language. It's not actually a big deal to design such a language, but it will have nothing to do with Less (which is yet again designed as a CSS superset and has nothing to do with JS at all).

Please please please:
.halfway-between(@large, @small) {
    max(@large, @small) - (abs(@large - @small) / 2);
}

:smiley:

@andrewhosgood What happens here?

.halfway-between(@large, @small) {
    max(@large, @small) - (abs(@large - @small) / 2);
}
.halfway-between(@large, @small) {
    property: value;
    foo: bar;
}
.rule {
    width: halfway-between(3, 2);
}

Ultimately, a mixin is a parameterized ruleset that can have multiple matches, and returns multiple values, and a function name can only have one match (per scope) and can only return one value.
I think @battlesnake had the simplest and most straightforward syntax proposal:
@function square(@x): @x * @x;

A slight adjustment so that the scope of @x isn't confused:
@function square(@x) { @x * @x; }

Or (possibly) so that we don't confuse with JS-based functions:
@expression square(@x) { @x * @x; }

I think single-use expressions would be simplest to grok, and wouldn't pollute understanding of mixins. And, would also serve most of the examples given. Basically, you're just short-handing (aliasing) expression values for quick re-use. Thoughts?

@matthew-dean Point taken. Just trying to use existing patterns. Amending my request then, would it be:
@function halfway-between(@large, @small) {
    max(@large, @small) - (abs(@large - @small) / 2);
}

Not worried about syntax, but this would then allow me to do the thing I can't do currently.

Syntax is the hardest part to get right. And you want to get it right because it's a new language feature.
I'm a little wary of @function now, more than I was when this discussion was active in the past, just because of @plugin-defined functions and existing functions in Less.js. And without a return statement it's not very function-y.
@expr square(@x): { @x * @x };
@expr halfway-between(@large, @small): {
    max(@large, @small) - (abs(@large - @small) / 2);
};

Thinking over it more, I think the colon : assignment and the semi-colon ; terminator is more logical. In that square(@x) is being assigned the value of the evaluated expression. This would seem to keep it more in line with detached rulesets. The braces {} indicate that the scope of @x is not the surrounding scope of the statement, but what is being assigned through the expression alias.
I like this simpler concept of re-usable expressions rather than "functions" (which already means "defined by the parsing language" i.e. JavaScript). So @expression or @expr makes sense to me here. I think re-usable expressions has more wide-spread utility and is easier to understand.

I like this simpler concept of re-usable expressions rather than "functions"

Basically; they're parametrized pre-processor macro expansions like in plain old C, right? But hopefully without the crazy abuse that came with those, since Less will have @plugin functions as a far more decent alternative for the heavier lifting.

a far more decent alternative for the heavier lifting and true complex functions.

https://github.com/less/less.js/issues/538#issuecomment-107247753. Though never mind.
And I still object the inventation of the special syntax hardcoded to specific "one liner" examples. Still smells like "I love to invent new cool syntaxes" syndrome.
After all it's just asking for more issues from the parser implementation point of view... For instance recall #2785 and think how ambiguous
{
   foo();
   foo() - bar();
   bar();
}

becomes actually. There you'll have to introduce a lot of new parsing rules to detect which statement is actually the function returning value and which are just root function calls (not even counting a friendly error messages if something goes wrong).
So in short, I think everything I wrote in https://github.com/less/less.js/issues/538#issuecomment-107255583 is still in effect.
And yes, stressing the Sassish @at-rule directive yet again - never been in Less yet, so why is it going to be now? (It seems like someone is just using too much PostCSS recently ;).

@seven-phases-max
{
   foo();
   foo() - bar();
   bar();
}

I was implying that multi-statements would be invalid here (would evaluate to a single expression), so that wouldn't apply, BUT....

...stressing the Sassish @at-rule directive yet again - never been in Less yet, so why is it going to be now? (It seems like someone is just using too much PostCSS recently ;).

I haven't been using PostCSS, but yes, writing both @function and @expression made me feel somewhat dirty. As I mentioned when this issue was re-commented on, much of the syntax discussion has moved even further away from this possibility. Less just doesn't have a matching syntactical paradigm for this, because everything is declarative. Meaning, even in a return statement in a mixin, these two statements would reasonably be equal, since values are constants for a scope (once resolved).
.function-sqralpha(@c) {
    @a: alpha(@c);
    return @a * @a;
}

.function-sqralpha(@c) {
  return @a * @a;
  @a: alpha(@c);
}

So, either way, with what's discussed so far, it seems somewhat square peg / round hole. I don't think mixins can reasonably pretend to be functions (without some compromises and unexpected behavior), and defining functions (or expressions or macro expansions) via Less (that is, in your stylesheet) has proven to also be problematic.

On a separate note-
One thing that might lean us even a bit more to closing this thread: when I was looking back through comments, including the one you linked to, you had this as a not an ideal way to solve the above problem.
functions.addMultiple({
    sqralpha : function(c) {
        var a = c.alpha; // no docs and no guaranty this internal stays the same, but there's no easy way to reuse built-in Less `alpha()` here
        return new tree.Dimension(a * a); // Dimension? some kind of quantum mechanics?
    }
});

With Less 3.0, I've simplified returns so that any non-Node (other than falsey values) returned by a function is cast to an Anonymous Node, such that it's easily output into your final CSS. Obviously, if you want to include that result in another expression, you need to be explicit in the Node type. Buuuuut.... 3.0 also includes a "late parsing" feature (all values are Anonymous until referenced - this allows property referencing without creating extra parsing work or extra nodes), so that could be repurposed in order to just be like:
functions.addMultiple({
    sqralpha : function(c) {
        var a = c.alpha; // docs have started! doing my best!
        return a * a;     // Cast to Dimension because Less is cool
    }
});

And considering 3.0 should be all about functions and @plugin, and the remaining list of things it needs to release... I would say at the least, this isn't the right time for this feature. I did my best to simplify the latest examples, but even with that, your objections are valid, and I'm ok to close for now.

@seven-phases-max
#538 (comment). Though never mind.

No no; you raise a good point.
There's substantial overhead for the middle-ground, where you have more than a simple one-liner expression to do, but not enough to warrant firing up a JS plugin and writing code that handles all the node-type mappings.
While @matthew-dean raises a good point that node return types could be inferred, that still feels like a lot of overhead for some simple math.
If working a usable return into the syntax is the problem, then why not skip the explicit return statement altogether by specifying what name the out-variable will be bound to:
.answer(@a, @b):@c {
  @c   : ~"The answer is @{sum}";
  @sum : @a + @b;
}

This feels natural with the order independence and declarative nature of the Less language. It also directly extends the signature of mixin declarations in a non-ambiguous manner, which the parser can look for and which avoids the need for an @expression or @function keyword or custom at-rule.
This also means it can work together with mixin overloading and multicast calls. If a mixin is called like a function, it requires that a declaration exists which has both a matching parameter signature and a colon-separated out parameter specified. And if multiple matching overloads exist, the return value becomes a list of the relevant calls in mixin declaration order. (Just as how multiple matching overloads currently output rules in declaration order.)

Huh. That's actually not so bad.
Question: what happens then with properties, values, and other variables declared in the mixin (if called as a function). Safe to presume they're isolated from the caller scope (since properties couldn't be omitted in the location of the call, if the call is within a value expression)?
That's not bad. We expanded functions to be called everywhere. So it could be that mixins could be called everywhere with the same checks to see if the resulting output node is legal in that location. So then functions = JS and mixins = LESS.
I also liked how you addressed and resolved multiple matching mixins (a list as the result). Clever. And declarative.
I was ready to give up on this idea but this is really not bad.

We could also update the documentation that mixins, by default, "outputs" a ruleset, unless an output var (or vars, or $properties??) are specified.

WHOA.  I know I'm months late, now, but this is wrinkling my brain.  I love this.

Was there ever a solution to this

@distransient There has been more in-depth discussion around designing solutions for this in: https://github.com/less/less-meta/issues/16.
(Less-meta is a repo for higher-level goal planning for Less.js, rather than individual issues or bug reports.)

authors: andrewhosgood battlesnake calvinjuarez cloudhead distransient jacobrask matthew-dean matthewdl rentalhost rjgotten seven-phases-max


text:
vows -w can't find tests after first run

I am experiencing a weird problem. This is my console ouput
[jose@feddes2 slido]$ vows ./test/* --spec --watch -v
vows bin argv [ './test/slideGeneratorTests.js' ]
vows bin options { reporter: 'watch', matcher: /.*/ }
vows bin discovering folder structure
vows bin discovered ./test
vows watcher watching [ './test/slideGeneratorTests.js' ]
#first time I save it
vows watcher detected change in ./test/slideGeneratorTests.js
vows watcher no equivalence found, running all tests.
vows runner loading [ '/home/jose/projects/slido/test/slideGeneratorTests' ]
vows runner running SlideGenerator
✓ OK » 8 honored
#second time i save it (without changes)
vows watcher detected change in ./test/slideGeneratorTests.js
vows watcher no equivalence found, running all tests.
vows runner loading [ '/home/jose/projects/slido/test/slideGeneratorTests' ]
Could not find any tests to run.
#third time (without any change):
vows watcher detected change in ./test/slideGeneratorTests.js
vows watcher no equivalence found, running all tests.
vows runner loading [ '/home/jose/projects/slido/test/slideGeneratorTests' ]
Could not find any tests to run.

I have the same issue as well.
Vows looks so unmaintained compared to before.
Where is Cloudhead?

source: gharchive/issue

authors: jfromaniello johnnywengluu

repo: cloudhead/vows

license_type: permissive

license_source: github-api


text:
new:dev: Adding final code from cloudmesh/earth

I will add path of this code to the report.
S17-IO-3017

you for got to rebase, we can not accept checkins that did not rebase

I am resolving conflicts. Thanks.

source: gharchive/pull-request

authors: laszewsk nsathe

license_source: bigquery


text:
Support GitHub Webhook

change directory structure

move seaman/ -> internal/

support GitHub Webhook
change logger: zap -> slog

resolved #55

repo: cloudnativedaysjp/seaman

license: MIT


text:
[AUTOMATED] Update Version Pinning for Terraform to support 0.13

What

Update Version Pinning for Terraform to support 0.13

Why

This is a relatively minor update that the CloudPosse module already likely supports.
This allows module consumers to not individually update our Terraform module to support Terraform 0.13.

/test all


text:
Add tags to launch template

Add tags to launch template itself

Thanks @rohityadav225 ! tagged as 0.1.3


text:
Add of Metadata property to the template anatomy?

This might be a some what recent addition to templates.  I was hoping to add metadata as a section as detailed in the doc in this link.
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html
We are hoping to use that section for helping to track versions once they are deployed.
It would look something like this:
"Metadata": {
"Version": "V1.0",
"LastUpdated": "Jan 1st 2015",
"UpdatedBy": "First Last",
"Comments": "Initial Draft"
},

Please give the patch above a try to see if it meets your needs.

That update seems to be working great!
Thank you for tackling this so quickly.
Much appreciated! =)

No problem, thanks for reporting the issue. This just got pushed out in v1.1.2.

authors: markpeek rackerroush

repo: cloudtools/troposphere


text:
Public Hosted Zone  using troposphere

Can we create a public hosted zone using troposphere..? If so can you please give me a snippet on how to do that where the hosted zone should log on the query calls to the cloudwatch log group. When i am writing the below statement it errs out. Can you please suggest where I am going wrong here.
HostedZones = template.add_resource(HostedZone(HostedZoneConfig={"Comment":"Public DNS Domain"}, Name="aws.kloudlabs.in",QueryLoggingConfig= {'CloudWatchLogsLogGroupArn':'arn:aws:logs:us-east-1:123456789:log-group:np-aws-kloudlabs:*'}))

HostedZones = template.add_resource(HostedZone(HostedZoneConfig={"Comment":"Public DNS Domain"}, Name="aws.kloudlabs.in",QueryLoggingConfig={'CloudWatchLogsLogGroupArn':'arn:aws:logs:us-east-1:1234456789:log-group:np-aws-publicdns:*'}))                                        Traceback (most recent call last):
File "", line 1, in
TypeError: init() takes at least 2 arguments (1 given)

Likely you would want to structure your code like this below (runs via troposphere but untested against AWS). The TypeError you are getting is due to name specifying the title ("zone" in this case) for the HostedZone resource.
from troposphere import Template
from troposphere.route53 import (
    HostedZone, HostedZoneConfiguration, QueryLoggingConfig
)

t = Template()
HostedZones = t.add_resource(HostedZone(
    "zone",
    HostedZoneConfig=HostedZoneConfiguration(Comment="Public DNS Domain"),
    Name="aws.kloudlabs.in",
    QueryLoggingConfig=QueryLoggingConfig(
        CloudWatchLogsLogGroupArn='arn:aws:logs:us-east-1:1234456789:log-group:np-aws-publicdns:*'
    )
))```

Thanks Mark for responding fast. So Creating public DNS thru troposphere is untested ?

No, I'm not saying it is untested through troposphere. I'm sure there are quite a few stacks created using troposphere that are creating public DNS. I meant the above snippet of code was not run through CloudFormation and I was just posting out an example that should work.

HI Mark,
Thanks for your help, Can you please point me to the code snippet which helps to create a Public hostedzone with logging enabled to cloudwatch log group. I am trying to deploy a stack through troposphere and the cloudformation stack is failing with the below error.
Error Message: The resource policy that you're using for Route 53 query logging doesn't grant Route 53 sufficient permission to create a log stream in the specified log group.

This is the code snippet that i have written,
https://pastebin.com/raw/8Sb6iXss

I have managed to resolve it. You need to set resource policy on the cloudwatch loggroup before you can deploy a public hostedzone that logs to the cloudwatch group. So you need to generate two different templtes one for cloudwatch log group and another template for public hosted zone.

authors: markpeek naveenpolamreddi


text:
automating maintenance with Github actions

tested in my fork to successfully reproduce https://github.com/cloudtools/troposphere/commit/227aa64541b3db7500f175a0bd27ce70d47b5547: https://github.com/PatMyron/troposphere/pull/1

Oh cool, thanks for putting this together as I was going to look at implementing something similar over the weekend. Some comments:

I like that it creates a PR for the changes so we can validate the changes. But given new spec files tend to come out once a week, should this run daily instead of every 5 minutes?
I was thinking something similar for PRs (such as new validators or other tweaks) to ensure a regen will give a clean git tree (meaning there aren't manual changes being made).
Should run make test and make lint (might need flake8 added as a dependency) to verify the code before moving on to the PR stage.

new spec files tend to come out once a week

Noting https://github.com/peter-evans/create-pull-request/ is idempotent, so it won't open multiple PRs, and it'll only update the existing PR if there are new changes. But feel free to slow the cadence if desired:

I was thinking something similar for PRs (such as new validators or other tweaks) to ensure a regen will give a clean git tree (meaning there aren't manual changes being made)

Good idea, should be able to re-run make regen and then run git diff --exit-code. Might open a separate PR for that

Should run make test and make lint to verify the code before moving on to the PR stage.

These currently run after the PR stage:
https://github.com/cloudtools/troposphere/blob/227aa64541b3db7500f175a0bd27ce70d47b5547/.github/workflows/tests.yml#L38-L41
Thinking it'd be useful to see the generated PR and failing tests, rather than more silently failing with no PRs being generated

Thanks!

authors: PatMyron markpeek


text:
change definition to list to match cloudformation

Fixes issue #336

Thanks!


text:
请问 为什么handler 中触发了 panic 却没有异常堆栈信息

如下图所示，我在handler 里之间 panic 了，然后用 postman 访问是 500 错误，但是控制台没有输出异常堆栈信息，请问要怎么让他输出呢

服务器启动代码如下：
func serverInit() {
	h := server.Default(
		server.WithHostPorts(viper.Conf.App.HostPort),
		server.WithExitWaitTime(60),
	)
	//h.Use(middleware.GlobalErrorHandler)
	register(h)
	h.Spin()
}

disabledLogger was returned due to zerolog's lack of call WithContext
https://github.com/hertz-contrib/logger/blob/main/zerolog/logger.go#L138

这是我 main.go 的代码
// Code generated by hertz generator.

package main

import (
	"github.com/cloudwego/hertz/pkg/app/server"
	"github.com/cloudwego/hertz/pkg/common/hlog"
	hertzZerolog "github.com/hertz-contrib/logger/zerolog"
	"os"
	"task-schedule/dal"
	"task-schedule/pkg/viper"
)

func main() {
	viper.InitViper()

	hlog.SetLogger(hertzZerolog.New(
		hertzZerolog.WithOutput(os.Stdout),     // allows to specify output
		hertzZerolog.WithLevel(hlog.LevelInfo), // option with log level
		hertzZerolog.WithTimestamp(),           // option with timestamp
		hertzZerolog.WithCaller()))             // option with caller

	err := dal.Init()
	if err != nil {
		return
	}
	serverInit()
}

func serverInit() {
	h := server.Default(
		server.WithHostPorts(viper.Conf.App.HostPort),
		server.WithExitWaitTime(60),
	)
	//h.Use(middleware.GlobalErrorHandler)
	register(h)
	h.Spin()
}

Hello @sillen102  I found that using zerolog's Ctx*** method calls zerolog.Ctx, which returns a new logger in most scenarios, causing some problems with printing because the user's configuration is missing.

Hello @sillen102 I found that using zerolog's Ctx*** method calls zerolog.Ctx, which returns a new logger in most scenarios, causing some problems with printing because the user's configuration is missing.

It's been a long time since I looked at this code but in what circumstances does it cause problems? According to the documentation from zerolog a logger should be attached to the context before calling this function. If there is no logger attached then it will use the DefaultContextLogger.
So it depends on what is the intent and what is expected. Is the expectation to associate a logger with a context that has no logger associated to it and then use it, or is the intent to use a logger already associated with the context?
I think that depending on the intent it could be as is or if it needs to be updated it could be fixed by using the other context function from zerolog like so:
// CtxLogf associate logger with context and log.
func (l *Logger) CtxLogf(level hlog.Level, ctx context.Context, format string, kvs ...interface{}) {
	logger := l.Unwrap()
	logger.WithContext(ctx)
	switch level {
	case hlog.LevelTrace, hlog.LevelDebug:
		logger.Debug().Msg(fmt.Sprintf(format, kvs...))
	case hlog.LevelInfo:
		logger.Info().Msg(fmt.Sprintf(format, kvs...))
	case hlog.LevelNotice, hlog.LevelWarn:
		logger.Warn().Msg(fmt.Sprintf(format, kvs...))
	case hlog.LevelError:
		logger.Error().Msg(fmt.Sprintf(format, kvs...))
	case hlog.LevelFatal:
		logger.Fatal().Msg(fmt.Sprintf(format, kvs...))
	default:
		logger.Warn().Msg(fmt.Sprintf(format, kvs...))
	}
}

For reference: this is the code used from zerolog:
type ctxKey struct{}

// WithContext returns a copy of ctx with l associated. If an instance of Logger
// is already in the context, the context is not updated.
//
// For instance, to add a field to an existing logger in the context, use this
// notation:
//
//     ctx := r.Context()
//     l := zerolog.Ctx(ctx)
//     l.UpdateContext(func(c Context) Context {
//         return c.Str("bar", "baz")
//     })
func (l Logger) WithContext(ctx context.Context) context.Context {
	if lp, ok := ctx.Value(ctxKey{}).(*Logger); ok {
		if lp == &l {
			// Do not store same logger.
			return ctx
		}
	} else if l.level == Disabled {
		// Do not store disabled logger.
		return ctx
	}
	return context.WithValue(ctx, ctxKey{}, &l)
}

// Ctx returns the Logger associated with the ctx. If no logger
// is associated, DefaultContextLogger is returned, unless DefaultContextLogger
// is nil, in which case a disabled logger is returned.
func Ctx(ctx context.Context) *Logger {
	if l, ok := ctx.Value(ctxKey{}).(*Logger); ok {
		return l
	} else if l = DefaultContextLogger; l != nil {
		return l
	}
	return disabledLogger
}

这不应该，因为我看到了恢复的默认现实，我本地测试一下https://github.com/cloudwego/hertz/blob/develop/pkg/app/middlewares/server/recovery/option.go#L37

你好 请问我现在应该怎么做 可以正常打印 panic 异常堆栈信息呢？
还有一个问题就是要怎么打印接口请求信息？比如一个接口的响应时间之类的，状态码之类的日志呢？

这不应该，因为我看到了恢复的默认现实，我本地测试一下https://github.com/cloudwego/hertz/blob/develop/pkg/app/middlewares/server/recovery/option.go#L37

你好 请问我现在应该怎么做 可以正常打印 panic 异常堆栈信息呢？ 还有一个问题就是要怎么打印接口请求信息？比如一个接口的响应时间之类的，状态码之类的日志呢？
@maojinhua

hlog 的 zero-log 实现在 Ctx*** 有一些问题可以看上文
第二个看下 hertz access_log  中间件的使用 https://github.com/hertz-contrib/logger/tree/main/accesslog

这不应该，因为我看到了恢复的默认现实，我本地测试一下https://github.com/cloudwego/hertz/blob/develop/pkg/app/middlewares/server/recovery/option.go#L37

你好 请问我现在应该怎么做 可以正常打印 panic 异常堆栈信息呢？ 还有一个问题就是要怎么打印接口请求信息？比如一个接口的响应时间之类的，状态码之类的日志呢？
@maojinhua

hlog 的 zero-log 实现在 Ctx*** 有一些问题可以看上文  cc @welkeyever ,这块看了一下直接用用户的logger打印日志是不是就可以，但是问题是 ctx 用不到了，zap 也有类似的 ctx 用不到的问题，目前解决方案是在扩展里加了 hook 函数来搞的 https://github.com/hertz-contrib/logger/pull/25/files
第二个看下 hertz access_log  中间件的使用 https://github.com/hertz-contrib/logger/tree/main/accesslog

嗯好的 谢谢，我试试哈

@li-jin-gou https://github.com/hertz-contrib/logger/pull/25/files 这个的思路是对的，CtxLogger这个接口的设计初衷就是给用户提供一个透传上下文的可能；具体如何处理ctx中的value也好，ctx的终结也好(ctx.Done)这个根据对应的logger实现来就行。
如果没有额外针对上述ctx的相关处理，原则上等价于Logger接口的具体实现。

@maojinhua  更新一下 github.com/hertz-contrib/logger/zerolog

repo: cloudwego/hertz


text:
Add simple streaming API

An experimental streaming API has been implemented via #31. However, it's quite cumbersome to work with.
In particular, one still has to wait on a promise progress event until one can access a stream object.
Instead, we should add a simple API that returns a stream right away and then emits events on it once the HTTP response comes in.

Also take connection hijacking into account for protocols that write outgoing data even after receiving the response headers.

This feature will likely be resolved with #30. API draft:
$browser->get($url)->then(function (Response $response) {
    $stream = $response->stream();

    $stream->on('data', function ($chunk) {
        echo $chunk;
    });
});

I've played around with several approaches to a sane streaming API while implementing this via #56:

The response could implement the ReadableStreamInterface. This works out reasonably well for the receiving side through the decorator pattern, but does not really fit for outgoing requests.
The fetch API offers additional methods and requires a custom Response object which still has to implement the base ResponseInterface. This works out reasonably well for the receiving side through the decorator pattern, but does not really fit for outgoing requests.
The fetch API resolves as soon as the headers has been received without waiting for the whole body. This is the main takeaway here.

repo: clue/php-buzz-react

license: mit


text:
Problem dissolving solution

I can't dissolve the shapefile for a solution, am I missing anything? I'm posting here an example using a toy example data (from pysal), but I have not been able to get it to work with other datasets too.
import pysal as ps
import clusterpy as clp
col = clp.importArcData(ps.examples.get_path('columbus'))
col.cluster('azpRTabu', ['HOVAL', 'CRIME'], 2, dissolve=1)

Which prints out the following output:
Getting variables
Variables successfully extracted
Running original AZP-R-Tabu algorithm (Openshaw and Rao, 1995)
Number of areas:  49
Number of regions:  2
Constructing regions
initial Solution:  [0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 1, 0, 0]
initial O.F:  24864.1208571
Performing local search
FINAL SOLUTION:  [0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 1, 0, 0]
FINAL OF:  24572.9644776
Done
Adding variables
Done
Dissolving lines
Problem: Amount of assigned regions does not match number of areas
Regions: [0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 1, 0, 0]
Done

Dear Dani,
I just tried the following code and it worked:
import clusterpy
col = clusterpy.importArcData("clusterpy/data_examples/columbus")
col.exportArcData("testOutput/columbus")
col.cluster('azpRTabu', ['HOVAL', 'CRIME'], 2, dissolve=1)
col.results[0].exportArcData("testOutput/ColDiss")

Juans-iMac:CP juanduque$ python testDissolve.py
ClusterPy: Library of spatially constrained clustering algorithms
Some functions are not available, reason: No module named Polygon
Some functions are not available, reason: No module named Polygon
Loading clusterpy/data_examples/columbus.dbf
Loading clusterpy/data_examples/columbus.shp
Done
Writing ESRI files
Writing DBF file
Done
ESRI files created
Getting variables
Variables successfully extracted
Running original AZP-R-Tabu algorithm (Openshaw and Rao, 1995)
Number of areas:  49
Number of regions:  2
Constructing regions
initial Solution:  [0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 1, 0, 0]
initial O.F:  24864.1208571
Performing local search
FINAL SOLUTION:  [0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 1, 0, 0]
FINAL OF:  24572.9644776
Done
Adding variables
Done
Dissolving lines
Done
Writing ESRI files
Writing DBF file
Done
ESRI files created
Juans-iMac:CP juanduque$

authors: JuancaDuque darribas

repo: clusterpy/clusterpy


text:
security.txt

https://securitytxt.org/

https://stackoverflow.com/questions/55880919/how-to-add-well-known-on-github-pages-files-using-html


text:
$lang parameter broken

I have copied your CurrentWeather example directly to my web-server so i could see how the api works. In the beginning you set the parameter to de which should be German but at example 7 the output for wind direction and wind speed description are in English.

Hey @Efratror,
this is something I cannot fix. See the following API call for reference:
http://api.openweathermap.org/data/2.5/weather?q=London,uk&appid=2f8796eefe67558dc205b09dd336d022&lang=de&mode=xml
You could try asking for help here: https://openweathermap.desk.com/.

authors: Efratror cmfcmf

repo: cmfcmf/OpenWeatherMap-PHP-Api


text:
Add version specs to requirements.txt

To make it easier to pip install -r requirements.txt

Thanks @trevormunoz !


text:
chore(main): release 0.2.0

:robot: I have created a release beep boop
0.2.0 (2024-06-29)
Features

lexer: Tokenize binary operations (+, -, *, /, %, **) (#12) (602ac83)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.2.0
:sunflower:

repo: cmnemoi/cmnemoiscript


text:
Unable to install on jetson-tx2

Hi there. I'm trying to install this on a Nvidia Jetson tx2 running Jetpack 3.3.
It seems to have some unresolved cmake dependency, but I haven't been able to track down how to resolve it. Any advice would be greatly appreciated!
$ pip install PyPCL --no-cache-dir
Looking in indexes: https://pypi.org/simple
Collecting PyPCL
Downloading https://files.pythonhosted.org/packages/b4/83/b3d397539f8877d99cc95a7073b58480a09fcee408997c19e2345e9933eb/PyPCL-0.1.8.tar.gz (179kB)
100% |████████████████████████████████| 184kB 2.6MB/s
Requirement already satisfied: numpy in ./venv/lib/python3.7/site-packages (from PyPCL) (1.16.1)
Installing collected packages: PyPCL
Running setup.py install for PyPCL ... error
Complete output from command /home/nvidia/repos/graspai/venv/bin/python3.7 -u -c "import setuptools, tokenize;file='/tmp/pip-install-3lvbtspx/PyPCL/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-record-pxtpiv6o/install-record.txt --single-version-externally-managed --compile --install-headers /home/nvidia/repos/graspai/venv/include/site/python3.7/PyPCL:
--------------------------------------------------------------------------------
-- Trying "Ninja" generator
--------------------------------
---------------------------
----------------------
-----------------
------------
-------
--
Not searching for unused variables given on the command line.
CMake Error: CMake was unable to find a build program corresponding to "Ninja".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
-- Configuring incomplete, errors occurred!
--
-------
------------
-----------------
----------------------
---------------------------
--------------------------------
-- Trying "Ninja" generator - failure
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
-- Trying "Unix Makefiles" generator
--------------------------------
---------------------------
----------------------
-----------------
------------
-------
--
Not searching for unused variables given on the command line.
-- The C compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- The CXX compiler identification is GNU 5.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/pip-install-3lvbtspx/PyPCL/_cmake_test_compile/build
--
-------
------------
-----------------
----------------------
---------------------------
--------------------------------
-- Trying "Unix Makefiles" generator - success
--------------------------------------------------------------------------------

-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /home/nvidia/repos/graspai/venv/bin/python3.7 (found version "3.7")
-- Found PythonLibs: /usr/local/lib/libpython3.7m.a (found version "3.7.0")
-c:42: DeprecationWarning: SO is deprecated, use EXT_SUFFIX
-- Found Cython: /home/nvidia/repos/graspai/venv/bin/cython
CMake Error at pcl/CMakeLists.txt:1 (find_package):
  By not providing "FindPCL.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "PCL", but
  CMake did not find one.

  Could not find a package configuration file provided by "PCL" with any of
  the following names:

    PCLConfig.cmake
    pcl-config.cmake

  Add the installation prefix of "PCL" to CMAKE_PREFIX_PATH or set "PCL_DIR"
  to a directory containing one of the above files.  If "PCL" provides a
  separate development package or SDK, be sure it has been installed.

-- Configuring incomplete, errors occurred!
See also "/tmp/pip-install-3lvbtspx/PyPCL/_skbuild/linux-aarch64-3.7/cmake-build/CMakeFiles/CMakeOutput.log".
Traceback (most recent call last):
  File "/home/nvidia/repos/graspai/venv/lib/python3.7/site-packages/skbuild/setuptools_wrap.py", line 548, in setup
    languages=cmake_languages
  File "/home/nvidia/repos/graspai/venv/lib/python3.7/site-packages/skbuild/cmaker.py", line 232, in configure
    os.path.abspath(CMAKE_BUILD_DIR)))

An error occurred while configuring with CMake.
  Command:
    "cmake" "/tmp/pip-install-3lvbtspx/PyPCL" "-G" "Unix Makefiles" "-DCMAKE_INSTALL_PREFIX:PATH=/tmp/pip-install-3lvbtspx/PyPCL/_skbuild/linux-aarch64-3.7/cmake-install" "-DPYTHON_EXECUTABLE:FILEPATH=/home/nvidia/repos/graspai/venv/bin/python3.7" "-DPYTHON_VERSION_STRING:STRING=3.7.0" "-DPYTHON_INCLUDE_DIR:PATH=/usr/local/include/python3.7m" "-DPYTHON_LIBRARY:FILEPATH=/usr/local/lib/libpython3.7m.a" "-DSKBUILD:BOOL=TRUE" "-DCMAKE_MODULE_PATH:PATH=/home/nvidia/repos/graspai/venv/lib/python3.7/site-packages/skbuild/resources/cmake" "-DCMAKE_BUILD_TYPE:STRING=Release"
  Source directory:
    /tmp/pip-install-3lvbtspx/PyPCL
  Working directory:
    /tmp/pip-install-3lvbtspx/PyPCL/_skbuild/linux-aarch64-3.7/cmake-build
Please see CMake's output for more information.

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

Command "/home/nvidia/repos/graspai/venv/bin/python3.7 -u -c "import setuptools, tokenize;file='/tmp/pip-install-3lvbtspx/PyPCL/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-record-pxtpiv6o/install-record.txt --single-version-externally-managed --compile --install-headers /home/nvidia/repos/graspai/venv/include/site/python3.7/PyPCL" failed with error code 1 in /tmp/pip-install-3lvbtspx/PyPCL/

Have you ever installed PCL (the C++ library) on the machine? Unfortunately PyPCL now is not standalone library, it depends on the C++ version of PCL

Hi,
I get the same error even with PCL installed. Does it need to be referenced somehow?
Do you have any advice?
Thanks in advance

Hi,
I get the same error even with PCL installed. Does it need to be referenced somehow?
Do you have any advice?
Thanks in advance

You mean error showing that cannot find PCLConfig.cmake? I guess this is due to that the path for PCL is not setup correctly. Did you install pcl using apt?

I was eventually able to get this installed using PCL1.8
I had to patch PyPCL to respect my header location:
rev 1dd6acc
`diff --git a/pypcl_build.py b/pypcl_build.py
index 72d91a8..b71a1b7 100644
--- a/pypcl_build.py
+++ b/pypcl_build.py
@@ -16,7 +16,7 @@ ffibuilder.cdef(pypcl_header_source)
To compile on another platform they need to be changed.
def pcl_header():
for version in ["1.7", "1.8"]:

   pcl_header = "/usr/include/pcl-{}".format(version)

   pcl_header = "/usr/local/include/pcl-{}".format(version)
   if os.path.exists(pcl_header):
       return pcl_header

raise Exception("No valid PCL header found")`

I also had to patch python-pcl at rev: d8b1fea
`diff --git a/setup.py b/setup.py
index cba5eb3..085a6e2 100644
--- a/setup.py
+++ b/setup.py
@@ -146,7 +146,7 @@ if platform.system() == "Windows":
break
else:
# Try to find PCL. XXX we should only do this when trying to build or install.

   PCL_SUPPORTED = ["-1.8", "-1.7", "-1.6", ""]    # in order of preference

   PCL_SUPPORTED = ["-1.7", "-1.6", ""]    # in order of preference

   for pcl_version in PCL_SUPPORTED:
       if subprocess.call(['.\\pkg-config\\pkg-config.exe', 'pcl_common%s' % pcl_version]) == 0:

@@ -550,6 +550,7 @@ else:
# "-I/usr/include/openni"
# /usr/include/ni
ext_args['include_dirs'].append('/usr/include/ni')

ext_args['include_dirs'].append('/usr/local/include/vtk-7.1')
ext_args['library_dirs'].append()
ext_args['libraries'].append()

@@ -614,22 +615,22 @@ else:
 if pcl_version == '-1.6':
     module = [Extension("pcl._pcl", ["pcl/_pcl.pyx", "pcl/minipcl.cpp", "pcl/ProjectInliers.cpp"], language="c++", **ext_args),

             # Extension("pcl.pcl_visualization", ["pcl/pcl_visualization.pyx"], language="c++", **ext_args),

             Extension("pcl.pcl_visualization", ["pcl/pcl_visualization.pyx"], language="c++", **ext_args),
             # Extension("pcl.pcl_grabber", ["pcl/pcl_grabber.pyx", "pcl/grabber_callback.cpp"], language="c++", **ext_args),
             # debug
             # gdb_debug=True,
             ]

elif pcl_version == '-1.7':
module = [Extension("pcl._pcl", ["pcl/_pcl_172.pyx", "pcl/minipcl.cpp", "pcl/ProjectInliers.cpp"], language="c++", **ext_args),

             # Extension("pcl.pcl_visualization", ["pcl/pcl_visualization.pyx"], language="c++", **ext_args),

             Extension("pcl.pcl_visualization", ["pcl/pcl_visualization.pyx"], language="c++", **ext_args),
             # Extension("pcl.pcl_grabber", ["pcl/pcl_grabber.pyx", "pcl/grabber_callback.cpp"], language="c++", **ext_args),
             # debug
             # gdb_debug=True,

:q
uu                   ]
elif pcl_version == '-1.8':
module = [Extension("pcl._pcl", ["pcl/_pcl_180.pyx", "pcl/minipcl.cpp", "pcl/ProjectInliers.cpp"], language="c++", **ext_args),

             # Extension("pcl.pcl_visualization", ["pcl/pcl_visualization.pyx"], language="c++", **ext_args),

             # Extension("pcl.pcl_grabber", ["pcl/pcl_grabber.pyx", "pcl/grabber_callback.cpp"], language="c++", **ext_args),

             Extension("pcl.pcl_visualization", ["pcl/pcl_visualization.pyx"], language="c++", **ext_args),

             #Extension("pcl.pcl_grabber", ["pcl/pcl_grabber.pyx", "pcl/grabber_callback.cpp"], language="c++", **ext_args),
             # debug
             # gdb_debug=True,
             ]

`

@bfouts-kindred I didn't find the corresponding codes in my source. Where does pypcl_build.py come from? Currently the location of PCL is determined by CMake modules, so as long as your PCL installation is able to be discovered by CMake, then it should be fine to build

The old version of pypcl has been deprecated, so this issue is going to be closed.

authors: Kildebo bfouts-kindred cmpute


text:
Support SNI and invalid certs

If a cert is invalid (e.g. it has already expired) or the host uses SNI the node script can fail.
To fix this add
rejectUnauthorized: False
servername: hostname_goes_here

to var options =

@jbrowngithubuser Can you give me a hostname that uses SNI that fails? I use SNI on all of my dev servers, and the script works just fine.

authors: cmrunton jbrowngithubuser

repo: cmrunton/tls-dashboard


text:
fix: lru-k old node size

Fix #16.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 81.70%. Comparing base (e84e63f) to head (1f5429a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #18      +/-   ##
==========================================
+ Coverage   80.57%   81.70%   +1.12%
==========================================
  Files          15       15
  Lines        1519     1536      +17
  Branches     1519     1536      +17
==========================================
+ Hits         1224     1255      +31
+ Misses        222      210      -12
+ Partials       73       71       -2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


text:
Update forecasting: sklearn DBSCAN for clustering, LSTM for predictions.

This PR implements a version of Query-Based Workload Forecasting adapted from QueryBot2000 by Lin et al (2018). Forecasting is currently divided into three components, each one dependent on artifacts produced by the previous.
Preprocessor
This converts a directory of Postgres CSV query logs into a parquet file of templatized queries and the corresponding parameters with which the original query can be reconstructed.
Clusterer
Templates are grouped into clusters based on the arrival rate of templates using the DBSCAN  algorithm. This produces a mapping from known templates to their assigned clusters.
Forecaster
The forecaster uses the templatized queries from the Preprocessor, as well as the assignments from the clustered to produce an aggregate arrival rate time series of each cluster. These rates are used to train an LSTM RNN to predict future arrival rates. The prediction of a cluster's arrival rate, as well as samples from the observed distribution of A.) templates within a query and B.) parameters within a template are used to generate the forecasted workload. This workload is reported in the form of a csv containing (query, count) pairs.
Included in this PR is a sample notebook (forecast/Sine-Forecast.ipynb) demonstrating the usage of the clusterer and LSTM model to produce accurate predictions on a synthetic trace of noisy, sinusoidal arrival rates for templates.
In dodo.py, forecasting is split into two tasks: forecast_preprocess and forecast_predict, since it may be the case that preprocess can be done ahead of time before predictions are needed. Currently, forecast_preprocess is always run as a dependency if forecast_predict is called, but I anticipate there will be cases where we split the forecasting tasks further so the pilot as finer control over the entire process.

Ignoring remaining conversations as they are formatting-related and I'm OK doing a manual pass for these early PRs that were made prior to us establishing coding style. Merging with admin permissions.

authors: lmwnshn mkpjnx

repo: cmu-db/noisepage-pilot


text:
#229: added CI test for psql

I have added tests into CI to test if PSQL works.

The installation script has been updated to install the postgresql-client apt package to get psql "out-of-the-box"

The test_jdbc.sh script runs script/testing/dml/basic1.sql and diff's the output with the reference output for validation

Travis has been updated to include this test script into CI

Coverage decreased (-0.1%) to 50.723% when pulling 4ec9ec2bf64bed1b0bb5aa546bf25515b865a1b2 on sid1607:master into 3fa4fae6424539a14e4bd4b7742e3c07b9ded8ea on cmu-db:master.

Coverage increased (+0.003%) to 50.852% when pulling bbfe1111e6262aed9aa9afce8a1cb1029dcaca2f on sid1607:master into 3fa4fae6424539a14e4bd4b7742e3c07b9ded8ea on cmu-db:master.

repo: cmu-db/peloton


text:
失效

http://zhnpng.com/mail
无法访问。

已经不再维护。
这个链接我记得是指向到mailgun的。

authors: cnDelbert kajweb

repo: cnDelbert/MailLoginPage


text:
Member updates 6.27.23

Pre-submission checklist:
Please check each of these after submitting your pull request:

[ ] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[ ] Is your project closed source or, if it is open source, does your project have at least 300 GitHub stars?
[ ] Have you picked the single best (existing) category for your project?
[ ] Does it follow the other guidelines from the new entries section?
[ ] Have you added your SVG to hosted_logos and referenced it there?
[ ] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[ ] Does your project/product name match the text on the logo?
[ ] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[ ] ~30 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

LGTM

repo: cncf/landscape


text:
Update cncf/glossary external_collaborators

Hello folks !
I am one of the maintainers of the https://github.com/cncf/glossary
We've recently removed existing localization approvers and added new approvers to the cncf/glossary repository

Based on https://github.com/cncf/glossary/pull/2960

Add new approvers for zh-tw branch based on a requested by the localization team.

@tico88612

Step down approvers for zh-tw branch based on a requested by the localization team.

@pichuang

We need to update config.yaml in cncf/people in order to follow the CNCF Sheriff bot.

PTAL @cjyabraham :)

repo: cncf/people


text:
TAG Observability Wiki

As mentioned on Slack, lots of the information shared in conversations and written chats is getting lost. Separately, whitepapers need a long time to be created and become outdated or only get updated by a small group of people. (This is partially due to the formal nature of a whitepaper.)
https://cloud-native.slack.com/archives/CTHCQKK7U/p1699643328722899?thread_ts=1699583604.842659&cid=CTHCQKK7U
There are lots of open issues for the whitepaper and I wonder if those could be addressed faster if people were not asked to contribute to a whitepaper but to a wiki.
Additionally, it would be great to have a place where professionals in the space can share their knowledge and use case "solutions"/approaches. These might be based on informal conversations, formal discussions, or use cases - such as those presented at KubeCon.
Difference to Observability Whitepaper:

More dynamic -- the Wiki can be based on multiple more minor discussions and informal working groups
Rather than focusing on explanations and theory, the wiki could be more centred around use cases and CNCF projects as well as locations where additional information can be found i.e. the goal should not be to repeat already available information but to make resources more accessible. I would think of it as an "evolving document".

To me, this seems aligned with the scope of the TAG; by formalising conversations and working towards contributions to the Wiki, it is easier to identify gaps, curate information, educate and inform users etc.
Maybe people in the TAG already thought about something similar, or there have already been conversation related etc. 🙂

Thanks for raising this concern @AnaisUrlichs.
I'd be interested in hearing your thoughts whether what you've described would fit within the Observe k8s WG that the TAG operators?

Hi @kenfinnigan -- I guess it could be one of the objectives to kick-start a Wiki, define goals, and processes so that people outside the working group also know how to contribute?
Ideally, the Wiki should survive the working group -- it could be under the repo proposed/worked on
I mean these are all my takes, I am sure some people have different ideas and I would love to hear them, too

Hi. Hope you are good.
I wrote this after some research and wanted to hear your toughts on the TAG Observability landing page.
https://cloud-native.slack.com/archives/CTHCQKK7U/p1700249237274639

authors: AnaisUrlichs caioroscelly kenfinnigan

repo: cncf/tag-observability


text:
Compilation error with GCC 14

I'm using w64devkit version 2.0.0.
This is the error message:
../../source/gui/widgets/treebox.cpp:359:60: error: no matching function for call to 'find(std::vector<nana::widgets::detail::tree_node<nana::drawerbase::treebox::trigger::treebox_node_type>*>::iterator, std::vector<nana::widgets::detail::tree_node<nana::drawerbase::treebox::trigger::treebox_node_type>*>::iterator, nana::drawerbase::treebox::trigger::implementation::node_type*&)'
  359 |                                         auto it = std::find(nodes_selected.begin(), nodes_selected.end(), node);
      |                                                   ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
make: *** [makefile:41: out/objs/gui/widgets/treebox.o] Error 1

I cloned the branch dev_dpi_system and build it using build/makefile.

Thanks for taking your time to try that branch. It is highly experimental. I will continue working on it by the end of this years. It is working 'on my computer' but it is not well tested, and not with gcc14.2. And I did not use/ not adapted /makefile. Only cmake. Please try that. It will be great if you fix that makefile dir for this branch.
If you are just trying nana, the best branch is develop-1.8

repo: cnjinhao/nana


text:
fixed React Native 0.40 headers

for issue #37

@cnjon Can we get this merged?

@cnjon merge it, please

@sibelius hi, maybe you can help with this?

tks, @cnjon can u do a breaking bump?

Is there a new release?

authors: gyzerok horsekitlin marcosinigaglia mehcode sibelius

repo: cnjon/react-native-pdf-view


text:
How to access Octopus-UI?

what's username and password?
I install with
kubectl apply -f https://raw.githubusercontent.com/cnrancher/octopus-api-server/master/deploy/e2e/all_in_one.yaml
kubectl get svc -n kube-system -l app.kubernetes.io/name=octopus-ui
NAME         TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
octopus-ui   NodePort   10.106.214.157   <none>        8443:8899/TCP   19m

nodeport exposed

@hillbun , Ocotpus UI is a special UI for K3s, after brought up a K3s cluster, you can find the account in the KUBECONFIG file. https://cnrancher.github.io/docs-octopus/docs/en/octopus-ui#authentication.
I will close this issue, please reopen it if needed, have a good day with Octopus.

@thxCode
is it possible to install it on k3s single node?

@hillbun yes, it should be possible to deploy to k3s single node, which has master and agent role.

k3s kubectl get svc -n kube-system -l app.kubernetes.io/name=octopus-ui
NAME                 TYPE           CLUSTER-IP     EXTERNAL-IP       PORT(S)          AGE
octopus-octopus-ui   LoadBalancer   10.43.104.46   192.168.153.129   8443:31210/TCP   45h
octopus-ui           LoadBalancer   10.43.74.89             8443:31451/TCP   5m33s
can't access the octopus-ui, how to solve it?

k3s kubectl get svc -n kube-system -l app.kubernetes.io/name=octopus-ui
root@k3s1:/home/ubuntu# k3s kubectl get svc -n kube-system -l app.kubernetes.io/name=octopus-ui NAME                 TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)          AGE octopus-octopus-ui   LoadBalancer   10.43.104.46    192.168.153.129   8443:31210/TCP   2d1h myapp-octopus-ui     LoadBalancer   10.43.126.154   <pending>         8443:31044/TCP   7m46s
can't access the octopus-ui, how to solve it?

k3s kubectl get svc -n kube-system -l app.kubernetes.io/name=octopus-ui
root@k3s1:/home/ubuntu# k3s kubectl get svc -n kube-system -l app.kubernetes.io/name=octopus-ui
NAME                 TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)          AGE
octopus-octopus-ui   LoadBalancer   10.43.104.46    192.168.153.129   8443:31210/TCP   2d1h
myapp-octopus-ui     LoadBalancer   10.43.126.154   <pending>         8443:31044/TCP   7m46s

can't access the octopus-ui, how to solve it?

authors: 1000sprites hillbun thxCode

repo: cnrancher/octopus


text:
J endcarto

so you'll see it's mainly a big cleaning of the console logs and also a global use of endpointGenerator instead of endpointCreator... There are finally some minor changes in the config files in the backend so we could declare whatever link we want for the navbar logo + an extra footer declaration for partners if any...

and now conflicts were resolved....

repo: co-demos/ApiViz


text:
defq function

Hi,
defq as defined is not a macro but a function.
However you use ~ in its body. I saw that when trying to use it unsuccessfully.
Based on your code in https://github.com/coast-framework/coast, something like this works better for me :
(defmacro defq
  ([conn-pool n filename]
   `(let [q-fn# (lighthouse.defq/query-fn ~conn-pool (assoc (lighthouse.defq/query ~(str n) ~filename) :ns *ns*))]
      (lighthouse.defq/create-root-var ~(str n) q-fn#)))
  ([conn-pool filename]
   `(lighthouse.defq/query-fns ~conn-pool ~filename)))

Any opinion on that?
Thanks,
jerome

Hm that’s definitely a lot better. Huge oversight on my part.
I definitely need to bring over some of the coast db connection stuff to this lib.
But yeah if you don’t get around to a PR, I’ll change defq to what you have here

authors: jgallinari swlkr

repo: coast-framework/lighthouse


text:
連合/ローカルタイムライン表示時にエラー (NoMethodError)

mikutter3.7.2.
停止はせず、表面上動作はしているように見えますが、連合またはローカルタイムラインを表示すると、断続的にエラーを吐きます. 下記はエラーの一部.
#<Thread:0x00007fb370177d90@/home/username/.mikutter/plugin/worldon/sse_stream.rb:214 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
	9: from /home/username/.mikutter/plugin/worldon/sse_stream.rb:216:in `block (3 levels) in <top (required)>'
	8: from /home/username/.mikutter/plugin/worldon/sse_stream.rb:254:in `update_handler'
	7: from /home/username/.mikutter/plugin/worldon/model/status.rb:80:in `build'
	6: from /home/username/.mikutter/plugin/worldon/model/status.rb:80:in `map'
	5: from /home/username/.mikutter/plugin/worldon/model/status.rb:81:in `block in build'
	4: from /home/username/.mikutter/plugin/worldon/model/status.rb:102:in `json2status'
	3: from /home/username/.mikutter/plugin/worldon/model/status.rb:137:in `merge_or_create'
	2: from /home/username/Downloads/mikutter/core/lib/weakstorage.rb:194:in `[]='
	1: from /home/username/Downloads/mikutter/vendor/diva/model.rb:61:in `hash'
/home/username/Downloads/mikutter/vendor/diva/model_extend.rb:39:in `block in add_field': undefined method `[]' for nil:NilClass (NoMethodError)
#<Thread:0x00007fb310047750@/home/username/.mikutter/plugin/worldon/sse_stream.rb:214 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
	9: from /home/username/.mikutter/plugin/worldon/sse_stream.rb:216:in `block (3 levels) in <top (required)>'
	8: from /home/username/.mikutter/plugin/worldon/sse_stream.rb:254:in `update_handler'
	7: from /home/username/.mikutter/plugin/worldon/model/status.rb:80:in `build'
	6: from /home/username/.mikutter/plugin/worldon/model/status.rb:80:in `map'
	5: from /home/username/.mikutter/plugin/worldon/model/status.rb:81:in `block in build'
	4: from /home/username/.mikutter/plugin/worldon/model/status.rb:102:in `json2status'
	3: from /home/username/.mikutter/plugin/worldon/model/status.rb:137:in `merge_or_create'
	2: from /home/username/Downloads/mikutter/core/lib/weakstorage.rb:194:in `[]='
	1: from /home/username/Downloads/mikutter/vendor/diva/model.rb:61:in `hash'
/home/username/Downloads/mikutter/vendor/diva/model_extend.rb:39:in `block in add_field': undefined method `[]' for nil:NilClass (NoMethodError)

報告ありがとうございます。
しかし私の環境では再現しません。
パスから察するにdivaをbundler以外の方法でインストールされているんでしょうか？
rubyやdivaのバージョン、worldonのcommit hash、具体的な利用環境など、もう少し詳しく教えてもらってもいいですか？

レスありがとうございます。各々のバージョンですが次のとおりです。
Ruby 2.5.0
diva 0.3.2
worldon #7c5712ff887e50eee1074eed59d196cc0e72b79c
使用している環境はGentoo Linuxで、解凍したMikutterのvendorディレクトリを消して、
bundle install  --path vendor
してます。
（試しに消さずにbundle install  --path vendor/bundle をするとv2.jsonがないとか怒られたため、手動でv2.jsonを入れてみました。添付の--debug出力はこの方法で入れたものの出力を貼り付けてしまいましたが、このインストール方法の違いでエラーは（パス以外）変わりませんでした）
その後、動作確認した後で、/usr/share/mikutter/へコピーしています。
以上ご参考まで。
#どのユーザのトゥートで出てるのかはっきりすればしぼりこめるかもしれませんが；

うーん、至って普通の環境ですね。

/usr/share/mikutter/へコピーしています。

というのはよくわかりませんけど……
あと、それが発生するMastodonインスタンスのドメインを教えてもらってもいいですか？
エラーの内容としては、Diva::Modelのフィールドを格納するHash型のインスタンス変数@valueがnilだと言っているわけですが、この変数はDiva::Model#initializeで引数（Hash）を使って初期化されるので、nilにはならないはずだと思うんですよね。
worldon/model/status.rb の 137行目
@@status_storage[uri] = status

の直前に
pp uri
$stdout.flush

を仕込むと、エラーメッセージの前に該当トゥートのURIが表示できると思うので、試してみてもらえますか？

試してみました。
エラーの出ているトゥートは、ミュートしているアカウントのトゥートです。
ミュートの機能は動いているようで当然というか、トゥート自体はMikutter上には表示されてません。
大量の投稿をしているアカウントをミュートしているため、多くのエラーが断続的に出る挙動になったようです。
ちなみに利用しているインスタンスはmstdn.jpです。
（/usr/share/mikutter はかつてパッケージマネージャでMikutterをインストールしたときの位置で、なんとなくそこへ今でもインストールしているという…)

ミュート機能が動くようになってinitializeがミュート時早期リターンするようになって(書いたのは私)
埋められるべきフィールドが埋められなくてエラー?
initializeはnil返してもクラスのインスタンス自体は出来てしまいますからね
ミュートした時にインスタンス変数を設定してmerge_or_createあたりで分岐する?
こちらの環境だと再現しないので修正が難しい

エラーの出ているトゥートは、ミュートしているアカウントのトゥートです。

initializeはnil返してもクラスのインスタンス自体は出来てしまいますからね
ミュートした時にインスタンス変数を設定してmerge_or_createあたりで分岐する?

なるほど、そうだったんですね。
次は分岐する位置を変えたコードを書いて試してみてもらうのがよさそうですね。

ncaqさん、コメントありがとうございます。このエラーはRuby2.5からデフォルトで有効になったみたいですね。まだ他にも環境が関係するのかもわかりませんが。
フォークしてsse_stream.rbとrest.rbへミュート判定を移動してみました。こちらの環境では一応動いているようにみえますが、これで良いのかな。テストしてもらえば有り難いです。スキル無くてこのくらいしか書けませんで申し訳ないです;

@ascamik パッチ見ました。しかし例えばトゥートのURLを引用した場合など、streamでもrestでもない手段で取得されるStatusというものが存在し、そういったものにもミュート判定は効かせたいため、移動先が不適切であると考えました。
包括的に扱えてしかもコンストラクタの外になる位置に移動させる修正をmasterにpushしましたので、確認していただけますか？

authors: ascamik cobodo ncaq

repo: cobodo/mikutter-worldon


text:
Update code_info.py

occured -> occurred

Emm...Thanks for your correction.
FYI, the documents and comments in the code are still being written. We will update them later.

authors: YXHXianYu eltociear

repo: cocacola-lab/MineLand


text:
sql: augment statement logging with a txn counter

PR: https://github.com/cockroachdb/cockroach/pull/41929
From release notes:

The structured payloads used for SQL audit and execution logs now include a transaction counter since the beginning of the session. Statements issued inside the same SQL transaction will thus be logged with the same counter value, thus enabling per-transactions grouping during log analysis. Separate sessions use independent counters. [#41929][#41929] {% comment %}doc{% endcomment %}

cc @ericharmeling, @ianjevans, this might be SQL observability, not sure.

This is about the log messages, so it should be my area.

Closed by #10273.

authors: jseldess taroface

repo: cockroachdb/docs


text:
distsql: support left outer lookup joins

PR: https://github.com/cockroachdb/cockroach/pull/25644
From release notes:

The experimental lookup join feature now supports left outer joins. [#25644][#25644] {% comment %}doc{% endcomment %}

Covered by https://github.com/cockroachdb/docs/issues/3153.


text:
Write multi-region EKS (Amazon) Kubernetes tutorial

Our current multi-k8s deployment guidance focused on GKE and requires a stable public load balancing IP to hook together DNS servers from different clusters. As seen on our forum, this approach  might not be possible on AWS, and as @bdarnell has mentioned, there are probably other, better options for achieving what we want anyway.

We should identify the right way to load balancer across multiple k8s clusters, likely via a load balancer hostname that is resolvable and routable from all the clusters.
We should then create a separate tutorial for AWS, and consider updating the GKE tutorial and configs.

Hi,
Are you still looking to write a tutorial for EKS? If yes we can collaborate and publish it on AWS container blog.

@realvz, this is definitely still planned, and we'd definitely be interested in collaborating. Would you mind emailing me at ryank@cockroachlabs.com, or letting me know how I can reach you directly?

@taroface You should have an email from me.

@realvz just followed up with you!

authors: jseldess realvz taroface


text:
Serializable Transactions Doc Update

Re: Serializable Transactions
Issue Description
I tried the same scenario but the results are below:
The commit on the first doctor succeeds and commit on second doctor fails
Suggested Resolution
Go over the scenario and correct the content

@lin-crl, where in the tutorial did you run into this? In the CRDB section, I imagine?

That's correct.
On Fri, Mar 5, 2021, 1:37 PM Jesse Seldess notifications@github.com wrote:

@lin-crl https://github.com/lin-crl, where in the tutorial did you run
into this? In the CRDB section, I imagine?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cockroachdb/docs/issues/9939#issuecomment-791725499,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASE3X5NWMGAVI3EITBV7JETTCFFIDANCNFSM4YV3TRZQ
.

authors: jseldess lin-crl


text:
DOC-9781 Docs for Implement prometheus integration for Serverless metrics export

Fixes DOC-9781
In Export Metrics for Standard page, added Prometheus scrape sections.

Thanks! Prometheus changes for standard clusters looks good to me. I'll follow up on the baseline metrics over the next few days, but I think adding that should not be an issue unless others have strong opinions.

DRAFT managed-service PR 16526
For now, there is a note: Metrics are only returned when an active workload is running on the cluster.

This link will need to be updated for Cloud 2.0:
[Cloud Console]({% link cockroachcloud/serverless-cluster-management.md %}#view-clusters-page)


text:
Script to auto-generate docs issues from release notes file

@knz and/or @benesch, this is ready for a review.

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/871b4655d4ead0ce85d2048aae71c4624625ba6b/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b895ce973bd2a6d0055b8512d5d6d29cbd8ea2a7/

TFTR, @benesch!

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/169b454cf243a48ac25f4d805295486bc742cf19/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/09967a22a197d8f51baff0bc89ce85bdaf677b4e/

authors: cockroach-teamcity jseldess


text:
Database drops and renames are now transactional

Fixes #8314.

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/ad29827be8197e501228c77950a6d5241b571021/
Edited pages:

v20.2/known-limitations.md
v20.2/rename-database.md
v20.2/rename-table.md

Issue for past versions: https://github.com/cockroachdb/docs/issues/8760

Re: atomically swapping names, I just saw that in our online schema changes documentation, we do already say this:

A table cannot be dropped and then recreated with the same name. This is not possible within a single transaction because DROP TABLE does not immediately drop the name of the table. As a workaround, split the DROP TABLE and CREATE TABLE statements into separate transactions.

https://www.cockroachlabs.com/docs/v20.1/online-schema-changes.html#limited-support-for-schema-changes-within-transactions
So I think for 20.2, we should expand this to indicate that this is true for databases, schemas, and user-defined types (enums). Also, we forbid any reuse of a name within a transaction, not just reuse after drop. (https://github.com/cockroachdb/cockroach/issues/54562 has some other examples: for instance, you can't rename a to b and then rename c to a in the same transaction.)

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/876206cb9672e60044c9d9fae59e2f3853576e3e/
Edited pages:

v19.2/known-limitations.md
v19.2/rename-database.md
v19.2/rename-table.md
v20.1/known-limitations.md
v20.1/rename-database.md
v20.1/rename-table.md
v20.2/known-limitations.md
v20.2/rename-database.md
v20.2/rename-table.md

@lucy-zhang Friendly ping on re-review. :)

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/82ad7d829e0c2881686f404999186c573ae6dde7/
Edited pages:

v19.2/known-limitations.md
v19.2/rename-database.md
v19.2/rename-table.md
v20.1/known-limitations.md
v20.1/rename-database.md
v20.1/rename-table.md
v20.2/known-limitations.md
v20.2/rename-database.md
v20.2/rename-table.md


text:
Simplified memory management for NifRes<T>::val

This PR simplifies memory management for NifRes<T>::val as described in #1.

Most of the changes look really good. However, I don't think the new released field you have added to NifRes is what we want:

If you don't care about thread-safety, looking at whether val.release is null is enough. (note: I need to re-read the rest of the spec again. I believe that besides ArrowArrayStream the other structs have similar cleanup mechanisms but I'm not 100% sure)
If you do care about thread safety, an atomic bool is not enough. Consider for instance the race condition where one thread is partially through get_next while the other just now calls release.

If you want to make this library thread-safe (which is probably outside of scope for this particular PR) then I think we need to create our own 'wrapper' implementation of ArrowArrayStream for which all of the callback functions are protected by the (same) mutex before calling into the wrapped ArrowArrayStream.

I don't think you can consume an arrow stream concurrently, so we will most likely need to attach its creator PID to it and only allow calls from the same PID. Even the connection is not guaranteed to support concurrency, so we will do some wrapping in Elixir land in the future. :)
About val->release, I would prefer to have our own field than assuming something on the ArrowStream one just because one additional boolean field is super cheap and it avoids this particular coupling?

I don't think you can consume an arrow stream concurrently, so we will most likely need to attach its creator PID to it and only allow calls from the same PID. Even the connection is not guaranteed to support concurrency, so we will do some wrapping in Elixir land in the future. :)

This is a good approach. I think we can live with the 'only same PID allowed' restriction and it has much less overhead compared to wrapping things with a mutex. 👍

About val->release, I would prefer to have our own field than assuming something on the ArrowStream one just because one additional boolean field is super cheap and it avoids this particular coupling?

What do you want to accomplish with the field? Do you want this library's NifRes type to be able to wrap structs other than those in the Adbc spec?

@Qqwy I believe none of AdbcStatement, AdbcDatabase, and AdbcConnection have a public release field according to the C spec.

@Qqwy I believe none of AdbcStatement, AdbcDatabase, and AdbcConnection have a public release field according to the C spec.

Correct. These structures are allowed to be re-used many times. And they contain a pointer to the 'AdbcDriver' they are managed by, which contains the methods responsible for manipulating them (including releasing them).
These methods to manipulate these objects on the 'AdbcDriver' themselves return an error (An AdbcStatusCode other than ADBC_STATUS_OK) when called with a structure that was already released.
I assume the long-term plan for this library is to expose these other structures also to both Elixir and --to be able to do anything useful with them-- to NIFs written in other libraries.
Any pre-existing code dealing with Adbc will talk the Adbc spec without requiring extra work by library builders.
If we add an additional 'released' flag on top of this, we require library builders to handle this additional flag properly as well as the handling the release-logic that is part of the Adbc spec.
That is why I prefer to not add the flag.
Are there upsides I am missing?

As an example: Many AdbcStatements can be constructed from an AdbcConnection. When the connection is released using AdbcDriver->AdbcConnectionRelease, all the statements that were constructed from this connection are released behind the scenes. But since the producer (e.g. Sqlite) does not know about our extra flag, the flags on the constructed NifRes<AdbcStatement>s will not be set.

@Qqwy perfect, so I agree we can remove the flag indeed. Thank you for the insights!

--to be able to do anything useful with them--

I don't think we will expose any other resource than the ArrowArrayStream to other NIFs. :)

Actually this flag is just to prevent any databases/statements/connections to be released twice in Adbc{Database,Connection,Statement}Release as it will crash the program.

Alright, so let's do this: this PR is definitely a step forward, so let's merge it in. @Qqwy could you please kindly send a PR with your changes on top so we can give it a try afterwards? Thank you all :heart:

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

Oh wait, I realized it is not my project. Sorry @cocoa-xu, force of habit :D

After checking the source code in adbc, I think we can remove the flag. The crash is caused by some inconsistent error-handling behaviour in adbc. When the databases/statements/connections is in invalid state, these functions, Adbc{Database,Connection,Statement}Release, only return ADBC_STATUS_INVALID_STATE without filling the AdbcError struct...

Now I feel double-bad for merging. Sorry!

Definitely no need to feel sorry!

We can do this in another PR to address the inconsistency in Adbc{Database,Connection,Statement}Release.

Thank you both! Collaborating with you two is a lot of fun 😊

authors: Qqwy cocoa-xu josevalim

repo: cocoa-xu/adbc


text:
dose it work with laravel 5.2

dose it work with laravel 5.2

This library is just PHP code, completely framework independent.

authors: florianeckerstorfer johnef

repo: cocur/domain


text:
lib: custom_widgets: Animate simulation card when removed/added to favourite

Currently the card just pops in and out when changing favorite status, an animation on the card would look better.

I would like to work on this.

Sure! Let me know if you have any problem. If contributing under GSSoC, make sure you discuss before opening a PR on slack, it make the review process easier for us.

Sure! Will you assign me to the issue ?

I would love to work on this under Gssoc21 @yashlamba

I would love to work on this under Gssoc21 @yashlamba

@pawan2806 please go ahead!

authors: Sameerkash pawan2806 yashlamba yashugarg

repo: cod-ed/simulate


text:
Bump xmlhttprequest-ssl to 1.6.2

The kind of change this PR does introduce

[x] a bug fix
[ ] a new feature
[ ] an update to the documentation
[ ] a code change that improves performance
[ ] other

Current behaviour
New behaviour
Other information (e.g. related issues)
Addresses this bug https://staging.coda.io/d/Quality-Tracker_d-GJF-DmEUK/My-Issues_sud-l#My-issues_tui9H/r17819&modal=true.

I read through the xmlhttprequest-ssl changelog between 1.5.5 and 1.6.2 and looked at the actual changes - doesn't look like anything breaking was really committed.