Allow user to use DB-values inside blogpost

When writing a blogpost, the user has full control on what to show - HTML, CSS and JS. But what if the user want's to access data from the database, e.g. inserting the blog posts publication date just beneath the blog post heading?
Proposal:
Define certain strings, which would be replaced on rendering.
Problems:
It is to my knowledge not possible to query a string from the DB and execute Nim-code within it.
Suggestion:
I can't seem to find an elegant solution to this, so my proposal is:

Prepare a multiReplace() on the queried string from the DB with certain elements such as publication date, views, category.

Example
# user edits a blog post from the browser interface

New blog

${category}

${views}

# routes
get "/blog/newblogpage":
  let data = query-DB-to-fetch-data()
  resp data.multiReplace([("${category}", "Cats"), ("${views}", viewCount)])

Before

After

Use a Template instead of a Route :grey_question:
See my implementation here for similar (but not same) kinda thing:
https://github.com/ThomasTJdev/nim_websitecreator/pull/80#issue-261868873


All output is always saved

It would be nice for big scans to have an option to save only responses with a 200 response code.

Done.
-s / --savestatus


'Flutter/Flutter.h' file not found

I have this error when running flutter on either physical device, simulator or build.
Steps to Reproduce

flutter run
Returns

Error output from Xcode build:
    error: generate-pch command failed with exit code 1 (use -v to see invocation)
    /Users/jackson/projects/profiles_gym_mobile/ios/Runner/GeneratedPluginRegistrant.h:10:9: error: 'Flutter/Flutter.h' file not found
    1 error generated.
    <unknown>:0: error: failed to emit precompiled header '/Users/jackson/Library/Developer/Xcode/DerivedData/Runner-dpbrdntdhqchttcajlurtflebzwj/Build/Intermediates.noindex/PrecompiledHeaders/Runner-Bridging-Header-swift_3VGZUILPTDXFD-clang_1YL5IT7XFP0VY.pch' for bridging header '/Users/jackson/projects/profiles_gym_mobile/ios/Runner/Runner-Bridging-Header.h'
    2 errors generated.
Error launching application on iPhone 13.

Logs
Logs

[✓] Flutter (Channel stable, 2.5.3, on macOS 12.0.1 21A559 darwin-arm, locale en-NZ)
    • Flutter version 2.5.3 at /Users/jackson/src/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 18116933e7 (7 weeks ago), 2021-10-15 10:46:35 -0700
    • Engine revision d3ea636dc5
    • Dart version 2.14.4

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/jackson/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 13.1, Build version 13A1030d
    • CocoaPods version 1.11.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code (version 1.62.3)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.29.0

[✓] Connected device (2 available)
    • iPhone 13 (mobile) • 1D1CFD3B-F05C-4383-8EBB-D9833D65A380 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-15-0 (simulator)
    • Chrome (web)       • chrome                               • web-javascript • Google Chrome 96.0.4664.55

• No issues found!

Podfile
# Uncomment this line to define a global platform for your project
platform :ios, '10.0'

# CocoaPods analytics sends network stats synchronously affecting flutter build latency.
ENV['COCOAPODS_DISABLE_STATS'] = 'true'

project 'Runner', {
  'Debug' => :debug,
  'Profile' => :release,
  'Release' => :release,
}

def flutter_root
  generated_xcode_build_settings_path = File.expand_path(File.join('..', 'Flutter', 'Generated.xcconfig'), __FILE__)
  unless File.exist?(generated_xcode_build_settings_path)
    raise "#{generated_xcode_build_settings_path} must exist. If you're running pod install manually, make sure flutter pub get is executed first"
  end

  File.foreach(generated_xcode_build_settings_path) do |line|
    matches = line.match(/FLUTTER_ROOT\=(.*)/)
    return matches[1].strip if matches
  end
  raise "FLUTTER_ROOT not found in #{generated_xcode_build_settings_path}. Try deleting Generated.xcconfig, then run flutter pub get"
end

require File.expand_path(File.join('packages', 'flutter_tools', 'bin', 'podhelper'), flutter_root)

flutter_ios_podfile_setup

target 'Runner' do
  use_frameworks!
  use_modular_headers!

  flutter_install_all_ios_pods File.dirname(File.realpath(__FILE__))
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
   flutter_additional_ios_build_settings(target)
   target.build_configurations.each do |config|
    config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'
   end
  end
end

Other things tried

Updating podfile with arm dependancies
Updating all packages
Replaced ios folder with new project's ios folder

Hi @jaxnz, from your logs, it looks like you haven't provisioned a team for signing your app.
Kindly see https://docs.flutter.dev/get-started/install/macos#deploy-to-ios-devices for instructions on how to do that and let me know if you still run into this error after doing so.
Thank you


Add test to check the search icon focuses the input

You can preview this change here:
Built with commit 88d31764378da2786eddb2e3c0621a2651d30623
https://deploy-preview-506--govuk-design-system-preview.netlify.com


Display Debug Data

Display

Input voltage (example 20.2V or 28.0V)
handle temperature (Han-C) if your handle (temperature on your PCB inside handle) looks like it's 50C, probably good idea to turn off pinecil and let it cool off for example.  Good Safety information.

these are already exposed in BLE. Would be nice if they were part of a main screen with the Set °C  ( I think it's easier instead of saying Set Temperature to just say  Set °C  or Set °F  depending on what people selected for C or F, and they will know  what that means without the longer word  Soldering Temp).

add a category called Debug data  to go before "Unused" which will show Tip R, Tip Res, and other information which is  not changeable by the user but very helpful in diagnosis and troubleshooting.  when people come into discord with a problem, we often ask them to give us the R-Tip and C-han right away since that is indicator of a possible Temperature sensor or Mosfet problem.  I believe that some of the Debug info is already transmitted.

Since voltage is already visible on the work view, this ticket could probably be a proper "debug view".
ACs:

[ ] display all available "live" values (see #48)
[ ] refresh values once every 5 seconds (to prevent bt/cpu stress)

I am separating out  Debug information as most of  that is not some thing people need to see in the Work view.
Except for handle temperature  (which could also wait to go with graph view if there is no room for handle  temperature in the Work view screen?  depends on what you think for fitting it in.
I'm opening a separate ticket for Debug info.


Add configs for monitoring

NB: the CI build fails because of missing AWS credentials.  To be added by Michael from the Cloud team.

Looks good to me.  Env vars have been set for circle-ci build.  merge when ready

Thanks MIchael!


python311Packages.aioridwell: 2023.08.0 -> 2023.10.0

Diff: https://github.com/bachya/aioridwell/compare/refs/tags/2023.08.0...2023.10.0
Changelog: https://github.com/bachya/aioridwell/releases/tag/2023.10.0
Description of changes

Things done

Built on platform(s)

[ ] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 260633 run on x86_64-linux 1

5 packages built:

home-assistant-component-tests.ridwell
python310Packages.aioridwell
python310Packages.aioridwell.dist
python311Packages.aioridwell
python311Packages.aioridwell.dist


Experimental KML IconStyle test

This adds an IconStyle test from #10119 to determine if there is an existing issue with either ol/format/KML or the test setup.  It is unlikely to need merging.

Closing this as there is clearly an existing issue unrelated to #10177 where something in a preceding test is preventing a "clean" IconStyle being read in a subsequent test..


Cover writing top-level release notes with categories enabled

I initially thought writing top-level release notes with categories enabled
required editing the changelog manually after running scriv collect.
However, a bit of experimentation shows that you can just leave the
heading out when creating the fragment in the first place.

I pushed these changes in commit 18cb5f8, thanks.


Support openrouter.ai

Hi, and thanks for a fantastic product!  Your POSIX approach, which enables Vim and other cli programs, speaks a lot!
Please consider adding support for the https://openrouter.ai/
I attempted to reuse Openai API
[openai]
url = "https://openrouter.ai/api/v1"
# default_model = "meta-llama/llama-3-70b-instruct"
# default_model = "openai/gpt-4o-mini"
# default_model = "google/gemini-flash-1.5"
# default_model = "anthropic/claude-3.5-sonnet:beta"
default_model = "openai/gpt-4o-mini"
api_key = "...."

but ended up with
RUST_BACKTRACE=full sc openai "hello ai"
thread 'main' panicked at /Users/ab/.cargo/registry/src/index.crates.io-6f17d22bba15001f/smartcat-2.2.0/src/utils.rs:9:30:
called `Result::unwrap()` on an `Err` value: reqwest::Error { kind: Decode, source: Error("expected value", line: 1, column: 1) }
stack backtrace:
   0:        0x105fc7148 - __mh_execute_header
   1:        0x105de490b - __mh_execute_header
   2:        0x105fc6bae - __mh_execute_header
   3:        0x105fe3d28 - __mh_execute_header
   4:        0x105fe56e5 - __mh_execute_header
   5:        0x105fca275 - __mh_execute_header
   6:        0x105fca1d9 - __mh_execute_header
   7:        0x105fe41a4 - __mh_execute_header
   8:        0x10606ff52 - __mh_execute_header
   9:        0x106070305 - __mh_execute_header
  10:        0x105d66906 - __mh_execute_header
  11:        0x105d6d1e2 - __mh_execute_header
[1]    94438 abort      RUST_BACKTRACE=full sc openai "hello ai"

Hey, thank you for the kind words :slightly_smiling_face:
That error is a bit weird, I'll look into it when I get some time!


URI Behind Reverse Proxy Incorrect Scheme

When I put the HTTP server behind an nginx reverse proxy with SSL enabled, the Request URI is showing a scheme of http.
I do not have this issue with Guzzle, and I'm wondering why ReactPHP HTTP is not using the correct scheme.
Thank you!

Hey @ellisonpatterson, I'm not quite sure if this is your case here, but the presence of the http scheme here actually makes sense. When a client wants to send a request to your server, it first reaches nginx and should use a secure connection for this. The communication between the nginx reverse proxy and HTTP server doesn't require an additional secure connection since they are often running on the same system (eliminating the need for a TLS handshake, etc.). Since the HTTP server only communicates directly with nginx in this setup, it only sees the address of the nginx, which is why you see the http scheme when the request comes in.
If you want to pass on the original address of your client, you can either use the X-Forwarded-For request header to address the originating IP address of a client connecting to your server through your proxy, or the X-Forwarded-Proto request header to identify the protocol (HTTP or HTTPS) of the client.
I hope this helps :+1:
I believe this should answer your question, so I will close this ticket for now. We can reopen this if you need further help with this. If you do need to reopen the ticket, please provide some information about the steps you've taken so far, what worked and what didn't.

The issue is that I am using Twilio validation as a middleware (https://www.twilio.com/docs/usage/security#validating-requests) and the URL specified has HTTPS as the scheme, but the RingCentral URI builder specifies HTTP which is not what what was requested, causing the Twilio request validation to fail. When I use Guzzle's PSR7 implementation, it specifies HTTPS in the URI builder as expected. I'm wondering then why the ReactPHP HTTP PSR7 implementation differs from the Guzzle one.
The problem is that it works everywhere else, but not with ReactPHP HTTP.

@ellisonpatterson Is there a gist you can share that reproduces this issue so we can have a deeper look at what is happening?

<?php

define('ABSPATH', dirname(__FILE__));
require ABSPATH . '/vendor/autoload.php';

use Psr\Http\Message\ServerRequestInterface;
use React\Http\Message\Response;
use React\Socket\SocketServer;
use React\Http\HttpServer;

$server = new HttpServer(
    fn (ServerRequestInterface $request) => Response::plainText((string) $request->getUri())
);

$socket = new SocketServer('<IP_ADDRESS>:1111');
$server->listen($socket);

I tested with nginx, but ngrok experiences the same issue.
ngrok http 1111
And it shows the entrypoint URL as this:
https://65bc-xx-xx-xx-xx.ngrok-free.app -> http://localhost:1111
I get the following response when visiting the ngrok HTTPS url:
http://65bc-xx-xx-xx-xx.ngrok-free.app/

@ellisonpatterson Thanks for the additional information :+1:
I'm still convinced this can be resolved by using the the X-Forwarded-For request header and the X-Forwarded-Proto request header to identify the protocol (HTTP or HTTPS) of the original client.
ReactPHP may differ here from other projects, but with our work on the upcoming v3 we also want to look into our current PSR7 implementation and some things might change. For example, we want get rid if our RingCentral dependency and maybe look into working on our own PSR-7 integration. Not completely sure if this will a v3 topic or if we integrate this in a upcoming v1.10.0. The roadmap for ReactPHP HTTP v3 is still outstanding, but will go live soon.
With that said, for now we need to use the suggested headers, but like I said, this may change in the near future.
The question for this should be answered, this is why I consider this ticket as closed. We can use the ReactPHP discussions to discuss any additional feature requests for improvements.


Win7X64 + VS2017 + simd/prj/vs2017w, Compile error

Win7X64 + VS2017 + simd/prj/vs2017w, Compile error
Error C3861 '_mm256_extract_epi64': identifier not found		e:\source\sse\simd\src\simd\simdextract.h	182

Hello! Thank you for bug report.
I have checked compilation on Visual Studio 2017 and it works fine.
The troubles may be caused the fact then I use newer version 15.7 of Visual Studio (_MSC_VER = 1914) unlike  of you. If you tell me your compiler version (_MSC_VER ) it will help to reproduce error and then fix it.

Version 15.9.21

I have reproduced this bug (at 32-bit mode) and fixed.


meshio for i/o

It seems to me that pytorch_geometric could profit by using meshio (a project of mine) which provides I/O for many mesh formats, amongst them OFF and PLY which are already in https://github.com/rusty1s/pytorch_geometric/tree/master/torch_geometric/io.

Thank you! I didn't know of your library yet, but this looks like a great project for I/O of many mesh formats. I think it should be straightforward to add this library as a dependency for the most common mesh formats. We can add a note to the documentation to use meshio separately for other formats.


Expand one empty collection item fields in the form without click on Add button

What is the way to make one group of fields for adding new collection item to show up without need to click on the Add button?

You are asking about a JS function, or the way to add item it in backend?

Making them on the backend would be better I think but ideally I'd like to have both options.

Backend
You must add a new items to your struct with additional formex_id value. On the JS side I'm generating new values using UUID, but it can be also numbers "1", "2", .... or any other string.
If you are using Ecto, then you have to preload that association before adding new items.
Example with Ecto:
article = Repo.get!(Article, id)
|> Repo.preload(:comments)

article = Map.put(article, :comments, article.comments ++ [
  %App.Comment{
    content: "default content of a new comment", # optional
    formex_id: "1" # required. it may be any unique string
  },
  %App.Comment{
    content: "default content of yet another new comment",
    formex_id: "2"
  }
])

form = create_form(App.ArticleType, article)

JS
import { Collection } from 'formex'

Collection.addCollectionItemForm($('.formex-collection'))

Sorry for the jQuery dependency 😄

Thanks, I'll try it out...
As for the jQuery... well I used to love it long ago))


Consider configuring Google and GitHub auth backends in development environment

It'd be nice for testing these to not require setting up a separate Oauth application for each person who wants to test.
There's some key management stuff to figure out (I think basically we need to register a "ZulipDev" oauth app that is configured to only support bounce you to localhost:9991, and put its secret key in the Zulip repo), and we'd need to determine if doing so violates ToS or otherwise creates security problems, but I don't see an immediate problem with every Zulip development environment using the same, public, Oauth application for login (one can already login to the servers that accept those credentials without any credentials at all anyway).

@zulipbot claim

Working on this.


doctor should check if workdir is sharable on OS X

On osx docker is running in a VirtualBox VM. That VM is configured to share your $HOME directory from OS X into the VM on the same path.
A couple of functions are relying on being able to use docker volumes lie:
docker run -v $PWD:/data some image

They will work only if the current working directory is under your $HOME. So /tmp/cbd-test won't work.
Add a check to cbd doctor

closed by #134


0.3.4 latest build fails after install

nitroshare-0.3.4-windows-x86.exe
SHA1: 1854efc0e38fb9879bf93d8d8c793c170a736ab9
From https://ci.quickmediasolutions.com/job/nitroshare/toolchain=windows&&x86&&msvc2015/lastSuccessfulBuild/artifact/build/nitroshare-0.3.4-windows-x86.exe (which will most likely change).

It appears that application still works. At least menus in systray.

That's odd. It appears the OpenSSL libraries aren't being included in the package.

This appears to be limited to the Windows platform since Qt on macOS either uses Secure Transport (the native API) or the bundled version of OpenSSL.


Network errors hidden with catchReturn

Expected Behavior

Calls like whoami() and isLoggedIn() should return a rejected promise with an error object describing the cause for the failure, for network errors such as invalid proxy configuration.
Users (e.g. balena CLI users) and support agents are able to see the error, understand the problem and solve it (e.g. fix the proxy configuration).

Actual Behavior

catchReturn(undefined) and catchReturn(false) expressions returned undefined / false, hiding the underlying error:
https://github.com/balena-io/balena-sdk/blame/v12.21.0/lib/auth.coffee#L102
https://github.com/balena-io/balena-sdk/blame/v12.21.0/lib/auth.coffee#L234
Users don't understand why it doesn't work and ask balena support to investigate. A number of engineers spend time trying to figure out what is going on, including myself.

Token authentication failed https://forums.balena.io/t/token-authentication-failed/17948
how to use balena deploy to build on device running development image https://forums.balena.io/t/how-to-use-balena-deploy-to-build-on-device-running-development-image/58490
Proxy fails with Node.js >= 10.16.0 https://github.com/balena-io/balena-cli/issues/1579

Note however that the commit that added the catchReturn lines is entitled "Stop exposing sdk.token object", so it appears that "hiding" some errors was done with a purpose. The fix therefore should be more selective about what to hide, or find a different way of not exposing tokens.

I did some investigation based on @pdcastro findings. I hope it can be useful. I will come back to this issue soon.
I noticed that getEmail does not call catchReturn and it was changed on f1369f0ca. Maybe it would never be able to expose sdk.token at this stage.
Errors are already normalized on normalizeAuthError, this could be used to filter sdk.token mentioned on f1369f0ca. But I need to go deeper to identify when sdk.token could be exposed in an error.
Reproducing the issue with proxy
It's possible to reproduce a proxy error on balena-sdk running balena-cli. (Following README#proxy-support)
export BALENARC_PROXY= # ensure proxy is disabled
balena login # you need to be logged in, otherwise, an ECONNREFUSED error happens
export BALENARC_PROXY='http://localhost:8000' # this is going to fail as I don't have a proxy running locally
balena apps # results on default login error "You have to log in to continue" without any extra information

Manually testing a quick fix

Remove line :234.catchReturn(false) from isLoggedIn
rebuild balena-sdk
run balena-cli from source (linked to balena-sdk using npm link)

export BALENARC_PROXY= # ensure proxy is disabled
bin/balena-dev login # you need to be logged in, otherwise an ECONNREFUSED error happens
export BALENARC_PROXY='http://localhost:8000' # this is going to fail as I don't have a proxy running locally
bin/balena-dev apps # expected error about proxy failure (no token exposed to command line result)
DEBUG=1 bin/balena-dev apps # expected error about proxy failure (no token exposed as well)

Error: ECONNRESET: request to https://api.balena-cloud.com/user/v1/whoami failed, reason: tunneling socket could not be established, cause=connect ECONNREFUSED <IP_ADDRESS>:8000
I still need to inspect the promise error object to ensure there is no extra data that might have sdk.token.
Next step

[ ] Identify what is sdk.token in the current codebase and which errors could expose it

That's what I have for now.

linked to balena-sdk using npm link

@josecoelho, if npm link is working for you then it's all good, but in my past experience it was a bit of hit-and-miss... What I and others ended up doing is copying (I personally like rsync) the relevant folders (build) from the dependency module (balena-sdk) to the node_modules folder of balena-cli.

@josecoelho @pdcastro thanks for this detailed issue report :+1:
I've just opened https://github.com/balena-io/balena-sdk/pull/823 to fix this issue and I'm going through again a few cli commands that the issue was manifesting to make sure it's indeed fixed.

Thank you @thgreasi 👍  Of course you didn't know it, but @josecoelho had written to me via LinkedIn that he was hoping to work on this issue as something to add to a job application to balena, and your PR may have spoiled that plan a little bit - lol. :-)


Community Edition Headless Version

Is your feature request related to a problem? Please describe.
I can't use the cluster headless version for community and I need to run a community version for testing.
Describe the solution you'd like
I want to have a headless service for Community
Describe alternatives you've considered
I tried this but I still get connect issues from my Python client which is inside a pod. It should connect with uri = "neo4j://<IP_ADDRESS>"
apiVersion: v1
kind: Service
metadata:
  name: neo4j
  namespace: default
spec:
  clusterIP: None
  ports:
  - name: neo4j
    port: 7687
    protocol: TCP
---
apiVersion: v1
kind: Endpoints
metadata:
  name: neo4j
  namespace: default
subsets:
  - addresses:
      - ip: <IP_ADDRESS> # your node's IP address
    ports:
      - port: 7687
        name: neo4j
        protocol: TCP```

**Additional context**
Add any other context or screenshots about the feature request here.

@mtgnoah
headless service is for clusters only and clusters are an enterprise edition feature only


GT Guidelines and OCR-D Wiki

For questions, the GT guidelines are sometimes quite rigid. A link between the OCR-D Wiki and the Guidelines would be welcome.
Steps

[x] Development of a mechanism for the transfer of GT Wiki contributions to the GT Guidelines
[x] Development and documentation as well as provision of a template for a GT Wiki submission
[ ] put it on the website

Duplicate of #226


}}@endslot without space before @endslot breaks formating

Template
If I have
@component('components.elements.button')     @slot('href')/plant/details/{{ $plant->system_name }} @endslot @endcomponent
after  formatting it is:
@component('components.elements.button')     @slot('href')/plant/details/{{ $plant->system_name }}@endslot     @endcomponent
It should be:
@component('components.elements.button')     @slot('href')/plant/details/{{ $plant->system_name }}@endslot @endcomponent
Context (Environment)

write your environment

Description

If there is a space before @endslot then it works as expected

I think this behavior is fixed in the latest version
@component('components.elements.button') @slot('href')/plant/details/{{ $plant->system_name }} @endslot @endcomponent

will format into
@component('components.elements.button')
    @slot('href')
        /plant/details/{{ $plant->system_name }}
    @endslot
@endcomponent


arara rule for knitr?

Hi @cereda! 🦆 I'm procrastinating, and so I'm getting to this a bit earlier than I had planned. In lieu of an email, I figured I'd open an issue here. Hope that's alright.
I started trying to write an arara rule for knitr, but I'm having some trouble because I don't really know how to construct the command.
Let me backup a bit, though, and explain how knitr works so that I can also flag some desiderata for what the rule should be able to do and how it should interact with other rules.
(Also, this is related to #46.)
knitr overview
knitr is a tool that allows for writing inline R code in a .tex document. The associated file extension is .Rnw, and an .Rnw file (say myfile.Rnw) might look like this:
\documentclass{article}

\begin{document}

A graph about cars (Figure~\ref{fig:cars}).

<<cars, echo=FALSE, message=FALSE, fig.cap="Car graph", fig.lp="fig:">>=
library(ggplot2)
CarPlot <- ggplot() +
  stat_summary(data = mtcars,
               aes(x = factor(gear),
                   y = mpg
                   ),
               fun.y = "mean",
               geom = "bar"
               )
CarPlot
@

\end{document}

Everything in between <<...>>= and @ is R code, and everything else is LaTeX. The idea is that you can produce a PDF from combining R code and LaTeX in a single document. The PDF is produced from an intermediate .tex file.
So the workflow would look as follows:

Edit the .Rnw file
Compile the .Rnw file to .tex; you could do this either by (a) starting an R session and knit()ing the file, or (b) running an R process via Rscript:

a.
$ R
R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin13.4.0 (64-bit)
> library(knitr)
> knit('myfile.Rnw')

b.
$ Rscript -e "library(knitr); knit('myfile.Rnw')"

Compile the resulting .tex file with your favorite TeX engine to get a PDF, e.g.:

lualatex myfile.tex

writing a knitr rule
So I'm trying to write a rule for knitr that uses getCommand() and the Rscript invocation mentioned above, but I'm having issues because of the quoting required by using Rscript to invoke an R process without starting an R session.
What's a good way to handle all of the quoting?
My first attempt was this, but this doesn't seem to actually expand the @{file} reference:
!config
identifier: knitr
name: knitr
authors:
- Adam Liter
commands:
- name: knitr
  command: >
    @{
          return getCommand('Rscript -e "library(knitr); knit(\'@{file}\')"');
    }
arguments: []

My current attempt was to construct the command to be executed outside the scope of getCommand():
!config
identifier: knitr
name: knitr
authors:
- Adam Liter
commands:
- name: knitr
  command: >
    @{
        command = 'Rscript -e "library(knitr); ';
        command = command.concat('knit(\'').concat(file).concat('\')"');
        return getCommand(command);
    }

But this results in a error:
Could not execute [Rscript -e "library(knitr);
knit('myfile.Rnw')"]. Error=2, No such file or directory

It actually seems like this is executing the correct command, so I'm not sure what is causing the no such file or directory error.
Can you give me any guidance here @cereda? I'm happy to write the rule and open a pull request (assuming you and the team are okay with incorporating a rule for knitr into arara directly, which you might not be okay with; see below), but I could use some guidance.
Some desiderata for a knitr rule
To wrap it all up, there are a few things worth mentioning that would be nice to consider in writing a rule for knitr. The first relates to the workflow for knitr sketched above. The .Rnw file is the only file that the user should be editing, so it would be nice to go straight from .Rnw to .pdf without having to look at the intermediate .tex file or interact with it directly.
Currently this is not possible because the (pdf|xe|lua)latex rules use the file name, including extension. One workaround is to make use of the files parameter to these rules. That is to say, in myfile.Rnw, you could have these directives:
% arara: knitr
% arara: lualatex: { files: [ myfile.tex] }

But this hardcodes the name of the file into the directive, which seems hacky, in my opinion. 😝
Is there a better way to solve this given the capabilities of arara? Two other options that come to mind are:

Write custom (pdf|xe|lua)latex rules, but I assume these would never be incorporated into arara, so it would be up to the user (and any of the user's collaborators) to do this
Include the execution of (pdf|xe|lua)latex as part of the knitr rule

Of these, (2) seems the best, but then the rule becomes complicated if you want to allow selection of the LaTeX engine and allow for passing other command line options.
Furthermore, knitr is capable of producing other output formats than just .tex. For example, an .Rhtml file (i.e., an HTML file with R code chunks) can be turned into an .html file by knitr, and an .Rmd file (i.e., a Markdown file with R code chunks) can be turned into an .md file by knitr. If the arara rule for knitr were to accommodate these other uses, it would be best to decouple the rule that does PDF generation from the knitr rule.
Two last things. First, if a knitr rule is incorporated into arara itself (rather than having users write their own rules), you may need to consider adding the .Rnw (and .Rhtml and .Rmd) file extensions to filetypes. Ideally, .Rnw would take precedence over .tex because you would want arara myfile to look for directives in the myfile.Rnw file, not the myfile.tex file. I'm not sure if having something take precedence over .tex is something that you and the team are open to.
Second, and finally 🙃, there are several other options to the knit() command, so ideally these could be hooked into via the parameters of the rule. I can give more details about this later. This is already a lot to chew on, I know. 🐣 But I can work on this on my own if you're able to give me some direction on how to handle quotes and why I'm getting the no such file or directory error.

Thanks for the help in the TeX.SX chat, @cereda 😸!
With your help, I've gotten close to having a knitr rule that accounts for all of the options to knit():
!config
identifier: knitr
name: knitr
authors:
- Adam Liter
- Paulo Cereda
commands:
- name: knitr
  command: >
    @{
        return getCommand('Rscript', '-e',
                          'library(knitr); knit("' + file + '", output = "' + output + '", tangle = ' + tangle + ', quiet = ' + quiet + ', envir = ' + envir + ', encoding = ' + encoding + ')');
    }
arguments:
- identifier: output
  flag: >
    @{
        if (isString(parameters.output)) {
            return parameters.output;
        }
        else {
            throwError('I was expecting a string name for the output file.');
        }
    }
  default: 'NULL'
- identifier: tangle
  flag: >
    @{
        if(isTrue(parameters.tangle) && parameters.output.equals('NULL')) {
            throwError('If you want to tangle the document, specify an output file.');
        }
        else {
            isTrue(parameters.tangle, 'TRUE', 'FALSE')
        }
    }
  default: ''
- identifier: quiet
  flag: >
    @{
        isTrue(parameters.quiet, 'TRUE', 'FALSE')
    }
  default: ''
- identifier: envir
  flag: >
    @{
        if (isString(parameters.envir)) {
            return parameters.envir;
        }
        else {
            throwError('I was expecting a string (that is evaluable as R code) specifying the environment in which code chunks should be evaluated.');
        }
    }
  default: 'parent.frame()'
- identifier: encoding
  flag: >
    @{
        if (isString(parameters.encoding)) {
            return parameters.encoding;
        }
        else {
            throwError('I was expecting a string specifying the encoding of the input file.');
        }
    }
  default: 'getOption("encoding")'

I really know nothing about Java, so if there are better ways to do anything, please make suggestions. 😉
One issue that I'm having with this rule currently is that when I leave output unspecified in the directive, I get the following error even though there is a default specified value for output:
[Error: could not access: output; in class:
java.util.LinkedHashMap]
[Near : {... rameters.tangle) &&
parameters.output.equals('NULL ....}]

Other than that, it seems like this rule works, though I haven't tested it extensively.
One further thing that would be nice would to be allow for arbitrary execution of R code before the call to knit(). I haven't yet tried to implement this, but I can do that.
For example, it would be nice to be able to run this before the call to knit():
knit_hooks$set(small.mar = function(before, options, envir) {
    if (before) par(mar = c(4, 4, .1, .1))
})

So the Rscript command would have to be: Rscript -e "library(knitr); knit_hooks$set(small.mar = function(before, options, envir) { f (before) par(mar = c(4, 4, .1, .1)) }); knit('myfile.Rnw')". I haven't yet tried implementing support for this because I'm not sure if passing arbitrary R code through a directive parameter will cause any issues.
Aside from that, if you have suggestions regarding the other desiderata mentioned above, I'd appreciate it. And let me know what you and the team thinking about incorporating this into arara.
Thanks again for all of the help! 🙌

Hello @adamliter!

I'm procrastinating, and so I'm getting to this a bit earlier than I had planned. In lieu of an email, I figured I'd open an issue here. Hope that's alright.

Of course it is! And procrastination is always a good thing. :wink:

Let me backup a bit, though, and explain how knitr works so that I can also flag some desiderata for what the rule should be able to do and how it should interact with other rules.

Thank you! For me, being a knitr newbie, it is very important to understand the inner workings of such workflow. Your explanation is fantastic, and now we can work together in order to come up with an awesome arara rule!
Let's go!

What's a good way to handle all of the quoting?

In previous versions of arara, we used plain strings to indicate command invocations and the tool had to employ guesswork to correctly parse arguments. I then realized this idea is the root of several issues reported by users. In other words, automatic argument parsing is definitely a bad idea, specially when handling complex scenarios like your knitr rule. From version 4.0, we marked this approach as deprecated and hopefully will be removed in future versions.
The best way of handling quotes is to rely on a high level structure with explicit argument parsing named Command. From the user perspective, a Command object is simply a good old list of Object objects, in which the list head (i.e, the first element) is the underlying system command, and the list tail (i.e, the remaining elements), if any, contains the associated command line arguments. The getCommand built-in method creates such object for us based on the provided arguments. For example:
getCommand('pdflatex', '--shell-escape', 'mydoc.tex')

The first element (namely, pdflatex) refers to the system command, and the two remaining ones (namely, --shell-escape and mydoc.tex) refer to the command arguments. The getCommand method then constructs a Command object for us.

My first attempt was this, but this doesn't seem to actually expand the @{file} reference:

The reason for that is because you are already inside an orb tag! The @{ ... } is required only when you are in a plain string context:
Hi, my name is @{name}

However, if we are inside an orb tag already, it means we are dealing with the expression language itself, so we simply refer to the variable by name:
@{ 'Hi, my name is' + name }

Note that string concatenation can be done with either +  or concat(...), both should work. I usually use them interchangeably with no issues.

Is there a better way to solve this given the capabilities of arara?

The team is discussing the inclusion of parameter evaluation in the directive context, so this upcoming feature might be exactly what you are looking for! It might take a while though to reach the mainstream code, because we are studying ways of not breaking existing stuff. :wink:

Include the execution of (pdf|xe|lua)latex as part of the knitr rule

Yes, that would be my suggestion.

Of these, (2) seems the best, but then the rule becomes complicated if you want to allow selection of the LaTeX engine and allow for passing other command line options.

Not too complicated. Take a look at, e.g, frontespizio, it is quite straightforward to make it happen. And since now we are using the folded style for writing scalars in the YAML file, the rule becomes cleaner, in my opinion. :wink:

If the arara rule for knitr were to accommodate these other uses, it would be best to decouple the rule that does PDF generation from the knitr rule.

Rules are designed under the encapsulation notion, such that the direct access to internal workings of such structures is restricted. That also means that one rule should not, in theory, know about what happened before, in previous rules. However, there is a way to cheat arara, which is the use of a Session object. In practical terms, this particular object is a global, persistent map, acting as a a mechanism for data sharing across rule contexts. Personally, I would avoid this approach, as I am not exactly fond of context-aware rules. :wink:
I think it would be worth to include other output formats in the knitr rule, and even the execution of other commands, like a TeX engine, if you believe this idea would cover most of the scenarios. :wink:

I'm not sure if having something take precedence over .tex is something that you and the team are open to.

I think there is always room for discussion, so do not worry too much. :wink: Also, since version 4.0 supports local configuration files, one could simply add the patterns to the root of a project and arara would work as expected, without the need of having a global configuration file.

I really know nothing about Java, so if there are better ways to do anything, please make suggestions. :wink:

Neither do I. :wink:

One issue that I'm having with this rule currently is that when I leave output unspecified in the directive, I get the following error even though there is a default specified value for output:

The reason for that is because output is not yet processed. It is quite tricky to mix different argument checks. One way of doing what you want is changing that offending line by:
if(isTrue(parameters.tangle) && !parameters.containsKey('output')) {
...
 However, nothing can be said about output, that is why we need to check if it exists in the map. In this case, note the negation ! before the method call, so we check if output is absent from the parameters.
I usually leave cross-argument validation to the command context, as everything is resolved in there, and keep simple verifications to the flag context. But that is basically my style of doing things. :wink:

One further thing that would be nice would to be allow for arbitrary execution of R code before the call to knit(). I haven't yet tried to implement this, but I can do that.

In theory, it should work, but I don't think the directive parameter handler would gracefully allow such entries. Perhaps passing arbirary code through directive parameters might not be a good idea. I will think of something along those lines.

Aside from that, if you have suggestions regarding the other desiderata mentioned above, I'd appreciate it. And let me know what you and the team thinking about incorporating this into arara.

I believe we are now reaching a very powerful and stable knitr rule, so it might be a good addition to the default rule pack of arara. I will take a look at your code later on and propose some improvements, but so far I am glad it works. :wink:
All the best!
Paulo

Thanks @cereda! This was all really helpful.
Regarding:

Include the execution of (pdf|xe|lua)latex as part of the knitr rule

Yes, that would be my suggestion.

Thinking about this a bit more, this is still not ideal because you may also want to process the resulting .tex file with, among other things, makeglossaries, biber, etc.. Bundling all of these potential things into a single knitr rule seems suboptimal, especially because (I think?) it would preclude making use of the conditional checks that you can now do with arara 4.0 in the directives.
For example, it'd be nice to be able to have the directives in myfile.Rnw look like this:
% arara: knitr
% arara: xelatex
% arara: biber
% arara: makeglossaries
% arara: xelatex while found('log', 'undefined references')

If the alternative is something like this:
% arara: knitr: { engine: xelatex, bibliography: biber, makeglossaries: yes }

it seems like you would lose the ability to sensibly check stuff conditionally in the directives, right? (You'd just end up rerunning the whole rule in its entirety, I think.) Of course, the rule could be written to be smart and do such checks itself, but it seems more in line with the spirit of arara to have this stuff specified in the directives. The user can then clearly see the compilation steps.
So perhaps for the time being, the best solution just is to hardcode the file name in the (pdf|xe|lua)latex directive like so:
% arara: knitr
% arara: xelatex: { files: [ myfile.tex ] }
% arara: biber
% arara: makeglossaries
% arara: xelatex { files: [ myfile.tex ] } while found('log', 'undefined references')

Do you have any further thoughts or suggestions? I'm still happy to open a pull request for a knitr rule, but if you have any further feedback, I'd appreciate it. I'll try to put together a pull request in the next day or two, which you and the others can take a look at and decide if this is something that you want to incorporate into arara.

arara v5.0 will feature a knitr rule inspired by your postings above. The release is scheduled to happen before the DANTE Frühjahrstagung.


Self scrolling text

This addresses #8  and does so in the same manner as the function that currently scrolls the metadata when the table overflows.
I also removed an unused debugging function that we were using to display the current version to users while testing.  It was pulling in the whole package.json for this, which is no longer necessary.
Is it OK with you if I remove the main.js from version control, rather than having to check in updated builds with each new feature?  You'd just need to build it before you publish it.  Apologies if you answered this somewhere else and I missed it.
I'm going to do some significant refactoring  of the displaymetadata.js module, but wanted to get this in right away since it addresses an open issue.

Eric, can you update the README with the steps I need to follow to build main.js ?

I will merge this and wait for you to update the README

Sure, good point.


exportpdftoimages : error ServiceApiError

Hello, I'm new and I'm trying to use @adobe/pdfservices-node-sdk to convert pdf to jpeg.
some time ago, I managed to convert, but since yesterday impossible and I have an error "Exception encountered while executing operation ServiceApiError"
2023-05-15T11:01:53.681:[INFO]: All validations successfully done. Beginning Export PDF to Images Operation execution Exception encountered while executing operation ServiceApiError     at rejectWithServiceApiError (..\node_modules\@adobe\pdfservices-node-sdk\src\internal\http\http-client.js:31:17)     at handleJsonResponse (..\node_modules\@adobe\pdfservices-node-sdk\src\internal\http\http-client.js:55:3)     at handleErrorResponse (..\node_modules\@adobe\pdfservices-node-sdk\src\internal\http\http-client.js:117:2)     at onEnd (..\node_modules\@adobe\pdfservices-node-sdk\src\internal\http\http-client.js:176:3)     at IncomingMessage.<anonymous> (..\node_modules\@adobe\pdfservices-node-sdk\src\internal\http\http-client.js:216:5)     at IncomingMessage.emit (events.js:412:35)     at endReadableNT (internal/streams/readable.js:1333:12)     at processTicksAndRejections (internal/process/task_queues.js:82:21) {   requestTrackingId: undefined,   statusCode: 400,   errorCode: 'UNKNOWN'
I applied the same code present in "src/exportpdftoimages/export-pdf-to-jpeg.js", copy the credential.json file and my private key.
Can you help me?

We are also having the same issue with PDF extraction.  Please help us resolve this issue

It w

We are also having the same issue with PDF extraction. Please help us resolve this issue

It worked after upgrading to 3.3.0 👍

Hi @vivo95, above-mentioned issue is resolved, hence closing it.


With a subscription, the customer is charged even if the product is out of stock

Expected behavior
If the product is out of stock, order is not passed and customer should not be charged
Actual behavior
If a product is out of stock, order is NOT created in PrestaShop backoffice, but customer is charged as a payment is initiated in Mollie backoffice 😳
Steps to reproduce the behavior
Subscribe to a product with few stock. On next subscription occurence, client will be charged in the Mollie backoffice but no order will be created.
Environment

PrestaShop version: <IP_ADDRESS>
Mollie module version: 6.2.2
PHP version: 7.3.31-1~deb10u7

Hi there,
We will check this issue and I will get back to you as soon as more details.
Thank you for your patience!
--
Best Regards,
Invertus Support team.

some more information about the issue
First (non recurrent) command

First (recurrent) command initiated by the Mollie backend

we can see payment is initiated, credit card is debited then webhook is called but in error each time (no stock)
Payment stays "payed" which should not be the case
If I read well the documentation
https://docs.mollie.com/reference/webhooks#retry-schema
it seems nothing is planned on Mollie side to cancel or review a payment if the webhook finally fails.
This is unfortunately inconceivable for us and represents a NOGO for our client
Do you have any follow-up to give to this?
Thanks

Hi there @zorrobiwan,
Forwarded everything to the Mollie team and our developer.
We will check this and discuss internally before coming back to you.
Best Regards,
Invertus Support team.

Hi there @zorrobiwan, thanks for waiting!
I've spoken to the Mollie team about this and all their integrations that have built a subscription functionality are built this way. For Mollie, it's out of their scope of whether the product is available or not.
At least for now, it is the merchant's responsibility to make sure there are enough goods available for the subscription.
TL:DR - It’s by design and intended as it is.
If you have any other questions, please let me know!
Best Regards,
Invertus Support team.

thanks for the answer even if it doesn't satisfy me
I'm also an IT guy and I know that it's pretty easy to answer "as designed" when a problem is complex to solve.
And it's pretty crazy that in a transactional financial universe, we debit a credit card without ANY control over the possible success of the operation linked to this debit
Anyway.
If this can't be done on the backend side (or in collaboration with), maybe you could consider stronger information on the PrestaShop side.
Currently, the module records an error in the PrestaShop log system (cfr MollieSubscriptionWebhookModuleFrontController). But I can't see an admin checking every morning if an order has failed due to lack of stock.
Couldn't you at least add the possibility of an email alert?
Big thanks for the follow-up

@zorrobiwan Hi there, thanks for waiting.
I have forwarded the information to the Mollie team.
Once I have more details, I will post an update here.
If you have any questions, please let me know!
Best Regards,
Invertus Support team.

Hi there @zorrobiwan,
We will update the documentation to cover this and provide the steps to handle this and avoid problems in the future.
As for handling it, our recommendation would be to set up the native PrestaShop module Mail Alerts, which has the functionality to send emails to the merchant when the product stock reaches a defined number of times.
It would be redundant to implement email notifications on Mollie's side when PS already offers this functionality:

This will help you to manage your subscriptions, as at the moment, Mollie is not planning on making improvements for this case.
If you have any questions, please let me know!
Best Regards,
Invertus Support team.

Thx for your reply
Of course my client implements the Mail Alerts module.
What I'm asking is to be warn about lack of stock by Mollie Module. It's to be warned (more than with a simple log) that a payement initiated on the backend side failed for any reason (which could be a lack of stock)!
Anyway, we'll find and implement our own solution (or use another payment provider)


Set vertical align

By default, the vertical align is the end of each column. I want it to be centred. I tried this:
center = workbook.add_format
center.set_valign('center')

But I got no luck. Also tried set_center_accross and other related methods.
The source code for set_valign() looks like it just calls set_align() or acts like an alias.
Is vertically aligning a column possible?

to set vertical alignment,
use set_align('vcenter'), not set_valign()
see https://github.com/cxn03651/write_xlsx/blob/master/examples/formats.rb
//--------------------------------------------
中村 英夫
日本大学 理工学部土木工学科 教授
〒101-8308 東京都千代田区神田駿河台1-8-14
TEL 03-3259-0876  Email @.***
研究室タワー・スコラ10階S1015室 https://goo.gl/maps/Ci3GAyxv1UoX7GBN7
//--------------------------------------------
2022年1月17日(月) 13:26 Sourav Goswami @.***>:

By default, the vertical align is the end of each column. I want it to be centred. I tried this:
center = workbook.add_format
center.set_valign('center')
But I got no luck. Also tried set_center_accross and other related methods.
The source code for set_valign() looks like it just calls set_align() or acts like an alias.
Is vertically aligning a column possible?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Thank you, It works!


Inconsistent type deduction between final x = …; and for (final x in …).

Not sure if this is an SDK issue or a language issue, but t1 is semantically identical to t2, and t3 is identical to t4, so it doesn't make sense that only one of each works. Neither with nor without a temporary variable seems to work in all cases.
List<int>? arr;

// Expected: x is int. OK.
int? t1() {
  final xs = arr ?? const [];
  for (final x in xs) {
    return x;
  }
}

// Expected: x is int. Actual: x is dynamic!
int? t2() {
  for (final x in arr ?? const []) {
    // A value of type 'dynamic' can't be returned from the function 't2' because it has a return type of 'int?'.
    return x;
  }
}

// Expected: x is num. Actual: x is int!
num? t3() {
  // The element type 'double' can't be assigned to the list type 'int'.
  final xs = arr ?? const [3.14];
  for (final x in xs) {
    return x;
  }
}

// Expected: x is num. OK.
num? t4() {
  for (final x in arr ?? const [3.14]) {
    return x;
  }
}

Dart SDK version: 2.13.4 (stable)

This is highly curious.
If we instrument the code, we can see the precise types of the const list literals and their context types.
List<int>? arr;

// Expected: x is int. OK.
int? t1() {
  final xs = arr ?? ((const [])..checkType<Exactly<List<int>>>());
  final xs2 = arr ?? (contextType(const<int>[])..checkType<Exactly<List<int>?>>());
  for (final x in xs) {
    return x..checkType<Exactly<int>>();
  }
}

// Expected: x is int. Actual: x is dynamic!
int? t2() {
  for (final x in arr ?? ((const [])..checkType<Exactly<List<dynamic>>>())) {
    // A value of type 'dynamic' can't be returned from the function 't2' because it has a return type of 'int?'.
    return x;
  }
  for (final x in arr ?? (contextType(const <int>[])..checkType<Exactly<Iterable<Object?>>>())) {
    // A value of type 'dynamic' can't be returned from the function 't2' because it has a return type of 'int?'.
    return x as int;
  }
}

// Expected: x is num. Actual: x is int!
num? t3() {
  // The element type 'double' can't be assigned to the list type 'int'.
  final xs = arr ?? ((const [3.14])..checkType<Exactly<List<int>>>());
  for (final x in xs) {
    return x;
  }
}

// Expected: x is num. OK.
num? t4() {
  for (final x in arr ?? ((const [3.14])..checkType<Exactly<List<double>>>())) {
    return x;
  }
}

main(){
  t1();
  t2();
  t3();
  t4();
}

extension <T> on T {
  T checkType<S extends Exactly<T>>() => this;
}

T contextType<T>(Object result) => result as T;

typedef Exactly<T> = T Function(T);

(The ..checkType calls above do not give any compile-time errors which means that that is exactly the static type of the expression they're called on). The contextType calls capture the context type at that point, and has the same type, so we can check them with ..checkType.)
This shows that final xs = arr ?? ... gives the thing after ?? a context type which is the static type of arr, which is List<int>?. Then inference infers the const [] to be const <int>[].
For for (final x in arr ?? const[]), the context type of const[] is Iterable<Object?>, which the same as the context type of the entire arr ?? const[]. Then const[] becomes const<Object?>[] (or const<dynamic>[] in some cases?) So, the outer context type is propagated in when there is one, and if not, the type of the first operand is used.
The last rule feels spurious. At least I'd prefer to use the non-null version of the type, since I already went out of my way to use ?? on it.
Is this deliberate, @stereotype441 ?

I don't know what the rationale behind the current rule is.  Maybe @leafpetersen knows?
I agree that it seems kind of spurious that when we have no outer context type, we use the type of the LHS as the context for the RHS, whereas when we do have an outer context type, we use it as the context for the RHS and completely ignore the type of the LHS.
It's tricky to decide on a good rule from first principles, because usually we think of the context type as the upper bound of what types the expression could evaluate to without causing an immediate type error, but occasionally we instead think of it as a "hint" of what type the user probably intends, even if a much broader type would also work without causing an immediate type error.  In the case of for (final x in arr ?? const []), type of arr is such a good indicator of what type the user intends for const [] that it makes sense to use it, even though the true upper bound of what types would be valid for const [] really is Iterable<Object?>.  So we're solidly in heuristic territory here.
If I understand @lrhn's idea correctly, I believe he's suggesting that the context for the RHS should always be the static type of the non-null version of the static type of the LHS, regardless of the outer context type.  That might work, I'm not sure.
If it turns out to be too breaking, I could imagine a less breaking rule that would be something like:

Let C be the outer context type and T be the static type of the LHS.
If C is _ or a top type, use T as the context for the RHS.
If both C and T are both subtypes of a common class B (*), instantiate it by recursively applying this rule to all of B's generic arguments, and use that as the context type (**).  So for instance if C is Iterable<_> and T is List<int>, the context for the RHS would become Iterable<int>.
Otherwise use C as the context for the RHS.

(* We would have to have a rule for what to do if there are multiple common superclasses.  Probably we could just use the same rule that LUB uses)
(** TBD: I'm not sure what the correct rules for nullability are.  My gut feeling is that we ignore the nullability of T and use whatever the nullability of C is)
A completely different approach to solving the problem would be to say that const [] always means const <Never>[], regardless of the context type.  (This should be fairly safe in practice, because const lists are de facto covariant in their element type).  This approach has the advantage that it doesn't mess with the behavior of ??, so it's probably less breaking.  But it has the disadvantage that it doesn't work for non-const lists at all, and that might be surprising to folks (people might reasonably expect that for (final x in arr ?? const []) has the same type analysis behavior as for (final x in arr ?? [])).
I'm going to transfer this to the language issue so I can tag it similarly to the other possible improvements to type inference and flow analysis that I'm planning to investigate in Q4.


DeserializeXNode in .net core

In attachment is console project with very simple code using "Newtonsoft.Json": "9.0.1":
string json = @"{
    ""CreatedDate"": ""2014-01-23T00:00:00""
}";
var dxml = JsonConvert.DeserializeXNode(json, "root");
Console.WriteLine("CreatedDate: " + dxml.Root.Element("CreatedDate").Value);
Console.WriteLine(dxml.ToString());

If you run this application on .net net452 you see output:
CreatedDate: 2014-01-23T00:00:00
<root>
  <CreatedDate>2014-01-23T00:00:00</CreatedDate>
</root>

If you run this application as .netCoreApp you see:
CreatedDate: 2014-01-23T00:00:00+01:00
<root>
  <CreatedDate>2014-01-23T00:00:00+01:00</CreatedDate>
</root>

Function DeserializeXNode add time zone to datetime in in .net core.
I check that any test from XmlNodeConverterTest.cs not run for .net core. Function DeserializeXNode don't have test on this platform.
DeserializeXNode.zip

This is because overload XmlConvert.ToString(DateTime, XsdDateTimeFlags) is not avaliable for netstandard1.0, and it ends up with implicit conversion of DateTime to DateTimeOffset (which doesn't support DateTimeKind.Unspecified and assumes local time zone instead).
See https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/Converters/XmlNodeConverter.cs#L1677.
Since date format in XML is fixed and culture-invariant, I'd suggest to replace XmlConvert with custom formatter for DateTime values.

You should read datetime like this:
return XmlConvert.ToString((DateTime)value, XmlDateTimeSerializationMode.RoundtripKind);
see .net core (corefx) source
https://github.com/dotnet/corefx/blob/d0dc5fc099946adc1035b34a8b1f6042eddb0c75/src/System.Xml.XmlSerializer/src/System/Xml/Serialization/XmlCustomFormatter.cs#L202
or see ExtendedXmlSerializer
https://github.com/wojtpl2/ExtendedXmlSerializer/blob/master/src/ExtendedXmlSerializer/PrimitiveValueTools.cs#L61

I meant it when I said it is not supported by netstandard1.0. Particularly, it is not supported in XmlConvert from Profile259 subset. As @JamesNK stated many times, he doesn't plan to move from netstandard1.0, that's why I suggested using a custom serializer.

OK. sorry. I understand now.
Maybe you should add another build for netstandard1.6? (I tell about add "netstandard1.6": {} in project.json)
Or use d.ToString("s") - it generate string always with format ISO 8601 ("yyyy'-'MM'-'dd'T'HH':'mm':'ss".)
https://msdn.microsoft.com/en-us/library/az4se3k1.aspx#Sortable
I checked this option - all project built.
If you don't agree with me please tell me how to create custom serializer for datetime.
Thank you.

I'm not a maintainer of the library, so it's not my call to do so.
But you're certainly welcomed to file a pull request :)

If something required in netstandard1.0 is missing and it is simple to do then the best approach would be to add an internal implementation.

I created the pull request 1015.

Thanks. Fixed!


As a user I want to have different editors for each content type

Description:
When the right sidebar is opened not all editors shall be displayed in one container. The user can select which type of post he wants to create. Afterwards the matching editor is displayed in the right sidebar.
Acceptance criteria:

[ ] Dropdown elements for:
Text notes
Images
Files
Polls
Surveys
[ ] Each element activates the right sidebar with the matching editor
[x] Move datepickers to EditorSidebars

Test case (Web browser):

[ ] Click on each dropdown element and check whether it is opening the corresponding editor

Additional notes:
#223 Aspect 6

Maybe also think about a possible idea like a quick create options for users that mainly use one option?
Or allow the user to set one option afterwards as his default option something like that.

Handed over to @Simon-Deuring


fix: recover url params when switching back to map

@aeschi could not reproduce, for me it always worked, tested with many different trees


Ability to modify toolbar interface styles?

Are the icons styled according to Strapi's design system? They are extremely difficult to make out when they're placed inside button styles. BTW, this is my main gripe with Strapi's default editor.
Is there anyway to make the icons more approachable akin to TipTap's own website?

Just reducing the padding on the button from 8px to 4px then changing the svg within the button to height: 100% and width: 100% makes all the difference.

I honestly agree that it would make a huge improvement! I will look into this.


https://deeplearning.mit.edu/ not available

https://deeplearning.mit.edu/ can't be accessed — could you please take a look at that? This seems to be a DB connection issue.

Thank you for your work, Lex 🤝

FYI it was a temporary issue, works now. however as noted on the specific repository selfdrivingcars.mit.edu no longer works


use fmt to wrap errors, not archived pkg/error

currently, github.com/pkg/errors is used to return error, however since go 1.13 introduced error wrapping, this is deprecated, and the repo has been archived since.

Hi. Thanks for mentioning this; I didn't know that. Do you experience any particular problem with scany using the github.com/pkg/errors package?
Although it's archived, I don't see any urgent reasons to replace it.
But If it's something you would like to work on, I encourage you to shoot a PR with the change.

firstly I'd say this error checking isn't very idiomatic after 1.13 release AFAIK.
it's more idiomatic to export the err, such as ErrNotFound, then users check it like errors.Is(err, ErrNotFound), instead of the current NotFound(err).
another major issue with pkg/errors especially WithStack is that, iirc, you can't call it more than 1 time. e.g., if I use this lib, and again wrap it with WithStack in my code, the previous stack info in this lib will be lost. I haven't used it for quite long, feel free to correct me.

I'll create a PR if you agree with this!

it's more idiomatic to export the err, such as ErrNotFound, then users check it like errors.Is(err, scany.ErrNotFound), instead of the current scany.NotFound(err).

Maybe you are right, and after 1.13 errors.Is(err, scany.ErrNotFound) makes more sense. But I don't see any problems with the scany.NotFound(err) approach either.

another major issue with pkg/errors especially WithStack is that, iirc, you can't call it more than 1 time

I think you are mistaken; it captures all stacks and keeps piling them. Then, later, you unwrap them with errors.Is() or errors.As() when checking for known errors.
All in all, I am optimistic about replacing pkg/errors with the standard implementation, but I would want not to break the current scany API.

Maybe you are right, and after 1.13 errors.Is(err, scany.ErrNotFound) makes more sense. But I don't see any problems with the scany.NotFound(err) approach either.

I suppose the issue is with idiom. users new to scany wouldn't know they need this to check for a certain error

All in all, I am optimistic about replacing pkg/errors with the standard implementation, but I would want not to break the current scany API.

sure, we can have both, i.e., export the ErrNotFound, wrap them, and change the scany.NotFound(err) with checks like errors.Is(err, ErrNotFound) (with the standard lib errors) , how does that sound to you?

I suppose the issue is with idiom. users new to scany wouldn't know they need this to check for a certain error

We could solve it by providing the documentation. Besides that, the new users, after not founding any exported sentinel error in the library, would most likely discover the function with the corresponding name.

sure, we can have both, i.e., export the ErrNotFound, wrap them, and change the scany.NotFound(err) with checks like errors.Is(err, ErrNotFound) (with the standard lib errors) , how does that sound to you?

Sounds good!

We could solve it by providing the documentation. Besides that, the new users, after not founding any exported sentinel error in the library, would most likely discover the function with the corresponding name.

Haha, exactly what I did. 😃

sure, we can have both, i.e., export the ErrNotFound, wrap them, and change the scany.NotFound(err) with checks like errors.Is(err, ErrNotFound) (with the standard lib errors) , how does that sound to you?

Sounds good!

I'll shoot a PR for a small subset of errors, if you'd find that appropriate, will do it for all.

+1, trying to check errors with stdlib's errors.Is doesn't work with stack.
import "errors"

...
errors.Is(err, pgx.ErrNoRows)

+1 on switching to stdlib, i use a framework that check errors with errors.Is and translates to a corresponding API error. Incompatible with the current approach, need to add some hacks around it

Here is the new release with stdlib errors, thanks to @mrkagelui:
https://github.com/georgysavva/scany/releases/tag/v1.2.0
cc: @steeling


Dear author： I’d like to know that how to use serilog.loki to establish a customizing client to make an index for writing logs as Elasticsearch.

Dear author： I’d like to know that how to use serilog.loki to establish a customizing client to make an index for writing logs as Elasticsearch.

Hello, @huzitao!
Sorry, can't get about what index do u talk? Do u mean a search index, used for indexation of log entries?

yes

Main principles of Loki differs from a principles of Elastic Search.
Traditional systems like ELK parse log strings entirely, including fields with a lot of unique values (for example, UserId from log entry) and save parsed data into big indexes. It has advantage that queries could be done fast, cause all required data is in the index. But the disadvantage is an index grows and become very large (in most cases size of the index could be almost equal to a logs size).
Loki works in another way. It's approach requires only most critical data must be extracted into index (called labels). So u have a possibility to find data, using filtration by datetime & labels. And the u could do an additional filtering with LogQL (it's kinda a regex & substring-based language).
U could find more details in Loki documentation.
So, for that approach you should determine most important fields for indexing and setup the sync with filtrationMode Include and filtrationLabels list.
For example:
ILogger logger = new LoggerConfiguration()
    .WriteTo.GrafanaLoki(
          "http://localhost:3100",
           filtrationMode: LokiLabelFiltrationMode.Include,
           filtrationLabels: new [] {"RequestId", "ClientIp", "SomeImportantLogValue"})
    .CreateLogger();

More examples of filtering are here in tests

thank you very much

Thank you for your help.  Meanwhile， i have another question. Does the loki client support custom labels to write logs？I need to write logs by costom labels at present.

谢谢你的帮助我还有一个问题。洛基客户端支持自定义标签写日志吗？我目前需要使用自定义标签编写日志。

Thank you for your help.  Meanwhile， i have another question. Does the loki client support custom labels to write logs？I need to write logs by custom labels at present.

Thank you for your help.  Meanwhile， i have another question. Does the Loki client support custom labels to write logs？I need to write logs by custom labels at present.

@huzitao yes, you could use a global labels. They would append to every log entries from configured service.
ILogger logger = new LoggerConfiguration()
    .WriteTo.GrafanaLoki(
          "http://localhost:3100",
            labels: new [] { new LokiLabel { Key = "app", Value = "payment"}})
    .CreateLogger();

You could find all options in project wiki


monaco ESM build contains an untranspiled require

Hi there. I was delighted to see that you all are now shipping an ESM build of monaco-editor (https://github.com/Microsoft/monaco-editor/issues/18#issuecomment-373086721)! I took it for a spin but encountered what seems to be a bug.
I’ve been using the example monaco + webpack project as reference. The primary editor code loads without issue, but if for some reason web workers fail to load, the web worker fallback throws the following error due to an untranspiled require:
languageFeatures.js:145 TypeError: self.require is not a function
    at eval (editorSimpleWorker.js:395)
    at new Promise_ctor (winjs.base.js:1660)
    at EditorSimpleWorkerImpl.BaseEditorSimpleWorker.loadForeignModule (editorSimpleWorker.js:393)
    at eval (webWorker.js:42)
  ...

monaco-editor version: 0.11.0
Browser: Chrome 64
OS: OSX
Steps or JS usage snippet reproducing the issue:

install monaco-editor 0.11.0
do something silly that prevents web worker bundles from loading (in my case, missing CORS header)
check your console

Let me know if there are any other details you’d like me to provide. Thanks!

That is the code path for the AMD case. It could be reached if a language tries to create a web worker and the correct worker file path is not returned. i.e. a missing or incomplete:
self.MonacoEnvironment = {
	getWorkerUrl: function (moduleId, label) {
		if (label === 'json') {
			return './json.worker.bundle.js';
		}
		if (label === 'css') {
			return './css.worker.bundle.js';
		}
		if (label === 'html') {
			return './html.worker.bundle.js';
		}
		if (label === 'typescript' || label === 'javascript') {
			return './ts.worker.bundle.js';
		}
		return './editor.worker.bundle.js';
	}
}

I am not sure what we should do, as this is ... a configuration error...

Maybe the correct solution here would be to fall back to a dynamic import() that lazily loads the chunk on-demand?

Yes, that is typically the approach we have taken.
The problem is that code should not execute, and it executes due to a configuration error.
The ESM case should fall in this if statement:
https://github.com/Microsoft/vscode/blob/304bb33e6e20d081d487cd807add896acf64c9b9/src/vs/editor/common/services/editorSimpleWorker.ts#L492-L502
and not fall back to trying to dynamically load the specializing module.
i.e. if it would be a dynamic import(), webpack couldn't do anything with it, as it is a variable and not a static string, and it would still throw, but perhaps with a different error message. The solution IMHO is for the integrator to implement MonacoEnvironment. getWorkerUrl correctly.

If I understand this correctly, it might take a little rewriting, but I think it would be achievable via webpack contexts – specifically by creating a ContextReplacementPlugin in the project's webpack config, where you would explicitly specify paths for all the worker fallbacks that could be dynamically imported at runtime. That way, when webpack encounters the dynamic import(), it will check if the path to be imported is one of the configured paths, and then load that module (and throw an error if it is an unrecogni`ed path).
I'm not an expert on this, and the documentation is a bit vague on how this operates, but maybe a webpack pro like @thelarkinn could chime in on whether this is a valid approach?

@timkendrick Thanks! But I don't believe there is anything to change on our side. The editor will at one point invoke new Worker(scriptPath). That creates a new web worker. The scriptPath is something that the integrator alone knows, as the integrator is the person that has bundled the editor under various filenames. i.e. in webpack there is not the same mapping as in AMD where in AMD a module name would indicate its location, in webpack the editor worker can be bundled under any file name...
...
IMHO the exception occurs because the integrator did not implement MonacoEvenironment.getWorkerUrl which is something they have to do. Let's wait for @meyer to get back to us and confirm that was the case.

@alexandrudima I see your point that the worker should always be present and correct (at least as much as a dynamic import would be), but it feels to me like good practice to provide a fallback in case the worker fails for whatever reason. I've been doing some investigation and it's definitely still possible to use the existing fallback mechanism under a webpack environment (see my fork of the monaco webpack sample which fixes this issue).
Looking at the vscode source, I can see why a plain context replacement wouldn't work on its own: the fallback modules are loaded via a call to self.require(), whereas webpack only processes global require()calls. This means the self.require() is left in the source code unprocessed, so when the worker script fails to load, it hits the self.require() and throws an error.
Now at this point we have a couple of different options. The cleanest one in my opinion would be to change the self.require() call to a plain require() in the vscode source if that's possible, and let the user's webpack config handle it by providing a ContextReplacementPlugin with the paths to the various worker scripts that they choose to bundle with their version of the monaco editor. The main problem with this is that I really can't figure out how the ContextReplacementPlugin is meant to work – I just want to map a list of requested module ids to the corresponding worker file sources, which sounds pretty simple, but I don't understand from the webpack documentation how to achieve this.
I'll try to investigate this further if I get a chance, but in the meantime, I got a version working that essentially does the same thing manually via a babel AST transform (see the webpack.config.js in my fork of the sample project). This will use the main-thread fallback versions of the worker scripts if the worker fails to load for some reason, as intended in the original AMD version.
It works by applying a babel transform to the editorSimpleWorker.js file, replacing the self.require() call with a mock require function that comes preloaded with the worker scripts specified in webpack.config.js. The main-thread fallbacks are loaded via standard webpack require() calls, so webpack's normal rules for code splitting etc. apply here.
Example source:
            self.require([moduleId], function (foreignModule) {
                ...

Babel-transformed source:
            (function (_moduleIds, _callback) {
                var _paths = {
                    'vs/language/css/cssWorker': require('/Users/tim/Sites/monaco-editor-samples/browser-esm-webpack/node_modules/monaco-editor/esm/vs/language/css/cssWorker.js'),
                    'vs/language/html/htmlWorker': require('/Users/tim/Sites/monaco-editor-samples/browser-esm-webpack/node_modules/monaco-editor/esm/vs/language/html/htmlWorker.js'),
                    'vs/language/json/jsonWorker': require('/Users/tim/Sites/monaco-editor-samples/browser-esm-webpack/node_modules/monaco-editor/esm/vs/language/json/jsonWorker.js'),
                    'vs/language/typescript/tsWorker': require('/Users/tim/Sites/monaco-editor-samples/browser-esm-webpack/node_modules/monaco-editor/esm/vs/language/ts/tsWorker.js')
                };
                return _callback.apply(undefined, _moduleIds.map(function (_moduleId) {
                    if (!(_moduleId in _paths)) throw new Error('Module not found: ' + _moduleId);
                    return _paths[_moduleId];
                }));
            })([moduleId], function (foreignModule) {
                ...

Webpack output:
            (function (_moduleIds, _callback) {
                var _paths = {
                    'vs/language/css/cssWorker': __webpack_require__(63),
                    'vs/language/html/htmlWorker': __webpack_require__(62),
                    'vs/language/json/jsonWorker': __webpack_require__(61),
                    'vs/language/typescript/tsWorker': __webpack_require__(60)
                };
                return _callback.apply(undefined, _moduleIds.map(function (_moduleId) {
                    if (!(_moduleId in _paths)) throw new Error('Module not found: ' + _moduleId);
                    return _paths[_moduleId];
                }));
            })([moduleId], function (foreignModule) {
                ...

With a little more effort, I'm sure the babel transform could output asynchronous import() expressions instead of require() calls, for better code splitting etc (it helps that the original AMD require is async).
Does this help at all?

@alexandrudima I configured the environment correctly, but I provided paths that were from a different origin because I forgot about the same origin restriction. The web workers then failed to load, which caused monaco to go down the fallback code path and trigger this error.
Here’s a screenshot:

In my case, I need to come up with a way to serve web workers from our CDN, but until then, the non-webworker case is very valid for me.

Ok, so I've figured out how to get this working with the ContextReplacementPlugin.
@meyer, does the sample at https://github.com/timkendrick/monaco-editor-samples/blob/feature/worker-context-fallbacks/browser-esm-webpack/webpack.config.js fix the issue for you? (you'll need to install the babel-loader package)
The babel loader is now only needed to transform the self.require in the monaco editor source code to a global require() call – if the vscode source were updated, the babel loader could be removed.
While this works, the configuration for the ContextReplacementPlugin is a bit fiddly and implementation-dependent, and not the kind of thing you'd want users to be writing. If this is an issue then maybe the monaco-editor package could export a plugin generator function?
I'm imagining something like this in the user's webpack config:
const webpack = require('webpack');
const MonacoWebpackPlugin = require('monaco-editor/webpack');

module.exports = {
  ...,
  plugins: [
    new MonacoWebpackPlugin(webpack), // creates a preconfigured webpack.ContextReplacementPlugin
  ]
};

…or if they wanted to provide a custom set of workers:
  plugins: [
    new MonacoWebpackPlugin(webpack, {
      'vs/language/xyz/xyzWorker': 'monaco-editor/esm/vs/language/xyz/xyz.worker',
    })
  ]

@timkendrick that does the trick! Thanks!

Running along with the ideas in my previous comment, I've built an experiment where all the Monaco webpack configuration is bundled up as a single webpack plugin that the user includes in their webpack config.
It's definitely much more straightforward than before: there's no need for all the entry, MonacoEnvironment, IgnorePlugin, or include 'vs/...' stuff any more. The worker script URLs are automatically generated based on the webpack publicPath setting so there's no need to hook them up manually, and the languages/features are loaded automatically based on the configuration passed to the plugin.
It's also nice that the user doesn't need to know anything about the internals of the monaco-editor: this plugin exposes a single well-defined public API, so there's no chance of breaking the user's webpack config when releasing updates to the editor. Seeing as it is bundled in the main monaco-editor package, plugin updates can be released in lockstep with the editor itself.
To include the full package with all languages you just need:
webpack.config.js:
const webpack = require('webpack');
const MonacoWebpackPlugin = require('monaco-editor/webpack');

module.exports = {
  entry: './index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'app.js'
  },
  plugins: [
    new MonacoWebpackPlugin(webpack)
  ]
};

index.js:
import * as monaco from 'monaco-editor';

monaco.editor.create(document.getElementById('container'), {
	value: 'console.log("Hello, world")',
	language: 'javascript'
});

…or to include a subset of the languages/features, you pass the configuration into the webpack plugin:
webpack.config.js:
const webpack = require('webpack');
const MonacoWebpackPlugin = require('monaco-editor/webpack');

module.exports = {
  entry: './index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'app.js'
  },
  plugins: [
    new MonacoWebpackPlugin(webpack, {
      languages: ['python'],
      features: ['coreCommands', 'findController']
    })
  ]
};

index.js:
import * as monaco from 'monaco-editor/esm/vs/editor/editor.api.js';

monaco.editor.create(document.getElementById('container'), {
	value: 'console.log("Hello, world")',
	language: 'javascript'
});

Things like language aliases and feature names could probably do with a bit of tweaking, but the mechanism seems to work reliably, as well as handling worker fallbacks gracefully.
You can see the source for the plugin itself here, and see examples for the two different setups here and here. I've tested it by npm installing from a local directory and it all seems to work fine.
Let me know if this is helpful / if you have any questions!

@meyer @timkendrick
Even if the errors are addressed, this is still IMHO a mis-configured webpage. Web workers are not starting up because the JS is served from a different domain than the HTML. And then the heavy-lifting code (which creates ASTs and other heavy stuff) runs in the UI thread. This can lead to UI freezes and a horrible a user experience! To reproduce, try to paste a 2MB TypeScript file in the editor (you can use checker.ts from the TypeScript repo) and try to use intellisense, hover, etc... Everything will lag because the expensive computations are not running on a separate thread, in a web worker.
The correct thing to do is to configure the web workers correctly: e.g.
Assuming the HTML lives at www.mydomain.com:
self.MonacoEnvironment = {
	getWorkerUrl: function (moduleId, label) {
		if (label === 'json') {
			return 'https://www.mydomain.com/json.worker.redirect.js';
		}
		if (label === 'css') {
			return 'https://www.mydomain.com//css.worker.redirect.js';
		}
		if (label === 'html') {
			return 'https://www.mydomain.com//html.worker.redirect.js';
		}
		if (label === 'typescript' || label === 'javascript') {
			return 'https://www.mydomain.com//ts.worker.redirect.js';
		}
		return 'https://www.mydomain.com//editor.worker.redirect.js';
	}
}

Then you must create/host 5 worker redirect files on www.mydomain.com:

https://www.mydomain.com/json.worker.redirect.js:

importScripts('www.mycdn.com/json.worker.bundle.js');

...
You can verify web workers are running by not seeing any warnings in the console or by looking in the dev tools for the Threads tab:

Hi @alexandrudima – thanks for looking into this. I realise I've been explaining myself badly and writing a lot, so I'll try to summarise:

Even if the errors are addressed, this is still IMHO a mis-configured webpage.

I agree (which is partly why I was proposing a plugin that minimises the chance of misconfiguration). However it's often seen as good practice to provide a fallback for the possibility that things fail due to network errors etc. That's presumably why this fallback was written in the first place.
Two questions:

Why is the fallback even there if you don't intend it to be used?
Surely as the fallback is there, it's better for it to be a working fallback than a broken fallback?

And then the heavy-lifting code (which creates ASTs and other heavy stuff) runs in the UI thread. This can lead to UI freezes and a horrible a user experience!

Agreed again – however this is a fallback, so presumably the alternative is having no language services at all, which I would say is worse.
Of course, 99% of the time the worker script will be loaded correctly and the fallback code path won't be hit. The fallback is there for the 1% of cases where the worker script doesn't load because they're using IE9, or because their corporate proxy doesn't allow certain types of request.
I'd understand if you decided to just take the fallback out completely (although I think this would be a bad idea), however what I don't understand is having a broken fallback that crashes the user's app with a confusing error message when the worker script fails to load.

@meyer I agree with @alexandrudima on this one, that the fallback should ideally be used only as a fallback and not as the primary means of loading the worker scripts. I also understand how there are some scenarios (e.g. yours), that you just don't have the liberty of being able to load external resources.
My suggestion is to get creative with webpack and write some custom loaders that compile the worker scripts and transform the compiled source into blob URLs. These blob URLs can then be returned from the MonacoEnvironment.getWorkerUrl() function (instead of the usual './editor.worker.js' or whatever). It all feels a bit crazy, but it allows you to embed all the worker scripts into the main source file so they can be run as true worker scripts in their own threads for a stutter-free UI experience.
Obviously if you go down this route you'll end up with an enormous bundle that takes a couple of seconds for the browser to parse, but that's probably unavoidable. I've written some working examples for this approach (see links at the end of this comment), but here's the step by step instructions:
First you'll need to update your getWorkerUrl function to return the webpack-compiled-and-blobified versions of the worker scripts:
index.js:
self.MonacoEnvironment = {
  getWorkerUrl(moduleId, label) {
    switch (label) {
      case 'json': return require('blob-url-loader?type=application/javascript!compile-loader?target=worker&emit=false!monaco-editor/esm/vs/language/json/json.worker');
      case 'css': return require('blob-url-loader?type=application/javascript!compile-loader?target=worker&emit=false!monaco-editor/esm/vs/language/css/css.worker');
      case 'html': return require('blob-url-loader?type=application/javascript!compile-loader?target=worker&emit=false!monaco-editor/esm/vs/language/html/html.worker');
      case 'typescript':
      case 'javascript': return require('blob-url-loader?type=application/javascript!compile-loader?target=worker&emit=false!monaco-editor/esm/vs/language/typescript/ts.worker');
      default:
        return require('blob-url-loader?type=application/javascript!compile-loader?target=worker&emit=false!monaco-editor/esm/vs/editor/editor.worker');
    }
  },
};

N.B. The loader config is embedded in require() paths here for simplicity; I tried specifying them as webpack config rules that apply the custom loaders to these specific files but for some reason that threw up errors in the resulting worker scripts. This approach is definitely ugly, but at least it works.

…then in your webpack config you'll need to add a resolveLoader.alias setting so it recognises the custom blob-url-loader and compile-loader loaders:
webpack.config.js:
module.exports = {
  ...
  resolveLoader: {
    alias: {
      'blob-url-loader': require.resolve('./loaders/blobUrl'),
      'compile-url-loader': require.resolve('./loaders/compile'),
    },
  },
};

…then in the ./loaders directory of the project root you can define the custom blob-url-loader and compile-loader, source code for which are here and here respectively.
I've put together some samples of this in action: see the batteries-included version and the minimal version which both seem to work fine.
Hope that helps!

@timkendrick omg thank you. i owe you bigtime.

Glad that helped! Now we just need someone to publish this as monaco-editor-standalone and everyone else can benefit from it as well… 😉

BTW in case anyone's following along at home, I've just added another webpack sample that outputs a standalone library version as a single monaco.min.js file. This file is a UMD module that can be used in a project via one of the following methods:

Script tag: <script src="./monaco.min.js"></script> (the API is exported as a global monaco variable)
ESM import: import * as monaco from './monaco.min.js'
CommonJS import: const monaco = require('./monaco.min.js')

…so if anyone wants to publish a standalone library build as an npm module, it should be as easy as:

Copy the sample directory contents
Update the package.json to change the name and version etc
Add "main": "./dist/monaco.min.js" to package.json
Add "scripts": { "prepublish": "webpack" } to package.json
npm publish and hope for the best

@timkendrick that bundle is, unfortunately, rather misleading, because it is not minimal.
your composition (browser-esm-webpack-bundled-library):

You can bet you have typescriptServices.js in ts.worker.js, too, because ts.worker.js is just that big.
The following is the composition of "browser-esm-webpack" (also a sample of the sample repository)

Here you can see 2x typescriptServices.js (and more dupes).
Your "minimal" bundle is the same, except that the bundle analyser cannot look into your ts.worker.js because of the inlined stuff, I suppose :)
Sad but true. Also, won't be able to be fixed that quickly, see #776
If you don't want dupes, sadly the AMD version is the only route atm.

i have a similar problem:
self.MonacoEnvironment = {
	getWorkerUrl: function (moduleId, label) {
		if (label === 'typescript' || label === 'javascript') {
			return './ts.worker.bundle.js';
		}
		return './editor.worker.bundle.js';
	}
}

now when i use HTML JSON or CSS language i get the following error (but NO previous worker failure like the thread starter mentioned):
languageFeatures.js:84 Error: self.require is not a function
    at eval (editorSimpleWorker.js:395)
    at new Promise_ctor (winjs.base.js:1660)
    at EditorSimpleWorkerImpl.BaseEditorSimpleWorker.loadForeignModule (editorSimpleWorker.js:393)
    at SimpleWorkerServer._handleMessage (simpleWorker.js:259)
    at Object.handleMessage (simpleWorker.js:245)
    at SimpleWorkerProtocol._handleMessage (simpleWorker.js:117)
    at SimpleWorkerProtocol.handleMessage (simpleWorker.js:89)
    at SimpleWorkerServer.onmessage (simpleWorker.js:249)
    at self.onmessage (editor.worker.js:23)

If the worker is missing I would expect just reduced language features, but not console errors.
Is this intended?
Do I really have to selectively import instead of
import * as monaco from 'monaco-editor';
?

@neoncom Thanks for bringing this up – you're right, perhaps 'minimal' was the wrong name for that version… 😉
To me it seems like there are probably two kinds of redundancy going on here:

The main-thread worker fallbacks are always bundled into the main app output bundle, even for the 'inlined worker' case (which should never load the fallback in a modern worker-enabled browser, making the fallbacks redundant in this case). This would be easily fixed by specifying an empty ContextReplacementPlugin(path.dirname('/path/to/editorSimpleWorker.js'), '', {}) for when you don't want to use the workers (or updating my plugin to add a fallbacks: false option to do this).

The main monaco.contribution.js plugin bootstrap file imports tsMode.js, which imports languageFeatures.js, which imports typescriptServices.js. As long as this is the case typescriptServices.js will be included in the main output bundle. I'd guess that this would need rearchitecting on the vscode side to fix?

@neoncom the self.require issue should be solved by this

@alexandrudima a bit confused on self.MonacoEnvironment - does that need to run in the main thread? Why self and not window? Is there a reason why this isn't simply an option to monaco.editor.create()?

I tried setting self.MonacoEnvironment with getUrlWorker. The function is called, and the URLs returned return the bundle correctly when I navigate to them manually, but I still get the warning "could not load workers".
I also tried the webpack plugin and still see the same issue.
Debuggin is incredibly annoying because my whole browser starts lagging heavily because of the fallback to load into the UI thread. I wish the fallback could be disabled.

I tracked it down - the error that causes the WebWorker creation to fail is ReferenceError: window is not defined in this line in the wrapper added by webpack:
/******/ 	var jsonpArray = window["webpackJsonp"] = window["webpackJsonp"] || [];

The fix is to set output.globalObject: 'self' in the webpack config, which points to the global object in both workers and main thread. I guess 'this' would also work for older browsers. I think this should be added to the webpack config in https://github.com/Microsoft/monaco-editor/blob/master/docs/integrate-esm.md#option-2-using-plain-webpack and is also a prime candidate to appear in the monaco webpack plugin.

@felixfbecker When I run the example at https://github.com/Microsoft/monaco-editor-samples/tree/master/browser-esm-webpack , I cannot find jsonpArray in any of the worker bundles. I wonder what might be different between our setups ?

The only difference I see is that I am using webpack 4.5.0, while the example uses 4.1.1

@alexandrudima The issue is only for 0.12.0 AFAIK for some reason. The sample repo for esm still uses 0.11.0

globalObject seems to only work for webpack 4 I tried setting the target to webworker but also failed. I guess I'll build separately in webpack 4

They are prebuilt in AMD form under the /amd/ folder. Webpack can also load them in AMD form, it is just that webpack must be taught to not attempt to package them again and rather do an xcopy when packing.

To avoid further derails of this issue, I suggest we close it for now, as the original issue the OP reported is fixed. Let's use new issues when new problems are found.

@alexandrudima @timkendrick monaco-editor-webpack-plugin is working quite nicely. thanks to both of you!


Create a method for burning AVAX tokens

Pull request related to this trello task
It relies on This pull request to be merged first

:tada: This PR is included in version 1.4.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Warn if manifest is using a newer schema version

Description of the new feature / enhancement
As more features and functionality are added to winget, new versions of the manifest schema are created to support these features. Often times new Installer Types or other functionality don't constitute breaking changes, but are not supported in older versions of winget.
winget should be able to explain this to the user in a helpful way, either as a warning (for minor schema updates) or an error (for major schema updates, like 1.x -> 2.x). There's a case to be made for it only being an error, but sometimes new schemas only add metadata fields that aren't relevant to whether winget can install a package, so I think it should just be a warning and the user can decide to abort if they want.
C:\Users\epillay> winget install Mozilla.Firefox
Found Mozilla Firefox [Mozilla.Firefox] Version 98.0
Warning: This manifest is using a newer version of the Windows Package Manager schema than this client supports.
We'll attempt to install the package anyway, but it is recommended that you check the Microsoft Store for updates.
<...>

or
C:\Users\epillay> winget install Mozilla.Firefox
Found Mozilla Firefox [Mozilla.Firefox] Version 98.0
Error: This manifest is using a newer version of the Windows Package Manager schema than this client supports.
This client is unable to use the new manifest for installation. Update App Installer in the Microsoft Store to continue.
C:\Users\epillay> # Darn!

Proposed technical implementation details
I don't know if the pre-indexed source currently sends along ManifestVersion, but it would need to for this to work. I'm almost certain the REST source doesn't, but I haven't looked at it in a hot second.
If anyone cares, prior art exists for this in NPM (and I'm sure other package managers). I've seen this quite a few times when Node isn't up-to-date in CI environments:
npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1,
but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!

Related, winget-cli should also communicate to a source which manifest / API versions it supports.
There has been an "APIVersion" query parameter for a long time: https://github.com/microsoft/winget-cli-restsource/blob/f134943b3e28be3422031944db150892fda1a90d/documentation/WinGet-1.4.0.yaml#L591 but it's never set by the client.
This means a source doesn't know which packages it can return to a querying client (it would be of no use to return portable-package manifests to an old incompatible client).
See also: https://github.com/microsoft/winget-cli-restsource/issues/194