logout is not working

I have an app service with the built in Auth/Autentication, using AD B2C.
I can't access the app without logging in first... but when I do a /.auth/logout nothing happens.
Is this a configuration issue or the endpoint is wrong?

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

ID: d4518495-4e07-ce2e-4045-5a50b7922b55
Version Independent ID: 034d1ba0-a737-21ab-3717-ed8798ac5fe1
Content: Advanced usage of authentication and authorization in Azure App Service
Content Source: articles/app-service/app-service-authentication-how-to.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

Thanks for the feedback! We are currently investigating and will update you shortly.

@martinlarosa, The same steps outlined in the document works for me, could you please review the configuration details again and re-try the operation and then let me know for further investigation.

I have a React app, which I understand shouldn't make any difference and an AAD B2C tenant.
I did my best to configure the App Service built in Authentication(I don't know if this has a new name like Easy Auth) and it apparently works. I can login, the problem is with logout. I've seen issues in stack overflow without any valid answer about this. Also I couldn't find a document that would address both AAD B2C and the built in Authentication.

@martinlarosa, By default, a successful sign-out redirects the client to the URL /.auth/logout/done.
You can change the post-sign-out redirect page by adding the post_logout_redirect_uri query parameter, what specific redirect_uri have added? Does it exhibit the same behavior with the default URL? You have stated that “Nothing happens”, could you post a screenshot of the issue after concealing any private details?
There is a discussion on a similar issue here, you may want to take a look and see if that helps, and let us know for further investigation.

I have tried specifying a redirect url without success, but I'll try again and report back. Also will try with a fresh new app.
Can you explain how that discussion relates to my case. Maybe it actually doesn't and that is fine. I just can't see how I can apply that to my scenario.
Thank you for looking into this.

@AjayKumar-MSFT what I'm seeing is that the AppServiceAuthSession I'm getting back in the login callback is set to expire on 1969-12-31T23:59:59.000Z
Also trying to access /.auth/logout/done by hand redirects me to the main page of the app

Thanks for the update and providing more details on this issue.
If your requirement fits and for isolating the issue, in the Web.config file add this to the system.Webserver-tag:

Additionally, the GitHub issue which I referenced, addresses a logout page issue which was fixed by commenting on the change of the main page right after the call, just referenced to a see if a similar approach can be employed in your scenario.
Check to see if this helps. Else, could you send an email to AzCommunity at Microsoft dot com with the below details to investigate this further?
This GitHub thread URL:
Subscription ID:


doesn't work with zoomify

It looks like it expects a newer version of FLK, which we haven't updated to support yet

1.0.1 has the updated versions


Timeout doesn't halt job when max_run_time is reached

We observed this behaviour in our environment, where the same job was being picked up by more than one worker. After some digging around, it seemed that the culprit were timed out jobs that weren't really halting after the timeout period.
Taking a look at the source code, we think we traced the culprit to this Timeout library quirk. By providing a specific timeout class to the Timeout module, we're allowing for the exception to be rescued inside the block  / job. Depending on the execution state of the thread running the job (i.e. if when the exception signal is received, the thread is in a code block wrapped in a rescue StandardError), the job may not halt.
As the max_run_time value was reached, another worker is then entitled to pick up that same job, which ultimately leads to multiple workers potentially executing the same job, at the same time.
I've drafted a quick POC which can be found here - https://github.com/diogoosorio/delayed-job-timeout-example
I believe some of these issues can probably be traced back to this problem.
\cc @magicknot

The issue is there, but the proposed solution isn't great and the recommendation is to fix this at a different level (see #1181). Closing the issue.


Fix issue #62

Coverage increased (+31.9%) to 86.641% when pulling 223900a42603dd8bd0e695a5291519cb6d628891 on issue_62 into 1bb3e919c516b037b16442818751e9c476df4b0a on master.


Better Debug documentation for TypeScript

I'm reading through https://code.visualstudio.com/docs/languages/typescript with the eyes of a TypeScript beginner and I believe Debug Server-Side should be improved.
It says:

Debug Node.js in VS Code using the built-in debugger. Setup is easy and there is a Node.js debugging tutorial to help you.

There are two things I would criticise:

If setup is easy, I'd expect that one of two things would work:

Start debugging by pressing F5, see it hit a breakpoint and see "Hello World" printed to the terminal.
Creating a default launch.json file with the before mentioned Node.js configuration, that leads to the same result as above when a debug session is started.
Both achieve the same thing, with the difference then one stores the configuration in a file. But both call node.exe ./helloworld.ts, which naturally results in a SyntaxError. I would not call this "easy" in a documentation that is clearly targeted towards absolute beginners on "Hello World" level.

The link to the "Node.js debugging tutorial" leads to a tutorial about how to debug a Express app. There are two things problematic with that:

The tutorial does not mention TypeScript compilation or debugging at all.
It doesn't help in the immediate attempt to setup a TypeScript debugger. Instead, it potentially overloads the reader with information about a framework that they are potentially unable to contextualise.

To improve the documentation, I would suggest that a basic or minimal working example is provided, so that after reading this tutorial, he is not only able to compile a Hello World, but also to set a break point, start the debugger and see the "Hello World" being printed to the server-side console.

I agree that "TypeScript debugging" is not easily to find in TypeScript in Visual Studio Code.
The "Debugging" section links to generic debugging pages.
But scrolling down to the "Next Steps" section has a Debugging TypeScript link.
I don't understand why this link is not more prominently located in the "Debugging" section.


Copilot forced removed even without getting ticked in tweaks

Describe the bug
when choosing standard in tweaks even when disabling copilot is not ticked it gets tweaked and removed
To Reproduce
Steps to reproduce the behavior:

Go to tweaks
Click on Standard
run tweaks
See error

Expected behavior
copilot shouldn't get removed as it is not ticked .
even when pressing get installed it shows that removing copilt is ticked

Screenshots

This happened to me, too.

This happened to me, too.

Just open customize  oo and re-enable it ( also re enable clipboard if you wanna use it ) and restart

Awesome. That was it for me, too. Thanks for your help.


[Feature Request] Study on efficiency improvement solutions

Required prerequisites

[X] I have searched the Issue Tracker and Discussions that this hasn't already been reported. (+1 or comment there if it has.)
[ ] Consider asking first in a Discussion.

Motivation
Study on efficiency improvement solutions and integrate necessary solutions
Solution
VLLM: A high-throughput and memory-efficient inference and serving engine for LLMs
Alternatives
No response
Additional context
No response

VLLM in #448


Add Documentation for UserProxyAgent

We need to add documentation for UserProxyAgent introduced in PR #4255
Comment from @ekzhu :

In the doc we need to make the case that there are multiple ways for human in the loop, and user proxy agent is a way that puts the team in a temporary blocking state that cannot be recovered if exception or failure happens. So it should be used with timeout and make sure the exceptions are catched and handled. This approach of human in the loop is for scenarios like just-in-time approval, feedback, alert, etc. For slow human in the loop, consider terminating the team run using termination condition and issue another one from run or run_stream with another message.

Also update the tutorial section which has an example for user proxy agent. Consider removing that or changing it to something else.
https://microsoft.github.io/autogen/dev/user-guide/agentchat-user-guide/tutorial/custom-agents.html#userproxyagent

Also update the tutorial section which has an example for user proxy agent. Consider removing that or changing it to something else.
https://microsoft.github.io/autogen/dev/user-guide/agentchat-user-guide/tutorial/custom-agents.html#userproxyagent

I'll add a section to the agentchat agents section mentioning the UserAgent and its quirks


Could you document what the Delta format looks like?

What do Delta's look like for these tables? How does it differ from the 'official' Quilljs Delta format 2.0 for tables?

Hi, @npcole
quill-better-table has some conflict with the official table module, so you need to disabled the official table module in editor initialize.

About the Delta format,

quill-delta structure is flat, the data structure between red lines correspond to a col html tag, every col will be wrapped with a colgroup tag. colgroup tags will be merged in blot's optimize phase.
Since the checkMerge api of TableColGroup always return true, the colgroup tags will be mreged into only one colgroup tag.

In the delta of table, { insert: '\n' } means that it is a block blot.
{ insert: '\n', attributes: { table-cell-line: { object } } } means that the bock blot is a instance of TableCellLine blot, and the object is attributes of TableCellLine.

@npcole I am not sure if it will help you ?

I will close this issue~


[feature] support sql_mode MODE_FLOAT_LITERAL

What type of PR is this：

[ ] bug
[x] feature
[ ] enhancement
[ ] refactor
[ ] others

Problem Summary(Required) ：
For accuracy, in the past our literal would give preference to the decimal type,
but in some cases we don't care about a precise value, so we provide a new SQL_MODE that gives preference to the float/double type for literals

run starrocks_fe_unittest


The relative PE

Hi, thanks for open-sourcing this excellent work. After reviewing the 'mdm_qnanet.py' code, I couldn't locate the implementation of the relative positional encoding (PE) mentioned in the paper. I'm curious about how this model achieves the generation of diverse results. Do you have any insights to share?

@Kebii, thank you for your interest!
The relative positional embedding is achieved by adding a bias to the attention heads:
https://github.com/SinMDM/SinMDM/blob/main/models/qna.py#L186C13-L186C13
It is equivalent to relative positional embedding because there is only a single "Query" in the self-attention calculation.
We are happy to answer any further questions.


Default logging config prevents server from starting.

Misconfigured logging details.

Commented out postgres DB config, leaving sqlite config as default.


fix: email validation regex updated

Email validation regex updated.
Resolves #15

I updated the minimal user creation since the email is the only field provided.
I'm happy to revert and add another minimal user creation only for the edge case if needed.


Refactor arrow function into traditional function for IE11 compatibility

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
✔

Tests pass?
✔

Fixed issues

@toir427 Found a small BC issue in https://github.com/yiisoft/yii2/pull/18323 released in 2.0.42

Thanks!


can not train on davis car turn

can not train on car turn
have pdb tracing bug
how to solve it?

why train on a subset of video(id 22-id42 in the breakdance-flare)?
why not train with the whole video

How is the data pre-processed? The pre-processing script hasn't been added yet.

why train on a subset of video(id 22-id42 in the breakdance-flare)?

We start from random root poses (equivalent to camera pose). Training on all videos does not always produce correct root pose of the dancer, possibly due to limited batch size.

Does the model only handle the situation when the camera is not moving?

In this work, moving camera is treated as static camera + moving root body.

batchsize 4 only cost 4Ggpu memory.
you can improve the batchsize.
Are you saying that the larger the batchsize, the better performance?

I used your preprocess code but got stuck (pdb) where you break.
Commenting out can be trained, but it seems that the program has bugs.
you can try it with 'car-turn'

Isn't this place data preprocessing code?
(https://github.com/gengshan-y/viser-release/blob/main/preprocess/README.md)

Can you point me where the break happens?
Unfortunately, I have limited capacity do further experiments. In my experience, larger batch size stabilizes training and improves performance. But note that solving dynamic shapes with large deformation from 2D is very under-constrained. I cannot guarantee it works even 2x batch size is used.
You are welcome to test it and let me know if that works.

Re

Isn't this place data preprocessing code?
(https://github.com/gengshan-y/viser-release/blob/main/preprocess/README.md)
I need to make it clear that the codebase's preprocessing code is complete

the result on car-turn is far from useful

at the beginning, the train/flowobs  map is black (on tensorboard).

I remembered it wrong and the pre-processing code was tested. I would suggest do the following.

check whether flow is correctly computed in the FlowFW/Full-Resolution/$sequence-name/ folder
check whether the code loads "black" flow images for breakdance sequence.
find the difference of data format between your sequence and breakdance sequence


Could not find required mod: litematica_printer requires {fabric @ [*]}

Could not find required mod: litematica_printer requires {fabric @ [*]}
Creating Empty clause ?

yea i figured that out, though i thought i had it at the time but apparently not


about THREE.Geometry cleanup

Actual text geometry. Based on extrude.
allow much shorter. toJSON.
allow to keep parameters.

same parameters as current THREE.ExtrudeGeometry.

what is the issue with THREE.ExtrudeGeometry.

it doesn't hold .parameters
so any .toJSON or .fromJSON from the extrude geometry will contains a long list of coordinates

what about including that in the editor.

as the parameters are kept, one could include a text in the scene, save it, reload it, and
then can change the text content
in the editor, there will be a textGeometry widget in the right sidebar, as there is TorusGeometry etc...
so user can pick text content, bevel and all the text generation parameters
if you like the idea, i would be happy to code it
what about .toJSON size

irrelevant


diagnostics\settings.json exception

[IOException: The process cannot access the file 'D:\home\site\diagnostics\settings.json' because it is being used by another process.]
   System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) +216
   System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) +1326
   System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share) +65
   System.IO.Abstractions.FileWrapper.Open(String path, FileMode mode, FileAccess access, FileShare share) +36
   Kudu.Core.Infrastructure.FileSystemHelpers.WriteAllTextToFile(String path, String content) +68
   Kudu.Core.Settings.DiagnosticsSettingsManager.SaveSettings(DiagnosticsSettings diagnosticsSettings) +75
   Kudu.Core.Settings.DiagnosticsSettingsManager.UpdateSetting(String key, Object value) +44
   Kudu.Services.Performance.LogStreamManager.<BeginProcessRequest>b__21_1() +92
   Kudu.Contracts.Infrastructure.LockExtensions.TryLockOperation(IOperationLock lockObj, Action operation, TimeSpan timeout) +218
   Kudu.Contracts.Infrastructure.LockExtensions.LockOperation(IOperationLock lockObj, Action operation, TimeSpan timeout) +26
   Kudu.Services.Performance.LogStreamManager.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) +347
   Kudu.Services.Performance.LogStreamHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) +127
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +103
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +155

Can you please provide more details? This stack doesn't appear related to the Functions runtime at all - where did you get it from? Perhaps this issue belongs in another repo?

@mathewc I've experimented a little. Took an existing function and xcopied to a new folder. That created a new functions, which was a neat thing. Though execution failed with this exception. There's something underneath that keeps track of these folders I suspect.

Where did you get the above exception trace from - the Functions portal? Does it happen every time? Can you provide exact repro steps?

Correct, from the logs windows. I couldn't get that templated function to run after the exception, so have deleted it. Steps I took to get into the mess are:

Have a timer based function
xcopy function to another function (folder)
try to run the new function (time set to every few mins)

This is really a Kudu issue. Tracking on https://github.com/projectkudu/kudu/issues/1999


nvme drive isn't found in installer

Hi! Thanks for your work on this. I'm able to boot into the installer correctly, but once in, not able to see the nvme drive to install to. nvme0n1 doesn't exist in lsblk and any other commands I tried.
Am I doing something wrong?

Did some debugging with a friend who had their system working but wasn't able to find the cause.
Here's journalctl -b0: https://gist.github.com/oliver-ni/ac69582073e68d5e3464ff9fd3664fff
Might have something to do with Line ~446?
I also noticed that the nvme devices showed up in U-Boot normally. They just didn't show up in the installer (nothing at /dev/nvme*, only thing in /dev/disk/* was the usb drive)

I'm not really sure what could be up here. It works fine on my 16" M1 Max machine and I verified we are using the same ISO.
Line 446 is a failure to mount the ESP to grab the WiFi firmware automatically for a better install experience. The NVMe block device will already exist by that point if everything is operating properly.
I assume this persists across multiple boots? Is this using the U-Boot provided by the official installer?

Update: I installed Asahi Arch and built the iso myself there, and flashed it to the usb. That worked, so not sure why the release iso would not work.
Not sure if this is helpful, but the journalctl -b0 output from the working installer: https://gist.github.com/oliver-ni/2786d24c7c4ad1f2d6de35e8a98cd019

If it’s not too much trouble, could you delete NixOS, install Asahi Arch again, and then try with the GitHub ISO? There might be a different version of the boot files between the UEFI only option and the Asahi Arch option.

Did you update Asahi Arch before using the ISO?

That is probably the issue. It looks like the boot files are around a year old. They evidently are not compatible with the latest kernel enough to get NVMe up. Updating Asahi Arch installed new compatible ones. Building the ISO yourself wasn't the thing that fixed it.
I have asked for the UEFI installer boot files to be updated.

I'm facing the same issue.
It seems to affect only my Macbook Pro.
I followed the guide without issue to install NixOS on my Macbook Air, but on my Macbook Pro (with m1 pro chip) the nvme disk is not detected.
(Using the same usb key / iso that I used for the Macbook Air).

I was experiencing the same issue on a 14 inch MacBook Pro M1. I wiped my previous working installation of Arch / Asahi Linux (that was installed from Monterey, if I remember correctly), and installed the UEFI environment from Ventura (13.0).
After replacing m1n1/boot.bin (the boot payload consisting of m1n1 stage2 + u-boot) with the one provided by the uboot-asahi flake output didn't work, I manually recreated the boot.bin file from Asahi Linux. I fetched the packages (m1n1, uboot-asahi, linux-asahi, and asahi-scripts as a reference) from the CDN and did what the update-m1n1 script would do:
cat m1n1/usr/lib/asahi-boot/m1n1.bin linux/usr/lib/modules/6.2.0-asahi-11-1-ARCH/dtbs/*.dtb > boot.bin
gzip -c u-boot/usr/lib/asahi-boot/u-boot-nodtb.bin >> boot.bin

I noticed that the uboot-asahi package is using the u-boot DTBs for boot.bin, while update-m1n1 from Asahi uses the kernel's DTBs:
: ${DTBS:=/lib/modules/*-ARCH/dtbs/*.dtb}

The kernel DTBs are added here. I can't do anything until the Asahi folks update the default installer images. It is possible to fix this issue on first boot by extracting and installing this boot.bin.
To fix this issue:

Install the UEFI option as described in the guide and make sure you can boot into U-Boot (you don't need to boot the installer)
Boot back into macOS
Locate the NixOS ESP. You can check which partition it is using diskutil list in Terminal. It should be named EFI - NIXOS assuming that's what you named the install using the Asahi installer.
Mount and open the ESP using a command like diskutil mount /dev/disk0s4 && open /Volumes/EFI\ -\ NIXOS (depending on partition number and name).
Download and unzip the linked boot.bin.
Copy the extracted boot.bin into the m1n1/ folder on the ESP and replace the existing file.
Reboot into U-Boot and run the installer as described in the guide.

m1n1, U-Boot, and the device trees will be managed by NixOS going forward.
The attached boot.bin can be reproduced by checking out commit 4e27fb9b22baab92af3a311054f136f286d94597 of the repo and running nix build .#installer-bootstrap.config.system.build.m1n1 && cp result boot.bin on an aarch64-linux machine (or x86_64-linux if you wish).

Thank you @tpwrules! I just followed the directions in your comment and was able to install NixOS on the macbook pro M1 :)

This should be fixed in the latest set of Asahi installer images.

I just saw the same problem after following the instructions this morning with the latest Asahi installer, though I did also recently upgrade to macOS 13.4 (MBP 16-inch 2021). lsblk just shows me loop0 /nix/.ro-store and sda /iso. Afraid I'm not in a position to dig further right now.

@Smaug123 a workaround for that issue is available in that thread


Update MemcachedHttpCacheStorage.java

UpdateCAS does not catch timeout exceptions.
getUpdateCAS catches and throws ResourceIOException, but updateCas does not. Try and catch is important since BasicHttpCache would catch this.
https://github.com/apache/httpcomponents-client/blob/master/httpclient5-cache/src/main/java/org/apache/hc/client5/http/impl/cache/BasicHttpCache.java#L273-L286

As we're refining this class, it might be beneficial to catch exceptions in the methods getForUpdateCAS, bulkRestore, restore, and store. Specifically, I noticed that OperationTimeoutException is thrown but not caught within these methods.
WDYT @snehanie

Superseded by 19ab1111c7e947a25afcfa84f1efd4a915e7a7e8

Thank you for the fix. I was going to raise another pull request and you beat me to it.


Support service prefix matching and validation

This is similar to machine prefix matching, but for services. In addition to adding the new PrincipalType this also expands the validation for principals and adds support for custom validation logic that can be applied using custom validators. We previously only validated machine prefixes, but now we also validate services and service prefixes to make sure they conform the proper format.

@jparise FYI, Devin is on parental leave and likely won't reply.


cannot clear the cache with redis driver

Environment
node v19
Reproduction
import { createStorage } from 'unstorage'
import redisDriver from 'unstorage/drivers/redis'

const storage = createStorage({
  driver: redisDriver({ base: 'test:' }),
})

await storage.setItem('item', 'val')

await storage.clear()

// item still exist
const item = await storage.setItem('item', 'val')

after runing the above code, the item is still exist in redis
import { createStorage } from 'unstorage'
import redisDriver from 'unstorage/drivers/redis'

// no items have been set yet...
await storage.clear()

if there is no items in redis initially, the clear mehtod will throw error
ReplyError: ERR wrong number of arguments for 'del' command
Describe the bug
cannot clear the cache with redis driver
Additional context
No response
Logs
No response

looked into the source code and found that the keys are prefixed again in the redis.del call
  async clear() {
    const keys = await redis.keys(r("*"));
    return redis.del(keys.map((key) => r(key))).then(() => {});
  },

should be just return redis.del(keys).then(() => {});
and if keys is empty, it should just return


rover: init at 0.4.8

Description of changes
Add Rover CLI for managing and maintaining graphs with Apollo Studio.
The rusty_v8 dependency took some special handling, and I "borrowed" a solution used in the deno package. It might make sense to extract some reusable portion of that solution, but it wasn't clear to me how to do so.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/help-packaging-rover-cli-written-in-rust/17148/2

This looks good to me.
There are a couple of style changes that could be applied, but I don't think it's worth delaying anything (for example, I see a lot of with maintainers;  instead of maintainers.name in the repo.
Thank you for the contribution!

Thanks @happysalada. I'm happy to make another PR with any followups (style or otherwise) that would improve this. I'd particularly like to add support for platforms other than x86_64-linux, but I wasn't sure how to tackle that.

if you include another platform in a PR, the ci runs and will tell you what error it gets.
it might not be an obvious error, but 90% of the time it's just a missing framework. It says something like missing framework Security. And then you just need to add security from darwin frameworks.


Add hyperterm-bold-tab

Keeping track of your current tab is not instantly visible in the native UI. hyperterm-bold-tab bold's the current tab's text so that you always know where you are!

Checklist:

[x] The title for my package or theme uses its npm title (hyperterm-plugin-example)
[x] The link for my package or theme uses the npmjs.com link (https://npmjs.com/package/hyperterm-plugin-example)
[x] There is a visual representation of what my plugin does in the repo. (Plugin: screenshot or gif || Theme: screenshot of the colors within HyperTerm)
[x] VERY IMPORTANT: I've written a short (one sentence) description for my package or theme of why it's awesome and deserves to be on the list.

Bolds the active tab to make keeping track of your current location simple.

Could you add www to your npmjs.com link? npm 302 redirects it to www automatically.
From the TravisCI build:
https://npmjs.com/package/hyperterm-bold-tab → https://www.npmjs.com/package/hyperterm-bold-tab

Fixed!

Thanks! 😊


[core] Host normalize-scroll-left

I have adapted the source to remove the server-side and setter support. The project has almost no feedback from the community (but is maintained), I think that it's a good signal that can consolidate the logic on Material-UI :).
@alitaheri Thank you for working on such a project!

ESM support was accepted pretty fast

@TrySound It's definitely maintained, I have no concern on this side.

What's the purpose of this PR? every dependency inlined increases app bundle size.

I think that in an ideal world, Material-UI would have zero dependencies because:

I gives us the most freedom, we won't be held back by any of them. We have seen this issue unfold a couple of time, recently, we had strict mode and IE 11 concerns.
It tells our users a lot about our mission, what problem we try to solve.
It feels safer from our users perspective.

Over the last few months, we have been going further in this direction, removed a bunch of dependencies (keycode, react-event-listener, react-select, warning, downshift) and we plan to go further down this direction with style adapters.
Now, in practice, having dependencies can also help us (I have tried to list all the deps I'm aware we have):

React: we don't have the resources to cover Vue nor Angular yet. We have also made it very explicit that React is our core focus and belief that it will hold and be dominant in the future.
jss: we are moving away from any hard dependencies on the styles, with the goal to support multiples engies.
prop-types: industry standard.
react-is: industry standard.
@babel/runtime: industry standard.
hoist-non-react-statics: industry standard.
clsx: hope it will become an industry standard.
normalize-scroll-left: there are very few lines of code, the problem is solved, we are almost the only user of it.
convert-css-length: a potentially good one to host directly. There are very few lines of code, the problem is solved. Maintained by Gatsby's CEO, I can imagine he has more important things to care about. I thought it was a dependency of Gatsby but it doesn't seem to be so. We are the main users of it: https://npm-stat.com/charts.html?package=convert-css-length (notice the change in May).
material-table: we are going with a dedicated Data Grid component.
material-pickers: we are further integrating it into the framework :)
notistack: this is probably a good one we could integrate back into the framework, long term, but not a priority, it has been doing a great job so far.
react-transition-group: I don't think that the current state of transition is awesome, I wonder what we should do about this one.
react-virtualized/react-window: it's almost an industry standard? We will see if we can leverage it for the DataGrid, otherwise, we might have to write a dedicated version, or contribute back.
popper.js: tricky!
material-ui-popup-state: definitely something we should solve in the core, but we never took the time.

@oliviertassinari react-transition-group should definitely be replaced. Some of the animations feel choppy. Maybe react-spring or similar? Especially on mobile with lower CPU you can feel the difference.

It feels safer from our users' perspective.

Feels arguments don't matter. It's indicative of bad education. It's our responsibility to document why we choose certain dependencies.

It gives us the most freedom [...],

I'm not following the freedom argument. The implementation of what dependency would you like to change to fix which bugs/enable what features?

we won't be held back by any of them

We're not that fast. It's hubris to actually believe dependencies hold us back.

react-select [...] downshift

These were not dependencies.

warning

Was removed with an actual rationale beyond "fewer dependencies"

keycode, react-event-listener

Also had a rationale. react-event-listener in particular was obsolete due to better ergonomics with hooks.

We have seen this issue unfold a couple of time, recently we had strict mode [...]

I'm not sure how else to say that because I'm saying it again and again but you keep shifting the blame: That is entirely my fault that it is holding us back at the moment not theirs.

and IE 11 concerns.

And we have IE11 issues in our code. Whether this is caused by a dependency or not is not the cause of IE 11 issues.
So again: What are you achieving by this other than "feeling better"? Objectively this will increase the bundle size for some apps.

Feels arguments don't matter.

I couldn't disagree more. Feeling is the single most important thing in what we are doing on Material-UI.
You might enjoy this podcast on a related topic, it's so joyful https://fs.blog/rory-sutherland/ 😌.

I think that these projects are great baselines:

https://npm.anvaka.com/#/view/2d/vuetify
https://npm.anvaka.com/#/view/2d/%2540angular%252Fmaterial
https://npm.anvaka.com/#/view/2d/vue
https://npm.anvaka.com/#/view/2d/react
https://npm.anvaka.com/#/view/2d/%2540angular%252Fcore
https://npm.anvaka.com/#/view/2d/bootstrap
https://npm.anvaka.com/#/view/2d/lodash

You might enjoy this podcast on a related topic, it's so joyful fs.blog/rory-sutherland :D.

I'm not listening to a two hour long podcast that is suggested to me laughing at me. If you can't explain the arguments of a two hour long conversations then the ownness is on you.

@eps1lon the episode is great on its own, outside the discussion we have here, it has changed some of my perspectives when I first listen it :).

Just a heads-up that removing dependencies breaks the published Material-UI Framer package, as it will have a require for which the dependency no longer exists in Material-UI. As a result, we'll have to coordinate any such releases in the future. Painful.

@mbrookes Do we have to worry about the same issue when adding new dependencies?

(The opposite issue?) Possibly.  Perhaps we need to pin the dependencies in the Framer package? I'll ask what best practice is.

Okay, they've acknowledged that the problem seems to be with their build process, and that the require shouldn't have been there in the first place. They're going to look into the root cause, so we should be good.


chore: release version 1.7.0

Pull Request Test Coverage Report for Build<PHONE_NUMBER>4
Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 92.422%

Totals

Change from base Build<PHONE_NUMBER>4:
0.02%

Covered Lines:
10562

Relevant Lines:
11428

💛  - Coveralls


TS: make it easier for a node.js user to leverage typescript

I recently went through the process of writing a new node module and I gave it a try using TypeScript. Even though I am a developer on VSCode I had to leave Code to search for a solution how to get Intellisense to work for the built in node modules.
Steps:

create a fresh folder
add a simple package.json
add a simple index.ts file (see contents below)
notice an error around the import
find no advice how to fix it

The actual fix was to add @types/node as a dependency but we should offer this to the user when we detect that a built in node module is being used. It is especially weird because we seem to offer this for other 3rd party modules that you add later on.
index.ts
var fs = require("fs");

Result:

I am tempted to mark this "important" because I think a lot of users will stop trying TypeScript after they went as far as I did without searching for the solution. And I think node.js with TypeScript users are one of our main target audience.
It could well be that this issue has to move to the TypeScript repo, but I start here.

I agree that we should be more helpful here. Particularly when you compare this with the experience you have when you do the same in JavaScript. Then, there is nothing for you to do, it just works.

Yes I think it's fairly safe to assume that when we see a module called fs or a require statement, the user wants to install @types/node. I've opened two issues to track improving this:

https://github.com/Microsoft/TypeScript/issues/23224
https://github.com/Microsoft/TypeScript/issues/23224


fr: fmt to even indents only

What is your idea? Provide a use case.
fmt to even space indents only
Why is it a good idea?
pipes lead to blocks offset by 3. Code blocks can then be offset by any number (from 10).
What is the current alternative and why is it not good enough?
use aiken/list.{map}

fn double(x: Int) -> Int {
  x + x
}

fn testing(this: List<Int>) {
  let z = {
    let z = {
      let z = {
        let z = 6
        double(z)
      }
    }
  }

  this
    |> map(
         fn(x) {
           let y = x + 1
           8 * y - z
         },
       )
}

indents: 0,2,4,6,8,9...

Indents should be multiples of 2.
Just wanted to raise it to hear opinions on the matter if any

Im talking about the code block within the parentheses

It's indented by two relative to map( isn't it?

It might be intended. I disagree that its preferable. This is like haskell
and afaik not like rust python elm ... pick a lang
(I'm sure there are others - but i think its a minority)


Initial mqtt port

Porting mqtt module as source and sink apps.
Fixes spring-cloud-stream-app-starters/app-starters-release#8
Fixes spring-cloud-stream-app-starters/app-starters-release#13

We might want to set the version of this project at 1.0.0.BUILD-SNAPSHOT as this is a new addition to app starters.

@sobychacko This versioning is one of a weirdest things in apps. While it's true that 1.0.0 is probably more appropriate but as all apps currently have same version we haven't followed this approach that new app starts from 1.0.0. Or is it a case that since initial 1.0.0 release we haven't added a singe new app?

@jvalkeal we had new apps in bacon, but because of some special circumstances, we needed to baseline everything to 1.2.0. But i think going forward, for new app starters, we should start from 1.0.0.

Merged as fbc87b2bf542265eb657a59386dcd0738d57e2bf with version 1.0.0, some minor checkstyle changes and switch to use AssertJ.


broken build

as in e4f1bfd npm install returns npm ERR! 404 Not Found<EMAIL_ADDRESS>

@pachamaltese I just pushed some an update that includes some recent minor d3plus dependency upgrades. Can you try again and see if you still get this error?

@davelandry I just pulled and did rm -rf node_modules && rm package-lock.json && npm install && npm run build and it works ok. Check this:
    d3plus-axis v0.3.53
    build compile

[ done ] transpiling ES6 for modules
[ done ] bundling build/d3plus-axis.js
[ done ] bundling build/d3plus-axis.full.js
[ done ] uglifying builds
[ done ] creating .zip distribution


Mark auth-helpers packages as deprecated on npm

The Auth helpers package is in maintenance mode and we won’t be actively improving it

Now that the Auth helpers packages are no longer recommended, I'd like to suggest officially marking the packages as deprecated on npm, in order to warn existing users of these packages.
It's also confusing that this repo is called auth-helpers, even though the main supported package is ssr.

please do not do this. SSR is still full of issues and updating would break every app I have built

@oldbettie marking as deprecated would not prevent you from using it; it would just indicate to users that it is no longer maintained.

Will definitely do this quite soon. Read more here: https://github.com/orgs/supabase/discussions/27037


RTI Web App Full v1.0

RTI Web App v1.0
-Open Source version
-Supports Suite 2 and 3

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


Update application email addresses

Update overseas passports application email addresses and fix formatting - opening hours used to show on the same line as email addresses.

LGTM :1:
As per comment elsewhere it would be good to fix the line breaks more globally in govspeak, but this is fine for now.


Stuck after merge a branch  with a single quote in the name

After the attempt to merge a branch with a single quote in its name GitLens stuck with the next message:
Pulling last-price-in-the-trade-form's-price-field...

GitLens Version:

Git Version: 2.17.1

VSCode Version: 1.52.1
ea3859d4ba2f3e577a159bc91e3074c5d85c0523
x64

OS Version: Ubuntu 18.04.5 LTS (WSL, Windows 10 )

Steps to Reproduce:

Create a branch with a single quote in its name
Checkout to master
Do right click on branch-with-a-single-qu'ote-in-its-name
Merge Branch into Current Branch...
Stuck

[2021-01-30 18:32:01:916] /home//.vscode-server/extensions/eamodio.gitlens-11.1.3/dist/gitlens.js:2:844163
Error: Command failed: /usr/bin/git -c core.quotepath=false -c color.ui=false merge-base --fork-point branch-with-a-single-qu'ote-in-its-name HEAD
I guess the solution should be:
/usr/bin/git -c core.quotepath=false -c color.ui=false merge-base --fork-point "branch-with-a-single-qu'ote-in-its-name" HEAD

Can you please verify this fix in tomorrow's insiders edition?
You can install the insiders edition from here. Be sure to disable/uninstall the stable version of GitLens first.


feat(publish): add --summary-file option

Outputs the packages and versions from publishing to a JSON file.

Description
As per Lerna PR 2653

When lerna publish --summary-file <path-to-file> It'll create a file to easily see what's been published and what version has been. Happy to rename --summary-file to something more meaningful
[
    {
        "packageName": "package1",
        "version": "v1.0.1-alpha"
    },
    {
        "packageName": "package2",
        "version": "v2.0.1-alpha"
    }
]

Motivation and Context
As per Lerna PR

When creating a release you don't get a definitive and easy way to see whats changed in a nice output especially if its a pre-release(canary), So added the ability to output a JSON object to a file which would look something like this. #2053

How Has This Been Tested?

Types of changes

[ ] Chore (change that has absolutely no effect on users)
[ ] 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)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report

Merging #428 (b9593e7) into main (a291ec0) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #428      +/-   ##
==========================================
+ Coverage   97.32%   97.33%   +0.01%
==========================================
  Files         147      147
  Lines        4359     4373      +14
  Branches     1011     1016       +5
==========================================
+ Hits         4242     4256      +14
  Misses        117      117

Impacted Files
Coverage Δ

...kages/cli/src/cli-commands/cli-publish-commands.ts
100.00% <ø> (ø)

packages/publish/src/publish-command.ts
99.09% <100.00%> (+0.04%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Update type of all completion handlers

According to Erica Sadun Apple has standardized on using () for parameters and Void for return types. Following that convention, completionHandler: (ModelType?, NSError?) -> () should be completionHandler: (ModelType?, NSError?) -> Void) instead.
(Note the definition of Void: typealias Void = ()).

I assume we can do a find and replace all for: ->() to  -> Void and -> () to -> Void.

Ready for acceptance with 36e16a06af0d1bd7cf768b3eb377a0a11f1cfd0c


[SourceKit][CursorInfo] Add two optional fields when configuring curso-infor request, key.length and key.actionable. NFC

This serves as a skeleton for future extensions on cursor info request.

@swift-ci Please smoke test and merge


Package data integration

The below data are in Google Drive (in various forms) but need to be moved to fortedata. Each may require pre-processing to work with the package (i.e. package data cleaning scripts that are currently or will be in the future, non-public facing, development only scripts). This list adapted from Alley Barry's 2020 stab at this and may need updating. @mgrigri1 @lisahaber @kaylamathes please check to see if there are data not on this list and feel free to add.

note maybe not all of these go into fortedata, for example not sure girdle surveys to check and make sure which tree was killed was the one meant to be killed should?

Filename, followed by description:

[x] FoRTE_CWDSurvey_2019 - coarse woody debris fsurvey from 2019
[ ] Litter_Trap_Masses_FoRTE_November2019 - 2019 litter trap mass data, only 2018 is currently in package
[ ] subcanopy_tree_ids_lisa_max_forte_2019
[ ] CanopyTrees_PhysSampling_2019 - Zeek samples trees from 2019
[ ] Subcanopy_Physiology_Sampling_2019
[ ] Mean_Photo_cond_canopy_2018_WithTreeIDs
[ ] LMA_reflectance_forte_leaves_NO_PINES_2018
[x] FoRTE_dendro_data_clean
[x] canopy_trees_dendro_band_reads_2018_2019
[x] 1-8cm_data_clean
[ ] FoRTE_0-1DBH_data
[x] DendroBands_FoRTE_Fall2018
[ ] individual inventory sheets for each subplot?
[ ] Inventory_CanopyTrees
[ ] inventory_D_rep_girdling_july_2019
[ ] group_d_girdle_survey
[ ] group_c_girdle_survey
[ ] group_a_girdle_survey
[ ] group_b_girdle_survey
[x] 2018 TLS Metadata
[x] "lidar" folder
[ ] 20180701_forte_ndvi
[x] "rld" folder
[ ] forte_plot_spatial_data
[ ] "subcanopy_leaf_CID_reflectance" folder
[ ] veg_surveys
[x] canopy_bands
[ ] LMA_Amax_leaves_forte_2018_FINAL

The "rld" folder contains model generated three-dimensional root length density profiles for pre- and post-disturbance. Useful for hypothesis testing, but likely not needed in the package.

hello

As of June 1st, 2022, " Litter_Trap_Masses_FoRTE_November2019" can be checked off as all data from the initiation of the project up through litter collected in the Fall of 2021 is now uploaded.


PreReq containing macros are mangled

PreReq:         /bin/rm /bin/mkdir /usr/bin/chroot %fillup_prereq %insserv_prereq is transformed to:
PreReq:         /bin/mkdir%{_bindir}/chroot%fillup_prereq%insserv_prereq
PreReq:         /bin/rm

The issue is in the parser of the deps.
@sleep-walker it again end in endless loop, se the latest test commit

Nasty but needed one, thanks for the report.


Option to not drop unmapped properties

W3C CCG's VC HTTP API Test Suite requires that Verifiable Credentials with certain JSON-LD-based Linked Data Proofs do not discard certain properties when expanding a JSON-LD document, as in the following two tests:

"4. The Verifier's Verify Credential HTTP API MUST fail to verify a Verifiable Credential with a property added to the credential." https://github.com/w3c-ccg/vc-http-api-test-suite/blob/61d498cd04c45a22b9578774e6a066b59a8f4e94/packages/vc-http-api-test-server/tests/verifyCredential.spec.js#L80
"7. The Verifier's Verify Credential HTTP API MUST fail to verify a Verifiable Credential with a property added to the proof." https://github.com/w3c-ccg/vc-http-api-test-suite/blob/61d498cd04c45a22b9578774e6a066b59a8f4e94/packages/vc-http-api-test-server/tests/verifyCredential.spec.js#L114-L122

These two tests involve inserting a property-value "newProp": "bar" - in the verifiable credential object, or in the proof object, respectively. Both of those objects are JSON-LD documents. Neither newProp or bar are defined in the JSON-LD context for these objects.
I see two possible ways to accomplish the negative test result:

Throw an error.
Expand the value to something, such that the document's RDF deserialization canonicalization results in a different value, so that the signature verification fails.

Before 7c9fd8e1340e26535f8988068736ca4b6fb5101c, the strict expansion mode added in https://github.com/timothee-haudebourg/json-ld/pull/4 could be used to accomplish 1. Currently the strict option is discarded.
I thought that 2 might be possible if the expansion base IRI option was passed, so that the property would get normalized as a relative IRI reference from the base IRI, but I didn't find that to work. I think I have seen JSON-LD Playground do that sometimes, but I'm unable to reproduce that now. Maybe this only happens when @vocab is in effect?
Some RDF deserialization tests require, however, that unexpandable properties are in fact dropped. FWIW, these are: tc014, tc018, te003, te016, te032, te059, te060, tin06, tpr06, tpr19, tpr36, tpr38, twf02 - which fail in ssi if the boolean for lax/strict mode is changed on this line: https://github.com/spruceid/ssi/blob/3e77c9b/src/jsonld.rs#L1630.
With the previous behavior of the strict expansion mode binary option, ssi could let the properties be silently dropped for RDF Deserialization Test Suite, while instead throwing a key expansion error for VC HTTP API. I think that allowing the unmapped properties expand to some IRI would also address both of these test requirements - but I don't know if there is a valid way to do that... [except maybe to use @vocab in an expandContext with a randomly generated URL and then error if that URL appears in the output.]
jsonld.js handles this issue using an expansionMap option - that seems to be like a functional generalization of the strict mode idea:

https://github.com/digitalbazaar/jsonld.js/blob/20e2286/lib/expand.js#L75
https://github.com/digitalbazaar/jsonld.js/blob/20e2286/lib/expand.js#L61-L65

jsonld-signatures (used by vc-js) passes a function for jsonld.js's expansionMap option that throws an error, saying The property "..." in the input was not defined in the context:
https://github.com/digitalbazaar/jsonld-signatures/blob/9a665c5/lib/expansionMap.js
Would there be any suggested way to accomplish this behavior (an option or technique to continue to expand instead of dropping properties), or could the previous behavior of the strict mode be re-added?

Terms that are not defined in the context are dropped unless:

there is a vocabulary binding defined in the context, in which case it is expanded into the concatenation vocabulary + term; or
there is a : character in the term (that may be what you have seen in the playground?). If the term is not an IRI nor a blank node identifier, it will be inserted in the expanded document as a Reference::Invalid variant. This is new to version 0.3.0, which is why the strict option disappeared (although I forgot to completely remove it, it is currently useless).

If I understand well, you want to avoid silent dropping of terms by either (1) raising an error when one is dropped (2) not dropping them at all. What I can propose is to introduce some kind of "expansion policies" defined in the expansion options:

"normal": the current policy, where terms are silently dropped;
"strict": terms that cannot be expanded and do not contain a : character will raise an error;
"stricter": terms that cannot be expanded into an IRI nor a blank node identifier (whether or not they contain a : character) will raise an error (no instances of Reference::Invalid are created);
"relaxed": terms that cannot be expanded are preserved, even if they have no : character, and made into a Reference::Invalid.

For now I don't have a way to send back warnings generated during expansion, but generating a warning when a term is dropped could also be a solution later.

I've released #14 in the new version 0.4.0.


Updating README with new features

Added workflow samples for using the new env variables to enable traceability features for dockerfile, manifests, helmcharts and acr.

Created PR for branch master : as README reflects in marketplace immediately


Support KILT Spiritnet

Hi,
I would love to use this UI for the KILT Spiritnet. Would it be possible to add Spiritnet to the supported chains?

Hello there, thanks a lot for your interest. I'll work on it in the next days. Can you please contact me on Tg or Twitter (I've the sane handle) since there are some small hosting costs I'd like to discuss.
Leaving this open till it's live

@weichweich I´m ready to deploy and found some active mulisigs. Let me know if that looks right:
    "accounts": [
      {
        "id": "kilt-4oSwk6CpqHDfU9MHUF1stogp8iLwh8CpEBqPQ7LWBemaoxqR",
        "isPureProxy": false,
        "isMultisig": true,
        "address": "4oSwk6CpqHDfU9MHUF1stogp8iLwh8CpEBqPQ7LWBemaoxqR",
        "threshold": 2
      },
      {
        "id": "kilt-4sZ1yyiJnBkMXFMbm5PpF9TeQvbATJQeKJ3paYMW9j7mnYpv",
        "isPureProxy": false,
        "isMultisig": true,
        "address": "4sZ1yyiJnBkMXFMbm5PpF9TeQvbATJQeKJ3paYMW9j7mnYpv",
        "threshold": 2
      },
      {
        "id": "kilt-4sPMk6DgLbaYHaDKWpwFJQVBv3GupqHJRFWngHeALUrv37x9",
        "isPureProxy": false,
        "isMultisig": true,
        "address": "4sPMk6DgLbaYHaDKWpwFJQVBv3GupqHJRFWngHeALUrv37x9",
        "threshold": 2
      }
    ]

Due to the lack of answer here and on element, this deployment will be removed for now :cry:

Sorry! Somehow i completely missed the activity here. :flushed: I'm very sorry.

@weichweich does that mean you want this to happen? I can re-deploy it shortly

Hi, thanks for the effort. I would like to see KILT supported, but I'm no longer working for KILT, so it would be up to another team member. I forwarded the ticket to them, if they are interested they will reach out.

Thank, I'll keep this open until someone tell me they want it :)


scvi-tools 1.1.6.post2 requires anndata<=0.10.8

Checklist

[x] Used a static YAML file for the patch if possible (instructions).
[x] Only wrote code directly into generate_patch_json.py if absolutely necessary.
[x] Ran pre-commit run -a and ensured all files pass the linting checks.
[x] Ran python show_diff.py and posted the output as part of the PR.
[x] Modifications won't affect packages built in the future.

Follow-up to https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/844
Upper bound added in https://github.com/scverse/scvi-tools/pull/2971
Already fixed in feedstock by https://github.com/conda-forge/scvi-tools-feedstock/pull/58
I couldn't figure out a way to insert <=0.10.8. upper_bound uses <, and there was no diff when I tried max_pin. anndata 0.10.9 has already been released (hence the need for the upper bound), so we know that <0.10.9 is equivalent to <=0.10.8

xref: https://github.com/conda-forge/scvi-tools-feedstock/pull/57#issuecomment-2353371071, https://github.com/bioconda/bioconda-recipes/pull/50636#issuecomment-2353603566

@conda-forge/scvi-tools @ori-kron-wis @canergen please review/approve this repodata patch to add the anndata upper bound to the requirements of the 1.1.6.post2 conda binary

python show_diff.py --subdir
s noarch
================================================================================
================================================================================
noarch
noarch::scvi-tools-1.1.6.post2-pyhd8ed1ab_0.conda
-    "anndata >=0.7.5",
+    "anndata >=0.7.5,<<IP_ADDRESS>a0",


tarball url in package.json could be with https

Hello devs,
Thank you for your great work.
In packages.json the tarball url is with http. According to this, registry.npmjs.org redirect all http requests to https anyway.
We would not append our proxy rules just for this.

that url is something that npm inserts when it installs it. it's not in the package.json that is checked into git. maybe reinstall it? otherwise it sounds like a bug in npm?


Update link to modified text/template package.

The link to the modified version of the standard text/template Go package was outdated due to renaming of github.com/icecrime/template to object/template in f1acd2e30cfa5c110fd49530e131b71c1d982b4f.
Thanks for this cool idea!

Cool thank you! :-)


any recommendations how to run this on mac / linux

There is no barrier for os. If you are facing any issue please let me know.


[Bug]: jest --init > testing environment > jsdom - Gives SecurityError: localStorage ...

Version
29.3.1
Steps to reproduce

There is also a repository with the steps done below.

Create a new directory (and initialize as new node project yarn init)
Follow the "Getting Started" tutorial

yarn add --dev jest
Create the sum.js and the sum.test.js
Modify the package.json
Run yarn test and watch everything pass

Follow "Generate a basic configuration file"

Run yarn jest --init
Would you like to use Jest when running "test" script in "package.json"? … yes
Would you like to use Typescript for the configuration file? … no
Choose the test environment that will be used for testing › jsdom (browser-like)
Do you want Jest to add coverage reports? … no
Which provider should be used to instrument code for coverage? › babel
Automatically clear mock calls, instances, contexts and results before every test? … no
Run yarn test, watch it fail

Modify jest.config.js to try to fix the error:// The test environment that will be used for testing
testEnvironment: "jsdom",

// Options that will be passed to the testEnvironment
testEnvironmentOptions: {
   url: "http://localhost/"
},

Watch it fail again.

- OR -

Clone https://github.com/drpicox/demo-jest-init-testenvironment-jsdom.git
Install dependencies (yarn)
Watch it fail
Follow previous step 4
Watch it fail again

Expected behavior
Test run without problems.
Actual behavior
It appears to me that it does not accept the configuration for the jsdom. Something feels not correctly configured.
% yarn test
yarn run v1.22.19
$ jest
 FAIL  ./sum.test.js
  ● Test suite failed to run

    SecurityError: localStorage is not available for opaque origins

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total
Time:        0.186 s
Ran all test suites.

Additional context
Tried configuring and not configuring the testEnvironmentOptions.url.
Environment
System:
    OS: macOS 13.0.1
    CPU: (10) arm64 Apple M1 Max
  Binaries:
    Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.12.1/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.1/bin/npm
  npmPackages:
    jest: ^29.3.1 => 29.3.1

I just checked again.
It has been solved, thanks!
  System:
    OS: macOS 13.1
    CPU: (10) arm64 Apple M1 Max
  Binaries:
    Node: 18.13.0 - ~/.nvm/versions/node/v18.13.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.13.0/bin/yarn
    npm: 8.19.3 - ~/.nvm/versions/node/v18.13.0/bin/npm
  npmPackages:
    jest: ^29.3.1 => 29.3.1

Although the jest version seems the same of the old one. The error message has changed:
% yarn test
yarn run v1.22.19
$ jest
● Validation Error:

  Test environment jest-environment-jsdom cannot be found. Make sure the testEnvironment configuration option points to an existing node module.

  Configuration Documentation:
  https://jestjs.io/docs/configuration

As of Jest 28 "jest-environment-jsdom" is no longer shipped by default, make sure to install it separately.
error Command failed with exit code 1.

If we add the yarn add --dev jest-environment-jsdom before step 4, now it works.
Thanks!


LocationParseError exception

I am getting the following when testing an example rules file on a CentOS 6.6 installation:

[root@Analytics example_rules]# elastalert-test-rule example_change.yaml
Successfully loaded New country login

Traceback (most recent call last):
File "/usr/local/bin/elastalert-test-rule", line 9, in
load_entry_point('elastalert==0.0.75', 'console_scripts', 'elastalert-test-rule')()
File "/usr/local/lib/python2.7/site-packages/elastalert-0.0.75-py2.7.egg/elastalert/test_rule.py", line 289, in main
test_instance.run_rule_test()
File "/usr/local/lib/python2.7/site-packages/elastalert-0.0.75-py2.7.egg/elastalert/test_rule.py", line 277, in run_rule_test
hits = self.test_file(copy.deepcopy(rule_yaml), args)
File "/usr/local/lib/python2.7/site-packages/elastalert-0.0.75-py2.7.egg/elastalert/test_rule.py", line 54, in test_file
es_client = ElastAlerter.new_elasticsearch(es_config)
File "/usr/local/lib/python2.7/site-packages/elastalert-0.0.75-py2.7.egg/elastalert/elastalert.py", line 130, in new_elasticsearch
timeout=es_conn_conf['es_conn_timeout'])
File "/usr/local/lib/python2.7/site-packages/elasticsearch/client/init.py", line 150, in init
self.transport = transport_class(_normalize_hosts(hosts), **kwargs)
File "/usr/local/lib/python2.7/site-packages/elasticsearch/transport.py", line 113, in init
self.set_connections(hosts)
File "/usr/local/lib/python2.7/site-packages/elasticsearch/transport.py", line 166, in set_connections
connections = map(_create_connection, hosts)
File "/usr/local/lib/python2.7/site-packages/elasticsearch/transport.py", line 165, in _create_connection
return self.connection_class(**kwargs)
File "/usr/local/lib/python2.7/site-packages/elasticsearch/connection/http_urllib3.py", line 48, in init
self.pool = pool_class(host, port=port, timeout=self.timeout, maxsize=maxsize, **kw)
File "/usr/local/lib/python2.7/site-packages/urllib3/connectionpool.py", line 144, in init
ConnectionPool.init(self, host, port)
File "/usr/local/lib/python2.7/site-packages/urllib3/connectionpool.py", line 70, in init
raise LocationParseError(host)
urllib3.exceptions.LocationParseError: Failed to parse: None
My config.yaml is:

rules_folder: /etc/elastalert/rules
run_every:
minutes: 1
buffer_time:
minutes: 15
es_host: localhost
es_port: 9200
writeback_index: elastalert_status
alert_time_limit:
days: 2

I've confirmed that Elasticsearch is running:

[root@Analytics example_rules]# curl -XGET 'http://localhost:9200/_count?pretty' -d '{"query": {"match_all": {}}}'
{
"count" : 3909430,
"_shards" : {
"total" : 236,
"successful" : 236,
"failed" : 0
}
}

Any ideas why this is happening?

Do you have es_host set in your rule? It looks like it's trying to use None as the host, which makes me think it is not parsing the yaml correctly or you have es_host: set without a value somewhere.

I did not have es_host set in my rule. I was following the directions at the link below and assumed it would carry over from the config.yaml file. Thanks for your help!
http://elastalert.readthedocs.org/en/latest/running_elastalert.html#requirements

It does carry over from config.yaml. Did your issue get resolved? What did you do?

It does carry over, but only if es_host is completely missing, not just unset.

I see. Thanks for the explanation. I had not set the es_host value in the example file I made, and was not using the config.yaml file shown in the example.


more component discussion

I spent part of the weekend convincing myself the types for component are wrong. Components are a black hole, it's not possible to interrogate them (for example, asking an Ace component what the current contents of the buffer are). While components emit declarative information in response to every input, that's not useful for communication; they cannot yield event information except in response to user input.
I think the signature I'm really looking for is something like this:
newtype Component p m i req res = Component (SF1 (Either i req) (Tuple (HTML p (m i)) (m res)))

type ComponentW p m req res = ComponentW (exists i. Component p m i req res)

This is possibly not exactly right, one can imagine wanting the Tuple to be an Either, but that's not precise enough either and allows a component to refuse to emit HTML. OTOH encoding more strictly reduces the power (e.g. prevents emitting res from user input or prevents updating HTML in response to requests).

If you use Tuple as in your first example, you won't be able to send non-external messages on user input, and if you use Either, you don't necessarily ever get a document to render.
What's the problem we're trying to solve?

I do think there is a problem with Component though, which is that they aren't as composable as raw signal functions. I think the existential gets in the way. It makes it hard to have things like lists of components, because you can't construct the appropriate existentially hidden type in any sensible way to combine them.
I think a good step would be to make the internal message type into a type variable, instead of quantifying it. Then we could write combinators like
list :: forall p m i res req. List (Component p m i res req) -> Component p m (Tuple Int i) (Tuple Int res) (Tuple Int req)

Either that, or just get rid of the Component abstraction entirely, since at that point we're basically back to a newtype on top of raw signal functions anyway.

What's the problem we're trying to solve?

It's quite simple: take the hypothetical Ace component as an example. Right now, you can build a toolbar which sends commands to the Ace component, as we have done in examples. But if you want to, for example, retrieve the content of the editor, or do any one of numerous other things, you have to go outside the component interface, or send something like AVar to a component, which will lead to very imperative code.
Components need a way not just to receive information, but to send it, more than that, to reply to requests for information. That's the only way a component can be completely encapsulated.
On the whole existential thing, I think the component's wrong type signature is really what's screwing it up here. Ideally, there would be two forms, a raw component:
newtype Component p m i req res = Component (SF1 (Either i req) (Tuple (HTML p (m i)) (m res)))

and one with existential hiding which is much easier to compose:
type ComponentW p m req res = ComponentW (exists i. Component p m i req res)

because you don't have to worry about i, useful when you want to crush the entropy that otherwise accumulates and seal off the possibility of driving a component with fake inputs.

If you use Tuple as in your first example, you won't be able to send non-external messages on user input

Well, user input can affect the state of the component, which can in turn yield res values. But yeah, I agree the type signature is not exactly right, at best it's an approximation.
Part of the problem is that ideally the component can respond to input or respond to requests, but is constrained by the fact that it must continuously produce a model of the HTML (indeed, this is necessary since one can imagine many requests updating the HTML).
 One cannot obtain any data about the state of the component, which prevents creation of a useful Ace component, and also prevents our use case for Cells being Components which communicate to the container via a well-defined ADT protocol.

As I say, I agree that something isn't quite right, but this would be a massive departure from what we've already done. At the start of the project, I suggested using explicit reactive variables, and passing them around, allowing us to potentially create data dependency graphs with cycles, but we decided the approach was too imperative. That's the reason I liked the signal function abstraction - there's a really clear, pure interpretation, and you can still represent cycles by tying the knot at the top level.
In fact, I'm not convinced we can't do what you want to do with the cell component - why do you think it's impossible? Even with the Ace example, you can keep the current content as state if you like, just by emitting events when the content changes. I guess that without more details about why you think things don't work, it'll be hard to make progress on this.
I'm not sure if adding another type of Component is the best option. We already have SF and Component, and ComponentW can be easily implemented in terms of Component above, by setting i to be Void.
Is the problem that you want the signal functions to be more like bidirectional channels? If so, I'd like to try to convince you that we don't need them, since the tying-the-knot trick essentially gives us bidirectionality.

The point is that this signature is wrong precisely because it creates a black hole

That is by design though, right? We didn't want arbitrary access to state. req was there to control what writes you were allowed to request, and res was there to control what information about the state you wanted to leak to the outside.
One approach might be to unroll the nu-type in SF1:
newtype SF1 s i o = SF1 { state :: s, step :: s -> i -> Tuple o s }

but I'm not sure that buys us much, or that it's a good thing to make the state visible.

It makes it hard to have things like lists of components, because you can't construct the appropriate existentially hidden type in any sensible way to combine them.

What if components had some notion of identity, such that you could do routing like that? It'd have to be done in FFI or (carefully inspected and tested) unsafe PS, but might be possible.

req was there to control what writes you were allowed to request, and res was there to control what information about the state you wanted to leak to the outside.

The problem is you cannot emit res whenever you want. Rather, req can affect state, which can affect view, and can therefore affect res, but req cannot be responded to with res.
Let's take the Ace component example. I want a toolbar that takes the current selection and makes it bold. The Ace component doesn't know anything about that (it would be conflation of concerns). Currently, I can send some commands to Ace to insert text at the current position -- but what I really what is to get the current selection, so I can apply my bold formatting to it, and then overwrite the current selection with the text.
The protocol supported by this component might look something like this:
data AceReq = InsertText Int String | GetSelection | ...

data AceRes = Selection Int Int | ...

This provides a way for me to get information out of the component on-demand. The alternative is to provide all possible information as events, so that parents can reconstruct the state from a monoid on the events. That requires component-users to know enough about the way a component works to be able to recreate its internal state tracking behavior by monoidally appending its events. This does not seem like it's an example of good design.
Also widgets cannot necessarily be made to produce all the events which can reconstruct the internal state of the component, making the strategy only usable for pure Halogen components.
In SlamData we want to use components for cells, which presents many of the same challenges.
Unrolling the nu-type is in some sense equivalent to allowing requests to return responses, but only for a pure Halogen component; for a widget the state may be stored in the DOM.

That's the reason I liked the signal function abstraction

I'm not suggesting an impure abstraction, only a pure one that allows components to selectively emit information. Right now req is always equal to res because that's the only thing that makes sense, so you have this invariant functor in which both requests and responses must share the same ADT (which is a bit like taking a function a -> b and turning it into Either a b -> Either a b just so you can make it i -> i for some i). While that makes the functor invariant and limits composition, the bigger problem is that the component may emit no information except on user input events (or initializers / finalizers), which does not permit "state interrogation" and creates barriers for encapsulation.

I think a good step would be to make the internal message type into a type variable, instead of quantifying it. Then we could write combinators like

These sorts of solutions work good for small examples, but remember that you cannot ever throw away any information, so the tiniest little internal details of some component deeply embedded into some button of a widget will propagate by sheer brute force to the top of the application. I think that's some of the complexity that @garyb is struggling with right now.

Let's take the Ace component example. I want a toolbar that takes the current selection and makes it bold. The Ace component doesn't know anything about that (it would be conflation of concerns). Currently, I can send some commands to Ace to insert text at the current position -- but what I really what is to get the current selection, so I can apply my bold formatting to it, and then overwrite the current selection with the text.

The way I figured this would work would be to have a single input to the Ace component like
data Input = MakeBold (Maybe Selection) | ...

Really, it sounds like you want your inputs to be commands with return types. Effectively they all have return type Unit right now.
 SF1 (FreeC f) (Either i req) (HTML p (m (Either i res))))

Quite a mouthful, but maybe we can break it up.
The idea is that if you want the internal structure of your component to support commands like getSelection which returns a Selection, you build some free monad which describes those commands, and then bake that into your signal function. So this is not to be thought of as effectful signal functions, but signal functions in which we support some internal commands. For the vast majority of cases, I imagine f will be trivial.
To interpret this, you need a natural transformation taking FreeC f to something like Eff.
To combine components, you take the free monad coproduct, and get to use Inject to compose things.
I think this might be overkill, personally, but it might work, and you still keep the state internal to the component - you just get a better language with which you can compose commands - which means your commands can be finer grained and actually isolate things better.

Really, it sounds like you want your inputs to be commands with return types.

Yes, session typing is really what I want but that's impossible in PureScript (at least in any usable fashion, AFAIK).

you build some free monad which describes those commands, and then bake that into your signal function

I think this approach has a lot promise and we should think about it more seriously. I need to inspect your proposed types more to understand the power and limitations of the approach.
In retrospect my example of a "function on state" is not exactly the best example because of this encoding:
data Selection = Selection Int Int String
data AceReq = GetSelection (Selection -> AceReq) | SetSelection Selection | ...

But as a protocol it still conflates request type and response types, leads to the ever-present invariant functor, etc. Also doesn't really avoid the problem: how can I tell the component to give me its JSON serialization so I can embed it in more JSON? I can't, my "function on state" can only issue commands the component already understands. It's broken.
We do need to hammer this out and relatively soon. I'll spend more time on the free approach.

I think I'm overthinking the Free approach. If we want the requests to be able to support a rich language of terms with things like getSelection, maybe we can just use an input type of Free f Unit for some f. I think that's sort of what you're saying above, right? We keep the "black box" property of the components, but get a nice language with which to make requests.
On the one hand, you have a simple ADT of inputs - not very expressive, but controlled. On the other hand, you have something like s -> Node -> Eff eff Unit - very expressive, but completely uncontrolled. I think a free monad could be a nice compromise.

I quite like the sound of using Free for this too. I've not followed the fine details of the discussion enough to have much of an idea on whether it fully solves the problem, but in principle it certainly seems promising.

Another thing I've been thinking about is how to share between components. Right now, there isn't really a good option, you have to just build one big component. One way might be to expose the state type in the signal function:
newtype SF1 s i o = SF1 { state :: s, step :: s -> i -> Tuple o s }

This would let us write a whole bunch of new combinators (including using lenses for composition), but I think we lose Apply (in the current version, we tuple the state types in <*>).
One option could be to split the rendering function out:
newtype Render s o = Render (s -> o)

newtype SF s i = SF s (s -> i -> s)

(this is starting to look quite a bit like thermite actually), so that you build your rendering function using things like Applicative, and maybe lenses too, and build your signal function separately. This way, different components can share parts of the state, but have their own parts too.

So here are the following problems with the Free approach sketched out above:

The monad requires an interpreter, and the Component is the only thing that knows how to interpret it. That is, a component is the only thing that knows how to interpret its F-algebra, so it must be the one to do the interpretation, or at least provide a natural transformation to some more generic algebra (or monad).
The Component interpretation of its F-algebra must be pure or have effects limited to m. Actually, the restriction is even more severe, since a Component is not allowed to have effects m, but it can produce event handlers which produce m-effectful events. The distinction is extremely important, because it means that if effects are required to answer a query in f, those effects have to be deferred until some arbitrary handler does something interesting in the future. This is nonsense, unfortunately.
The f input passed to the Component cannot represent in any meaningful sense the rest of the program. This means if it's going to have any effect on the world, it will have to do so through effectful, imperative code (it's basically a callback!). So all your input commands to the Component must terminate in something like AVar's putVar, or Eff or Aff or something equally effectful.
If Free f Unit is the input, then Free f Unit must be the output, to satisfy the way Halogen wants UIs to work, which not only conflates internal state updating events with external commands, but makes the output useless to anyone else, since in general interpreting the output would require the ability to interpret the F-algebra, something only the Component knows how to do.

In summary, the idea of using Free monads to describe DSLs for components sounds attractive, but I have no idea what it would look like in practice. If it can be made to work, I don't think it would be any minor modification of type parameters to SF1. It would be a total rethinking of the approach and I don't know what that would look like.
I took another look at bichannels, and it's not quite right either:
type Bichannel a a' b b' f r = Channel (Either a b) (Either a' b') f r

One can imagine a -> a' as being specialized to i -> i, that is, events driven by the user, which makes it invariant with respect to i, but which can be existentially hidden (if desired); and b -> b' as being req -> res. But here channels are allowed to terminate with final result r, which is not needed for Halogen (although one can imagine using it for closing dialogs and the like). Also the effect f is very powerful, capable of blocking any UI output.
newtype SF1 s i o = SF1 { state :: s, step :: s -> i -> Tuple o s }

This solves sharing between components, which permits upward propagation of state information (i.e. parent can peek into children's state). It sort of awkwardly requires that children expose answers to all possible queries in part of their state (e.g. the current selection, the line number, the number of lines, the text of the buffer, etc.), which may not yield good performance, especially with 3rd-party widgets -- and assuming its doable at all, which it seems not to be for widgets because that state changes at arbitrary times (from the components point of view).

I think we lose Apply (in the current version, we tuple the state types in <*>).

We actually don't need that, we just need IApply, i.e. the invariant equivalent, which permits zipping these things together, creating tupled s's that can then be unnested and fed to an iso-function. Need PRs to purescript-invariant. :)
newtype Render s o = Render (s -> o)

newtype SF s i = SF s (s -> i -> s)

Here are the capabilities I'd like to see:

Component can handle input generated from its own event handlers. In theory, this can be existentially hidden, because the values are generated internal to the component and consumed by the component. In practice, sometimes it might be nice to feed a component fake input.
Component can respond to requests for information (generally, these are queries about state, but in the case of a widget, whatever state the pure part has is probably incomplete compared to the state that exists outside the pure part).
Component can signal parent with new events. I'm thinking, a user clicks on an echart, and the echart notifies the parent component. Something like stackable bichannels here, but it can't be monadic (too powerful).

Exposing the state is orthogonal to (1) and maybe (3), and seems to partially solve (2), at least for pure components (with a big question mark for widgets).
What kind of types let us do that?

Component has some initial state s.
Component has a renderer for that state which produces inputs i.
Component accepts internal input i or external requests req and effectfully (?) produces s -> s and res.
i (and s) can be existentially hidden and in the case of widgets, there are no is produced or consumed (Void), because the state's all hidden; effectively, widgets just accept req and produce res.

I think approaching it from the point of view of, "What do widgets force us to do?" is helpful. For example, sharing state works for communicating information to parents, but is problematic for widgets. That sort of thinking which uses the common denominator between pure component and widget to extract out a facade that works for both.
One thing separating state seems to allow is for the signal function to not produce the view -- only to produce a state updater (newtype SF s i = SF i -> (s -> s)). The reason I like that is because a state updater can be produced inside Aff without blocking the UI. There are no race conditions between state updaters because they don't have any "old" state to capture over.
So one can imagine a component being able to respond to requests and produce state updaters both inside the same monad.
newtype Component p m req res s i =
  Component { initial :: s, render :: s -> HTML p i, step :: Either i req -> m (Tuple res (s -> s)) }

Although this could probably be cleaned up quite a bit! It's invariant in i and s, have to think if both those can be hidden & composed with the usual invariant machinery. Here m would be Par eff and not Aff eff because composition should be in parallel and not sequential (also monad may be too powerful).
In this representation, it doesn't matter or what effects transpire to (a) reply to a request, or (b) produce a state updater; the UI is never blocked and there are no state race conditions.
Actually, it's getting late and I've been really sick, so I want to rethink this over the weekend! :smile:

The monad requires an interpreter, and the Component is the only thing that knows how to interpret it

Yes, but I don't see that as a disadvantage. The free monad is just another data structure. We already write interpreters for our inputs, using pattern matching.

If Free f Unit is the input, then Free f Unit must be the output, to satisfy the way Halogen wants UIs to work

Only at the top level. Individual components do not have this restriction, it's just that when you glue your components together, the final component must have res = req.
I'm not suggesting the free monad approach as a general framework, just another technique which users can use to structure their code. I wouldn't even include support for it in halogen.
I've been thinking about the problem in the following way: before we had Component, the library was expressive but things were hard to compose. It is perfectly possible to write a full app using SF and HTML, composing things by hand. The problem is that it requires a lot of manual plumbing, and the question is, how do we make this less painful?
Component gives one answer, but not a great one in my opinion - it solves one problem, but at a massive price in terms of composability.
I think the better approach is to stick to SF and HTML, and to provide better tools for composing them.  In most practical code, people don't seem to be using Component anyway.
I think invariance is just something we have to deal with if we want to stick with the signal function/no disappearing information approach. I do think lenses can help, but I don't fully see how yet. Maybe we can restructure things to make lenses more applicable (thermite does a decent job of this, I think - see @joneshf 's changes on the todo-mvc example).

Another option, which I've thought about, but I don't fully like, is to have a Component represent an effectful, self-contained bundle of views and logic, a la React. You would still be able to send messages in, and subscribe to outputs, but diffing would be contained inside the component. This pushes us in the direction of manually-configured graphs of components, which I don't like as much. The global diffing approach is a bit inefficient, perhaps, but allows for some nice abstractions.

Yes, but I don't see that as a disadvantage. The free monad is just another data structure. We already write interpreters for our inputs, using pattern matching.

Perhaps I should have made the point more forcefully: the free monad approach cannot work at all in Halogen. The only way to leak information out is through event handlers, which fire only in response to user input. So a free monad can only be used for "write-only" DSLs, which is not necessary since you can just pass (input) parameters to the component.

Only at the top level. Individual components do not have this restriction, it's just that when you glue your components together, the final component must have res = req.

For all practical intent and purpose, req = res. It's theoretically possible for them to differ but then the SF / component cannot respond to its own input, which is relatively useless. At the very least, res is a superset of req. Also I've never seen real code in which they differ. :smile:

I'm not suggesting the free monad approach as a general framework, just another technique which users can use to structure their code. I wouldn't even include support for it in halogen.

Again, the free monad approach is a dead end, there is nothing useful that can be done with them in the current design. One can imagine bundling the interpreter (natural transformation from f ~> Aff eff with the component, that would make it useful but extremely imperative. An m in a SF output can of course be a free monad but cannot be interpreted by the component (so it's really a way of providing a DSL to components that they can use, not exposing a component-specific DSL to consumers of components).

The problem is that it requires a lot of manual plumbing, and the question is, how do we make this less painful?

I'm all in favor of this. I think Inject1 helps and beefing up purescript-invariant would also help quite a lot.

Another option, which I've thought about, but I don't fully like, is to have a Component represent an effectful, self-contained bundle of views and logic, a la React.

My main drive for this is widgets, i.e. those colossal JS libs that are impossible to replicate in any reasonable amount of time (ace, echarts, etc.). Widgets by their very nature bundle MVC together into a self-contained, encapsulated package that can be snapped with other such bundles. So if your requirement is to be able to use widgets, you need an abstraction capable of bundling together MVC, which composes with the rest of the library (i.e. non-widget implementations).
When you have an MVC bundle, what do you need to do with it? Add event listeners and send it commands / requests that have responses, and of course plug it in somewhere in your HTML. Those are the fundamental requirements to using third-party Javascript components. They have equal expressive power to React components for the same reason.
In PureScript, components can benefit from strong typing. Moreover, every DOM element can be viewed as a component, which responds to commands / requests, emits events that can be listened to, and is located somewhere in the DOM. Components are in some sense the "assembly language" of the DOM.
If the framework were capable of typing a third-party widget with no expressive power in a way that composes with "the rest of the library", then theoretically you could take advantage of that same power to define, e.g., a reusable look-ahead component, as @natefaubion wanted to do, without any nasty FFI code or third-party library.
All this is academic right now, but I feel there's a good chance an ace widget will be poorly typed and / or fail to serve the needs of SlamData (but I guess we'll see soon, maybe next week). Beyond that, we have these things called "cells" in SlamData which are intended to be uniform bundles of MVC that can be written externally in JS or other AltJS languages, for which we need some abstraction that will have to somehow interop with Halogen. TBD exactly what that will look like.

Perhaps I should have made the point more forcefully: the free monad approach cannot work at all in Halogen.

Ok, I'll drop it, but I just want to clarify a couple of things.

So a free monad can only be used for "write-only" DSLs

Absolutely, it doesn't offer anything new or solve a problem, it's just a different way of structuring the input.

At the very least, res is a superset of req. Also I've never seen real code in which they differ.

The Ace example has two components where res /= req. In general, I think we want to be able to decompose a large sum into summands in different ways, which I think is why Inject1 is so helpful.

When you have an MVC bundle, what do you need to do with it? Add event listeners and send it commands / requests that have responses.

I really think we need to reconsider (possibly-)effectful signal functions, but I still don't really understand why we need to query the Ace editor. It seems to break our abstraction, and I feel like we can already do the same things with event handlers (instead of "give me your current selection", we subscribe to selection-changed events).
I don't really like the way widgets are modeled in the HTML document right now. I feel like there is possibly a better approach than just sticking a Widget in a placeholder. For statically placed widgets, we could model them externally and use the driver function to push their events into the system.
Our two main problems seem to be

Being able to treat widgets like pure components
How to compose signal functions (I would say this is solved, but the solution isn't ideal)

I feel like things are largely solved for the pure case, and the issue is really how to deal with widgets. I don't know what the solution is yet, or even if there is one.
I still like the option of using the driver function to push effects (including reading from/updating widgets) to the boundary, but that might not work so well with dynamically generated widgets. It's probably still worth considering though, and I might spend some time looking into that.

It seems to break our abstraction, and I feel like we can already do the same things with event handlers (instead of "give me your current selection", we subscribe to selection-changed events).

That assumes two things which are not true in the general case:

That the component broadcasts all state changes in a way that can be used to reconstruct the internal state of the component. For example, a component which allows a user to draw on the canvas does not broadcast individual painted pixels, nor does Ace broadcast many changes to internal state. A pure Halogen component has the guarantee that its internal state can be duplicated using the initial state and the events coming from the component, but no such guarantee exists for 3rd party components (and, in general, it does not hold for such components).
That the client subscribing to the state changes knows how to combine them in such a way to yield an accurate model of the component's internal state. For example, if all you get from the component are key pressed events and keyboard arrow events, then you have to build the state of the document from these events and hope you did so correctly.

Thinking more about (1), one thing I like about the "explicit state" is that it really hammers home the point that the state is purely determined by the initial state and the succession of events produced by the HTML (s, s -> i -> s). It should also be faster since it's one function versus lots of dynamically created functions capturing over state.
But regardless...

Being able to treat widgets like pure components

I'd say it's more like "being able to integrate all of the impure functionality provided by 3rd party widgets into the semi-pure framework of Halogen". The internal state of foreign widgets cannot be re-created from the events they emit, so if you cannot query them in a pure, type-safe fashion, you have no access to that state. Even in cases where you can re-create it, do you really want to, e.g., recreate the contents of an editor's buffer from primitive operations on it (this is just a random example)?

For statically placed widgets, we could model them externally and use the driver function to push their events into the system.

This would be cleaner but I'm not sure it solves the information problem above.
Widgets really want to be something like:
type Component p m req res s i =
  Component {
    initial :: s,
    render  :: s -> HTML p i,
    ask     :: req -> s -> m (Tuple res (s -> s)),
    update  :: i -> m (s -> s) }

which composes and can easily be pure, but which doesn't fit so well into Halogen.
One way I can see for making Ace fit Halogen is to effectfully interact with the widget to get the editor's buffer, the caret position, this and that, etc., and stuffing that into a gigantic record (basically, a series of responses to all possible queries). Then on any event that ace exposes, you can include the big, dynamically generated record, which gives you access to the (formerly internal) state of the component.
Another option on some widgets may be trying to expose enough event information that it's actually possible to write a function s -> i -> s for some useful amount of state.

To a certain extent, that's what the original Ace example did:

It represented the Ace widget as a pure function from a state (just the buffer contents at that point, a String) to a Widget.
update is essentially "diff the state with your internal state, and apply a patch operation", which in this case was just "set the buffer content to this String".

This approach is slower obviously, but maybe it's not a bad option if the data is small.
There are conditions on update so that you don't run into the "updates being applied twice" issue we saw before. Basically I think the conditions amount to:

update being idempotent: update newState *> update newState = update newState
update respects the current state: getState >>= update does not change the component's internal state.

In the case where we had to version events to prevent duplicate updates, the second law was being violated: if the current buffer was non-empty and the current state (last input) was ClearText, then getState >>= update would clear the buffer, which affected the internal state of the component.
This is probably only a good option if we decide to go the route of ditching Component and developing the SF machinery though (@garyb reported good experiences with lenses for example, and there's also Inject1 now as well).

update is essentially "diff the state with your internal state, and apply a patch operation", which in this case was just "set the buffer content to this String".

This would be truly horrifying for a widget allowing the user to paint on a canvas. Only slightly less horrifying for Ace. :smiling_imp:

This is probably only a good option if we decide to go the route of ditching Component

Increasingly, I don't see much value in current definition of Component vs just wrapping a widget as a SF (you can send write-only commands to the component, but you can do that already through SF interface).

Increasingly, I don't see much value in current definition of Component

Agreed, its only value is to hide a few Eithers. I would gladly get rid of it in 0.5 until we can figure out something better.

@jdegoes What do you want to do with this now that #105 and #106 have been merged? I think post-render hooks give us a way to query widgets, and for components, the new approach seems to be plain signal functions and (soon) isomorphisms.


Examples, please!

Would love to see some examples on this page, or links to where there are suitable example.

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

ID: fbd309ae-5573-bd9f-9b72-137ac7d1ca72
Version Independent ID: 28c4c225-ca8d-635b-b959-c4088daa505e
Content: Use Microsoft.VisualStudio.TestTools.UnitTesting in unit tests - Visual Studio
Content Source: docs/test/using-microsoft-visualstudio-testtools-unittesting-members-in-unit-tests.md
Product: visual-studio-windows
Technology: vs-ide-test
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

Well, not so much on this page, but in the individual pages underneath it, e.g. https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.testtools.unittesting.ignoreattribute?view=mstest-net-1.2.0
The walkthrough is good though.


Tutorial for Setting up Sqlite.Ecto as a Test Database

In mix and config we can setup different development environments for our code depending on whether we are in production, testing, etc.  A particular use case could be to configure Sqlite.Ecto for testing and the default PostgreSQL adapter for production.
Figure out how to do the above, and write a tutorial to walk a user through the configuration.

Done.
See:  https://github.com/jazzyb/sqlite_ecto/wiki/Using-Sqlite.Ecto-as-a-Test-Database