text:
Linux complie problem.

root@ubuntu:~/libraries# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04.3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
root@ubuntu:~/libraries# ./build.sh
==== clean linux libmacro done.
==== clean linux libatomic done.
==== clean linux libtime done.
==== clean linux liblog done.
==== clean linux libgevent done.
==== clean linux libworkq done.
==== clean linux libdict done.
==== clean linux libsort done.
==== clean linux librbtree done.
==== clean linux libringbuffer done.
==== clean linux liblock done.
==== clean linux libthread done.
==== clean linux libconfig done.
==== clean linux libosal done.
==== clean linux libvector done.
==== clean linux libdebug done.
==== clean linux libfile done.
==== clean linux libskt done.
==== clean linux libstun done.
==== clean linux libptcp done.
==== clean linux librpc done.
==== clean linux libp2p done.
==== clean linux libipc done.
==== build linux libmacro done.
==== build linux libatomic done.
==== build linux libtime done.
==== build linux liblog done.
==== build linux libgevent done.
==== build linux libworkq done.
==== build linux libdict done.
==== build linux libsort done.
==== build linux librbtree done.
==== build linux libringbuffer done.
test_liblock.c: In function ‘print_mutex_lock’:
test_liblock.c:45:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (uint64_t i = 0; i < n; ++ i) {
^
test_liblock.c:45:5: note: use option -std=c99 or -std=gnu99 to compile your code
test_liblock.c: In function ‘print_spin_lock’:
test_liblock.c:72:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (uint64_t i = 0; i < n; ++ i) {
^
make: *** [test_liblock.o] Error 1
==== build linux liblock failed
In file included from libthread.c:13:0:
libthread.h:14:21: fatal error: liblock.h: No such file or directory
#include <liblock.h>
^
compilation terminated.
make: *** [libthread.o] Error 1
==== build linux libthread failed
Package lua5.2 was not found in the pkg-config search path.
Perhaps you should add the directory containing lua5.2.pc' to the PKG_CONFIG_PATH environment variable No package 'lua5.2' found Package lua5.2 was not found in the pkg-config search path. Perhaps you should add the directory containing lua5.2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.2' found
Package lua5.2 was not found in the pkg-config search path.
Perhaps you should add the directory containing lua5.2.pc' to the PKG_CONFIG_PATH environment variable No package 'lua5.2' found Package lua5.2 was not found in the pkg-config search path. Perhaps you should add the directory containing lua5.2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.2' found
Package lua5.2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.2' found
json/json_config.c:8:21: fatal error: jansson.h: No such file or directory
#include <jansson.h>
^
compilation terminated.
make: *** [json/json_config.o] Error 1
==== build linux libconfig failed
==== build linux libosal done.
==== build linux libvector done.
libdebug.c: In function ‘debug_backtrace_init’:
libdebug.c:121:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (uint32_t i = 0; i < (sizeof(signum) / sizeof(uint32_t)); ++i) {
^
libdebug.c:121:5: note: use option -std=c99 or -std=gnu99 to compile your code
make: *** [libdebug.o] Error 1
==== build linux libdebug failed
==== build linux libfile done.
test_libskt.c:17:23: fatal error: libthread.h: No such file or directory
#include <libthread.h>
^
compilation terminated.
make: *** [test_libskt.o] Error 1
==== build linux libskt failed
==== build linux libstun done.
==== build linux libptcp done.
librpc.c:15:20: fatal error: libskt.h: No such file or directory
#include <libskt.h>
^
compilation terminated.
make: *** [librpc.o] Error 1
==== build linux librpc failed
libp2p.c:21:20: fatal error: libskt.h: No such file or directory
#include <libskt.h>
^
compilation terminated.
make: *** [libp2p.o] Error 1
==== build linux libp2p failed
netlink.c:20:23: fatal error: libthread.h: No such file or directory
#include <libthread.h>
^
compilation terminated.
make: *** [netlink.o] Error 1
==== build linux libipc failed

The library has depending on glibc libraries,  and does this is your original intention?
root@ubuntu:~/libraries# ./build.sh
==== clean linux libmacro done.
==== clean linux libatomic done.
==== clean linux libtime done.
==== clean linux liblog done.
==== clean linux libgevent done.
==== clean linux libworkq done.
==== clean linux libdict done.
==== clean linux libsort done.
==== clean linux librbtree done.
==== clean linux libringbuffer done.
==== clean linux liblock done.
==== clean linux libthread done.
==== clean linux libconfig done.
==== clean linux libosal done.
==== clean linux libvector done.
==== clean linux libdebug done.
==== clean linux libfile done.
==== clean linux libskt done.
==== clean linux libstun done.
==== clean linux libptcp done.
==== clean linux librpc done.
==== clean linux libp2p done.
==== clean linux libipc done.
==== build linux libmacro done.
==== build linux libatomic done.
==== build linux libtime done.
==== build linux liblog done.
==== build linux libgevent done.
==== build linux libworkq done.
==== build linux libdict done.
==== build linux libsort done.
==== build linux librbtree done.
==== build linux libringbuffer done.
liblock.c: In function ‘mutex_cond_wait’:
liblock.c:236:9: error: implicit declaration of function ‘clock_gettime’ [-Werror=implicit-function-declaration]
clock_gettime(CLOCK_REALTIME, &ts);
^
liblock.c:236:23: error: ‘CLOCK_REALTIME’ undeclared (first use in this function)
clock_gettime(CLOCK_REALTIME, &ts);
^
liblock.c:236:23: note: each undeclared identifier is reported only once for each function it appears in
liblock.c: In function ‘rwlock_init’:
liblock.c:287:5: error: unknown type name ‘pthread_rwlock_t’
pthread_rwlock_t *lock = (pthread_rwlock_t *)calloc(1,
^
liblock.c:287:31: error: ‘pthread_rwlock_t’ undeclared (first use in this function)
pthread_rwlock_t *lock = (pthread_rwlock_t *)calloc(1,
^
liblock.c:287:49: error: expected expression before ‘)’ token
pthread_rwlock_t *lock = (pthread_rwlock_t *)calloc(1,
^
liblock.c:293:5: error: implicit declaration of function ‘pthread_rwlock_init’ [-Werror=implicit-function-declaration]
int ret = pthread_rwlock_init(lock, NULL);
^
liblock.c: In function ‘rwlock_deinit’:
liblock.c:325:5: error: unknown type name ‘pthread_rwlock_t’
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:325:31: error: ‘pthread_rwlock_t’ undeclared (first use in this function)
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:325:49: error: expected expression before ‘)’ token
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:326:5: error: implicit declaration of function ‘pthread_rwlock_destroy’ [-Werror=implicit-function-declaration]
if (0 != pthread_rwlock_destroy(lock)) {
^
liblock.c: In function ‘rwlock_rdlock’:
liblock.c:337:5: error: unknown type name ‘pthread_rwlock_t’
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:337:31: error: ‘pthread_rwlock_t’ undeclared (first use in this function)
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:337:49: error: expected expression before ‘)’ token
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:338:5: error: implicit declaration of function ‘pthread_rwlock_rdlock’ [-Werror=implicit-function-declaration]
int ret = pthread_rwlock_rdlock(lock);
^
liblock.c: In function ‘rwlock_tryrdlock’:
liblock.c:367:5: error: unknown type name ‘pthread_rwlock_t’
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:367:31: error: ‘pthread_rwlock_t’ undeclared (first use in this function)
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:367:49: error: expected expression before ‘)’ token
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:368:5: error: implicit declaration of function ‘pthread_rwlock_tryrdlock’ [-Werror=implicit-function-declaration]
int ret = pthread_rwlock_tryrdlock(lock);
^
liblock.c: In function ‘rwlock_wrlock’:
liblock.c:397:5: error: unknown type name ‘pthread_rwlock_t’
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:397:31: error: ‘pthread_rwlock_t’ undeclared (first use in this function)
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:397:49: error: expected expression before ‘)’ token
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:398:5: error: implicit declaration of function ‘pthread_rwlock_wrlock’ [-Werror=implicit-function-declaration]
int ret = pthread_rwlock_wrlock(lock);
^
liblock.c: In function ‘rwlock_trywrlock’:
liblock.c:418:5: error: unknown type name ‘pthread_rwlock_t’
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:418:31: error: ‘pthread_rwlock_t’ undeclared (first use in this function)
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:418:49: error: expected expression before ‘)’ token
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:419:5: error: implicit declaration of function ‘pthread_rwlock_trywrlock’ [-Werror=implicit-function-declaration]
int ret = pthread_rwlock_trywrlock(lock);
^
liblock.c: In function ‘rwlock_unlock’:
liblock.c:442:5: error: unknown type name ‘pthread_rwlock_t’
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:442:31: error: ‘pthread_rwlock_t’ undeclared (first use in this function)
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:442:49: error: expected expression before ‘)’ token
pthread_rwlock_t *lock = (pthread_rwlock_t *)ptr;
^
liblock.c:443:5: error: implicit declaration of function ‘pthread_rwlock_unlock’ [-Werror=implicit-function-declaration]
int ret = pthread_rwlock_unlock(lock);
^
liblock.c: In function ‘sem_lock_wait’:
liblock.c:506:23: error: ‘CLOCK_REALTIME’ undeclared (first use in this function)
clock_gettime(CLOCK_REALTIME, &ts);
^
liblock.c:509:9: error: implicit declaration of function ‘sem_timedwait’ [-Werror=implicit-function-declaration]
ret = sem_timedwait(lock, &ts);
^
cc1: all warnings being treated as errors
make: *** [liblock.o] Error 1
==== build linux liblock failed
In file included from libthread.c:13:0:
libthread.h:14:21: fatal error: liblock.h: No such file or directory
#include <liblock.h>
^
compilation terminated.
make: *** [libthread.o] Error 1
==== build linux libthread failed
Package lua5.2 was not found in the pkg-config search path.
Perhaps you should add the directory containing lua5.2.pc' to the PKG_CONFIG_PATH environment variable No package 'lua5.2' found Package lua5.2 was not found in the pkg-config search path. Perhaps you should add the directory containing lua5.2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.2' found
Package lua5.2 was not found in the pkg-config search path.
Perhaps you should add the directory containing lua5.2.pc' to the PKG_CONFIG_PATH environment variable No package 'lua5.2' found Package lua5.2 was not found in the pkg-config search path. Perhaps you should add the directory containing lua5.2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.2' found
Package lua5.2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.2' found
json/json_config.c:8:21: fatal error: jansson.h: No such file or directory
#include <jansson.h>
^
compilation terminated.
make: *** [json/json_config.o] Error 1
==== build linux libconfig failed
==== build linux libosal done.
==== build linux libvector done.
==== build linux libdebug done.
==== build linux libfile done.
In file included from libskt.c:27:0:
libskt.h:91:37: error: ‘struct tcp_info’ declared inside parameter list [-Werror]
int skt_get_tcp_info(int fd, struct tcp_info *ti);
^
libskt.h:91:37: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
libskt.c:169:37: error: ‘struct tcp_info’ declared inside parameter list [-Werror]
int skt_get_tcp_info(int fd, struct tcp_info *tcpi)
^
libskt.c:169:5: error: conflicting types for ‘skt_get_tcp_info’
int skt_get_tcp_info(int fd, struct tcp_info *tcpi)
^
In file included from libskt.c:27:0:
libskt.h:91:5: note: previous declaration of ‘skt_get_tcp_info’ was here
int skt_get_tcp_info(int fd, struct tcp_info *ti);
^
libskt.c: In function ‘skt_get_tcp_info’:
libskt.c:171:28: error: dereferencing pointer to incomplete type
socklen_t len = sizeof(*tcpi);
^
libskt.c:172:27: error: ‘SOL_TCP’ undeclared (first use in this function)
return getsockopt(fd, SOL_TCP, TCP_INFO, tcpi, &len);
^
libskt.c:172:27: note: each undeclared identifier is reported only once for each function it appears in
libskt.c: In function ‘skt_get_local_list’:
libskt.c:193:32: error: ‘IFF_UP’ undeclared (first use in this function)
if (!(ifa->ifa_flags & IFF_UP))
^
libskt.c:218:31: error: ‘IFF_LOOPBACK’ undeclared (first use in this function)
if ((ifa->ifa_flags & IFF_LOOPBACK) && !loopback)
^
libskt.c: In function ‘skt_getaddrinfo’:
libskt.c:302:21: error: storage size of ‘hints’ isn’t known
struct addrinfo hints, *ai_list, *rp;
^
libskt.c:305:30: error: invalid application of ‘sizeof’ to incomplete type ‘struct addrinfo’
memset(&hints, 0, sizeof(struct addrinfo));
^
libskt.c:309:22: error: ‘AI_CANONNAME’ undeclared (first use in this function)
hints.ai_flags = AI_CANONNAME;
^
libskt.c:311:5: error: implicit declaration of function ‘getaddrinfo’ [-Werror=implicit-function-declaration]
ret = getaddrinfo(domain, port, &hints, &ai_list);
^
libskt.c:313:9: error: implicit declaration of function ‘gai_strerror’ [-Werror=implicit-function-declaration]
loge("getaddrinfo: %s\n", gai_strerror(ret));
^
libskt.c:319:43: error: dereferencing pointer to incomplete type
for (rp = ai_list; rp != NULL; rp = rp->ai_next ) {
^
libskt.c:321:48: error: dereferencing pointer to incomplete type
an->addr.ip = ((struct sockaddr_in *)rp->ai_addr)->sin_addr.s_addr;
^
libskt.c:322:56: error: dereferencing pointer to incomplete type
an->addr.port = ntohs(((struct sockaddr_in *)rp->ai_addr)->sin_port);
^
libskt.c:336:5: error: implicit declaration of function ‘freeaddrinfo’ [-Werror=implicit-function-declaration]
freeaddrinfo(ai_list);
^
libskt.c:302:21: error: unused variable ‘hints’ [-Werror=unused-variable]
struct addrinfo hints, *ai_list, *rp;
^
libskt.c: In function ‘skt_gethostbyname’:
libskt.c:348:9: error: implicit declaration of function ‘herror’ [-Werror=implicit-function-declaration]
herror("gethostbyname failed!\n");
^
libskt.c: In function ‘skt_get_tcp_info’:
libskt.c:173:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
cc1: all warnings being treated as errors
make: *** [libskt.o] Error 1
==== build linux libskt failed
==== build linux libstun done.
==== build linux libptcp done.
librpc.c:15:20: fatal error: libskt.h: No such file or directory
#include <libskt.h>
^
compilation terminated.
make: *** [librpc.o] Error 1
==== build linux librpc failed
libp2p.c:21:20: fatal error: libskt.h: No such file or directory
#include <libskt.h>
^
compilation terminated.
make: *** [libp2p.o] Error 1
==== build linux libp2p failed
netlink.c:20:23: fatal error: libthread.h: No such file or directory
#include <libthread.h>
^
compilation terminated.
make: *** [netlink.o] Error 1
==== build linux libipc failed

for (uint64_t i = 0; i < n; ++ i) {
^
test_liblock.c:45:5: note: use option -std=c99 or -std=gnu99 to compile your code 目前这种写法在GCC编译器下是通不过的。。。

@zh794390558 Thanks for your issue report.
The only C99 mode issue has been fixed, and you should install libjasson-dev and liblua5.2-dev to compile the libconfig.
Some of the libraries are depended on glibc now, and the flexiblility will be improved when porting other platforms.
And my environment is:
$ uname -a
Linux laptop 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 16.04.1 LTS \n \l
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)

@core1011 非常感谢您的建议。
现在部分code在-std=c89 下确实编译不过，比如libmacro，里边包含了部分linux kernel 的头文件，考虑到kernel支持c99的情况，所以为保证一致性，就没有fix c89的编译问题，其他libxxx会尽量fix。

@gozfree liblock librpc libskt must use -std=gnu99 to compile, do you known the diffrence of the two options.

@zh794390558 Thanks for your fix, and I have fix the compile error instead of using '-std=gnu99'

repo: gozfree/libraries


text:
Upgrade node-sass to 2.0.1 and react-hot-loader to 1.1

Upon npm install node-sass was causing Error: Module did not self-register. errors on my system.
react-hot-loader generated a warning and wanted to be upgraded to 1.1 so I have updated things  to get it to work out of the box:
"node-sass": "^2.0.1",
"react-hot-loader": "^1.1.0",

Thanks!

source: gharchive/pull-request

authors: gpbl ryardley

repo: gpbl/isomorphic-react-template

license: MIT

license_type: permissive

license_source: github-api


text:
Changes to [UIApplication sharedApplication] canOpenURL in iOS 9

I jumped back into integrating this into an app today and noticed that canOpenURL no longer returns YES when an app is installed.
Apparently this is a change in iOS 9, where the scheme needs to be whitelisted in Info.plist.
Would it be possible be add this to the README?
Will submit PR if I've got some time :blush:
Source: http://awkwardhare.com/post/121196006730/quick-take-on-ios-9-url-scheme-changes
EDIT: Looks like canOpenURL should just be openURL to solve this issue.

Thanks for the heads-up @Alastair. I'll add this later this week.

Updated for iOS 9. Thanks again @alihen
https://github.com/gpolak/GPUberView/releases/tag/1.1.1

source: gharchive/issue

authors: alihen gpolak

repo: gpolak/GPUberView

license: mit

license_source: bigquery


text:
[ferry_generator] nullable element list field not generate nullable

environment
ferry_generator: ^0.6.1
flutter SDK: 3.0.1

schema.grapnql
type Query {
  test: Test
}

type Test {
  string_list: [String!]
  nullable_string_list: [String]
}

test.graphql
query GetTest {
  test {
    string_list
    nullable_string_list
  }
}

generated test.data.gql.g.dart
class _$GGetTestData_test extends GGetTestData_test {
  @override
  final String G__typename;
  @override
  final BuiltList<String>? string_list;
  @override
  final BuiltList<String>? nullable_string_list;

  factory _$GGetTestData_test(
          [void Function(GGetTestData_testBuilder)? updates]) =>
      (new GGetTestData_testBuilder()..update(updates))._build();

  _$GGetTestData_test._(
      {required this.G__typename, this.string_list, this.nullable_string_list})
      : super._() {
    BuiltValueNullFieldError.checkNotNull(
        G__typename, r'GGetTestData_test', 'G__typename');
  }

  @override
  GGetTestData_test rebuild(void Function(GGetTestData_testBuilder) updates) =>
      (toBuilder()..update(updates)).build();

  @override
  GGetTestData_testBuilder toBuilder() =>
      new GGetTestData_testBuilder()..replace(this);

  @override
  bool operator ==(Object other) {
    if (identical(other, this)) return true;
    return other is GGetTestData_test &&
        G__typename == other.G__typename &&
        string_list == other.string_list &&
        nullable_string_list == other.nullable_string_list;
  }

  @override
  int get hashCode {
    return $jf($jc($jc($jc(0, G__typename.hashCode), string_list.hashCode),
        nullable_string_list.hashCode));
  }

  @override
  String toString() {
    return (newBuiltValueToStringHelper(r'GGetTestData_test')
          ..add('G__typename', G__typename)
          ..add('string_list', string_list)
          ..add('nullable_string_list', nullable_string_list))
        .toString();
  }
}

@override
final BuiltList? string_list;
@override
final BuiltList? nullable_string_list;

not nullable element list.
both of them, non-null element list
i expedted under.
final BuiltList<String?>? nullable_string_list;

graphql doc ~ Combining List and Non-Null ~
please help me.
thanks.

Yes, this is a known bug and will be fixed soon.

fixed by https://github.com/gql-dart/ferry/pull/445

repo: gql-dart/ferry


text:
fix(ferry): Properly type-constrain ErrorTypedLink's forward response stream

In the ErrorTypedLink, the response stream recieved via the forward function is not type-constrained, thus cast it to be of the generic types TData and TVars.
This fixes an error that could sometimes occur, where the forward response stream was of a different type than TData and TVars, which mismatched with the StreamTransformer's inferred types, throwing an exception.
LinkException(type '_StreamHandlerTransformer<OperationResponse<dynamic, dynamic>, OperationResponse<dynamic, dynamic>>' is not a subtype of type 'StreamTransformer<OperationResponse<ConcreteTypeData, ConcreteTypeVars>, OperationResponse<dynamic, dynamic>>' of 'streamTransformer',
#0      Stream.transform (dart:async/stream.dart:1007:50)
#1      ErrorTypedLink.request (package:ferry/src/error_typed_link.dart:25:41)
#2      _TypedLinkChain.request.<anonymous closure>.<anonymous closure> (package:ferry_exec/src/typed_link.dart:131:46)
#3      _TypedLinkChain.request (package:ferry_exec/src/typed_link.dart:132:9)
#4      Client.request (package:ferry/ferry.dart:80:18)

This fixes an error that could sometimes occur,

Can you show a repro, how this error could occur?

authors: jimgerth knaeckeKami


text:
bind this to graaljs context, in callback

I am providing an event listener registration api like this
public class Events {
  public void on(String event, Consumer<Event> callback) {
    // ...
  }
}

JavaScript can use the host object
events.on('event_name', function (event) {
  this.something
}

Is there a way to set the this of the JavaScript Consumer<Event> when it is run?

Is there a way to set the this of the JavaScript Consumer when it is run?

What about:
events.on('event_name', (function (event) {
  this.something
}).bind(desiredThis) )

Does that work for you?

@iamstolis unfortunately not, because as far as I know the desiredThis must be defined and passed at context-creation time, however I would like to run the consumer with a new this dynamically.

If you need help with your problem then it would be really beneficial to provide a complete test-case. It is not very productive if we try to guess what you are trying to do.

as far as I know the desiredThis must be defined and passed at context-creation time, however I would like to run the consumer with a new this dynamically.

I see no relation to context creation time. If desiredThis is not know at the time of the registration of the callback then the only other case that I can imagine is setting this when the callback is triggered/invoked. It seems that you are invoking the callback from Java side, i.e., using Polyglot API. Unfortunately, the specification of this for an executed function is JavaScript specific feature and Polyglot API does not provide language-specific features. So, you have to work around that somehow. For example, you can use BiConsumer instead of Consumer and pass desiredThis as an additional argument of your callback.

Another possible solution may be the replacement of Consumer<Event> by org.graalvm.polyglot.Value (i.e. public void on(String event, Value callback)) and the execution of the callback using Function.prototype.call, i.e., callback.invokeMember("call", desiredThis, event).

@theonlygusti, was the problem solved by the suggestion of @iamstolis?

authors: fernando-valdez iamstolis theonlygusti

repo: graalvm/graaljs


text:
Refactor arithmetic merge

Merge PR

refactor_arithmetic_transactionlist
refactor_arithmetic_transactionlist_adminarea

This requires some more fixes in the admin code I believe

Broken Startbock:

Missing decay info since last transaction:

Always empty

authors: ogerly ulfgebhardt

repo: gradido/gradido


text:
Get branch name from env var (#74)

The implemented behavior will try to get the branch name from the env var first (even if the Git CLI is available).
This PR includes some refactoring to rely on Optional.

I would hold off on merging this PR until we have resolved the config caching issue explored in this PR and raised in this issue.
I believe we need to make significant changes to where we read the env vars in order to not cause constant config cache invalidation. Depending on how that will be solved, it might require a different approach/implementation.

Closing PR for now. Let's re-open after making the CC compatibility changes.

@erichaagdev how often does this actually come up? We have 1 case for sure which is the one that triggeed this PR. Before time is spend on this PR, we need to certain is worth the added complexity to itegrate and maintain. 1 single customer would not justify it.

I don't think it was intentionally left out.
I think we should also include GitHub actions but this PR is very, very old. This would improve our samples and our builds. For example here

@etiennestuder This would address the issue where CI checks out the branch in a detached HEAD state. In this case,
git rev-parse --abbrev-ref HEAD returns HEAD rather than the branch name.
This is the case for GitHub Actions when a workflow is triggered by a pull_request event. For example, consider this build for android-cache-fix-gradle-plugin:

GitHub Actions checks out the branch in a detached HEAD state: https://github.com/gradle/android-cache-fix-gradle-plugin/actions/runs/4299768295/jobs/7495318117#step:2:372
The corresponding Build Scan is tagged with HEAD and has a custom value of Git branch=HEAD: https://ge.solutions-team.gradle.com/s/5kt2y4de3ahka/custom-values#L2

My expectation in this case is that the Build Scan is tagged with erichaagdev/update-daily-dependabot-time and has a custom value of Git branch=erichaagdev/update-daily-dependabot-time.
Of course this has the side effect that you cannot filter the Build Scan dashboard to include only builds for your branch.
To better understand the impact this has, consider this filter project: android-cache-fix-gradle-plugin and tags: CI not:main not:head for the last 90 days. There are only 16 builds shown: https://ge.solutions-team.gradle.com/scans?search.relativeStartTime=P90D&search.rootProjectNames=android-cache-fix-gradle-plugin&search.tags=ci%2Cnot:head%2Cnot:main&search.timeZoneId=America/Chicago
Now if we drop the tag: HEAD, we have 1954 builds: https://ge.solutions-team.gradle.com/scans?search.relativeStartTime=P90D&search.rootProjectNames=android-cache-fix-gradle-plugin&search.tags=ci,not:main&search.timeZoneId=America/Chicago
This PR also defines a pattern for how to address #114. In that case, builds running on Bamboo with the repository caching feature enabled will see the Git repository custom value as a local file path, rather than the remote repository. See the issue for more details.

@erichaagdev Thanks for the details. But you are not addressing the core of my question which is: how often does this come up with customers?

Sorry, @etiennestuder but I will not be able to provide an exact frequency.
This would be a problem for any customer using GitHub Actions to run workflows on pull_request events, or any other CI provider which checks out projects in a detached state.
The similar #114 issue that I referenced is actually from a customer.

Closing in favor of https://github.com/gradle/common-custom-user-data-gradle-plugin/pull/240

authors: alextu erichaagdev etiennestuder runningcode


text:
IDE import should not realize any tasks

Importing into an IDE should not realize any tasks (except those required to do the import, if any). Instead, we should have APIs that allow an IDE to query the available tasks and some basic information about those tasks without realizing everything.

Let's keep this open stale bot

authors: adammurdoch eskatos

repo: gradle/gradle


text:
Import of Ant build script does not respect antcall definitions

Original issue: https://issues.gradle.org/browse/GRADLE-1571
Expected Behavior
The declaration of antcall is translated into a task dependency.
Current Behavior
The declaration of antcall is ignored. No task dependency is established.
build.gradle:
ant.importBuild 'build.xml'

task intro {
    dependsOn hello

    doLast {
        println 'Hello, from Gradle'
    }
}

build.xml:
<project>
    <target name="indirect"/>

    <target name="hello">
        <echo>Hello, from Ant</echo>
        <antcall target="indirect" />
    </target>
</project>

Context
The bug still presents a big hole in Gradle's Ant compatibility layer.

The example here doesn't reproduce the problem.
This is the build.gradle:
`ant.importBuild 'build.xml'
task intro {
doLast {
println 'Hello, from Gradle'
}
}
build.xml
<!-- New target: -->
<target name="indirect">
</target>

<target name="hello"  depends="intro">
    <echo>Hello, from Ant</echo>
    <antcall target="indirect" />
</target>

`

Hello there, i ran into a similar problem while using
ant.importBuild('build.xml') { antTargetName ->
    'a-' + antTargetName
}

just that the message was stating
BUILD FAILED in 0s
Imported Ant target 'a-fest' depends on target or task 'a-printEnvironmentInfo' which does not exist
15:33:15: Task execution finished 'a-fest'.
build.gradle
task printEnvironmentInfo {
    doLast {
        println 'Hello, from Gradle'
    }
}

build.xml
<project>
    <target name="fest"  depends="printEnvironmentInfo">
        <echo>Hello, from Ant</echo>
    </target>
</project>

Might the cause of this be the same as above or should i start writing a new issue?
Greetings,
Robert
PS: I might try solving this issue as it would help our transition to gradle enormously

authors: Kassmadin bmuschko deaddowney


text:
Internal caching for archives is too simplistic

Expected Behavior
Manipulating independent archives from tasks should happen independently.
Current Behavior
Due to internal caching of archive content weird things can happen.
Context (optional)
This issue has been filed after noticing weird behavior in an internal Gradle test.
Steps to Reproduce
Use the reproducer located here.
Run: ./gradlew clean update1 verify1 verify2
See the output:
> Task :update1
Updating tar entry /Users/jozsef/Work/bt-support/tmp/build/archives1/test1.tar!subdir2/file2.txt
         BEFORE: original text 2
         AFTER: modification 1 text 2
Updating tar entry /Users/jozsef/Work/bt-support/tmp/build/archives1/test1.tar!subdir2/file3.txt
         BEFORE: original text 3
         AFTER: modification 1 text 3
Updating tar entry /Users/jozsef/Work/bt-support/tmp/build/archives1/test1.tar!subdir1/file.txt
         BEFORE: original text 1
         AFTER: modification 1 text 1

> Task :verify1
Verifying tar entry /Users/jozsef/Work/bt-support/tmp/build/archives1/test1.tar!subdir2/file2.txt
         IS: modification 1 text 2

Verifying tar entry /Users/jozsef/Work/bt-support/tmp/build/archives1/test1.tar!subdir2/file3.txt
         IS: modification 1 text 3

Verifying tar entry /Users/jozsef/Work/bt-support/tmp/build/archives1/test1.tar!subdir1/file.txt
         IS: modification 1 text 1

> Task :verify2
Verifying tar entry /Users/jozsef/Work/bt-support/tmp/build/archives2/test2.tar!subdir2/file2.txt
         IS: modification 1 text 2

Verifying tar entry /Users/jozsef/Work/bt-support/tmp/build/archives2/test2.tar!subdir2/file3.txt
         IS: modification 1 text 3

Verifying tar entry /Users/jozsef/Work/bt-support/tmp/build/archives2/test2.tar!subdir1/file.txt
         IS: modification 1 text 1

There are two identical archives involved. Some tasks work with one of them, some tasks with the other and the two activities should not influence each-other. Yet, due to internal caching (based only on the hash of the original archive files), they do influence each-other.
True, the use case is weird, the update task changes the content of the files in the archive, but since this is (apparently) allowed, it should work in non-surprising ways.
Gradle version
8.1.1
Build scan URL (optional)
No response
Your Environment (optional)
No response

It's unclear what you mean by "manipulating archives" that should happen independently, and what "some tasks work" means. The title of the issue is also not helpful, as "too simplistic" is not something we can fix.
What is the expected behavior and what happens instead?

Okay, now I understand the problem.
It's not really related to the main problem, but there's an issue with the reproducer. Gradle does not support incremental execution for tasks like UpdateTask that modify their own inputs. Your definition is incorrect, as getArchive() is annotated with @InputFile but it's also an output of the task. Once we do https://github.com/gradle/gradle/issues/9134 this build should fail with a validation error. A way to make this work properly is to make UpdateTask @Untracked.
That out of the way, the main issue here is that you are misusing ArchiveOperations.tarTree(). Here's what the Javadoc says:

Creates a read-only FileTree which contains the contents of the given TAR file, as defined by Project.tarTree(Object).

True, it's relatively easy to shoot yourself in the foot like you do in the reproduced. Do you have a proposal to make this safer, or to make the problem easier to spot?

Actually, let's close this, because I don't see how we could improve this in a feasible way. Please reopen if you have a proposal to do so.

authors: jbartok lptr


text:
Updating gradle from 8.1.1 to 8.2.1 caused an error with isCanBeResolved

Expected Behavior
Don't give an error, sync succesful.
Current Behavior
Gives an error.
Updating gradle from 8.1.1 to 8.2.1 caused an error on this line:     ).onEach { it.isCanBeResolved = true }.
Pastebin of the error.
Context (optional)
In my build.gradle.kts
in shadowJar task I have
configurations = listOf(
project.configurations.implementation.get()
).onEach { it.isCanBeResolved = true }
to make implementation shadow.
Updating gradle from 8.1.1 to 8.2.1 caused an error on this line:     ).onEach { it.isCanBeResolved = true }.
Pastebin of the error.
Steps to Reproduce

Have gradle 8.1.1 kotlin dsl project
Have  project.configurations.implementation.get().isCanBeResolved = true or similar in your gradle executing somewhere
Update to 8.2.1 using ./gradlew wrapper --gradle-version=8.2.1
Error while sync!

Gradle version
8.2.1 gives the error, 8.1.1 is fine.
Build scan URL (optional)
No response
Your Environment (optional)
Intellij IDEA 2023.2 on windows.

Sorry that you're having trouble with Gradle!
We appreciate the effort that went into filing this issue, but we must ask for more information.
As stated in our issue template, a minimal reproducible example is a must for us to be able to track down and fix your problem efficiently. Our available resources are severely limited, and we must be sure we are looking at the exact problem you are facing.
If we have a reproducer, we may be able also to suggest workarounds or ways to avoid the problem.
The ideal way to provide a reproducer is to leverage our reproducer template. You can also use Gradle Project Replicator to reproduce the structure of your project.
This issue will be closed after 7 days unless you provide more information.

We weren't able to reproduce your problem using the steps you provided. Please provide a reproducer using the information above.

Sorry that you're having trouble with Gradle!
This is an issue with IntelliJ IDEA’s Gradle integration, which is developed by JetBrains and cannot be addressed in the Gradle Build Tool project.
Please open such IntelliJ-related issues on the JetBrains Issue Tracker at https://youtrack.jetbrains.com/newIssue?project=IDEA.

Note that we do not recommend setting implementation configuration to be resolvable. This will become an error in future versions of Gradle.


text:
Junit 5 parallel test execution via Gradle fails with "Received a completed event for test with unknown id".

Expected Behavior
All tests are executed normally. Like they do when running them with idea runner.
Current Behavior
One or several tests are ignored or fail. The cause seems to be "Received a completed event for test with unknown id".
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Received a completed event for test with unknown id '27.78'. Registered test ids: '[27.82, 27.1, 27.81, :test]'Close stacktrace at org.gradle.api.internal.tasks.testing.results.StateTrackingTestResultProcessor.completed(StateTrackingTestResultProcessor.java:79) at org.gradle.api.internal.tasks.testing.results.AttachParentTestResultProcessor.completed(AttachParentTestResultProcessor.java:56) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29) at org.gradle.internal.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:133) at org.gradle.internal.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:34) at org.gradle.internal.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:73) at org.gradle.internal.operations.CurrentBuildOperationPreservingRunnable.run(CurrentBuildOperationPreservingRunnable.java:42) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Context
We decided to parallelize our test to improve test execution performance and build times using the new Junit 5 parallel test execution feature.
Steps to Reproduce
I've made an example project that somewhat resembles the tests that we have in the project i'm working on. An abstract class with method for some initialization to be done before running each test and a number of test classes extending it. Not sure this inheritance is relevant, but the bug doesn't reproduce if i'm just running the same test 100000 times with RepeatedTest annotation.
Github project: https://github.com/bersercker111/gradle_4_9_junit_5_3_RC1_parallel_test_bug
Commands to reproduce:
git clone https://github.com/bersercker111/gradle_4_9_junit_5_3_RC1_parallel_test_bug
cd gradle_4_9_junit_5_3_RC1_parallel_test_bug
./gradlew test

The bug occurs almost every time on my environment if i'm running all test with gradle test task.
Your Environment
Operating system	Linux 4.8.0-53-generic
CPU cores	4 cores
Max Gradle workers	4 workers
Java runtime	Oracle Java(TM) SE Runtime Environment 1.8.0_144-b01
Java VM	Oracle Java HotSpot(TM) 64-Bit Server VM 25.144-b01 (mixed mode)
Max JVM memory heap size	954 MB
Gradle version: 4.9.0
Junit version: 5.3.0_RC1
Build scan URL: https://scans.gradle.com/s/3gl3valcquzfo

Time to time fails for me as well.
Your Environment

System Version: macOS 10.13.6 (17G65)
Kernel Version: Darwin 17.7.0
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)

Have same issue. After some debugging find out that issue is in JUnitPlatformTestExecutionListener
https://github.com/gradle/gradle/blob/2b3811843a0b371f018d7c828927bb725f1564cd/subprojects/testing-junit-platform/src/main/java/org/gradle/api/internal/tasks/testing/junitplatform/JUnitPlatformTestExecutionListener.java#L48
It doesn't expect to have multiple running classes simultaneously.
Temporary fix is to configure gradle test task to run classes in different forks
test {
      maxParallelForks = Runtime.runtime.availableProcessors().intdiv(2) ?: 1
}

Just one more update right configuration for workaround is
test {
      systemProperties['junit.jupiter.execution.parallel.enabled'] = true
      maxParallelForks = Runtime.runtime.availableProcessors().intdiv(2) ?: 1
      forkEvery = 1
}

Same error here with gradle 4.10

Another workaround:
build.gradle
test {
      maxParallelForks = Runtime.runtime.availableProcessors().intdiv(2) ?: 1
      forkEvery = 1
}

src/test/resources/junit-platform.properties
junit.jupiter.execution.parallel.enabled=true

Without the forkEvery = 1 you sometimes get errors like this one:
Received a completed event for test with unknown id '5.18'. Registered test ids: '[2.2, 2.3, 2.1, 5.1, 2.6, 2.7, 2.4, 2.5, 2.8, 2.9, :test]'
java.lang.IllegalArgumentException: Received a completed event for test with unknown id '5.18'. Registered test ids: '[2.2, 2.3, 2.1, 5.1, 2.6, 2.7, 2.4, 2.5, 2.8, 2.9, :test]'
        at org.gradle.api.internal.tasks.testing.results.StateTrackingTestResultProcessor.completed(StateTrackingTestResultProcessor.java:79)
        at org.gradle.api.internal.tasks.testing.results.AttachParentTestResultProcessor.completed(AttachParentTestResultProcessor.java:56)
        at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29)
        at org.gradle.internal.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:133)
        at org.gradle.internal.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:34)
        at org.gradle.internal.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:73)
        at org.gradle.internal.operations.CurrentBuildOperationPreservingRunnable.run(CurrentBuildOperationPreservingRunnable.java:42)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.lang.Thread.run(Thread.java:748)

The workarounds do work, but forking the jvm for each test is not possible for a medium/big size project

@marcphilipp Assuming we use Gradle > 5.1:
To get JUnit 5 parallel execution we need:
A)
build.gradle
test {
      maxParallelForks = Runtime.runtime.availableProcessors().intdiv(2) ?: 1
}

src/test/resources/junit-platform.properties
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.mode.default=concurrent

B)
src/test/resources/junit-platform.properties
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.mode.default=concurrent

How does maxParallelForks interact with JUnit 5 junit.jupiter.execution.parallel.config.fixed.parallelism?

maxParallelForks will use multiple VMs and JUnit will parallelize test execution according to the configured parallelism in each of them.
For example with maxParallelForks = 2 and junit.jupiter.execution.parallel.config.fixed.parallelism = 4, Gradle will fork two VMs and distribute the found test classes evenly among them. In each VM, JUnit will execute the tests in 4 concurrent threads.

Personally, I would just use JUnit's parallelism because it should have less overhead. Thus B) is sufficient IMHO.

How does maxParallelForks interact with JUnit 5 junit.jupiter.execution.parallel.config.fixed.parallelism?

To extend @marcphilipp explanation, gradle distributes classes among processes, while junit distrubutes classes and methods. So after gradle spawns a VM, junit is responsible for parallelizing the classes (1-n) it received.

Maybe add a section to the Gradle documentation?

Documentation still missing on this. Shouldn't there be a section here? https://docs.gradle.org/current/userguide/java_testing.html#using_junit5

@calvertdw This is a JUnit feature, not a Gradle one and is documented in the JUnit User Guide.

Marc: I would just use JUnit's parallelism because it should have less overhead

a) Gradle-based parallelism should better control resource utilization for multi-module builds. Gradle-based VMs account the number of parallel workers, while JUnit parallelism does not know if there is concurrent execution of tests from another module.
b) Gradle-based parallelism could cache test outcomes. In other words, if a batch fails, then Gradle could retry just a subset of tests. Of course, source-code change would probably trigger re-execution of all the tests.
c) Gradle tracks execution history, so it knows past response times for the test, so it can better schedule test execution order
d) Gradle-based parallelism allows concurrent execution of tests which can't really work in the same JVM. For instance, if tests play with System.properties, TimeZone.setDefault, classloaders, then the tests are hard to parallelize in a single JVM.

d) Gradle-based parallelism allows concurrent execution of tests which can't really work in the same JVM. For instance, if tests play with System.properties, TimeZone.setDefault, classloaders, then the tests are hard to parallelize in a single JVM.

JUnit5 Jupiter has support for managing access to shared resources via @ResourceLocks  the same goes for Spock 2.0.

@leonard84 , concurrent means simultaneous. ResourseLock makes the test executed in a single thread, however, the concurrent execution is not possible

Yes, that is true, but in a most cases not every test modifies the shared resource, and resource locks only enforce single threaded execution, if you are acquiring a READ_WRITE lock, all test that use just a READ lock, can execute concurrently. Gradle runs a single test class also sequentially, so you don't have full concurrency either.
So YMMV depending on you test suite. For example, if you have a single data driven tests that makes a remote call to 100+ systems, Gradle class based forking method can't run those concurrently.
Also don't forget the memory overhead of multiple jvms, especially on free-tier ci-systems you are quite limited.

cc: @marcphilipp
Would it be possible to reopen?
This prevents our project from upgrading to Gradle 7. We've documented our experience here. Our users have reported similar problems in their projects.

@sanity Could you please create a new issue??

authors: ajax-tykhonov-g calvertdw cocorossello dlapunas leonard84 marcphilipp mdolinin moleksyuk sanity sdavids vlsi


text:
Polish variant-aware dependency substitution

This PR builds on top of #13299  and adds documentation and missing APIs.

@bot-gradle test RFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

OK, I've already cancelled the old build and triggered a new ReadyForMerge build for you.

@bot-gradle test this

OK, I've already cancelled the old build and triggered a new ReadyForMerge build for you.

authors: bot-gradle melix


text:
Note token from command in exception

instead of accidentally logging the daemon token twice.
See https://github.com/gradle/gradle/commit/b810473f2bd9df34872c36cba313a829dbff7bba#r46962987

@bot-gradle test QFL

OK, I've already triggered QuickFeedbackLinux build for you.

authors: bot-gradle wolfs


text:
Publish 8.0-20230204010107+0000

Publish 8.0-20230204010107+0000

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

I've triggered a build for you.


text:
Task logger should have fallback operation id during execution

Context
When tasks use external threads, output is not linked to the task execution build operation id. This fixes this problem by explicitly assigning the task execution build operation id as fallback to the task logger.

@big-guy would be great to get feedback from you on this


text:
Implement persistent volumes in AWS

The primary goal is to export a metric that calculates the hourly cost of each persistent volume within our EKS clusters. The exported metric should align with our existing metrics(cloudcost_aws_eks_persistent_volume_dollars_per_hour).
There's really two parts:

Generate a Pricing Map that enables searching by region and storage class
List out EBS volumes

There should be the following labels:

cluster
namespace
persistentvolume
storage_class
status(in use or not)

@paulajulve had pointed out the cluster label may not be possible to derive from the API response. If that's the case, then we need to consider how we can join against existing kube state metrics to derive the cluster name.

Most of the functionality is implemented with tweaks to naming and what not. The main thing is adding tests, specifically for the Collect method, is tightly coupled to the compute module.
@Pokom will take a look to see if we can split out the collect method in such a way where you can create a method that encapsulates the logic into a testable method.

Currently working to offload processing of the volumes to a background goroutine for performance reasons. @paulajulve will close this out and follow up with another issue that details the performance problems and track the work there.

Next steps:

performance implementations will continue here
I've not yet fully validated the numbers on the metrics we're emitting, but that'll continue as a separate work stream too, as I work to switch our own usage of Open Cost for EBS volumes to these ones.

authors: Pokom paulajulve

repo: grafana/cloudcost-exporter


text:
Why Alloy in StatefulSet mode?

The default way to deploy an Alloy controller is DaemonSet mode. Why does this chart override that setting to be StatefulSet mode?
If there's a good reason for it, what would be the suggested way to scale Alloy for metrics scraping? Change to DaemonSet, or increase the number of replicas? How do I make sure metrics aren't scraped twice? Does it filter on node name?
My cluster has ~1000 nodes.

I have the same questions as @ppawiggers , so just commenting for visibility.
@ppawiggers I am going to try to set it to DaemonSet even if I see that the configuration has an @ignored comment on it, hopefully we are able to go for a daemon set

This doc should hopefully explain things a bit:
https://github.com/grafana/k8s-monitoring-helm/blob/main/charts/k8s-monitoring/docs/Structure.md
TL;DR:

alloy is a statefulset because it:

Doesn't need to be a daemonset, it's not required to be on every node
It set up easily to have its own storage for write-ahead logging

alloy-events is a single-instance deployment because it doesn't need storage and if it scales beyond a single instance it'll start sending duplicate events
alloy-logs is a daemonset because the default way it gathers pod logs is by accessing each individual node's filesystem.

So, it's set up with these footprints because it's the most optimal deployment pattern for the type of work each alloy instance is doing.

authors: petewall pioardi ppawiggers


text:
tk export produces wrapped lines

tk export sometimes produces invalid Kubernetes manifests due to wrapping of long lines. Most fields where long lines might exist are resistant to \n in their values, but some fields are not.
This is a sample file where we can see the line wrapping occurring:
// environments/default/main.jsonnet
{
  service: {
    apiVersion: 'v1',
    kind: 'Service',
    metadata: {
      annotations: {
        k: 'aaaaa bbbbb ccccc ddddd eeeee fffff ggggg hhhhh iiiii jjjjj kkkkk mmmmm nnnnn',
      },
      labels: {
        name: 'grafana',
      },
      name: 'grafana',
    },
    spec: {
      ports: [{
        name: 'grafana-ui',
        port: 3000,
        targetPort: 3000,
      }],
      selector: { name: 'grafana' },
      type: 'NodePort',
    },
  },
}

tk export output environments/default/main.jsonnet produces the following (notice the k annotation):
apiVersion: v1
 kind: Service
 metadata:
     annotations:
         k: aaaaa bbbbb ccccc ddddd eeeee fffff ggggg hhhhh iiiii jjjjj kkkkk mmmmm
             nnnnn
     labels:
         name: grafana
     name: grafana
     namespace: default
 spec:
     ports:
       - name: grafana-ui
         port: 3000
         targetPort: 3000
     selector:
         name: grafana
     type: NodePort

In our particular use-case, we're using tanka to generate helm charts, and so some values are actually Helm templating, e.g.:
{
  spec+: {
    template+: {
      metadata+: {
        annotations+: {
          local tplname(obj) = '%s.%s-%s' % [obj.apiVersion, obj.kind, obj.metadata.name],
          'checksum/grafana-config': '{{ include (print $.Template.BasePath "/generated/%s.yaml") . | sha256sum }}' % tplname($.grafana.config),
        },
      },
    },
  },
}

The output of this snippet makes helm templating fail because it breaks the {{ }} markers into different lines.
This has been a known surprising behavior of go-yaml.v2 for quite some time, so much so that v3 changed to not wrap long lines by default.
I tried this patch locally and it fixes the issue, but I don't know if it will have unintended side-effects elsewhere:
diff --git a/pkg/kubernetes/manifest/manifest.go b/pkg/kubernetes/manifest/manifest.go
index 51f577d..55a6102 100644
--- a/pkg/kubernetes/manifest/manifest.go
+++ b/pkg/kubernetes/manifest/manifest.go
@@ -9,7 +9,7 @@ import (
        "github.com/Masterminds/sprig/v3"
        "github.com/pkg/errors"
        "github.com/stretchr/objx"
-       yaml "gopkg.in/yaml.v2"
+       yaml "gopkg.in/yaml.v3"
 )

 // Manifest represents a Kubernetes API object. The fields `apiVersion` and

Another option would be to use yaml.v2's FutureLineWrap() to disable line wrapping, if you're not in a place where you can migrate to v3.

I can remember a few discussions about yaml.v2/v3 but I can't recall what implications that may have. @sh0rez might have more context.

To be noted that this causes a massive amount of indent changes. The kustomize Kubernetes team has the same issue with go-yaml. They have their own fork that allows to customize the indents (reducing the migration impact). This issue has been updated semi-recently so it might be good to see what comes of it: https://github.com/go-yaml/yaml/issues/720 before forcing a massive YAML update on users. Also, it does seem like kubectl still imports v2.4.0 🤔

Will you consider using the aforementioned FutureLineWrap() in manifest.go to enable v3's line wrapping while v2/v3 migration discussion is ongoing?

Hey folks 👋
Is there a way to reconsider moving to V3? Semantically, it should not make a difference so tools like FluxCD/ArgoCD/... won't apply any changes to target environments

Perhaps it would be more beneficial to poke upstream to fix the issue?

Tanka is now on v3 and I can no longer reproduce this issue 🙂

> tk --version
v0.27.1

Tanka's definition
local keycloakContainer =
  core.container.new('keycloak', 'quay.io/keycloak/keycloak')\
  + core.container.withArgs('start aaaaa bbbbb ccccc ddddd eeeee fffff ggggg hhhhh iiiii jjjjj kkkkk mmmmm nnnnn')

produces
    spec:
      containers:
      - args:
        - start aaaaa bbbbb ccccc ddddd eeeee fffff ggggg hhhhh iiiii jjjjj kkkkk
          mmmmm nnnnn
        image: quay.io/keycloak/keycloak

Reproduced on other resources as well.

You are absolutely right ... now I wonder why I couldn't reproduce it before.

Looks like that's a problem with gopkg.in/yaml.v2 v2.4.0. It was "fixed" before but since it introduces a behavioral change, it got reverted and is now only fixed in v3 🙁
https://github.com/go-yaml/yaml/pull/571
Unfortunately that's also consistent with how sigs.k8s.io/yaml marshals things.

Maybe we will only be able to fix that once we are able to upgrade to yaml.v3 everywhere. Let's put it this way: This has been on our wishlist for a while...

I open exported yamls in Visual Studio Code. And TBH, example with container didn't show errors.

Reproduced on other resources as well

But I was afraid of my Traefik Ingress Route:
k8s.traefik.v1alpha1.traefik.ingressRouteRule.new('Host(`%s`) && (PathPrefix(`/realms`,`/resources`,`/js`) || Path(`/robots.txt`))' % conf.hostname)

which produces
  - kind: Rule
    match: Host(`keycloak.example.com`) && (PathPrefix(`/realms`,`/resources`,`/js`)
      || Path(`/robots.txt`))

which in VS Code looks like

that's also consistent with how sigs.k8s.io/yaml marshals things

Maybe because of that, but Kubernetes took that yaml without complains and fixes it a little (added >-):
    - kind: Rule
      match: >-
        Host(`keycloak.example.com`) && (PathPrefix(`/realms`,`/resources`,`/js`)
        || Path(`/robots.txt`))

In the end this is not urgent issue to me. For now at least.

Most fields where long lines might exist are resistant to \n in their values, but some fields are not

upgrade to yaml.v3 everywhere

That would be great. Thank you.

Ahhhhh, looks like in YAML linebreaks in list-item values are ignored... So your initial example output
    spec:
      containers:
      - args:
        - start aaaaa bbbbb ccccc ddddd eeeee fffff ggggg hhhhh iiiii jjjjj kkkkk
          mmmmm nnnnn
        image: quay.io/keycloak/keycloak

is valid and the arg contains everything including nnnnn. I then also tried it with yq and putting the string into an object property. This also produced the line-wrapping but yq was again able to parse it 😐
As far as I can tell, as long as you are not trying to parse the produced YAML with something that does not support this language "feature", then you should be good to go also in your Traefik example 🙂

authors: Duologic julienduchesne pharaujo xvzf zc-devs zerok

repo: grafana/tanka


text:
Allow inline environments to be pruned

Fixes https://github.com/grafana/tanka/issues/510
The prune logic in pkg/tanka/prune.go already calls Load(), which handles inline envs based on Opts.Name, so this extremely simple change appears to be enough, at least based on the testing I've done.
Let me know if I've missed anything 👍

Nice! This indeed enables the feature, but there is a bit more to it which is very subtle.
Label uniqueness
tk prune discovers what to prune based on a label called tanka.dev/environment, which value is generated by *Environment.Metadata.NameLabel(): https://github.com/grafana/tanka/blob/a43a83920937a4ea819a965b82fee59962ac813c/pkg/spec/v1alpha1/environment.go#L48-L50
This works fine for static environments, because they have their name generated based on their path on disk. Inline environments however permit any user-given name, and instead use the Metadata.Namespace (not to be confused with spec.namespace) field for their path on disk.
This means to generate an unique label above function would need to include information from both Metadata.Name and Metadata.Namespace. Otherwise running tk prune on a equally named environment would wrongly delete resources.
Environment uniqueness
Currently it is possible to define two inline environments of the same name in the same file. This is merely an oversight and not a guaranteed feature, but it breaks above uniqueness (again).
Given we never gave support guarantees, we can easily avoid that by having tanka.List() fail when it encounters two environments of the same name.

Given this increase in complexity, let us know whether you are still interested in doing this. Of course we would be there to assist if you wanna do it yourself :)

Thanks for the quick reply @sh0rez!

Inline environments however permit any user-given name, and instead use the Metadata.Namespace (not to be confused with spec.namespace) field for their path on disk.

Am I right to assume you mean Metadata.Name, not Namespace? If so this matches my mental model of inline environments: their name is the value of metadata.name, not the path on disk.
I want to make sure I understand the problem you go on to describe, with prune not being currently able to guarantee that it will not delete the "wrong" resources. A scenario I can think of that could cause this:

A tanka repo with 2 environment paths on disk, each using inline environments: environments/A/main.jsonnet, and environments/B/main.jsonnet.
Each main.jsonnet declares a tanka.Environment with identical metadata.name: "foo", in identical namespaces.
After tk applying each environment (tk apply environments/A --name foo; tk apply environments/B --name foo), you have various resources in the same namespace with identical prune labels.
tk prune environments/A --name foo will delete the resources from B, in addition to the resources from A. Whoops!

The new label could look something like :, e.g. environments/default/main.jsonnet:myEnv

By making the path-on-disk part of the prune label, we'd avoid the scenario above. That makes sense. Whether we change the value of tanka.dev/environment or change inline environments only to use a new label, won't that create a breaking change for tanka users who've started using inline environments since 0.14.0 came out? I can't immediately think of a way out of that, and we do need to support prunes. Breaking changes in this way might be preferable to the possibility of deleting the wrong resources! FWIW, using the same label key seems best.

Currently it is possible to define two inline environments of the same name in the same file.

I think I understand you, are you saying that this is an invalid state that we should guard against? If so, that makes sense: a tk-eval tree with 2 tanka.Environments with the same metadata.name should not be valid. This is different from the scenario I describe above.

If I've indeed got the right end of the stick, I'm happy to add to this PR 👍

Concatenating paths on disk and environment names might commonly come close to the k8s 63 character limit on label values. Wdyt of truncate(hashsum(sprintf("%s:%s", pathOnDisk, Environment.metadata.name))?

Am I right to assume you mean Metadata.Name, not Namespace? If so this matches my mental model of inline environments: their name is the value of metadata.name, not the path on disk.

I actually meant metadata.namespace. Take a look how we parse environments:
// static env at /environments/default
{
  kind: "Environment",
  metadata: {
    name: "environments/default",
    namespace: "environments/default/main.jsonnet"
  }
}

// inline env at /environments/default
{
  kind: "Environment",
  metadata: {
    name: "whateverYouChose",
    namespace: "environments/default/main.jsonnet"
  }
}

// inline env at /environments/default/foo.jsonnet
{
  kind: "Environment",
  metadata: {
    name: "whateverYouChose",
    namespace: "environments/default/foo.jsonnet"
  }
}

So namespace always holds the path to the file that was used as the entrypoint. For static envs, name also holds the path to the directory the entrypoint is enclosed in.

I want to make sure I understand the problem you go on to describe, with prune not being currently able to guarantee that it will not delete the "wrong" resources. A scenario I can think of that could cause this ...

That scenario is exactly what I had in mind.

Breaking changes in this way might be preferable to the possibility of deleting the wrong resources

Totally! It wouldn't be too bad though. If newer Tanka versions would start to use different label values, the worst thing that could happen is that they would miss resources created by previous versions and not yet re-applied.
Same for older versions, they would miss resources by newer versions. afaict no resources would falsely be deleted.

a tk-eval tree with 2 tanka.Environments with the same metadata.name should not be valid. This is different from the scenario I describe above.
Yup it's different, but it would lead to equal name+namespace, but we should disallow it anyways.

Wdyt of truncate(hashsum(sprintf("%s:%s", pathOnDisk, Environment.metadata.name))?

We thought of this option before, sounds reasonable. If we are going to break anyways, then yeah, let's fix both issues

Ah ha, the part I was missing was that metadata.Namespace already contains the path on disk: https://github.com/grafana/tanka/blob/a43a83920937a4ea819a965b82fee59962ac813c/pkg/spec/spec.go#L41-L55
I think I have enough info to get started, and thanks again 👍

We thought of this option before, sounds reasonable. If we are going to break anyways, then yeah, let's fix both issues

Break one thing, fix two. Sounds like a win to me. :)
I did some work towards this in https://github.com/grafana/tanka/pull/433, please have look, might want to steal some ideas.

@sh0rez @Duologic I think this is ready for review now, would you mind taking a look? I've updated the commit message / description to reflect the changes requested earlier.

Nice one, thanks for reviewing this. I plan to start using this at GitLab pretty soon.

authors: Duologic craigfurman sh0rez


text:
Creating rudimentary size tracking of unused disks

Adding a small prometheus metrics to track the unused disk size by namespace as well as type (ssd vs hdd)

Oops, there's a conflict now that #65 is merged. Sorry! 😬

authors: inkel logyball

repo: grafana/unused


text:
Time goes forward or backward or both?

A fundamental choice we need to make is what direction we see time going in. Having tried to document a backwards-in-time description for several years now, I'm pretty convinced that talking about population processes backwards in time is an inherently confusing thing, even to experts, who still make mistakes. IMO, the goal we should aim for is a simple and intuitive description of population processes forwards in time, with concrete and unambiguous language to define the various concepts. Given this unambiguous description, it'll be simple enough for things that work in backwards time (like msprime) to translate into their own internal models.
There is the issue of when we make the reference time, i.e., when is zero. I don't think this is much of an issue, really - it's just an arbitrary time that we measure differences from, and can be left to the user. They can make the present day be time zero, if they like, and make events using negative times. Or, we could make the reference time the present, and state that units are in "year ago". It really doesn't matter that much, and we can easily have a flag to sort out how that works.
For things like migration, I don't think we can avoid using terminology like source and destination, because individuals really do come from somewhere and go to somewhere else. These concepts from from and to should be in the forwards-time sense, because the backwards sense is very confusing.

That's my opinion though - what do others think?!

I agree that time should flow forwards, such that we have start_time < end_time, or early_time < late_time. However, describing models using "years ago", or kya, seems very natural to me. And I reckon its a bad idea to require that a user identify the oldest time in their model and translate all other times to be relative to this, each time they write a yaml file. So making T_now=0 and using negative times for the past seems like a nice practical solution.
Just how jarring is it to use negative numbers here though? Presumably the most obvious error would be to forget, and use positive numbers where a negative number is intended. Is there any reason to permit the use of both positive and negative times in a single demography?

So it sounds like we next need to settle on a convention for measuring time, now that we're happy with the direction of time flowing from past to present (forward time convention). Having negative time I think can be confusing, and anchoring at time other than present I also find less convenient or clear. My current PR has time measure in time units back from present, so it checks that the start of an epoch is older than the end of the epoch, e.g. I personally prefer this option for now, but happy to discuss alternatives or be persuaded otherwise :)

I think that's a fine convention. How did you imagine specifying a forwards time demography that matches an "experimental evolution" type study (sorry, I don't know the correct terminology for this)? In this case, the model writer would have to put time zero at the end of their study, which seems wrong to me, particularly if the experiment has not been run. I guess whatever choice we make, it will be less than ideal for some types of models.
Also, I'm convinced we should change the terms "start_time" and "end_time" to something else, if only to avoid confusion due to these terms being used differently in the msprime API.

For experimental evolution, having time zero be the end has the same meaning as for other models--"the final sampling point".

To summarise: time flows forwards, time=0 means the present, and start_time > end_time. This implies that source/dest for migrations has the forward-time convention: a migrant is born in 'source' and has offspring in 'dest'.

authors: apragsdale grahamgower jeromekelleher molpopgen

repo: grahamgower/demes

license: ISC


text:
Question: implications of Packer in Bazel?

My understanding of Packer is that it can register AMIs to AWS so that you can deploy them as EC2s. This sits outside of Bazel's usual design (all inputs are local, and all outputs go to the artefacts folder).
What are the implications of a Bazel rule that might modify external services (in this case AWS) in practice?

@njlr thank you for your question!
We architected the rules wrapping Packer (and pretty much all rules, for that matter) as a combination of assemble_ rule and deploy_ rule. Assemble rules are meant to be built by executing bazel build and deployment rules are meant to be executed via bazel run and usually depend on revelant assemble target. With regards to Packer, assemble_packer rule would only produce an archive on files Packer would need to run, so no "real" action (touching the network) would happen is you build it. The real image deployment happens when you execute bazel run on a deploy_packer target.

@vmax That makes sense. Thank you!

authors: njlr vmax

repo: graknlabs/bazel-distribution


text:
feat: narrow message updates

Fixes grammyjs/hydrate#11

@deptyped let's get https://github.com/grammyjs/types/pull/18 merged (we should do this anyway) and then adjust and merge this in order to fix #11. What do you think?

authors: KnorpelSenf deptyped

repo: grammyjs/hydrate


text:
Incorrect type for sendDocument’s result

Sending a WebP video or photo, or a .tgs file returns a StickerMessage, not DocumentMessage.

Maybe this is just to be fixed in the core repo? Change DocumentMessage in the return type of sendDocument to DocumentMessage | StickerMessage.

Maybe this is just to be fixed in the core repo?

The types are defined here, and only here: https://github.com/grammyjs/types/blob/fbbb7c54c0b67cd9e168d5584b0e993d05db3fe3/methods.ts#L343

Change DocumentMessage in the return type of sendDocument to DocumentMessage | StickerMessage.

That would describe something undocumented.

Any send* methods that is used for sending media files, except photos, are subject to return messages of any type

That is correct. This is a known and intended inconsistency between the types and the specs.
In 99 % of cases, the returned message object contains exactly what is expected. This leaves us with two options:

Follow the specs very closely. Use Message. Upside: correctness in the 1 % of cases. Downside: worse usability in the other 99 %.
Do the intuitive and mostly correct thing. The current way. Use Message.DocumentMessage etc. Upside: good usability, downside: not quite correct.

Currently, grammY does number 2. Telegraf used to have types that are very hard to use in order to be highly accurate. grammY way supposed to improve this by making reasonable compromises, trading in some correctness for a lot of usability. Being practical about such things is the vastly more successful model, however, in this particular instance, I have indeed often thought that I should've went with option 1 instead. I might reconsider this for the next major version of grammY.

rendering the custom *Message types useless.

That is not correct. They are useful in bot code in any case, no matter if they're used as return types or not.

The goal of types is to not allow broken code to run. Closing this anyway.

repo: grammyjs/types


text:
Functionality for Now version 2

Made changes in index.js that allow now version 2 to build the app with a lambda function. The changes will allow the GraphiQL playground to be used during development. The project structure is set up with a new now.json file and now-secrets.json file which should, of course, be added to the .gitignore file of the project in a real app. Should be able to deploy with just the "now" command.

Thanks Michael!

authors: MuddyBootsCode johnymontana

repo: grand-stack/grand-stack-starter


text:
Add an example of using graphql.ID

Add an example of using graphql.ID. More specifically creating one from an integer and extracting an int value out of it.
All examples must be placed in the /examples/ folder in the root of this project.

👋 Hello!
Do you mind if take this issue? Thanks!

A quick question on the ask for this issue.
Looking at the GraphQL spec, it mentions that IDs should always be serialized to a string (http://spec.graphql.org/October2016/#sec-ID). In that case, should we provide examples of how to convert a GraphQL ID to an Integer if the specs recommend converting it to a String? I'd love to get more clarification on this. Thanks!

@ConnieJChi Feel free to add an executable example in example_test.go file in the relay package. Make sure that you use the MarshalID, UnmarshalKind and UnmarshalSpec in your executable examples.

authors: ConnieJChi pavelnikolov

repo: graph-gophers/graphql-go


text:
Move tests to groovy spock framework

Move all the tests to Groovy with inline json and inline flow files
Example
https://github.com/graph-quilt/graphql-orchestrator-java/tree/master/src/test/groovy

Hi Ashpak, can you assign this issue to me!

authors: ankushkawanpure ashpak-shaikh

repo: graph-quilt/graphql-service-adapters


text:
What version/s of node will work with this specific build?

I am wanting to build from the typescript in the repo.  Which is the most up to date version of node that works with this codebase?

hi, I use node v8.9.1 in MacOS

repo: grapheco/InteractiveGraph


text:
neo4j_interactivegraph知识图谱可视化中节点图片显示问题

您好，不好意思，打扰您一下！我在使用neo4j+interactivegraph知识图谱可视化中发现web界面上节点的图片都显示不出来，我知道是因为图片链接地址已经被豆瓣给修改了，但是我在neo4j中一个电影节点的'image"属性给修改成了一个可以打开的图片URL,可是在web界面仍然没有显示，，我现在不知道该如何去解决这个问题，还请您在百忙之中，指点我一下，麻烦您了。

This is same issue as #46


text:
Remove FlagEncoder

Fixes to a large extent #2463.
The FlagEncoder interface is gone. But what previously was an implementation of it, the now very simple VehicleEncodedValues class, still remains. All it does now is grouping a few encoded values together, like car_access+car_average_speed.
So basically there is no such thing as a 'flag encoder' anymore. We already moved everything that was related to 'vehicle-specific' OSM parsing to the VehicleTagParsers in #2561. But with this PR the EncodingManager also no longer offers methods like encodingManager.getEncoder("car"). It only 'manages' encoded values now. So the only thing we can fetch from the EncodingManager are encoded values. The only thing that still remains is that we can add a group of certain encoded values to the encoding manager collectively, i.e. there still is EncodingManager#add(VehicleEncodedValues.bike()) which, e.g. adds access, speed + priority encoded values for a bike. The reason I kept this here is that it corresponds to our config option graph.flag_encoders which defines multiple encoded values for each entry (and enables the corresponding vehicle parsers as well). I think we should also remove this, but since this requires some discussion about the new format better in a later PR. Actually I removed this pattern from almost all tests already and and it only remains on a high level / the GraphHopper class now.
The most important change here is that the fastest weighting (and others, also see here: 15426ef4588797f3c0031722ecb64297b98bfc1) no longer receives a FlagEncoder, but the encoded values directly. So for example this:
FlagEncoder encoder = encodingManager.getEncoder("car");
Weighting weighting = new FastestWeighting(encoder);

is now this:
BooleanEncodedValue accessEnc = encodingManager.getBooleanEncodedValue(VehicleAccess.key("car"));
DecimalEncodedValue speedEnc = encodingManager.getDecimalEncodedValue(VehicleSpeed.key("car"));
Weighting weighting = new FastestWeighting(accessEnc, speedEnc);

Importantly, the FastestWeighting also used encoder.getMaxSpeed() from the encoder, which we need to replace with speedEnc.getMaxValue(). This still remains todo before we can merge here. @karussell already did some work in this direction here: b3b3b11e35f1c9633d5c50a33c1b37ef3456ee73. Update: This was done in #2614, #2616, #2619 and the new method is now called: getMaxOrMaxStorableDecimal().
The other thing that is still missing are the private/destination penalties in FastestWeighting, which we also configured via the FlagEncoder so far. They should probably be replaced with config options for the weighting, i.e. weighting: fastest|private_penalty_factor=10, see the todo comments in FastestWeighting. Update: This is done in DefaultWeightingFactory now.

Can you update your comment to use the VehicleAccess and maybe also mention this in the changelog?

:+1: done :)

So finally. Really nice. When will you livestream the merge ;)

3, 2, 1... few years later, and its gone!

repo: graphhopper/graphhopper


text:
Point graph node to graphprotocol/ethabi/graph-patches to fix errors

Decentraland does not work unless ethabi supports event overloading and being able to parse event fields that aren't bytes32, such as this: https://etherscan.io/tx/0xc760d94f4512aac26123ad4345b824cdf271d0b3c9529778a42d3329b88b35bc#eventlog
The branch we are pointing to, created by @leodasvacas are a combination of https://github.com/paritytech/ethabi/pull/145 and https://github.com/paritytech/ethabi/pull/140
Hopefully those get merged one day into parities upstream branch, but for now this is needed to make Decentraland work.

Hmm. We should not include and depend on the changes in my ethabi PR. They are correct that this was a bug in a previous Solidity compiler version. If Decentraland's contracts were deployed with that bug then we may have to deal with the contracts being broken. Unless we can convince the ethabi team to take the PR in anwyay to be more resilient against bugs like that.

I think we should probably then deal with the bad solidity compiler versions of contracts ourselves. I think it is fair for the ethabi team to reject the issue since their code meets what the standard is.
As you stated previously, Livepeer was having this issue, and now I found Decentraland to have this issue too. There are probably a good amount of other contracts that we haven't seen.
So, I guess I will use this solution for the mean time, but not merge it into master. but we should have a plan to deal with this within the graph node

As we've just discussed, we're moving forward with this, taking in both fixes.

As we've just discussed, we're moving forward with this, taking in both fixes.
@davekaj Could you add the link to the other bug to the comments like @leodasvacas suggested?

@leodasvacas comments have been updated !

authors: Jannis davekaj

repo: graphprotocol/graph-node


text:
Feature request: Add indexer stake information to indexer-cli status output

When running indexer-cli status, display all relevant values from the subgraph on the Indexer to make it easier for the operator to see how much available stake can be allocated, etc

@chriswessels Hi is this useful only for CLI and is there a higher order goal you want to achieve by seeing the stake?  Is browser view useful as well in some cases versus just CLI

repo: graphprotocol/indexer


text:
fix indexer-cli v0.20.11

Running graph indexer status with 0.20.11 causes an error due to the absence of the axios module.
We will therefore fix this with this request.

#596

Looks like CI is failing because the yarn.lock file is missing.
@mattsu2020 could you please add that change as well, please?
Thanks for your PR! :)

@tilacog
yarn.lock added.

We discovered that the root cause of the error was a missing dependency over indexer-common, so I'm closing this in favor of #605.
Thanks for the insight, @mattsu2020!


text:
Performing multiple operations in a single request

How do you send multiple operations in a single request (in rocket for example)?
When I try and execute this query:
mutation a1 {
  doSomething(id: "thing") {
    id
  }
}

mutation a2 {
  doSomething(id: "thing_else") {
    id
  }
}

I get GraphQLError::MultipleOperationsProvided.
There seems to be unit tests to validate this kind of syntax, but no tests of actually running it.
Thanks

I haven't personally used it myself, but support was added in https://github.com/graphql-rust/juniper/pull/171 so perhaps reading that might help.

I found an example from that pull request (sending an array of operation requests).
https://github.com/graphql-rust/juniper/blob/56f71e934be814722d10b0660156cf56b3753470/juniper/src/http/mod.rs#L267
I should've tried that.
thanks!

repo: graphql-rust/juniper


text:
Support custom scalar types

I've toyed a bit around to support custom scalar values in juniper.
The following is some sort of brain dump of the current state.
Adding support for new scalar types that are mapping to existing types seems to be quite easily possible, by reusing existing enum variants in Value and InputValue. Using this approach  it is for example possible to add support for a 16 bit integer type, because we could simply map that to the existing 32 bit integer. On the other hand adding support for types that are not representable by the existing enum variants is not possible. (An Example here would be adding support for 64 bit integers. They would potentially cause overflows in the 32 bit integer enum variant)
I see several ways to "solve" this: (I've not tried any of this so it may work or it may not work)

Add more variants to both enums. So that there is a own variant for each supported type.
This approach has several downsides:

Only a limited set of types could be supported, so if someone want's to introduce a fancy type doing crazy things he will hit the same limit as today
We need to teach the parser when to use which integer type (I think this information should already exist somewhere in the schema)

Use other types in the existing enum variants
Again there are downsides:

What's the correct type to uses? For integers: should we use i64, but what when someone want's to represent a i128 and so on
Again, this is not extensible by some crazy new user defined type

Try to make the schema generic about the exact Value/InputValue type, provide a default Value type (maybe the existing one) and allow users to override this type
Downsides:

Again we need to use more knowledge from the schema in the parser
I would guess this involves at least rewriting bigger parts of the schema and the parser

I would love to here some other opinions on this before trying further to make this work in a nice way.
(This is basically the only remaining open point for wundergraph)
cc @theduke @LegNeato
Related: #198

Thanks for the investigation in this and #198 !
I don't know why, but this still seems "off" to me. It feels like leaking the implementation details / server language semantics into the GraphQL layer. For example, a JS client wouldn't care about i16 vs i32, yet it now needs to care because the server exposes both as scalar types.
Then again, custom scalar types are essentially the server telling the client what the requirements are and the invariants that hold for that field, so maybe it is the right thing to do.
I guess if we define these types in juniper consumers of the lib aren't forced to use them. They could just use the default Int and Float types and it would be as if they were never added.
So, I think I  adding these via a feature flag that defaults to on--similar to the uuid, url, etc integrations--would be a good way forward. That way, if juniper users want to stick to only the scalars defined in the spec and defined by their code they can.
That being said, it sounds like we aren't really set up to handle this case based on your investigations, right? We can treat them as a String but when it hits the Juniper machinery we can't really support things like i128 because at the end of the day the "core" needs to pass a typed value around and there isn't a great way to know in advance what that type should be in the custom scalar case.

Also see https://github.com/facebook/graphql/pull/326

I don't know why, but this still seems off to me. It feels like leaking the implementation details / server language semantics into the GraphQL layer. For example, a JS client wouldn't care about i16 vs i32, yet it now needs to care because the server exposes both as scalar types.

From the perspective of a JS client this is looking like leaking a implementation detail, right. But who says that the Client needs to be JS (and also the transport layer needs to be http with json serialization.)
As far as I understand GraphQL it is not (at least) entirely a thing purely build for webapps but could also  be used in other places. So let's be a bit creative and construct some use cases that would for example benefit from having different integer types:

Using a different serialisation (for example bincode instead of json)
Using a js dialect or a language that compiles to wasm/asm.js for the frontend that can handle
… (More creative examples :wink:)

I guess if we define these types in juniper consumers of the lib aren't forced to use them. They could just use the default Int and Float types and it would be as if they were never added.

If someone does not (want) to use those types they should not be seen anywhere.

So, I think I adding these via a feature flag that defaults to on--similar to the uuid, url, etc integrations--would be a good way forward. That way, if juniper users want to stick to only the scalars defined in the spec and defined by their code they can.

That being said, it sounds like we aren't really set up to handle this case based on your investigations, right? We can treat them as a String but when it hits the Juniper machinery we can't really support things like i128 because at the end of the day the "core" needs to pass a typed value around and there isn't a great way to know in advance what that type should be in the custom scalar case.

After a bit toying around I think the proper solution is to replace the scalar enum variants in Value and InputValue with something generic and let the user decide what exact representation for scalar values should be used.
I've started to implement that here but unfortunately rustc does not like me and eats all my memory 😟

It looks like the spec might be changing soon: https://github.com/facebook/graphql/pull/521

It looks like the spec might be changing soon:  facebook/graphql#521

As far as I understood this proposal this only adds a way to specify that a custom scalar value has the same representation as an existing scalar value. This does not forbid doing something like type BigInt and then using a i64 there. So fundamentally #251 continues to be "required".

This should be fixed after #251 was merged.

authors: LegNeato weiznich


text:
Not working on ie11

Hi,
Thank you in advance. Just wanted to let you know the the web interface not working on ie11.
looks like we need add Array.from polyfill: err:  Object doesn't support property or method 'from'
Thanks again,

The best way to fix this is to use babel-polyfill in your code or bundle the Array.frmo polyfill with your codebase.

Thanks for the note, but graphiql UI code has nothing to do with our UI code base. We use poly-fill but again 2 different codebase.

You would be bundling the graphiql lib somehow. Just load the array polyfill too.

The same is true for MS Edge

Edge has support for Array.from: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/from

I have this error in Edge
SCRIPT1028: Expected identifier, string or number
which is caused by line 226

@shablenko-sednor are you bundling the node module yourself or using one of the pre made CDN bundles? is this with GraphiQL?

our npm main modules have changed targets, with typescript libraries targeting es2018 for native async await, etc. so if you are using those this is expected without bundling. but if you’re using the CDN bundles, graphiql.js or graphiql.min.js then this would be a bug.

While using graphql-language-service-interface 2.3.0 from npm, I see the following code using a default function parameter.
Original Position:
    webpack:///node_modules/graphql-language-service-interface/dist/getDiagnostics.js, Line 35:37

Code Section:
30 |         ];
31 |     }
32 |     return validateQuery(ast, schema, customRules, isRelayCompatMode);
33 | }
34 | exports.getDiagnostics = getDiagnostics;
35>| function validateQuery(ast, schema = null, customRules, isRelayCompatMode) {
                                          ^
36 |     if (!schema) {
37 |         return [];
38 |     }
39 |     const validationErrorAnnotations = mapCat(graphql_language_service_utils_1.validateWithCustomRules(schema, ast, customRules, isRelayCompatMode), error => annotations(error, exports.SEVERITY.ERROR, 'Validation'));
40 |     const deprecationWarningAnnotations = !graphql_1.findDeprecatedUsages

I was expecting the target to be es5 at most, but default function parameters are an es2015 feature. Is that the intended behavior?

yes, please read my comment above

these libraries are isomorphic, so we are exporting them in the most performant and progressive ways possible. adding a module key next go around. downstream bundler config will need to account for this. use @babel/preset-env with your webpack config to set browserslist targets, i can show you how. Targeting es5 would lead to too many sup-optimizations for modern browsers or the node runtime, for the language server

@VassilIordanov if you need more support with this issue, come to our GraphiQL support channel on Discord

@acao I use Angular 8 and upgraded from graphiql 0.12.0 to 0.17.15 and i get the error SCRIPT1028: Expected identifier, string or number in Edge. The problem is with state.prevState = { ...state }; here :
function pushRule(rules, state, ruleKind) {     if (!rules[ruleKind]) {         throw new TypeError('Unknown rule: ' + ruleKind);     }     state.prevState = { ...state };     state.kind = ruleKind;     state.name = null;     state.type = null;     state.rule = rules[ruleKind];     state.step = 0;     state.needsSeperator = false; }
How can i fix this in Angular 8?

you'll need to transpile those modules to the desired browser target. we ship progressively and then you can customize using your bundler

oh hmm, this is usually available in webpack/rollup etc but not in angular CLI i guess:
https://github.com/angular/angular-cli/issues/11892

Is this something you could fix, so that Angular CLI users also can use this library?

I think I will backport a fix for one of our last 0.17.x releases, and just target es5. Is angular CLI consuming the es6 (module) or commonjs (main) modules?  Do the errors show with .esm.js files or just .js files?

Ok, thank you that would be great. Angular cli supports es6 modules. The error I got was only showing in the bundled main.js fils or the vendor.js file. I managed to do a workaround and make it work. If someone else is having this issue maybe this can help.
I added these three lines in angular.json under scripts:
            "scripts": [               "node_modules/react/umd/react.production.min.js",               "node_modules/react-dom/umd/react-dom.production.min.js",               "node_modules/graphiql/graphiql.min.js"             ]
and then in my component instead of importing graphiql I did this:
`declare var GraphiQL: any;
export class GraphQLComponent implements AfterViewInit{
.....
  ReactDOM.render(
    React.createElement(GraphiQL, {
      fetcher: this.graphQLFetcher
    }),
    this.getRootDomNode()
  );

`

https://github.com/graphql/graphiql#browserslistrc our UMD bundle no longer supports IE. let us know if this is an issue, and we can consider a legacy build.
if you need IE11 support, there are ways to configure webpack or other bundlers to achieve this

https://github.com/graphql/graphiql#browserslistrc our UMD bundle no longer supports IE. let us know if this is an issue, and we can consider a legacy build.
if you need IE11 support, there are ways to configure webpack or other bundlers to achieve this

authors: VassilIordanov acao kumarharsh linkan111 mzins psyCodelist shablenko-sednor

repo: graphql/graphiql


text:
allowing for multiple node definitions

I understand there may be better ways to going about this, but I didn't want to disturb too much code. At the moment, in order to build these schemas, you're essentially dealing with massive files, especially when it comes to node definitions. Allowing for different node definitions per different node types I think would greatly allow for further decoupling and modularization of unrelated node types.

Sorry for the long delay with feedback.
Spec mandates single Node so we can't merge this change.

authors: IvanGoncharov elonybear

repo: graphql/graphql-relay-js


text:
Add "website" profile field

In addition to being able to link to my Twitter or Github profiles, I should be able to link to my own website.
The link should include rel=me, so that it is possible to use Gittip as an authentication provider for https://indieauth.com/

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Closing in light of our decision to shut down Gratipay.
Thank you all for a great run, and I'm sorry it didn't work out! 😞  💃


text:
Certain postgres metrics not being reported since upgrade

Sent to Heroku:

Hi,
I was looking at our Librato stats, looks like the read-iops metric is no longer being reported (it always has a value of 0).

To make sure this wasn't a Librato integration bug, I checked the raw logs:

If it helps, we did upgrade our database around that time - could be related to the new version?
Regards,
Paul

@rohitpaulk Maybe browse the list of available metrics in Librato? Perhaps it was simply renamed?

Perhaps it was simply renamed?

The metric is still being reported, with a value of 0.

Mmmm.

Hi Paul,

If your dataset is entirely memory resident that it's not unreasonable that read iops are frequently reported as 0. Additionally, the API we rely on to retrieve the underlying io numbers on these volumes is convoluted and practically eliminates the possibility of acquiring pinpoint accurate numbers. Instead we must rely on proxy metrics like blkio.throttle.io_service_bytes. The iops metrics are most useful in marking out trends and spikes and using this information as a guide when trying to debug performance issues.

Given that your dataset is modest relative to the available cache on your plan I would not anticipate that your instance will consume much in the way of piops until it begins to outgrow the plan. Hopefully this explanation makes the io metrics a little more useful to you.

Let us know if there is anything else we can help with.

Cheers,
Bradley


text:
Remove Jenkinsfile.nightly

Description
This is no longer used.  Nightlies are run via  the vanilla Jenkinsfile with the ROBOTEST_CONFIG variable set.
Type of change

Internal change (not necessarily a bug fix or a new feature)

Linked tickets and other PRs

Completes the work started in https://github.com/gravitational/gravity/pull/2198

TODOs

[x] Self-review the change
[x] Perform manual testing
[ ] Address review feedback

Testing done
https://jenkins.gravitational.io/view/Robotest/job/gravity-try-build/85/
https://jenkins.gravitational.io/view/Robotest/job/Gravity-Nightly/488/
I'll wait to merge until tomorrow, to make sure the 2020-10-08 nightly is clean.
Edit: It is: https://jenkins.gravitational.io/view/Gravity/job/Gravity-Nightly/489/

@a-palchikov You asked me about the CI failures in slack. After some research, I believe those are fixed by https://github.com/gravitational/gravity/pull/2223, which I'm doing extended testing on now.  I have no reason to believe the failures are related to the changes here.

repo: gravitational/gravity