print(5) only works on one platform

print(5)

I compile the script to bytecode on Mac (M1 chip).
I run on Mac, it prints "5".
I run on a Cortex M4, it prints "ld".
print("ok") works on both platform.
The bytecode is supposed to be multiplatform?

I guess it's an endianness issue.

I doubt it. Intel and ARM macs are both little endian. The bytecode is not intended to be multiplatform because it depends on compile options like size of int and size of float. However if you compile with the same options it should work.
Can you share the compiled bytecode on both platforms?

Mac and Cortex are both ARM. Not sure if that matters or not…
I don't have a compiler for the Cortex M4.
I generate the bytecode from my Mac:
Bytecode (base64):
echo "vs3+AgMAAAAXAAAAAQAAAAUAX2FyZ3YEAG1haW4HAHRlc3QuYmUAAgAABAAAAAEAAGAEAAZUAAIAfAAAAIAAAAAAAAAAAAA=" | base64 -d > /tmp/test.o

berry_conf.h:
/********************************************************************
** Copyright (c) 2018-2020 Guan Wenliang
** This file is part of the Berry default interpreter.
**<EMAIL_ADDRESS>https://github.com/Skiars/berry
** See Copyright Notice in the LICENSE file or at
** https://github.com/Skiars/berry/blob/master/LICENSE
********************************************************************/
#ifndef BERRY_CONF_H
#define BERRY_CONF_H

#include <assert.h>

/* Macro: BE_DEBUG
 * Berry interpreter debug switch.
 * Default: 0
 **/
#ifndef BE_DEBUG
#define BE_DEBUG                        0
#endif

/* Macro: BE_LONGLONG_INT
 * Select integer length.
 * If the value is 0, use an integer of type int, use a long
 * integer type when the value is 1, and use a long long integer
 * type when the value is 2.
 * Default: 2
 */
#define BE_INTGER_TYPE                  2

/* Macro: BE_USE_SINGLE_FLOAT
 * Select floating point precision.
 * Use double-precision floating-point numbers when the value
 * is 0 (default), otherwise use single-precision floating-point
 * numbers.
 * Default: 0
 **/
#define BE_USE_SINGLE_FLOAT             0

/* Macro: BE_USE_PRECOMPILED_OBJECT
 * Use precompiled objects to avoid creating these objects at
 * runtime. Enable this macro can greatly optimize RAM usage.
 * Default: 1
 **/
#define BE_USE_PRECOMPILED_OBJECT       1

/* Macro: BE_DEBUG_RUNTIME_INFO
 * Set runtime error debugging information.
 * 0: unable to output source file and line number at runtime.
 * 1: output source file and line number information at runtime.
 * 2: the information use uint16_t type (save space).
 * Default: 1
 **/
#define BE_DEBUG_RUNTIME_INFO           1

/* Macro: BE_DEBUG_VAR_INFO
 * Set variable debugging tracking information.
 * 0: disable variable debugging tracking information at runtime.
 * 1: enable variable debugging tracking information at runtime.
 * Default: 1
 **/
#define BE_DEBUG_VAR_INFO               1

/* Macro: BE_USE_OBSERVABILITY_HOOK
 * Use the obshook function to report low-level actions.
 * Default: 0
 **/
#define BE_USE_OBSERVABILITY_HOOK       0

/* Macro: BE_STACK_TOTAL_MAX
 * Set the maximum total stack size.
 * Default: 20000
 **/
#define BE_STACK_TOTAL_MAX              20000

/* Macro: BE_STACK_FREE_MIN
 * Set the minimum free count of the stack. The stack idles will
 * be checked when a function is called, and the stack will be
 * expanded if the number of free is less than BE_STACK_FREE_MIN.
 * Default: 10
 **/
#define BE_STACK_FREE_MIN               10

/* Macro: BE_CONST_SEARCH_SIZE
 * Constants in function are limited to 255. However the compiler
 * will look for a maximum of pre-existing constants to avoid
 * performance degradation. This may cause the number of constants
 * to be higher than required.
 * Increase is you need to solidify functions.
 * Default: 50
 **/
#define BE_CONST_SEARCH_SIZE            50

/* Macro: BE_STACK_FREE_MIN
 * The short string will hold the hash value when the value is
 * true. It may be faster but requires more RAM.
 * Default: 0
 **/
#define BE_USE_STR_HASH_CACHE           0

/* Macro: BE_USE_FILE_SYSTEM
 * The file system interface will be used when this macro is true
 * or when using the OS module. Otherwise the file system interface
 * will not be used.
 * Default: 0
 **/
#define BE_USE_FILE_SYSTEM              0

/* Macro: BE_USE_SCRIPT_COMPILER
 * Enable compiler when BE_USE_SCRIPT_COMPILER is not 0, otherwise
 * disable the compiler.
 * Default: 1
 **/
#define BE_USE_SCRIPT_COMPILER          0

/* Macro: BE_USE_BYTECODE_SAVER
 * Enable save bytecode to file when BE_USE_BYTECODE_SAVER is not 0,
 * otherwise disable the feature.
 * Default: 1
 **/
#define BE_USE_BYTECODE_SAVER           0

/* Macro: BE_USE_BYTECODE_LOADER
 * Enable load bytecode from file when BE_USE_BYTECODE_LOADER is not 0,
 * otherwise disable the feature.
 * Default: 1
 **/
#define BE_USE_BYTECODE_LOADER          1

/* Macro: BE_USE_SHARED_LIB
 * Enable shared library  when BE_USE_SHARED_LIB is not 0,
 * otherwise disable the feature.
 * Default: 1
 **/
#define BE_USE_SHARED_LIB               0

/* Macro: BE_USE_OVERLOAD_HASH
 * Allows instances to overload hash methods for use in the
 * built-in Map class. Disable this feature to crop the code
 * size.
 * Default: 1
 **/
#define BE_USE_OVERLOAD_HASH            1

/* Macro: BE_USE_DEBUG_HOOK
 * Berry debug hook switch.
 * Default: 0
 **/
#define BE_USE_DEBUG_HOOK               0

/* Macro: BE_USE_DEBUG_GC
 * Enable GC debug mode. This causes an actual gc after each
 * allocation. It's much slower and should not be used
 * in production code.
 * Default: 0
 **/
#define BE_USE_DEBUG_GC                  0

/* Macro: BE_USE_XXX_MODULE
 * These macros control whether the related module is compiled.
 * When they are true, they will enable related modules. At this
 * point you can use the import statement to import the module.
 * They will not compile related modules when they are false.
 **/
#define BE_USE_STRING_MODULE            1
#define BE_USE_JSON_MODULE              1
#define BE_USE_MATH_MODULE              1
#define BE_USE_TIME_MODULE              0
#define BE_USE_OS_MODULE                0
#define BE_USE_GLOBAL_MODULE            1
#define BE_USE_SYS_MODULE               1
#define BE_USE_DEBUG_MODULE             1
#define BE_USE_GC_MODULE                1
#define BE_USE_SOLIDIFY_MODULE          1
#define BE_USE_INTROSPECT_MODULE        1
#define BE_USE_STRICT_MODULE            1

/* Macro: BE_EXPLICIT_XXX
 * If these macros are defined, the corresponding function will
 * use the version defined by these macros. These macro definitions
 * are not required.
 * The default is to use the functions in the standard library.
 **/
#define BE_EXPLICIT_ABORT               abort
#define BE_EXPLICIT_EXIT                exit
#define BE_EXPLICIT_MALLOC              malloc
#define BE_EXPLICIT_FREE                free
#define BE_EXPLICIT_REALLOC             realloc

/* Macro: be_assert
 * Berry debug assertion. Only enabled when BE_DEBUG is active.
 * Default: use the assert() function of the standard library.
 **/
#define be_assert(expr)                 assert(expr)

#endif

Sorry I thought it was both macs. Modern processors are often capable of doing both little and big endian, it depends on how they are configured at boot. But indeed bytecode will be different if endianness is different.
For Cortex M4 I would suggest to use 32 bits ints and 32 bits floats, it will probably make smaller code.
How do you test on Cortex M4 if you don't have a compiler?

I generate the bytecode on mac.

And the only use the vm on the Cortex.

By compiling I meant compiling my berry code into bytecode.
The goal is to avoid extra work on the embedded device, and also save space.
Compiling require extra CPU work, and using source code instead of bytecode use extra Flash space. It's work that can be done ahead of time on a host machine.
It's something I was doing with Lua. There is a cross-compiler that allows compiling for the embedded CPU from a host machine.
Would that be something doable?

Hmm, it looks like something else. I'm now not using bytecode on the device, but the source directly, and I get the same result.
I'm investigating…

print("foo")
print("5")
print(5)
print("8")
print(8)
print("bar")

This prints:
foo
5
ld
8
ld
bar

I use be_loadmode(vm, "test.be", false)

Using BE_INTGER_TYPE=1 instead of 2 solves the issue.
But I'd like to use 64 bits integers.

Results:

BE_INTGER_TYPE=2: compiled on Mac or Cortex, executed on Cortex, I'm getting "ld" when calling print(5).
BE_INTGER_TYPE=2: compiled on Mac, executed on Mac, it works as expected.
BE_INTGER_TYPE=1: compiled on Cortex, executed on Cortex, it works as expected.
BE_INTGER_TYPE=1: compiled on Mac, executed on Cortex, I get an "invalid bytecode" error.
BE_INTGER_TYPE=0: compiled on Mac, executed on Cortex, it works as expected.

I think that your cortex M4 libs does not support 64 bits. Which is common on embedded devices to save space.
As said before I strongly advise to use 32 bits integers. If you use the same Berry compile options then you can do cross bytecode compile

Understood.
BE_INTGER_TYPE=0 works well.
I'm using Berry on this chip from Rust code, and it's working really well. Lot nicer than using lua or other solutions.
Thank you.


Reasoning behind returning false on RSemaphore

Why do methods such as trySetPermits only return false when the attempt fails? I am trying to debug an issue around using semaphores, and this method is returning false; however, since no exception is thrown, I have no insight into why this is failing.
What would be the possible reasons for failing on this method?

Unable to reproduce the issue.


cmd/compile: recognize and optimize "in range" booleans

package p

func inrange(x int) bool {
	return 5 <= x && x < 10
}

func inrange2(x int) bool {
	return uint(x-5) < 5
}

These two functions are equivalent, but the second is more efficient (it trades a subtraction for a compare-and-branch). We do this already for index-in-bounds checks. We should generally recognize integer-in-range patterns and convert them.
We should probably do this in the SSA backend, since it'll be more general and powerful there than a limited front-end rewrite like rotation recognition. (I'm open to being convinced otherwise, though.)
This will be helpful for #15780. It'll also help a bit with a hot line in scanobject (arena_start <= obj && obj < arena_used).
/cc @brtzsnr @randall77

This turns out to be a real pain to do in SSA, so I added it to the frontend instead. Even the fairly simple fix there has pleasing results for package strconv, which makes heavy use of these kinds of checks, both directly and via package unicode.
name                          old time/op  new time/op   delta
Atof64Decimal-8               41.4ns ± 3%   38.9ns ± 2%   -5.89%  (p=0.000 n=24+25)
Atof64Float-8                 48.5ns ± 0%   46.8ns ± 3%   -3.64%  (p=0.000 n=20+23)
Atof64FloatExp-8              97.7ns ± 4%   93.5ns ± 1%   -4.25%  (p=0.000 n=25+20)
Atof64Big-8                    187ns ± 8%    162ns ± 2%  -13.54%  (p=0.000 n=24+22)
Atof64RandomBits-8             250ns ± 6%    233ns ± 5%   -6.76%  (p=0.000 n=25+25)
Atof64RandomFloats-8           160ns ± 0%    152ns ± 0%   -5.00%  (p=0.000 n=21+22)
Atof32Decimal-8               41.1ns ± 1%   38.7ns ± 2%   -5.86%  (p=0.000 n=24+24)
Atof32Float-8                 46.1ns ± 1%   43.5ns ± 3%   -5.63%  (p=0.000 n=21+24)
Atof32FloatExp-8               101ns ± 4%    100ns ± 2%   -1.59%  (p=0.000 n=24+23)
Atof32Random-8                 136ns ± 3%    133ns ± 3%   -2.83%  (p=0.000 n=22+22)
Atoi-8                        33.8ns ± 3%   30.6ns ± 3%   -9.51%  (p=0.000 n=24+25)
AtoiNeg-8                     31.6ns ± 3%   29.1ns ± 2%   -8.05%  (p=0.000 n=23+24)
Atoi64-8                      48.6ns ± 1%   43.8ns ± 1%   -9.81%  (p=0.000 n=20+23)
Atoi64Neg-8                   47.1ns ± 4%   42.0ns ± 2%  -10.83%  (p=0.000 n=25+25)
FormatFloatDecimal-8           177ns ± 9%    178ns ± 6%     ~     (p=0.460 n=25+25)
FormatFloat-8                  282ns ± 6%    282ns ± 3%     ~     (p=0.954 n=25+22)
FormatFloatExp-8               259ns ± 7%    255ns ± 6%     ~     (p=0.089 n=25+24)
FormatFloatNegExp-8            253ns ± 6%    254ns ± 6%     ~     (p=0.941 n=25+24)
FormatFloatBig-8               340ns ± 6%    341ns ± 8%     ~     (p=0.600 n=22+25)
AppendFloatDecimal-8          79.4ns ± 0%   80.6ns ± 6%     ~     (p=0.861 n=20+25)
AppendFloat-8                  175ns ± 3%    174ns ± 0%     ~     (p=0.722 n=25+20)
AppendFloatExp-8               142ns ± 4%    142ns ± 2%     ~     (p=0.948 n=25+24)
AppendFloatNegExp-8            137ns ± 2%    138ns ± 2%   +0.70%  (p=0.001 n=24+25)
AppendFloatBig-8               218ns ± 3%    218ns ± 4%     ~     (p=0.596 n=25+25)
AppendFloatBinaryExp-8        80.0ns ± 4%   78.0ns ± 1%   -2.43%  (p=0.000 n=24+21)
AppendFloat32Integer-8        82.3ns ± 3%   79.3ns ± 4%   -3.69%  (p=0.000 n=24+25)
AppendFloat32ExactFraction-8   143ns ± 2%    143ns ± 0%     ~     (p=0.177 n=23+19)
AppendFloat32Point-8           175ns ± 3%    175ns ± 3%     ~     (p=0.062 n=24+25)
AppendFloat32Exp-8             139ns ± 2%    137ns ± 4%   -1.05%  (p=0.001 n=24+24)
AppendFloat32NegExp-8          134ns ± 0%    137ns ± 4%   +2.06%  (p=0.000 n=22+25)
AppendFloat64Fixed1-8         97.8ns ± 0%   98.6ns ± 3%     ~     (p=0.711 n=20+25)
AppendFloat64Fixed2-8          110ns ± 3%    110ns ± 5%   -0.45%  (p=0.037 n=24+24)
AppendFloat64Fixed3-8          102ns ± 3%    102ns ± 3%     ~     (p=0.684 n=24+24)
AppendFloat64Fixed4-8          112ns ± 3%    110ns ± 0%   -1.43%  (p=0.000 n=25+18)
FormatInt-8                   3.18µs ± 4%   3.10µs ± 6%   -2.54%  (p=0.001 n=24+25)
AppendInt-8                   1.81µs ± 5%   1.80µs ± 5%     ~     (p=0.648 n=25+25)
FormatUint-8                   812ns ± 6%    816ns ± 6%     ~     (p=0.777 n=25+25)
AppendUint-8                   536ns ± 4%    538ns ± 3%     ~     (p=0.798 n=20+22)
Quote-8                        605ns ± 6%    602ns ± 9%     ~     (p=0.573 n=25+25)
QuoteRune-8                   99.5ns ± 8%  100.2ns ± 7%     ~     (p=0.432 n=25+25)
AppendQuote-8                  361ns ± 3%    363ns ± 4%     ~     (p=0.085 n=25+25)
AppendQuoteRune-8             23.3ns ± 3%   22.4ns ± 2%   -3.79%  (p=0.000 n=25+24)
UnquoteEasy-8                  146ns ± 4%    145ns ± 5%     ~     (p=0.112 n=24+24)
UnquoteHard-8                  804ns ± 6%    771ns ± 6%   -4.10%  (p=0.000 n=25+24)

This optimization is only safe for constant bounds, because if the low bound is higher than the high bound, their different underflows. It therefore doesn't help the scanobject check. However, the scanobject can be adjusted manually; I plan to do so.


Error: Incorrect arguments to mysqld_stmt_execute

Executing:
sql.execute(SQL`
        SELECT id, name
        FROM account
        LEFT JOIN login ON login.account_id = account.id
        WHERE login.account_id=${buffer.readInt32BE(0)} AND login.secret=UNHEX(${buffer.toString('hex', 4)}) LIMIT 1`)

yields:
Error: Incorrect arguments to mysqld_stmt_execute
    at Packet.asError (\node_modules\mysql2\lib\packets\packet.js:543:13)
    at Execute.Command.execute (\node_modules\mysql2\lib\commands\command.js:28:22)
    at Connection.handlePacket (\node_modules\mysql2\lib\connection.js:261:28)
    at PacketParser.onPacket (\node_modules\mysql2\lib\connection.js:95:66)
    at PacketParser.executeStart (\node_modules\mysql2\lib\packet_parser.js:44:12)
    at Socket.<anonymous> (\node_modules\mysql2\lib\connection.js:97:29)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:177:18)
    at Socket.Readable.push (_stream_readable.js:135:10)
    at TCP.onread (net.js:542:20) code: 'ER_WRONG_ARGUMENTS', errno: 1210, sqlState: '#HY000'

This works:
sql.execute(`
        SELECT id, name
        FROM account
        LEFT JOIN login ON login.account_id = account.id
        WHERE login.account_id=? AND login.secret=UNHEX(?) LIMIT 1`, [buffer.readInt32BE(0), buffer.toString('hex', 4)])

I'm using mysql2/promise and MariaDB.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/36896759-error-incorrect-arguments-to-mysqld_stmt_execute?utm_campaign=plugin&utm_content=tracker%2F23067419&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F23067419&utm_medium=issues&utm_source=github).

Hi, what is the output when you do
console.log(SQL`
        SELECT id, name
        FROM account
        LEFT JOIN login ON login.account_id = account.id
        WHERE login.account_id=${buffer.readInt32BE(0)} AND login.secret=UNHEX(${buffer.toString('hex', 4)}) LIMIT 1`)

?

SQLStatement {
  strings:
   [ '\n        SELECT id, name\n        FROM account\n        LEFT JOIN login ON login.account_id = account.id\n        WHERE login.account_id=',
     ' AND login.secret=UNHEX(',
     ') LIMIT 1' ],
  values: [ 12, 'ee926e1bb3c53a574cdc776845d5478e8f3a39c6' ] }

ah sorry, the non-enumerable properties are not included. Could you please do
console.log(require('util').inspect(SQL`...`, {showHidden: true}))

And on what version are you?

SQLStatement {
  strings:
   [ '\n        SELECT id, name\n        FROM account\n        LEFT JOIN login ON login.account_id = account.id\n        WHERE login.account_id=',
     ' AND login.secret=UNHEX(',
     ') LIMIT 1',
     [length]: 3 ],
  values: [ 12, 'ee926e1bb3c53a574cdc776845d5478e8f3a39c6', [length]: 2 ] }

Version 2.2.0

I should mention that calling sql.query instead of sql.execute works. But mysql2 won't execute this as a prepared statement then.

That did not do the trick, could you just log console.log(SQL....sql)?

'\n        SELECT id, name\n        FROM account\n        LEFT JOIN login ON login.account_id = account.id\n        WHERE login.account_id=? AND login.secret=UNHEX(?) LIMIT 1'

But that seems to be correct... Does it work if you run the query like this
sql.execute({sql: '...', values: [...]})

?

Same error with .execute but works with .query

Then this is not an issue with this library 😉


remove storybook deployment step for storybook.move.mil - MB-3431

Description
This PR removes storybook deploy step for storybook.move.mil so it stops getting latest storybook copy. The buckets content that holds files for storybook.move.mil will be replaced by a single html re-directing to storybook new home @ storybook.dp3.us
Contents of stand-in html file:
<!doctype html>

  <meta charset="utf-8">
  <title>Storybook has moved</title>

Hi there, storybook has a new home and can be found at storybook.dp3.us.

Code Review Verification Steps

[ ] User facing changes have been reviewed by design.
[x] Request review from a member of a different team.
[x] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change

Screenshots
Storybook.move.mil will look like this shortly:

Messages

:book:
:link: MB-3431

  Generated by :no_entry_sign: dangerJS against 047a90d3fbf0f3f0de215827dd8c294c5d0a4b0f


Hugo docker cannot find Go binary in PATH

What version of Hugo are you using (hugo version)?

$ hugo version
0.135 (docker)

Does this issue reproduce with the latest release?
Yes
When using hugo to load the modules from my go.mod file, my CI on GitLab complains that the image hasn't "go" in it's PATH.
See log
log.txt

Fixed in #12921 ....


doc/image-handling: Cover publishing

Signed-off-by: Stéphane Graber<EMAIL_ADDRESS>

Testsuite passed

@tomponline good to go


'this' does not contain validated form values in action callback

When using data= to setup initial form values, this of the action callback contains those initial values instead of the new validated values.
This issue does not occur when not using data=.
A workaround is to use the els argument to get the value from the DOM:
        return function(els, callbacks) {
            var fields = {};
            els.forEach(function(el)
                {
                var $el = $(el);
                var name = $el.attr('name');
                check(name, String);
                fields[name] = $el.val();
                });

            // Here 'this' contains the old values and 'fields' contains the new ones
            ...
        }

Thanks for the workaround. I will fix this ASAP.

Just want to confirm--does this happen when you've made changes to the form elements that passed validation?

I cannot reproduce the issue! Please let me check.

Got it: the issue occurs when I change the value programatically (using $element.val(newValue)). The issue does not occur when changing the value manually (normal case).
My mistake is that I expected the package to behave the same way when changing values manually and programatically.

I will add a feature request for a function to change values programatically :-)

When you register an element, the validationEvent is what triggers the change. So you can probably pull it off just by triggering that event on the element with the ".reactive-element" class with jQuery after the update.

Your suggestion works like a charm, thanks a lot!


Add support for TCP_CONGESTION socketopt

tcp_congestion uses raw syscall since diff os have diff policy on modifying len
set_tcp_congestion uses raw syscall since exact str len must be passed in

Closes: #370
Co-authored-by: Campbell He<EMAIL_ADDRESS>

Currently have no idea why FreeBSD throws an error on the code debug_assert_eq!(len as usize, size_of::<T>()); since let mut len = size_of::<T>() as libc::socklen_t;.
Woking on this now.

I have fixed the error thrown by FreeBSD. This is because that FreeBSD will modify the len field to the true string lenght while Linux not.
Now this pr is ready for review.

Code has been polished again, ready for another review!

Some modification:

New tcp ca test is added
tcp_congestion return the untruncated u8 buf[..len]

Execute the command sysctl net.inet.tcp.cc.available on FreeBSD CI, which shows that it only supports newreno. This might be because other cc modules are not loaded.

So now I only test newreno on FreeBSD. Any suggestion?

I have a suggestion that can we use OsString instead as the crate nix does? Accepting a &[u8] and especially returning the Vec with trailing \0s seems not so user-friendly I'm afraid. Up to you to confirm which interface you prefer.
Also, newreno is the only ca we can test on CI's FreeBSD.
So any ideas on the two points? Or is there anything else I should implement?

So now I only test newreno on FreeBSD. Any suggestion?

That's fine, let's just set newreno again.

I have a suggestion that can we use OsString instead as the crate nix does? Accepting a &[u8] and especially returning the Vec with trailing \0s seems not so user-friendly I'm afraid. Up to you to confirm which interface you prefer.

No, we're already using Vec<u8>/&[u8] other places. Let's stick with a consistent API.

Get  your point. Then I've implemented all requested.

Thanks @BobAnkh


Expose metrics on port 8080

What type of PR is this?
/kind bug
What this PR does / why we need it:
Expose metrics on port 8080
Also fix help message for http-endpoint
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
By default, metrics are now exposed on port 8080.

Can you add a release note?

/lgtm
/approve


Server side dependencies prevent client side compilation

Hello!
If I have @elysiajs/static or @elysia/apollo-graphql in my server definition client side compilation will fail.
This is happening because of inner dependencies which are not available in the browser environment.
While it can be solved and handled (for example, by splitting your eden-safe plugins and unsafe ones and applying the unsafe ones in a different files), I think it points to an underlying limitation.
Am I missing something?
If not, do you think we can improve the situation with a specific bun build configuration? Shall we consider an alternative route where we produce a static specification of the API and embed a simple JSON in the client?
Error details:
Apollo:
error: No matching export in "node:zlib" for import "gzip"

import { gzip } from 'zlib';
         ^
elysia-demo/node_modules/@elysiajs/apollo/node_modules/@apollo/server/dist/esm/plugin/usageReporting/plugin.js:8:10 377

Static:
error: No matching export in "node:path" for import "resolve"

import { resolve, resolve as resolveFn, join } from 'path';
         ^
elysia-demo/node_modules/@elysiajs/static/dist/index.js:2:10 54

error: No matching export in "node:path" for import "resolve"

import { resolve, resolve as resolveFn, join } from 'path';
                  ^
elysia-demo/node_modules/@elysiajs/static/dist/index.js:2:19 63

error: No matching export in "node:path" for import "join"

import { resolve, resolve as resolveFn, join } from 'path';
                                        ^
elysia-demo/node_modules/@elysiajs/static/dist/index.js:2:41 85

Cheers

My bad, I was importing something else from the same file!
The proper solution is to only import the type
import type { ElysiaApp } from "..";

and not
import { ElysiaApp, origin } from "..";


XDG_CONFIG_HOME being incorrectly set via post-generation scripts

Description
I'm unsure at what point the post-generation scripts are supposed to be ran, so this might be entirely my own fault but i'm using this repo to create images to run my own Azure DevOps Agents so that i have more power behind the build agent for various tasks. This repo seemed like a great starting point to get a "like for like" experience from Microsoft hosted to self-hosted without encountering issues of things not existing.
Having ran the GenerateResourcesAndImage to create a VHD, an image was created from the VHD and this image backs the agents.
i'm unsure at what point i should be running this post-generation script so that the agent is able to execute properly. Looking at the Azure VM Scale Set approach, it results in a VMSS which spins instances up and the azure devops extension is enabled which results in the azure-devops agent being installed and configured to enable jobs within a relevant pool.
My issue is that the azure-devops extension creates a user AzDevOps, and the custom-script extension executes before the agent is installed.
Should i be running the instances with AzDevOps as the default user so that when the custom-script extension executes the correct values are populated into the /etc/environment settings? (since currently, i'm getting admin in /etc/environment and the jobs fail as they are running as AzDevOps and attempt to populate things in the wrong directories)
I see that post-generation was added in this PR to address different issues happening in the past https://github.com/actions/runner-images/pull/3030
Platforms affected

[X] Azure DevOps
[ ] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[X] Ubuntu 22.04
[ ] macOS 11
[ ] macOS 12
[ ] macOS 13
[ ] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
built using the git tag tags/ubuntu22/20230702.1
Is it regression?
no
Expected behavior
Agent runs the jobs that worked on the microsoft-hosted pool, using config files as specified by the XDG_CONFIG_HOME
Actual behavior
Job fails as it is attempting to write to the wrong directory (instance default user, not AzDevOps)
Repro steps

Create a VHD using the provided packer scripts
Create an Image from this VHD
Create a Virtual Machine Scale Set with a user such as admin
Attach the VMSS to an Azure DevOps Pipeline pool
Add the custom-script extension to run the post-generation scripts (again, not sure this is the correct place for the post-generation)
Run jobs checking the values of /etc/environment and see that it has admin within it not AzDevOps

Hello @jack1902, thank you for finding a solution for your issue and sharing it with the community. Since post-generation scripts are intended to be run manually, and we cannot predict all cases, we would not like to change anything here.
This issue will be closed. If you have any questions feel free to reach us.


License

Could you kindly add a license for your tutorial code?
https://choosealicense.com//

Done! Sorry for the delay @duber000 😁


hwdata: 0.310 -> 0.311

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/hwdata/versions.
These checks were done:

built on NixOS
Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
found 0.311 with grep in /nix/store/gfaiffnb4k4pmszbnv41jxmibvd07v1w-hwdata-0.311
directory tree listing: https://gist.github.com/a3dcff8ef8aec362a11c36f07277ad0d

Success on x86_64-linux (full log)
Attempted: hwdata
Partial log (click to expand)
done
mkdir -p -m 755 /nix/store/gfaiffnb4k4pmszbnv41jxmibvd07v1w-hwdata-0.311/lib/modprobe.d
install -m 644 -T blacklist.conf /nix/store/gfaiffnb4k4pmszbnv41jxmibvd07v1w-hwdata-0.311/lib/modprobe.d/dist-blacklist.conf
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/gfaiffnb4k4pmszbnv41jxmibvd07v1w-hwdata-0.311
strip is /nix/store/fzcs0fn6bb04m82frhlb78nc03ny3w55-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/gfaiffnb4k4pmszbnv41jxmibvd07v1w-hwdata-0.311/lib
patching script interpreter paths in /nix/store/gfaiffnb4k4pmszbnv41jxmibvd07v1w-hwdata-0.311
checking for references to /tmp/nix-build-hwdata-0.311.drv-0 in /nix/store/gfaiffnb4k4pmszbnv41jxmibvd07v1w-hwdata-0.311...
/nix/store/gfaiffnb4k4pmszbnv41jxmibvd07v1w-hwdata-0.311

Success on aarch64-linux (full log)
Attempted: hwdata
Partial log (click to expand)
done
mkdir -p -m 755 /nix/store/gzb7c7wvvazpjygvq2knplsxsj7i1f4i-hwdata-0.311/lib/modprobe.d
install -m 644 -T blacklist.conf /nix/store/gzb7c7wvvazpjygvq2knplsxsj7i1f4i-hwdata-0.311/lib/modprobe.d/dist-blacklist.conf
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/gzb7c7wvvazpjygvq2knplsxsj7i1f4i-hwdata-0.311
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/gzb7c7wvvazpjygvq2knplsxsj7i1f4i-hwdata-0.311/lib
patching script interpreter paths in /nix/store/gzb7c7wvvazpjygvq2knplsxsj7i1f4i-hwdata-0.311
checking for references to /build in /nix/store/gzb7c7wvvazpjygvq2knplsxsj7i1f4i-hwdata-0.311...
/nix/store/gzb7c7wvvazpjygvq2knplsxsj7i1f4i-hwdata-0.311

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: hwdata
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.


Translate /concepts/overview/working-with-objects/kubernetes-objects/ into Japanese

close #13952

/assign @cstoku

Applied suggestions from code review.

/lgtm

/approve

/close


🐛 Pairing failed: isConnected failed: ECONNREFUSED (Connection refused)

Try this:

Open Automate settings
Forget Privileged service ADB keys.
Privileged service start method > Android Debug Bridge
Pair Automate.

(Note: After step 2 above, it was necessary to reset the device.)
New error:
06-21 23:45:37.233 I 422231@6: ADB protocol set
06-21 23:45:37.458 F 422231@6: javax.net.ssl.SSLProtocolException: Read error: ssl=0xb400007078395918: Failure in SSL library, usually a protocol error
error:10000416:SSL routines:OPENSSL_internal:SSLV3_ALERT_CERTIFICATE_UNKNOWN (external/boringssl/src/ssl/tls_record.cc:592 0xb400006f783dfa40:0x00000003)

(Note: After step 2 above, it was necessary to reset the device.)
New error:
06-21 23:45:37.233 I 422231@6: ADB protocol set
06-21 23:45:37.458 F 422231@6: javax.net.ssl.SSLProtocolException: Read error: ssl=0xb400007078395918: Failure in SSL library, usually a protocol error error:10000416:SSL routines:OPENSSL_internal:SSLV3_ALERT_CERTIFICATE_UNKNOWN (external/boringssl/src/ssl/tls_record.cc:592 0xb400006f783dfa40:0x00000003)

Generate a key, and set it. Look at troubleshooting section and look for suffixes, you'll find the fixes.

Flow works when the device is restarted and paired.  However, after Shizuku is manually terminated, the flow gives an error when it is run again.  It is necessary to restart the device and pair it.  But this method does not always work.  So the flow does not work stably.

Flow works when the device is restarted and paired.

As intended.

However, after Shizuku is manually terminated, the flow gives an error when it is run again.

This flow was designed to run only once. I don't know why you have to restart the flow again. It already set TCP to 5555. Now when you press start on shizuku, you can select 5555, and it will run again.

It is necessary to restart the device and pair it.

No, paring process is only time thing. Seems like a device issue to me.

But this method does not always work. So the flow does not work stably.

Flow works perfectly fine. I'm running it on my device for over a week now.
You need to check your device settings.

Hi again,
I rearranged
Shizuku batch start.zip
Flow to work the way I wanted.  So I can run Shizuku with a single click only when I need it.  This prevents the device's resources from being used in vain and positively affects its performance.  I put important explanations about Flow in Turkish. Thanks 'Rahat Gazi'.

Hi again,
I rearranged Shizuku batch start.zip Flow to work the way I wanted. So I can run Shizuku with a single click only when I need it.

Glad to hear that.

This prevents the device's resources from being used in vain and positively affects its performance.

Does shizuku really use that many resources? I keep it running, I don't see any issue.

I put important explanations about Flow in Turkish. Thanks 'Rahat Gazi'.

Nice, you should translate it in English and share it on automate community, should if anyone else need it.
By the way, did the isConnected failed issue resolve?


[Improve] Improve streampark-console module base on [4 Exception Processing]

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
[Improve] Improve streampark-console module base on 4 Exception Processing
Usage Scenario
No response
Related issues
#2986
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

N.A


Add BC.repo type

Before, BC.create and similar took a config argument. Now, they take a repo argument, which can be obtained by calling BC.connect config.
The main goal here is to allow state to be shared between branches. For example, an Irmin repository backed by a database could open a connection in connect once, where currently it must open one connection for every branch or head store created.
A memory store could use this to keep the state (rather than using a global) and an HTTP-backed store could use this for the connection pool.
In fact, the old code didn't open one connection per branch, but 4, because the content, node, commit and tag stores each also open a connection. Ideally, I'd like to share the repo with these backing stores to get the number of required connections down to 1, but that isn't done yet.
Also, the terminology isn't very good:

connect may be confusing for HTTP stores, since it might not make an HTTP connection at that point
there should probably be separate modules for Repository and Branch, rather than bundling everything in Store.

Does this look like a reasonable approach?

Does this look like a reasonable approach?

Yes it is! Few things are not totally clear to me yet though:

why do you need to remove the create function from AO? the BC store can just redefine the function.
it is not totally clear by reading the API why you gain by doing the change. I understand the rational (caching repository connection) but I think we should find a way to expose it a bit better. Maybe going further and having separate Repo and Branch modules would make sense. Would make sense to rename Tag as the same time :-)

OK, there's now a Repo.t that can hold state that is shared between multiple branches. In particular, the contents, node, commit and ref_store stores are now created once per repository, not once per branch.
BC.create is now BC.master and takes a Repo.t rather than a config. It takes it as the last parameter to simplify the single-branch case:
BC.Repo.create config >>= BC.master task >>= fun t ->

BC.of_branch_id, BC.of_head and BC.empty are changed similarly.
BC.config is gone, and replaced by BC.repo. BC.Repo.config can then be used to recover the configuration. I'd like to remove this at some point, allowing custom constructors with different arguments, but some code needs it for now.
AO.config is still needed, for the hack in Irmin_git.Internals. Would be good to find a way for implementations to extend the basic operations in a type-safe way.
View.config is gone (it just returned Ir_conf.empty), as are the configs for the RW stores in the various back-ends.

Looks good. Just check that create is not used in the doc anymore.

Fixed. The other reference is from the examples section, but those are very out-of-date anyway. It's probably worth waiting until the next release to update those, as there are more changes coming...


https website forcibly redirects to http

I am using snitchdns deployed over docker. The DNS as such works fine. The difficulty is in accessing the ui.
Only the https server is working. http just returns not found response.
Morevoer whenever I submit a form in the ui, it redirects to the http site and goes to 404 not found.
I have to manually change the url each time from http to https.
If this bug is fixed, the system is really easy to setup and use.

Thanks for reporting this.
I'm not able to reproduce this using a standard setup in my VM - in the past however, this issue was caused by running SnitchDNS using SSH tunnels (which was fixed).
Could you please describe your setup, and could you confirm you're using the latest and greatest Dockerfile?

Thanks for the update - I'll have a look and try to reproduce the issue locally.

Hi @srnthsrdhrn - are you still having this issue?

@sadreck The issues still exists. Just cloned the repo and did the build/run command and the UI runs on HTTPS port but constantly redirects to HTTP (http://localhost/install for example upon first request after start).

@jnehlmeier could you describe your setup please? Things like:

Which OS are you using?
Where are you installing it? Cloud, local/lan VM?
How are you connecting to it? Is there a VPN in place? Are you using SSH tunnels?
Are you behind any sort of load balancer that rewrites origin IPs?
Anything else that you think might help me reproduce this?

Really nothing special.
I use docker on macOS 10.15.7 and simply did your short tutorial without modifying any dockerfile build arg.
Then I executed docker run -p 80:80 -p 443:443 -p 5311:2024/udp --name snitch snitchdns and opened http://localhost which shows me the default apache index html page. Then I opened https://localhost which redirected to http://localhost/install so I had to change it back to https://localhost/install in order to see the UI. Then in your ADMIN UI after saving anything it usually redirects to HTTP instead fo HTTPS. Switching menu items works though (except opening the system settings at the top right).

Ok I have to correct me. I already had something running on port 80 and 443 and thus used different ports. And that seems to be the issue.

Add <IP_ADDRESS>   www.snitch.docker to /etc/hosts
Execute docker run -p 8800:80 -p 4430:443 -p 5300:2024/udp --name snitch snitchdns
Open http://www.snitch.docker:8800
You will be redirected to https://www.snitch.docker:8800 which obviously fails to load
Change URL to `https://www.snitch.docker:4430
You will be redirected to http://www.snitch.docker:4430/install/ and you see the message that a HTTP request has been done to a HTTPS port. So for some reason a HTTPS to HTTP redirect has been done here.
Change URL back to https:// to see the install page

If I run the app with published port 80 and 443 everything works as expected.

Thanks for the detailed steps! I'll have a look when I get some downtime.


agda, nixos/tests/agda: LLVM error on aarch64-linux

Describe the bug
The test nixos/tests/agda.nix fails on aarch64-linux because it doesn't find LLVM:
Calling: /nix/store/jg9bfvlpmgwrmnzw2ny78lcz6gigqqqh-ghc-8.10.3-with-packages/bin/ghc -O -o /tmp/HelloWorld -Werror -i/tmp -main-is MAlonzo.Code.HelloWorld /tmp/MAlonzo/Code/HelloWorld.hs --make -fwarn-incomplete-patterns -fno-warn-overlapping-patterns
[  1 of 130] Compiling MAlonzo.RTE      ( MAlonzo/RTE.hs, MAlonzo/RTE.o )
Compilation error:

<no location info>: error:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM 9

<no location info>: error:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM 9
ghc: could not execute: opt

Note that Agda itself works fine, but the subsequent call to ghc doesn't succeed.
The correct resolution is probably to make sure that on aarch64-linux, the GHC called by Agda has an additional dependency on LLVM. (We could also make LLVM available on the test machine, but I think it's likely that Agda is actually broken on aarch64-linux in general, not just in the test.)
Notify maintainers
@alexarice @neosimsim

Example failed run: https://hydra.nixos.org/build/136240205

Side note: It would be nice to have a 6.topic: agda label, but I don't know who can create one.

I don't know how I reproduce this locally. I can do nix-build nixos/tests/agda.nix --option system aarch64-linux --sandbox, but then I get:
warning: ignoring the user-specified setting 'sandbox', because it is a restricted setting and you are not a trusted user
warning: ignoring the user-specified setting 'system', because it is a restricted setting and you are not a trusted user
[...]
error: a 'aarch64-linux' with features {} is required to build '/nix/store/w6wf7h1cqam1vy3jma072iz6lic072m0-hello-world.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

When I add myself to trusted users and execute the same command (with or without --sandbox), I get:
building '/nix/store/qn5r3sdski7j47hzwa64bl2l8iqijns4-append-initrd-secrets.drv'...
while setting up the build environment: executing '/nix/store/83zszzf9h5zrgaasga0wwm4jnpby4i1z-bash-4.4-p23/bin/bash': Exec format error
while setting up the build environment: executing '/nix/store/83zszzf9h5zrgaasga0wwm4jnpby4i1z-bash-4.4-p23/bin/bash': Exec format error
builder for '/nix/store/qn5r3sdski7j47hzwa64bl2l8iqijns4-append-initrd-secrets.drv' failed with exit code 1
builder for '/nix/store/w6wf7h1cqam1vy3jma072iz6lic072m0-hello-world.drv' failed with exit code 1
cannot build derivation '/nix/store/nmf13vw5l5k62k9h6cfqmh7bmfhs0lfj-nixos-test-driver-agda.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/kr605yh3vrhjlzvz2bs6qm3fjqr4227b-vm-test-run-agda.drv': 1 dependencies couldn't be built
error: build of '/nix/store/kr605yh3vrhjlzvz2bs6qm3fjqr4227b-vm-test-run-agda.drv' failed

I think the misunderstanding here is that I don't need the build architecture to be aarch64-linux, only the VM architecture.

I unfortunately have no idea about cross compiling

With adisbladis' help I did the following:

Add boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; to my host system
nix-build nixos/tests/agda.nix --option system aarch64-linux

I then get:
$ nix-build nixos/tests/agda.nix --option system aarch64-linux --sandbox
these derivations will be built:
  /nix/store/2bfx002wcaizj49pc70nb63qr13klpwi-vm-test-run-agda.drv
building '/nix/store/2bfx002wcaizj49pc70nb63qr13klpwi-vm-test-run-agda.drv'...
starting VDE switch for network 1
running the VM test script
machine: must succeed: touch TestEmpty.agda
machine: waiting for the VM to finish booting
machine: starting vm
machine # Formatting '/build/vm-state-machine/machine.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=536870912 lazy_refcounts=off refcount_bits=16
machine # kvm version too old
machine # qemu-system-aarch64: failed to initialize kvm: Function not implemented
machine: QEMU running (pid 28)
machine: connected to guest root shell
machine: (connecting took 0.00 seconds)
(0.65 seconds)
error:
Traceback (most recent call last):
  File "/nix/store/avlkddzkp0q51w6rys4wkwcw5cc80b30-nixos-test-driver/bin/.nixos-test-driver-wrapped", line 897, in run_tests
    exec(tests, globals())
  File "<string>", line 1, in <module>
  File "<string>", line 2, in <module>
  File "/nix/store/avlkddzkp0q51w6rys4wkwcw5cc80b30-nixos-test-driver/bin/.nixos-test-driver-wrapped", line 419, in succeed
    (status, out) = self.execute(command)
  File "/nix/store/avlkddzkp0q51w6rys4wkwcw5cc80b30-nixos-test-driver/bin/.nixos-test-driver-wrapped", line 400, in execute
    self.shell.send(out_command.encode())
BrokenPipeError: [Errno 32] Broken pipe
cleaning up
killing machine (pid 28)
(0.00 seconds)
builder for '/nix/store/2bfx002wcaizj49pc70nb63qr13klpwi-vm-test-run-agda.drv' failed with exit code 1
error: build of '/nix/store/2bfx002wcaizj49pc70nb63qr13klpwi-vm-test-run-agda.drv' failed

I can't make any progress here if noone can teach us how to do cross-testing locally.

I have no idea either.

Should be fixed on the haskell-updates branch.

Ok, I'll assume this is fixed. Reopen if the problem occurs again.

It's gonna be a bit until it hits master though, but yeah, I think this should be resolved for now.


feat: support for Windows (using MinGW)

This is a very preliminary attempt. I successfully built it using GCC version 14.2.0 (Rev1, Built by the MSYS2 project), and it works on my machine.
Currently, On Windows, cgo only supports MinGW, and support for MSVC is still in progress (ref: https://github.com/golang/go/issues/20982), so we have to use MinGW.
Although the upstream project (https://github.com/frida/frida-core) has a build action workflow for Windows-MinGW, there is no frida-core-devkit for Windows-MinGW in the releases at https://github.com/frida/frida/releases. This means users need to manually build the frida-core-devkit for Windows-MinGW from source code. (Note: I’m not sure why this is the case.)
Noticing that CI/CD includes testing, based on point 3, it seems challenging to integrate testing for the Windows platform into CI/CD (due to the absence of a frida-core-devkit for Windows-MinGW in https://github.com/frida/frida/releases).
Clearly, most of the examples in the documentation are designed specifically for Unix systems. If needed, I can provide alternative examples for the Windows platform.

@pk5ls20 thank you for this PR. I just have a couple of questions:

Could you please update README.md to reflect the GCC version you tested this on and that MSYS2 is used.
Isn't frida-core.lib built for mingw inside of frida-core-devkit
Windows usage example would be awesome for other folks.

Could you please update README.md to reflect the GCC version you tested this on and that MSYS2 is used.

Sure, I will update the README to include this information.

Isn't frida-core.lib built for mingw inside of frida-core-devkit

Yes, frida-core.lib is built inside the frida-core-devkit. However, the official Frida release (https://github.com/frida/frida/releases/) does not provide a pre-built frida-core-devkit for the Windows MinGW target. This means users need to manually build the frida-core-devkit for the Windows MinGW target from the source.

Windows usage example would be awesome for other folks.

Got it! I will add some example code tailored for the Windows platform in the EXAMPLES.md file.
I will set the PR to draft for now. Once I have time to complete the first and third points and it's ready to be merged, I will mark it as ready for review

Looking forward to it.


One of the node stop responding to the arp requests after some random Minutes (approx 10 ~ 30 min)

Hello All
Thanks for releasing version  0.13.2, I have deployed it in my on-prem k8s cluster. but one of the node stop responding to the arp request after 10~30 min, if I restart all pods in Kube-system then it starts to work for another 10 ~ 30 min.  Is anyone facing similar issues with 0.13.2?
Appreciate your guidance on this. thanks.

Kubernetes Version - v1.21.3
CNI  weave  - weave-kube:2.8.1
MetalLB -  0.13.3 with layer 2 mode (with 2x address pool) ( installed using YAML operator from main branch)

Speaker logs from Node which is having issues after 10 min (Here service announced for only one address pool!)
{"caller":"config_controller.go:148","controller":"ConfigReconciler","end reconcile":"/sum-dev-app","level":"info","ts":"2022-07-08T10:56:20Z"}
{"caller":"service_controller_reload.go:61","controller":"ServiceReconciler - reprocessAll","level":"info","start reconcile":"metallbreload/reload","ts":"2022-07-08T10:56:20Z"}
{"caller":"main.go:344","event":"serviceAnnounced","ips":["<IP_ADDRESS>"],"level":"info","msg":"service has IP, announcing","pool":"sum-dev-ing-ingress","protocol":"layer2","ts":"2022-07-08T10:56:20Z"}
{"caller":"service_controller_reload.go:103","controller":"ServiceReconciler - reprocessAll","end reconcile":"metallbreload/reload","level":"info","ts":"2022-07-08T10:56:20Z"}
{"caller":"config_controller.go:48","controller":"ConfigReconciler","level":"info","start reconcile":"/sum-dev-edge01","ts":"2022-07-08T10:56:30Z"}
{"caller":"config_controller.go:136","controller":"ConfigReconciler","event":"force service reload","level":"info","ts":"2022-07-08T10:56:30Z"}
{"caller":"config_controller.go:147","controller":"ConfigReconciler","event":"config reloaded","level":"info","ts":"2022-07-08T10:56:30Z"}
{"caller":"config_controller.go:148","controller":"ConfigReconciler","end reconcile":"/sum-dev-edge01","level":"info","ts":"2022-07-08T10:56:30Z"}
{"caller":"service_controller_reload.go:61","controller":"ServiceReconciler - reprocessAll","level":"info","start reconcile":"metallbreload/reload","ts":"2022-07-08T10:56:30Z"}
{"caller":"main.go:344","event":"serviceAnnounced","ips":["<IP_ADDRESS>"],"level":"info","msg":"service has IP, announcing","pool":"sum-dev-ing-ingress","protocol":"layer2","ts":"2022-07-08T10:56:30Z"}
{"caller":"service_controller_reload.go:103","controller":"ServiceReconciler - reprocessAll","end reconcile":"metallbreload/reload","level":"info","ts":"2022-07-08T10:56:30Z"}
{"caller":"service_controller.go:60","controller":"ServiceReconciler","level":"info","start reconcile":"app/robot-app-api","ts":"2022-07-08T10:57:20Z"}
{"caller":"service_controller.go:103","controller":"ServiceReconciler","end reconcile":"app/robot-app-api","level":"info","ts":"2022-07-08T10:57:20Z"}
{"caller":"service_controller.go:60","controller":"ServiceReconciler","level":"info","start reconcile":"app/robot-app-api","ts":"2022-07-08T10:57:21Z"}
{"caller":"service_controller.go:103","controller":"ServiceReconciler","end reconcile":"app/robot-app-api","level":"info","ts":"2022-07-08T10:57:21Z"}
{"caller":"config_controller.go:48","controller":"ConfigReconciler","level":"info","start reconcile":"/sum-dev-edgeinit01","ts":"2022-07-08T10:57:47Z"}
{"caller":"config_controller.go:136","controller":"ConfigReconciler","event":"force service reload","level":"info","ts":"2022-07-08T10:57:47Z"}
{"caller":"config_controller.go:147","controller":"ConfigReconciler","event":"config reloaded","level":"info","ts":"2022-07-08T10:57:47Z"}
{"caller":"config_controller.go:148","controller":"ConfigReconciler","end reconcile":"/sum-dev-edgeinit01","level":"info","ts":"2022-07-08T10:57:47Z"}
{"caller":"service_controller_reload.go:61","controller":"ServiceReconciler - reprocessAll","level":"info","start reconcile":"metallbreload/reload","ts":"2022-07-08T10:57:47Z"}
{"caller":"main.go:344","event":"serviceAnnounced","ips":["<IP_ADDRESS>"],"level":"info","msg":"service has IP, announcing","pool":"sum-dev-ing-ingress","protocol":"layer2","ts":"2022-07-08T10:57:47Z"}
{"caller":"service_controller_reload.go:103","controller":"ServiceReconciler - reprocessAll","end reconcile":"metallbreload/reload","level":"info","ts":"2022-07-08T10:57:47Z"}
{"caller":"service_controller.go:60","controller":"ServiceReconciler","level":"info","start reconcile":"app/bms-app-api","ts":"2022-07-08T10:58:27Z"}
{"caller":"service_controller.go:103","controller":"ServiceReconciler","end reconcile":"app/bms-app-api","level":"info","ts":"2022-07-08T10:58:27Z"}
{"caller":"service_controller.go:60","controller":"ServiceReconciler","level":"info","start reconcile":"app/bms-app-api","ts":"2022-07-08T10:58:38Z"}
{"caller":"service_controller.go:103","controller":"ServiceReconciler","end reconcile":"app/bms-app-api","level":"info","ts":"2022-07-08T10:58:38Z"}
{"caller":"config_controller.go:48","controller":"ConfigReconciler","level":"info","start reconcile":"/sum-dev-aiml","ts":"2022-07-08T10:59:51Z"}
{"caller":"config_controller.go:136","controller":"ConfigReconciler","event":"force service reload","level":"info","ts":"2022-07-08T10:59:51Z"}
{"caller":"config_controller.go:147","controller":"ConfigReconciler","event":"config reloaded","level":"info","ts":"2022-07-08T10:59:51Z"}

Speaker logs from Node which do not have any issues. (Here  service announced for both address pools!)
{"caller":"config_controller.go:48","controller":"ConfigReconciler","level":"info","start reconcile":"/sum-dev-edge01","ts":"2022-07-08T11:01:32Z"}
{"caller":"config_controller.go:136","controller":"ConfigReconciler","event":"force service reload","level":"info","ts":"2022-07-08T11:01:32Z"}
{"caller":"config_controller.go:147","controller":"ConfigReconciler","event":"config reloaded","level":"info","ts":"2022-07-08T11:01:32Z"}
{"caller":"config_controller.go:148","controller":"ConfigReconciler","end reconcile":"/sum-dev-edge01","level":"info","ts":"2022-07-08T11:01:32Z"}
{"caller":"service_controller_reload.go:61","controller":"ServiceReconciler - reprocessAll","level":"info","start reconcile":"metallbreload/reload","ts":"2022-07-08T11:01:32Z"}
{"caller":"main.go:344","event":"serviceAnnounced","ips":["<IP_ADDRESS>"],"level":"info","msg":"service has IP, announcing","pool":"sum-dev-app-ingress","protocol":"layer2","ts":"2022-07-08T11:01:32Z"}
{"caller":"main.go:344","event":"serviceAnnounced","ips":["<IP_ADDRESS>"],"level":"info","msg":"service has IP, announcing","pool":"sum-dev-ing-ingress","protocol":"layer2","ts":"2022-07-08T11:01:32Z"}
{"caller":"service_controller_reload.go:103","controller":"ServiceReconciler - reprocessAll","end reconcile":"metallbreload/reload","level":"info","ts":"2022-07-08T11:01:32Z"}
{"caller":"service_controller.go:60","controller":"ServiceReconciler","level":"info","start reconcile":"app/robot-app-api","ts":"2022-07-08T11:02:22Z"}
{"caller":"service_controller.go:103","controller":"ServiceReconciler","end reconcile":"app/robot-app-api","level":"info","ts":"2022-07-08T11:02:22Z"}
{"caller":"service_controller.go:60","controller":"ServiceReconciler","level":"info","start reconcile":"app/robot-app-api","ts":"2022-07-08T11:02:24Z"}
{"caller":"service_controller.go:103","controller":"ServiceReconciler","end reconcile":"app/robot-app-api","level":"info","ts":"2022-07-08T11:02:24Z"}
{"caller":"config_controller.go:48","controller":"ConfigReconciler","level":"info","start reconcile":"/sum-dev-edgeinit01","ts":"2022-07-08T11:02:48Z"}
{"caller":"config_controller.go:136","controller":"ConfigReconciler","event":"force service reload","level":"info","ts":"2022-07-08T11:02:48Z"}
{"caller":"config_controller.go:147","controller":"ConfigReconciler","event":"config reloaded","level":"info","ts":"2022-07-08T11:02:48Z"}
{"caller":"config_controller.go:148","controller":"ConfigReconciler","end reconcile":"/sum-dev-edgeinit01","level":"info","ts":"2022-07-08T11:02:48Z"}

speaker-logs.txt
in the speaker log
All Working Normal From -  2022-07-08T11:57:42Z
Addresspool  <IP_ADDRESS>-4.9  stopped working from - 2022-07-08T12:38:42Z

Hi, apologies for the late reply.
I don't see any of the ips in the <IP_ADDRESS>-4.9 being ever advertised in the logs you added above.
You should find something like
{"caller":"main.go:344","event":"serviceAnnounced","ips":["<IP_ADDRESS>"],"level":"info","msg":"service has IP, announcing","pool":"sum-dev-ing-ingress","protocol":"layer2","ts":"2022-07-08T11:58:23Z"}

for the service you are interested in.
Thats .139 is the only service I see being asked for in those logs, last one
{"caller":"arp.go:105","interface":"eth0","ip":"<IP_ADDRESS>","level":"debug","msg":"got ARP request for service IP, sending response","responseMAC":"00:15:5d:07:fd:0a","senderIP":"<IP_ADDRESS>","senderMAC":"00:15:5d:07:fd:00","ts":"2022-07-08T11:57:42Z"}

Hi Fedepaol,  No worries and Thanks for replying.
I have changed version v0.13.3 since I was  using the main branch previously
I have two layer to configurations

`apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: sum-dev-app-ingress
namespace: metallb-system
spec:
addresses:
- <IP_ADDRESS>-<IP_ADDRESS>
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: sum-dev-app-add
spec:
ipAddressPools:

sum-dev-app-ingress
nodeSelectors:
matchLabels:
kubernetes.io/hostname: sum-dev-app`

`apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: sum-dev-ing-ingress
namespace: metallb-system
spec:
addresses:
- <IP_ADDRESS>-<IP_ADDRESS>
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: sum-dev-ing-add
spec:
ipAddressPools:

sum-dev-ing-ingress
nodeSelectors:
matchLabels:
kubernetes.io/hostname: sum-dev-ing`

both node`s Speaker logs shows that , skipping should announce l2 and the reason is pool not matching my node
logs from sum-dev-app node.txt
logs from sum-dev-ing node.txt
{"caller":"main.go:256","event":"startUpdate","level":"debug","msg":"start of service update","ts":"2022-07-26T04:07:38Z"} {"caller":"bgp_controller.go:159","event":"skipping should announce bgp","ips":["<IP_ADDRESS>"],"level":"debug","pool":"sum-dev-app-ingress","protocol":"bgp","reason":"pool not matching my node","service":"ingress-nginx-app/ingress-nginx-app-controller","ts":"2022-07-26T04:07:38Z"} {"caller":"layer2_controller.go:103","event":"skipping should announce l2","ips":["<IP_ADDRESS>"],"level":"debug","pool":"sum-dev-app-ingress","protocol":"layer2","reason":"pool not matching my node","service":"ingress-nginx-app/ingress-nginx-app-controller","ts":"2022-07-26T04:07:38Z"} {"caller":"main.go:305","event":"endUpdate","level":"debug","msg":"end of service update","ts":"2022-07-26T04:07:38Z"}

Can you double check the labels on the node, making sure they match       kubernetes.io/hostname: sum-dev-ing ?

Hi @fedepaol, Thanks, Yes the labels exist on the nodes.

Other question: is your service with externaltrafficpolicy = local or cluster?
Are the spekaers running on all the nodes?

External Traffic Policy:  Cluster.
Yes Speake pods running in all the nodes

Hi @fedepaol  Thanks for your help.  Found the issue,  kind: L2Advertisement was not applied to metallb-system names space.

oh thanks for following up!
We are changing the webhooks to avoid this to happen!


Make compatible with windows

Thanks for the PR! I've changed the base branch from humble to main. We'll backport to humble after this is merged. Could you just rebase your commit on the main branch?

Done.

Pulls: ros-tooling/topic_tools#68
Gist: https://gist.githubusercontent.com/emersonknapp/6344476197d93205d189a2cf57bae540/raw/e67e903ac4f5f0625e6562d407542891cc75041f/ros2.repos
BUILD args:  --packages-above-and-dependencies topic_tools
TEST args:  --packages-above topic_tools
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/12331

Linux
Linux-aarch64
Windows

Thanks for this patch - we haven't run Windows CI on this package yet, I'm glad it looks like only a small change to make it go. Looking forward to seeing if the CI reveals any extra things. However if this makes build go from red->yellow that's still fine by me and I'll be happy to merge it, even if not green

@mergifyio backport iron humble


AllowToAddGuests - first sentence needs fixing.

"A boolean indicating whether or not is allowed to add guests to this directory."
Incomplete sentence - "...whether or not ___ is allowed...".
And is 'add guests to this directory' the right noun, or is it supposed to read 'add guests to this group'?

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

ID: 4cd7a703-534a-5fbd-6470-5d29bf512fd2
Version Independent ID: 4f70ed16-6a1c-c0be-3c5e-d56e1b7c7275
Content: Configure group settings using PowerShell - Azure AD
Content Source: articles/active-directory/users-groups-roles/groups-settings-cmdlets.md
Service: active-directory
Sub-service: users-groups-roles
GitHub Login: @curtand
Microsoft Alias: curtand

@npherson
Thanks for your feedback! We will investigate and update as appropriate.

Thanks! I made a pull request to fix this. https://github.com/MicrosoftDocs/azure-docs-pr/pull/123905


Expected double-quoted property name in JSON at position 222

Bug description
Click Container logs，Some container will tip “Expected double-quoted property xxx in JSON at position xxx”

Expected behavior
Portainer Logs
Steps to reproduce the issue:
Technical details:

Portainer version: 2.16.0
Docker version (managed by Portainer): 20.10.3 (API: 1.41)
Kubernetes version (managed by Portainer):
Platform (windows/linux): linux
Command used to start Portainer (docker run -p 9443:9443 portainer/portainer):
Browser: Chrome  106.0.5249.62

Additional context

Closing as duplicate of #7956 .
A fix will be available in the next release.


thanks a lot

thanks so much men. just eight hours ago. This is the best. make my day. perfectly integretad with progresive web apps. thanks a lot.

No worries 👍  I'm glad it's being used.
If you come across an issue, performance drop or a memory leak due to this module, just let me know :)


Second browser window is opening.

Hello.
We were trying to update version of playwright-lighthouse from 2.2.2 to 4.0.0.
Older version of the package ran lighthouse audit in the same browser window and it worked well. New version of lighthouse additionally openes new browser window when running function playAudit(). Is there a way to prevent this from happening and perform the audit in the initial browser window?
New browser window doesn't have necessary cookies (and maybe some other storage data?) which causes the page to open with errors.
I found a way to pass necessary cookies to the second browser:
return playAudit({
return playAudit({
  ...
  opts: {
    logLevel: 'debug',
    extraHeaders: {
      Cookie: 'cookie1=val1;cookie2=val2...'
    }
  }
  ...
});

And it did partially help to resolve the issue. Partially, because it passed all the cookies, apart from one. My guess is it is because that specific cookie contained = sybol inside its value, perhaps this somehow prevents the cookie to be added to the 2nd browser?

@ZurabKV Facing the same issue

Same issue, additional consequences.
I'm running a11y audits on a page generated from a form submission (POST). Because playAudit is re-loading the page itself, it does a GET to the url and loses the form context.
await page.route('https://example.com/form-endpoint', (route, request) => {
  const method = 'POST';
  const postData = 'key=value';
  route.continue({ method, postData });
});

await page.goto('https://example.com/form-endpoint'); // works ok
await playAudit({
  page,
  thresholds: {accessibility: 99},
  opts: {onlyCategories: ['accessibility']},
}); // does GET request & reloads the page

It's like running lighthouse in chrome in 'Navigation' mode instead of 'Snapshot'?

Facing the same issue, this repo seems poor maintained

Same issue here.  Sadly, this makes temporal testing impossible with Playwright which, for me, is the big selling point of LightHouse.
I had to revert back several versions to get this working.
"lighthouse": "^9.6.8",
"@lighthousejs/types": "^0.0.3",
"playwright-lighthouse": "^2.2.2",
As Playwright is now the most popular test framework, it would be good to see the Lighthouse plugin maintained for this.


[ASK] [THEME] about tonotdo

WHAT

subject: theme
theme: tonotdo

ASK
I think space is needed in next to ➜  but I'm not sure.
Is this only my problem?
SAMPLE
I wrote sample code.
I added a space in next to ➜.
path: ./oh-my-zsh/themes/tonotdo.zsh-theme
-PROMPT='%{$fg_no_bold[cyan]%}%n%{$fg_no_bold[magenta]%}➜%{$fg_no_bold[green]%}%3~$(git_prompt_info)%{$reset_color%}» '
+PROMPT='%{$fg_no_bold[cyan]%}%n%{$fg_no_bold[magenta]%}➜ %{$fg_no_bold[green]%}%3~$(git_prompt_info)%{$reset_color%}» '

REF

tonotdo: https://github.com/robbyrussell/oh-my-zsh/blob/master/themes/tonotdo.zsh-theme
my dotfiles: https://github.com/sachin21/dotfiles/commit/433b3f42a1ed6239aaf303e532e0e3e9fafeb7e2#diff-a2a09db31be38b45553c68ac2a746d46R61

This looks like it might be a problem with certain fonts.
Here's how it looks for me in Terminal.app on OS X.
With Menlo or Meslo, the characters do not overlap, and it looks fine.

With Courier, the ➜ is displayed as two characters wide, and it overlaps with the following text.

Basically, the font and the terminal don't agree on how wide the character should be. Most of the fonts on my Mac OS X system think ➜ is double-width, like Courier. Menlo seems to be the exception. But both Terminal and iTerm think it's single-width. (There may also be complications where some fonts don't actually include the ➜ glyph, so it's actually using some fallback font for that particular character.)
In no case should spaces be necessary to keep characters from overlapping in the terminal display. This is a bug in the font and/or terminal text rendering stack. But it's not an easy fix, because fonts don't include monospace-cell-count info in them, so terminals have to rely on heuristics or their own size tables or some other hack.
You could switch to Menlo for use with this theme. If you want to add the space in for use with other fonts, maybe you could put it inside a conditional like if [[ $TONOTDO_WIDE_ARROW == true ]] to enable use of this theme with "wide-arrow" fonts, but leave the default behavior the same, since it seems to be developed for fonts where the arrow is single-wide.
@To1ne, as the original tonotdo author, what font(s) were you using when developing this? Thoughts?

I think I've been using Deja Vu at the time.
But to be honest, I do no longer use this theme, I am using agnoster now. So I do not really care about the changes in this theme. Just file a PR of your suggested change.

Okay, I'll be using agnoster.
Thank you :smile:


How can I find out what parameters a specified function takes?

Please add parameters and what this function should return to the documentation

I believe the fcn's arg is just the controllers value.
  gui.add(controller, 'width', 100, 1000, 25).onChange(width => {
        view.setWidth(width)
  })

Oh, and many times with an onChange, you really don't care about the actual controller.width value, you only want to call a function with that value like above.
A sneaky trick is to just have a one-parameter "controller" that is not used elsewhere:
    gui.add({ width: 700 }, 'width', 100, 1000, 25).onChange(val => {
         view.setWidth(val)
    })


feat: Automatically join solicited-node multicast addresses

IPv6 over Ethernet should join the solicited-node multicast
addresses required by the configured IPv6 addresses, as neighbor
solicitations for these addresses have the solicited-node multicast
address as destination address.
This commit automatically leaves old solicited-node multicast addresses
and joins the new set when the IP addresses on the interface are
updated.

One effect of this pr is that an ethernet-based interface wants to send out multicast reports as soon as an IPv6 address is configured. Not sure if there's strong opinions on that.
According to rfc 6775 § 5.2  joining the solicited-node multicast address is not required on IEEE 802.15.4.


haskellPackages.xkbcommon does not build

codehero@wheatley ~ % nix-env -f "<nixpkgs>" -iA haskellPackages.xkbcommon                                                                                :(
installing ‘haskell-xkbcommon-0.0.1’
these derivations will be built:
  /nix/store/nwkw3riiqhdxddw6blwkzsssa1rc00p3-haskell-xkbcommon-0.0.1.drv
building path(s) ‘/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1’
setupCompilerEnvironmentPhase
Build with /nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1.
unpacking sources
unpacking source archive /nix/store/8r94zcd96d4wpvpwcja4kglp2j68kfss-xkbcommon-0.0.1.tar.gz
source root is xkbcommon-0.0.1
patching sources
compileBuildDriverPhase
setupCompileFlags: -package-db=/tmp/nix-build-haskell-xkbcommon-0.0.1.drv-3/package.conf.d -j1 -threaded
[1 of 1] Compiling Main             ( Setup.hs, /tmp/nix-build-haskell-xkbcommon-0.0.1.drv-3/Main.o )
Linking Setup ...
configuring
configureFlags: --verbose --prefix=/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --with-gcc=gcc --package-db=/tmp/nix-build-haskell-xkbcommon-0.0.1.drv-3/package.conf.d --ghc-option=-optl=-Wl,-rpath=/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1/lib/ghc-7.10.1/xkbcommon-0.0.1 --enable-split-objs --disable-library-profiling --enable-shared --enable-library-vanilla --enable-executable-dynamic --enable-tests
Configuring xkbcommon-0.0.1...
Dependency base <5: using base-<IP_ADDRESS>
Dependency bytestring -any: using bytestring-<IP_ADDRESS>
Dependency cpphs -any: using cpphs-1.19
Dependency data-flags -any: using data-flags-<IP_ADDRESS>
Dependency filepath -any: using filepath-<IP_ADDRESS>
Dependency process -any: using process-<IP_ADDRESS>
Dependency storable-record -any: using storable-record-0.0.3
Dependency template-haskell -any: using template-haskell-<IP_ADDRESS>
Dependency text -any: using text-<IP_ADDRESS>
Dependency transformers -any: using transformers-<IP_ADDRESS>
Dependency unix -any: using unix-<IP_ADDRESS>
Dependency xkbcommon -any: using xkbcommon-0.0.1
Using Cabal-<IP_ADDRESS> compiled by ghc-7.10
Using compiler: ghc-7.10.1
Using install prefix:
/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1
Binaries installed in:
/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1/bin
Libraries installed in:
/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1/lib/ghc-7.10.1/xkbcommon-0.0.1
Private binaries installed in:
/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1/libexec
Data files installed in:
/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1/share/x86_64-linux-ghc-7.10.1/xkbcommon-0.0.1
Documentation installed in:
/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1/share/doc/x86_64-linux-ghc-7.10.1/xkbcommon-0.0.1
Configuration files installed in:
/nix/store/plhwmf92c9ydydl8jmrfd9yghrqpjrvg-haskell-xkbcommon-0.0.1/etc
No alex found
Using ar found on system at:
/nix/store/yxg5zsjxp1l16xk7r23rayyc18fkxynk-binutils-2.23.1/bin/ar
No c2hs found
Using cpphs version 1.19 found on system at:
/nix/store/8mkh0b8dfzvy3zy0qwdb5wfg48l8hang-haskell-cpphs-1.19/bin/cpphs
Using gcc version 4.8.4 given by user at:
/nix/store/ylj1q31a7x3pvcraxk60dyv9y4wmwcrc-gcc-wrapper-4.8.4/bin/gcc
Using ghc version 7.10.1 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/ghc
Using ghc-pkg version 7.10.1 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/ghc-pkg
No ghcjs found
No ghcjs-pkg found
No greencard found
Using haddock version 2.16.0 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/haddock
No happy found
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.67 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/hpc
Using hsc2hs version 0.67 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/hsc2hs
Using hscolour version 1.22 found on system at:
/nix/store/g6mfdhbmwm0499n88bnzd32y96gmnfn9-hscolour-1.23/bin/HsColour
No jhc found
Using ld found on system at:
/nix/store/ylj1q31a7x3pvcraxk60dyv9y4wmwcrc-gcc-wrapper-4.8.4/bin/ld
No lhc found
No lhc-pkg found
No pkg-config found
Using strip version 2.23 found on system at:
/nix/store/yxg5zsjxp1l16xk7r23rayyc18fkxynk-binutils-2.23.1/bin/strip
Using tar found on system at:
/nix/store/blyc5sprbm85ph2fmksyhrqislp9j0im-gnutar-1.28/bin/tar
No uhc found
Setup: Missing dependency on a foreign library:
* Missing C library: xkbcommon
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
builder for ‘/nix/store/nwkw3riiqhdxddw6blwkzsssa1rc00p3-haskell-xkbcommon-0.0.1.drv’ failed with exit code 1
error: build of ‘/nix/store/nwkw3riiqhdxddw6blwkzsssa1rc00p3-haskell-xkbcommon-0.0.1.drv’ failed

When i replace all instances of xkbcommon (those that are not in quotes) with libxkbcommon between lines 134353 and 134370 and remove the xkbcommon = null in the braces, the build goes on longer before hitting an error. This time the erorr does not concern the compilation phase but the testing phase. If I replace xkbcommon = null from the braces with xkbcommons = libxkbcommon, I get the same testing error as when I replaced each instance of xkbcommon with libxkbcommon.
codehero@wheatley ~ % nix-env -f ./nixpkgs -iA haskellPackages.xkbcommon                                                                                :(
installing ‘haskell-xkbcommon-0.0.1’
these derivations will be built:
  /nix/store/0fl2f9srlhsikzp853wa5a2wf0xm3kbm-haskell-xkbcommon-0.0.1.drv
building path(s) ‘/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1’
setupCompilerEnvironmentPhase
Build with /nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1.
unpacking sources
unpacking source archive /nix/store/8r94zcd96d4wpvpwcja4kglp2j68kfss-xkbcommon-0.0.1.tar.gz
source root is xkbcommon-0.0.1
patching sources
compileBuildDriverPhase
setupCompileFlags: -package-db=/tmp/nix-build-haskell-xkbcommon-0.0.1.drv-3/package.conf.d -j1 -threaded
[1 of 1] Compiling Main             ( Setup.hs, /tmp/nix-build-haskell-xkbcommon-0.0.1.drv-3/Main.o )
Linking Setup ...
configuring
configureFlags: --verbose --prefix=/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --with-gcc=gcc --package-db=/tmp/nix-build-haskell-xkbcommon-0.0.1.drv-3/package.conf.d --ghc-option=-optl=-Wl,-rpath=/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1/lib/ghc-7.10.1/xkbcommon-0.0.1 --enable-split-objs --disable-library-profiling --enable-shared --enable-library-vanilla --enable-executable-dynamic --enable-tests --extra-include-dirs=/nix/store/jarcq2wf36619vs3lr9c9ap50v9icmgz-libxkbcommon-0.4.3/include --extra-lib-dirs=/nix/store/jarcq2wf36619vs3lr9c9ap50v9icmgz-libxkbcommon-0.4.3/lib
Configuring xkbcommon-0.0.1...
Dependency base <5: using base-<IP_ADDRESS>
Dependency bytestring -any: using bytestring-<IP_ADDRESS>
Dependency cpphs -any: using cpphs-1.19
Dependency data-flags -any: using data-flags-<IP_ADDRESS>
Dependency filepath -any: using filepath-<IP_ADDRESS>
Dependency process -any: using process-<IP_ADDRESS>
Dependency storable-record -any: using storable-record-0.0.3
Dependency template-haskell -any: using template-haskell-<IP_ADDRESS>
Dependency text -any: using text-<IP_ADDRESS>
Dependency transformers -any: using transformers-<IP_ADDRESS>
Dependency unix -any: using unix-<IP_ADDRESS>
Dependency xkbcommon -any: using xkbcommon-0.0.1
Using Cabal-<IP_ADDRESS> compiled by ghc-7.10
Using compiler: ghc-7.10.1
Using install prefix:
/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1
Binaries installed in:
/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1/bin
Libraries installed in:
/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1/lib/ghc-7.10.1/xkbcommon-0.0.1
Private binaries installed in:
/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1/libexec
Data files installed in:
/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1/share/x86_64-linux-ghc-7.10.1/xkbcommon-0.0.1
Documentation installed in:
/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1/share/doc/x86_64-linux-ghc-7.10.1/xkbcommon-0.0.1
Configuration files installed in:
/nix/store/f8iry9pwibdlmczrxfmank94c6rx4njv-haskell-xkbcommon-0.0.1/etc
No alex found
Using ar found on system at:
/nix/store/yxg5zsjxp1l16xk7r23rayyc18fkxynk-binutils-2.23.1/bin/ar
No c2hs found
Using cpphs version 1.19 found on system at:
/nix/store/8mkh0b8dfzvy3zy0qwdb5wfg48l8hang-haskell-cpphs-1.19/bin/cpphs
Using gcc version 4.8.4 given by user at:
/nix/store/ylj1q31a7x3pvcraxk60dyv9y4wmwcrc-gcc-wrapper-4.8.4/bin/gcc
Using ghc version 7.10.1 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/ghc
Using ghc-pkg version 7.10.1 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/ghc-pkg
No ghcjs found
No ghcjs-pkg found
No greencard found
Using haddock version 2.16.0 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/haddock
No happy found
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.67 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/hpc
Using hsc2hs version 0.67 found on system at:
/nix/store/bc84hdk730zcdm1c9s5yf2ahpvm51lzp-ghc-7.10.1/bin/hsc2hs
Using hscolour version 1.22 found on system at:
/nix/store/g6mfdhbmwm0499n88bnzd32y96gmnfn9-hscolour-1.23/bin/HsColour
No jhc found
Using ld found on system at:
/nix/store/ylj1q31a7x3pvcraxk60dyv9y4wmwcrc-gcc-wrapper-4.8.4/bin/ld
No lhc found
No lhc-pkg found
No pkg-config found
Using strip version 2.23 found on system at:
/nix/store/yxg5zsjxp1l16xk7r23rayyc18fkxynk-binutils-2.23.1/bin/strip
Using tar found on system at:
/nix/store/blyc5sprbm85ph2fmksyhrqislp9j0im-gnutar-1.28/bin/tar
No uhc found
building
Building xkbcommon-0.0.1...
Preprocessing library xkbcommon-0.0.1...
[ 1 of 12] Compiling Text.XkbCommon.InternalTypes ( dist/build/Text/XkbCommon/InternalTypes.hs, dist/build/Text/XkbCommon/InternalTypes.o )
[ 2 of 12] Compiling Text.XkbCommon.ParseDefines ( Text/XkbCommon/ParseDefines.hs, dist/build/Text/XkbCommon/ParseDefines.o )
[ 3 of 12] Compiling Text.XkbCommon.KeycodeList ( Text/XkbCommon/KeycodeList.hs, dist/build/Text/XkbCommon/KeycodeList.o )
[ 4 of 12] Compiling Text.XkbCommon.ModList ( Text/XkbCommon/ModList.hs, dist/build/Text/XkbCommon/ModList.o )
[ 5 of 12] Compiling Text.XkbCommon.KeysymList ( Text/XkbCommon/KeysymList.hs, dist/build/Text/XkbCommon/KeysymList.o )
[ 6 of 12] Compiling Text.XkbCommon.Constants ( Text/XkbCommon/Constants.hs, dist/build/Text/XkbCommon/Constants.o )
[ 7 of 12] Compiling Text.XkbCommon.Keysym ( dist/build/Text/XkbCommon/Keysym.hs, dist/build/Text/XkbCommon/Keysym.o )
[ 8 of 12] Compiling Text.XkbCommon.KeyboardState ( dist/build/Text/XkbCommon/KeyboardState.hs, dist/build/Text/XkbCommon/KeyboardState.o )
[ 9 of 12] Compiling Text.XkbCommon.Keymap ( dist/build/Text/XkbCommon/Keymap.hs, dist/build/Text/XkbCommon/Keymap.o )
[10 of 12] Compiling Text.XkbCommon.Context ( dist/build/Text/XkbCommon/Context.hs, dist/build/Text/XkbCommon/Context.o )
[11 of 12] Compiling Text.XkbCommon.Types ( Text/XkbCommon/Types.hs, dist/build/Text/XkbCommon/Types.o )
[12 of 12] Compiling Text.XkbCommon   ( Text/XkbCommon.hs, dist/build/Text/XkbCommon.o )
In-place registering xkbcommon-0.0.1...
Preprocessing test suite 'context' for xkbcommon-0.0.1...
[1 of 2] Compiling Common           ( tests/Common.hs, dist/build/context/context-tmp/Common.dyn_o )
[2 of 2] Compiling Main             ( tests/context.hs, dist/build/context/context-tmp/Main.dyn_o )

tests/context.hs:9:1: Warning: Tab character

tests/context.hs:11:1: Warning: Tab character

tests/context.hs:12:1: Warning: Tab character

tests/context.hs:13:1: Warning: Tab character

tests/context.hs:14:1: Warning: Tab character

tests/context.hs:15:1: Warning: Tab character

tests/context.hs:16:1: Warning: Tab character
Linking dist/build/context/context ...
Preprocessing test suite 'filecomp' for xkbcommon-0.0.1...
[1 of 2] Compiling Common           ( tests/Common.hs, dist/build/filecomp/filecomp-tmp/Common.dyn_o )
[2 of 2] Compiling Main             ( tests/filecomp.hs, dist/build/filecomp/filecomp-tmp/Main.dyn_o )

tests/filecomp.hs:21:1: Warning: Tab character

tests/filecomp.hs:22:1: Warning: Tab character

tests/filecomp.hs:23:1: Warning: Tab character

tests/filecomp.hs:25:1: Warning: Tab character

tests/filecomp.hs:26:1: Warning: Tab character
Linking dist/build/filecomp/filecomp ...
Preprocessing test suite 'keyseq' for xkbcommon-0.0.1...
[1 of 2] Compiling Common           ( tests/Common.hs, dist/build/keyseq/keyseq-tmp/Common.dyn_o )
[2 of 2] Compiling Main             ( tests/keyseq.hs, dist/build/keyseq/keyseq-tmp/Main.dyn_o )
Linking dist/build/keyseq/keyseq ...
Preprocessing test suite 'keysym' for xkbcommon-0.0.1...
[1 of 2] Compiling Common           ( tests/Common.hs, dist/build/keysym/keysym-tmp/Common.dyn_o )
[2 of 2] Compiling Main             ( tests/keysym.hs, dist/build/keysym/keysym-tmp/Main.dyn_o )
Linking dist/build/keysym/keysym ...
Preprocessing test suite 'rulescomp' for xkbcommon-0.0.1...
[1 of 2] Compiling Common           ( tests/Common.hs, dist/build/rulescomp/rulescomp-tmp/Common.dyn_o )
[2 of 2] Compiling Main             ( tests/rulescomp.hs, dist/build/rulescomp/rulescomp-tmp/Main.dyn_o )
Linking dist/build/rulescomp/rulescomp ...
Preprocessing test suite 'state' for xkbcommon-0.0.1...
[1 of 2] Compiling Common           ( tests/Common.hs, dist/build/state/state-tmp/Common.dyn_o )
[2 of 2] Compiling Main             ( tests/state.hs, dist/build/state/state-tmp/Main.dyn_o )
Linking dist/build/state/state ...
Preprocessing test suite 'stringcomp' for xkbcommon-0.0.1...
[1 of 2] Compiling Common           ( tests/Common.hs, dist/build/stringcomp/stringcomp-tmp/Common.dyn_o )
[2 of 2] Compiling Main             ( tests/stringcomp.hs, dist/build/stringcomp/stringcomp-tmp/Main.dyn_o )

tests/stringcomp.hs:15:1: Warning: Tab character

tests/stringcomp.hs:16:1: Warning: Tab character
Linking dist/build/stringcomp/stringcomp ...
running tests
Running 7 test suites...
Test suite context: RUNNING...
context: user error (did not find data/ dir)
Test suite context: FAIL
Test suite logged to: dist/test/xkbcommon-0.0.1-context.log
Test suite filecomp: RUNNING...
filecomp: data/keymaps/basic.xkb: openFile: does not exist (No such file or directory)
Test suite filecomp: FAIL
Test suite logged to: dist/test/xkbcommon-0.0.1-filecomp.log
Test suite keyseq: RUNNING...
xkbcommon: ERROR: Couldn't find file "rules/evdev" in include paths
xkbcommon: ERROR: There are no include paths to search
xkbcommon: ERROR: 1 include paths could not be added:
xkbcommon: ERROR: 	data/
xkbcommon: ERROR: Couldn't look up rules 'evdev', model 'evdev', layout 'us,il,ru,de', variant ',,phonetic,neo', options 'grp:alt_shift_toggle,grp:menu_toggle'
keyseq: Maybe.fromJust: Nothing
Test suite keyseq: FAIL
Test suite logged to: dist/test/xkbcommon-0.0.1-keyseq.log
Test suite keysym: RUNNING...
Test suite keysym: PASS
Test suite logged to: dist/test/xkbcommon-0.0.1-keysym.log
Test suite rulescomp: RUNNING...
xkbcommon: ERROR: Couldn't find file "rules/evdev" in include paths
xkbcommon: ERROR: There are no include paths to search
xkbcommon: ERROR: 1 include paths could not be added:
xkbcommon: ERROR: 	data/
xkbcommon: ERROR: Couldn't look up rules 'evdev', model 'pc105', layout 'us,il,ru,ca', variant ',,,multix', options 'grp:alts_toggle,ctrl:nocaps,compose:rwin'
rulescomp: Maybe.fromJust: Nothing
Test suite rulescomp: FAIL
Test suite logged to: dist/test/xkbcommon-0.0.1-rulescomp.log
Test suite state: RUNNING...
xkbcommon: ERROR: Couldn't find file "rules/evdev" in include paths
xkbcommon: ERROR: There are no include paths to search
xkbcommon: ERROR: 1 include paths could not be added:
xkbcommon: ERROR: 	data/
xkbcommon: ERROR: Couldn't look up rules 'evdev', model 'pc104', layout 'us,ru', variant '(null)', options 'grp:menu_toggle'
state: Maybe.fromJust: Nothing
Test suite state: FAIL
Test suite logged to: dist/test/xkbcommon-0.0.1-state.log
Test suite stringcomp: RUNNING...
stringcomp: data/keymaps/stringcomp.data: openFile: does not exist (No such file or directory)
Test suite stringcomp: FAIL
Test suite logged to: dist/test/xkbcommon-0.0.1-stringcomp.log
1 of 7 test suites (1 of 7 test cases) passed.
builder for ‘/nix/store/0fl2f9srlhsikzp853wa5a2wf0xm3kbm-haskell-xkbcommon-0.0.1.drv’ failed with exit code 1
error: build of ‘/nix/store/0fl2f9srlhsikzp853wa5a2wf0xm3kbm-haskell-xkbcommon-0.0.1.drv’ failed

This works fine in master after 84235ff763ee77058032319f791fb1d49c9695d8:
$ nix-build '<nixpkgs>' -A haskellPackages.xkbcommon
/nix/store/aw3wh8p0b694dz9zfz2j031iqbhqczxc-haskell-xkbcommon-0.0.1

Okay. Thank you


extract_area: bad extract area when toBuffer

sharp version 0.32.6
I've upgraded sharp from version 0.25.0 to 0.32.6
but the same code can not run success in new version, like blow:
const image = sharp(imageSource); // imageSource = 'c:/test.jpg'
const layout = {
    back: {x: 3072, y: 1024, width: 1024, height: 1024},
    bottom: {x: 1024, y: 2048, width: 1024, height: 1024},
    front: {x: 1024, y: 1024, width: 1024, height: 1024},
    left: {x: 0, y: 1024, width: 1024, height: 1024},
    right: {x: 2048, y: 1024, width: 1024, height: 1024},
    top: {x: 1024, y: 0, width: 1024, height: 1024},
}
await Promise.all(Object.keys(layout).map(async (faceName) => {
    const faceBlit = layout[faceName];
    const faceSharp = await image.extract({
        left: faceBlit.x,
        top: faceBlit.y,
        width: faceBlit.width,
        height: faceBlit.height,
    });
    // thrown error when get buffer after extract next image
    const faceImageData = await faceSharp.toFormat(sharp.format.png).toBuffer();
    mipmapData[faceName] = faceImageData;
}));

i fix it by change the code
-      const image = sharp(imageSource); // imageSource = 'c:/test.jpg'
        await Promise.all(faceNames.map(async (faceName) => {
            const faceBlit = layout[faceName];
+          const image = sharp(imageSource)
            const faceSharp = await image.extract({
                left: faceBlit.x,
                top: faceBlit.y,
                width: faceBlit.width,
                height: faceBlit.height,
            });
            const faceImageData = await faceSharp.toFormat(sharp.format.png).toBuffer();
            mipmapData[faceName] = faceImageData;
        }));

the size of  'test.jpg' is  4096 * 3072

You are correct to create a new sharp instance within the loop, otherwise you're modifying the outer instance with the potential for race conditions.
As per the documentation, extract() returns the current sharp instance, and does not return a Promise so there's no need to await it.
https://sharp.pixelplumbing.com/api-resize#extract

I hope this information helped. Please feel free to re-open with more details if further assistance is required.


Community Global Config System

Community System.
community.join('id'); and community.leave();
So that users dont need to give the Com. Variable at every little Step that they are doing.

Felix you got me wrong here. I didnt thought of actually joining and
leaving communites. It's like in Amino that you can only use one community
at a time. Like community.use('xtesting') and then every other function
is then called in xtesting (so make the community variable Irrelevant.). I
didnt think about really joining or leaving communites, but it could be a
function soonTM.
On Sat, 5 Jan 2019, 08:20 Felix Fong<EMAIL_ADDRESS>wrote:

What if the users want to perform a community leave operation but with
another community?
How about we let the user assign a community ID as the first function
param, and if the ID is given then overwrite the default community ID.
And as of the default community ID, the ID will come from the community.
join.
And if both default ID and user-specified ID(function params) return null
or undefined, we just simply throw an exception?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/AminoJS/Amino.JS/issues/51#issuecomment-451634423,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqOM8tsr2pheSCwEN8HbqaPlxrP0nB3gks5vAFI_gaJpZM4Zpgg-
.

It would be cool. It's not really hard to implement it, since it already have a Global SID config.

One question
The community.join('id'); set all the modules to work in the given community(if the person isn't on the community, does the person joins it?), but what does community.leave(); should do? Quit the community?

let us just say a person want's to check into every community, list all chats, send a message and then exit the process.
the way he would do that would be like this:
const amino = require('amino.js');

//login logic
let coms = amino.getComs();
coms.forEach(com => {
let chats = amino.getJoinedChats(communityID);
chats.forEach(chat => {
amino.sendChat(communityID, [other params]);
})})
process.exit(0);

The way i find it more successful for everyone is the community system:
An Example again:
const amino = require('amino.js');

//login logic
let coms = amino.getComs();
coms.forEach(com => {
community.join(com.id);
let chats = amino.getJoinedChats();
chats.forEach(chat => {
amino.sendChat([other params]);
})
community.leave();
})
process.exit(0);

The Logic behind actually Joining or Leaving Communities would be a totally different one.

Aaaaah got it! Understood the logic
I’ll be working on it when I get time!
�
From: Robin Möller<EMAIL_ADDRESS>Sent: Sunday, March 24, 2019 5:06 AM
To: AminoJS/Amino.JS
Cc: Akatsuki Levi; Assign
Subject: Re: [AminoJS/Amino.JS] Community Global Config System (#51)
�
let us just say a person want's to check into every community, list all chats, send a message and then exit the process.
the way he would do that would be like this:
amino = require('amino.js');


Fix compatibility with React 16.9

Fix for #465, #426 and #413 by updating react-side-effect to v2.0.0 since it's now using UNSAFE_componentWillMount instead of componentWillMount.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@rifaidev you need to change react and react-dom dependencies in package.json to ^16.3 or they don't match the requirements of react-side-effect. This'll be more than a patch update then too, probably a major.

@wheeler makes sense, however looks like the maintainers have abandoned the library! 🤷♂

It would be nice to merge this PR please @tmbtech . It is really confusing to hack yarn.lock to make a warning disappear.

@cwelch5 Could you look at this?

#473 is now merged and Travis CI is building again. Maybe add an empty commit to trigger CI build again for this PR (or rebuild manually if possible)?

@rifaidev #473 is now merged and Travis CI is building again. Maybe add an empty commit to trigger CI build again for this PR (or trigger manually if possible)?

I think maintainers can manually trigger it.

Please merge this PR it become a need of hour to get our console free from such warning messages.

I think maintainers can manually trigger it.

@rifaidev Would you mind try pushing an empty commit? Maybe the maintainers won't pick this up until all checks are green and this could speed up merging.

Would you mind try pushing an empty commit? Maybe the maintainers won't pick this up until all checks are green and this could speed up merging.

I just did, and still failing.
Actually I highly recommend switching to https://github.com/staylor/react-helmet-async instead.

This is such a popular repository, and I am amazed with the fact that an issue since last year still have no resolution even after a potential fix given in current PR. Seems authors are no more interested in this community work. I am disappointed to drop such a fantastic pacakge from my project I will add a plan to drop it or will use some alternative of this 😞


Adding Colossyan AI API

I want to add information and references of the Colossyan API under video genration API as a part of GSSoC.
@ashitaprasad Please assign the issue to me.

This API has been already added.


Using Multiple Loaders

It might be a useful feature to have the possibility to combine different loader.
For example I would like to use both the partial-loader in conjunction to a url-loader

Hello, @endamaco. angular-translate provides loaders for common use cases. But, obviously, it is impossible to cover all possible variations.
To solve your task you can create a custom loader. It may contain any additional logic you need.
You can find more information about loaders here:
http://angular-translate.github.io/docs/#/guide/13_custom-loaders
http://angular-translate.github.io/docs/#/guide/12_asynchronous-loading
Also, you can take any existing loader as an example.

@endamaco : Just like @DWand  already said: If you need more features within a loader, you can easily build your own. You can even re-use existing ones, since they are all documented and have a similar interface.


refactor!: New approach to lazy initialization

This fixes #295 while still keeping the advantages of #179 for clean integrations on Windows and macOS.
The placeholder tree, if necessary, is now the responsibility of the platform adapter; that makes the adapter somewhat more complicated, but it's better to have that kind of complexity in AccessKit than in the caller. The AT-SPI implementation doesn't need a placeholder tree, and neither will Newton (the new Wayland-native accessibility stack I'm prototyping). I don't like how accesskit_atspi_common has to expose some of its implementation details to enable robust state transitions with minimal overhead in accesskit_unix, but I don't know a better way, and accesskit_atspi_common is basically an internal crate anyway.
The update to egui is in this branch. The changes are mostly in egui-winit and eframe.
@DataTriny Please repeat the same testing you did when you implemented lazy initialization for AT-SPI.
I don't yet know how to get all the benefits of #179, particularly synchronous tree initialization without requiring the application/toolkit state to be wrapped in a reference-counted mutex, in the Unix adapter. The problem is that on Windows and macOS, tree initialization is always done in response to a platform event which, in a clean integration, is initially handled by the toolkit, so it can pass us a short-lived mutable reference to the activation handler. But in the Unix adapter, we listen to accessibility status changes on our own thread. Maybe accesskit_unix could have an alternate API where the application listens to that property itself and calls a function when it changes, passing us a short-lived reference to the activation handler.

The behavior of lazy initialization on Unix seem to still work as expected. Reviewing the code now.


kubernetes: Add CILIUM_MONITOR_AGGREGATION_LEVEL to crio-o DaemonSet

Fixes: 25edcda4931d ("examples: Add MONITOR_AGGREGATION_LEVEL option")
Signed-off-by: Thomas Graf<EMAIL_ADDRESS>This is a new feature in 1.2 and thus does not need any backports

test-me-please

Shouldn't the scripts that we have to make the example YAMLs have caught this? Did this have to be added manually?

We have two template files right now, the default one and the cri-o one. Not ideal.

We have two template files right now, the default one and the cri-o one. Not ideal.

Oof.


Add notification if no todo items are present

A message should display if no todo items are found.

Done in #12


fix(scripts): metadata for taginfo

The taginfo.json lacks contact_name and contact_email according to https://wiki.openstreetmap.org/wiki/Taginfo/Projects
This blocks the update to the new URL (referring to the develop branch): https://github.com/taginfo/taginfo-projects/pull/95

@simon04 Sounds fine, but I'll be the point of contact for this. The email is [q at quincylvania.com].

@quincylvania, alright - done! :-)

@simon04 Great, thanks! I might do a patch release to update the various references to the master branch in iD, including this. Otherwise this will take a few months to get out.


Media type icon on gallery card image

Is your feature request related to a problem?
I'm always frustrated when I don't know what media type I'll be looking at
Describe the solution you would like
I would like to see an icon on gallery image (like we show event icon or price on card) for what media type nft is
Describe alternatives you have considered
I would put these icons in the top left corner

VIDEO
IMAGE
3D
VR
MUSIC

Screeenshots
WIP: Paste your vision

I guess let's go, maybe we can highlight this in NFT item detail as well, what's mediatype it's
Also I would make it as option in settings to turn off to keep minimal UI :)

no need, we have generative art - lets focus on that.


New error

Hello!
so after last time, today (with pretty much larger knowledge at scripting i think)
i wanted to try your script again and found out what didn't work for me last time, basically the $1 as input for cal command was invalid, its outputting
"year `' not in range 1..9999"
so i just removed it and calendar at least show itself, but not exactly how i wanted it to
https://imgur.com/a/CWAUXry
Can you give me so tips ? Should i change dunst config or just try my hand with sed?
Thank you very much
Edit: just saw your reply to my last post and now i feel stupid
Edit2: ok so i changed dunst config a little bit and have something like this:
https://imgur.com/a/CqnrbIR
it seems that highlighting is making this spacing in the center of calendar, i will try to remove it.
EDIT3:
So after some odd things i found this (ncal -b -h ) to be working perfectly, i hope this will help someone out.

So after some odd things i found this (ncal -b -h ) to be working perfectly, i hope this will help someone out.
glad you could find a fix, i'll leave this issue open for posterity!