Bash

We want to get Bash up and running in Lind.
Yiwen showed me how it was being used before, and I can compile and run bash (trivially I can have bash --version run and show the version info). He also showed me how to supply a script as arguments.
These are good first steps, but running scripts is failing. Some minor debugging is showing it failing in dup2 which is being supplied with invalid file descriptors.

More specifically it seems like the fd# the ldr is supplying to dup2 as newfd is 255, which doesn't exist (255 here definitely has some significance).
We'll need to test dup further.

The 255 was significant! But not in the way we thought. Bash uses it specifically as a fd trick.
As of now, Bash can now read from a file (whereas is was erroring out on dup2 before), I've been testing with a script that just echos a "hello world". Extremely strangely, its failing to output.
This seems to be a difference in behavior between the nacl-compiled and normally compiled bash.
Running this through normal bash with strace produces
stat("lind_project/hello", {st_mode=S_IFREG|0755, st_size=32, ...}) = 0
ioctl(3, TCGETS, 0x7fff6b5854b0)        = -1 ENOTTY (Inappropriate ioctl for device)
lseek(3, 0, SEEK_CUR)                   = 0
read(3, "#!/bin/bash\n\necho \"hello world\"\n", 80) = 32
lseek(3, 0, SEEK_SET)                   = 0
prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
fcntl(255, F_GETFD)                     = -1 EBADF (Bad file descriptor)
dup2(3, 255)                            = 255
close(3)                                = 0
fcntl(255, F_SETFD, FD_CLOEXEC)         = 0
fcntl(255, F_GETFL)                     = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(255, {st_mode=S_IFREG|0755, st_size=32, ...}) = 0
lseek(255, 0, SEEK_CUR)                 = 0
read(255, "#!/bin/bash\n\necho \"hello world\"\n", 32) = 32
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
write(1, "hello world\n", 12hello world
)           = 12
read(255, "", 32)                       = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0

whereas in Lind with debug level -v we get
[13737,3849512704:09:58:56.708876] Cage 1 NaClHostDescOpen(0x7f86dc012570, hello, 00, 00) returned 0
[13737,3849512704:09:58:56.708888] Entered into open file table at 4
[13737,3849512704:09:58:56.708894] [NaClSysOpen] fd = 15, filepath = hello
[13737,3849512704:09:58:56.708902] Entered NaClSysStat(0x558871bebbc0, 0x100567a8, 0xfffefbd0)
[13737,3849512704:09:58:56.708909] NaClStatAclCheck(0x7fff88817ef0, hello)
[13737,3849512704:09:58:56.709099] [NaClSysLindSyscall] Entered: callNum=3 inNum=1 outNum=0
[13737,3849512704:09:58:56.709113] String argument: ioctl unimplemented
[13737,3849512704:09:58:56.709159] Entered NaClSysLseek(0x558871bebbc0, 15, 0xfffefcb8, 1)
[13737,3849512704:09:58:56.709285] Cage 1 Entered NaClSysRead(0x558871bebbc0, 15, 0xfffefd70, 80[0x50])
[13737,3849512704:09:58:56.709295]  ndp = 7f86dc02c850
[13737,3849512704:09:58:56.709481] Entered NaClSysLseek(0x558871bebbc0, 15, 0xfffefcb8, 0)
[13737,3849512704:09:58:56.709578] [dup2] Entered dup2!
[13737,3849512704:09:58:56.709586] [dup2] cage id = 1
[13737,3849512704:09:58:56.709591] [dup2] oldfd = 15
[13737,3849512704:09:58:56.709597] [dup2] newfd = 255
[13737,3849512704:09:58:56.709686] Cage 1 Entered NaClSysClose(0x558871bebbc0, 15)
[13737,3849512704:09:58:56.709695] Invoking Close virtual function of object 0x7f86dc02c850
[13737,3849512704:09:58:56.709798] [dup2] Entered dup2!
[13737,3849512704:09:58:56.709806] [dup2] cage id = 1
[13737,3849512704:09:58:56.709810] [dup2] oldfd = 255
[13737,3849512704:09:58:56.709813] [dup2] newfd = 1

*** a bunch of reads truncated for brevity ***

[13737,3849512704:09:58:56.715886] Cage 1 Entered NaClSysWrite(0x558871bebbc0, 1, 0xfeff0000, 12[0xc])
[13737,3849512704:09:58:56.715893]  ndp = 558871cb1fd0
[13737,3849512704:09:58:56.715899] In NaClSysWrite(1, hello world
, 12)
[13737,3849512704:09:58:56.715991] Entered NaClSysFstat(0x558871bebbc0, 2, 0xfffef140)
[13737,3849512704:09:58:56.716000] sizeof(struct nacl_abi_stat) = 104 (0x68)
[13737,3849512704:09:58:56.716143] NaClAbiStatHostDescStatXlateCtor: Unusual NaCl descriptor type (not constructible). The NaCl app has a file with st_mode = 0140666. (This is normal for std{in,out,err}, or other inherited/injected files.)
[13737,3849512704:09:58:56.716153] ntered NaClSysMmap(0x00000000,0x2000,0x3,0x22,-1,0xfffef198)
[13737,3849512704:09:58:56.716158]  offset = 0x00000000
[13737,3849512704:09:58:56.716163] NaClSysMmap: rounded length to 0x10000
[13737,3849512704:09:58:56.716169] NaClSysMmap: FindMapSpace: page 0xfefe0
[13737,3849512704:09:58:56.716173] NaClSysMmap: new starting addr: 0xfefe0000
[13737,3849512704:09:58:56.716178] NaClSysMmap: NaClDescIoDescMap(,,0x74e3fefe0000,0x00010000,0x3,0x32,0x00000000)
[13737,3849512704:09:58:56.716191] NaClVmmapUpdate(0x7fff88819670, 0xfefe0, 0x10, 0x3, 0x32, 0, 0x0, 0x0)
[13737,3849512704:09:58:56.716199] NaClVmmapAdd(0x7fff88819670, 0xfefe0, 0x10, 0x3, 0x32, 0x0, 0x0)
[13737,3849512704:09:58:56.716219] Cage 1 Entered NaClSysWrite(0x558871bebbc0, 2, 0xfefe0000, 54[0x36])
[13737,3849512704:09:58:56.716227]  ndp = 558871bf0360
[13737,3849512704:09:58:56.716233] In NaClSysWrite(2, hello: line 3: echo: write error: Bad file descriptor
, 54)
hello: line 3: echo: write error: Bad file descriptor

You can see that there's an extra dup2 going on there! It's dup2(255, STDOUT). STDOUT is getting read only permissions from 255 which it got from the original file, and thus cant write!
I have no idea where this extra dup2 is coming from.

I went back and built a version of Lind from before Jonathan and I started to make changes this summer to see if something we did was causing this weird behavior.
It turns out it is in fact doing the same as above (inserting the extra dup), so I don't believe my changes have affected this. Still extremely weird.
@detectivelyw do you remember seeing anything like above?

So I think the closest checkpoint in our codebase that was able to run some Bash commands is this https://github.com/Lind-Project/native_client/tree/caging, my old "caging" branch of native_client. You probably need to roll back a few commits to make it work with Bash, because in the latest commit I was trying to manually set up some pipes and load in binaries.
And the tests I was able to run are here: https://github.com/detectivelyw/caging/tree/master/experiments/shell_scripts
For example, I ran echo "Hello World!" in script_01, and "ls" in script_04.
There was also an output log that recorded what happened when I ran one of the tests:
https://github.com/detectivelyw/caging/blob/master/experiments/shell_scripts/log/log_01.txt
Many things have changed since then, so it may not work out of the box.
But hopefully this may provide you with some useful info when you debug.

Okay, so I have a backup of our Lind fs that was able to run some Bash scripts:
https://github.com/detectivelyw/caging/tree/master/repy/repy
You could view the linddata files there and see if you are missing anything.
Also, the Bash program and the scripts I tested are here:
https://github.com/detectivelyw/caging/tree/master/repy/repy/test_case/bash
Hope this helps.

So I believe I've tracked this issue down! It seems our glibc IS adding it in!
Following Brendan's advice I used backtrace running gdb on bash to find the area this code was executing, and tracked it down to this macro using some good 'ol printf'ing: #define SET_CLOSE_ON_EXEC(fd)  (fcntl ((fd), F_SETFD, FD_CLOEXEC))
This seemed weird because their still wasn't a dup2, but then I looked into the fcntl implementation in lind_glibc and found this
Seems to have been changed right after Yiwen got it working last time. @detectivelyw did this get changed accidentally at some point? I don't really follow the logic here.

I think this line "result = __nacl_irt_dup2(fd, set_op); " in "sysdeps/nacl/fcntl.c" was added by Joey. I don't remember adding this line myself, and am not sure the logic behind this change. Please feel free to change this line if it doesn't make sense to you. And perhaps this could fix the problem you encountered.

Thanks! It seems like this got caught up in a mixup.
The good news is I changed fcntl in glibc back and now running echo scripts work through lind bash!
I'm still getting some errors running programs that need to fork/exec. So investigating that now.

It seems like this new problem is coming from exec. Also strange behavior. I'm attempting to isolate this using the basic exec test program we had lying around.
Running this program on a working hello.nexe gives the correct output:
#include <stdlib.h>
#include <unistd.h>

extern char **environ;

int main(void)
{
	char *args[] = {"/hello.nexe", 0};
	FILE *fp = stdout;

	fprintf(fp, "environ = [%p]\n", (void *)environ);
	fprintf(fp, "executing: %s", args[0]);
	for (size_t i = 1; args[i]; i++) {
		putc(' ', fp);
		fprintf(fp, "%s", args[i]);
	}
	putc('\n', fp);

	/* execv(args[0], args); */
	execve(args[0], args, environ);

	return 0;
}

However, replacing it with the date program as date.nexe here crashes:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

extern char **environ;

int main(void)
{
	char *args[] = {"/date.nexe", 0};
	FILE *fp = stdout;

	fprintf(fp, "environ = [%p]\n", (void *)environ);
	fprintf(fp, "executing: %s", args[0]);
	for (size_t i = 1; args[i]; i++) {
		putc(' ', fp);
		fprintf(fp, "%s", args[i]);
	}
	putc('\n', fp);

	/* execv(args[0], args); */
	execve(args[0], args, environ);

	return 0;
}

It fails with this error ** Signal 11 from untrusted code: pc=1f6c0101b6c8
Both hello.nexe and date.nexe run correctly independently.

I investigated where the above exec/date program fails and it seems to fail after an mmap call. It is peculiar though that the call returns successfully, and the program SIGSEGV's when returning to the main handler.
This behavior is what is happening when running the ls script through bash. It fails after a sigprocmask not from the call, but when it returns the program handler. I rebuilt glibc reverting back to before we handled sigprocmask but the program is still failing in the same way, but now after the general purpose NaClSysLindSyscall instead of the sigprocmask handler.
I think this behavior from both of these programs is making me believe that the individual syscall implementations aren't the problems. Specifically they're both failing when we go to switcher NaClSwitchSSE, 0 here. I am really unsure about whats really happening here since this is somewhat of the lowest level of NaCl. I'm going to try to get familiar but any pointers would be super helpful.
My plan is also to dig deeper into why the hello.nexe actually works! Because it doesn't make sense that it doesn't fail like the rest of these.

Making some theoretical progress here. Had a lightbulb/facepalm moment.
I'm realizing the ** Signal 11 from untrusted code: pc=1f6c0101b6c81 error is actually the program being run (the untrusted code) faulting in some way, and doesn't have to do with the Lind infrastructure, which is why Lind is stopping in this transitional area. This would mean the bash error and the smaller exec program errors are in fact different.
As for the exec programs, they're faulting because it's trying to do an exec and not a fork exec. I don't think the permissions are there to do this. For example, if I run exec from the command line in docker, it kicks me out of docker. This all makes sense.
Moving to a simple fork/exec program. The program doesn't fault, but it doesn't seem to actually execute the exec'd code. I'm going to start a new issue for this.
I haven't tracked down the bash segfault yet, but hopefully it will be easier now that I somewhat know what I'm looking for.

I've found where Bash is failing, at an xmalloc call in lib/sh/stringvec.c
The variables count and starting_index here are set to 1 and 0 respectively at the point of failure. I'm not sure why xmalloc causes this to fail, but this is true among all Bash scripts that need to fork/exec.
strvec_from_word_list (list, alloc, starting_index, ip)
     WORD_LIST *list;
     int alloc, starting_index, *ip;
{
  int count;
  char **array;

  count = list_length (list);
  array = (char **)xmalloc ((1 + count + starting_index) * sizeof (char *));

  for (count = 0; count < starting_index; count++)
    array[count] = (char *)NULL;
  for (count = starting_index; list; count++, list = list->next)
    array[count] = alloc ? savestring (list->word->word) : list->word->word;
  array[count] = (char *)NULL;

  if (ip)
    *ip = count;
  return (array);
}```

Earlier I traced the above and found that its a specific malloc inside of xmalloc that's failing. We talked a bit about potential sources of why malloc could be failing in yesterdays meeting including investigating brk/sbrk.
One quirk here is that we intercept brk as a syscall, so if it was failing inside/because of brk we would expect to see a log message of Entering Syscall 20 before the failure. However, that's not the case.

I was able to track down the line in malloc where it's faulting using the program counter (w/o the base address, and then subtracting where libc was mmaped) and then used addr2line.
It led me to this line in libc:   arena_get(ar_ptr, bytes);
Talking with Brendan, we started to suspect it may have to do with using malloc with threads.
I ran two tests, one where I malloc until the cage reaches capacity, and the other where I fork and do the same. This didn't seem to trigger any errors.

It was suggested that we substitute malloc in glibc with a library such as dmalloc

It's been a few weeks since I was working on this and wanted to check if any of the fixes in exec changed this at all (was assuming that it wouldn't).
After a rebuild, the same errors are occurring in malloc at arena_get. Now to figure out how to install a debug malloc library. Any suggestions on what to use/how are appreciated.

Brendan directed me to a couple examples of libraries. The plan is to compile these as .so files using nacl_gcc and then add them to linker when compiling nacl programs.
Though that sounds simple enough I'm having all sorts of problems attempting to compile these with nacl_gcc.

I'm now able to debug glibc in gdb! Thanks to Brendan for the help! I've updated the wiki with a bunch of debugging techniques, I think this will be helpful in the future.
GDB is telling me its failing on the arena_get function due to ar_ptr being optimized away. I'm wondering why that is happening.

Brendan mentioned that ar_ptr being optimized away is most likely the compiler deciding for it to live in a register rather than the stack, and not being discarded entirely.
I tried building glibc with -O0 instead of the default -O2 to no avail. Apparently glibc needs optimizations!
My next move is to use the new found gdb-ability to analyze programs previous malloc calls that were successful, and compare that to whats happening where it fails.

I'm actually able to see an address for ar_ptr post crash. It reproducible yields the address 0x36920.
Brendan has asked me to use p $_siginfo._sifields._sigfault.si_addr to find the address it was faulting on, this is also reproducibly the above ar_ptr address (plus the calling cage's base address).
Using gdb x/i to find the instruction it crashes at yields lock cmpxchg %edx,(%r15,%r13,1). Peering into those registers r15 is always the base address for the cage that is calling malloc, and r13 is above mentioned ar_ptr address.
These are the assembly instructions that are happening around the fault:
0xeb2012970d5 	add    %al,(%rax)
0xeb2012970d7 	xor    %eax,%eax
0xeb2012970d9 	nopl   0x0(%rax)
0xeb2012970e0 	mov    %r13d,%r13d
0xeb2012970e3   lock cmpxchg %edx,(%r15,%r13,1)
0xeb2012970e9 	test   %eax,%eax
0xeb2012970eb 	je     0xeb201297140

I've made a bit of progress narrowing this down. Upon further inspection, the $r13 register (which holds the lower bytes of what is ar_ptr) is referencing an address that is 1) outside of glibc's address space within the cage, and 2) not in a region that has r/w permissions. This is causing this to fail. I'm pretty sure this corresponds to the   if(ptr && !mutex_trylock(&ptr->mutex)) line in arena_get and since the pointer (this is ar_ptr) is invalid it all fails.
I created a lighter-weight program that just does a fork + malloc to inspect the behavior overall and look at the value for ar_ptr as well as the register contents throughout execution. This program runs without failure. Whats nice is the asm instructions from the call to malloc in glibc matchup nicely with the one's from the bash-bug so comparing the behavior is much easier.
It seems the error is arising because ar_ptr is being generated at an invalid address. As far as the code goes, I suspect this is due to something going on with tsd_getspecific in ptr = (mstate)tsd_getspecific(arena_key, vptr); \ I'm trying to comb through the asm to see why $r13 is eventually invalid, it seems $rax gets populated by a series of calls that are hard to follow, and then is eventually manipulated into $r13.
The main takeaways here are that in the bug ar_ptr is being incorrectly generated, and that this issue is specific to the bash build.

So the "series of call that are hard to follow" I described above seems to be tsd_getspecific()!
I was able to find the values of registers post-fork by looking at the Lind log at high verbosity. In both my minimal fork/malloc example and in the bash bug, the value of %rax post that function call is equal to the value tls_value1. Since tsd_getspecific seems to get tls values, this seems right!
The thing is, both the working example and bash both return the same value! They maintain the same value in rax until it gets to the insn mov    r13d,DWORD PTR [r15+rax*1] where r15 is equal to the base addr for each programs current child cage. That value shouldn't/doesn't matter since its moving a 32bit address into r13 anyways.
This is where the programs diverge. Post-this instruction, r13 is 0x110e07c0 in the working example, but 0x36920 in the bash bug. The former is a valid address in glibc's memory region, and is r/w. The latter is not!
I'm really not sure why r13 doesn't end up being the same address for both, let alone this non-sensical value.
Anyways, this clarifies a bunch of the periphery and narrows this bug down to this single location. Still unsure of what's causing it though!

Ah, so I misunderstood x86 a bit, but it is indeed transferring into r13 what it should be. This moves what is pointed to at the address [r15+rax*1] ie 0x37f810040a28 where 0x374800000000 is the base address. In the working sample that value is 0x110e07c0 whereas in the bash bug it is 0x36920. The question is why is that value stored there.

Remembering this helpful note that I wrote myself earlier, and its implications with non-det crashes. I inserted some debug lines into Repy and saw Lind behave differently (getting futher in the program but still crashing).
I then looked at the FD table in SafePOSIX and am realizing that we're not replicating the masterfiledescriptor table from cage to cage when exec happens (remembering that our current implementation of exec creates a new cage), this certainly could be the cause of the current problem or at least other problems.
I'm going to focus here for a bit and report back.

Seems like more descriptor havoc. I fixed the SafePOSIX descriptor cloning for exec (which is obviously very necessary) but wasn't the source of this bug. Looking further into FD's it seems that the actual NaCl cage table (which maps program fds to NaCl FDs) isn't being properly replicated upon exec.

Both the SafePOSIX and cagetable bugs are fixed, which are good finds for the long run, but unfortunately were red herrings for the issue at hand.
I'll attempt to write this up now that I have a clearer picture, but it seems that the Vmmap entries are being corrupted during the exec process. The free which it fails upon is actually because its trying to free a string and not a pointer! Looking into the entries it seems like a lot of these are filled with garbage.

Like many bugs, the actual cause of this is misleading. There actually isn't anything wrong with the Vmmap. Instead there was a triggred buffer overflow from some old unused code that used a table called the lib_cache_table. The increase in FDs from bash (I'm opening another issue on fd allocation in a minute) plus a bug in that code was causing NaCl to overwrite memory in a far away location (which ended up being over our memory map).

Ok, well the recent PR fixes that bug.... but bash is still failing. The bug is dead, long live the bug.
But we're past the library loads now! This has to be the final stretch here. More info to come.

The new bug was a minor error on how we parsed the amount of args/env variables. This is fixed now and....
We're able to run ls from bash!!!! ... huge milestone
There is one "final" bug left however. It's going to an infinite wait loop after execution instead of exiting gracefully.

The wait bug seems to stem from a combination of how bash specifically handles waiting for children and a minor bug in the parent/children booking keeping when we use exec.
More specifically the fork's parent process number of children is being incremented a second time upon exec, but isn't being decremented.

So I got it to run ls without the hang! Which I think is the objective of this issue, so I give that a minor hooray.
However, the fix is pretty hacky, and still doesn't fix everything, for example a ls | cat script still hangs.
Going over all this I found several issues in exec wait and the overall infrastructure that I think needs to be fixed for the long term sake of the project. Unfortunately this means its time for a somewhat major refactor which could take some time.

This issue is now waiting for the current refactoring job, documented here.

Continuing to use this thread to talk about some of the bash pipelining issues I'm seeing.
Tracking this down has been sort of a rabbit-hole

I found out that std descriptors were'nt being given cage ids appropriately (FIXED).

I found out that dup2 was breaking because it couldn't differentiate between stdin (fd 0) and a new specified descriptor (as specified in the dup2 manpage). This because our cagetable was using 0 to specify both stdin, and unused descriptors. I changed the infrastructure to use -1 for unused fds, and fixed the dup structure to use that to decide to create a new descriptor. (FIXED)

In SafePOSIX, I found some issues with inodes for pipe and std streams in fstat and dup2. I've opened up some discussion here but made some quicker fixes that have gotten by this, it may be worthwhile to fix completely sooner than later.

Now when running bash I'm seeing some really weird behavior that wasn't uncovered before due to the same cagetable set as 0 problem I described above. It was discussed before that Bash uses this descriptor number of 255 in order to save stdin and such. Now I'm seeing when its trying to restore stdin back to 0 from 255, it can't because immediately beforehand it's closing fd 255, and you can't dup2 a closed oldfd.

This wasn't getting uncovered before because the closed old fd was set to 0... which is stdin. So it was duping stdin to stdin and going on its way, but that's not supposed to happen.
I'm a little lost here, but will continue to dig. My thought so far is that it could be something with CLOEXEC? I'm going to have to dig into bash again and see what the expected behavior is.

I'm not seeing the same behavior when I run bash natively vs in Lind. I have a feeling some of the macros set when compiling with nacl may be different than the native build.
What's making this harder to investigate is the poor fd allocation scheme we have in Native Client, as document in this issue. I'm going to tackle this issue today.

Have had a lot of success over the past two days:

I fixed that native client fd allocation, this not only served to make things easier to compare to native, but I found and fixed the bug I described above as (4) where it was trying to dup a closed descriptor.
I updated how we deal with stream inodes and fstat in SafePOSIX. This seems to have fixed most of the other piping issues!

However my inode fix seems to have broken how I've checked for closed pipe ends to send EOF. So now were actually reading the ls results in cat from our pipe! It's just not seeing that it should end and is getting stuck in a loop.
Regardless, these pretty major updates were needed and we're super close here!

It seems like EOF problem is actually coming from the exec syscall. We've been copying out filedescriptor table (because we're using different cages) but haven't been destroying the old tables. This makes Lind believe there's still unclosed pipe end references.
I'm going to add separate RPC for exec and add exec_syscall to SafePOSIX.

Adding exec_syscall fixed the problem. Pipes are now working properly in bash! I'll PR this soon.
We're still dealing with the wait issue, where it still gets stuck in a loop after execution, so I'll dig into this next.

This issue is closed... for now and hopefully forever.


Export TestHelper?

This is not actually an issue.
The TestHelper.ts file under tests folder is really useful, can it be exported so we can use it in our project?

I can, but...

it depends on fs from node (so it does not work in the browser)
it assumes all files are utf-8 encoded (so you'd better have the correct encoding on your files)
it would mean exporting the d.ts file

Do you really want it exported?

Also, feel free to submit your rules here as a feature request!

Yes, it would be helpful, I would use this file to test my customized rules.
One problem is the rulesDirectroy and formatterDirectory is hard coded, I can only use it if I can specify this option.
And thanks for your offer, I just started working on some react-accessibility rules, waiting for more feedbacks from our project team.

OK, I will export this class. I am also working on some React accessibility rules. I would very much like to hear your ideas. I am going to open a different issue and cc you for a discussion!

Cool, Great to hear, Thanks!

OK, the npm package is now on the https://github.com/Microsoft/tslint-microsoft-contrib/tree/releases
Do you need an npm deployment to use this? Or can you point your package.json at this project's releases branch?

Perhaps I need a npm deployment to use it for our check-in procedure. I would use this releases branch for testing first.
Thank you so much!


Mis-matched text: Beginning / Start

The start page is labelled "Beginning" in the question view and tree view but labelled "Start" in the logic dropdown list.

Potentially also related #3930?

No, this is unrelated. It's just a labelling consistency issue.

Consideration
Now that we've switched from "sections" to "pages" and added early exits, we might consider changing the "start" and "end" concepts to make the page concept more explicit:
Proposal:
EN: Start page // Review page // Confirmation page
FR: Page de départ // Page de révision // Page de confirmation


linked api documentation refers to legacy chain

The api doc linked to in the documentation is for legacy stacks-1.0 branch.  Its misleading to be included in current docs.
https://docs.blockstack.org/stacks-blockchain/install-api
Its linked in the sidebar, here: https://docs.blockstack.org/stacks-blockchain/overview

This was fixed with the chapter redesign. The doc is now inside the "Stacks 1.0" category


Restore fails for netcoreapp5.0 projects

Paket does not like the .NET 5 preview released the other day, in particular it does not recognize netcoreapp5.0 references in paket.dependencies and fsproj files.

Is there also a new netstandard?
kerams<EMAIL_ADDRESS>schrieb am Mi., 18. März 2020, 07:06:

Paket does not like the .NET 5 preview released the other day, in
particular it does not recognize netcoreapp5.0 references in
paket.dependencies and fsproj files.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3811, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAOANAPDLLS2WZUSAITL7LRIBQFJANCNFSM4LOHMANQ
.

I don't see any mention of it in the announcement blog post.

ok it's now part of the new alpha version. Please let me know if it works

Strangely, it doesn't:
Paket version 6.0.0-alpha019
Performance:
 - Runtime: 345 milliseconds
Paket failed with
-> Extracting platforms from path 'netcoreapp5.0' failed, a newer Paket version might support it, otherwise please open an issue for a missing platform handler.

Paket version 6.0.0-alpha019
Performance:
 - Runtime: 119 milliseconds
Paket failed with
-> Error in paket.dependencies line 5
     Could not parse framework 'netcoreapp5.0'. Try to update or install again or report a paket bug.

can you please copy your deps file into this?

group Server
    source https://api.nuget.org/v3/index.json
    framework: netcoreapp5.0
    storage: none

nuget Awssdk.s3
nuget awssdk.simpleemail
nuget fsconfig
    nuget FSharp.Core
nuget fsharp.data.npgsql
nuget fspickler
nuget fspickler.json
    nuget Giraffe
    nuget Fable.Remoting.Giraffe
nuget Google.Apis.Texttospeech.v1beta1
nuget Microsoft.AspNetCore.Cryptography.KeyDerivation
nuget Microsoft.Extensions.Configuration.Ini
nuget prometheus-net.AspNetCore
nuget prometheus-net.DotNetRuntime
nuget serilog
nuget serilog.sinks.console 4.0.0-dev-00839 dev
nuget Serilog.Sinks.Seq 5.0.0-dev-00174 dev
nuget TaskBuilder.fs 2.2.0-alpha alpha

group Client
    source https://api.nuget.org/v3/index.json
    framework: netstandard2.0
    storage: none

nuget elmish.sweetalert
    nuget Fable.Core ~> 3
    nuget Fable.Elmish ~> 3
    nuget Fable.Elmish.Debugger ~> 3
    nuget Fable.Elmish.React ~> 3
    nuget Fable.Elmish.HMR ~> 4
    nuget Fable.React ~> 5
    nuget Fable.Remoting.Client ~> 5
nuget fable.simplehttp
	nuget Feliz.Router
    nuget Fulma
    nuget Fable.FontAwesome.Free
nuget Fulma.Extensions.Wikiki.Checkradio
nuget fulma.extensions.wikiki.tooltip
	nuget Thoth.Json

group Extension
	source https://api.nuget.org/v3/index.json
    framework: netstandard2.0
    storage: none

    nuget Fable.Core ~> 3
	nuget Thoth.Json

group Build
    source https://api.nuget.org/v3/index.json
    framework: netstandard2.0
    storage: none

nuget Fake.IO.Zip
    nuget FSharp.Core
    nuget Fake.Core.Target
    nuget Fake.DotNet.Cli
    nuget Fake.IO.FileSystem

group Tests
    source https://api.nuget.org/v3/index.json
    framework: netcoreapp5.0
    storage: none
nuget expecto.fscheck
nuget expecto.testresults

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp5.0</TargetFramework>
    <LangVersion>preview</LangVersion>
    <PublishTrimmed>true</PublishTrimmed>
    <SatelliteResourceLanguages>en</SatelliteResourceLanguages>
    <UserSecretsId>42dcc4c3-923c-4481-a432-412929bc341a</UserSecretsId>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="CompositionRoot.fs" />
    <Compile Include="Util.fs" />
    <Compile Include="Server.fs" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\WebApiCommon\WebApiCommon.fsproj" />
  </ItemGroup>
  <Import Project="..\..\.paket\Paket.Restore.targets" />
</Project>

so what's the package that's making trouble?

It's not a package-specific problem:
paket restore --project .\src\Server\Server.fsproj
Paket version 6.0.0-alpha019
Performance:
 - Runtime: 120 milliseconds
Paket failed with
-> Error in paket.dependencies line 3
     Could not parse framework 'netcoreapp5.0'. Try to update or install again or report a paket bug.

6.0.0-alpha020 has yet another fix

Looks good now, many thanks!

net5.0
is accepted by the project tooling and likely the future version identifier for .net 5.0 apps
I think I heard @cartermp  talk about it also but not 100% sure.

Yes, net5.0 is the base TFM. There will be net5.0-ios and so on for other TFMs though. You can read about it here: https://devblogs.microsoft.com/dotnet/announcing-net-5-preview-4-and-our-journey-to-one-net/


Move all to modern JS Code

Change Testing and so on to use modern JS Code (ESM Modules instead of CommonJs)

done


Usage when the assets pipeline is disabled

Is it possible to use this gem without the assets? I'm using the Turbolinks npm package, but would like to use the redirection stuff from this gem.
I have a --skip-sprockets project which outputs this on rails s:
rescue in block (2 levels) in require': There was an error while trying to load the gem 'turbolinks'. (Bundler::GemRequireError)
Gem Load Error is: undefined method `assets' for #<Rails::Engine::Configuration:0x007fcf51d04350>

I solved it, but I'm not sure if this is the best way. Any input?
Gemfile
gem "turbolinks", "~> 5.0.0", require: false

application_controller.rb
class ApplicationController < ActionController::Base
  include Turbolinks::Redirection
  ...

Getting same error and I think this is a better solution: #18


Special Attributes

Many times there are attributes you want to include in a POP for utility purposes, but they shouldn't be in the end result(after unpopping). There should be some way to mark certain attributes as special.
This could also replace #1 since you can just add extenders in a pop's extension and mark those attributes as "special", so they get removed when unpopping.
p = pop {
  defaults.value = 0;
  extension = self: super: {
    # Mark increment as "special" somehow
    increment = pop { supers = [ self ]; extension = _: _: { value = super.value + 1; }; };
  };
}
unpop (p.increment.increment) => { value = 2; }

or with #7
pop {
  defaults.value = 0;
  extension = self: super: {
    increment = self { value = super.value + 1; };
  };
}

In terms of the API here are some ideas I'm thinking it could be a list: pop { specialProps = [ "increment" ]; }. And maybe __meta__ and __unpop__ could be part of that list, so unpop doesn't have to know about those, it only has to know about the list of special properties.

In terms of the API here are some ideas I'm thinking it could be a list: pop { specialProps = [ "increment" ]; }. And maybe __meta__ and __unpop__ could be part of that list, so unpop doesn't have to know about those, it only has to know about the list of special properties.


SUBMARINE-523 Fix the wrong path in deepfm.json and fm.json

What is this PR for?
Fix the wrong path
What type of PR is it?
Bug Fix
Todos

[ ] - Task

What is the Jira issue?

Open an issue on Jira https://issues.apache.org/jira/browse/SUBMARINE-523/

How should this be tested?

First time? Setup Travis CI as described on https://submarine.apache.org/contribution/contributions.html#continuous-integration
Strongly recommended: add automated unit tests for any new or changed behavior
Outline any manual steps to test the PR here.

Screenshots (if appropriate)
Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

@arbaobao I help you to add your jira account nelson(arbaobao) to the submarine contribtuion list, and later you can create issues and assign to yourself.


Investigate geotiffjs for streaming COGs instead of tilesets

https://geotiffjs.github.io/
Benefits:

Streaming COGs
Wide format and compression support (stripe, tile)
Supports band/pixel interleave
BigTIFF Support (limited)

Risks:

New Library to test/implement
We will need to use Git LFS (Large File Support) to host such large files

I'm not sure if this is a good path forward at this time.


✨ whitelist dev onboarding app for uid injection

Do not merge this, only merge the staging one Imo.


Port race condition fix

This fix should be ported — it's quite important for algorithm robustness: https://github.com/mapbox/delaunator/pull/25
@fogleman BTW thanks for the port — it looks great!

@mourner Thanks, I'll take a look soon. I wonder if my floating point epsilon checks addressed this.

Looks like my epsilon checks did address this, but I like this approach better - thanks!

@fogleman thanks! I think these are different issues that just happened to overlap for the tested examples — e.g. there could be a case that would corrupt halfedges integrity even with the epsilon check.
Numerical robustness may still be an issue (e.g. see https://github.com/mapbox/delaunator/issues/13) — I just decided not to address it in the library itself (and leave it up to users to e.g. round up the coordinates or multiply by a constant factor).


Update react-onclickoutside to 6.1.0

Fixes https://github.com/YouCanBookMe/react-datetime/issues/331 , which is a total breaking bug.
Description
Pretty minimal change, just version bumping a dependency to get around an issue which react-datetime is imported into another component which is itself being imported.  All of the tests which were already passing continued to pass with the new version.
Motivation and Context
PR should be merged because it fixes an open issue.
Checklist
[ ] I have added tests covering my changes
[x] All new and existing tests pass
[ ] My changes required the documentation to be updated
  [ ] I have updated the documentation accordingly
  [ ] I have updated the TypeScript 1.8 type definitions accordingly
  [ ] I have updated the TypeScript 2.0+ type definitions accordingly

Well that's odd, the Travis build failed with a totally different set of errors than I experienced on my local machine.  Testing further.

Update 2: The plot thickens<EMAIL_ADDRESS>no longer supports create-react-class.  They're surprisingly opinionated about which of their versions matches the proper react versions.  A good amount of this library uses mixins, so migrating to pure classes doesn't seem to be straightforward.  Version 5.11.x is explicitly designed to depend on create-react-class, but it still exhibits the issue shown here.  Looks like there isn't a way to fix that issue without doing a non-trivial refactor such that react-datetime stops using mixins.


Touch No Fire Game Added.

#2505
Description
🎮 Game Request
Game logic and basic description
Game Rules!

Eat the food to gain score
Do not touch the fire
The fire multiplies once with even scores
If you stay idle, the fire won't do anything
Do not touch the moving fire
Please play using arrow keys

Point down the features
Screenshot Section

Demo Video Section
https://github.com/GameSphere-MultiPlayer/GameSphere/assets/154777864/a88f676a-69c8-4cc9-b6e6-98e5fca1aa59
Fixes:  #2505
Type of change

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

Checklist:

[X] I have made this from my own
[X] I have taken help from some online resourses
[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation
[X] My changes generate no new warnings

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK
Screenshot Section

Demo Video Section
https://github.com/GameSphere-MultiPlayer/GameSphere/assets/154777864/a88f676a-69c8-4cc9-b6e6-98e5fca1aa59

@Sulagna-Dutta-Roy please review the PR.

@Sulagna-Dutta-Roy please review the PR.

@Sulagna-Dutta-Roy manifest files mean?

@Sulagna-Dutta-Roy manifest files mean?

Currently the project is a simple project not an extension. So every project should have manifest files. Kindly check other merged PRs

@Sulagna-Dutta-Roy manifest files mean?

Currently the project is a simple project not an extension. So every project should have manifest files. Kindly check other merged PRs

okay

@Sulagna-Dutta-Roy can we make issue on the above game , to change the UI of the Game?

@Sulagna-Dutta-Roy can we rise issue on the above game , to change the UI of the Game?

Nope, it's not possible. You can't raise this but can change the other contributor projects @Anjaliavv51

@Sulagna-Dutta-Roy can we rise issue on the above game , to change the UI of the Game?

Nope, it's not possible. You can't raise this but can change the other contributor projects @Anjaliavv51

okay

@Sulagna-Dutta-Roy please review the PR.

Add the manifest files @Anjaliavv51 Reducing to the level1,as it's an entry level project

@Sulagna-Dutta-Roy  ur request is done
please review the PR.


ISSUES-2553 add offset parameter to numbers

#2535
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

You didn't provide any motivation for this change.
So I have to guess, is it any useful.
At first glance, it seems completely useless,
because the user can always write
SELECT number + 10 FROM numbers(123)

instead of
SELECT number FROM numbers(10, 123)

and proposed change will only make query language more heavy.
It's also non obvious (without reading the docs), what does numbers(n, m) means:

offset and limit;
range begin and end, including end;
range begin and end, not including end.

But finally I found at least some possible motivation for your change (but I leave it for you).

Sorry, I didn't introduce motivation.

At first glance, it seems completely useless,
because the user can always write
SELECT number + 10 FROM numbers(123)
instead of
SELECT number FROM numbers(10, 123)
and proposed change will only make query language more heavy.

You are right, but

SELECT number + 10 AS a, number + 10 AS b ... number + 10 AS n ... is complicated.
numbers(10, 123) can always be rewritten as SELECT number FROM system.numbers LIMIT 10,123 but it's always more efficient

I doubt tgat performance of numbers table can be a bottleneck in some real scenarios.
you can simplyfy such a selects using WITH clause like

with number + 10 as number2
select number2 as a, number2 as b ...```
3) may be it would be better to introduce range/enumerate table function which will support all data types customizable init value and customizable increment step? Like classic `for` keyword in programming languages? For example ```select mondays from enumerate(toDate('2018-08-25'), x -> x <= toDate('2018-12-31'), x -> x + INTERVAL 7 DAYS)```

I doubt tgat performance of numbers table can be a bottleneck in some real scenarios.
Yes, if you use LIMIT m, n you will have unnecessary wait offset, and if you use number + m ... LIMIT n you will have unnecessary operations, like '+'
you can simplyfy such a selects using WITH clause like
That's great
may be it would be better to introduce range/enumerate table function which will support all data types customizable init value and customizable increment step? Like classic for keyword in programming languages? For example select mondays from enumerate(toDate('2018-08-25'), x -> x <= toDate('2018-12-31'), x -> x + INTERVAL 7 DAYS)
Good idea, but the implementation is complicated, but I'll try : )


PHPStan 1.8.3 breaks our test

Description
Please see https://github.com/nunomaduro/larastan/runs/8146438432?check_suite_focus=true
non-falsy-string ✨

and the nightly cron job: https://github.com/nunomaduro/larastan/runs/8147274082?check_suite_focus=true

Fixed. Thanks.

Now older PHPStan does not like non-falsy-string
Will we raise its version contstrain to ^1.8.3 ?


Get statistics from verification engine

Is there any way to get the statistical data of verification processes from verification engine directly (e.g. verified procedures ) or turn infer into a sound verification tool?
BTW: How can I run infer on SPEC CPU 2000 whose building system is customized with a wrapper called runspec? It seems "--force-integration" doesn't work.

@slight-code, what kind of analysis are you interested in having the list of verified procedure?

BTW: How can I run infer on SPEC CPU 2000 whose building system is customized with a wrapper called runspec? It seems "--force-integration" doesn't work.

Infer does not support third party build systems but we will happy to help with PRs adding this kind of integration.


Susan/formsand sample page updates

Loader to show Sample processing

Take off authentication fields from User create and edit forms

Remove sample memory and job queue field for non-admins

Rerun sample if Pipeline run failed

In general, looks good. See comments about rerun. I don't know where the rerun button is enabled but the logic needs some work.
Also, after sample creation, it redirects to /samples, which is bad. It should go to / instead. /samples is kinda backdoor path for developers to debug.
thanks,


[Fonts] Icon request: lock_reset

Hi @Hassan6197, the lock_reset icons already exist on stable. See https://api.flutter.dev/flutter/material/Icons/lock_reset-constant.html
Closing this as the icon already exists.


fixed XSS bug in tags.

Please submit your pull requests to the 'dev' branch.
When submitting a pull request, please make sure you have completed the following checklist:

[x] Your code is flake8 compliant (Dojo's code isn't currently flake8 compliant, but we're trying to correct that)
[ ] If this is a new feature and not a bug fix, you've included the proper documentation under the /docs folder

@aaronweaver Can you review it. Some commits have checks failed due to difference in requirements.txt in master and dev branch .


ImageStacks file parser implementation

Currently imagestacks uses the order OS provides. THere are reports of cases where MacOS does not seem to sort the files by filenames by defaults, or skips files during selection of large number of files.
A filename parser that will sort filenames will be good to mitigate these issues.

closed via #132


beforeChange is not fired?

MyCode:
<CodeMirror
         value={script.code}
         options={{
           mode: 'javascript',
           theme: 'solarized light',
           lineNumbers: true,
           extraKeys: {
             Alt: 'autocomplete',
           },
           hintOptions: {
             word: script.dictionary,
             hint: this.handleShowHint,
             completeSingle: false,
           },
           highlightSelectionMatches: { showToken: /\w/, annotateScrollbar: true },
         }}
         onChange={this.handleCodeChange}
         onUpdate={this.handleDomChange}
         onBeforeChange = {this.handleBeforeChange}
       />

I don't know what kind of React wrapper you are using here, but CodeMirror's own interface, editor.on("beforeChange"), seems to work fine.

onChange is fired


Add 'defaultWait' timeout setting

Closes #13
This also makes a couple breaking changes, so look over those (see CHANGELOG.md) and let me know what you think!

Thx for the PR!

Woohoo! :+1:  My pleasure.  Looking forward to using the new features :smile:

@mltsy published in 0.4.0

Yay! :tada: ... Oh, maybe you meant it will be published in 0.4.0 - looks like 0.4.0 isn't available via npm yet?

@mltsy I did try to publish it but I fired a yarn publish and forgot, checked this morning and it was still publishing... Anyway should be published now (with npm publish this time)

Oooh, hah strange!  Awesome, thanks :+1:


internal/operator-sdk/run|cleanup: initial boilerplate

Description of the change:
Adds hidden run bundle and cleanup bundle commands with flag and bundle parsing boilerplate.
Motivation for the change:
To initialize a new package to be use for the run bundle command and enable progress on implementation to be made in parallel.
Checklist
If the pull request includes user-facing changes, extra documentation is required:

[ ] Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
[ ] Add or update relevant sections of the docs website in website/content/en/docs

/hold
We might want to put this on a feature branch at least until 1.0 is released. WDYT?

/hold cancel


onInactive is not even triggering in android

Upon using the npm, onInactive is not even triggering in android..plz help

same here :((

same here :((


Use TypeScript type references for Autocompletions

Is there any way, that TabNine could use the type definitions from TypeScript for using it in the suggested list of functions and properties for the Autocompletion?
Actually types will be referenced in TypeScript but also JavaScript files like this,
/// <reference types="Cypress" />

VisualStudioCode can read such types reference and provide a better Codecompletion.
I actually use TabNine within VIM and it would be great, when TabNine would support this feature.

You should upload the screeshot for difference.

This is how it looks in VSCode. In VIM only the following functions were suggested

In Vim, semantic completion doesn't work.

Hm.  It can be support in Tabnine?
It should be supported in LSP level.

I also thought that semantic completion should be possible because of the LSP. But I'm not sure about how to read the link to the reference file and if it could be imported.

VisualStudioCode can read such types reference and provide a better Codecompletion.

It does not mean LSP supports the feature.

This is out of scope for TabNine, but if you can find a language server that supports this feature I can include it in TabNine's default configuration.

I was trying to find out how it's working in VSCode. But it seems that it's part of the communication between client and server when using the LSP.
https://microsoft.github.io/language-server-protocol/specification#textDocument_typeDefinition
So when Typescript or also JavaScript files will be loading and the client find some reference definitions it could ask the server about a link where the typedefinition can be found. To be honest I don't have enough knowledge about how it's working in details and what is the role of TabNine here.


Support for Passing Backstage Token on Request

Description
In Backstage version 1.28.0, the default value of the proxy's credentials field was changed to require from dangerously-allow-unauthenticated, meaning that all requests must include a valid Backstage token.
This update causes the Sysdig plugin requests to return a Status 401 (Unauthorized) error when using the proxy settings defined in the documentation.
Current Workaround:
The quick fix for this issue is to update the proxy configuration with credentials: dangerously-allow-unauthenticated. This solves the problem but also opens up the proxy to unauthenticated users.
proxy:
  endpoints:
     '/sysdig':
       target: ${SYSDIG_SECURE_ENDPOINT}
       changeOrigin: true
       allowedMethods: ['GET']
+      credentials: dangerously-allow-unauthenticated
       headers:
         "Authorization": "Bearer ${SYSDIG_SECURE_TOKEN}"
         "Content-Type": "application/json"
         "Accept": "application/json"
         "X-Sysdig-Product": "SDS"

Proposed Solution:
A better solution would be to add support for the plugin to include a valid Backstage token with each request. This can be done by using the Backstage FetchApi.fetch() method instead of the standard fetch().
References:

Backstage FetchApi
Backstage Version 1.28.0 Release Notes

After a day of troubleshooting this workaround fixed my issue

Hi, Thanks for the MR fixing this.
Just tested it and it works fine 🚀


[WIP] Bug snagging

[x] UK citizen validation on sign skews page:
https://www.pivotaltracker.com/story/show/98640970
[x] Sponsor message on email confirm:
https://www.pivotaltracker.com/story/show/98637502
[ ] Sponsor limit:
https://www.pivotaltracker.com/story/show/98647724
[ ] 6th (or more) sponsor to sign after moderation:
https://www.pivotaltracker.com/story/show/98638702

Don't merge until all boxes are ticked

Updated to address @alexander-bobin's comment


feat: introducing Qs&As, reddit like tiny platform

PR feat:
Introducing tiny reddit like platform where people can ask questions or post something and people can reply.
In the prisma Schema two models are seperated (questions,answers) because with single recursive model it would be hard to get recursive answers.

Resolves #[Issue Number if there]
Checklist before requesting a review

[x] I have performed a self-review of my code
[x] I assure there is no similar/duplicate pull request regarding same issue
[x] I assure that the build i working in local

are you thinking off adding a subreddit sort of thing as well, if yes then till which depth. @siinghd.
Something like this also engages community quite much : https://codeforces.com/blog/entry/127903

are you thinking off adding a subreddit sort of thing as well, if yes then till which depth. @siinghd. Something like this also engages community quite much : https://codeforces.com/blog/entry/127903

This is just like that, looks same as that

@hkirat veere can you look at this?

wow nice
are these attached per video?
or is this a global thing?

@hkirat this is global thing, i think for video we could just expand the comments. We already have different type of comments.
In this somehow we could reference the video... like github does with pr's

Can we put this behind a globally configurable feature flag @siinghd ?
Happy to merge it but need to be able to disable it quickly if there are bugs

Maybe generally add a frontend feature flag functionality if possible

@hkirat sure let me do it

@hkirat  should be done, maybe its dumb but i have added env var NEXT_PUBLIC_DISABLE_FEATURES = "featurea,featureb,featurec"
if you add qa or QA, basically you disable it, from server side it will redirect the user to '/'. if you are not in the page actions also can't be used i think. let me know if this is what u were thinking
Maybe u also want to disable some things on clientside (like conditional rendering) thats why the env is with NEXT_PUBLIC

MMMM build has some problems with const session = await getServerSession(authOptions), let me check

@hkirat ok veere should have fixed the build, idk why there were issues with session types and other types but should be working now.
But do check one time https://github.com/code100x/cms/pull/436/commits/5e0429ee98c0818991f74baaf84280fe21789491

/bounty $600
Will be testing after merging


[CARBONDATA-1895] Fix issue of create table if not exists

Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[ ] Any interfaces changed? No

[ ] Any backward compatibility impacted? No

[ ] Document update required? No

[ ] Testing done
Already add test case in project.

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/710/

retest this please

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/716/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/1943/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2271/

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/1953/

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/725/

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/1955/

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/727/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/750/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/1978/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2300/

retest this please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/1982/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/752/

Please modify the description of the PR

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2360/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2050/

retest this please

retest this please

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/838/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2064/

LGTM


Issue running script on macOS 14.4

Problem Description
python path issue on macOS Sonoma 14.4
Other experiencing the issue here: https://github.com/elegantthemes/create-divi-extension/issues/490
Steps To Reproduce

Using node 21.7.1 and python 3.12.2
running the provided command inside the plugins folder.
Script fails look for python path.

Screenshot and/or gif

Looks like you're experiencing the well known node-sass issue. https://github.com/elegantthemes/create-divi-extension/issues/621
I solved it on my end by using node version 14.4.0 using the nvm package: https://github.com/nvm-sh/nvm

Cheers! Not currently looking to downgrade node as I was only fooling
around with this anyway.
Thanks
Sam Kobe
Designer/Developer
@.***
+1<PHONE_NUMBER>
On Mon, 25 Mar 2024 at 13:03, Andrew Robbins @.***>
wrote:

Looks like you're experiencing the well known node-sass issue. #621
https://github.com/elegantthemes/create-divi-extension/issues/621
I solved it on my end by using node version 14.4.0 using the nvm package:
https://github.com/nvm-sh/nvm
—
Reply to this email directly, view it on GitHub
https://github.com/elegantthemes/create-divi-extension/issues/683#issuecomment-2018811995,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAE2PYT43OUBOIJPBXHNIFTY2B7JLAVCNFSM6AAAAABFGOK4DWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJYHAYTCOJZGU
.
You are receiving this because you authored the thread.Message ID:
@.***>


Wrap CMATRIX for gRPC

Resolves issue #571
Closes #571

A few notes:
PR Naming
PRs need to have descriptive names.  Include the issue resolved within the PR notes and not in the title.  I've changed this to match the correct style.
Wrapped CMATRIX Method
We need to run the non-interactive part within the method that we're wrapping.  There's no point in wrapping a method unless we're also going to do the leg work making the method easy to run.  As such, we need to change the following:
https://github.com/pyansys/pymapdl/blob/0ef7b24a53ef890ed5e0d42e7533806acd5fc654/ansys/mapdl/core/mapdl_grpc.py#L1636-L1637
to:
# The CMATRIX command needs to run in non-interactive mode as the server redirects output.
if not self._store_commands:  # check if already in non-interactive mode
    with self.non_interactive:
        super().cmatrix(symfac, condname, numcond, grndkey, capname, **kwargs)
        # Output stored in cmatrix.out
        self._response = self._download_as_raw('cmatrix.out').decode()
        return self._response

# otherwise, simply run cmatrix as we're already in non-interactive
super().cmatrix(symfac, condname, numcond, grndkey, capname, **kwargs)

This does two things.  First, we're checking if we're running in non-interactive.  We don't want to enter it twice (and in fact, open a new issue to add a check to see if we're already running non-interactive when initially entering non-interactive), so if we're already non-interactive, we just fire off the command and it gets placed in the command queue.  The output won't be captured there anyway, so we won't worry about returning the last response.  Otherwise, we return the output.
This was implemented in commit 70b6f17c94e5a9e374b70267857c84f0d2b3df66.

Unit Testing
I went ahead and closed #589.  New unit tests must be added in the PR that adds the new feature.  It's best to practice Test Driven Development.
As such, your unit test should be in the tests/test_grpc.py file.  Additionally, your unit test needs to:

Use existing fixtures so we avoid starting/stopping mapdl in or outside of devops
Be as simplistic as possible

Commit 70b6f17c94e5a9e374b70267857c84f0d2b3df66 also moves the unit test here.  Note how we're using the mapdl fixture defined in conftest.py to manage mapdl, and then creating a new fixture to run the setup for cmatrix.  Each unit test should test one method, so all the setup for the method needs to be outside of the unit test.
Also note that the unit test covers both possible branches of the method.  We test if it works outside of a non-interactive context, which is how we expect the user to use it, but we also test it within the non-interactive context as it's an edge case we have to account for (albeit unlikely).
With this approach, we know that any feature we add is fully covered by our testing and we don't need a separate PR to verify that our feature works.

CI/CD is failing because the image appears to have an issue with running CMATRIX on the docker image.  With docker running locally it's failing outright with:
MapdlInvalidRoutineError: *** WARNING ***                         CP =       1.785   TIME= 18:53:31
 CMATRIX is not a recognized SOLUTION command, abbreviation, or macro.

I'm rebuilding the image locally to verify this.

Found out the error with CMATRIX.  There are a ton of MAC files I've neglected to copy over to the docker image.  I'm regenerating and we'll use this PR to bump the docker image.

PRs need to have descriptive names. Include the issue resolved within the PR notes and not in the title. I've changed this to match the correct style.

I should have realized this way before.

We need to run the non-interactive part within the method that we're wrapping. There's no point in wrapping a method unless we're also going to do the leg work making the method easy to run.

To be honest, I thought about it. Quite a bit, but since other problematic commands are not being wrapped I thought the consensus was to not "hide" that from the user. Now I know I will do that from now on. So my wrapper was just fixing the output in the last_response .. I know... Simple.
I think I mentioned somewhere before that we could create a wrapper (decorator?) for this type of functions, call it @only_non_interactive_execution for example. So we can apply it for all the functions (assuming similar issues/solutions for all of them).
Does it make sense?


RTD build error

Log is here:
https://readthedocs.org/api/v2/build/7863347.txt
Currently cannot find any real reason for the build failure. Gotta investigate more.

No, there's nothing obvious in that report, is there.
Is this since 10bfc9b943e47a3ef0ba69ae46d544cadbee8623 ?  I did include some special Unicode characters in a print-string. Could that have been it?
     print('ψ0 = {} (cf. exact = 1/64 ≐ {})'.format(Psi0, 1/64))

Yes, it's after I added the new example. I still didn't figure it out. Since there are no error messages, I probably have to just remove parts of the example and try whether it compiles. It works on my local machine well enough.,

I'm now planning the switch to hosting static Sphinx generated HTML-files in a separate repository using Github Pages. The code for generating the docs will remain here but the build directory will be in a separate repository, e.g. scikit-fem-docs. Through GH pages, this will be hosted at https://kinnala.github.io/scikit-fem-docs/.

This is now done.


[AlignPoints.py] cannot align points for open contour

Traceback (most recent call last):
  File "AlignPoints.py", line 55, in <module>
  File "AlignPoints.py", line 27, in _adjacentPointsThatAreOffCurve
IndexError: tuple index out of range

Was having this issue a couple days ago, but my latest version should work fine.


How can I retrieve downstream raw audio data for post-processing and later send it using WebRTC

How can I retrieve downstream raw audio data for post-processing and later send it using WebRTC

I would also be interested on how to get access to raw audio data for pre and post-processing.


Adds trash tag to more items

Some janitors ingame noted they couldn't pick up banana peels or cigarette butts so went through and added trash tags to more items that needed it (and removed it from paper as identified in my other PR).
This is a stop gap until decision is made on #6166 in maintainer meeting as janitors need this now to function better but there is some overlap in the two PRs.
:cl:

fix: Trashbag can now pick up banana peels, cigarette ends and more!

Review addressed. Had similar issue in the original PR with shotgun cartridges not inheriting from parent because it has its own tag component.


authenticate endpoint doesn't response error (401) to invalid credentials provided

Bug Report
iRODS Version, OS and Version
4.3.1, almalinux8
What did you try to do?
For the server running with the basic authentication scheme configured, posted wrong credentials to the authenticate endpoint to get the token.
[irods@dev-u0137480 go-http-client]$ curl -X POST -u rods:wrong-pass http://localhost:9000/irods-http-api/0.1.0/authenticate
[irods@dev-u0137480 go-http-client]$

Expected behavior
An error code in the client side and some also some logging in server.
Observed behavior (including steps to reproduce, if applicable)
Nothing observed. Should the authenticate endpoint response with error (401) to invalid credentials provided?

I couldn't reproduce this with other languages. Probably I am not using curl correctly. Therefore closing this.

Please share what you see with the -v verbose option.

I am getting what I should :)
*   Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 9000 failed: Connection refused
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to localhost (<IP_ADDRESS>) port 9000 (#0)
* Server auth using Basic with user 'rods'
> POST /irods-http-api/0.1.0/authenticate HTTP/1.1
> Host: localhost:9000
> Authorization: Basic cm9kczpodW50ZXI=
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Server: irods_http_api/0.1.0 [38d67aa5ab798952450dc4429c20d82586a375e8]
< Content-Type: application/json
< Content-Length: 0
<
* Connection #0 to host localhost left intact


Create main.yml

Add WINUI3 GitHub Workflow for ShelterVault

Current configuration uses WinUI3 Packaged.
GitHub workflow for WinUI3 only works with WinUI3 single-project MSIX.


GitHub is used as a CDN - should we change that?

I saw this reference:
https://github.com/choldgraf/jupyterhub-sphinx-theme/blob/f97104c11cae55869ddc8394eb83594bd5c7d075/src/jupyterhub_sphinx_theme/__init__.py#L17-L21
Should we host this logo ourselves somewhere? But if so, where?

we could vendor it with this package I think, would that work?

Ah, sounds like a good choice if we can make it possible technically!

Ideally this theme should be usable by people who block cross-domain resource requests- I've met quite a few developers who do this. This also means this theme would work in security focussed enterprise environments with strict firewalls.


[stable/k8s-spot-termination-handler] Add missing 'namespace'

The 'namespace' wasn't set for daemonset and serviceaccount.
Signed-off-by: Kai Forsthövel<EMAIL_ADDRESS>
Is this a new chart

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

What this PR does / why we need it:
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[ ] Title of the PR starts with chart name (e.g. [stable/mychartname])

@kforsthoevel
Would you mind to bump the chart version to latest please? Thank you.

@zanhsieh - I have bumped the version from 1.4.6 to 1.4.7 already. Or am I missing something here? Sorry, it's my first PR for this repo.

@kforsthoevel
Yes, this PR need another bump to 1.4.8 due to fast iteration (unfortunately).

/ok-to-test

@zanhsieh
Is there anything else I need to do? Thanks.

@axozoid
@egeland
@kierranm
@mariusv
Would you guys LGTM this PR please?

/assign @mariusv

/lgtm


[posix] fix fall-through error

Good to have the break. But maybe it's not fix since it does not actually change behavior?

I agree. I removed the bug label earlier, because this is not really a bug.


#15 Make demo page accessible for public

You can see sample here : https://mazipan.github.io/vue-rangedate-picker/demo/
Just set for gh-pages to master branch

Fix for issue #15


Update show-features.py

Updated with f strings for enhanced readability.

Checklist

[x] No CHANGELOG update needed

[ ] No new tests needed

[ ] No documentation update needed

has been addressed in #1353
Thanks for all your work, @ggold7046. These were still helpful to validate what happened in #1353!


Codes in markdown is omitted

Markdown source file:
# Time Schemes

## Implicit Time Schemes

### BDF

### Comparative Study

- `YuMeilin-2019arXiv-CompareRosenbrock_ESDIRK_BDF`

## Multigrid Methods

Html output:

YuMeilin-2019arXiv-CompareRosenbrock_ESDIRK_BDF is omitted in the html file.
markmap-lib version:
$ markmap --version
0.4.2

As a workaround, you can escape symbol with the backslash like this `

fixed in 4301e9cf558855065c444740623c4cc1b308d286 , without style yet


No 'EntryPoint' attribute generated for namespace functions

Given the following header:
namespace N {
   int f();
}

the generator fails to add mangled name to the DllImport attribute. Don't really know what am I doing, but the following change seems to make it work:
diff --git a/sources/ClangSharp.PInvokeGenerator/PInvokeGenerator.VisitDecl.cs b/sources/ClangSharp.PInvokeGenerator/PInvokeGenerator.VisitDecl.cs
index 097e5df..97bac12 100644
--- a/sources/ClangSharp.PInvokeGenerator/PInvokeGenerator.VisitDecl.cs
+++ b/sources/ClangSharp.PInvokeGenerator/PInvokeGenerator.VisitDecl.cs
@@ -464,10 +464,10 @@ namespace ClangSharp
             }

             var callingConventionName = GetCallingConvention(functionDecl, callConv, name);
-            var entryPoint = !isVirtual && body is null
-                ? (cxxMethodDecl is null) ? GetCursorName(functionDecl) : cxxMethodDecl.Handle.Mangling.CString
+            var isDllImport = !isVirtual && body is null;
+            var entryPoint = isDllImport
+                ? (cxxMethodDecl is null) ? functionDecl.Handle.Mangling.CString : cxxMethodDecl.Handle.Mangling.CString
                 : null;
-            var isDllImport = body is null && !isVirtual;

             var desc = new FunctionOrDelegateDesc<(string Name, PInvokeGenerator This)>
             {

This looks correct. Namespace level declarations don't have a lot of coverage today.

Do you mean the current code is correct? Namespace is just a single example, the mangled name in the EntryPoint is required for any function not in extern "C" block.

I meant your suggested fix is correct. This was missed because there is not significant coverage for many C++ concepts, one of which is namespace level function declarations.
Most users tend to bind over C libraries, not C++ ones, because there are many potential ABI problems and incompatibilities that can come out for C++.

Thanks for clarifying! Can it be simplified to:
var entryPoint = isDllImport ? functionDecl.Handle.Mangling.CString : null;

?

Yes, I believe it can, provided all the existing tests pass anyways

The tests will fail, I guess, because the tool defaults to C++, as per ClangSharpPInvokeGenerator help output, but tests assume C source code if they pass without this change now :)
BTW, could you bump .NET versions for tests? I can't run them on Linux because all I have here is .NET Core 5, and running dotnet tests results in
Testhost process exited with error: It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '3.1.0' was not found.
  - The following frameworks were found:
      5.0.7 at [/opt/dotnet_core/shared/Microsoft.NETCore.App]

BTW, could you bump .NET versions for tests? I can't run them on Linux because all I have here is .NET Core 5, and running dotnet test results in

Never mind, I was stupid, dotnet test accepts --framework option. But now I can't run tests because of #246.

@tannergooding, am I right that the proper fix requires:

This change.
Teach tests to select input language for code fragments and set it to "C" for some.
Change some "expected" text fragments to include the "EntryPoint" property.
Teach libClangSharp to select mangling scheme to run Windows tests on Linux and vise-versa
Set mangling scheme for tests

Or is there a simpler way?


Download dataset error

python ./example/run_mujoco.py --task Goal2

How to address it?

@Chenrf1121 thanks for catching this. Our server was down. Just fixed it.


homebridge installed on MacOS not working after update to 0.4.39 depend of HW config

Hi,
In my case config is Mojave with internet sharing homebridge installed on.
Update after 0.4.38 does not work.
Main differences between those two builds is node_modules.
in 0.4.38 it use mdns.
since 0.4.39 it use bonjour-hap.
In case of installing homebridge on a Mac connecting to this server it works up to last build.
Fred

Sorry, seems to be same issue as #1843

Close then.

No, there is a real issue when using with 2 Ethernets/wifi  connection.
Should it be possible to add option in config.json to tell homebridge to listen on en0 en1 bridge ...?
Fred

After many test I can say that this bug is not in Homebridge.
At the moment I just can say that, hap is not shown in Bonjour Browser when using 0.4.45 rev.
Trouble is either in hap-nodes or bonjour-hap.
now searching how to get debug log of those 2 modules.

So after some investigations.
The issu is in hap-nodejs. it can't create hap. alone.
if I run homebridge 0.4.38 on one Mac and run Homebridge 0.4.45 on another one, it works
So closed


Add a "simple" test case to verify the mean() good behavior

Quite simple test verifying the good behavior of the mean() function.

The point of this library is not to test InfluxDB. What are you trying to do here?

yeaaah sure ;)
that's for the same reason than the others tests with a server instance running:  it ease to detect change of format response from the server..
and as far as it's possible to use a real server instance then I find it far better than using mock of requests package..
no more, no less ;)

The point of this library is not to test InfluxDB

the point is of the library is to offer a python client library to query an influxdb server.
So I find that actually testing the good behavior of this client library when used against a real server is the best thing to actually test the client itself. don't you think ?

I will rebase it once https://github.com/influxdb/influxdb-python/pull/142 as been merged. this one also needs it because of last server update..

Using a function does not affect the response format,  so you are not testing anything meaningful here. The library does not do anything different because you have used mean in your query.
This test would make sense in the InfluxDB repository if you wanted to test that 30 +60+30 / 3 = 40

Using a function does not affect the response format

hmm, it might be, but that's not necessarily (always) the case.. The server could use different formatting function(s) depending on the query and what it contains..
but you're right that this kind of tests could (or should) also be part of the server test itself..

this kind of tests could (or should) also be part of the server test itself..

For the reasons stated above, I think that it should only be part of the server So I will not merge this.


Name the new row a row, not a column

Hi @lcorneliussen, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

Thank you!


Box station TEG is designed to troll players

Description
The Box Station TEG is designed to troll (especially new) players due to:

Burnbox is tiled in floorthat when crowbared turn into in individual steel rods that are very hard to pick up without replacing the floor, and you can often accidentally click on them if you don't pick them up as they leave diagonal jail bars. Additionally this floor hides the pipes to anyone not using a T-Ray, and obscures the fact that the burnbox radiator does absolutely nothing. This is FRUSTRATING.

The burnbox radiator does nothing. Nothing at all. Radiators require flow in order to do the temp delta, so a radiator on a random pipe loop doesn't do anything. If you have no experience with radiators you will get very frustrated why the way the game shows you to use them doesn't work.

The external cooling loop also does nothing! Did radiators used to work on still gas? This is a trap for new players as they will assume they can just slap radiators on and they will work. They will get frustrated because the game lied to them about how a mechanic functions.

Time to setup a functional TEG is extended significantly due to the scutt work of having to crowbar up floor, collect all the tiny rods one by one, unwrench all the bad pipes, weld them all down to bare steel, ghostplace and build your real setup, realize you need more steel and run out and look for it while the whole station yells at engineering for not making power etc. etc. Obviously frustrating.

There is a one-click grief valve for your atmosyndie/shitter to open and equalize the hot and cold sides if you don't remove, which is HILARIOUS and therefore should NOT be changed, no cap.

Reproduction

Go to Box station as an atmos/engi
Set up the TEG under time pressure, don't worry the whole station is counting on you
Drag the welding fuel in from engilounge just so you can finish welding your hoard of pipes.
Realize that it is, indeed, frustrating for literally no reason

Screenshots

Why
Additional context
Honestly this wasn't as troublesome before the AME nerf, but now it's more important to have secondary power running, and important to have it faster. Because of this, the pain of this setup is really obvious and honestly needs rework.
If suggestions are welcome, I would like to present an alternative bare setup that encourages rather than trolls the players:

I would be happy to update map with permission from the map-master.

go ahead

every ss13 ported map is like this

every ss13 ported map is like this

I did not realize this. That would fully explain why the layout is how it is, as I believe radiators didn't need flow in SS13.
After quick investigation I noted maps that need a TEG rework because of the same issue:

[ ] Fland
[ ] Bagel
[ ] Marathon
[ ] Packed

All the others appear to not have the same issue and are updated/originally made to be radiator-aware!


Fail to load ELF for exe

I am running benchmark program GemsFDTD_base.gcc in spec06
I tried the following command : hotpatcher -l ./Release/libhotpatchtest.so -s mysym -vvv 15912
(15912 is the pid of GemsFDTD_base.gcc )
I got the following result:
Options Given:
Verbose Level: 2
Process PID: 15912
Symbol name: mysym
Library name: ./Release/libhotpatchtest.so
Dry run: false
[exe_load_headers:490] Entry point 0x3408048db0
[exe_load_headers:510] Error in loading section headers
[exe_load_symbols:539] Unable to load Elf details for /proc/15912/exe
[hotpatch_create:197] Unable to find any symbols in exe.
[hotpatch_inject_library:594] No malloc/dlopen found.

Sorry, just saw this. What operating system are you running here ?


Sync Zoom and Liner markers on Dotplots & Spectrum Viewers

This PR syncs the axis limits and vertical line marks on the spectrum and dotplots.
Stage 3 gives an example of how to activate and deactivate linking using a reactive (computed in this example).
Common logic for linking two variables with some transformation between them is handled in a function sync_reactives in the hubbleds utils.
This does not adjust the story guidelines or apply the appropriate sequencing.

I can't speak to the back end logistics, but on the user side, this is looking very much improved!! I noticed a few lingering wonky things:

If you zoom in to a region of the dot plot, the spectrum view zooms to the correct corresponding range. If you click "reset" in the dot plot, that zooms the dot plot back out to the full range, but the spectrum graph zooms out to this funny partial range.  (If you do the same thing in reverse, i.e. starting with the spectrum graph, the dot plot does zoom back out correctly).

These next few issues can be seen in the bottom screenshot:

We should use the same "reset" icon in both graphs. (In the dot plot, it's a double arrow; in the spectrum viewer it's a single arrow).
The order of the icons should be the same in both graphs. I think what makes sense is put them in the order we present them to the students in the guidelines, then make the dotplot icon order match (where they are in common).
In the spectrum viewer, we should have a vertical line to mark the measuring tool (like we do in the dot plot viewer). I thought it used to be a vertical line, but now I'm getting a double-headed horizontal arrow, which does not show a clear x-value.

Merging this since it is now mostly working. Will move any lingering tasks to a new issue.


Add find initial PR from current commit text

This fix the problem described here https://github.com/Azure/azure-rest-api-specs/pull/228 of the lack of comments in the initial PR when it's merged.

LGTM!


Add project level content trust case

Add project level content trust testcase

Coverage increased (+0.02%) to 64.538% when pulling 6019aeececa532d6790d6e994dc909a8f81fe2b9 on sigsbee:content into b537ea96f3bcc5b9fc7d485e797613efa699e45b on vmware:master.


[Change Request] table 5645 "FA Date Type" - procedure InsertRec

Hello, can you please change the procedure InsertRec in table table 5645 "FA Date Type" as global?
    procedure InsertRec(FAEntryNo: Integer; FADateTypeNo: Integer; FADateTypeName: Text[80])
    begin
        "Entry No." := FAEntryNo;
        "FA Date Type No." := FADateTypeNo;
        "FA Date Type Name" := CopyStr(FADateTypeName, 1, MaxStrLen("FA Date Type Name"));
        Insert();
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 10134.


win10 install error

The more we know about your system and use case, the more easily and likely we can help.
Environment info

OS: win10 (1709)
App Version (Command/Ctrl + ,):Lepton.Setup.1.5.2-alpha-2.exe

Description of the problem / feature request / question:
i run Lepton.Setup.1.5.2-alpha-2.exe,  and no gui display, in windows event manager i found error:
http://<IP_ADDRESS>/1.png
http://<IP_ADDRESS>/2.png
i test another windows7, it works well, have compatibility for win10?
thanks.

AFAIK, there is no compatibility issue for win10 so far. What about having a try for Lepton-1.5.1-win.7z?

hi, hackjutsu ,
thanks for your reply, i have test Lepton-1.5.1-win.7z, it works normal.


could this template add Microsoft Cordova-Simulate support?

Cordova-Simulate is  Microsoft's plugin can Simulates Apache Cordova application in the browser.
https://github.com/Microsoft/cordova-simulate
if add this plugin,we can debug some native api function in the browser.

hey @kiler398, could you help us about how to import this application into cordova-template-framework7-vue-webpack template?

I find a solution to use  Microsoft Cordova-Simulate
if we install a cordova-tools plugin in vscode,we can use Microsoft Cordova-Simulate  for your template
https://marketplace.visualstudio.com/items?itemName=vsmobile.cordova-tools

Great idea @kiler398 I made your tip in README file :)


Implement "localbeach:upgrade" command

Essentially this is:

docker-compose -f /usr/local/lib/beach-cli/localbeach/docker-compose.yml stop
docker-compose -f /usr/local/lib/beach-cli/localbeach/docker-compose.yml pull
docker-compose -f /usr/local/lib/beach-cli/localbeach/docker-compose.yml start

May rather call this ´beach restartinstead? And with an optional--remove` flag?

Note: beach restart exists by now (see https://github.com/flownative/localbeach/commit/e5c5d1b53e0da2d9fbaa62e5c314aaf140cb0e42 and https://github.com/flownative/localbeach/commit/66c4e75ae150a1463a641a98e9c5fa16c80defa6), but does not target the reverse proxy and database server.

beach down && beach start currently does what's necessary to upgrade. So maybe we don't need this command at all.


[Bug]: If backup restored with deviating coinType, account creation throws errors

Issue description
When a backup is restored with deviating coinType, account creation throws the following error:
Error:  {
  type: 'invalidCoinType',
  error: 'invalid coin type for new account: 1, existing coin type is: 4218'
}

Version
develop
Expected behaviour
The account manager should create accounts with the coinType specified in the options if the ignoreIfCoinTypeMismatch is passed.
Actual behaviour
Error is thrown
Can the issue reliably be reproduced?
Yes
Steps to reproduce the issue
Stronghold file to reproduce error with:
firefly-cointype-4218.stronghold.txt
Script to reproduce error with:
/**
 * This script throws the error
 */
const path = require('path')
require('dotenv').config({ path: path.resolve(__dirname, '.env') });
const { AccountManager } = require('@iota/wallet');
async function run() {
    try {
        const accountManagerOptions = {
            storagePath: './restore-database',
            clientOptions: {
                nodes: [{url: 'https://api.testnet.shimmer.network', disabled: false}],
                localPow: true,
            },
            coinType: 1,
            secretManager: {
                stronghold: { snapshotPath: './restore-database/wallet.stronghold'},
            },
        };

        const manager = new AccountManager(accountManagerOptions);

        // Add the path to the file from example 5-backup.js
        // for example: ./backup/2021-02-12T01-23-11-iota-wallet-backup-wallet.stronghold
        const path = ''//"input your backup file"
        await manager.restoreBackup(path, 'dp&79S!vZAsyaC4Ia3VL', true, 'rms');
        const account = await manager.createAccount({alias: 'Alice', bech32Hrp: 'smr'});
        console.log('Account:', account.getMetadata().alias);
        console.log('Addresses:', await account.addresses());
    } catch (error) {
        console.log('Error: ', error);
    }
    process.exit(0);
}

run();

Errors
Error:  {
  type: 'invalidCoinType',
  error: 'invalid coin type for new account: 1, existing coin type is: 4218'
}

Duplicate declaration

[X] I have searched the issues tracker this issue and there is none

The coin type in the backup is 1, but the account has coin type 4218 :thinking:
Looks like you created the account with 4218, and then later created a wallet with coin type 1 and then this backup
So I guess we should check the account type when the wallet is created with existing accounts to prevent this from happening

You can "fix" the backup by creating the AccountManager with another cointype after it got restored and then do a new backup
    /**
     * This script throws the error
     */
    const path = require('path')
    require('dotenv').config({ path: path.resolve(__dirname, '.env') });
    const { AccountManager } = require('@iota/wallet');
    async function run() {
        try {
            const accountManagerOptions = {
                storagePath: './restore-database',
                clientOptions: {
                    nodes: [{ url: 'https://api.testnet.shimmer.network', disabled: false }],
                    localPow: true,
                },
                coinType: 1,
                secretManager: {
                    stronghold: { snapshotPath: './restore-database/wallet.stronghold' },
                },
            };

            const manager = new AccountManager(accountManagerOptions);

            const path = 'firefly-cointype-4218.stronghold'
            await manager.restoreBackup(path, 'dp&79S!vZAsyaC4Ia3VL');
            await manager.destroy()

            // Create wallet again, but with 4218 coin type and create a new backup
            const accountManagerOptions2 = {
                storagePath: './restore-database',
                clientOptions: {
                    nodes: [{ url: 'https://api.testnet.shimmer.network', disabled: false }],
                    localPow: true,
                },
                coinType: 4218,
                secretManager: {
                    stronghold: { snapshotPath: './restore-database/wallet.stronghold' },
                },
            };
            const manager2 = new AccountManager(accountManagerOptions2);
            const newBackupPath = "new-firefly-cointype-4218.stronghold"
            await manager2.backup(newBackupPath, 'dp&79S!vZAsyaC4Ia3VL')
            await manager2.destroy()

            // Delete db and restore the new snapshot, this time account creation will work
            const fs = require('fs');
            fs.rmSync('./restore-database', { recursive: true, force: true });
            const manager3 = new AccountManager(accountManagerOptions2);
            await manager3.restoreBackup(newBackupPath, 'dp&79S!vZAsyaC4Ia3VL');
            const account = await manager3.createAccount({ alias: 'Alice', bech32Hrp: 'smr' });
            console.log('Account:', account.getMetadata().alias);
            console.log('Addresses:', await account.addresses());
            console.log(await manager3.getAccounts())
        } catch (error) {
            console.log('Error: ', error);
        }
        process.exit(0);
    }

    run();


OCommandExecutorNotFoundException on simple record copy

Hi,
I am using Orient 2.0.5 and trying to make the copy example work. Here's my command:
insert into User from ( select from Tenant where @rid = #12:0 )

This produces the following error:
Error: com.orientechnologies.orient.core.command.OCommandExecutorNotFoundException: Cannot find a command executor for the command request: sql.( select from Tenant where @rid = #12:0 )

Record #12:0 is in database. User class is a simple class without any properties defined or restricted (i.e. just a shell).

Remove parenthesis

However this isn't the first time the very same report happens. Can we check the docs about it? Or maybe support also this syntax?

That worked very well, thank you!

Hi @lvca,
There's another problem which I stumbled upon right away. I'd like to return @rid or @this after query executes, but apparently I cannot do that.
insert into User from (select from Tenant where @rid = #12:0) return @this

gives initial error and the the other one without parenthesis
insert into ActionLog from select from Tenant where @rid = #12:0 return @this

throws the following at me:
Error: com.orientechnologies.orient.core.sql.OCommandSQLParsingException: Error on parsing command at position #38: Invalid keyword 'RETURN'
Command: select from Tenant where @rid = #12:0 RETURN @this
----------------------------------------------^

What do i do?

Hi @luigidellaquila,
Regarding my question above. Is there any workaround that I can use in this case?

Hi @andreyvk
have you tried this?
insert into ActionLog return @this from select from Tenant where @rid = #12:0

Hi @luigidellaquila,
That works well actually. Thanks!


no plugins from default oh-my-zsh repository  install

Type:

[x] Bug
[ ] Enhancement
[ ] Feature Request
[ ] Question

zplug --version: 2.4.2
zsh --version: zsh 5.1.1 (x86_64-ubuntu-linux-gnu)
uname -a: Linux [...] 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

everything else seems to work.


custom resolution in iframe

Ability to set a custom X and Y resolution for the iframe, but have it visually scale back to fit the window. This would allow for screenshots to be taken at a pre-defined resolution.

Added a Dropdown with some common square choices, the artworks should just auto-size within them if they aren't square.


@svgr/webpack v6.1 - fails due to a duplicate default export

🐛 Bug Report
Build fails with svgr/webpack & url-loader due to:
ERROR in ../../libs/ui/src/lib/components/Toggle/on.svg 40:7
Module parse failed: Duplicate export 'default' (40:7)
File was processed with these loaders:
 *<EMAIL_ADDRESS> * ../../node_modules/file-loader/dist/cjs.js
You may need an additional loader to handle the result of these loaders.
| export { ForwardRef as ReactComponent };
| export default __webpack_public_path__ + "assets/svg/on.3827650.svg";
> export default __webpack_public_path__ + "assets/svg/on.3827650.svg";

To Reproduce
Steps to reproduce the behavior:

Install<EMAIL_ADDRESS>Setup webpack similarly to the config below
Export an SVG as follows:

export { ReactComponent as StarIcon } from './star.svg'
export { default as StarIcon } from './star.svg'

Consume them in the app you're building

Webpack loaders:
{
   module: {
     rules: {
        test: /\.svg$/i,
        oneOf: [
          {
            issuer: /\.[jt]sx?$/,
            use: [
              {
                loader: '@svgr/webpack',
                options: svgrConfig
              },
              {
                loader: 'file-loader',
                options: {
                  limit: 10000, // 10kB
                  name: '[name].[hash:7].[ext]',
                  outputPath: 'assets/svg'
                }
              }
            ]
          },
          {
            type: 'asset/resource',
            generator: {
              filename: 'assets/svg/[name].[hash][ext][query]'
            }
          }
        ]
     }
   }
}

Expected behavior
Should not error, just as previous versions - works as expected on 6.0.0
Link to repl or repo (highly encouraged)
Please provide a minimal repository on GitHub.
Issues without a reproduction link are likely to stall.
Run npx envinfo --system --binaries --npmPackages @svgr/core,@svgr/cli,@svgr/webpack,@svgr/rollup --markdown --clipboard
Paste the results here:
## System:
 - OS: macOS 12.0.1
 - CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
 - Memory: 2.36 GB / 32.00 GB
 - Shell: 5.8 - /bin/zsh
## Binaries:
 - Node: 16.13.0 - /usr/local/bin/node
 - Yarn: 3.1.0 - /usr/local/bin/yarn
 - npm: 8.1.0 - /usr/local/bin/npm
## npmPackages:
 - @svgr/rollup: 5.5.0 => 5.5.0
 - @svgr/webpack: 6.1.0 => 6.1.0

Have the same issue even if I downgrade the version to 6.0.0. I use a custom loader as a work around.
export default function (source) {

  // Apply some transformations to the source...

  return source.replace(/export default .*\n/, '');
}

webpack.config.js
use: [
                            {
                                loader: path.resolve(__dirname, './removeDuplicateExportLoader'),
                            },
                            {
                                loader: require.resolve('@svgr/webpack'),
                                options: {
                                    titleProp: true,
                                    // typescript: true,
                                    exportType: 'named',
                                    svgo: false,
                                },
                            },
                            {
                                loader: 'file-loader',
                                options: {
                                    name: 'images/[hash].[ext]',
                                },
                            },
                        ],


Fix cargo audit in CI

Description
This PR fixes cargo-audit panic in CI by downgrading cargo-audit to the previous minor version.
Related Issue(s)

Closes #894

Type of Change

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update
[ ] Other (please describe):

Checklist

[X] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have run cargo fmt and cargo clippy to ensure my code is formatted and linted correctly
[ ] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

awesome!


Homepage update

I just downloaded and loaded this version of the website. It looks really nice! My only comment is the "Learning gem5" link on the main page is broken. This should  be fixed.

Thanks!