What do we call this command-line option?

Consider two TypeScript files:
a.ts
module M {
  export var t = 5;
}

b.ts
var t = 'foo';
module M {
  var s = t; // <-- what does this mean?
}

If we compile b.ts on its own, the t in var s = t refers to the outer var t, a string. The emit for this line is simply var s = t;.
If we compile b.ts along with a.ts, the t in var s = t refers to M.t, the exported variable of type number. The emit for this line is var s = M.t.
This behavior, and a few other language features (e.g. const enum), prevent TypeScript from being able to correctly operate on a single file without understanding the entire universe of files involved in the program. This has performance implications for features like compile-on-save, especially in larger projects, and blocks scenarios like on-the-fly compilation in module loaders.
We'd really prefer to be able to emit a file without first understanding the entire program it's a part of. The language as-is prevents this. However, by slightly subsetting the language to disallow things that require whole-program binding/typechecking, we can re-enable those scenarios. People can "opt in" their project to this language subset as a trade-off.
Tentatively, we're calling the prongs of this fork "whole program mode" and "single file mode". Naming TBD.
A key part of this is that you need to be able to compile e.g. a.ts and b.ts above in a mode that says "This code will not work in single-file-mode", e.g.:
 > tsc --warnMeIfThisIsNotSafeInSingleFileMode a.ts b.ts
TS1234 (b.ts line 2): Modules may not be re-opened in single-file mode

We need some help naming these things, especially the commandline flag. The current list of ideas on the whiteboard, of which nobody likes anything, consists of the following :frowning:

separateCompile
singleFileEmit
disableGlobalOptimizations
safeForTranspile
safeForSyntacticTranspilation
separate
isolated
safeTransform
singleFileScope
crossFileSafe
crossFileRestrictions

Please help :bike: :house:!
Ref #2499

If you're in single-file mode, how do you even know that the module, M, in b.ts is being re-opened?

That's the tricky thing -- this flag isn't a flag that turns on single-file mode. It's a flag that says "Compile this normally, but error if you do anything that doesn't work in single-file mode"

Just in order to be sure, in such a "single-file-mode", does this following file compile?
b.ts
module M {
  export var t = 5;
}

Maybe --segregated, although --singleFileMode seems to say what it does. Maybe put them on the whiteboard until you hate them more than your original ideas :)

Just in order to be sure, in such a "single-file-mode", does this following file compile?

If a.ts is part of the compilation, no. If a.ts is not part of the compilation, then yes.

So, this is not so "single-file" as it would mean... ^_^
Good luck finding an accurate name!

So what you're really doing is adding linting flags or increasing the warnings level to disallow certain unsafe constructs. Is tsc.exe the right place to put this functionality as it has nothing to do with compiling and a lot to do with whether other tools can make assumptions about potentially unsafe constructs?

-singularCompile, -individualCompile, -bounded Compile (bounded context pattern)

Why not --preventConflict since this is the goal of this option.

Is tsc.exe the right place to put this functionality as it has nothing to do with compiling

The entire point of this flag is to enable the compilation of files without examining their dependencies. 99% of the code to do this checking is in tsc already. A hypothetical external tool to do this checking would start with the tsc.js code and make about five edits. So yes, tsc.exe is absolutely the right place for this.

Why not --preventConflict since this is the goal of this option.

This isn't about conflicts. References outside the declaring file to const enums, for example, are disallowed under this flag because they require inlining, but the compiler doesn't know what value to inline without having that other file available.

Maybe --noDependencies or the team suggestion --isolated. Isolated seems to describe the kind of restrictions you may encounter.

@RyanCavanaugh Thanks for your explanations. You know specs better :p
@Steve-Fenton --noDependencies should go on the whiteboard

I'm confused. You want to compile single files without worrying about "the world", but you want to provide warnings about re-opening modules, which you can only do by looking at the world. What am I missing here?

which you can only do by looking at the world. What am I missing here?

This isn't a flag that says "ignore the world". It's a flag that says "Compile this normally, but error if you do anything that doesn't work if you are not allowed to work at the world"

This could be seen as a kind of "strict compilation"

In this mode, we are not allowed to call a function defined in another file, aren't we?

This could be seen as a kind of "strict compilation"

The word "strict" is basically reserved for any "use strict" stuff, especially since many ES6 constructs force their enclosing block to be in strict mode.

In this mode, we are not allowed to call a function defined in another file, aren't we?

It's totally allowed. The only things that would be disallowed are:

Re-opening an internal module (see posted example)
Using a const enum from another file (since we can't inline them without opening another file)
Possibly some edge-case stuff around async/await and the spread operator

Since things that are disallowed are quite special cases, you should maybe consider a term with a vague, broad meaning like --safeCompilation

--standalone

I don't like the "safeFor" stuff, I think names like that are leading to the confusion in the thread -- you're not changing the compilation, you're just adding warnings to the output. How about a flag named a bit more to the point, like: warnForSingleFileUse (or just warnForSingleFile) or even warnOnCrossFileDependencies (or just warnMultiFileSyntax)

What about making it not a boolean flag but rather a two valued enum, something like:
enum CompilationUnit {program, individialFile} so in command line it would be:
 -compileAs program // default one
- compileAs individualFile

@Jaykul If we refer to the cases given by @RyanCavanaugh above, I think any term including "singleFile" or "dependency" a bit too strong since all dependencies are not disallowed but only few of them. Also the compilation would look at the project scope for resolving "simple" dependencies like functions, Thus, the compilation will not be restricted to a "single file", a misleading term I think.

@yahiko00 -- have I misunderstood? The idea is a flag which would be passed when compiling all the files which will warn you about stuff that would prevent you from getting the exact same result if you compiled individual files.
That is: warn me if there's anything that will break if I compile individual files one at a time.
Thus, warnForSingleFileUse -- since the only reason you'd care about these warnings is if you want to be able to to compile single files.

What about something like warnEmitDependencies (warn if the emitted JS of a TS file depends on other TS files).

Maybe the flag could be the answer to the question "why would I use this flag?", for example if it is to allow faster single-file compilation, it could be quickLimitedCompile, for example.

Sidetrack: such issues don't exist when only using external modules right ?

Perhaps it's implicit on if module is specified
Implicit off if people use --out.

@basarat there are still the const enum from an ambient declaration that needs to be flagged here.

@mhegazy can you give me an example of what changes in emit of a file depending on a constant enum in another file.
My follow up question will be "does anything bad happen if we don't do this different emit"

The use of the const enum is replaced by the value (i.e. the number is inlined).

@basarat  emit is not conditioned on the flag. the differences is you will get an error if you use the flag with a full compilation. the example is as follows:
// a.d.ts
declare const enum E {
   a = 0
}

// b.ts
var x = E.a;

in full program compilation mode:
// b.js

var x = 0 /* E.a */;

in single file emit:
// b.js

var x = E.a;

The problem is at single file emit, we have no way to know that E is a const enum, we only emit it as a property access. this might work if a.d.ts was built using ---pereserveConstEnum but will fail with reference error otherwise. The flag will warn you about these cases to ensure your program is safe for single file compilation.
you can see the implementation in PR #2550.

@mhegazy With this new flag, What would be the emit for:
// b.ts
var x = E.a;

(assume E is declared as a const enum but of course with this flag you cannot look at that fact).

The emit would be the same.
The flag is not "emit one file at a time" it is "tell me what breaks if I build one file at a time"

@mhegazy If I have one file a.ts (the one that I am compiling):
module M {
  var s = t;
}

And another file we can't look at:
module M {
  export var t = 5;
}

And yet another we can't look at:
var t = 5;

Would single compiling a.ts still be considered an error?

The current behavior is no.
But if you call ts.transpile it will give u an error because a.ts is not an external module.
Would u propose to make that an error in the command line case?

Would u propose to make that an error in the command line case

No.
With that answer, why can't we get people to just use external modules everywhere? Are we making our lives difficult getting --out to work efficiently? Its not going to be safe for cases like :
module M {
  var s = t;
}

Which is essentially anything that's ambient right?

rant.
Because there is no good answer I would suggest that instead of this feature ... we do a different feature:

only support isolated compile for files that have external modules
Assume any ambient stuff to be valid (this might be coming from lib.d.ts or coming from node.d.ts or something else.... the point is we don't know, its something the build server can sort out)
Assume any import to be valid.

But I guess this is exactly what ts.transpile means?
I don't like out
/rant

But I guess this is exactly what ts.transpile means?

yes :D, that is where we landed. that still leaves you with the const enum from an ambient declaration issue..

that still leaves you with the const enum from an ambient declaration issue..

Got it. We want to expose ts.transpile on some command line flag. Implicit with this flag is:

you have an external module loader, i.e. no --out.
preserveContantEnums: true
Any thing not declared in the file explicitly is assumed to be any.
Any import is any

Reason for no --out : you don't want the build server output to be different from any local fast compile.

Again my feature suggestion:
noExternalLookups
locally:
tsc --preserveConstantEnums --module commonjs --noExternalLookups a.ts b.ts
build server
tsc --preserveConstantEnums --module commonjs a.ts b.ts

@mhegazy can you provide a local vs. build server flags split with the proposed (call it isolated) flag?  Or am I still understanding it wrong?

@basarat i was not thinking of the server/local scenario, but that should work as well.. here is the scenario i had in mind.
you are using something like JSPM, or es6-module-loader (with TypeScript support), system.js enabled website with TypeScript as a transpiler ..etc.. in these work flows, there are no build step. transpilation is happening on the fly, no errors reported from the compiler, only runtime errors from your browser. i.e. the compiler is called through ts.transpile..
now, you would have some tooling, e.g. VS, atom, sublime texts, etc.. you would set the flag ---noExternalLookups in your tsconfig.json, and you will get some red squiggles under const enums use sites, for instance. if you fix all these errors in your editor, you are guaranteed you will get no unexpected runtime-errors when you hit F5 in your browser, or deploy your jspm package.
the same can be said in a workflow like atom plugins, in your editor/local build you would use the flag, then deploy to atom and that will grantee that it is safe to transpile using typescript-simple.

here is the scenario i had in mind

@mhegazy That scenario can be served by:

enabled website with TypeScript as a transpiler : taken care of by ts.transpile
you would have some tooling, e.g. VS, atom, sublime texts, etc : The user uses external modules and has --preserveConstantEnum:true.

This way any errors in the tooling are errors at runtime otherwise runtime will work fine.
Does that not cater for it, or do we still needs this flag?

even with --perseveContantEnum, if you are consuming a const enum from another .d.ts that was not built with --perserveConstantEnum, it is going to fail at runtime.

Got it. Effectively this new flag is for IDE's to:

Warn on const enum usage
Warn on reopening internal module usage
others later ... hopefully not.

With the purpose of safe for per file transpilation.
So : checkSafeForTranspile.

for future references, the flag name is --isolatedModules

I noticed the autocomplete in VSCode for my tsconfig included the isolatedModules option.  The current documentation is "Unconditionally emit imports for unresolved files."  This didn't mean anything to me so I searched around and found this conversation, which sounds completely different than the definition in the docs.  Can I get some clarification on what this option does?

I makes the compiler behave as if you called ts.transpile (https://github.com/Microsoft/TypeScript/issues/2499) on each file sparely.
There are some rules in place, i.e. const enums are always preserved, no namespaces, and the emitter will emit some checks when inlining types for decorators.
if you are not using ts.transpile to transpile your file one at a time, you do not need to care about this flag.

@mhegazy - +1 for updating the current docs for this argument, with a better explanation or a link to a more detailed explanation like the one you have just given! :-)


Terminal pagination breaks after resize

Windows Terminal version
1.16.10262.0
Windows build number
10.0.22621.1702
Other Software
git version 2.39.2.windows.1
Steps to reproduce

start a terminal
run a command which uses a pager e.g. git log
Maximize the terminal pane
Page down (space) a few pages
Terminal goes unresponsive (i.e. the 'less' prompt does not reappear)

Expected Behavior
Scrolling down keeps working normally
Pressing 'q' quits the pager
Actual Behavior
One must interrupt to get the prompt back.
For some reason terminal within vscode cannot be interrupted with keyboard & one must kill the task.
See https://github.com/microsoft/vscode/issues/180406

Yes, same behavior with conhost and sizes equal.

Looks like this is an issue with the Windows port of "less". We'll raise the issue with the upstream project. Thanks!

@dqgthb Could you maybe provide any more info? When this got ported out to https://github.com/gwsw/less/issues/411, OP couldn't repro the issue anymore. Are you using the Terminal or conhost? Which version? Which version of less, and how are you running it (basically, is this WSL less, less.exe, git bash less, some less via ssh...)
It might warrant your own issue, since clearly whatever was at the root of OP's issue was transient, and we might not want to cross-pollute your bug report with the one from OP.


chore(docs): Add queue github task link

This project uses semver, please check the scope of this pr:

[x] #patch# - backwards-compatible bug fix
[ ] #minor# - adding functionality in a backwards-compatible manner
[ ] #major# - incompatible API change

Changes Unknown when pulling 5d71f8efbdcdfb1cebac6c7d635e1223b011f0bd on chore/documentation-update into ** on master**.

Changes Unknown when pulling 5d71f8efbdcdfb1cebac6c7d635e1223b011f0bd on chore/documentation-update into ** on master**.


Feature Request : Allow to customize the Bibliography Format

Current #bibliography function is great with three inbuilt styles, until some journal requires the bibliography to be set in their own specific style. Can we have some way to customize the format of bibliography, at least in what order various elements appear, and their style ; or a way to provide a callback function which will accept the reference number and reference data (from .bib file or other) and return Content .
Thank you!

For those who are looking for a solution in meantime, I did

// must set size to 0, if we use hide, then #cite does not work
#[
#set text(size: 0pt)
#bibliography("ref.bib",style:"ieee")
]

#linebreak()

// actual 'Bibliography' title
#[
#set text( size: 15pt)
*Bibliography*
]

// ... manually write refs one by one, in the order given by original bibliography

At least bibliography headings can be modified with show rules in the next release #ff1e4049d168.

I believe there could be some system for customizing bibliography styles, e.g. a function that takes a dict with all information specified for a given item of the bibliography file. This might ultimately be necessary to accomodate for all styles around the world (by letting users customize them entirely).

How about a function (let's say #iter-bibliography) that has the same effect as #bibliography, but it does not place a finished formatted bibliography but returns a dictionary where the key is the label of the citation and the value is a dictionary holding the bibliographic raw data (author, title, journal, etc.).
I would then expect to be able to use it as follows:
#for (label, entry) in iter-bibliography("references.bib") {
  [#label: #entry.author, #emph(entry.journal) #bold(entry.volume) (#entry.year), #entry.pages . \]
}

One would need to iterate over the authors as well, but I hope this gets the idea across.
Something like this may be possible with the feature suggested in #1220 , but having the iterator over the bibliography would perhaps make it a little easier to quickly customize the bibliography.

Would be great if more styles can be supported.
I would actually be interested in alpha as e.g. declared here: https://web.archive.org/web/20161119024545/http://sites.stat.psu.edu/~surajit/present/bib.htm

I believe there could be some system for customizing bibliography styles, e.g. a function that takes a dict with all information specified for a given item of the bibliography file. This might ultimately be necessary to accomodate for all styles around the world (by letting users customize them entirely).

This seems as the best option. Maybe the way in which they can be style can be similar with outline.entry for outlines.

How about a function (let's say #iter-bibliography) that has the same effect as #bibliography, but it does not place a finished formatted bibliography but returns a dictionary where the key is the label of the citation and the value is a dictionary holding the bibliographic raw data (author, title, journal, etc.).

I think it would be better and more extensible if the bibliography function could take as an argument a function that displays an individual item. Citations could also use a style parameter for rendering each cited item. Such style parameter could be made global. For example:
#cite("something", style: weird-journal-style.bibliography-item)
#bibliography("works.bib", item: weird-journal-style.bibliography-item)

I think it would be better and more extensible if the bibliography function could take as an argument a function that displays an individual item.

Having a bibliography.entry or bibliography.item function would give you very similar capabilities in combination with show rule.

@Edenhofer

Is there any way currently to customize the style of the bibliography no matter how hacky?

You can supply your own CSL style to the bibliography function. See https://typst.app/docs/reference/meta/bibliography/#parameters-style

Is there some way to customize the bib through a post-processing step, for example, to highlight certain author entries or automatically replace certain keywords? From what I can see, CSL doesn't seem to easily support this.

You can do very hacky things to make a auto sorted custom bibliographies for now.
#let fakebib(yaml-data) = {
  // [= Bibliography]

    let format-entry(b) = {
         b.author
         [. ]
         b.title
         // etc.
    }
    locate(loc => {
        // Get all ref'd cite `@doe2024` cf. https://discord.com/channels/1054443721975922748/1179252098362253384/1179258313863606283
        // Limitation: it will not work on #cite(<doe2024>) though
        let citations = query(ref.where(element: none), loc).map((r) => str(r.target)).dedup()

       enum(
          numbering: "[1]",
          ..citations.map((c) => format-entry(yaml-data.at(c)))
    )
  })
}

#show bibliography: it => {
    set text(size: 0pt)
    show heading: set text(size: 12pt)
    it
}

@may2000 @doe2024

#bibliography("citations.yml", style: "ieee")
#fakebib(yaml("citations.yml")) // Read yaml file here because if you put fakebib() into a package, it cannot access your hayagriva yaml file

doe2024:
    type: Book
    title: Typst Example
    author: John Doe

may2000:
    type: Article
    title: Typst Example 2
    author: Jane May

Is there some way to customize the bib through a post-processing step, for example, to highlight certain author entries or automatically replace certain keywords? From what I can see, CSL doesn't seem to easily support this.

this is a common need for academic CVs. It'd be really great if there was a way to post process the output of cite(..., form: "full").

Is there some way to customize the bib through a post-processing step, for example, to highlight certain author entries or automatically replace certain keywords? From what I can see, CSL doesn't seem to easily support this.

this is a common need for academic CVs. It'd be really great if there was a way to post process the output of cite(..., form: "full").

Is this still not possible? This is kind of vital to have to stay in the "philosophy" of the easy to use nature of typst

A related functionality that I find lacking is the ability to turn arbitrary parts of the bibliography entries into links; this is not supported by CSL: https://docs.citationstyles.org/en/stable/specification.html#appendix-vi-links (In this case, I would have wanted to turn just the journal reference in a #cite(<ref>, form: "full") into a link, not the author names. Making the full citation a link works by wrapping into a #link("dest", cite(key, ...)), but requires me to manually input the link target instead of taking it from the bibliography.)


Update iteration.d UT comment

Circleci failure is unrelated. Something's segfaulting in the style check step.


Add ProductLog theme

@apvarun we will need to add Notion as a cms before we can merge this.

@JugglerX Anything I need to do here? if not, when can I expect notion as a source


Added missing icon on index.astro

So I went ahead & added an SVG of an eye, which we'll call eye, to the IconPath.ts file. I got the SVG from phosphoricons & I removed the <svg></svg> wrapper. Also, went ahead & removed the unwanted project from the site. Check it out

Thanks. This looks good.


[ci:component:github.com/gardener/autoscaler:v0.10.0->v0.12.0]

Release Notes:
Autoscaler avoids scaling down the machines which are already being terminated.

/assign @hardikdr
/invite @hardikdr

/close
I'd open a version bump PR manually, as we want to run 2 versions of CA, one for < k8s 1.16 , and one for >= k8s 1.16 .


Trouble running with Windows Ollama

Hi, I'm trying to get twinny running with ollama on windows. When it works it runs great, however it doesn't seem to work a lot of the time, and when it doesn't work it is basically impossible to figure out what is wrong. It really needs some feedback on what is happening in the setup stage after detecting ollama and running model.
What happens is that it detects Ollama and the model it is running, but completion doesn't happen and when you send a chat nothing happens. I've tried turning on the log option but there are no logs output. I've just tried with the basic codellama. I checked the ollama logs and it seems to stop sending requests after the first one - maybe it gets stuck in a loop or something. My local openwebui works fine with ollama.

A bit more info - it seems to be sending something off to ollama - here's the ollama log - the successful one on top is from a script I used to make sure /v1/chat/completions was working. Again there are no logs generated by twinny so I have no idea what it is doing outside of breaking out wireshark. I've tried both http/https etc..
[GIN] 2024/10/24 - 02:45:11 | 200 |    379.5247ms |       <IP_ADDRESS> | POST     "/v1/chat/completions" <-- my script
[GIN] 2024/10/24 - 02:45:29 | 200 |      1.2039ms |       <IP_ADDRESS> | GET      "/api/tags"
[GIN] 2024/10/24 - 02:45:43 | 404 |            0s |       <IP_ADDRESS> | POST     "/v1/chat/completions" <-- 404 when twinny does it
--------- script for ref
from openai import OpenAI
client = OpenAI(
base_url='http://localhost:11434/v1/',
# required but ignored
api_key='ollama',

)
chat_completion = client.chat.completions.create(
messages=[
{
'role': 'user',
'content': 'Say this is a test',
}
],
model='codellama',
)

Hey, thanks for the report. If you open developer tools on vscode Help > Toggle Developer Tools there should be logs in there. Hope it helps. It's difficult for me to to help with support on an individual basis so let me know if that provides any idea into the problem. Many thanks.

Understandable! Turns out this is user error. In the past I used only codellama:latest - now you have to fetch 7b-instruct and 7b-code both individually. Twinny wasn't respecting the model name I put in each - it was forcing 7b-instruct for chat and 7b-code for api/generate, which made debugging it a lot harder. Anyway, closing since it's user error - thanks! Sorry to waste your time.


avoid buffer-size larger than memory limit

close https://github.com/juicedata/juicefs-csi-driver/issues/730

Codecov Report
Patch coverage: 86.66% and project coverage change: +0.23% :tada:

Comparison is base (864d9db) 38.16% compared to head (1ae4be3) 38.40%.
Report is 4 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #742      +/-   ##
==========================================
+ Coverage   38.16%   38.40%   +0.23%
==========================================
  Files          33       33
  Lines        4087     4114      +27
==========================================
+ Hits         1560     1580      +20
- Misses       2380     2386       +6
- Partials      147      148       +1

Files Changed
Coverage Δ

pkg/config/config.go
0.00% <ø> (ø)

pkg/juicefs/juicefs.go
49.63% <81.81%> (+0.56%)
:arrow_up:

pkg/config/setting.go
75.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


add foundry.toml configuration

rn some settings can be configured via env vars (see dapp tools env vars, .dapprc)
to make migrating as painless as possible, there should be a forge config {init, migrate} command to create the default toml file or migrate from .dapprc (as much as possible, since .dapprc is a script, focus is on all key-value settings)
This will not be limited to critical settings, like endpoint etc, but should also provide a way to configure something like color output eventually.
Some settings, therefore are intended to apply globally. To support that we could support a global config file at ~/foundry.toml and one in a project as well, which "inherits" from that global one
This requires clear priorities for determining the final "Config":
global vars > repository config > global config

How do you envision the migrate command should work/what are constraints on the migrator since .dapprc is essentially just a shell script?

have a look at https://github.com/gakonst/foundry/pull/297 README.md
the easiest would be to use already set env vars when populating the Config type.
so after source .dapprc we can merge the vars:
https://github.com/gakonst/foundry/blob/aee88f9451c2c66c3b1e50b08976295e32bb2c8b/config/src/lib.rs#L229-L233
if we add .merge(Env::prefixed("DAPP_").global())
but this only works for vars, there's no alternative solution to .dapprc functions.

Minor point that source .dapprc would need to happen outside of the migrate command, since it proved to be quite hard to run a shell script and get its outputs https://github.com/gakonst/foundry/pull/190


Update syntatis/utils

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


2.6 roadmap

[x] No-column print in ls and ls-remote if piping isatty stdout. #249
[x] Do not hide installed plugins in fisher ls-remote. #250
[x] Auto-complete only fisher [install] with ls-remote output if available. #256
[x] Use a single source of truth for the blacklisted plugins. #255
[x] Check if git, curl, etc., are installed before using them and inform the user about it. #253

https://github.com/fisherman/fisherman/commit/62e5b3e6b2bf4965baf8b3a4afea1e609abc7369


Setup with proxy

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
Hi,
Can't install with proxy : download-dist don't download dist.tar.gz.
Proxy configuration for npm :
npm config set proxy "my.proxy.lan:8080" npm config set https-proxy "my.proxy.lan:8080"
Error message :

root@vm:~/uptime-kuma# npm run setup

<EMAIL_ADDRESS>setup
git checkout 1.10.2 && npm ci --production && npm run download-dist

HEAD est maintenant sur bf64095 update to 1.10.2
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package<EMAIL_ADDRESS>npm WARN EBADENGINE   required: { node: '14.*' },
npm WARN EBADENGINE   current: { node: 'v12.22.5', npm: '8.1.4' }
npm WARN EBADENGINE }
npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS><EMAIL_ADDRESS>is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Please, upgrade your dependencies to the actual version of core-js.
added 430 packages, and audited 431 packages in 22s
26 packages are looking for funding
run npm fund for details
9 moderate severity vulnerabilities
To address issues that do not require attention, run:
npm audit fix
To address all issues, run:
npm audit fix --force
Run npm audit for details.

<EMAIL_ADDRESS>download-dist
node extra/download-dist.js

Downloading dist
https://github.com/louislam/uptime-kuma/releases/download/1.10.2/dist.tar.gz
events.js:291
throw er; // Unhandled 'error' event
^
Error: connect ETIMEDOUT <IP_ADDRESS>:443
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1138:16)
Emitted 'error' event on ClientRequest instance at:
at TLSSocket.socketErrorListener (_http_client.js:427:9)
at TLSSocket.emit (events.js:314:20)
at emitErrorNT (internal/streams/destroy.js:92:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
errno: 'ETIMEDOUT',
code: 'ETIMEDOUT',
syscall: 'connect',
address: '<IP_ADDRESS>',
port: 443
}
npm ERR! code 1
npm ERR! path /root/uptime-kuma
npm ERR! command failed
npm ERR! command sh -c git checkout 1.10.2 && npm ci --production && npm run download-dist
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2021-12-02T12_22_50_235Z-debug.log

Thanks.
🐻 Uptime-Kuma Version
1.10.2
💻 Operating System and Arch
Debian 11
🌐 Browser
Firefox
🐋 Docker Version
No response
🟩 NodeJS Version
No response

Hi, the error looks like related with Node.js version, could you try with node version >= 14

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE package<EMAIL_ADDRESS>npm WARN EBADENGINE required: { node: '14.*' },
npm WARN EBADENGINE current: { node: 'v12.22.5', npm: '8.1.4' }

You can download dist.tar.gz manually in the release page.
https://github.com/louislam/uptime-kuma/releases/tag/1.10.2

Hi, where is the full path fo dist ?

Find a workaround :
When installation script fails, edit uptime-kuma/extra/download-dist.js and look at this line :
const url='https://github.com/louislam/uptime-kuma/releases/download/${version}/${filename}';
Download this file, where X.X.X is the last release :
https://github.com/louislam/uptime-kuma/releases/download/X.X.X/dist.tar.gz`;
Upload dist.tar.gz on a local webserver or a local NextCloud (so, no proxy used), and retreive download URL. Edit the "const url" line on download-dist.js with this new URL, like it :
const url='http://cloud.network.local/index.php/s/xxxxxxxxx/download/dist.tar.gz';
Save the file and relaunch :
pme2 delete all ; bash -f kuma_install.sh
Now installation will be OK.

You can download dist.tar.gz manually in the release page.
https://github.com/louislam/uptime-kuma/releases/tag/1.10.2

Tried it but script still trying to check online. It always download, even with dist.tar.gz on directory.


Cargo hangs when initializing or creating a project on a network share on Windows

I'm using Windows 10, msys-git and rustup. I mount the network share on a Z: drive. Git works fine, but cargo doesn't. It doesn't produce any output, it just hangs, no matter if I run cargo new myproject or cargo init in an already created directory. I have full permissions on the share and cargo works fine if I mount the share on linux.

Thanks for the report! Does it work if you pass --vcs none? The git library we're using, libgit2, has historically had trouble with network filesystem volumes but I"m not sure if that'd be the cause here.

No, --vcs none has no effect.

Unusual! This'll be pretty difficult to debug remotely, unfortunately. Could you attach a debugger to a running Cargo process and see where it's hanging? A backtrace would be quite useful!

When I run the process from gdb and then break in it, I get the following
(gdb) bt
#0  0x00007ff8833852f7 in SetHandleCount () from C:\WINDOWS\System32\KernelBase.dll
#1  0x0000000000000000 in ?? ()

When I run cargo separately and then attach gdb I get this
(gdb) bt
#0  0x00007ff886559921 in ntdll!DbgPrint () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ff8865819ba in ntdll!DbgUiSetThreadDebugObject () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x0000000000000000 in ?? ()

Not sure how helpful this is. The stack trace is from the debug build of cargo git.

Perhaps the MSVC build of Cargo could be attempted? I think those tend to have better stack traces at least.

 Here's the proper call stack:
>	cargo.exe!git2::repo::Repository::discover<&std::path::Path>() Line 14	Unknown
 	cargo.exe!cargo::util::vcs::GitRepo::discover(std::path::Path * path) Line 17	Unknown
 	cargo.exe!cargo::ops::cargo_new::existing_vcs_repo(std::path::Path * path, std::path::Path * cwd) Line 373	Unknown
 	cargo.exe!cargo::ops::cargo_new::mk(cargo::util::config::Config * config, cargo::ops::cargo_new::MkOptions * opts) Line 381	Unknown
 	cargo.exe!cargo::ops::cargo_new::new(cargo::ops::cargo_new::NewOptions opts, cargo::util::config::Config * config) Line 286	Unknown
 	cargo.exe!cargo::new::execute(cargo::new::Options options, cargo::util::config::Config * config) Line 134	Unknown
 	cargo.exe!cargo::call_main_without_stdin<cargo::new::Options>(core::result::Result<(), cargo::util::errors::CliError>(*)(cargo::new::Options, cargo::util::config::Config *) exec, cargo::util::config::Config * config, &str usage, &[collections::string::String] args, bool options_first) Line 124	Unknown
 	cargo.exe!cargo::try_execute(cargo::util::config::Config * config, &[collections::string::String] args) Line 258	Unknown
 	cargo.exe!cargo::execute(cargo::Flags flags, cargo::util::config::Config * config) Line 222	Unknown
 	cargo.exe!cargo::call_main_without_stdin<cargo::Flags>(core::result::Result<(), cargo::util::errors::CliError>(*)(cargo::Flags, cargo::util::config::Config *) exec, cargo::util::config::Config * config, &str usage, &[collections::string::String] args, bool options_first) Line 124	Unknown
 	cargo.exe!cargo::main::{{closure}}(closure *) Line 87	Unknown
 	cargo.exe!cargo::main() Line 80	Unknown
 	cargo.exe!panic_unwind::__rust_maybe_catch_panic() Line 97	Unknown
 	cargo.exe!std::rt::lang_start() Line 51	Unknown

Interesting... so it looks like it may still be related to libgit2 even though --vcs none is being passed. Despite the top stack trace pointing to Rust code in git2-rs my guess is that the thread is actually stuck somewhere inside libgit2...

filed an issue:
Next question: is cargo supposed to search for a git repo when the user explicitly says not to?

Nah yeah if vcs is disabled I think we could definitely skip this logic!

libgit master now has a fix for this. So the issue can be closed as soon as you update the submodule.

Sent a PR as https://github.com/rust-lang/cargo/pull/3714
Thanks for the ping!

Fix with #3714


DotNetCliToolReference

According to messages from SDK 2.1 tools, using the element DotNetCliToolReference (e.g. for reference to Microsoft.EntityFrameworkCore.Tools.DotNet) is deprecated, because it is included in .NET Core SDK.

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

ID: b34c4871-adc3-0d13-6f20-6f6ac1f65e91
Version Independent ID: ea1742b3-808b-d449-3308-6847a9f339f9
Content: Add a model to an ASP.NET Core Razor Pages app with Visual Studio Code
Content Source: aspnetcore/tutorials/razor-pages-vsc/model.md
Product: aspnet-core
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

To complement: this tutorial ("Razor Pages web app with VS Code") has .NET Core 2.1 SDK or later as a prerequisite. So using older techniques is misleading a bit.

Dup of #7233

This is not a duplicate #7233, again, because it is about another behavior.


Enable SpringwolfKafkaProducer configuration from the user

Do I understand it correctly, that it should be possible to configure https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/autoconfigure/kafka/KafkaProperties.Producer.html in the application configuration to give full control over the KafkaTemplate (independent of what was or was not configured as part if the spring configuration)?

@stavshamir I started working with my interpretation of the feature and added #144 as a proposal

The new version of springwolf has been released. Thank you @sam0r040 for the contribution


UTxO HD performance: On-disc backend

What?
Performance assessment of the UTxO HD functionality, configured with the on-disc backend.
Why?
UTxO HD is expected to bring a regression to the node performance.
The attendant risks need to be assessed.
Dependencies

Cross-team collaboration.

Superseded by https://github.com/input-output-hk/ouroboros-consensus/issues/203


ii testing Conformance results for v1.20/vcluster

Pre-submission checklist:
Please check each of these after submitting your pull request:

[ ] If this is a new entry, have you submitted a signed participation form?
[ ] Did you include the product/project logo in SVG, EPS or AI format?
[ ] Does your logo clearly state the name of the product/project and follow the other logo guidelines?
[ ] If your product/project is open source, did you include the repo_url?
[ ] Did you copy and paste the installation and configuration instructions into the README.md file in addition to linking to them?

Found v1.20 in logs

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

All requirements have passed for the submission!

All requirements have passed for the submission!

Found v1.20 in logs

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

Some requirements have not passed:

Found v1.20 in logs

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

Some requirements have not passed:

Check e2e.log for Kubernetes release version

Unable to use file 'e2e.log' in product submission PR, because it does not contain a release version of Kubernetes in it

All requirements have passed for the submission!

Found v1.20 in logs

Some requirements have not passed:

a test label is set

idk something lol

Found v1.20 in logs

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

Some requirements have not passed:

a test label is set

idk something lol

All requirements (16) have passed for the submission!

All requirements (16) have passed for the submission!

Found v1.20 in logs

All requirements (0) have passed for the submission!

All requirements (0) have passed for the submission!

All requirements (1) have passed for the submission!

Found v1.20 in logs

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

All requirements (5) have passed for the submission!

Found v1.20 in logs

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

All requirements (6) have passed for the submission!

Found v1.20 in logs

All requirements (1) have passed for the submission!

All requirements (1) have passed for the submission!

Found v1.20 in logs

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

All requirements (1) have passed for the submission!

Found v1.20 in logs

Some requirements have not passed:

a test label is set

idk something lol

All requirements (1) have passed for the submission!

Some requirements have not passed:

a test label is set

idk something lol

All requirements (1) have passed for the submission!

Some requirements have not passed:

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

[FAIL] the submission release version is a supported version of Kubernetes

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

7/9 requirements passed. Please review the following:

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

[FAIL] the submission release version is a supported version of Kubernetes

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

7 of 9 requirements have passed. Please review the following:

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

[FAIL] the submission release version is a supported version of Kubernetes

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

7 of 9 requirements have passed. Please review the following:

[FAIL] there are labels for tests succeeding

there are no labels found

[FAIL] the submission release version is a supported version of Kubernetes

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

7 of 9 requirements have passed. Please review the following:

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

[FAIL] the submission release version is a supported version of Kubernetes

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

7 of 9 requirements have passed. Please review the following:

[FAIL] there are labels for tests succeeding

there are no labels found

[FAIL] the submission release version is a supported version of Kubernetes

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

7 of 9 requirements have passed. Please review the following:

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

[FAIL] the submission release version is a supported version of Kubernetes

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

7 of 9 requirements have passed. Please review the following:

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

[FAIL] the submission release version is a supported version of Kubernetes

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

8 of 9 requirements have passed. Please review the following:

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

7 of 9 requirements have passed. Please review the following:

[FAIL] the PRODUCT.yaml metadata contains required fields

unable to use field 'documentation_url' in PRODUCT.yaml as the data in the resolved content (text/plain; charset=utf-8) doesn't match what is expected (text/html). Please ensure that the urls resolve to exact resources intended (especially for an image the exact image url)

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

8 of 9 requirements have passed. Please review the following:

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

9 of 10 requirements have passed. Please review the following:

[FAIL] there are labels for tests succeeding

unable to find required label 'no-failed-tests-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing
unable to find required label 'tests-verified-v1.20' on this PR. It may be safe to ignore and wait for it to appear if everything else is passing

All requirements (9) have passed for the submission!

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

Automatically verified as having all required tests present and passed

All requirements (10) have passed for the submission!

9 of 10 requirements have passed. Please review the following:

[FAIL] it seems the e2e.log does not contain the Kubernetes release version that match the submission title

the file 'e2e.log' does not contain a release version of Kubernetes in it

All requirements (10) have passed for the submission!

All requirements (12) have passed for the submission!

All requirements (12) have passed for the submission!

All requirements (12) have passed for the submission!

11 of 12 requirements have passed. Please review the following:

[FAIL] it appears that the PRODUCT.yaml file does not contain all the required fields (https://github.com/cncf/k8s-conformance/blob/master/instructions.md#productyaml)

func received more arguments than expected: expected 4 arguments, matched 2 from step

for a full list of requirements, please refer to these sections of the docs: content of the PR, and requirements.

All requirements (12) have passed for the submission!

All requirements (12) have passed for the submission!

11 of 12 requirements have passed. Please review the following:

[FAIL] it appears that the PRODUCT.yaml file does not contain all the required fields (https://github.com/cncf/k8s-conformance/blob/master/instructions.md#productyaml)

unsupported argument type: the argument 2 type bool is not supported

for a full list of requirements, please refer to these sections of the docs: content of the PR, and requirements.

All requirements (12) have passed for the submission!

All requirements (13) have passed for the submission!

All requirements (13) have passed for the submission!

12 of 13 requirements have passed. Please review the following:

[FAIL] the Kubenetes release version in this pull request does not qualify for conformance submission anymore (https://github.com/cncf/k8s-conformance/blob/master/terms-conditions/Certified_Kubernetes_Terms.md#qualifying-offerings-and-self-testing)

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

for a full list of requirements, please refer to these sections of the docs: content of the PR, and requirements.

13 of 14 requirements have passed. Please review the following:

[FAIL] the Kubenetes release version in this pull request does not qualify for conformance submission anymore (https://github.com/cncf/k8s-conformance/blob/master/terms-conditions/Certified_Kubernetes_Terms.md#qualifying-offerings-and-self-testing)

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

for a full list of requirements, please refer to these sections of the docs: content of the PR, and requirements.

13 of 14 requirements have passed. Please review the following:

[FAIL] the Kubenetes release version in this pull request does not qualify for conformance submission anymore (https://github.com/cncf/k8s-conformance/blob/master/terms-conditions/Certified_Kubernetes_Terms.md#qualifying-offerings-and-self-testing)

unable to use version 'v1.20' because it is older than the last currently supported release (v1.21)

for a full list of requirements, please refer to these sections of the docs: content of the PR, and requirements.


Feeds no longer produce functional URLs

As of ~September 6th, it looks like the <enclosure url> fields within hosted feeds are no longer resolving to valid audio/video links. The rest of the feed appears to build correctly.
I've tested the public instance as well as a personal one; the same issue is present in both.

Looks like there’s a new issue with the ytdl-core package. I’ve updated to a patched version of the package and it seems to be working now.


add instantiable support for treasury pallet

With instantiable support, runtime could manage seperated funding pots with dedicated module id.
This enhancement uses DefaultInstance which no impact on current single instance using.

missed benchmark change, will update.

you should also make use of benchmarks_instance! instead of benchmarks

We are done with our review for this PR - please refer to issues #15 and #16 in the internal tracker.

I see issues 15 and 16 were not introduced by this PR thus it seems to me valid to consider this issue as audited.


feat: Secure React Native gRPC connections

To secure the React Native gRPC connection, we implement a transport that uses native calls to make the gRPC calls instead of a TCP connection.
Only the server streaming is implemented in this PR (we don't need the client streaming).
Flow:
React-Native gRPC client <-> native (Android/iOS) <-> golang gRPC client (UDS) <-> golang gRPC server

Does this PR resolve issue #20?


Optionally fetch client_secret from SSM

The client_secret is fetched from SSM and injected into the
provider_details map.

@gordonj7 @akibare999 copied this branch into her own fork. I'm closing out this pull request. See https://github.com/techservicesillinois/terraform-aws-cognito/pull/3.


Fix dart inplace prediction with GPU input.

On C API there's a check for output prediction being device-readable.  With dart this doesn't hold.
Added optimization to avoid memory copying whenever possible.  Will post the result later.

100 rounds on higgs:
Before:
Train::Duration: 1497.7212617397308
After:
Train::Duration:<PHONE_NUMBER>732025

Trying to understand what this PR does.

Your summary is correct.


fix #3: Create a custom IPropertyIndexValueFactory to customise Examine Index property value

Fixes #3 This will mean only the content of the cells is stored in the examine index and searchable

Hi @Nysosis and thanks for creating this PR 👍
I think that we may have some code that relies on the field being the JSON structure opposed to a more friendly text as proposed by your PR. As such this is a breaking change.
I know Umbraco are doing doing similar for some of the build-in property editors, but I'm not always a fan of this either.
One approach could be to keep the existing field, but then also add the search friendly text as an additional field. Eg. if the field key is tableData, a second field with the key tableData_search is added with the search friendly.
Since we're using this package for many of our client projects, I need to have a chat with my colleagues on the best way to proceed.

Hi @Nysosis
The PR in general is fine, but like mentioned in my previous comment, we think the original JSON should remain in the index. I'll merge the PR, but I'm also looking into saving two different fields in the index.


FR: For macOS, don't unnecessarily stub out iOS+ SDK

Hey wonderful Firebase folks,
The iOS+ SDK these days has pretty broad support for macOS. But on quick inspection, it looks like a lot of that functionality, e.g., Analytics, is unnecessarily stubbed out in this C++ SDK.
Could you fix that? It seems like it wouldn't be that hard to change the build to pipe it through, same as tvOS, since the underlying pieces are there.
Thanks for your consideration!
Chris
(ex-Googler)
P.S. If it's already supported--and I've missed it, then please correct me, and my apologies in advance.
P.P.S. #234 is related in that both involve desktop analytics support, but this issue differs in that it should be quite easy to add macOS support more broadly, since it's already supported by an underlying platform SDK.

Hi Chris,
As you mentioned the iOS+ SDK now supports many things that are otherwise just stubs in the macOS version of the C++ SDK
I don't think I can confirm any details or timelines yet, but this is definitely something that we are considering and looking into. It will be great if we can indeed make use of the iOS SDK to improve our coverage of the C++ SDK on macOS.

Thanks for your quick reply, @AlmostMatt. Super excited for whatever might be coming. And I really appreciate your confirming that it's on your radar.
Could I ask that you keep us posted on your plans, as much as is allowed?
[Musing: I think this might be the type of product/feature where secrecy doesn't serve Google as well as transparency. It's not like phones where people will buy fewer today if they know what features are coming that they'd wait for. Instead, people are more likely to use Firebase if they know what exciting things are coming! (Nor, presumably do you need to be worried about people copying this feature.) This twitter exchange got me thinking about it originally.]

As all of our development on the C++ SDK is done in this open-source repo now, I wouldn't say it's a matter of secrecy, more just that we can't commit to when we'd be able to start working on expanded macOS desktop support. I definitely want to see it happen, it's more a question of prioritization and resources than anything else.
Of course, being an open-source repo, we are always open to external contributions... :)

Indeed! Fair enough. Expectation management is important for sure.
May well get there--and just tossed up an unrelated mini (but useful) PR for fun--but I think I should get things set up and rolling on mobile for my team first.
(I do contribute fairly heavily to Google open source, but this one's also a commercial product, and I think more of a your-guys'-configuration kinda thing.)


get_root_directory_client() method for  azure.storage.filedatalake.FileSystemClient class

The current method to operate on the root directory is _get_root_directory_client() which is a protected method. It works fine when I try to operate on the ACL of the root directory. However it's not ideal to use a protected method of the class.
Please implement a public method so that we have a safer way to work with the root folder. The get_directory_client method did not work when I tried supplying in the root folder as a parameter.
If it's possible to leverage the get_directory_client method to operate on the root directory, please provide an example. Thanks.
I'm using the class library to apply ACLs to root directory and also provisioning ACLs for specific folders and propagating to the descendants.

Hi @Lackshu, you should be able to just call get_directory_client('/') to get the root directory client. That's all the private method does anyway.
https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/storage/azure-storage-file-datalake/azure/storage/filedatalake/_file_system_client.py#L964


Use YAML for test cases

I think this is more readable (rewritten by GPT-4):
- comment: |
    Block level elements should have a newline
  input: |

H1

Para

pre

  args: ["h1", "pre"]
  expected: |
    H1
    pre
- comment: |
    Various ways whitespace should be stripped
  input: |
    Hello
    This
    Is
    Newlines
  args: ["--minify"]
  expected: |
    Hello
    This
    Is
    Newlines
- input: |
    Hello
    This
    Is
    Newlines
  args: ["-m"]
  expected: |
    Hello
    This

    Is
    Newlines
- input: |
    Hello
    This

    Is
    Newlines
  args: ["--minify"]
  expected: |
    Hello
    This

    Is
    Newlines
- input: |
    Hello  this   has     spaces
  args: ["--minify"]
  expected: |
    Hello this has spaces
- comment: |
    Should remove script and style
  input: |
    Hello
  args: []
  expected: |
    Hello
- comment: |
    Test alt text replacement
  input: |

  args: []
  expected: |
    FooBar
- comment: |
    Even with --minify
 tag content should be unaffected
  input: |

this
      has
        spaces

  args: ["--minify"]
  expected: |
    this
      has
        spaces
- comment: |
    Test --first
  input: |
    Ignore start
First paragraph

Second paragraph
Ignore end
  args: ["p", "--first"]
  expected: |
    First paragraph
- comment: |
    Keep tags
  input: |
    Outside of section

    Keep these:

an h1

h2 with class and id

This p will have its tag ignored

    Outside again
  args: ["section", "-t", "hs", "-m"]
  expected: |
    Keep these:

an h1

h2 with class and id
 This p will have its tag ignored

Something went wrong with this - it's only 30 tests now and it was 54 before.
I'm going to ditch the GPT-4 generated YAML and make this myself.

Wrote this conversion code for the old TEST_PARAMETERS:
import json

examples = [{"input": t[0], "args": t[1], "expected": t[2]} for t in TEST_PARAMETERS]

for example in examples:
    print("- input: |")
    print("    " + "\n    ".join(example["input"].split("\n")))
    print("  args: " + json.dumps(example["args"]))
    print("  expected: |")
    print("    " + "\n    ".join(example["expected"].split("\n")))

New YAML tests are here: https://github.com/simonw/strip-tags/blob/ab56f86a404284b16a7e449b09fa8847359873c6/tests/tests.yaml


Home page

Adding the home page of the blog, ignoring all later updates like featured patterns

Done! Perhaps will revisit in another styling pass, but looks better than I expected it to look by this time


Fix helm push and versioning

Fixes the helm chart name to match the repo we push to and prevents override of RELEASE_VERSION

Would it make sense to change the Cloud repo to fit the helm repo name instead, so we don't make this fork diverge further?

@sclevine Updated the oci registry name to be gateway-helm, so now this just fixes the version tag which was being overridden.


fix: make tid and oid optional to allow User validation in B2C

This fix is related to the discussion around B2C in Pull Request #140 (and issue #136).
It makes the claims tid and oid optional in the Pydantic User Model so that B2C auth won't fail when these claims in the token are missing.

Thank you!
There’s something failing with mypy, I’ll have to investigate, unless you figure it out in the mean time 😊

Some proposed changes in the recent commit. One is adding type hints with Union plus casting to string, the other simply ignoring the mypy error, could not really figure it out why that occurs now.

Just out of curiosity as I found my way here from a linked issue. If tid becomes optional and B2CMultiTenantAuthorizationCodeBearer sets multi_tenant to true, then we'll want to verify our issuer and provide the iss_callable? That being the case, would Line 170 of auth.py still cause issues?
I'm actually in the process of configuring this for B2C and have found that I can't get it to work when it's looking for tid as it's not a claim that exists in the token, although iss does. If tid is hardcoded then is it optional? Sorry for asking here, I can comment in the issue if you'd prefer, it just seemed closer to where you were making a related change

I'm out of office until Monday, I'll make sure to go through all of this then. Sorry for the delays.

Hi! I'm back! Could you rebase main? Want to make sure tests pass with new changes before I merge 😄

did that, still some failures (in test_openapi_scheme.py)

ah, looks like it could be related to the works in #143

Yes I think they should be resolved if we merge #143 first

I've merged that now. 😊 Please rebase

Not sure why the tests are still failing as I rebased, and my branch says

This branch is not behind the upstream Intility/fastapi-azure-auth:main.
No new commits to fetch.

Sure, that works for me too 😊 Thanks @davidhuser


Added colors to icons

Fixed issue #429
Description

Added the hover feature for youtube and fixed the bug of wrong color.
Added the correct color code of instagram and youtube.

Screenshots

Checklist

[x] My code adheres to the established style guidelines of the project.
[ ] I have included comments in areas that may be difficult to understand.
[x] My changes have not introduced any new warnings.
[x] I have conducted a self-review of my code.

Resolve conflict

Resolve conflict

Conflicts resolved

Still there is conflcit but now button are looking nice no change need kindly work on other issues

Still there is conflcit but now button are looking nice no change need kindly work on other issues

sir but you didnt merge the commit?


#4821 Sync a Sharedfolder for local VM development

addresses #4821

also addresses #4822 by reducing the depth of the github repo to be cloned on build time and so minizimizing the risk of the cloning failing.


tsc command won't work

I recently installed typescript globally and I used tsc to check the version of typescript i'm using. Whenever I use tsc, it always shows an error message and I don't know what to do.Please fix this bug as im waiting to make a new app with typescript

This sounds more like a misconfiguration problem than a TypeScript bug. If you could post the error message, a community member may be able to help out, but tsc is not broken in general and there's nothing we can do on our side to diagnose the problem without more concrete information. Thanks!


Environment Configuration Management

Description
Implement commands to facilitate configuration management across different environments, such as development, staging, and production. This feature should allow quick switching between different configuration files (application.properties or application.yml) and ensure that the active environment loads correctly.

This feature is connected with this PR: #11

Done!


Make attribute type required in entity api spec

It would be very helpful if we could have attribute types as required, that would allow us to discriminate an attribute by its type, and avoid a lot of of the assertions around attributes in entity-ui.
Do you foresee any undesired consequences at the API level that could arise from this change?

Hi @josecarneiro! Please make sure to apply this change upstream in Entity API source openapi.yml
The openapi json files distributed via the SDK are not meant to be directly edited, but rather updated via the npm openapi script.
Otherwise this seems like a sensible change 👍

Hi @anttiviljami, my bad, I should've started this discussion upstream. I'll propose these changes for the entity API and close this PR for the time being. Thank you!


Upgrade to daml 2.3.2

This includes

Daml migration to ~2.3.1~ 2.3.2
Moving from Party based setup to user based setup (given that the new sandbox is canton-based, and party literals can not be easily used)
Updating the UI to be able to deal with a user-based setup
Updating startup scripts

Additionally, there is a regression in daml script in 2.3, not allowing you to use a participant.config but forcing you to use the --ledger-host command argument.

Although all UI tests are passing, there are some issues in the test logs. This will be cleaned up in the work focused on upgrading all UI dependencies to the newest versions.


Throw helpful error message on unsupported major

Today if the diagnostics tool is run against a major version that it does not support it throws a null pointer exception and does not really reveal what the problem is. This commit traps this situation and provides a helpful error message to the user.
Additionally, the logic for parsing the major version is broken as it will fail when the major version has two digits. This commit fixes this situation too.

Thanks again @nemonster!

Should actually thank you for fixing something I should have addressed prior.


Newly composed messages always saving as draft

<IP_ADDRESS>, Chrome 53, Windows 10 Pro
Everytime I try to compose an email, on typing the content of the email after a while, rainloop tries to autosave the email, but I end up getting a red save button saying Can't save message.  The emails go through fine, but the drafts get populated with duplicates of the email. If I click the save button, I get the same response with a duplicated email in the drafts.
Also, when I receive emails, after checking the mail and some seconds, the emails show up as being unread again, and it goes on and on.
Screnshots:

An option to automatically save drafts (or not) is already present in the latest version.
If it solves your issue, please close it.


Conform to readability-avoid-const-params-in-decls

https://clang.llvm.org/extra/clang-tidy/checks/readability-avoid-const-params-in-decls.html

Jenkins, test this please.

Jenkins CI test (for commit 069ba8069b32346cfe827be5d4deb48d166d5a07, target branch master) failed with status FAILURE.

Jenkins, test this please.

Jenkins CI test (for commit 069ba8069b32346cfe827be5d4deb48d166d5a07, target branch master) succeeded!

LGTM.


Ericscript integration

This pull request aims to integrate EricScript into bcbio (issue #1649 )
To run gene fusion detection with EricScript in rnaseq pipeline, you need to install the tool, download it's reference data, and add the fusion_caller: ericscript to the algorithm section of the config.
Changes:

Added a wrapper for EricScript, which runs the tool itself. EricScript takes 2 fastq files as an input, so there's not much logic in the wrapper. In case of an algorithm with disambiguation,  the .bam file with disambiguated reads is converted into 2 fastq files. Otherwise, the 2 fastq files with trimmed reads from the sample config object are used.
Slightly changed the logic of rnaseq pipeline. Previously, fusion_mode parameter was determining whether the fusion needs to be run, and the fusion calling was done with  an aligner of choice.
I've added a second option, fusion_caller (which can be left out), which can be used to specify a standalone caller like EricScript. If a fusion_caller is present, gene fusion detection won't be run with an aligner. My wild guess is that this is the most user-friendly behavior; however, this guess might be totally wrong, so we can change it back if you think it was a bad idea.
Possibility to install EricScript with bcbio upgrade via --toolplus argument. Currently, EricScript requires samtools=0.1.19, which conflicts with bcbio's latest samtools verison. That's why EricScript is installed into its own conda environment. The EricScript's author plans to update the required samtools version, so whenever it's done, EricScript can be installed together with the rest of the tools or conda packages (EricScirpt and its dependencies are conda installable).
Possibility to install the latest version of EricScript's database. The reference data is currently shared via Google Drive, so I've added integration with Google Drive API to bcbio's objectstore module.
The tricky part is that Google API requires API keys, even for publicly available files. I've made a set of keys, and put it in a .json file in the repo. You might want to get a set of keys, and maybe find a better way to store them.
As a consequence of integration with Google API, there's a new dependency on google-api-client. Currently those are listed in requirements_dev.txt, and also installed in .travis.yml in a hackish way. As soon as they're added to list of bcbio dependencies, we can of course remove them from those files.
Documentation updated (the installation section) with the instructions on how to install EricScript and its data.
A small change: renamed the open function from the objectstore module, because it was conflicting with python's built in open.
I didn't add any "full pipeline" tests; instead, I wrote 2 integration tests which run only the EricScript wrapper, and verify that the output is as expected. However, I've tested the full pipeline locally, and it works as intended. Sadly, I can't test all the possible parallelization scenarios, so a sanity check of the changes to the bcbio/pipeline/main.py is needed.

Any feedback is most welcome!
I am not sure whether I you prefer to keep commits small, squash them into a few large commits, or squash them into one ("one commit - one feature"). So currently there are just a lot of small commits. Please let me know if I should squash them somehow.

This is awesome. A couple things, I had to add init.py to the tests/unit/rnaseq and tests/integration/rnaseq to get py.test to behave ok. I'm having trouble installing ericscript via bioconda, how did you get it installed?
Fetching package metadata .........
Solving package specifications: .

PackageNotFoundError: Package not found: '' Dependencies missing in current linux-64 channels:
  - ericscript 0.5.5* -> r 3.3.1* -> r-base 3.3.1 -> bzip2
  - ericscript 0.5.5* -> r 3.3.1* -> r-base 3.3.1 -> icu 54.*
  - ericscript 0.5.5* -> r 3.3.1* -> r-base 3.3.1 -> libgcc
  - ericscript 0.5.5* -> r 3.3.1* -> r-base 3.3.1 -> jpeg 8d*

Close matches found; did you mean one of these?

    bzip2: pbzip2, zip, pbgzip
    libgcc: libgd, libmagic

You can search for packages on anaconda.org with

    anaconda search -t conda libgcc

(and similarly for the other packages)

Tetiana;
Wow, this is incredible. Thank you for all the work integrating this. We're hoping to have a new release in the next couple of days and would love to pull this in afterwards, once Rory has had a chance to test and evaluate.
Rory, for the install you also need to include conda-forge and it looks like it'll pick up all the dependencies:
bcbio_conda install -c r -c conda-forge -c bioconda ericscript

Some thoughts:

Is it possible to move the data installation to a CloudBioLinux ggd-recipe (https://github.com/chapmanb/cloudbiolinux/tree/master/ggd-recipes). The Google Drive logic is pretty complex, I wasn't sure if it's possible to replicate from the commandline. In general we've been trying to push installs as ggd-recipes so they could also be generally useful outside of bcbio, and more easily accessible to others looking at the logic.
What is the source of the samtools 0.1.9 dependency? Ericscript is dependent on the command line, or something else? It would be awesome to get this as a standard install if we could resolve this and avoid needing a separate conda environment.

Thank you again for all the great work.

Hello @chapmanb and @roryk, thank you for your kind words and your feedback.  I am sorry for the late reply, I was sick and out of the office last week.
@chapmanb

Is it possible to move the data installation to a CloudBioLinux ggd-recipe

Theoretically, ericscript should be able to download its own databases, but the download is buggy.  I've mailed the author of the EricScript about a month ago, and he said that he plans to fix the issue. There's also a post on their google group.
Downloading a file with the python API client seems unnecessarily complex for such a simple task.  But the problem with GoogleDrive is that one needs an API key to interact with it programmatically. It's not possible to get a file from the Drive "normally" (via wget or a similar command line utility). While it is possible in principle to download a file via plain HTTP requests, it's not clear to me how to run authentication. Additionally, the docs advise against this approach:

the mechanics of server-to-server authentication interactions require applications to create and cryptographically sign JSON Web Tokens (JWTs), and it's easy to make serious errors ... For this reason, we strongly encourage you to use libraries, such as the Google APIs client libraries, that abstract the cryptography away from your application code.

As the GoogleDrive is not among the most popular ways to store reference data, maybe there's no reason to keep this code in bcbcio as it won't be used much anyway. I can create a standalone python script which downloads a file from GoogleDrive and then can create a cloudbiolinux recipe using this script.
Alternatively, we could ask users to download the file manually via browser until the issue is fixed.

What is the source of the samtools 0.1.19 dependency?

Samtools underwent some major changes after version 0.1.19, I guess EricScript hasn't adjusted to  newer versions yet. It simply fails with an error:
Error: SAMtools >= 1.0 detected! EricScript is not yet compatible with it. Please use samtools 0.1.19 to run EricScript.
On the bright side, a separate environment guarantees that the main bcbio installation won't be accidentally messed up by different versions of dependent packages. I wonder if you've encountered  dependency version conflicts in the past, and if so, how did you solve the problem?
@roryk thanks a lot, I've removed the breakpoint, added the conda-forge channel, and added __intit__.py files.

Tetiana;
Hope you're feeling better, and thank you again for all this work and explaining the approach. It sounds like some of these sticking points will be resolved over time but it makes sense to get this in now. If Rory is good with all the integration work I'm happy to merge this. Apologies but I created a couple of merge conflicts pulling in Michael's py3 work as well so after we squash those happy to get this all in and start testing it.

I am psyched to have this in-- Brad, do the two remaining merge conflicts look like master handles them correctly?

Rory -- it would be awesome if you want to fix the conflicts and get this merged. Happy to have this in place so you and others can start working with it.

Yup, I'm on it.

What's the status of this PR? I will be able to help with the merging if needed.

Thanks Vang,
I had a heck of a time getting ericscript to be able to be installed by bioconda but it looks like it is installable now. This would be a nice fusion calling option to have integrated for sure.

Nice work Rory. Wonder how the conflict of samtools version was solved. bcbio_nextgen currently uses goleft , which require samtools >=1.3 (I was hit by this conflict). One quick way I can think of is to alias samtools to fullpath of samtools 0.1.19 for ericscript. Or depending on how tightly ericscript integrates with samtools, we may be able to upgrade to samtools 1.3 for it.
Back to merge conflict, shall I try resolve conflict or you are in the process now?
Cheers
Vang

Just did a test installation of ericscript:
/bcbio_nexgen/anaconda/bin/conda install ericscript
Fetching package metadata .................
Solving package specifications: .

Package plan for installation in environment /bcbio_nextgen/anaconda:

The following NEW packages will be INSTALLED:

    blat:               35-1                       bioconda
    bleach:             1.4.2-py27_0               bioconda
    configparser:       3.5.0-py27h5117587_0
    entrypoints:        0.2.3-py27h502b47d_2
    ericscript:         0.5.5-pl5.22.0r3.4.1_1     bioconda
    html5lib:           0.999999999-py27hdf15f34_0
    ipywidgets:         7.0.0-py27h4fda95d_0
    mistune:            0.7.4-py27h6da7e90_0
    nbconvert:          5.3.1-py27he041f76_0
    notebook:           5.0.0-py27h3661c2b_2
    pandocfilters:      1.4.2-py27h428e1e5_1
    pytest-marks:       0.4-py27_0                 bioconda
    r-ada:              2.0_5-r3.4.1_0             conda-forge
    sh:                 1.11-py27_0
    terminado:          0.6-py27h4be8df9_0
    testpath:           0.3.1-py27hc38d2c4_0
    webencodings:       0.5.1-py27hff10b21_1
    widgetsnbextension: 3.0.2-py27hcb77dec_1

The following packages will be UPDATED:

    conda:              4.3.29-py27_0              conda-forge --> 4.3.30-py27h6ae6dc7_0
    conda-env:          2.6.0-0                    conda-forge --> 2.6.0-h36134e3_1

The following packages will be DOWNGRADED:

    bcbio-nextgen:      1.0.5-py27_0               bioconda    --> 1.0.3a-py27_6         bioconda
    cnvkit:             0.8.6a0-py27_2             bioconda    --> 0.8.1-py27_0          bioconda
    pysam:              <IP_ADDRESS>-py27_1            bioconda    --> 0.9.0-py27_1          bioconda
    samtools:           1.6-0                      bioconda    --> 0.1.19-2              bioconda

Proceed ([y]/n)? n

Exiting

This means that samtools version conflicts still occur, and it is not preferable in my opinion.

Vang and Rory;
Thanks so much for helping to get this in. The bcbio installation now has separate environments which we use for python3-only tools so I will work on creating an isolated install for eriscript that avoid the samtools conflict. With that in place we'd then need to remove the custom install code in this PR and clean up the conflicts. If either of you can work on those issues I'll tackle the ericscript install so we have something to test with. Thanks again for helping with this.

@chapmanb @roryk @tetianakh I got some spare time on friday afternoon, so I played with git merge a bit and made this branch: https://github.com/biocyberman/bcbio-nextgen/tree/pr1724merged. I haven't run any test, so use with precaution.
My strategy is: rebase this PR on to 28c985f8, and then merge:

prefer @tetianakh changes where you made improvement.
parallel addition of new code are both kept
prefer official version in .travis.yml

Vang;
Thanks so much for working on this. I pushed the ericscript install to CloudBioLinux so doing bcbio_nextgen.py upgrade --tools will get it installed in a bcbio installation in an isolated conda environment. Looking through the PR the major things I'd like to do are:

Back out custom conda install logic, in favor of fixes.
Avoid changing travis and Docker files, we can address any dependency issues afterwards.
Remove the changes to prun, since the logic there has changed slightly since the original PR.
Remove the custom download and add this as a ggd-recipe. I can take on the data install.

Do you feel comfortable with git skills for updating and rebasing this? I've been nervous to tackle because I'm definitely going to mess that up but would be happy to get a non-conflicting branch in and tweak afterwards as well.
Thanks again for helping push this forward.

Vang and Rory;
I pushed install targets for ericscript to CloudBioLinux as well so now both the tool and data installation are located there. We can remove the custom install code and only need a ericscript data target. This should make the PR a bit simpler by removing the custom Google integration so we can avoid all the extra dependency updates and focus on only the fusion, ericscript, disambiguation and testing changes. Thanks again for helping move this forward with us.

Brad
Cool with the additional samtools0 conda env. I will take a closer look at the merge conflicts with the bulletpoints you mentioned.  I am comfortable with solving merge conflicts. Just wonder what data I can use to make a test run after merging.

@chapmanb: This branch is already rebased and merged without conflict https://github.com/biocyberman/bcbio-nextgen/tree/pr1724merged. However, to revert/remove non-conflicting code it will take more time by going through all files of the PR. Would it be OK if I do merge without rebase, and then divide the merge code into several commits?

Vang;
Thanks again for looking at this. I'm not too worried about rebase/merge on the branch so whatever works best practically is good for me. The history on this is already pretty messy so some more commits shouldn't make a big impact.
Practically we're aiming to do a 1.0.6 release soon and then will work on merging this after that is out, to avoid having a big set of code changes just prior to the release. Thanks again for all the help finalizing this.

Thank you so much for this contribution. We've got it all cleaned up and pulled in PR #2146. I'm excited to have this finally sorted out and integrated and looking forward to testing and using it in bcbio. Our next aim will be to test and clean up before the next release. Thank you again.