Fix xml navigation on xml union type

Purpose
Fixes #28692
Approach
Remove the check for union type in the TypeChecker for the xml navigation expression, because union type is allowed here in the checkExpr call for the expr in the navigationExpr guarantee that the expr is of the subtype xml.
Samples
Remarks
Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[x] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

The spec says.

XML navigation expressions allow for convenient navigation of XML element structure, in a similar way to XPath.

One way to interpret this is that XML navigation is supported only for XML values with the xml:Element subtype. In a scenario where an XML value has the type xml:Comment|xml:Text, it seems okay to issue a compile-time error, as users wouldn't be able to find anything useful from such an operation. wdyt? @MaryamZi

Was not able to add a test with an xml element sequence due to this bug

@MaryamZi Do we need to remove diagnostic from DiagnosticErrorCode and compiler.properties files?

Yeah, we can remove. Just need to leave the rest of the diagnostic codes (and IDs) as they are.

The spec says.

XML navigation expressions allow for convenient navigation of XML element structure, in a similar way to XPath.

One way to interpret this is that XML navigation is supported only for XML values with the xml:Element subtype.

If we do this, we'll be disallowing access on xml also, won't we?

In a scenario where an XML value has the type xml:Comment|xml:Text, it seems okay to issue a compile-time error, as users wouldn't be able to find anything useful from such an operation. wdyt? @MaryamZi

The spec says for the expression, "The static type of the expression must be a subtype of xml.".
So from a spec point of view this is OK. Also when we perform the access on non-element XML values, we get an empty sequence rather than an error, so if at all, I think we can give a warning to say it will always be an empty sequence (I don't think we need to), but we shouldn't be giving an error.

Was not able to add a test with an xml element sequence due to this bug

Can't we work around it with something like
xml<xml:Element>|xml:Comment x = <xml<xml:Element>> xml `<a></a><b></b>`;

?


ESP-IDF windows build error (IDFGH-11499)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
5.0
Operating System used.
Windows
How did you build your project?
Command line with Make
If you are using Windows, please specify command line type.
None
What is the expected behavior?
build my project and flash
What is the actual behavior?
an error while building
Steps to reproduce.

create any project
run cmd esp idf
run idf set-target esp32
...

Build or installation Logs.
Determining if the include file sys/types.h exists failed with the following output:
Change Dir: F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp

Run Build Command(s):E:/Software/ESP32/tools/ninja/1.10.2/ninja.exe cmTC_1f413 && [1/2] Building C object CMakeFiles/cmTC_1f413.dir/CheckIncludeFile.c.obj
FAILED: CMakeFiles/cmTC_1f413.dir/CheckIncludeFile.c.obj
E:\Software\ESP32\tools\xtensa-esp32-elf\esp-2022r1-11.2.0\xtensa-esp32-elf\bin\xtensa-esp32-elf-gcc.exe   -mlongcalls -Wno-frame-address -o CMakeFiles/cmTC_1f413.dir/CheckIncludeFile.c.obj -c F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c
F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10: fatal error: "/sys/types.h: Invalid argument
    1 | #include <sys/types.h>
      |          ^~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

Determining if the include file stdint.h exists failed with the following output:
Change Dir: F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp

Run Build Command(s):E:/Software/ESP32/tools/ninja/1.10.2/ninja.exe cmTC_51311 && [1/2] Building C object CMakeFiles/cmTC_51311.dir/CheckIncludeFile.c.obj
FAILED: CMakeFiles/cmTC_51311.dir/CheckIncludeFile.c.obj
E:\Software\ESP32\tools\xtensa-esp32-elf\esp-2022r1-11.2.0\xtensa-esp32-elf\bin\xtensa-esp32-elf-gcc.exe   -mlongcalls -Wno-frame-address -o CMakeFiles/cmTC_51311.dir/CheckIncludeFile.c.obj -c F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c
F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10: fatal error: "/stdint.h: Invalid argument
    1 | #include <stdint.h>
      |          ^~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

Determining if the include file stddef.h exists failed with the following output:
Change Dir: F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp

Run Build Command(s):E:/Software/ESP32/tools/ninja/1.10.2/ninja.exe cmTC_eaac6 && [1/2] Building C object CMakeFiles/cmTC_eaac6.dir/CheckIncludeFile.c.obj
FAILED: CMakeFiles/cmTC_eaac6.dir/CheckIncludeFile.c.obj
E:\Software\ESP32\tools\xtensa-esp32-elf\esp-2022r1-11.2.0\xtensa-esp32-elf\bin\xtensa-esp32-elf-gcc.exe   -mlongcalls -Wno-frame-address -o CMakeFiles/cmTC_eaac6.dir/CheckIncludeFile.c.obj -c F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c
F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10: fatal error: "/stddef.h: Invalid argument
    1 | #include <stddef.h>
      |          ^~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

Determining size of time_t failed with the following output:
Change Dir: F:/ESP_project/hello_world/build/CMakeFiles/CMakeTmp

Run Build Command(s):E:/Software/ESP32/tools/ninja/1.10.2/ninja.exe cmTC_2814e && [1/2] Building C object CMakeFiles/cmTC_2814e.dir/TIME_T_SIZE.c.obj
FAILED: CMakeFiles/cmTC_2814e.dir/TIME_T_SIZE.c.obj
E:\Software\ESP32\tools\xtensa-esp32-elf\esp-2022r1-11.2.0\xtensa-esp32-elf\bin\xtensa-esp32-elf-gcc.exe   -mlongcalls -Wno-frame-address -o CMakeFiles/cmTC_2814e.dir/TIME_T_SIZE.c.obj -c F:/ESP_project/hello_world/build/CMakeFiles/CheckTypeSize/TIME_T_SIZE.c
F:/ESP_project/hello_world/build/CMakeFiles/CheckTypeSize/TIME_T_SIZE.c:24:22: error: 'time_t' undeclared here (not in a function)
   24 | #define SIZE (sizeof(time_t))
      |                      ^~~~~~
F:/ESP_project/hello_world/build/CMakeFiles/CheckTypeSize/TIME_T_SIZE.c:26:12: note: in expansion of macro 'SIZE'
   26 |   ('0' + ((SIZE / 10000)%10)),
      |            ^~~~
ninja: build stopped: subcommand failed.

F:/ESP_project/hello_world/build/CMakeFiles/CheckTypeSize/TIME_T_SIZE.c:

#undef KEY
#if defined(__i386)
# define KEY '_','_','i','3','8','6'
#elif defined(__x86_64)
# define KEY '_','_','x','8','6','_','6','4'
#elif defined(__PPC64__)
# define KEY '_','_','P','P','C','6','4','_','_'
#elif defined(__ppc64__)
# define KEY '_','_','p','p','c','6','4','_','_'
#elif defined(__PPC__)
# define KEY '_','_','P','P','C','_','_'
#elif defined(__ppc__)
# define KEY '_','_','p','p','c','_','_'
#elif defined(__aarch64__)
# define KEY '_','_','a','a','r','c','h','6','4','_','_'
#elif defined(__ARM_ARCH_7A__)
# define KEY '_','_','A','R','M','_','A','R','C','H','_','7','A','_','_'
#elif defined(__ARM_ARCH_7S__)
# define KEY '_','_','A','R','M','_','A','R','C','H','_','7','S','_','_'
#endif

#define SIZE (sizeof(time_t))
static char info_size[] =  {'I', 'N', 'F', 'O', ':', 's','i','z','e','[',
  ('0' + ((SIZE / 10000)%10)),
  ('0' + ((SIZE / 1000)%10)),
  ('0' + ((SIZE / 100)%10)),
  ('0' + ((SIZE / 10)%10)),
  ('0' +  (SIZE    % 10)),
  ']',
#ifdef KEY
  ' ','k','e','y','[', KEY, ']',
#endif
  '\0'};

#ifdef __CLASSIC_C__
int main(argc, argv) int argc; char *argv[];
#else
int main(int argc, char *argv[])
#endif
{
  int require = 0;
  require += info_size[argc];
  (void)argv;
  return require;
}

More Information.
nothing

@coderboyisongithub  Hi, I have met similar issue resent times on windows, the Header files can't find are all in tool chain, they must be here. Root issue is almost from RF/LF line ending format of windows, so:

what you mean command line? windows CMD or powershell or wsl?
what line-ending-format you have set for your git

Please don't mix using different terminal on windows.
For my way, I deleted all files in esp-idf folder, then git reset --hard HEAD~1 to let it Re-checkout all files, then is pass the build. because it must be some files is in different format, but we don't know which one, So we can simply refresh them all again. If not mind, you can also follow my step, then all git options are as normal

How did you installed your ESP-IDF? Did you used the Windows Installer?

fatal error: "/sys/types.h:

/ is put before the includes. It is like it would try to locate those includes in the root directory (which doesn't exist on Windows, of course). I don't think I've seen this before but maybe the the include paths are not properly set. So I would also check your first step, create any project. What kind of project is that? How did you make it? With idf.py create-project (https://docs.espressif.com/projects/esp-idf/en/release-v5.0/esp32/api-guides/tools/idf-py.html#start-a-new-project-create-project)? Or have you copied an example project (https://github.com/espressif/esp-idf/tree/release/v5.0/examples)? Does building any of these produce an issue?

Closing this issue due to lack of response.
@coderboyisongithub if you are still experiencing this issue then please feel free to re-open the ticket.

it was happening because I was using windows 11 preview beta(from insider program).It was unstable os not updating env variables while installation .I re installed the os with stable build and it works as according to documentation


Allow specifying the version name with Renv install

Currently, when using Renv install, the name of the version stored in ~/.Renv/versions is taken from the version number, such as 3.2.3. This adds support for changing the version name. This is useful when creating versions for different projects, where you might want the same version number but want to isolate the packages installed into those versions.
This feature is already available when running R-build as a standalone program. Here, I'm adding the feature to R-build when called as an Renv plugin.

Thanks!


Node partly draggable

Is there any way to make a node partly draggable? So if I for example have a node like a post it note. I would like to resize it using re-resizable og something similar. However, due to the draggable feature of a node i cannot resize the node, without the node is dragged simultaneously. However, I would still like to drag the post it, but only, when the user is hovering over the correct spot on it. Kind of like: https://react-latest-ui.github.io/react-sticky-notes/.

Not the maintainer, but you should be able to prevent dragging by adding the nodrag class to any element inside a custom node - https://reactflow.dev/docs/api/node-types/ (see "Prevent dragging & selecting"). That class can be added to the re-resizable handle classes so only the handles will ignore the drag (see sandbox).
Example sandbox (sorry if messy, forked something else i had done): https://codesandbox.io/s/white-waterfall-qy9o1?file=/src/App.js

Arh thats great! thank you very much for a precise answer!

@wernst can i ask where you read about the nodrag class, I cannot seem to find it in the documentation?

@Keanottesen  https://reactflow.dev/docs/api/node-types/ (see "Prevent dragging & selecting")


@Skiars are you still there?

@Skiars PR are piling up and I have a few of them more. Can you please give me commit/admin rights?

All done.


Restore script isn't restoring ini.d correctly

It is close to be fixed, the operation is generating a folder "init" within the folder init.d

Comment on issue


Solving issues and removing old files from the repo

This PR addresses the closed issues 23-25, 28-31, 33-35 and 37

There is a slight issue which should be taken care of at some point. In order to not have to rewrite the API configuration I uploaded one example graph to the data directory, rather than using the test/data directory. I described it more thoroughly in the issue linked below.
https://github.com/Workflomics/pubmetric/issues/47#issue-2608352976


Feature: (Soft) Require Solid Density for Substance.solid()

Various unrealistic behaviors were noticed for solids that resulted from their densities automatically being set to 1.
A simple example would be adding an arbitrary quantity, say 50 grams, of an arbitrary solid substance, say NaCl, to a container. The container would report a volume of 50 mL, but in reality NaCl has a density of around 2.17 g/mL, so the actual volume taken up by the salt would be ~23 mL.
To address these problems, both the Substance() constructor and Substance.solid() have been given an additional parameter, density, to allow for this value to be specified for both currently supported phases of matter (solids and liquids).
However, there are cases where a user may not know the density of a solid, or it may not be required for setting up their experiments (e.g. when the solid is in a very dilute solution, and the concentration in said solution need not be precise). To allow for these cases, Substance.solid() can still be called without providing a density. Doing so will trigger a warning for the user to inform them of the risks associated with not providing a density, which they can either choose to ignore or choose to address by providing a density.
As one might expect, the unit test code responsible for creating solids was refactored to provide solid densities. This broke some of the strict equalities present on many of the assert statements, so a number of these were adjusted to include a call to pytest.approx(). The two example files were also updated to include solid densities for Substance.solid().
Additional cleanup changes that were made to Substance:

Unused concentration attribute was removed.
Constructor argument value checking was improved - unsupported molecule types will now trigger a ValueError.
Constructor now requires a molecular weight and density, both of which must be positive (for now, the door for infinite density and molecular weight has been left open, but this may be removed if deemed appropriate).
Repeated code across Substance(), Substance.solid(), and Substance.liquid() was consolidated (the latter two functions simply call the constructor with the appropriate phase of matter).

Additional changes that were missed in previous features:

The two example files contained references to the functions Recipe.create_container() and Container.dilute(), both of which were removed in the Container rework feature pull request. These examples were updated to reflect the current state of the library.
The default enzyme density parameter was not removed from either the Config class or pyplate.yaml. The parameter has now been removed from both files.

Checks have passed, so this branch will now be merged and deleted.


Gamma distribution reports NA for standard error estimate; warn user; solution is rescale data

For some extreme sets of data, the gamma distribution reports NA for the standard error. Eg.]
library(ssdtools)
test.csv <- textConnection(
"dummy  ,  Conc  ,  Units
all  ,  0.1  ,    ug/L
all  ,  0.12  ,  ug/L
all  ,  0.24  ,  ug/L
all  ,  0.42  ,  ug/L
all  ,  0.67  ,  ug/L
all  ,  0.78  ,  ug/L
all  ,  120  ,  ug/L
all  ,  2030  ,  ug/L
all  ,  9033  ,  ug/L
all  ,  15000  ,  ug/L
all  ,  15779  ,  ug/L
all  ,  20000  ,  ug/L
all  ,  31000  ,  ug/L
all  ,  40000  ,  ug/L
all  ,  105650  ,  ug/L")
test <- read.csv(test.csv, header=TRUE, strip.white=TRUE, as.is=TRUE)
ssd_fit_dists(test, dists="gamma")
reports
Fitting of the distribution ' gamma ' by maximum likelihood
Parameters:
estimate Std. Error
scale 9.695693e+04        NaN
shape 1.642224e-01 0.04142257
Estimates of scale and shape are ok, but it was unable to compute a standard error for the scale parameter. This appears to be a scaling problem in inverting the hessian. The standard error for the scale parameter is about 67000 and the se for the shape is .04. So the vcov will have terms on the order of 67000^2 and .04^2 which vary by 2.8 x 10^12 (!) so I suspect that it is a numerical issue
If you rescale the data
factor=100
test2 <- test
test2$Conc <- test2$Conc/ factor
ssd_fit_dists(test2, dists="gamma")
all is well
Fitting of the distribution ' gamma ' by maximum likelihood
Parameters:
estimate  Std. Error
scale<PHONE_NUMBER><PHONE_NUMBER>
shape   0.1641717   0.0454135
The pdf for the gamma has a term x/s so if you multiple x by a factor k and multiply s by a factor of k, the pdf is unchanged except for the change in the scale factor.
I would advise user if any estimates have NA for the standard errors and advise them that a rescaling may be appropriate. We could make a specific message for each distribution, i.e. typically advise gamma users to divide by a factor k, or a generic message and the user needs to try both multiplying or dividing the data by a factor until message "disappears".
Estimates are ok, so estimates of HCx are ok. Bootstrapping used to compute SE for HCx so this should also work fine.
Carl

done


seeding in HH example

In the current HH example (https://www.mackelab.org/sbi/examples/00_HH_simulator/), we seed the simulator inside the simulator function:
https://github.com/mackelab/sbi/blob/main/examples/HH_helper_functions.py#L56-L59
As correctly pointed out by Umberto Picchini (@umbertopicchini, thank you very much for pointing this out!), in this case, there is no variability across simulations for the same parameter set, which is not the setting we really want and is also not in agreement with our own numerical experiments. I suggest we correct this in the tutorial:
(1) remove the optional seeding inside the simulator function;
(2) seed pytorch at the beginning of the notebook (https://github.com/mackelab/sbi/blob/main/examples/00_HH_simulator.ipynb), e.g.
seed_torch = 1
torch.manual_seed(seed_torch)
(3) rerun the notebook to update the results.

I made a PR here. Unfortunately, there is no great solution. When using multiprocessing (as we do in the example), seeds can get messed up. The clean solution would be to always pass a seed around and save the seed for every simulation, but this can not be achieved with the simple interface (as it would consider the seed a part of the parameter space and would do inference over it). Instead, I decided to not seed the simulator for our example.


New Components: Command & Combobox

Hi, @huntabyte
First things first, you're awesome. Thanks for cmdk-sv. Truly grateful.
I went ahead and started using Command, (even though it's still a W.I.P), and honestly, everything works perfectly, at least for my small use-case.
That said, there are a few warnings, and wanted to let you know about them in case you missed it. If already know, please discard this.
Command.Dialog isn't "aware" of loop & label props
I tried passing the loop and label props like so:
<Command.Dialog bind:open={$command} loop label="Navigation Menu">
...

but in my browser, I got these warnings:

The functionality is as expected, save for those warning.
Adding this seemed to shut them up.
<script lang="ts">
	import Command from './command.svelte';
	import * as Dialog from '$lib/components/ui/dialog';
	import type { Dialog as DialogPrimitive } from 'bits-ui';
	import type { Command as CommandPrimitive } from 'cmdk-sv';

	type $$Props = DialogPrimitive.Props & CommandPrimitive.CommandProps;

	export let open: $$Props['open'] = false;
	export let value: $$Props['value'] = undefined;
+	export let loop: $$Props['loop'] = false;
+	export let label: $$Props['label'] = undefined;
</script>

<Dialog.Root bind:open {...$$restProps}>
	<Dialog.Content class="overflow-hidden p-0 shadow-lg">
		<Command
			class="[&_[data-cmdk-group-heading]]:px-2 [&_[data-cmdk-group-heading]]:font-medium [&_[data-cmdk-group-heading]]:text-muted-foreground [&_[data-cmdk-group]:not([hidden])_~[data-cmdk-group]]:pt-0 [&_[data-cmdk-group]]:px-2 [&_[data-cmdk-input-wrapper]_svg]:h-5 [&_[data-cmdk-input-wrapper]_svg]:w-5 [&_[data-cmdk-input]]:h-12 [&_[data-cmdk-item]]:px-2 [&_[data-cmdk-item]]:py-3 [&_[data-cmdk-item]_svg]:h-5 [&_[data-cmdk-item]_svg]:w-5"
			{...$$restProps}
+			{loop}
+			{label}
			bind:value
		>
			<slot />
		</Command>
	</Dialog.Content>
</Dialog.Root>

But I'm pretty sure you'll come up with a better way to tidy this up.
That's it, for now, at least. I'll be sure to report other issues if I land on them, but like I said, everything seems to be perfect.
Thanks again.

Hey @shyakadavis,
Those warnings are the bane of my existence & if ...$$restProps exists then they shouldn't be occurring IMO.


How to increase the timeout threshold for a download?

Hi Itay,
Background

I'm working on a project that is using pySmartDL to download media files from a server.
The server had been using the HTTP protocol but just switched to HTTPS.
Now downloads take a long time to get started (even without using pySmartDL; it seems to be some issue with the server).

The problem

Unfortunately these more-slow download-starts seem to cause pySmartDL to hit a URLError exception on line 129 of pySmartDL.py, where it makes a call to utils.is_HTTPRange_supported(self.url).

A potential solution

I think I might be able to avoid the exception if I could pass in a larger timeout threshold to that function, for example by passing in a timeout argument to the SmartDL() call.

The stack trace:
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python3.6/urllib/request.py", line 1318, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/lib/python3.6/http/client.py", line 1239, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1285, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1234, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/usr/lib/python3.6/http/client.py", line 964, in send
    self.connect()
  File "/usr/lib/python3.6/http/client.py", line 1400, in connect
    server_hostname=server_hostname)
  File "/home/vagrant/.local/lib/python3.6/site-packages/eventlet/green/ssl.py", line 392, in wrap_socket
    return GreenSSLSocket(sock, *a, _context=self, **kw)
  File "/home/vagrant/.local/lib/python3.6/site-packages/eventlet/green/ssl.py", line 87, in __init__
    self.do_handshake()
  File "/home/vagrant/.local/lib/python3.6/site-packages/eventlet/green/ssl.py", line 260, in do_handshake
    super(GreenSSLSocket, self).do_handshake)
  File "/home/vagrant/.local/lib/python3.6/site-packages/eventlet/green/ssl.py", line 115, in _call_trampolining
    timeout_exc=timeout_exc('timed out'))
  File "/home/vagrant/.local/lib/python3.6/site-packages/eventlet/hubs/__init__.py", line 164, in trampoline
    return hub.switch()
  File "/home/vagrant/.local/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 297, in switch
    return self.greenlet.switch()
ssl.SSLError: ('timed out',)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/vagrant/src/__init__.py", line 131, in wrapper_function
    thread_function(*args, **kwargs)
  File "/vagrant/src/__init__.py", line 199, in media_downloader_service
    download_queued_media(retry_failed_downloads=True)
  File "/vagrant/src/DKServerAPI/download_queued_media.py", line 52, in download_queued_media
    download_was_successful = _download_media(session, queued_download, tick_step_size, retry_failed_downloads)
  File "/vagrant/src/DKServerAPI/download_queued_media.py", line 104, in _download_media
    smart_downloader = SmartDL(full_url_to_download, media_item_specific_download_folder, progress_bar=False)
  File "/home/vagrant/.local/lib/python3.6/site-packages/pySmartDL/pySmartDL.py", line 129, in __init__
    if not utils.is_HTTPRange_supported(self.url):
  File "/home/vagrant/.local/lib/python3.6/site-packages/pySmartDL/utils.py", line 107, in is_HTTPRange_supported
    urlObj = urllib.request.urlopen(req, timeout=timeout)
  File "/usr/lib/python3.6/urllib/request.py", line 223, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.6/urllib/request.py", line 526, in open
    response = self._open(req, data)
  File "/usr/lib/python3.6/urllib/request.py", line 544, in _open
    '_open', req)
  File "/usr/lib/python3.6/urllib/request.py", line 504, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.6/urllib/request.py", line 1361, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "/usr/lib/python3.6/urllib/request.py", line 1320, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error ('timed out',)>

The timeout parameter should really be passed as an optional argument to the SmartDL constructor.
Furthermore it seems that the utils.is_HTTPRange_supported is not using the global SmartDL timeout.
I'll make a patch for that later today.

Thank you!

I've added the option. Can you check it's solving your issue?

Unfortunately it seems the server is responding quickly enough now that it isn't causing an error even with the version of pySmartDL I was using before this update you pushed, so I can't verify whether this will fix the issue if it pops up again, but I suspect it will.  If I see the issue tomorrow (when there may be more load on the server) I'll be sure to try to use the constructor parameter and I'll let you know if it works or not.
Here's the link to the video if you want to test it yourself:
https://staging.doohken.com/storage/4/fillervideo-skateboarding_screen.mp4


PROD-592: Fix reveal status mixpanel event

Description
This update ensures accurate event recording by marking it as RevealTransactionPending instead of RevealTransactionSucceeded when the transaction status cannot be confirmed in some edge cases (e.g delay in sign txn)

What are the steps to test that this code is working?
Try to reveal and sign txn after a few seconds of delay, you can verify from mixpanel dashboard in preview env

Screen shots or recordings for UI changes

I mistakenly created branch from my previous work. Please ignore the other changes related to mysteryBox and migration.

I updated all REVEAL mixpanel events with a flag passed as an args from button. REVEAL_TYPE will be based on button and not questionIds. We are GTG!


Where is the definitive place to find the latest version?

I can see version 4.18.2207.2 is available on SCCM, yet there is no mention of this version on this page as being available. If it's not here, where can I see information on this version?

@reticentnz Please indicate which document you are referring to. Thanks

Apologies, it is this page I'm referring to - here

@reticentnz Thank you for your feedback. The latest update from the catalog still shows 1.18.2205.7
The definitive place to get the latest version is https://www.catalog.update.microsoft.com/search.aspx?q=antimalware
The author will update the document once more information is available about this.
CC :  @denisebmsft
Hope this helps!
Thanks
Sri

@msbemba Thank you very much for the contribution and sharing this explanation. @reticentnz Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Moving heat templates for f5-openstack-heat-plugins to this repo

Issues: Fixes: Issue #28
Problem: Moving heat plugins templates to this repo
Analysis: The template from f5-openstack-heat plugins have been
consolidated and moved to a new direcotry called f5_plugins in the
unsupported directory
Tests:

This is just a relocation of templates from f5-openstack-heat-plugins to f5-openstack-heat. Merging.


[FR] Add Apprise for notifications

    @matmair: I just stumbled on this package again. Have used it earlier (CLI only) for Gotify. However, it may give the possibility of having general notifications, without explicitly adding every service independently..

https://github.com/caronc/apprise
Originally posted by @miggland in https://github.com/inventree/InvenTree/issues/4114#issuecomment-1367213231

Hi there @miggland - I have released a plugin that integrates Apprise, please make note if something is not working:
https://pypi.org/project/inventree-apprise/

Nice, @matmair! Will install and try it out.

BTW, I tried it out and worked fine! Thanks for implementing.


Gradle Wrapper Ignores Logging Flags If After Task(s)

Expected Behavior

When running ./gradlew printSomething -q without the relevant Gradle version downloaded, I would expect that the only output would be from the printSomething task.
Current Behavior

When running ./gradlew printSomething -q without the relevant Gradle version downloaded, I still see the download logs:
Downloading https://services.gradle.org/distributions/gradle-3.5-bin.zip .........................

If instead I run ./gradlew -q printSomething with the -q flag first, it works as expected.
Context

We have Gradle tasks to print out the version of our app to deploy by looking up the latest version in a repository e.g:
VERSION_TO_DEPLOY=`../gradlew getLatestReleaseCandidate -q
../gradlew deployToStage -PdeployVersion=$VERSION_TO_DEPLOY

With this bug the download logs are also assigned to VERSION_TO_DEPLOY which then breaks the deploy task.
Steps to Reproduce (for bugs)

https://github.com/adamdougal/gradle-wrapper-logging-issue
You can run the run.sh to reproduce.
Your Environment

Build scan URL: https://scans.gradle.com/s/2i4vzfmgd4dsm

This example uses Gradle version 4.7 but I've also seen this happen with many other versions including: 2.9, 3.5, 4.1 and4.6.

Heya, I don't suppose you have any update on this? We are frequently finding teams running into this issue. Happy to raise a PR if you can point me in the right direction.

I don't believe anyone's looked at this.
You can start here:
https://github.com/gradle/gradle/blob/982d3999a0fbb9aa1a236a517e50c3e95631f925/subprojects/wrapper/src/main/java/org/gradle/wrapper/GradleWrapperMain.java#L43-L60
This looks eerily similar to https://github.com/gradle/gradle/issues/1895, so my suspicion is that we stop parsing the command-line on the first unrecognized option or we're ignoring options after the first unrecognized option as if they're parameters to that unrecognized option.
I'm happy to look at a PR.  I would try reproducing the problem in WrapperLoggingIntegrationTest

Still happening in 7.4:
./gradlew run --console=plain --quiet
Downloading https://services.gradle.org/distributions/gradle-7.3.1-bin.zip
    ...........10%...........20%...........30%...........40%...........50%...........60%...........70%...........80%...........90%...........100%
...


[UI] Suggestion: Open K8Ns Dashboard immediately, skip page with single button

Rancher versions: rancher/server: 1.6
Environment Template: Kubernetes
Suggestion:
Open Kubernetes dashboard immediately after clicking on the the "Kubernetes > Dashboard" entry in the navigation and skip the confirmation page with a single button.
Description:
The K8Ns dashboard is currently available by clicking the "Dashboard" entry in the main navigation. After clicking it you have to click on a second button "Kubernetes UI" to open the dashboard. This is kind of annoying since there is no other action on that page. I think it would be much more convenient if the dashboard would open imminently in a new Tab.

n/a to 2.0.


Download/delete theme buttons have white "border" in dark mode

Issue Summary
While in dark mode, if you try to download or delete a theme a white "border" exists at the top of the selection box as well as the bottom left and right corners.

Steps to Reproduce

Switch to dark mode
Try to download or delete a theme
See white "borders"

Ghost Version
5.54.0
Node.js Version
?
How did you install Ghost?
Ghost(Pro)
Database type
MySQL 5.7
Browser & OS version
No response
Relevant log / error output
No response
Code of Conduct

[X] I agree to be friendly and polite to people in this repository

sir plss assign this to me. I can resolve the bug and fix this.
thank you

Please assign this to me

Hi, can I work on this issue?

This issue has been obviated by the new editor, so I'm closing it.


feat(portal): remove old mapping template upgrade page

Description

remove old mapping template upgrade page
fix more bugs found in regression tests

Related Issue

[FEATURE] Remove older version of mapping template upgrade
[Improvement] Show truncated API path with "..." in the front, when user hovers show the full name

Motivation and Context
Removing old mapping template upgrade page since new one had been published.
How This Has Been Tested
N/A
Screenshots (if appropriate)

Types of changes

[ ] 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 change)
[x] Refactoring or add test (improvements in base code or adds test coverage to functionality)
[ ] CI/CD or documentation update (changes to CI/CD pipeline or documentation)

Checklist

[ ] I ensured that the documentation is up to date
[x] I explained why this PR updates in detail with reasoning why it's required
[x] I would like a code coverage CI quality gate exception and have explained why

Hi Bartek @KsiBart , please review again.


[ai-text-analytics] Client tests with record & playback

This PR adds basic tests of the client's functionality. We just make sure that the client throws in appropriate places, that the service returns successes for things that should succeed, etc. I'm hesitant to add too many things that test the service itself, but we will add some tests of the service's behavior in our critical scenarios as we move forward. These tests are sufficient to get us to 100% client code coverage and to get our live testing off the ground.

Added tests for all client methods using AAD in textAnalyticsClient.spec.ts

invalid inputs such as empty-arrays on every method should throw
success with or without optional parameters
success with string[] inputs that will be wrapped
success with mixed-language inputs using the various input objects directly
a few tests that some things (like PII) actually do detect PII-like information, and that country hints must be well-formed

Added one basic success test of each API method using the API Key in apiKey.spec.ts
Added support for the recorder through karma.conf and test/utils/recordedClient.ts, which contains a helper that sets up the recorder replacements and manufactures an authenticated client.
Recorded all the tests and made sure my creds were scrubbed

/azp run js - textanalytics - tests


Continuous errors when there are no CSRs present

The container logs an error each second, when there are no CSRs present.
<...>
E0919 09:03:26.669701       1 reflector.go:315] github.com/proofpoint/kapprover/kapprover/kapprover.go:120: Failed to watch *v1beta1.CertificateSigningRequest: unknown (get certificatesigningrequests.certificates.k8s.io)
E0919 09:03:27.671919       1 reflector.go:315] github.com/proofpoint/kapprover/kapprover/kapprover.go:120: Failed to watch *v1beta1.CertificateSigningRequest: unknown (get certificatesigningrequests.certificates.k8s.io)
E0919 09:03:28.676251       1 reflector.go:315] github.com/proofpoint/kapprover/kapprover/kapprover.go:120: Failed to watch *v1beta1.CertificateSigningRequest: unknown (get certificatesigningrequests.certificates.k8s.io)
E0919 09:03:29.677922       1 reflector.go:315] github.com/proofpoint/kapprover/kapprover/kapprover.go:120: Failed to watch *v1beta1.CertificateSigningRequest: unknown (get certificatesigningrequests.certificates.k8s.io)
It successfully approves them and deletes them afterwards, once they are created.
It's not a bug for the functionality, just these errors could be suppressed or handled.

Facing the same issue.

Hi @audriusb
Thanks for reporting the bug. can you check RBAC and see if it has permissions to "watch" setup. If not can you please add it and see if you are still able to reproduce the issue after that.
- apiGroups: ["certificates.k8s.io"]
  resources: ["certificatesigningrequests" ]
  verbs:     ["get", "list", "delete"]

Hi @rajatjindal
The solution works just fine. It gets and approves the CSRs, just when there's no CSRs it floods those errors. I wouldn't mind that much, but I'm directing all of it to elasticsearch and this is just trash in my logs.
For know, I used a workaround to redirect stderr to /dev/null, hoping that no real errors are suppressed.

Updated the sample RBAC to include the missing "watch" permission. Please update your RBAC to match the example in release 0.7.0.


Automated cherry pick of #628 #655 #662 #674

Cherry pick of #628 #655 #662 #674 on release-0.3.
#628: Vault issuer MUST USE the vault 'sign' endpoint
#655: Update e2e test ACME email
#662: issuers: Skip triggering API update if status has not changed
#674: Don't return invalid/expired orders in

/retest

/approve

/release-note-none


Add additional tests for Clear-Content to improve coverage

Coverage is reported to be more than 85% for Clear-Content
actual coverage for this is much higher (it looks like closing braces are not being counted as covered). I am following up with OpenCover folks.

restarted Linux in TravisCI


🐛 Set M3M concurrency to 1 and add warning

What this PR does / why we need it:
We currently have an issue with concurrency when associating a BMH to a M3M. A mutex was already added before to the Associate function. However, this does not completely solve the issue, because a caching client is used. In other words, the next M3M to associate can sometimes use cached data about the BMHs and pick one that is already associated.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
This is a temporary workaround for #1004

/test-centos-e2e-integration-main
/test-ubuntu-integration-main

/approve


Better input format for shapes

The purpose of this PR is to slim down the format for storing structures in the input file. I think the functionality is sufficiently new that we don't need to worry about being backward compatible, but we should move relatively fast before it becomes an issue. Main point we want to address here is that storing vertices for each atom is a huge overhead if all that happens is that a structure is rotated or displaced.
I suggest to proceed as follows. Shapes are still stored as entries in a dictionary. Each entry contains
export interface BaseShapeData {
    kind: string;
    settings:  {};
    frame_settings: undefined | {};
    atom_settings: undefined | {};
}

Each shape is generated by passing the settings to a function. If frame_settings or atom_settings are defined, then they must be a dictionaries where each parameter is an array containing the values of the parameters for each frame, or each atom in each frame.
Then, shapes are created by looping over the appropriate entities, and calling the appropriate function with an argument list created by combining settings, frame_settings and atom_settings.
For instance, one could have:
{kind: "arrow", settings={'radius': 0.1}, frame_settings: {direction: [[0,0,1],[0,2,0]]} }
which will plot an arrow in the specified direction, centered on the origin, for frames 1 and 2.
{kind: "arrow", frame_settings={'radius': [0.1, 0.2]}, atom_settings: {direction: [ [[0,0,1],[0.0,2]], [[0,2,0],[1,1,1]]]} }
will plot arrows with radius 0.1 in frame 1 (one for each of the two atoms) and arrows with radius 0.2 in frame 2.
Incidentally, this format also addresses the use case in which one wants to have shapes that are not directly attached to atoms, e.g. polyhedra or isosurfaces.

I agree with the idea here, it would be nice for smaller files by not repeating identical values.
A couple of things:

I would use parameters instead of settings
frame_parameters and atoms_parameters should be mutually exclusive. If we need to use the same parameters across all frames, we can put them in the parameters. Having something different from one structure to the other, but the same for all atoms feels like a corner case that we don't need to support.
if not provided, the position parameter will be [0, 0, 0]  for frame_parameters or the atom position for atoms_parameter.

Another consideration: should atoms_parameter be named particles_parameters?
Overall, I would do something like this:
interface SomeShapeData {
    orientation: ...
    color: ...
    ...
}

export interface ShapeParameters<T> {
    kind: string;
    parameters:  {
        global: Partial<T>,
        structures?: Array<Partial<T>>,
        particles?: Array<Partial<T>>,
    }
}

What is not covered by this proposal is the ability to have a handful of "template" shapes to pick between (e.g. have 3 different ellispoids, where only the position & orientation vary between particles). Not sure how much this would be worth it, but we should consider it now.

What is not covered by this proposal is the ability to have a handful of "template" shapes to pick between (e.g. have 3 different ellispoids, where only the position & orientation vary between particles). Not sure how much this would be worth it, but we should consider it now.

Not sure I understand what you mean here. You mean building a "template shape" composing multiple primitive and then placing them at different positions and orientations?
One major issue I see is that RN shapes are deeply associated with atoms - they are stored in the frames and not as a separate section of the dataset. This is quite a deep change and my re-implementation kind of stalled trying to disentangle shapes from frames.

Not sure I understand what you mean here. You mean building a "template shape" composing multiple primitive and then placing them at different positions and orientations?

something like this: we store could parameters once per template and then refer to a template in the shapes
templates = {
    A = {kind = "...", parameters: ...}
    B = {kind = "...", parameters: ...}
    C = {kind = "...", parameters: ...}
}

shapes = {
    "name" = {
        parameters = {
            global = {
                ...
            }
            particles = [
                { template: "A", position: ... },
                { template: "A", position: ... },
                { template: "B", position: ... },
                { template: "A", position: ... },
                { template: "A", position: ... },
                { template: "C", position: ... },
                { template: "C", position: ... },
                { template: "B", position: ... },
                { template: "B", position: ... },
            ]
        }
    }
}

One major issue I see is that RN shapes are deeply associated with atoms - they are stored in the frames and not as a separate section of the dataset.

That's fine? This way we can easily display shapes in a standalone viewer as well. Why would we want to move the shapes outside of the structures? (I agree they should not be inside the atoms, but we don't have a concept of atom, cf https://chemiscope.org/docs/api/interfaces/Structure.html).

OK, this is starting to get somewhere. @rosecers can you look at LAMMPS parsing and the validation code - that I have largely commented out ATM - while I fix the custom shapes and perhaps add a builtin arrow?

Looking at current version. Can you @rosecers update the test? I'll go through the rest and polish up.

@Luthaf any objection to removing lammps port? Finding we don't need it with the new format

You mean the Python code to extract shapes from ase Atoms in LAMMPS format? Happy to remove it if it is no longer needed!

I should really learn how to run eslint locally

You can set it up to automatically run inside vscode (https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) or other editors, or run it with npx eslint on command line.

Hi @Luthaf  I think this is ready to merge. Will wait for you to have a last look.
FYI - I didn't take in your suggestion to use particles for the shape parameters to stay consistent with the nomenclature we used for the properties target.


Lauwsj/integrate profile

Summary

Improve UI on view t/patient
Change toString() method of the patient, to print the tag better instead of [x][y] etc
Fix some commented test
Integrate the profile with referral and sideWindow

Pictures / Gif

Checks

[x] Link PR to issue
[x] Add Reviewer
[x] Pass CI

Codecov Report

Merging #169 (3b26cfd) into master (ffb2d0d) will decrease coverage by 0.32%.
The diff coverage is 15.62%.

@@             Coverage Diff              @@
##             master     #169      +/-   ##
============================================
- Coverage     74.97%   74.64%   -0.33%
- Complexity      966      967       +1
============================================
  Files           132      132
  Lines          3109     3128      +19
  Branches        369      369
============================================
+ Hits           2331     2335       +4
- Misses          640      655      +15
  Partials        138      138

Impacted Files
Coverage Δ

...n/java/gomedic/logic/commands/ReferralCommand.java
24.77% <0.00%> (-0.91%)
:arrow_down:

...gic/commands/addcommand/AddAppointmentCommand.java
67.74% <ø> (ø)

src/main/java/gomedic/ui/card/ActivityCard.java
0.00% <ø> (ø)

src/main/java/gomedic/ui/table/ActivityTable.java
0.00% <0.00%> (ø)

src/main/java/gomedic/ui/view/PatientView.java
0.00% <0.00%> (ø)

...ain/java/gomedic/model/person/patient/Patient.java
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ffb2d0d...3b26cfd. Read the comment docs.


Mp3 tags and info

First up that code I put up for reading header info failed on a couple of files, but pretty sure I know why and it will be fixed in the next couple of days.  Plus Ill be extending it and making it do more like error checking (sooooooo boring).  I wrote that just by looking at the specs and not other peoples code (except the lookup tables, im lazy) so as to avoid having to use their licences....plus it was a real fun challenge.  But now Ill go and look around and see what else needs adding to make it more complete.
At some point your going to need this stuff and was wondering if you still think....
https://github.com/aadsm/JavaScript-ID3-Reader
...is what you want to use?
Ive been looking at it and its real good, but I cant test on other devices as I dont own any and so cant comment on that.
The only real problem I saw for your needs was that it was using a string to hold its binary data and that meant youd have to first convert your mp3 to a string which is dumb considering your already have it as  arraybuffer.  So Ive patched it to be able to use an arraybuffer (Ill send them a pull request later), so now it doesnt have to reproduce the file once again, plus itll be quicker.  On speed, Ive noticed a couple of things in that code that could be speed up and Ill prolly do them at some time.  And if its going to use an arraybuffer I could add even more optimisations if they want.
If this is the one you want to use then Ill get my info stuff more robust and then Ill see if/how they want to add it in.

Back again ;)
Got distracted and wanted a break....atleast one distraction turned out to be cool, https://github.com/Nuclides/github-highlight-selected/issues/4 , nice when you get something you wanted at the end of it :P
Found another node based bunch of librarys...
https://github.com/jquense/node-audio-info
...also look at....
https://github.com/KenanY/id3v2-in-browser
...and he has repos for the individual formats aswell.
This one is alot smaller than the other one and seems to handle mp3's fine (including extended headers which a couple failed on, like the one you originally mentioned).  This one is about 95k minnimized for just the id3v2 stuff.  I could get that a little smaller by then removing underscore that he used twice for two things that done need underscore, which would get about 20k off....but its always going to be to big for my liking as its all buffer, stream, node stuff that the browser dont need.
So I know you didnt like the idea of me reinventing the wheel again, but dam I know I could do it with less spokes ;P.....
http://plnkr.co/edit/9ahBhEpArMqrlWsMJ3hq?p=preview
...I rewrote it to be more browser like.  Minified its 8.2k!!!!....thats more like it :P
So Im going to convert id3v1 and ogg tomorrow, now Ive done this one it shouldnt be to bad.  It also needs some stuff to handle tags and some extra header stuff (its simple) but even with that and the other formats I dont see this thing getting up to even 15k.  Bytes (my buffer alternative) is one of the bigger things and thats not getting much bigger now, its got lots of nice stuff.

Welcome back. 8K is pretty convincing, and at first glance the code looks like it makes sense.
Whether we use your code or an existing library, I think we should keep it as a separate project. Parsing id3 tags in the browser is a useful problem to solve. If we believe that the current solutions are not good enough (aka, too bloated), then we should make our (your) alternative available as an alternative for other projects.
@PAEz, would you be interested in developing this fully and maintaining it as a repository under your GitHub account? If not, how would you feel about me putting your code in a repository under my account?
I really like the idea of a much leaner library, but I have a few concerns:

Including your code means I have to either depend on you to maintain it as we find bugs, or be willing to maintain it myself. I'm not 100% sure I'm qualified or interested enough to maintain such a library.
Mp3 have probably been generated with all kinds of tools that generate poorly formed id3 tags. Adopting a new library (like yours) as opposed to a more "battle tested" one, means we are going to notice and either accommodate, or decide to ignore those mp3s. I'm not sure we are really in a position where we have a broad user base that will help by reporting issues when their mp3s behave poorly.
Using an existing library might give us the advantage of future extensibility. What if we want to support some other format(s) in the future? (That being said, I think id3 versions 1 and 2 plus ogg/flac should be enough for the foreseeable future).
As much as I've been interested in controlling the file size, because it presents a fun and interesting challenge, I have to remind myself that we are really prematurely optimizing here. We are currently at 180K which is TINY compared to most sites today, AND given what we are doing, I think people would be just as pleased if it 1 or 2 MB.

So, keeping it lean and without dependencies fits nicely with the aesthetic of this project, but it comes with at a cost. Do you think it's worth it?

Id be cool with sticking up a repo for it, Im not totally cool on maintaining it though as Im to fickle for that.  But then it wouldnt be tHaT much hassle to maintain as its just a matter of keeping this up to date with musicmetadata.
I just converted musicmetadata over to using Bytes (I love Bytes;).....
http://plnkr.co/edit/PPOvkq?p=preview
...well Ive done most of the main files.  I cant do one bit yet as I cant find a file to test it on, I need an mp3 encoded with vbr but not containing an extended/info/lame header...bumma.  I converted musicmetadata coz it does more than the other one, it can get the duration and can scan all frames (which I might need soon).  It was a little harder coz of its streaming tokenizer, but I faked that with something Im calling Chunks.  If you have a look at the original and this one youll see that their code looks extremely similar which is why I think mainlining wouldnt be that bad.  This way your basically getting a battle hardened tested library, but with the bloat gone....this was about 17.5k minified and I could get that down a bit more but would need to change the code and wanted you to see how close it is to the original first.
Point 1
Its going to be so close to musicmetadata I dont think thatll be much of a hassle.
    This came up with the text encodings stuff.  The specs say to support utf8,16 and iso-somethingorother only, but that some stuff (jap) used other encodings....tuff, should have used utf16.  Dealing with that would have just been nuts and why if its not even in the specs?...Im not supporting that, use software that sticks to the specs.
Point 3
Ill prolly end up doing all of musicmetadata.
Point 4
Size counts and Ill be dammed if Ill ever be one of those people that think it doesnt coz of broadband and what not....it sickens me how many simple pages weigh in more than a meg, bleh.  And one of winamp 2.95s joy was its complete lack of bloat.

PAEz you really are godsend!
I've been looking for a way to read and edit id3 tags for a music project I'm working on. Searching on npm keeps yielding projects that rely on editing the id3 of a file already on disk using wrappers to c++ packages like ffmpeg or libav.
I already have the mp3's binary passing through my server and I would rather not have to save it to update it. You're working at a low-enough level that reading (and hopefully editing) them at that level shouldn't be a challenge, it seems.
I can't wait to check out what you've done here and see if it's possible to make a package on npm to do the same thing and save others from having to work with old, clunky tools.

Alright! Sounds like we have a plan. Let's use your code.
Thanks @Akamaozu. Looks like we already have another customer for this stand-alone id3 library. :)
I think the only question left unresolved is where is this library is going to live.

You host it on your GitHub account. I send pull requests for things I need/want. If you lose interest, I fork it.
I host it on my GitHub account. I can manage all the Git stuff. (I've noticed you prefer comments to pull requests). I would also do my best to manage any potential community contributions.

Let me know which way you want to go.

It's also worth mentioning that musicmetadata is MIT licensed, so we can freely look at/steal any of their code which we find useful.

Whatever happened to this?

Not sure. Any interest in looking into this? We would need to re-evaluate our options, since I'm sure things have evolved since 2015.
@parrotgeek1 proposed looking into https://github.com/audiocogs/mp3.js/ obviously that's a bit heavy for us (we just need bitrate and id3, not actual decoding) but it might be a starting place. Maybe some of that stuff is/could be modularize.


Problem with path in add_to_index

Using RAGatouille==0.0.6a2 in colab, trying  .add_to_index
for i, batch in enumerate(batches, start=0):
    RAG.add_to_index(
        new_collection=batch,
        index_name="dharma_colb",
        split_documents=True,
    )

error message
WARNING: add_to_index support is currently experimental! add_to_index support will be more thorough in future versions

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

FileNotFoundError                         Traceback (most recent call last)

[/usr/local/lib/python3.10/dist-packages/colbert/infra/config/base_config.py](https://localhost:8080/#) in load_from_index(cls, index_path)
     93             metadata_path = os.path.join(index_path, "metadata.json")
---> 94             loaded_config, _ = cls.from_path(metadata_path)
     95         except:

6 frames

FileNotFoundError: [Errno 2] No such file or directory: '.ragatouille/colbert/indexes/colbert/indexes/dharma_colb/metadata.json'

During handling of the above exception, another exception occurred:

FileNotFoundError                         Traceback (most recent call last)

[/usr/local/lib/python3.10/dist-packages/colbert/infra/config/base_config.py](https://localhost:8080/#) in from_path(cls, name)
     42     @classmethod
     43     def from_path(cls, name):
---> 44         with open(name) as f:
     45             args = ujson.load(f)
     46

FileNotFoundError: [Errno 2] No such file or directory: '.ragatouille/colbert/indexes/colbert/indexes/dharma_colb/plan.json'

colbert/indexes is doubled in path

Hey! Good shout, thank you for flagging. The CRUD aspects are very much experimental at the moment but we're working on bringing them up to speed, appreciate the feedback and will ping you when this is fixed!
(cc @anirudhdharmarajan further CRUD issues (vaguely related but distinct to https://github.com/bclavie/RAGatouille/issues/71))

this isn't pressing issue for me (was using batching and add_to_index while colab was acting wierd) just wanted raport a bug, and message clearly states that this ies experimental. Cheers

Thanks! Much appreciated 😊

I had the same issue, it works if you give full path of the index (returned once index is created). In your case it would be .ragatouille/colbert/indexes/dharma_colb for index_name arg

FYI, this week got extremely busy but I'll have a fix ready by Monday!

HI, I also faced the same issue. I can get around by setting RAG.model.loaded_from_index = True .  RAG  being a RAGPretrainedModel

Thanks @anirudhdharmarajan for taking a stab at this!


Top level declarations should have a descriptive type signature

eg:
replace: export const whatever = new Symbol()
with:    export const whatever: symbol = new Symbol()
replace: export function sayHello()
with:    export function sayHello(): void

same with methods if possible


Update byte-buddy, byte-buddy-agent to 1.12.8

Updates

net.bytebuddy:byte-buddy
net.bytebuddy:byte-buddy-agent

from 1.12.7 to 1.12.8.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "net.bytebuddy" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #368.

Superseded by #368.


UPnP Error 701 received

Hi,
I'm using SoCo in Home-Assistant and have been seeing some errors in the log lately.
Python release (python3 --version): 3.4.2
Version of SoCo is unclear, how do I check that? The installation is about 2 weeks old so the library should be resent.

UPnP Error 701 received: Transition not available
Error doing job: Future exception was never retrieved

Here are the logs:
soco.exceptions.SoCoUPnPException: UPnP Error 701 received: Transition not available from <IP_ADDRESS>
16-12-08 08:13:15 soco.services: UPnP Error 701 received: Transition not available from <IP_ADDRESS>
Traceback (most recent call last):
  File "/home/hass/.homeassistant/deps/soco/services.py", line 408, in send_command
    self.handle_upnp_error(response.text)
  File "/home/hass/.homeassistant/deps/soco/services.py", line 469, in handle_upnp_error
    error_xml=xml_error
soco.exceptions.SoCoUPnPException: UPnP Error 701 received: Transition not available from <IP_ADDRESS>
16-12-08 08:19:30 homeassistant.core: Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/core.py", line 1045, in execute_service
    service_handler.func(service_call)
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/media_player/__init__.py", line 324, in media_player_service_handler
    getattr(player, method)()
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/media_player/sonos.py", line 830, in turn_off
    self.media_pause()
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/media_player/sonos.py", line 844, in media_pause
    self._player.pause()
  File "/home/hass/.homeassistant/deps/soco/core.py", line 104, in inner_function
    return function(self, *args, **kwargs)
  File "/home/hass/.homeassistant/deps/soco/core.py", line 501, in pause
    ('Speed', 1)
  File "/home/hass/.homeassistant/deps/soco/services.py", line 181, in _dispatcher
    return self.send_command(action, *args, **kwargs)
  File "/home/hass/.homeassistant/deps/soco/services.py", line 408, in send_command
    self.handle_upnp_error(response.text)
  File "/home/hass/.homeassistant/deps/soco/services.py", line 469, in handle_upnp_error
    error_xml=xml_error

Additional info:

Error 701 is thrown if in the current state, pausing the player is not possible (e.g. if there is no music). It is returned by the Sonos speakers themselves, SoCo just converts it into a Python exception.
The solutions for your problem might be observing what state the player is in and prohibiting execution of pause() if there is nothing to pause, or just silently handling the exception (it probably does no harm to ignore it).

@ZyberSE you can find the soco version by doing:
import soco
soco.__version__

Are you satisfied with the answer you git from @ghcs27 regarding the origin of the exception?
@ghcs27 I can see in the source code that it is documented that e.g. play and pause may raise SoCoUPnPException, but it does not mention anything about the error code. It may be useful to add a little something to the docstrings about the most common sources of failures and about more acceptable sources of failures, such as this one. What do you think.

I would support adding UPnP error codes and their meaning to the docs. The basic meaning of the error codes can be found on page 89 of the UPnP specs, but some codes probably have a Sonos specific meaning.

@ghcs27 It might be that we should add some sort of list (probably not exhaustive though, but with links) somewhere in the docs, but my question was more whether it would be a good idea to explain one or 2 particularly relevant error codes in the doc string for methods like e.g. pause. Thoughts?

I had this error on a snapshot restore(). I mention this as your comment suggests that I should be checking if the Sonos is in a state to be played, but I don't think I have that option with a snapshot.
snap.snapshot()
deviceco.play_uri(alert_uri)
time.sleep(10)
snap.restore()

Hi @mediaguycouk,
am pretty sure as has been said you are tying to pause() when there is nothing to pause.
Interestingly is you use stop() this doesn't throw an error.
If you want to know what commands you can use then the following code will tell you.
import soco
s = soco.SoCo('<IP_ADDRESS>')
print(s.avTransport.GetCurrentTransportActions([('InstanceID', 0)]))

However you can probably catch it by seeing if it was playing before you pause() it.
get_current_transport_info()['current_transport_state'] tells you if it was playing - if not no need to stop / pause it.
Hope this helps,
Cheers David

Closing this in favor of #584 and #585.


query_range endpoint not documented

I might be early to use the endpoint, but I was directed to it. I noticed that the endpoint is not documented on the README.

Thanks @apoydence! This is fixed now.


Artist bio + image on zune hd

I found an old program from back in the day that would allow replacing an artist bio and image for syncing to the zune hd. The readme (attached) has the uri that the software queries to pull data for the device. Hope it's helpful :)
ee85eac0-4936-4599-97a6-569cdb71a999.pdf

Howdy! Thanks for the tip, that will be useful in the future. Though uhh... I have a bit of a surprise for you :)

That looks amazing! Thanks for all your work on this - I'm really excited to try it out!!


Add missing call to CloseClipboard on windows

This could cause a druid application to steal control of the clipboard, preventing it from working in other apps

Dang it Raph!

Just spotted another case where this isn't always called, so don't merge just yet 😄

get_format wasn't calling CloseClipboard in the None path, so I've wrapped everything in a little helper function instead


Access to the WebCrypto API is restricted to secure origins

Describe the bug
I am using a library that relies on WebCrypto API and get this error when that library is loaded (it is loaded on demand)
Uncaught (in promise) [Portis] Access to the WebCrypto API is restricted to secure origins.
If this is a development environment please use http://localhost: instead.
Otherwise, please use an SSL certificate.

is webcrypto not available in tauri ?

Is this on dev or on build? Tauri relies on the crypto API so it should be available.

both

Can you please give us more details about your system? yarn tauri info is a good start, as is the frontend framework you are using.

What OS are you running and which API are you trying to use? Tauri relies on crypto.getRandomValues.

tauri info
Operating System - Windows, version 10.0.19042 X64

Node.js environment
  Node.js - 14.16.0
  @tauri-apps/cli - 1.0.0-beta-rc.4
  @tauri-apps/api Not installed

Global packages
  npm - 6.14.11
  yarn - 1.22.5

Rust environment
  rustc - 1.51.0
  cargo - 1.51.0

App directory structure
/.svelte
/.vscode
/build
/node_modules
/src
/src-tauri
/static

App
  tauri.rs - 1.0.0-beta-rc.4
build-type - bundle
CSP - default-src blob: data: filesystem: ws: http: https: 'unsafe-eval' 'unsafe-inline'
distDir - ../build
devPath - ../build

framework: svelte+svelte-kit
the library that is causing problem is loaded via a script tag element created at runtime.
I need to look deeper what exactly they are using : https://www.npmjs.com/package/@portis/web3

this is their detection function
export function validateSecureOrigin() {
  const isLocalhost = location.hostname === 'localhost' || location.hostname === '<IP_ADDRESS>';
  const isSecureOrigin = location.protocol === 'https:';
  const isSecure = isLocalhost || isSecureOrigin;

  if (!isSecure) {
    throw `[Portis] Access to the WebCrypto API is restricted to secure origins.\nIf this is a development environment please use http://localhost:${
      location.port
    } instead.\nOtherwise, please use an SSL certificate.`;
  }
}

So I think we already fixed this

This change is on wry 0.9, so it'll be available on the next release.


No json file

Hi,
I couldn't find
Additional` files in satlas/metadata/ contain extra data. train_highres.json, train_lowres.json, test_event.json, test_highres.json, train_lowres.json, test_event.json enumerate the tiles assigned to each split.
May I ask where it is?

It should be in the dataset download (https://github.com/allenai/satlas/blob/main/SatlasPretrain.md#satlaspretrain-dataset) specifically the satlas-dataset-v1-metadata.tar file, do you not see it there?

Sorry to open this again @favyen2 , but I actually cannot find the metadata tarball on huggingface and I tried:
hf_hub_download(repo_id="allenai/satlas-pretrain", filename="satlas-dataset-v1-metadata.tar")
Entry Not Found for url: https://huggingface.co/allenai/satlas-pretrain/resolve/main/satlas-dataset-v1-metadata.tar.

and
hf_hub_download(repo_id="allenai/satlas-pretrain", filename="dataset/satlas-dataset-v1-metadata.tar")
Entry Not Found for url: https://huggingface.co/allenai/satlas-pretrain/resolve/main/dataset/satlas-dataset-v1-metadata.tar.

Here it is https://huggingface.co/allenai/satlas-pretrain/blob/main/dataset/satlaspretrain_dataset_metadata_0000.tar
You can also use the URLs here https://github.com/allenai/satlas/blob/main/satlaspretrain_urls.txt


Submit Order transaction receipt view

Story
As a wallet user
I want to immediately recognise where the submit order transaction has come from, what it's for and with which key I am signing it
So that I can get back to what I was doing as quickly as possible
Acceptance criteria

[ ] When the dapp requests a transaction with a key we don't know about, we don't see a request in the wallet but instead send an error back to the dapp
[ ] When the dapp requests a transaction type / or includes transaction details that we don't recognise, we don't present the transaction request in the wallet but provide an error to the dapp that feeds back that the transaction can not be processed
[ ] When a transaction is submitted from a dapp to a connected wallet...
[ ] Chrome opens the browser extension
[ ] Firefox notification icon to indicate there is something pending (if we can't open the browser extension)
[ ] When the user opens the extension (or it has automatically opened) they can immediately see a transaction request
[ ] If the browser extension is closed during a transaction request, the request persists
[ ] I can see  the transaction type e.g. "Place order"
[ ] I can see where the transaction came from e.g. console.vega.xyz with a favicon
[ ] I can see the key being used to sign it e.g. Vega Key 1 with a visual cue
[ ] The key the transaction applies to is the one selected in the dapp
[ ] The primary order transaction information for submit orders is human readable
-- [ ] Transaction title
-- [ ] Where it is from  e.g. console.vega.xyz with a favicon
-- [ ] The key you are using to sign with a visual identifier
-- [ ] The time the request to sign and send was received by the wallet
-- [ ] Market name
-- [ ] Order type: Limit or market order
-- [ ] Direction: Long or short
-- [ ] Size
-- [ ] Price
-- [ ] Time in force
-- [ ] Expiry date / time
-- [ ] Post only
-- [ ] Raw JSON details for anything else
[ ] Transaction title is as defined in the network (Order submission for example even though the button in console is place order!)
[ ] There is a loading state for the human readable 'receipt' data in the case that we are not able to show it instantly (believe this to apply to symbol, market name, price)
[ ] If data returned is a default value, we don't display it
[ ] I can copy the raw json to my clipboard
[ ] For data that requires us to get human readable data from the data node (Price, Market Name) we first display what we get from the transaction (i.e. unformatted price and market ID) and then replace with human readable when/if we receive

Notes

[ ] If you have more than one key, you have to have chosen the "right" key to start with in the dapp (not in the wallet)

Tasks

[x] Detailed sketch
[ ] Visual design
[ ] Frontend

[ ] Implement UI
[ ] Find a way to mock the data to be able to dev and test against

[ ] Backend tasks

[ ] Extend the sample dapp / document (as part of this https://github.com/vegaprotocol/vegawallet-browser/issues/134) to have the ability to place orders - show the shape of the json data for orders
[ ] Work out how the backend provides asset and market details
[ ] Caching the results

[ ] Integrate with backend
[ ] Implement Authentication (encryption)
[ ] Write unit tests
[ ] Write end to end tests
[ ] Code review
[ ] Team verify acceptance criteria met
[ ] Exploratory QA testing
[ ] Capture bugs and new edge cases in tickets (this one or new TBD)
[ ] Write automated regression tests for the A/Cs (expanding on A/Cs where possible)
[ ] Add story and A/Cs to spec doc
[ ] Review with stakeholders
[ ] Release

Design
Figma link ↳

Sketches
Miro - https://miro.com/app/board/uXjVPUiQ2AE=/?moveToWidget=3458764552847131824&cot=14

Additional details / background info

The first pass on all these is now done.
This part is to add the market names / prices etc into the view.
This is above the referral line


feature(azure-iot-device): Added .on_new_sastoken_required handler

Enabled the .on_new_sastoken_required handler
Renamed the SasTokenRenewalStage to simply SasTokenStage (perhaps SasTokenUpdateStage would be preferable?)


feat: Support for reStrcuturedText style

Updates version of pytkdocs to allow use of release that supports reStructuredText. Also update documentation.
Addresses #176

Hello! Thank you for the PR.
This is not technically a feature so I'll squash and use a docs type for the commit.
Could you also revert the pytkdocs version range upgrade in pyproject.toml? I'd like to do that in a separate commit once I'm ready to release mkdocstrings version 0.14.
Thanks again!

I can do that. But just to be clear, I updated the docs to include a reStructuredText snippet. So the documentation will not build successfully until the new version of pytkdocs is pulled into the project.
The CI failure seems to be an issue poetry decides to use pytkdocs==0.9.0 instead of the newer version. I'm still trying to figure out why that is happening. It might be a conflict with the allowed ranges for the indirect dependencies.

But just to be clear, I updated the docs to include a reStructuredText snippet. So the documentation will not build successfully until the new version of pytkdocs is pulled into the project.

OK sure, not a problem :slightly_smiling_face:

The CI failure seems to be an issue poetry decides to use pytkdocs==0.9.0 instead of the newer version. I'm still trying to figure out why that is happening. It might be a conflict with the allowed ranges for the indirect dependencies.

Hmmmm yeah, I wonder how deps would resolve if one of mkdocstrings dev dep is also depending on mkdocstrings :sweat_smile:

Made the change as requested. Also, I believe the linked PR will resolve the issue that showed up in CI for this PR.
Because of the inter-dependencies here, it is OK if this PR hangs out open until you are closer to releasing the new version of this project.


Reviews Page

Hello,
I was wondering if there is a webpage for all of your ✪✪✪✪✪✪ reviews for the app? I need to write mine down with the fancy six-star rating if possible? This is the best thing since sliced 🍞.
This needs to go the extra rating.
Kind regards,
Mic

@sumnermic 😍 ❤ Thank you ☺ BTW, this is a great idea – we'll make sure to discuss it in our next meeting – thank you!

Cool thank you @matheuss .
Everyone, I was messaged back within 2 minutes. Evidence right above me lol 👍
Cheers matheuss

Hi, again!
I'm going to close this issue for now since we decided to keep our landing page clean and simple. If you want to show support for Kap, you can share on social media and that'll be enough thanks for us ❤
Thanks again!


bscfee.wtf

hey there! i just randomly found this and would propose that you add bscfee.wtf to your project. it is the same as fees.wtf but made for the binance smart chain, so you can check all fees paid on BSC 👍🏻
thanks!

bscfee.wtf looks cool, but I tend to keep stakerwatch for the etherum and related ecosystem


Update labels page with new label and updated links

Update to fix https://github.com/mattermost/mattermost-handbook/issues/80

Thanks for the feedback, @jasonblais!


[unstable option] struct_field_align_threshold

Tracking issue for unstable option: struct_field_align_threshold

Two issues I've noticed with this option:
First, it interacts poorly with hard_tabs. The + lines ought to be tabbed equal to len and then space-aligned afterward, but they're being given block indentation instead. Users with different tab lengths will see weird formatting.
This might be easier to visualize by copying the following examples to an editor with space highlighting.
Bad:
	.push_sized(&fuse_kernel::fuse_out_header {
		len:    (size_of::<fuse_kernel::fuse_out_header>()
			+ fuse_kernel::FUSE_COMPAT_ENTRY_OUT_SIZE
			+ size_of::<fuse_kernel::fuse_open_out>()) as u32,
		error:  0,
		unique: REQUEST_ID,
	})

Would be good:
	.push_sized(&fuse_kernel::fuse_out_header {
		len:    (size_of::<fuse_kernel::fuse_out_header>()
		         + fuse_kernel::FUSE_COMPAT_ENTRY_OUT_SIZE
		         + size_of::<fuse_kernel::fuse_open_out>()) as u32,
		error:  0,
		unique: REQUEST_ID,
	})

Secondly, I don't think block-formatted literals should be aligned -- or it should maybe be disable-able. This is how gofmt does it, and it is easier to read when working with mixed primitives and compound literals.
Example of poor formatting:
  .push_sized(&fuse_kernel::fuse_entry_out {
    // ...
    entry_valid_nsec: 0,
    attr_valid_nsec:  0,
    attr:             fuse_kernel::fuse_attr {
      ino: 11,
      ..Default::default()
    },
  })

What I would expect:
  .push_sized(&fuse_kernel::fuse_entry_out {
    // ...
    entry_valid_nsec: 0,
    attr_valid_nsec:  0,
    attr: fuse_kernel::fuse_attr {
      ino: 11,
      ..Default::default()
    },
  })

Is there a similar option for function parameters?

Will this ever be made available in stable Rust?

@wusticality please see https://github.com/rust-lang/rustfmt/discussions/5365

Thanks for adding this option. An issue I have noticed whilst using it is that the formatting isn't applied when using ..Default::default(). For example, I get:
StandardMaterial {
    base_color_texture: Some(asset_server.load("textures/card_back.png")),
    cull_mode: Some(Face::Front),
    fog_enabled: false,
    unlit: true,
    alpha_mode: AlphaMode::Blend,
    ..Default::default()
}

whereas I would expect:
StandardMaterial {
    base_color_texture: Some(asset_server.load("textures/card_back.png")),
    cull_mode:          Some(Face::Front),
    fog_enabled:        false,
    unlit:              true,
    alpha_mode:         AlphaMode::Blend,
    ..Default::default()
}

@theon thanks for sharing. When you have a chance can you create a new issue outlining the problem in more detail. I think it would be best to track this in a separate thread.

Thanks @ytmimi, I have raised https://github.com/rust-lang/rustfmt/issues/6080

Wish this gets stabilized one day 🙏


feat: Allow customization of the supabase root directory name

Is your feature request related to a problem? Please describe.
I have a monorepo that has a very specific naming structure with /apps and /libs folders. The option for --workdir is great when initializing a new project, however I would love to specify the name of the root directory alongside this.
Describe the solution you'd like
Having a cli flag for --rootname <folder name> would be great.
Describe alternatives you've considered
The alternative is to place a parent folder with the desired name before initializing a project. Eg: apps/testproject/supabase.
Something like this is required for multiple projects to exist within a monorepo.
Additional context
This appears to currently be hardcoded in internal/utils/misc.go.
I am unsure whether other considerations are needed such as an indicator for what is a supabase directory or not. Maybe the CLI can automatically detect this based off --workdir or the contents of the cwd.

Do you mean to customize like apps/testproject/custom-supabase? That wouldn't be possible because a lot of our platform's GitHub integrations depend on a directory named supabase.
If you mean apps/testproject/supabase, I think it's already supported with supabase init --workdir apps/testproject flag.

Yes I mean apps/testpropject/custom-supabase - this would be great. Maybe this can be accomplished by having the directory name specified in the config.toml instead of assumed to be supabase always?

config.toml lives inside supabase directory though. How would you suggest we find the right config.toml file if we support custom-supabase directory?

@sweatybridge I'm also interested in the possibility to place Supabase directories anywhere I want in my project.
Next.JS docs encourage a structure where everything is in the src or app folder, and the root directory is only used for config files.
I can imagine a supabase.config.toml file here, or a .supabase directory ' (personally prefer the first solution) where you would provide the paths of supabase stuff!

I see, so perhaps a --config <path-to-toml> flag that can be passed to CLI to override the default location of supabase/config.toml.
Within config.toml, users can declare path overrides for other directories relative to the location of config.toml. For eg.
workdir = '..'

[migrations]
path = './migrations/*.sql'

[seed]
path = './seed.sql'

[functions.slug]
path = '../src/index.ts'

I see, so perhaps a --config <path-to-toml> flag that can be passed to CLI to override the default location of supabase/config.toml.
Within config.toml, users can declare path overrides for other directories relative to the location of config.toml. For eg.
workdir = '..'

[migrations]
path = './migrations/*.sql'

[seed]
path = './seed.sql'

[functions.slug]
path = '../src/index.ts'

This could indeed be handy. I using a monorepo for multiple identical apps with the same supabase setup and would like to have separate config for each project, but use the same migrations/seed etc. This would probably do the job.

I see, so perhaps a --config  flag that can be passed to CLI to override the default location of supabase/config.toml.

This would also be handy to have separate containers and volumes for running e2e tests without touching your development instances.


Rule: use-if and use-contains

It would be nice to have linter warnings for policies that are not using the if and contains keywords as these are planned to be required in 1.0. I looked at the docs and didn't see any rules that matched this description.

Agreed, we should have that in for the next release.
I have a local branch for use-rego-v1 which would suggest this by proxy of the compiler (or if it is the parser, don't remember). But now that we have a capabilities feature, we could easily have both, and suggest use-rego-v1 for the default capabilities, and use-if and use-contains whenever the import_rego_v1 capability feature is missing (which would disable use-rego-v1 with a notice).

A cursory look at this just now reminded me why this isn't as straightforward as it should be. Since neither if nor contains are made available in the AST, our only way to check this is via the text attribute on the rule's location, which as expected returns the text representation of the whole rule. One would think/hope that maybe the rule.head.location.text would provide this, as then we could pretty much just do an endswith check for if/contains but given a rule head like rule := true if {, rule.head.location.text will only give us rule := true.
Finding an if or contains from the text of the whole rule is simple as long as we're dealing with something like  rule := true if {, but once we have rules like:
rule := [x |
    some x in input
    x == 2
] {
    some_conditions
}

It's not as simple. I guess one way to do this is to take the count of rule.head.location.text and then start the search for if or contains at that location in ``rule.location.text`. Not exactly pretty, but I think probably the best way to do it given our limitations.


Update stable version in repo from 2.1.1 to 2.2.1

Think about update stable version to 2.2.1
Version: stable=2.1.1 (172 days old) => latest=2.2.1 (15 days old)
Installs: stable=749 (70%), latest=128 (11.96%), total=1070
Click to use developer portal
Click to edit
Do not close this issue manually as a new issue will be created if condition for update still exists.
Please drop a comment if any reason exists which blocks updating to version 2.2.1 at this time.
Note: This is an automatically generated message and not personally authored by bluefox!
@mcm1957 for evidence

This issue seems to be outdated.
This issue suggests to update the stable version of this adapter to 2.2.1 but the current stable version is already 2.2.1.
So this issue should be closed.
@mcm1957 for evidence


Redesign

Redesign
So I've been working on a rewrite/redesign of sweet.js. Turns out that what we currently have is kinda a rolling collection of hacks that are in desperate need of some rethinking. Things are slow and just getting slower in the branch with ES6 module support so something has to give.
What I'm pushing right now is definitely a work in progress but I think it shows promise. In particular I think it's much more comprehensible for people coming to the codebase for the first time. Read on if you're interested in helping out or just curious as to what might be changing.
Comments/opinions requested.
The current todo status looks something like this:

[ ] add support for all forms (right now I have some of the obvious ones but switch, yield and lots more aren't supported)
[ ] add hygiene (actually should be straightforward, hooks are already in the right places)
[ ] add declarative macros (rule and case, currently just primitive macros "work")
[ ] add module support (not straightforward but doable)
[ ] add infix macros
[ ] add custom operators
[ ] spec out multi-token equivalent
[ ] add line number and sourcemap support
[ ] test each syntactic form
[ ] port old tests
[ ] add perf benchmarks
[ ] add descriptive error messages

No more destructuring
One of the big areas of slowdown came from the fact that we weren't doing real parsing. Expansion worked by building up a partial AST (TermTree) and then throwing all that work away by destructuring the partial AST back to an array of tokens and fed that to esprima to actually produce a real AST.
Now instead of doing all the parsing work twice, we just build the complete AST. This is being handled by two data structures, a Term (roughly equivalent to the current TermTree) that acts as a partial AST (some terms hold syntax objects and some hold other terms) and a Node that is just an ESTree representing the complete AST.
A Term has two methods, parse and expand. The parse method returns a new corresponding Node while expand is roughly equivalent to expandToTermTree in the current expander (ie handles some hygiene details and walks down partially expanded Terms).
The final Node is shipped directly to babel (via transform.fromAST) because ES6. All sweet.js code you write is now ES6 (or at least as much as babel can support).
Recursive descent enforest
The old enforest was weird and complicated and basically a giant if block. The new enforest is still weird and complicated but at least it's a bit more modular.
Immutable.js
Currently the expansion algorithm is written as if we were using lists when in fact it's arrays all the way down. Lot's of calls to concat that should not be happening if we care about performance.
Now we're using immutable.js lists of syntax objects which should be better.
New syntax transformer type
There's a new syntax declaration form (analogous to var/let/const for compiletime values) that looks like syntax <id> = <expr>. Previously sweet supported a couple different primitive macro forms but you could only really put macros into the compiletime environment. This new form allows you to put whatever you want into the env.
Normally (e.g. Racket, old sweet) syntax transformers (aka macros) are just functions but I'm changing things up. Macros are actually objects with two methods match and transform.
syntax m = {
    // List[Syntax] -> {subst: Substitution,
    //                  rest: List[Syntax] }
    match: function(stxl) {
        return {
            subst: [],
            rest: stxl.rest()
        };
    },
    // Substitution -> List[Syntax]
    transform: function(subst) {
        return syntaxQuote { 42 };
    }
};

The reason for breaking matching and transforming out into two functions is hygiene. Currently sweet has to pass some hygiene information to primitive macros so that they can mark syntax that they match and their result syntax. This is gross and dangerous; badly behaved primitive macros can mess us hygiene in various ways. By splitting macros into two functions we can pull the hygiene manipulation code back into the expander.
More details to work out here but I think this is the right factoring.
This of course is just the primitive form, declarative rule can case macro forms will be built on top of this.
No multi-tokens
Right now you can do things like macro (number?) { ... } to create multi-token macros. This massively complicates the expander for not much gain. Hacking the lexical structure of your language can be done with readtables (thanks @jlongster!) so let's do that instead.
Limit infix macros
Infix macros are cool but maybe too cool. The enforestation of operators is massively complicated because we want to allow infix macros to be very flexible. Some heroic work was done by @natefaubion here but I think we are both of the opinion it's not actually worth it.
I think we can still have them but just in a restricted state. My proposal is that they can only match on previously seen Terms and operators create implicit delimiters that infix macros can't "see" out of (so in 2 + inf 42 the inf macro sees an empty prefix list). Just my initial intuition, more details to work though.

I think overall, this is a much needed change, and things are looking a lot better from what I've glanced at.

Right now you can do things like macro (number?) { ... } to create multi-token macros. This massively complicates the expander for not much gain. Hacking the lexical structure of your language can be done with readtables (thanks @jlongster!) so let's do that instead.

I don't agree with this. Without multi-token macros (or some equivalent) it makes it impossible to create (importable) custom symbolic operators. There may be a better of doing it than before, but I think if we are going to keep custom operators, we need a way to keep this around. I don't think read tables are a good solution for this. Read tables are neither modular nor composable. If we want read tables to be used, then I would like to see them used more along the lines of Racket's #lang declaration with an expanded API for controlling the expansion of a module.

I think we can still have them but just in a restricted state. My proposal is that they can only match on previously seen Terms and operators create implicit delimiters that infix macros can't "see" out of (so in 2 + inf 42 the inf macro sees an empty prefix list). Just my initial intuition, more details to work though.

I strongly agree with this. If you make it a single term look behind only (enough to implement arrows), you don't need to keep the nasty zipper-like structure we were using at all.

Macros are actually objects with two methods match and transform.

I don't really like the ad-hoc record. I think we could still keep the single function definition if we had a safe API for extracting syntax from the context rather than manipulating it directly, but I don't know what that would look like. In general, I think it would be good to think about the low-level APIs we need to build things like declarative macros as libraries rather than hard wiring them into our own opinionated system. I think it would be great if sweet.js was just a pure low-level core, but that's just me.
If we did really want to go this route, I think it would be better to go all-in with ES6 classes, and have something like a Macro base class that you can import from some magic-module, where appropriate hooks are exposed. This also makes it easier to pickup which compile-time values are actually macros. Maybe you could also use this to expose AST-transformers rather than just pure syntax transformers. I don't know what that would look like though, just a thought.

Read tables are neither modular nor composable. If we want read tables to be used, then I would like to see them used more along the lines of Racket's #lang declaration with an expanded API for controlling the expansion of a module.

Good points. I'm adding a todo item to spec out what we really need for this. I'd really like to keep multi-token code out of the main expander so my hope is that modules are sufficient. We'll see.

If you make it a single term look behind only (enough to implement arrows), you don't need to keep the nasty zipper-like structure we were using at all.

Is there any reason to cap it at a single term?

I think it would be great if sweet.js was just a pure low-level core, but that's just me.

Totally agree. My thinking is that syntax transformers should be as low-level as possible but not lower than hygiene. Hygiene should be completely handled by the expander, which means that the expander needs to (at minimum) distinguish between syntax provided to the transformer and syntax returned by the transformer.
You're right though, we could still accomplish this with just a single function if the syntax extraction API is "safe".
Hmm...actually the match/transform approach has another problem which is that the rest syntax returned from match is not guaranteed to be correlated with the syntax it put into the substitution (e.g. match could grab all the syntax but return exactly the list provided to it). A buggy match could do some damage.
Ok, so maybe like you said we just need a good and safe extraction API, which would obviate the need to break things out into a pair of functions.
Here's some first thoughts.
Have macros take as their only argument an iterator-like object (so macros don't get direct access to the syntax list, just the iterator). Each time next is called the returned value can be appropriately marked by the hygiene algorithm and when the macro returns the expander knows exactly where the "rest" of the syntax is (whatever was not consumed by the iterator).
So the type of a transformer is something like Iterator -> [Syntax].
syntax id = function(ctx) {
  let macro_name = ctx.next();
  let arg = ctx.next();
  return [arg];
}

A critical part of the API of course is matching against bits of the grammar (like :expr) so the iterator could also have methods like nextExpression that call back into enforest to build up an expression.
// { mylet $id:ident = $init:expr }
// =>
// { var $id = $init }
syntax mylet = function(ctx) {
  let result = [makeKeyword("var")];
  let macro_name = ctx.next();

  let id = ctx.nextIdentifier();
  result.push(id);

  let eq = ctx.nextPunctuator();
  result.push(eq);

  let init = ctx.nextExpression();
  result.push(init);
  return result;
}

This raises the question what should the type of next* be. Currently when sweet sees :expr it builds up a term via enforest and the destructs it down to an array of syntax and then wraps that syntax in a () to keep precedence right (this is confusing to macro authors and leads to bugs). It would probably be better if we could skip the destruct and just have the next* functions have the type () -> Term.
Doing this means that a syntax transformer would now have the type Iterator -> [Syntax or Term] and so the expander would need to handle both syntax objects and terms in the result of a macro.
Does this seem reasonable?

Damn I'm looking forward to this. :smile:

I saw the refactor branch before but somehow missed this PR. This is huge! My favorite part is no more destructuring and building on top of babel. I always hated how much unnecessary CPU time we were using up with all that.
I don't have strong opinions about the new feature-set, as I'm currently not as involved, but man I can't wait to start playing with this again.

Very excited. In the emerging re-design will the ability to create whitespace-sensitive macros be more accessible?

Not directly part of the redesign but it will definitely set us up in a good position to start working on that.

So exciting news! I think we're really close to an MVP for the redesign.
I've published an alpha-tagged version on npm so if you would like to try it out and help find bugs etc. get it at npm install<EMAIL_ADDRESS>This is definitely a MVP so not all the equivalent features from the current 0.7.x version are here yet but I think we now have a solid base to iterate on. My current plan is to shake out the bugs and then get it merged into master. Then we can start working on the features from the deferred list.
I started on the documentation and you can read it here.
This example illustrates the highlights:
// create a syntax transformer (aka macro) with the new `syntax` keyword, which
// is like `let` but for compile-time values
syntax function = function(ctx) {
  // ctx is an iterable that provides access to syntax at the call-site
  let id = ctx.next().value;
  let parens = ctx.next().value;
  let body = ctx.next().value;

  // `of` creates a new context around a delimiter syntax object like parens
  let parenCtx = ctx.of(parens);
  let paren_id = parenCtx.next().value;
  parenCtx.next() // =
  // calling `next` with a string invokes the enforester to match
  // against the grammar
  let paren_init = parenCtx.next('expr').value;

  let bodyCtx = ctx.of(body);
  let b = [];
  // contexts are iterables so we can use for-of!
  for (let s of bodyCtx) {
    b.push(s);
  }

  // syntax templates via #``
  return #`function ${id} (${paren_id}) {
    ${paren_id} = ${paren_id} || ${paren_init};
    ${b}
  }`;
}

function foo (x = 42) {
  console.log(x);
}

Deferred:

Pattern matching (aka macro rules)
Infix
Custom operators
Macroclass
Invoke
Local expand
Syntax function zoo
Source maps
Macro stepper
Read tables
Multi token macro names
Full Modules (import for macros)

Wow! That's an insane body of work. Well done!

Yay! I was just thinking about this today when fiddling with JS! :D

When you planned complete the work?

@vendethiel @zackp30 thanks for the props!
@acterhd software estimates are fiction and doubly so for open source so I won't bother telling you a tall tale. It goes faster when people contribute though so feel free to submit pull requests :)

@vendethiel :)

So in super-cool news the redesign is now self-hosting! Sweet.js is once again building sweet.js!
This means that I'm calling the redesign officially close enough for merging into master. I'm planning on waiting a week to see if any blocking bugs show up but after that I think we can start iterating on a much better foundation.
The pre-release version is available under the pre npm tag (i.e. install it with npm install sweet.js@pre.0). The documentation is available here.

Link from previous post 'here' doesn't work :(

@Alexsey I split the documentation out into the tutorial and the reference.

\o/