Import helpdb.jl and intergrate with REPL help.

Load the contents of helpdb.jl and create __METADATA__ objects in required modules. Also intercept REPL help system (namely Base.Help.@help macro) to call Lexicon.query.

Already implemented. Not importing helpdb.jl, but rather commandeering the REPL's ? mode.

Does this mean you ought to be able to apply Lexicon to Base?
e.g.
julia> save("base.html", Base)
ERROR: ArgumentError: Base is not documented.
 in metadata at /Users/andy/.julia/v0.4/Docile/src/interface.jl:57

I get the feeling I'm missing something obvious here!

Nope, you're not missing anything. My closing comment was just a bit vague.
What's actually implemented is this and this. Lexicon intercepts the ? mode in the REPL, displays the base help docs related to a query and then displays any results from documented packages.
A while ago I did try parsing the base docs, but lack of an rst package to do the parsing of docstrings and signatures that didn't always match up to actual julia syntax meant it was hit or miss most of the time trying to link objects to docstrings.

Ah, ok thanks! Would be interesting to see if we can do something going forward (if Julia's migrating to md anyways). I wonder how lossy using pandoc to do the conversion would be... As a proof of concept, even if there's some/many conversion errors, it would be very cool! :)

Not sure how pandoc would do with this. Would definitely be worth investigating.

You could use pypandoc and pycall, something like:
pypandoc.convert(rst_string, 'rst', 'md', extra_args=('-tmarkdown_github',))

should have a good go at converting from rst to md (with the gh table syntax), I'm not sure what else will be missing...

That's really cool! Does pypandoc include a pandoc binary with it or does that need to be downloaded separately?

I'm not sure tbh, I installed it seperately: pandoc - make sure your pandoc version is 0.13+ so it has github flavour.
IIRC if pandoc is in your PATH it all "just works".

Another thing to support is cross references. cc @jiahao
Should we make this a sep issue(s), I think there's kinda three here:

convert rst docs to Julia md without loss (tables + cross-references + testable code (?) + ...)*, Note: we can apply plain to get it to something md/doc can parse.

get help from REPL (with current system)... I don't know if this is just me but if I import Lexicon help stops working in the REPL. ERROR: UndefVarError: @help not defined (e.g. after ?fft.

get Lexicon working with Base (to generate docs).

Am I right in thinking once we have 1. and 2. we get 3. free? and 1. is desired in the long-term for Base.
*My thinking was that if we solve that we could write a script to paste this as @doc where the function is defined... though I don't see how that should quite work (due to ambiguity in where to put it)... although you could just dump all the docstrings in a single file as @doc coverted_thing_found f (hmmm that could actually work).
At the moment, I don't understand which (if any) of these is generated from the others: help.db basedocs.jl math.rst

I think we should be translating these as meta though @one-more-minute feels strongly the other way!

The primary source files are in doc/stdlib/*.rst. You can see for yourself what ReST/Sphinx features are used.
Running make -C helpdb updates doc/helpdb.jl.
basedocs.jl is new; I don't know how it is generated. @one-more-minute.

My experience with pandoc is that markdown -> html is good, latex -> html is decent (if you have no equations), and other conversions I've tried (like markdown -> markdown to use pandoc's citation generator) produced unsatisfactory results.
I once looked into trying to add in missing features upstream, but then I realized I had to learn Haskell first.

basedocs.jl is the moral equivalent of helpdb.jl, but at the moment it's more a proof of concept than anything else – completely written out by hand.
Assuming we're agreed that Markdown docs in base should be the canonical format, the steps are:

Generate helpdb.jl/basedocs.jl/whatever from the current RST docs, as a bunch of @doc invocations.

I don't see a way to make this lossless without basically writing an RST parser, so there's going to have to be some human intervention and/or horrible regexes involved. Luckily this only happens once. Also, it would be nice to move a lot of the docs inline, but since that's not possible in general something like helpdb.jl will always be necessary.

Generate manual pages

Given that we're using RST at the moment, it might be right to just generate RST pages from Julia. We can do that losslessly, with references etc. We can also generate HTML directly, output Markdown for MkDocs, whatever – the world's our oyster, basically.
And that's it, really.

Also, I should mention that I'm not at all against metadata, I just think it should be done via the Markdown itself. For example:
@doc meta(doc"Foo function", Dict(:author => "Mickey")) ->
function foo() ...
# or, pending syntax:
"""
Foo function
* Author: Mickey
"""
function foo() ...

I think it's pretty clear what's more convenient for the coder writing this, the maintainer reading it, and (most importantly) the helpless user looking at it in the REPL. The main concern here is being able to use the information programmatically, but that turns out to be easy thanks to the fact that we can easily parse markdown and pull metadata out. It's not the approach you'd take if you were looking for water-tightness against ambiguity, but the priority here has to be the human consumer (and, fortunately, humans are pretty good with syntactic ambiguity).

Happy to have a go here, is there an easy way to extract a Dict of methods to rsts?
I think we should put together the interesting cases in the rsts (e.g. cross-links, tables, etc), and throw them at pandoc and see what we lose:

file bug for X to pandoc and see if it's an easy fix
Count how many examples of X in the rsts there are + go through by hand/regex fix each X in the rst i.e. regex to find/fix.

Hmmmm interesting idea about munging out the meta by extending markdown. What about the following at the end of a docstring (although we don't support vbar yet):
Foo function
---
* author: Mickey
* return_type: Dict

translates/lowers to something with meta.
@doc meta(doc"Foo function", :author => "Mickey", :return_type => "Dict") ->
function foo() ...

@one-more-minute, I've also been leaning towards embedding the metadata in the docstring itself recently myself. meta was a nice idea, but once I started writing out some actual docstrings with it it gets annoying pretty quickly. Was definitely worth experimenting with though.
@hayd, the syntax you've got there is basically YAML I think. I'd been pondering importing the YAML.jl package for that. It seems a little more reasonable than having to write out all the additional meta syntax explicitly.
The ERROR: UndefVarError: @help not defined is from differences in what ? calls in 0.3 and 0.4. 0.4 uses @doc now. So I'll push a fix for that later today.

@MichaelHatherly the problem with YAML is it's super sensitive (I'm not sure if that's the case with YAML.jl, but IIRC it's the spec that's sensitive) which IMO goes against markdown - which is a very forgiving language.
I guess the main driver for this is "what is allowed in the meta" ? If it's a single line, like the above, then it's easy, if it's multiline parsing (e.g. sections) then things gets complicated... (If they're not complicated then can we just use a special MD List.)

That's true. Might be worth not tying ourselves to a specific syntax yet, and rather see what people begin to use naturally for denoting "metadata" in their docstrings.

+:100:

I have a small script which does the extraction, rst -> md conversion, and creates a julia file with lots of @docs for each of the rst stdlib files (not got it working on all of them yet, but don't think it'll be too bad).
One barrier I've got to which would be great to solve is how to @doc against the signature (I commented on this somewhere else, not sure where). At the moment I have:
@doc """Constuct a Date type by `Period` type parts. Arguments may be in any order. Date parts not provided will default to the value of `Dates.default(period)`.
""" Date(period::Period...) -> Date

but I want something like the following to parse:
@doc """Constuct a Date type by `Period` type parts. Arguments may be in any order. Date parts not provided will default to the value of `Dates.default(period)`.
---
* return_type: Date
""" Date(period::Period...)

I'm -:100: as (to flog this horse some more) IMO if we don't agree on something which will parse, everyone will be doing something random and it will be impossible (or, at least, a complete mess) to parse later....especially if we going to do something like the above in Base (and stuff like https://github.com/JuliaLang/julia/pull/9838).

For Base docs, let's just put the signature as a first line:
@doc """
    Date(period::Period...) -> Date
Constuct a Date type by `Period` type parts. Arguments may be in any order.
Date parts not provided will default to the value of `Dates.default(period)`.
""" Date

That seems a lot cleaner to me than having a bullet at the end, and it'll look nicer for the end user (which has to be the priority at the moment). It's also very easy to pull the signature or return type out if necessary.
The main issue I have with setting a standard is that it means predicting everyone's use cases, and there's no way I'd feel confident doing that until use is a bit more widespread. If it's too cumbersome, you discourage people from writing docs, and if it's too lightweight, you restrict those who need more. I'd happily throw parseability out the window before taking either of those options.
Moreover, remember that right now we have a very smart and dedicated community of beta testers using this thing. I have no doubt that some interesting ideas will emerge that we'd never have thought of, and the last thing I'd want to do is suppress that.

In fact, I hope @MichaelHatherly won't mind me quoting him to drive my point home:

meta was a nice idea, but once I started writing out some actual docstrings with it it gets annoying pretty quickly.

Not long ago a lot of people were arguing strongly for meta – if we'd standardised earlier we could easily have included it. It's absolutely a bad idea to standardise any similarly nice ideas that haven't been widely tested in practice (and at this point, there aren't any that have).

Writing the "human-readable" signature as the first line is a good idea. When a docstring is quite long having the signature at the top can help with context while reading. Short doctrings don't really need this though I've found.
In some cases I've come across Lexicon's automatic signature can be unhelpfully long. This doesn't happen in every case though. Having to type out a signature manually and then keep it in sync is something that we could probably avoid since we do store all the required information. It's just a matter of displaying a useful amount of information.
How about this for starters:
If the first element in a docstring's .content is a Markdown.Code then use that as the signature, otherwise automatically generate and display one based on the documented object.
We could probably add the return type automatically as well in most cases using Base.return_types unless the result is overly complex or meaningless.
It would then be up to the documenter to decide whether they would like the system to add a signature or create their own.

IMO there aren't many in practice because there's no easy options yet, at least I don't see any. If there was something in the Docile docs explaining either:

how to parse additional syntax into meta (roll your own @doc)
some example meta syntaxes (use an existing one)

I agree it would be good if these could be tested in the wild before migrating to Base. But I strongly disagree that a lack of usage at this stage, without the above, indicates a lack of appetite.

It sucks not attaching to the signature (the return_types is not so important, and prepending it is no big deal, though I think if we we should ensure we can extract it later), you really want to attach it to a specific signature. Perhaps I'm confusing things by talking about a type constructor (Date) rather than a method?
To give a silly example, when you do:
?> *("a", "b")

you want the help for + with these types to come up (atm it doesn't) and this is only possible if the help messages are attached via signature. e.g. with some syntax like:
@doc """"
`Base.*(s, t)`
Concatenate strings. The "*" operator is an alias to this
function.

   julia> "Hello " * "world"
   "Hello world"
""" *(s::AbstractString, t::AbstractString)

Note: This is what happens if you @doc at definition time, e.g. with your own methods.

Actually, that's already implemented ;) Documentation is already attached to specific methods and it's easy in principle to grab the docstring for a specific method. It's not implemented for the repl help in Base yet but it's easy to do. That's why the main priority for the inline signature is to be human readable – the computable data already exists.

If the first element in a docstring's .content is a Markdown.Code then use that as the signature, otherwise automatically generate and display one based on the documented object.

This is roughly along the lines I've been thinking. It'd be easy to also have e.g.
    :sig
blah blah blah

as notation to let the doc system generate a signature for you.

@one-more-minute what's the syntax to attach it to a specific signature (after definition time)? When trying the above I get:
ERROR: UndefVarError: s not defined

(I know it works if you @doc at definition time, it's awesome!)
Hmmm interesting idea to label sig (if you provide sig use that), perhaps if you instead provide return_type (the doc system generates, actual_sig + " -> " + return_type).

what's the syntax to attach it to a specific signature (after definition time)?

I've not come across a need to attach docs to a Method after definition, but I guess you could extract the Method you need using:
julia> m = first(methods(+, (String, String)))
+(a::AbstractString,b::AbstractString) at none:1

julia> @doc "docs for +" m
+(a::AbstractString,b::AbstractString) at none:1

julia> @doc m
  docs for +

Not that elegant though.
With the plain docstrings syntax in Docile the following also works:
"docs for +"
(+, String, String)

@one-more-minute: This is roughly along the lines I've been thinking. It'd be easy to also have e.g.

@hayd: if you instead provide return_type (the doc system generates, actual_sig + " -> " + return_type).

Those seems reasonable. Perhaps [returns] rather than [return_type] to shorten it slightly?

I've not come across a need to attach docs to a Method after definition

The need (for me) is generating from the stdlib rsts the @doc statements. Currently I can get something like the above (which seems so close to something that could work!)...
@MichaelHatherly I had tried with the methods, but perhaps I am getting a little confused that:
?> a  #works

?> *("a", "b") # doesn't

julia> @doc *("a", "b")  # doesn't

but I think this is just something to do with Base lookups (i.e. it being a special case)?

That Docile syntax looks fantastic.

As a user I want to be able to do something like:
help?> *(x::Bool,y::Bool)
ERROR: UndefVarError: x not defined

help?> *(a, b, c, xs...)
ERROR: UndefVarError: b not defined

If this could work on the user side: use the above to lookup a specific method and @doc that. Then we could do the same on the documenting side (which I agree is an unusual case, usually you want to doc at definition time, but it'll make rsts->doc statements much easier/useful).
i.e. a macro to take the above expressions to the correct specific method ?

@MichaelHatherly I was trying something like the following (in docs.jl) to get the method if you pass it an expression like :(f("s"::String,t::Int,u,:v,7,::Any)):
function maybe_get_method(def)
    if :head in names(def) && def.head == :call
        sig = Any[]
        for arg in def.args[2:end]
            if isa(arg, Symbol)
                push!(sig, Any)
            elseif isa(arg, QuoteNode)
                push!(sig, typeof(arg.value))
            elseif isa(arg, Expr)
                assert(arg.head == :(::))
                push!(sig, eval(arg.args[end]))  # this needs to escape too
            else
                push!(sig, typeof(arg))
            end
        end
        sig = tuple(sig...) # getting sig works a treat (provided the types are in scope)

        f = quote @init $(esc(def.args[1])) end   #this is wrong
        possible_methods = methods(f, sig)
        length(possible_methods) == 0 && throw(ArgumentError("No method found with the given signature"))
        return possible_methods[1]  # potentially you want to apply doc to each method in this list??
    end
    def
end

This seems to get the signature ((AbstractString,Int64,Any,Symbol,Int64,Any)) correctly, but I'm not escaping correctly - tbh I have no idea what I'm doing with quote and @init... Is it possible to do this? (I suspect I'm missing something obvious!)
The issue is that f, and potentially the datatypes in the signature, is not defined in the local scope.

That way the syntax alluded to above ought to "just work" :)

Sorry for the delayed response @hayd.
Where in docs.jl are you trying to call maybe_get_method from? The @init macro in
f = quote @init $(esc(def.args[1])) end   #this is wrong

needs to be spliced back into the location where @doc is called from so that META will refer to the correct META. I don't think it will be necessary to use it in this particular case.
typeof(f) === Expr and methods doesn't have a matching signature for that type. To get the actual Function object to pass to methods you could probably use something like:
f = getfield(current_module(), def.args[1])
possible_methods = methods(f, sig)

You might also be able to use getfield(current_module(), ...) to replace the use of eval.

The need (for me) is generating from the stdlib rsts the @doc statements.

Yes, that makes sense. Totally forgot what the title of this issue was.

The need (for me) is generating from the stdlib rsts the @doc statements.

For now it would be fine to just associate the whole docstring with the function itself, I think. At worst we're not losing anything over what's currently available. I'll also add a syntax for this to Base so that it can be extended in future.

@one-more-minute the annoying this is you have several docstrings (for the same method) then you have to just concat the strings (lose some info and gets a bit more complicated), if we can do the method signature thing this would be much nicer :)

From a quick skim of the manual there doesn't seem to be too many Method-specific docs at the moment luckily, so @one-more-minute's suggestion should work for most of this. For the docs that are associated with particular methods it might be worth starting to write the docs above the actual methods. A syntax for what you'd like to accomplish @hayd would be nice to have though.

@MichaelHatherly I meant to say, your above worked a treat to get the method!
I need some hand holding, neither of the following quite work (in docm definition), it feels close...
# setting
isa(m, Method) && return doc(getfield(current_module(), m.func.code.name),
                                                m, meta, m.func.code)

# retrieving
isa(m, Method) && return doc(getfield(current_module(), m.func.code.name), m)

unless @one-more-minute's already putting something together? But thought I sat what I'd tried!

dates was one of the examples I started with which has a few method specific docs.

@hayd could you post a diff or link to the branch?

@MichaelHatherly this is very wip/messy (I left some printing in here too sorry) https://github.com/hayd/julia/commit/246314b2e5518db6c1960c7ba1b693649b9c51d3
create docs for each file e.g. make_doc("collections")

@hayd, I've written some in line notes in the branch you've linked. (Not sure if you'd get notified about them there.)


[build.psm1] - mc.exe input file needs quotes

mc.exe would fail to run if the path/filename had a space in it.  Added quotes to avoid this.

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

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

TTYL, MSBOT;

Good catch! Can you, please rebase to avoid unnecessary merge commit?

@vors why not just squash during merging ? :)

This comes from my inability to have git do what I want it to the first sixteen times I try to do something :) Can it be squashed on merge?

Oh, right :) GitHub added it. Never tried it before.

Hm, looks like it will require some additional work to enable. At the moment there is no such option. cc @andschwa can you take a look? I'm on mobile at the moment


[Bug Report] Steps border color is not a setting color

Element UI version
2.2.0
OS/Browsers version
mac / 63.0.3239.132
Vue version
2.5.13
Reproduction Link
https://jsfiddle.net/mmx38qxw/890/
Steps to reproduce
Check steps border color (#c0c4cc).
What is Expected?
steps border color is  #e4e7ed( $--disabled-border-base = $--border-color-light in element-variables.scss)
What is actually happening?
steps border color is #c0c4cc.
I wonder why steps border color is not #e4e7ed but #c0c4cc.
I did not set border-color-light to #c0c4cc
.
p.s = my develop environment is NUXT.

Because the border color is not $--disabled-border-base: https://github.com/ElemeFE/element/blob/dev/packages/theme-chalk/src/step.scss#L36

Thank you for quick response.
In "element-variables.scss" file > Steps section > $--steps-border-color: $--disabled-border-base !default;
I thought $--steps-border-color is steps border color.
If it is not, $--steps-border-color is what for?


invalid format on service

hello im trying to send a service to log the timne for a week but i keep getting invalid format without much context
{
   "type":"call_service",
   "domain": "harvest_time_tracker",
   "service":"add_time_with_hours",
   "service_data":{
      "project_id":123123,
      "task_id":123123,
      "date":"2023-10-29",
      "hours":8
   },
   "target":{
      "entity_id":"sensor.harvest_time_tracker_123123_hours_week"
   }
}

Hi. How are you trying to call the service? I assume not via an automation or similar as it's not yaml? As per the docs, what you have entered should be correct, although I'm not sure about the domain field.

You should get an error in your home assistant logs which at the very bottom have a response which should indicate the possible error

I was using the websocket through a js script. Looks like a user error though I. My part. Works great thanks!


[Feature]: Resizable component (Splitpane)

Describe the feature

Create a resizable component using the SplitPane library

Part of #220
Additional information

[X] I intend to submit a PR for this feature.
[ ] I have already implemented and/or tested this feature.

a years ago 👽😪
Maybe we could use @ark-ui/vue Splitter  If it's headless and tree-shakable?
I saw some projects that were based on the main shadcn-ui uses Material UI Base UI for some component that not yet existed in shadcn-ui

Splitpanes has more features than any other projects tho.
But the problem is it's not currently maintained.

Ark's Splitter uses @zag-js/splitter under the hood. It's tree shakable and can be installed seperately.
I'll play with both this and splitpanes to see which one fits best in a project and which one has more features.

@sadeghbarati I was able to get the functionality ready with splitpanes but with ark-ui/vue not so much luck.
You can check it out here https://github.com/wasimTQ/shadcn-vue/tree/feature/resizable/apps/www/src/lib/registry/default/ui/resizable.
In the branch feature/resizable

@sadeghbarati If possible can you play around with ark-ui splitter component. And tell me your thoughts. As far as I worked with it, I couldn't get the exact implementations as the docs

Go with SplitPane then
I'll check your branch, Thanks

Problem is Splitpane don't have typescript support. Other than that, it's pretty good for our usecase

Let's fork it and build it with TypeScript support, are you in?

I'm in

Shall we merge it as it is for now?

@sadeghbarati Let's discuss whether we should merge it with the current implementation that is without Typescript support for the package.
We already added custom types for props. So I guess that should be enough already.
The @types/splitpanes package is not compatible with version 3.5.*. But it's not much of an issue now.
I'll fork the repo and add typescript support and some additional functionality like accessibility that's not built in.
How it sounds?

@wasimTQ
There is no rush just here to say if you fork the project You can add me
I can take Bundling Task with unbuild or rollup or bunchee or tsup or any other good bundlers

@sadeghbarati I was busy with my job. So I couldn't focus on it more. I did clone the project and saw how I can improve it.
The code is currently written using options API. And I want to change it to composition api and cleanup some code for better readability. And change the documentation to vite.
It'll take some time. I'll add you to the repo once I forked it.


ValueError: Invalid result: 1.01 (0xCA) is > 1

11:48:21.862 I --- 13:103760 --:------ 13:103760 3EF0 003 0000FF < Support the development of ramses_rf by reporting this packet (byte 5: )

11:48:39.094 I --- 13:107116 --:------ 13:107116 3EF0 003 00C8FF < Support the development of ramses_rf by reporting this packet (byte 5: )

15:17:41.881 I --- 04:065911 --:------ 01:095571 3150 002 03CA < Coding error: ValueError(Invalid result: 1.01 (0xCA) is > 1)

Traceback (most recent call last):
File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/message.py", line 331, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(

File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/parsers.py", line 141, in wrapper
result = fnc(payload, msg, **kwargs)

File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/parsers.py", line 2057, in parser_3150
return valve_demand(payload[2:]) # TODO: check UFC/FC is == CTL/FC

File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/helpers.py", line 27, in wrapper
return fnc(*args, **kwargs)

File "/home/supervisor/Scrivania/ramses_rf-master v0.21.6 01_11 mod/ramses_rf/protocol/helpers.py", line 328, in valve_demand
raise ValueError(f"Invalid result: {result} (0x{value}) is > 1")

ValueError: Invalid result: 1.01 (0xCA) is > 1

message trace v0.21.6 -.txt
packet.log
evohome controllers configurations v0.21.06.txt

There are two issues here - this addresses the first issue...
These are bugs, and I have identified them - they will be corrected in the next release:
11:48:21.862 I --- 13:103760 --:------ 13:103760 3EF0 003 0000FF < Support the development of ramses_rf by reporting this packet (byte 5: )
11:48:39.094 I --- 13:107116 --:------ 13:107116 3EF0 003 00C8FF < Support the development of ramses_rf by reporting this packet (byte 5: )

This is not a bug - more so it is behaviour that is not understood...
15:17:41.881 I --- 04:065911 --:------ 01:095571 3150 002 03CA < Coding error: ValueError(Invalid result: 1.01 (0xCA) is > 1)

I am looking into it.

@epicurei
Reagrding these errors:
11:48:21.862 I --- 13:103760 --:------ 13:103760 3EF0 003 0000FF < Support the development of ramses_rf by reporting this packet (byte 5: )
11:48:39.094 I --- 13:107116 --:------ 13:107116 3EF0 003 00C8FF < Support the development of ramses_rf by reporting this packet (byte 5: )

It would be great for you to confirm which release of ramses_rf (or ramses_cc*) you were using.

the version is the one indicated in the files name ramses_rf v0.21.6 downloaded on the first of november
Da: David Bonnes @.>
Inviato: domenica 6 novembre 2022 13:11
A: zxdavb/ramses_rf @.>
Cc: epicurei @.>; Mention @.>
Oggetto: Re: [zxdavb/ramses_rf] ValueError: Invalid result: 1.01 (0xCA) is > 1 (Issue #59)
@epicurei https://github.com/epicurei
Reagrding these errors:
11:48:21.862 I --- 13:103760 --:------ 13:103760 3EF0 003 0000FF < Support the development of ramses_rf by reporting this packet (byte 5: )
11:48:39.094 I --- 13:107116 --:------ 13:107116 3EF0 003 00C8FF < Support the development of ramses_rf by reporting this packet (byte 5: )
It would be great for you to confirm which release of ramses_rf (or ramses_cc*) you were using.
—
Reply to this email directly, view it on GitHub https://github.com/zxdavb/ramses_rf/issues/59#issuecomment-1304786910 , or unsubscribe https://github.com/notifications/unsubscribe-auth/A2UBW3VUIBQWYMNOQQXHI73WG6N4TANCNFSM6AAAAAARW6AT7Q .
You are receiving this because you were mentioned.Message ID: @.***>
--
Questa email è stata esaminata alla ricerca di virus dal software antivirus AVG.
www.avg.com

To be exact: you downloaded it via HACS?

The image has not made it to github - I think because you responded via email.

I have no idea what you mean by HACS but here attached image of what I use to download new versions as I did today with 0.22.1

OK, got you now, thanks.
I suggest you only use tagged versions (unless you want), see:

https://github.com/zxdavb/ramses_rf/tags

The master branch is very likely to have bugs, so reporting issues against that can be counter-productive.
The latest tagged version is 0.22.1.
Don't worry: this ValueError is a genuine bug.

See #71 - continue there


Add  warning

Also replace cdnjs.cloudflare.com warning with something similar to extension-warning style.

Added.


Tags don't propagate on layouts

I'm not sure if this is a feature request or a bug.
if you have:
_include/mylayout.njk
---
tags: mytag
---

page.njk
---
layout: mylayout.njk
---

Then I'd expect that page.njk would be part of mytag. Other data seems to propagate properly, but tags seem to be ignored. When used like this:
---
renderOrder: 1
---
{%- for post in search.pages('mytag') -%}

we seem to only save content from #renderPage. I think it would make sense to update data too?

Data in layouts doesn't affect to the pages, it's used only for rendering. You can use _data.* files to apply the same tag to all files in a directory.
Why do you want to do this?

It's a bit quality of life. It feels it should just work.
My use case is: I have a special type of post, that has a different layout and I want to search all of those. Mostly to avoid having to do:
layout: x
tags: x

everywhere. In my case, _data will probably solve it.

Note that you can search a page not only by tags but any other value. For example:
{%- for post in search.pages('layout=mylayout.njk') -%}

That totally solves it. :)
"The purpose of layouts is rendering pages, not assign data. You have _data.* files and folders for that purpose."
That's fair, I guess.


Vulnerability roundup 79: bind-9.14.7: 1 advisory

search, files

[ ] CVE-2019-6477 CVSSv3=7.5 (nixos-19.09)

Scanned versions: nixos-19.09: d85e435b7bd. May contain false positives.

See also: #73617

Unstable/master: PR #74109; 19.09: 1d2b6d232 (staging ATM, but should get into channel within days).


ARROW-14054: [C++] [Docs] Simplify C++ row conversion example

Add explanations for code example
Print out entries
make variable names clearer

@amol- Since you're getting acquainted with Arrow C++, what do you think about this?

Thanks for the feedback. Will incorporate this.


Write a Ruby program to convert binary to decimal

Description
Write a Ruby program to convert binary to decimal
Binary is a base-2 number system. It uses only two digits: 0 and 1. The digits are called bits. A bit is the smallest unit of information in a computer. A bit can be either 0 or 1. A bit can be used to represent a single value, such as 0 or 1, or it can be used to represent a single state, such as on or off.
To convert a binary number to decimal, we can use the following algorithm:

Multiply the first bit by 2^0.
Multiply the second bit by 2^1.
Multiply the third bit by 2^2.
Multiply the fourth bit by 2^3.
Repeat steps 3 and 4 until the last bit.
Add the results of all the multiplications.
The decimal number is the sum of all the multiplications.

Input  : 1010
Output : 10

How to contribute

Save the solution in ConvertBinaryToDecimal.rb file
Add ConvertBinaryToDecimal.rb file in convert-binary-to-decimal folder

!assign

Hey @thekavikumar,
This issue has been assigned to you for more than 15 days.
We are unassigning you from this issue.
If you are still interested in contributing to this issue, please get auto-assigned on the issue by commenting !assign again.
Thanks for your contributions :)


I tried to deploy an app that was already deployed using my azure extension and is no longer working

Does this occur consistently?
Repro steps:

Action: appService.Deploy
Error type: TypeError
Error Message: Cannot read properties of undefined (reading 'createClient')
Version: 0.24.9
OS: darwin
OS Release: 23.4.0
Product: Visual Studio Code
Product Version: 1.71.0
Language: en

Call Stack
extension.bundle.js:2:3774912
fulfilled extension.bundle.js:2:3773583

Please provide detailed repo steps.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


graphOpacity property

It would be nice to be able to set the graph's opacity in the constuctor of the LineGraph class.

Hi I added the changes you requested and I also put a default value to the new property

Hey @dllarsson, Merged your PR. Appreciate your contribution ❤


fix: use .text instead of .json for ALB key http call

Hey, I just made a Pull Request!
Add fix for bug introduced in  ALB provider during code review  - fetch needs to use .text instead of .json for getting public key data from AWS.

:heavy_check_mark: Checklist

[X] A changeset describing the change and affected packages. (more info)
[X] Added or updated documentation
[X] Tests for new functionality and regression tests for bug fixes
[X] Screenshots attached (for UI changes)

@Rugvip Hope this https://github.com/backstage/backstage/pull/4225 should be enough for the markdown check 😄

@Rugvip Hope this https://github.com/backstage/backstage/pull/4225 should be enough for the markdown check 😄


[QUESTION]: Where is the notebook for illuminati1.1 ?

What happened?
Hello, I can't find it, is it not supported anymore?
Console logs
No response
Is there an existing issue for this?

[X] I have searched the existing issues and checked the recent builds/commits

Are you using the latest version of the colab notebook?

[X] Yes, i am using the latest version from the repo

Which colab notebook did you use?
N/A
Which repo branch did the colab you use comes from ?
stable
Which tunnel did you use ?
--share (Gradio Tunnel)
What browsers do you use to access the WebUI ?
Google Chrome

The model is still available to download manually/with batchlinks on civitai, but the point is, camenduru won't include the colab on his repo for those reasons.


create applyFilters function

Given a list of filters, return a new filtered reference.

This is no longer relevant since we want the UX to be more adaptive..


Add mouse events to text and image primitives

Fixes #124.
Fixes #125.
I have tested them locally, but didn't commit any usage in the examples. Happy to do so if needed!

🎉 Thanks @bryphe ! Just a small note in case it happens again, I had to run the tests twice because the build of jsoo ppx failed 🤔 Not sure why, but re-running the tests fixed it.


CLI flags inconsistent nexctl --host vs nexd --service-url

Describe the bug
CLI flags are inconsistent between nexctl --host and nexd --service-url.  They seem to be for the same purpose.
How to Reproduce
See usage info for both commands.
Expected Behavior
Both commands should use the same flag.
Deployment Environment
No response
Additional Context
No response

I vote --service-url, though the behavior and defaults are not quite the same.
The default in nexctl has an api prefix while the default for nexd does not. It would be nice to make the behavior of the options the same as part of making the option names the same.

I vote --service-url, though the behavior and defaults are not quite the same.
The default in nexctl has an api prefix while the default for nexd does not. It would be nice to make the behavior of the options the same as part of making the option names the same.

I agree with all the above.


Update flyway-core to 7.9.0

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

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.flywaydb", artifactId = "flyway-core" } ]

labels: library-update, semver-minor

Superseded by #501.


Add Docker support

Todos:

[ ] Add workflows for build and push to DockerHub
[ ] Update documentation

Hey @clausnagel, thx for the new features, that's really cool. I'll test that tomorrow.
I will add add workflows for automatic image creation similar to the workflows for the Importer/Exporter as well.

@BWibo, @yaozhihang, how should we deal with the wfs.log file inside a Docker container to avoid that it grows too large and requires too much disk space? For example:

Do not write to the log file at all but only print log messages to the console
Write the log to a data volume
Install and use logrotate in the container
...

Maybe a combination of different methods?

@BWibo, @yaozhihang, how should we deal with the wfs.log file inside a Docker container to avoid that it grows too large and requires too much disk space? For example:

Do not write to the log file at all but only print log messages to the console
Write the log to a data volume
Install and use logrotate in the container
...

Maybe a combination of different methods?

Good point. In my opinion, the first option sounds better. a) It allows to explore the log info straightforward via console. b) The rotate and remove of old logs can be managed by docker's built-in log drivers automatically.

Thanks for your feedback, @yaozhihang. Yes, I agree with you. Another argument for the first option is that it can be easily imlpemented without a lot of code changes. We just have to change the current behaviour that a log file is always created. Will make a proposal.

I think the first option is best from a Docker perspective. Docker will automatically collect anything that comes in from the application running inside the container from STDOUT, STDERR.
Different ways of handling these logs are provided by  docker logs and various logging drivers.
I suggest to disable file logging by default. Are errors currently logged to console (STDERR) as well?

Ok, the WFS can now be configured to only log to the console (https://github.com/3dcitydb/web-feature-service/commit/e961afd304e570ffdf36cfb194c4b1c538ac582c). And I changed the default-config.xml for Docker so that it uses this new feature (https://github.com/3dcitydb/web-feature-service/commit/f4771395ff66f2433eb03dd8b56c94d4c9a36458).

I think the first option is best from a Docker perspective. Docker will automatically collect anything that comes in from the application running inside the container from STDOUT, STDERR.

👍

I suggest to disable file logging by default. Are errors currently logged to console (STDERR) as well?

Yep, file logging is now disabled by default. And yes, errors go to STDERR.

I added an Alpine image version and added github workflows for builidng docker images.
I push the images to https://hub.docker.com/repository/docker/3dcitydb/wfs for testing.

Am I missing something? Maybe this is caused by the context path.
Inside the container the webapp seems to be in place:
docker exec wfs bash -c "ls -lah /usr/local/tomcat/webapps/ROOT"
total 20K
drwxr-x--- 5 tomcat tomcat 4.0K Sep  1 13:29 .
drwxr-xr-x 1 tomcat tomcat 4.0K Sep  1 13:29 ..
drwxr-x--- 2 tomcat tomcat 4.0K Sep  1 13:29 META-INF
drwxr-x--- 5 tomcat tomcat 4.0K Sep  1 13:29 WEB-INF
drwxr-x--- 5 tomcat tomcat 4.0K Sep  1 13:29 wfsclient
tomcat@66eff3790c59:~$

The WFS log seems file too:
...
...
...
01-Sep-2021 13:29:50.011 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/9.0.52]
01-Sep-2021 13:29:50.025 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/usr/local/tomcat/webapps/ROOT.war]
01-Sep-2021 13:29:52.196 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
[13:29:54 INFO] Starting 3DCityDB-Web-Feature-Service, version 4.3.0.
[13:29:54 INFO] Database connection established.
[13:29:54 INFO] 3D City Database: 4.1.0
[13:29:54 INFO] DBMS: PostgreSQL 13.2 (Debian 13.2-1.pgdg100+1)
[13:29:54 INFO] Connection: postgres@cdbtemp:5432/postgres
[13:29:54 INFO] Schema: citydb
[13:29:54 INFO] SRID: 25832 (Projected)
[13:29:54 INFO] SRS: ETRS89 / UTM zone 32N
[13:29:54 INFO] gml:srsName: urn:ogc:def:crs:EPSG::25832
01-Sep-2021 13:29:55.199 INFO [main] org.hsqldb.persist.Logger.logInfoEvent dataFileCache open start
[13:29:55 INFO] Reference system 'WGS 84' (SRID: 4326) supported.
[13:29:55 WARN] The version 4.1.0 of the 3D City Database is out of date. Consider upgrading.
01-Sep-2021 13:29:56.217 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/usr/local/tomcat/webapps/ROOT.war] has finished in [6,191] ms
01-Sep-2021 13:29:56.230 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
01-Sep-2021 13:29:56.238 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [6272] milliseconds

The new env ars are as follows, right?
CITYDB_TYPE
CITYDB_HOST
CITYDB_PORT
CITYDB_NAME
CITYDB_SCHEMA
CITYDB_USERNAME
CITYDB_PASSWORD

One addition:
When I build like this:
DOCKER_BUILDKIT=1 \
docker build . \
  --build-arg CONTEXT_PATH=citydb-wfs \
  -t 3dcitydb/wfs:edge

The services are available at: http://localhost:8080/citydb-wfs/wfsclient/ http://localhost:8080/citydb-wfs/wfs
Same applies to:
DOCKER_BUILDKIT=1 \
docker build . \
  --build-arg CONTEXT_PATH=root \
  -t 3dcitydb/wfs:edge

The services are available at: http://localhost:8080/root/wfsclient/ http://localhost:8080/root/wfs
It seems like capital letters in CONTEXT_PATH cause an error.
I suggest setting the CONTEXT_PATH default to citydb-wfs in the Dockerfiles.

Some more thoughts on the image:

In some situations it could be handy to change the CONTEXT_PATH on runtime with an config ENV var.
This should be possible by renaming the WAR-file in citydb-wfs-entrypoint.sh.

The same applies for setting the DEFAULT_CONFIG. I suggest to rename DEFAULT_CONFIG to e.g. WFS_CONFIG and allow setting it on runtime as well. Like this, we could provide a set of default configs the user can choose from or allow the user to mount own config files as well.
This would require copying the selected/mounted file to CONTEXT_PATH/WEB-INF/config.xml in  citydb-wfs-entrypoint.sh, right?

Hi @BWibo,

When I try to open http://localhost:8080/ROOT/wfsclient or http://localhost:8080/ROOT/wfsclient or

ROOT should not be part of your URL when requesting the service. ROOT is rather an "empty" context path.
Thus, when you deploy with ROOT, the service is available at localhost:8080/wfs
When you deply with, for instance, citydb-wfs, the service is available at  localhost:8080/citydb-wfs/wfs
This works fine in my tests

I suggest to rename DEFAULT_CONFIG to e.g. WFS_CONFIG and allow setting it on runtime as well.

We already have a WFS_CONFIG_FILE environment variable. So the user can already pick an arbitrary config.xml file at startup. The DEFAULT_CONFIG is the config that is used in case the no other config is provided through WFS_CONFIG_FILE.

Ah perfect. I didn't know the ROOT thing and WFS_CONFIG_FILE. Then everything is fine and this can be merged I guess.
The behavior of the workflows is the same as for the Importer/Exporter images:

Push to master: edge and edge-alpine are built and pushed.
Push to PR: The build-only workflows run for testing.
Release: * x.x.x, x.x.x-alpine, latest and latest-alpine are built and pushed.

Thanks for adding the workflows, @BWibo, this is awesome! And thanks for approving the PR. I like your idea of turning the CONTEXT_PATH argument into a ENV variable though. I can still add it here.

@BWibo, I turned CONTEXT_PATH into the ENV variable WFS_CONTEXT_PATH, which is now used to rename the WAR file in the citydb-wfs-entrypoint.sh file.

Documentation will follow in the upcoming days. Merging the code now.


silex2 cloudflare flexible ssl redirect loop

prior to silex2... we have been using the following to handle ssl redirect loops that is mostly described here... https://support.cloudflare.com/hc/en-us/articles/218890817-Fixing-redirect-loops-when-using-Flexible-SSL
in our app.php we had...
$app['url_matcher'] = $app->share(function () use ($app) {
    return new \Someapp\SomeFramework\SomeRedirectableUrlMatcher($app['routes'], $app['request_context']);
});

which i have changed for silex2 to
$app['url_matcher'] = function () use ($app) {
    return new \Someapp\SomeFramework\SomeRedirectableUrlMatcher($app['routes'], $app['request_context']);
};

and SomeRedirectableUrlMatcher.php looks like...
use Symfony\Component\Routing\Route;
use Silex\Provider\Routing\RedirectableUrlMatcher as BaseRedirectableUrlMatcher;

class SomeRedirectableUrlMatcher extends BaseRedirectableUrlMatcher
{
    protected function handleRouteRequirements($pathinfo, $name, Route $route)
    {
        // expression condition
        if ($route->getCondition() &&
            !$this->getExpressionLanguage()->evaluate(
                $route->getCondition(),
                array('context' => $this->context, 'request' => $this->request)
            )) {
            return array(self::REQUIREMENT_MISMATCH, null);
        }

        // check HTTP scheme requirement
        $scheme = $this->context->getScheme();
        $schemes = $route->getSchemes();

        if (!empty($_SERVER["HTTP_CF_VISITOR"])) {
            $cfInfo = json_decode($_SERVER["HTTP_CF_VISITOR"]);

            if (!empty($cfInfo->scheme) && $cfInfo->scheme == 'https') {
                $scheme = $cfInfo->scheme;
            }
        }

        if ($schemes && !$route->hasScheme($scheme)) {
            return array(self::ROUTE_MATCH, $this->redirect($pathinfo, $name, current($schemes)));
        }

        return array(self::REQUIREMENT_MATCH, null);
    }
}

In silex2 this just does not seem to be used or at least not working and we are getting a redirect loop.
Any advice for this as I am not seeing what would have changed.

$app['url_matcher'] needs to now be $app['request_matcher']
maybe add to changelog?


Upgrade Indexes-related methods to the v0.25.0

Includes creation of a new implementation of PendingUpdate to be used inside the MeiliSearchClient instance.
All the tests are related directly to the updated version of the indexes.

Related to the v0.25.0 upgrade.

And a last question did these two new methods would be implemented after?

client.getTasks that calls /tasks
client.getTask that calls /tasks/:uid


Re-implement checkpoint/restore after containerd integration

Add (experimental) support for checkpoint/restore to Docker
Support for C/R has been implemented before (#13602 and #13442), but due to the upcoming move to integrate containerd in Docker 1.11, the existing checkpoint/restore PR unfortunately had to be closed (see https://github.com/docker/docker/pull/13602#issuecomment-181614492).
This issue is to track progress on the re-implementation of the checkpoint/restore feature after containerd has been integrated.

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

Just as a heads up for people interested in the meantime, here's a compiled version of the now closed pull request you can play around with in the meantime (now with working networking support):
https://github.com/boucher/docker/releases/tag/v1.10_2-16-16-experimental

Cool, thanks @boucher :heart:

Hi, I was interested in your closed pull requests.
I want to ask a few simple questions.

Will this issue be merged to original docker?
If I want to use checkpoint/restore functions,
2.1. Install docker from original docker codes.
2.2. stop docker service
2.3. change binary file which you commented above.
2.4. re-start docker service

@boucher any chance you might consider the awesome forward-thinking work and fork/PR Docker 1.11 with CRIU 2.0? Looking forward to seeing this land!
Also, could you clarify if there is indeed a minimum kernel version required? I'm curious if the suggestion to use --security-opt seccomp:unconfined would allow older kernel support.

Using --security-opt=seccomp:unconfined should work fine on older kernels.
And things should work transparently with CRIU 2.0. I think doing the work
for final Docker integration has to wait until the containerd work is
finished (or close to finished). I'm not sure what the status of that is
currently.
On Tue, Mar 8, 2016 at 1:18 PM Mike Atlas<EMAIL_ADDRESS>wrote:

@boucher https://github.com/boucher any chance you might consider the
awesome forward-thinking work and fork/PR Docker 1.11 with CRIU 2.0?
Looking forward to seeing this land!
Also, could you clarify if there is indeed a minimum kernel version
required? I'm curious if the suggestion to use --security-opt
seccomp:unconfined would allow older kernel support.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/20300#issuecomment-193898338.

I'm just going to leave this here and sneak away https://github.com/dmtcp/dmtcp
/cc @rhatdan @vishh

Any updates on this? It looks like the containerd integration has happened.

This is the first step: https://github.com/docker/engine-api/pull/175

The basics (API) are merged https://github.com/docker/docker/issues/22049, so I'm closing this issue


Android build fails with certain plugins if project is in a different drive (from sdk)

Steps to Reproduce

Create project in a different drive from Flutter SDK
Add shared_preferences and url_launcher to pubspec.yaml and run flutter pub get
Open the android folder with Android Studio or IDEA
Gradle sync fails (error logs below)

I checked stackoverflow and https://stackoverflow.com/a/71734846/13978447 this is the workaround that works for me too.
The build fails only if the project is in a different drive from the drive in which the sdk is in.
My project is in D: and both (Android and Flutter) SDKs are in C:.
I copied the project to C: and the build succeeds.
Although this fixes the issue I do not want to store the project in C: drive (and I shouldn't have to).
I also noticed that using an old version of the plugin shared_preferences: 2.0.6 instead of the latest 2.0.15 fixes the issue for this plugin atleast.

Screenshots and Logs

logs_1.txt

logs_2.txt

logs_3.txt

logs_4.txt

Flutter Doctor
[√] Flutter (Channel stable, 3.0.1, on Microsoft Windows [Version 10.0.19043.1706], locale en-IN)
    • Flutter version 3.0.1 at C:\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision fb57da5f94 (2 weeks ago), 2022-05-19 15:50:29 -0700
    • Engine revision caaafc5604
    • Dart version 2.17.1
    • DevTools version 2.12.2

[√] Android toolchain - develop for Android devices (Android SDK version 32.0.0)
    • Android SDK at C:\Users\VARUN\AppData\Local\Android\Sdk
    • Platform android-Tiramisu, build-tools 32.0.0
    • ANDROID_HOME = C:\Users\VARUN\AppData\Local\Android\Sdk
    • ANDROID_SDK_ROOT = C:\Users\VARUN\AppData\Local\Android\Sdk
    • Java binary at: C:\Users\VARUN\.jdks\corretto-11.0.15\bin\java
    • Java version OpenJDK Runtime Environment Corretto-<IP_ADDRESS>.1 (build 11.0.15+9-LTS)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Build Tools 2019 16.9.3)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
    • Visual Studio Build Tools 2019 version 16.9.31129.286
    • Windows 10 SDK version 10.0.18362.0

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).

[√] IntelliJ IDEA Ultimate Edition (version 2022.1)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA 2022.1
    • Flutter plugin version 68.1.4
    • Dart plugin version 221.5787.37

[√] VS Code, 64-bit edition (version 1.67.2)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension can be installed from:
       https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[√] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.19043.1706]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 102.0.5005.63
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 101.0.1210.39

[√] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

Hi @VarunS2002,
I can not reproduce this issue on the latest stable and master channels.
The project I created on drive D: run well with Flutter SDK located on drive C:

Sample code
The default new created project with adding two dependencies:
  shared_preferences: ^2.0.15
  url_launcher: ^6.1.2

Logs
PS D:\WIP\reproducesample> flutterm run -t .\lib\build_fail_diff_storage_105395.dart
Running "flutter pub get" in reproducesample...                  2,162ms
Launching .\lib\build_fail_diff_storage_105395.dart on Pixel 3a in debug mode...
Warning: Mapping new ns http://schemas.android.com/repository/android/common/02 to old ns http://schemas.android.com/repository/android/common/01
Warning: Mapping new ns http://schemas.android.com/repository/android/generic/02 to old ns http://schemas.android.com/repository/android/generic/01
Warning: Mapping new ns http://schemas.android.com/sdk/android/repo/addon2/02 to old ns http://schemas.android.com/sdk/android/repo/addon2/01
Warning: Mapping new ns http://schemas.android.com/sdk/android/repo/repository2/02 to old ns http://schemas.android.com/sdk/android/repo/repository2/01
Warning: Mapping new ns http://schemas.android.com/sdk/android/repo/sys-img2/02 to old ns http://schemas.android.com/sdk/android/repo/sys-img2/01
Running Gradle task 'assembleDebug'...                             56.7s
√  Built build\app\outputs\flutter-apk\app-debug.apk.
Installing build\app\outputs\flutter-apk\app.apk...              2,770ms
Syncing files to device Pixel 3a...                                185ms

Flutter run key commands.
r Hot reload.
R Hot restart.
h List all available interactive commands.
d Detach (terminate "flutter run" but leave application running).
c Clear the screen
q Quit (terminate the application on the device).

 Running with sound null safety

An Observatory debugger and profiler on Pixel 3a is available at: http://<IP_ADDRESS>:50155/V-NbAkkmIG8=/
The Flutter DevTools debugger and profiler on Pixel 3a is available at: http://<IP_ADDRESS>:9101?uri=http://<IP_ADDRESS>:50155/V-NbAkkmIG8=/

flutter doctor -v
[√] Flutter (Channel stable, 3.0.1, on Microsoft Windows [Version 10.0.19043.1706], locale en-US)
    • Flutter version 3.0.1 at C:\WIP\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision fb57da5f94 (2 weeks ago), 2022-05-19 15:50:29 -0700
    • Engine revision caaafc5604
    • Dart version 2.17.1
    • DevTools version 2.12.2

[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at C:\AndroidSDK
    • Platform android-31, build-tools 31.0.0
    • ANDROID_HOME = C:\AndroidSDK
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.1.6)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.1.32421.90
    • Windows 10 SDK version 10.0.20348.0

[√] Android Studio (version 2020.3)
    • Android Studio at C:\Program Files\Android\Android Studio
    • 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.67.2)
    • VS Code at C:\Users\ADMIN\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.42.0

[√] Connected device (4 available)
    • Pixel 3a (mobile) • 964AY0WL20 • android-arm64  • Android 12 (API 32)
    • Windows (desktop) • windows    • windows-x64    • Microsoft Windows [Version 10.0.19043.1706]
    • Chrome (web)      • chrome     • web-javascript • Google Chrome 102.0.5005.63
    • Edge (web)        • edge       • web-javascript • Microsoft Edge 101.0.1210.53

[√] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

[√] Flutter (Channel master, 3.1.0-0.0.pre.1116, on Microsoft Windows [Version 10.0.19043.1706], locale en-US)
    • Flutter version 3.1.0-0.0.pre.1116 at C:\WIP\flutter_master
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 66be43338e (in the future), 2022-06-06 03:53:08 -0400
    • Engine revision 054e4b2af9
    • Dart version 2.18.0 (build 2.18.0-170.0.dev)
    • DevTools version 2.14.0

[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at C:\AndroidSDK
    • Platform android-31, build-tools 31.0.0
    • ANDROID_HOME = C:\AndroidSDK
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.1.6)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.1.32421.90
    • Windows 10 SDK version 10.0.20348.0

[√] Android Studio (version 2020.3)
    • Android Studio at C:\Program Files\Android\Android Studio
    • 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.67.2)
    • VS Code at C:\Users\ADMIN\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.42.0

[√] Connected device (4 available)
    • Pixel 3a (mobile) • 964AY0WL20 • android-arm64  • Android 12 (API 32)
    • Windows (desktop) • windows    • windows-x64    • Microsoft Windows [Version 10.0.19043.1706]
    • Chrome (web)      • chrome     • web-javascript • Google Chrome 102.0.5005.63
    • Edge (web)        • edge       • web-javascript • Microsoft Edge 101.0.1210.53

[√] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

As I can see from your flutter doctor -v:

[!] Android Studio (not installed)
• Android Studio not found; download from https://developer.android.com/studio/index.html
(or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).

It seems you're not using Android Studio. What's your current IDEA? Or can you try installing Android Studio and retry?

@huycozy
Oh no don't get me wrong.
flutter run and flutter build apk both work fine.
Which indicates that the gradle tasks assembleDebug and assembleRelease both work.
Only the gradle sync process fails in IDEA when I open the android folder as a project resulting in me unable to use the native Android features in IDEA.
One thing to note is that I am using Android Gradle Build Plugin 7.0.4 instead of the Flutter default 7.1.2 because IDEA 2022.1.2 doesn't support it apparently.
I will install and setup Android Studio to test the same but I will need a few days time so please don't close the issue by then,

@huycozy Oh no don't get me wrong. flutter run and flutter build apk both work fine.
Which indicates that the gradle tasks assembleDebug and assembleRelease both work. Only the gradle sync process fails in IDEA when I open the android folder as a project resulting in me unable to use the native Android features in IDEA. One thing to note is that I am using Android Gradle Build Plugin 7.0.4 instead of the Flutter default 7.1.2 because IDEA 2022.1.2 doesn't support it apparently.
I will install and setup Android Studio to test the same but I will need a few days time so please don't close the issue by then,

I tried it with the latest Android Studio Chipmunk 2021.2.1 Patch 1 but the issue persists.
With Android Gradle Plugin 7.0.4:

With Android Gradle Plugin 7.1.2:

@huycozy Oh no don't get me wrong. flutter run and flutter build apk both work fine.
Which indicates that the gradle tasks assembleDebug and assembleRelease both work. Only the gradle sync process fails in IDEA when I open the android folder as a project resulting in me unable to use the native Android features in IDEA. One thing to note is that I am using Android Gradle Build Plugin 7.0.4 instead of the Flutter default 7.1.2 because IDEA 2022.1.2 doesn't support it apparently.
I will install and setup Android Studio to test the same but I will need a few days time so please don't close the issue by then,

I tried it with the latest Android Studio Chipmunk 2021.2.1 Patch 1 but the issue persists.
With Android Gradle Plugin 7.0.4:

With Android Gradle Plugin 7.1.2:

I created a new empty project to reproduce the issue which I'm attaching here:
test.zip

New Flutter Doctor output
[√] Flutter (Channel stable, 3.0.1, on Microsoft Windows [Version 10.0.19043.1706], locale en-IN)
    • Flutter version 3.0.1 at C:\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision fb57da5f94 (3 weeks ago), 2022-05-19 15:50:29 -0700
    • Engine revision caaafc5604
    • Dart version 2.17.1
    • DevTools version 2.12.2

Checking Android licenses is taking an unexpectedly long time...[√] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
    • Android SDK at C:\Users\VARUN\AppData\Local\Android\Sdk
    • Platform android-Tiramisu, build-tools 32.1.0-rc1
    • ANDROID_HOME = C:\Users\VARUN\AppData\Local\Android\Sdk
    • ANDROID_SDK_ROOT = C:\Users\VARUN\AppData\Local\Android\Sdk
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Build Tools 2019 16.9.3)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
    • Visual Studio Build Tools 2019 version 16.9.31129.286
    • Windows 10 SDK version 10.0.18362.0

[√] Android Studio (version 2021.2)
    • Android Studio at C:\Program Files\Android\Android Studio
    • 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.12+7-b1504.28-7817840)

[√] IntelliJ IDEA Ultimate Edition (version 2022.1)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA 2022.1
    • Flutter plugin version 68.1.4
    • Dart plugin version 221.5787.37

[√] VS Code, 64-bit edition (version 1.67.2)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension can be installed from:
       https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[√] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.19043.1706]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 102.0.5005.63
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 101.0.1210.39

[√] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

@VarunS2002
Opened your test.zip and see the version is different than you reported.
It's using 7.1.2:

classpath 'com.android.tools.build:gradle:7.1.2'

Anyway, I got the same error when creating new project and adding dependencies as above mentioned.

Logs
Could not create task ':shared_preferences_android:generateDebugUnitTestConfig'.
this and base files have different roots: D:\WIP\test_flutter_gradle\build\shared_preferences_android and C:\Users\ADMIN\AppData\Local\Pub\Cache\hosted\pub.dartlang.org\shared_preferences_android-2.0.12\android.

The temporary workaround is to use lower gradle 4.1.3:

classpath 'com.android.tools.build:gradle:4.1.3'

FYI, there is a completed work here #87649 in order to support for Android Gradle Plugin 7.0.0, but it's not supported for first party packages/plugins yet.  Follow up on #88666 for further updates.
I'm closing the current one as a duplicate.
If you disagree, please write in the comments and I will reopen it.

The version was different because I created a new project in the latest Android Studio to test this issue (to check whether IDEA or AGB 7.0.4 was the problem). My main project still has AGP 7.04 and throws the same error.
Either way you're able to reproduce the error so it doesn't matter.

Also I'm curious why this happens only on a different drive and works fine on the drive that has the sdk?

Also I'm curious why this happens only on a different drive and works fine on the drive that has the sdk?

You're right, it worked well on the same drive even with default Gradle 7.1.2. It means that we don't need to update anything from new project when creating the project in the same drive with Flutter SDK.
Reopen this issue for further investigation from the team due to this issue's occurring in a special case, it is unlikely that #88666 will be aware/fix it next time.

Also I'm curious why this happens only on a different drive and works fine on the drive that has the sdk?

You're right, it worked well on the same drive even with default Gradle 7.1.2. It means that we don't need to update anything from new project when creating the project in the same drive with Flutter SDK.
Reopen this issue for further investigation from the team due to this issue's occurring in a special case, it is unlikely that #88666 will be aware/fix it next time.

Hope this gets fixed soon. Meanwhile I'll develop in the same drive as the Flutter SDK.

we migrated our project to flutter 3.0，also occured this issue...
we can sync successfully after run flutter clean with the project, but after run pub get or pug upgrade, the Android Studio can't sync and report this error

flutter 3.0 . my flutter sdk was in E drive and project was d drive .showing this error
i project to e drive problem solved.temp solution

I am having the same issue. flutter sdk in C drive and project in D.
That's turned out that my current gradle version(com.android.tools.build:gradle:7.1.3) was somehow incompatible with image_picker: ^0.8.5+3, because after removing it from pubspec.yaml  this issue disappeared
I also changed my distributionUrl to the latest distributionUrl =https://services.gradle.org/distributions/gradle-7.5.1-all.zip
Then I Opened the android folder with Android Studio or IDEA and it built successfully
In addition, Android Studio recommended me to Updgade my Gradle from the current version 7.1.3 to version 7.2.2.

Hi @VarunS2002, I can not reproduce this issue on the latest stable and master channels. The project I created on drive D: run well with Flutter SDK located on drive C:
Sample code
Logs
flutter doctor -v
As I can see from your flutter doctor -v:

[!] Android Studio (not installed)
• Android Studio not found; download from https://developer.android.com/studio/index.html
(or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).

It seems you're not using Android Studio. What's your current IDEA? Or can you try installing Android Studio and retry?

If flutter is installed on disk D:, perhaps setting the pub cache path to disk D:\ will solve this problem; Set the environment variable PUB_CACHE

I ran into the same issue and as a temporary word around, as @json1994 suggested,  I set a PUB_CACHE environment variable (https://dart.dev/tools/pub/environment-variables) so that that pub cache is located on the same drive as the flutter project. In my  case, flutter SDK is installed on D: drive and the project folder is in F: drive, so I set PUB_CACHE to a new folder under F: drive. The Flutter SDK is still located on D: drive.  The Gradle sync issue no longer occurs in Android Studio. I am using Gradle 7.4 and AGP 7.1.2.

Facing the same issue when flutter is updated to 3.7.3:
A build operation failed.
    Could not create task ':path_provider_android:generateDebugUnitTestConfig'.
Could not create task ':path_provider_android:generateDebugUnitTestConfig'.
this and base files have different roots: D:\XX\x_project\example\build\path_provider_android and C:\Users\XX\AppData\Local\Pub\Cache\hosted\pub.flutter-io.cn\path_provider_android-2.0.16\android.

It works befor I update to 3.7.3.

Facing the same issue when flutter is updated to 3.7.3:
A build operation failed.
    Could not create task ':path_provider_android:generateDebugUnitTestConfig'.
Could not create task ':path_provider_android:generateDebugUnitTestConfig'.
this and base files have different roots: D:\XX\x_project\example\build\path_provider_android and C:\Users\XX\AppData\Local\Pub\Cache\hosted\pub.flutter-io.cn\path_provider_android-2.0.16\android.

It works befor I update to 3.7.3.

same here

my project and flutter sdk is in the same drive and I have this issue ,
Flutter 3.7.3 • channel stable
Tools • Dart 2.19.2 • DevTools 2.20.1

Adding customer: crowd label based on the number of reports and upvotes.

Having same problem today, found a post on stackoverflow that stated:

delete your ./android folder from your project
flutter create --platforms android .  (remember to add the "." at the end of the command and to run this in your project directory
make the changes you had before you had to recreate the android directory (I did not have any custom changes for my simple project).
This solved my problem

I encountered the same error, but I found an easier workaround. I found the answer in stackoverflow. Rather than moving the project folder to the same drive/partition as the gradle folder, you just need to gradle sync BEFORE you do flutter pub get.
Here are the full steps:

Run flutter clean
Run gradle sync
Run flutter pub get

Following those steps, I can now build and run my flutter app without issues, with gradle sync working as well, without needing to move my project folder.

I encountered the same error, but I found an easier workaround. I found the workaround in stackoverflow. Rather than moving the project folder to the same drive/partition as the gradle folder, you just need to gradle sync BEFORE you do flutter pub get.
Here are the full steps:

Run flutter clean
Run gradle sync
Run flutter pub get

Following those steps, I can now build and run my flutter app without issues, with gradle sync working as well, without needing to move my project folder. I hope this can help people with the same issue.

You made my day, this worked. Stuck with this issue for almost a day.

I encountered this issue  and following your instructions helped me resolve the problem. Thank you!

I encountered the same error, but I found an easier workaround. I found the workaround in stackoverflow. Rather than moving the project folder to the same drive/partition as the gradle folder, you just need to gradle sync BEFORE you do flutter pub get.
Here are the full steps:

Run flutter clean
Run gradle sync
Run flutter pub get

Following those steps, I can now build and run my flutter app without issues, with gradle sync working as well, without needing to move my project folder. I hope this can help people with the same issue.

You made my day, this worked. Stuck with this issue for almost a day.

Thank you so much for your solution. IT worked also for me.

I encountered the same error, but I found an easier workaround. I found the workaround in stackoverflow. Rather than moving the project folder to the same drive/partition as the gradle folder, you just need to gradle sync BEFORE you do flutter pub get.
Here are the full steps:

Run flutter clean
Run gradle sync
Run flutter pub get

Following those steps, I can now build and run my flutter app without issues, with gradle sync working as well, without needing to move my project folder. I hope this can help people with the same issue.

Unluckily, this isn't working for me. I guess because my (native) project depends on a flutter project and is added like this: https://docs.flutter.dev/add-to-app/android/project-setup#option-b---depend-on-the-modules-source-code
When running flutter clean, it removes include_flutter.groovy and I get another build error :(
The manual creation of the android project as suggested by @MrTaz results in the same error.
The only way for me was to change the location of PUB_CACHE to the same drive as the projects. flutter pub clean and flutter pub get and the Gradle sync of main project worked :)

I encountered the same error, but I found an easier workaround. I found the workaround in stackoverflow. Rather than moving the project folder to the same drive/partition as the gradle folder, you just need to gradle sync BEFORE you do flutter pub get.
Here are the full steps:

Run flutter clean
Run gradle sync
Run flutter pub get

Following those steps, I can now build and run my flutter app without issues, with gradle sync working as well, without needing to move my project folder. I hope this can help people with the same issue.

Works for me as long as I disabled VS code auto gradle extension (which somehow trigger the issue again and again ...)

Apart from moving both directories to the same drive there is a simple solution of creating a symbolic junction/link for your project directory
Assuming you have Pub cache in C drive and your project in D drive:

Create a hard symbolic link in C drive to your app directory using windows command prompt:

mklink /J C:\Development\your\project\directory\link D:\your\project\directory\real\path

Open the project in your IDEs from symbolic junction/link

C:\Development\your\project\directory\link instead of D:\your\project\directory\real\path

With this everything should work as expected, however if you open terminal in IntelliJ it might give you the real path instead of symbolic link, hence after opening terminal do

cd C:\Development\your\project\directory\link

If you are using any custom or forked local dependencies from a relative path not absolute path and these are also in D(or any other non Pub cache) drive then you will need to create symbolic links for these paths as well e.g.:

mklink /J C:\Development\Flutter\custom_dependencies D:\Development\Flutter\custom_dependencies

If you use PoweShell instead of windows command prompt then you need to use New-Item to create symbolic directory junction:
New-Item -ItemType Junction -Path "Link" -Target "Target"

The way to solve this is to move the pub cache folder to the same drive where your flutter projects located.
Assume your pub cache folder located in C:\Users\<YOURNAME>\AppData\Local\Pub\Cache
Then move it to other drive, for example: E:\src\Pub\Cache
Then add PUB_CACHE into system environment variable, point to that folder path.
You might have to do a cache repair:
flutter pub cache repair

Also I'm curious why this happens only on a different drive and works fine on the drive that has the sdk?

This is not flutter's problem. This is a problem with the AGP unit test task.
When you open the android folder with Android Studio or IDEA, and run "Sync project with gradle files", it will generate some unit test tasks.
In com.android.build.gradle.tasksGenerateTestConfig.kt, there are methods that calculate the relationship between the buildDir path and the project path:

If there is no relative path relationship between them, it will will throw an exception: "this and base files have different roots:xxxxxx"

Hi @2017398956 , Thanks for clarifying on the issue, but the given steps to resolve the not clear. I tried below code in Flutter module app but not worked
subprojects {     project.buildDir ="${rootProject.buildDir}/${project.name}" }
Could you please give clear details in steps.

Hi @2017398956 , Thanks for clarifying on the issue, but the given steps to resolve the not clear. I tried below code in Flutter module app but not worked subprojects { project.buildDir ="${rootProject.buildDir}/${project.name}" }
Could you please give clear details in steps.

Comment out project.buildDir ="${rootProject.buildDir}/${project.name}"

@2017398956 , not working. but beow steps given by @topex-psy

The way to solve this is to move the pub cache folder to the same drive where your flutter projects located.
Assume your pub cache folder located in C:\Users\<YOURNAME>\AppData\Local\Pub\Cache Then move it to other drive, for example: E:\src\Pub\Cache
Then add PUB_CACHE into system environment variable, point to that folder path.
You might have to do a cache repair: flutter pub cache repair

I tried @topex-psy steps, and it worked, resolved the issue.
Thank you

@2017398956 , not working. but beow steps given by @topex-psy

The way to solve this is to move the pub cache folder to the same drive where your flutter projects located.
Assume your pub cache folder located in C:\Users\<YOURNAME>\AppData\Local\Pub\Cache Then move it to other drive, for example: E:\src\Pub\Cache
Then add PUB_CACHE into system environment variable, point to that folder path.
You might have to do a cache repair: flutter pub cache repair

I tried @topex-psy steps, and it worked, resolved the issue.
Thank you

Yes, that works, but when you have several projects under different drives, it can become cumbersome.
My solution is not to actually solve the problem, but to keep it from affecting android code.

The way to solve this is to move the pub cache folder to the same drive where your flutter projects located.

Sorry but this is not "the way to solve". This might be a temporary workaround but the solution is to fix this issue. We should obviously be allowed to put our folders anywhere we please, as was the case earlier, too.

The way to solve this is to move the pub cache folder to the same drive where your flutter projects located.

Sorry but this is not "the way to solve". This might be a temporary workaround but the solution is to fix this issue. We should obviously be allowed to put our folders anywhere we please, as was the case earlier, too.

I very agree, it should be allowed like it always has been. But sadly looks like it is not Flutter issue but a Gradle issue in their recent update. I don't exactly know why they need to be in same drive, but Flutter has always silently made cache folder exist in our AppData since the beginning. This is intentional and shouldn't be wrong at all like you said.

This issue still exists. Very annoying indeed!

This issue still exists

is there any update on this issue?

Apart from moving both directories to the same drive there is a simple workaround of creating a symbolic junction/link for your project directory
Assuming you have Pub cache in C drive and your project in D drive:

Create a hard symbolic link in C drive to your app directory using windows command prompt:

mklink /J C:\Development\your\project\directory\link D:\your\project\directory\real\path

Open the project in your IDEs from symbolic junction/link

C:\Development\your\project\directory\link instead of D:\your\project\directory\real\path

With this everything should work as expected, however if you open terminal in IntelliJ it might give you the real path instead of symbolic link, hence after opening terminal do

cd C:\Development\your\project\directory\link

If you are using any custom or forked local dependencies from a relative path not absolute path and these are also in D(or any other non Pub cache) drive then you will need to create symbolic links for these paths as well e.g.:

mklink /J C:\Development\Flutter\custom_dependencies D:\Development\Flutter\custom_dependencies

If you use PoweShell instead of windows command prompt then you need to use New-Item to create symbolic directory junction:
New-Item -ItemType Junction -Path "Link" -Target "Target"

This issue still exists

I faced the same issue and commenting out the following line in project level build.gradle worked for me!
subprojects {
//    project.buildDir = "${rootProject.buildDir}/${project.name}"
}


[BOT PR] to update dependencies of istio

This PR will be merged automatically once checks are successful.
none

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: istio-testing
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: hklai
If they are not already assigned, you can assign the PR to them by writing /assign @hklai in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@istio-testing: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
91f6e446a06687d56dd2321487800f2a9959558a
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@istio-testing: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
91f6e446a06687d56dd2321487800f2a9959558a
link
/test istio-unit-tests

prow/istio-pilot-multicluster-e2e.sh
91f6e446a06687d56dd2321487800f2a9959558a
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


cache invalidated building workspace members for default and explicit targets

Problem
Cargo's cache appears to be invalidated when building one workspace member with the default target followed by another workspace member with an explicit target.
Steps
Create a workspace with two crates, a and b. Make each workspace member depend on the "wasm-bindgen" crate.
Run cargo build --package a and cargo build --package b --target wasm32-unknown-unknown.
Now run cargo build --package a and observe that the build starts from scratch, rather than finishing immediately.
Caching does work as expected when the default target is explicitly specified. For example:
cargo build --package a --target x86_64-unknown-linux-gnu
cargo build --package b --target wasm32-unknown-unknown
cargo build --package a --target x86_64-unknown-linux-gnu

As a workaround, I currently use a separate target directory for wasm builds.
Output of cargo version: cargo 1.48.0 (65cbdd2dc 2020-10-14)

Hm, I'm not able to immediately reproduce the issue with the steps provided.
When it rebuilds, can you run cargo with the CARGO_LOG=cargo::core::compiler::fingerprint=trace environment variable set to print out some debug information that should indicate why it thinks it needed to rebuild.

@ehuss thanks, that helped. Cargo is reporting that rustflags have changed when I switch targets because I have the following in ~/.cargo/config.toml: target.x86_64-unknown-linux-gnu.rustflags = ["-C", "link-arg=-fuse-ld=lld"]. Removing that line resolves the issue, but is there some way that I can use LLD for the linux target while not triggering rebuilds by building for wasm?

I don't think so, you'll need to always pass --target (or use separate target directories).  It's kind of a long-standing issue that RUSTFLAGS without --target applies to build dependencies (#3739).  There's also #8716, which is to keep crates built with different flags isolated with different filenames, but there are some complications that make that difficult.

Thanks for the help. I will close this in favor of #8716.


Optimize collections create and delete

I want to merge this change because it optimizes collection create and delete mutations.
There is a big prefetch going on in these, which doesn't necessary needs to extend the mutation time. It could also make use of replicas which now it does (after deletion code, so should be safe replication-lag wise).
This is a port of https://github.com/saleor/saleor/pull/14941

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations

Docs

[ ] Link to documentation:

Pull Request Checklist

[ ] Privileged queries and mutations are either absent or guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migrations are either absent or optimized for zero downtime
[ ] The changes are covered by test cases
[ ] All new fields/inputs/mutations have proper labels added (ADDED_IN_X, PREVIEW_FEATURE, etc.)
[ ] All migrations have proper dependencies
[ ] All indexes are added concurrently in migrations
[ ] All RunSql and RunPython migrations have revert option defined

@IKarbowiak Added tests for product batching.


ProgressBar's knobBefore will not disappear when at value of 0

Issue details
A progress bar's knobBefore will not disappear when the Value is set to 0. Even after having made sure the minWidth of the knobBefore drawable was 0.
This issue seems to be related to c6b7119a53c94086ce04f07f62d2bf44f8cf0739
While Testing I made a subclass of ProgressBar and reverted the changes for Math.max(bgBottomHeight, position); back to Math.max(Math.min(0, bgBottomHeight), position);  and Math.max(bgLeftWidth, position); back to Math.max(Math.min(0, bgLeftWidth), position);  and it began to work as expected.
Reproduction steps/code
Made a simple barebones project. Using a skin with a just a drawable for the background and knobBefore.
ProgressBar min/max, 0 to 50, value set to 0;
Version of LibGDX and/or relevant dependencies
1.9.12, 1.9.13, 1.9.14 and 1.10.0

Please select the affected platforms

[x] Android
[x] iOS
[x] HTML/GWT
[x] Windows
[x] Linux
[x] MacOS

Duplicate? https://github.com/libgdx/libgdx/issues/6259

Duplicate? #6259

I came across this issue in my search. But the workaround suggested, didn't have any effect. The only solution so far, was reverting that last change I mentioned above. While it might be related, I thought it was at least worth placing the issue. As it's been here since at least 1.9.12

We first need to decide how before/after drawables should be shown. I guess they should be to the edge of the knob. Before:

After:

That allows knobs to have blank space on the left/right to let the before/after drawable show through.

Thanks Nate!
Just a follow up, stating that I've tried this change out in the latest snapshot and it fixed the issue.
Also, I would like to just chime in and say that one of the reasons I brought this issue up was that I've noticed a lot of people are told to use the ProgressBar actor as a way to quickly make character health/energy bars. And the issue with the knobBefore/knobAfter would nullify that. I know it's not the progress bar's main purpose. It's just nice to have, though.

Cool, thanks for verifying! A health bar is a perfect use for progress bar.


Added Hippo

Added Hippo, a standards checker with access to the AST and token stream.

@ziadoz rebased.

Hey, sorry to keep you waiting. If you rebate this again I'll get it merged.

Thanks for the suggestion.