cmd/compile, cmd/link: generate dwarf type info in compiler

Background
I have focused on dynamic link (plugin,linkshared,buildemode-shared)  in golang for two years. I noticed that the dynlink library can't be debuged. And I know that the reason of it is the dwarf type info is generated in linker.
Related issues:
https://github.com/golang/go/issues/38378
https://github.com/golang/go/issues/44982
Later, I saw this in https://github.com/golang/go/issues/47788#issuecomment-957967840.
@thanm said:

One thing we can do that would make the problem more tractable in general would be to move DWARF type DIE generation out of the linker and into the compiler (this is an idea that we've toyed with the in the past but haven't gotten to). Doing that would definitely help for the "link shared against libstd.so" use case.

Thanks for @thanm , I have tried to implement generating dwarf type info in compile for a long time. Now it can work,  though it is a very very initial version. I think it is the correct time to submit a proposal about it, and maybe I can improve it and contribute it to go community.
Proposal
The dwarf type info can be generated in compiler instead of linker. My initial version implement it with this way:

We can collect all the types (global var, local var, const and the type which runtime type should be keeped) used in current compile unit.
Do "defgotype" like the linker now. And we don't need to decode the infomation from binary like linker, we only need to get the info from types.Type struct in compile.
Synthesize map type, chan type and soon. Because some proto type (runtime.hchan, runtime.hmap...) are not in current compile unit, we must make some "stub" type of them.
Before dumpobj in compiler, convert all the type dies to LSym and put them to data section.

I will send a CL to share my very very initial  prototype.
If this proposal is a little likely to be accepted, I will implement it continue. I think thers is much things todo.
TODO:

Clarify the dwarf symbol name and type name.
Use aux sym for typedef sym instead of lookup it by name.
Investigate why fixedbugs/ssue30908.go failed. It seems like there is some different duplicate dwarf symbols.
Distinguish linkshared and static link. For  linkshared, generate completely dwarf types for every compile unit. For static link, only generate dwarf types that defined in current compile unit.Then the user who use -linkshared, They could debug the dynlink library.

Costs

What is the compile time cost?
Longer. But it will not much because of parallel compile. And maybe we can get a shorter link time.
What is the run time cost?
No cost.
Can you describe a possible implementation?
Above
Do you have a prototype? (This is not required.)
Yes.

Update 2022.5.10:
List an intial version todo list for formal modification:

[x] Implement some base interface for dwarf in compiler

CL 399294
CL 399059
CL 399063
CL 399064
CL 399301

[x] generate dwarf info sym for the type (except the type need to be synthesized) defined in current compile unit in compier.

CL 399302

[x] Create some type description for synthesize type in compiler, thus we can generate and synthesize more type info in compiler.

CL 399877

[x] add some util functiong for synthesizing type.

CL 399879
CL 399879
CL 399880
CL 405455

[x] synthesize ptr, hchan, hmap, string and slice in compiler.

CL 400137

[x] use the dwarf sym generated in compiler in linker.

CL 399275

[x] cleanup some redundancy and duplicate code

CL 400138

[x] generate whole dwarf type info in compiler for dynlink.

CL 400634
CL 404734

[x] do not generate the types which must be emited by runtime

CL 403334

[ ] add a new reloc type for using aux symbol for type info
[ ] refactor and optimize the DWDIE struct to reduce the pointer
[ ] unify the die create way in internal/dwarf
[x] add testcases for these cls

CL 404217
CL 404754
CL 404755

There is no user visible change here (except that debug info is better), so this doesn't have to go through the proposal process.  The linker/compiler/runtime team can decide what to do here.
CC @golang/runtime

I will send CL tree to implement it formally.

@thanm thanks for your reply. I'm glad to know it is a worthy project.
Now it can simply work with  CL 399275 (with some bugs I’m investigating)  and the relation chain of it. At this time, the dwarf type info is generated in both compiler and linker. In compiler, generate  the type difined in current compile unit except the synthesize type. In linker, generate all the others info. I will move the remaining step by step.
To avoid my idea is on the wrong track, Could you take a little look for the current patchsets ?It begin with CL 399059. Thanks very much.
I want to cleanups something, too. I didn't add duplicate code in compiler, I moved some code from linker to cmd/internal/dwarf. We can use them in both compiler and linker. In the future, it can be unified more easy.

To avoid my idea is on the wrong track, Could you take a little look for the current patchsets ?It begin with CL 399059. Thanks very much.

I took a very quick skim. In general looks to be moving in the right direction.
I am not sure about https://go-review.googlesource.com/c/go/+/399302 however-- what is the purpose of making DWARF type die symbols into aux symbols attached to type symbols? If the type DIE symbol is an aux, it means you can't look it up by name. This seems to me that it will force a lot of rewriting/post-processing in the linker.

it means you can't look it up by name.
Sorry, maybe I use a incorrect combine of aux and pkgDef for dwarf sym? It seems I can still look it up by name now. And I can also get them by aux of a type symbol.

what is the purpose of making DWARF type die symbols into aux symbols attached to type symbols?

According to the understanding I described above,  I hope that all the dwarf type can be collected by using aux sym of reachable gotype and traverse the relocs of them at last. May be it is more fast than name lookup.  In the future, maybe  no one need to look it up by name. At that time, I think the symbol name of them can be removed and put them in nonPkgDef set.
If I missed something which can prevent doing as this, I will put them in data.

It doesn't really make sense to have a symbol that is both aux and pkgdef -- the primary reason we make the other DWARF sub-symbols (ex: DWARFLINES, DWARFFCN) is that we never have to look them up by name.  Better to have the DWARF type DIE symbols just be regular named symbols.

The other thing I can't do with certainty is CL 399877. Should I do it like this? Or put them into cmd/compile/internal/typecheck/builtin, then fix mkbuiltin.go and deal with them by a common way? Could you give me some advice?

I'm not familiar with the DWARF or linker complexities here, but strictly from a cmd/compile point-of-view:

My first preference would be that the DWARF type descriptions are simply generated while compiling package runtime, derived from the real type descriptors. We already
If that's not doable, then extending mkbuiltin.go so that we have a single source of mock compiler definitions, seems preferable to keep everything in one place.
If there's technical reasons why the DWARF type descriptions need to be kept separate from the builtin prototypes, keeping it separate like that CL seems fine. (I don't think there's a need for nested internal packages though; and if there is, please do not use package internal.)

My first preference would be that the DWARF type descriptions are simply generated while compiling package runtime,

The dwarf type symbol can't be generated directly, a prototype is needed. As what now the linker do in src/cmd/link/internal/ld/dwarf.go:^synthesizeXXXtypes. A basic dwarf type for map, slice, chan and string will be generated in newtype. Then we need to synthesize the final dwarf info with the prototype of them. Maybe some implements can be simplifed in the future, but it seems we can't do this without the prototypes .

If that's not doable, then extending mkbuiltin.go so that we have a single source of mock compiler definitions,

Maybe some work need to be done for mkbuiltin.go before I add them to builtin. mkbuiltin.go can't support the complex struct type. I will try to fix it later. Now I will keep it as the CL do temporarily, For I can do synthesize  continue.

As what now the linker do in src/cmd/link/internal/ld/dwarf.go:^synthesizeXXXtypes.

It looks like that code is accessing the Go runtime type descriptor's for the actual declared types within package runtime?
If so, I don't see a need for those types to be added to cmd/compile/internal/typecheck/builtin/runtime.go or to any similar files.

It looks like that code is accessing the Go runtime type descriptor's for the actual declared types within package runtime?

If so, I don't see a need for those types to be added to cmd/compile/internal/typecheck/builtin/runtime.go or to any similar files. It should be sufficient that they're declared within runtime/*.go already.

In linker. it can access any symbol it need in all imported package and base package. If I move synthesizeXXXtypes to compiler, I need a mock type wich can describe these types. If not, for slice and string, they are simple enough, I can hard code and keep a relocation to runtime type for it. But for map and hchan, AFAIK, it is like the template in C++, I need to fill them when I generate these dwarf type in compiler.

It doesn't really make sense to have a symbol that is both aux and pkgdef -- the primary reason we make the other DWARF sub-symbols (ex: DWARFLINES, DWARFFCN) is that we never have to look them up by name. Better to have the DWARF type DIE symbols just be regular named symbols.

Thank you very much, it can work after I use them as regular symbols, and it is more easy than use them as aux symbols.

I met a tricky problem for me. This testcase can't pass, because some dwarf types are defined in more than one compileunit. Should I skip the SDWARFTYPE symbol in this check ?

# go run run.go -- fixedbugs/issue30908.go
exit status 1
cmd/link: while reading object for 'os': duplicate symbol 'go.info.*[]string', previous def at 'main', with mismatched payload: same length but different contents
cmd/link: while reading object for 'os': duplicate symbol 'go.info.*interface {}', previous def at 'main', with mismatched payload: same length but different contents
cmd/link: while reading object for 'io/fs': duplicate symbol 'go.info.*interface {}', previous def at 'main', with mismatched payload: same length but different contents
cmd/link: while reading object for 'io/fs': duplicate symbol 'go.info.*io/fs.DirEntry', previous def at 'os', with mismatched payload: same length but different contents
cmd/link: while reading object for 'io/fs': duplicate symbol 'go.info.*[]string', previous def at 'main', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime': duplicate symbol 'go.info.*error', previous def at 'os', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime': duplicate symbol 'go.info.*int64', previous def at 'os', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime': duplicate symbol 'go.info.*uintptr', previous def at 'os', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime': duplicate symbol 'go.info.*int32', previous def at 'io', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime': duplicate symbol 'go.info.*uint8', previous def at 'main', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime': duplicate symbol 'go.info.*uint16', previous def at 'io', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime': duplicate symbol 'go.info.*uint64', previous def at 'os', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime': duplicate symbol 'go.info.*float64', previous def at 'sort', with mismatched payload: same length but different contents
cmd/link: while reading object for 'sync': duplicate symbol 'go.info.*uint32', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'syscall': duplicate symbol 'go.info.*unsafe.Pointer', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'syscall': duplicate symbol 'go.info.*syscall.Timespec', previous def at 'os', with mismatched payload: same length but different contents
cmd/link: while reading object for 'syscall': duplicate symbol 'go.info.*uint32', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'internal/poll': duplicate symbol 'go.info.*syscall.Sockaddr', previous def at 'syscall', with mismatched payload: same length but different contents
cmd/link: while reading object for 'internal/poll': duplicate symbol 'go.info.*syscall.Iovec', previous def at 'syscall', with mismatched payload: same length but different contents
cmd/link: while reading object for 'time': duplicate symbol 'go.info.*time.Duration', previous def at 'os', with mismatched payload: same length but different contents
cmd/link: while reading object for 'time': duplicate symbol 'go.info.*time.Time', previous def at 'os', with mismatched payload: same length but different contents
cmd/link: while reading object for 'time': duplicate symbol 'go.info.*[]uint8', previous def at 'main', with mismatched payload: same length but different contents
cmd/link: while reading object for 'time': duplicate symbol 'go.info.*uint32', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'io/ioutil': duplicate symbol 'go.info.*[]io/fs.FileInfo', previous def at 'os', with mismatched payload: same length but different contents
cmd/link: while reading object for 'internal/reflectlite': duplicate symbol 'go.info.**uint8', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'internal/reflectlite': duplicate symbol 'go.info.*internal/reflectlite.Value', previous def at 'sort', with mismatched payload: same length but different contents
cmd/link: while reading object for 'internal/reflectlite': duplicate symbol 'go.info.*unsafe.Pointer', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'internal/reflectlite': duplicate symbol 'go.info.*int16', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'internal/cpu': duplicate symbol 'go.info.*uint32', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime/internal/atomic': duplicate symbol 'go.info.*uint32', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'runtime/internal/atomic': duplicate symbol 'go.info.*unsafe.Pointer', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'internal/abi': duplicate symbol 'go.info.*unsafe.Pointer', previous def at 'runtime', with mismatched payload: same length but different contents
cmd/link: while reading object for 'strings': duplicate symbol 'go.info.*uint32', previous def at 'runtime', with mismatched payload: same length but different contents

FAIL    fixedbugs/issue30908.go 1.179s

This testcase can't pass, because some dwarf types are defined in more than one compileunit

This looks like an actual bug to me.  We expect content to match for dupok symbols (if not, it's nearly always an indication of a real problem).
DWARF type die symbols should follow the same rules that type descriptor symbols do, with respect to where they are defined and whether they are emitted as "dupok".
For named types, what we want is for the compiler to emit type DIE symbol definition only only for things defined in the package. These should be regular symbols, not dupok symbols (since by construction each package has a distinct package path).
For non-named, types, like the "[13]complex16" below, when compiling package "foo" we have to allow for the possibility of some other package also having a variable of "[13]complex64" type, so the strategy would be to emit an appropriately named DWARF type DIE symbol but make it dupok.
  package foo

  var X [13]complex16

In addition:
For type descriptor symbols, the compiler has a hard-coded set of very basic, common types that it only emits definitions for when building the runtime. So for example when you compile some other package (not the runtime) and the compiler needs to refer to "type.uint8", it just emits a reference and assumes that the runtime will have a definition of that type descriptor symbol.    DWARF generation should work the same way-- when compiling the "syscall" package (for example), the compiler should not be emitting a DWARF type DIE symbol like "go.info.*uint32", since that DIE will be defined by the runtime.
See https://go.googlesource.com/go/+/b55a2fb3b0d67b346bac871737b862f16e5a6447/src/cmd/compile/internal/reflectdata/reflect.go#1394 (related).
Let me know if this makes sense. These sorts of issues are normally hashed out during a design review or as part of discussion/comment on design doc, but that sort of got sidestepped in this case.

@thanm, I'm not sure I followed your explanation of why the DWARF type DIEs shouldn't be aux symbols. To me it seems pretty natural that, since the type descriptor symbols already have the naming and dupok properties we need, that we should just hang the DWARF equivalent off the type descriptor symbol. You mentioned that this would require a lot of post-processing in the linker; what sort of post-processing were you concerned about?

Consider this package:
package bar

type X [99]uint64

func A(p1 X) uint64 {
	return p1[0]
}

Compiler generates this as a DWARF subprogram DIE for "A":
aux for "".A<0> SDWARFFCN size=55
	0x0000 03 62 61 64 2e 41 00 00 00 00 00 00 00 00 00 00  .bad.A..........
	0x0010 00 00 00 00 00 00 00 01 9c 02 00 00 00 01 11 70  ...............p
	0x0020 31 00 00 05 00 00 00 00 01 9c 11 7e 72 30 00 01  1..........~r0..
	0x0030 05 00 00 00 00 00 00                             .......
	rel 0+0 t=22 type.uint64<0>+0
	rel 7+8 t=1 "".A<1>+0
	rel 15+8 t=1 "".A<1>+6
	rel 36+4 t=31 go.info."".X<0>+0
	rel 49+4 t=31 go.info.uint64<0>+0

In the initial set of patches sent by zhouguangyuan0718@, type DIEs were being emitted as aux symbols attached to type descriptor symbols. However subprogram DIE generation was unchanged (param types were still references to "go.info.<type>".  In the code above you can see relocs against go.info."".X and go.info.uint64. If the type DIE for the type "X" is an aux symbol (and not a named pkgdef symbol) then we would have to have some sort of fixup phase in the linker that would take convert the go.info."".X reference and rewrite it to the aux symbol. Or something like that.
Let me know if this answers your question.

Thanks for the explanation. Clearly we wouldn't be able to reference the "go.info.X" symbols like that if the type DIEs are in aux symbols, but that seems like more a problem with the references than with the idea of using aux symbols. Wouldn't it work to have a new relocation type that's like R_DWARFSECREF, but that references the Go type descriptor and resolves to the DWARF offset of its type DIE? Or is that just more complicated than having a parallel set of named symbols for the type DIEs? (In general I'm just weary of anything that depends on name lookups in the linker.)

Wouldn't it work to have a new relocation type that's like R_DWARFSECREF, but that references the Go type descriptor and resolves to the DWARF offset of its type DIE?

Cool idea, yeah, that seems like it could work. Of course all of those relocations would have to be treated specially by the linker (since it's a sort of "wink wink nudge nudge, I'm pointing to X but really to Y"), but it sounds doable.

@thanm Thanks for your advising. I did not concern the dupok of type description before. I will try it.
About aux symbol, at the beginning, I hope that the type die sum can be find out by both type description and name. But seems it is not a normal way. So, I make them as regular named symbol and access them by name and reloc. It works well except the bug above.

Wouldn't it work to have a new relocation type that's like R_DWARFSECREF, but that references the Go type descriptor and resolves to the DWARF offset of its type DIE?

Cool idea, yeah, that seems like it could work. Of course all of those relocations would have to be treated specially by the linker (since it's a sort of "wink wink nudge nudge, I'm pointing to X but really to Y"), but it sounds doable.

It's an interesting way. But what I worry about is for dynamic link. For dynamic link. We don't have all the type symbol in linker. I know dynamic link is not a common case. But the original purpose to do this is to resolve the dynlink lib and exe. So I hope I can do this with a balanced solution.

This looks like an actual bug to me. We expect content to match for dupok symbols (if not, it's nearly always an indication of a real problem).

I misunderstood whe this testcase mean before. I found out the main reason of the failure is that the ptr die sym defined by DefPtrTo missed DW_AT_go_kind attributes  before. It missed it in linker before my patchset. It is no effect in linker. But in compiler, because of duplicate gereration, it failed. I fixed it in compiler in my patchset, it seems works well now.I will send a separate CL to fix it in linker for mater branch later.

@thanm Thanks for your advising. I did not concern the dupok of type description before. I will try it.

Besides above, the patchset is done as what you advised about the dupok property. The dwarf type die inherited the dupok propety from the correspond type description.
And I mark the ptr defined by DefPtrTo and the internal type of hchan and hmap as dupok. Because I think they are unnamed, too. Am I misunderstand?

Let me know if this makes sense.

@thanm Yes, It cleared my confusion about the tricky symbols. And it works well now.
The newest patchset when I write this comment is patchset 5 of CL 400137. It contains what I'm writing in this comment.
In the next steps, besides what I list in the content of this issue. I'm planing to do some functional cleanups and refactor.

eliminate some symbols which WriteBasicTypes has dumped in runtime.
Try to add a new reloc type and use aux symbol for dwarf type die for static link.

But before I continue to do these and ready to review.  I hope I can make sure the patchset now is correct and works well on more builders. I can only run all.bash on my windows machine and wsl on it.  Could you help me run trybots on the newest patchset? It would be better if I could get get the try-bots access in issue #52249.

@thanm, now all the CL I has sent is already workable. I will do the others for this issue continue and change these CL
s not too much. If there is some no functional refactor I need to do, I hope I can do it at the cleanup CL at the end of them.
So,  could you start to review them? Or do you need I do some compress for the CLs?
There is some temporary code mixed in them. It is a little  confusing. they are already removed at the top CLs. But if I keep it as it is, you can understand the details in the CLs more clearly.

I'll try to free up some time to review in the next couple of days (my queue is a bit full at the moment).

@mdempsky Sorry, maybe my explanation in https://github.com/golang/go/issues/52209#issuecomment-1097475287 is not detailed enough.
Consider this code:
package main

import "fmt"

func main() {
	m := make(map[int]int)
	m[1] = 1
	fmt.Println(m)
}

I build it use go1.17 and then use readelf -wi to decode the dwarf info. Then we can find that the dwarf type info of map[int]int is more than what we can see in language level. I have excerpted key information：

 <1><69112>: Abbrev Number: 32 (DW_TAG_typedef)
    <69113>   DW_AT_name        : map[int]int
    <6911f>   DW_AT_type        : <0x6ca7f>
    <69123>   Unknown AT value: 2900: 21
    <69124>   Unknown AT value: 2904: 0x9680
    <6912c>   Unknown AT value: 2901: <0x5800c>
    <69130>   Unknown AT value: 2902: <0x5800c>

In dwarf info, the type map[int]int is a typedef the actual type is *hash<int,int>:

<1><6ca7f>: Abbrev Number: 33 (DW_TAG_pointer_type)
    <6ca80>   DW_AT_name        : *hash<int,int>
    <6ca8f>   DW_AT_type        : <0x6c9e5>
    <6ca93>   Unknown AT value: 2900: 0
    <6ca94>   Unknown AT value: 2904: 0x0

*hash<int,int> is a pointer to  hash<int,int>.

<1><6c9e5>: Abbrev Number: 37 (DW_TAG_structure_type)
    <6c9e6>   DW_AT_name        : hash<int,int>
    <6c9f4>   DW_AT_byte_size   : 48
    <6c9f5>   Unknown AT value: 2900: 0
    <6c9f6>   Unknown AT value: 2904: 0x0
 <2><6c9fe>: Abbrev Number: 22 (DW_TAG_member)
    <6c9ff>   DW_AT_name        : count
    <6ca05>   DW_AT_data_member_location: 0
    <6ca06>   DW_AT_type        : <0x5800c>
    <6ca0a>   Unknown AT value: 2903: 0
 <2><6ca0b>: Abbrev Number: 22 (DW_TAG_member)
    <6ca0c>   DW_AT_name        : flags
    <6ca12>   DW_AT_data_member_location: 8
    <6ca13>   DW_AT_type        : <0x5790d>
    <6ca17>   Unknown AT value: 2903: 0
 <2><6ca18>: Abbrev Number: 22 (DW_TAG_member)
    <6ca19>   DW_AT_name        : B
    <6ca1b>   DW_AT_data_member_location: 9
    <6ca1c>   DW_AT_type        : <0x5790d>
    <6ca20>   Unknown AT value: 2903: 0
 <2><6ca21>: Abbrev Number: 22 (DW_TAG_member)
    <6ca22>   DW_AT_name        : noverflow
    <6ca2c>   DW_AT_data_member_location: 10
    <6ca2d>   DW_AT_type        : <0x57b38>
    <6ca31>   Unknown AT value: 2903: 0
 <2><6ca32>: Abbrev Number: 22 (DW_TAG_member)
    <6ca33>   DW_AT_name        : hash0
    <6ca39>   DW_AT_data_member_location: 12
    <6ca3a>   DW_AT_type        : <0x578e0>
    <6ca3e>   Unknown AT value: 2903: 0
 <2><6ca3f>: Abbrev Number: 22 (DW_TAG_member)
    <6ca40>   DW_AT_name        : buckets
    <6ca48>   DW_AT_data_member_location: 16
    <6ca49>   DW_AT_type        : <0x6c9c6>
    <6ca4d>   Unknown AT value: 2903: 0
 <2><6ca4e>: Abbrev Number: 22 (DW_TAG_member)
    <6ca4f>   DW_AT_name        : oldbuckets
    <6ca5a>   DW_AT_data_member_location: 24
    <6ca5b>   DW_AT_type        : <0x6c9c6>
    <6ca5f>   Unknown AT value: 2903: 0
 <2><6ca60>: Abbrev Number: 22 (DW_TAG_member)
    <6ca61>   DW_AT_name        : nevacuate
    <6ca6b>   DW_AT_data_member_location: 32
    <6ca6c>   DW_AT_type        : <0x57809>
    <6ca70>   Unknown AT value: 2903: 0
 <2><6ca71>: Abbrev Number: 22 (DW_TAG_member)
    <6ca72>   DW_AT_name        : extra
    <6ca78>   DW_AT_data_member_location: 40
    <6ca79>   DW_AT_type        : <0x5e068>
    <6ca7d>   Unknown AT value: 2903: 0
 <2><6ca7e>: Abbrev Number: 0

hash<int,int> is a struct, actually it is runtime.hmap. In  hash<int,int>, it reference the type  *bucket<int,int> by field buckets and oldbuckets.

 <1><6c9c6>: Abbrev Number: 33 (DW_TAG_pointer_type)
    <6c9c7>   DW_AT_name        : *bucket<int,int>
    <6c9d8>   DW_AT_type        : <0x6c96f>
    <6c9dc>   Unknown AT value: 2900: 0
    <6c9dd>   Unknown AT value: 2904: 0x0

*bucket<int,int> is a pointer to bucket<int,int>.

 <1><6c96f>: Abbrev Number: 37 (DW_TAG_structure_type)
    <6c970>   DW_AT_name        : bucket<int,int>
    <6c980>   DW_AT_byte_size   : 144
    <6c982>   Unknown AT value: 2900: 0
    <6c983>   Unknown AT value: 2904: 0x0
 <2><6c98b>: Abbrev Number: 22 (DW_TAG_member)
    <6c98c>   DW_AT_name        : tophash
    <6c994>   DW_AT_data_member_location: 0
    <6c995>   DW_AT_type        : <0x5bfb2>
    <6c999>   Unknown AT value: 2903: 0
 <2><6c99a>: Abbrev Number: 22 (DW_TAG_member)
    <6c99b>   DW_AT_name        : keys
    <6c9a0>   DW_AT_data_member_location: 8
    <6c9a1>   DW_AT_type        : <0x6c92d>
    <6c9a5>   Unknown AT value: 2903: 0
 <2><6c9a6>: Abbrev Number: 22 (DW_TAG_member)
    <6c9a7>   DW_AT_name        : values
    <6c9ae>   DW_AT_data_member_location: 72
    <6c9af>   DW_AT_type        : <0x6c94e>
    <6c9b3>   Unknown AT value: 2903: 0
 <2><6c9b4>: Abbrev Number: 22 (DW_TAG_member)
    <6c9b5>   DW_AT_name        : overflow
    <6c9be>   DW_AT_data_member_location: 136
    <6c9c0>   DW_AT_type        : <0x6c9c6>
    <6c9c4>   Unknown AT value: 2903: 0
 <2><6c9c5>: Abbrev Number: 0

bucket<int,int> is a struct, actually it is runtime.bmap. It reference []key and []val by field keys and vals.

 <1><6c92d>: Abbrev Number: 28 (DW_TAG_array_type)
    <6c92e>   DW_AT_name        : []key<int>
    <6c939>   DW_AT_type        : <0x5800c>
    <6c93d>   DW_AT_byte_size   : 64
    <6c93e>   Unknown AT value: 2900: 0
    <6c93f>   Unknown AT value: 2904: 0x0
 <2><6c947>: Abbrev Number: 25 (DW_TAG_subrange_type)
    <6c948>   DW_AT_type        : <0x57809>
    <6c94c>   DW_AT_count       : 8
 <2><6c94d>: Abbrev Number: 0

<1><6c94e>: Abbrev Number: 28 (DW_TAG_array_type)
    <6c94f>   DW_AT_name        : []val<int>
    <6c95a>   DW_AT_type        : <0x5800c>
    <6c95e>   DW_AT_byte_size   : 64
    <6c95f>   Unknown AT value: 2900: 0
    <6c960>   Unknown AT value: 2904: 0x0
 <2><6c968>: Abbrev Number: 25 (DW_TAG_subrange_type)
    <6c969>   DW_AT_type        : <0x57809>
    <6c96d>   DW_AT_count       : 8
 <2><6c96e>: Abbrev Number: 0

[]key and []val are array of int.

 <1><5800c>: Abbrev Number: 27 (DW_TAG_base_type)
    <5800d>   DW_AT_name        : int
    <58011>   DW_AT_encoding    : 5     (signed)
    <58012>   DW_AT_byte_size   : 8
    <58013>   Unknown AT value: 2900: 2
    <58014>   Unknown AT value: 2904: 0x68c0

We can see that the runtime.hmap and runtime.bmap are like template types,  every instantiate type has different name. Particularly the bucket<T,T>(runtime.bmap), []valand[]key`, the size of them will be affected by the elem type.
So, without prototype of  of runtime.hmap and runtime.bmap, it is a little diffcult to generate whole type info in compiler.
Without them , we need to hard code the prototype in compiler dwarf generation, or do some post process in linker,  or keep linker generate as it is.
 In linker, these symbols only need to be reloced and then put them to dwarf info section directly. We can't implement this only rely to these type defined in runtime compile unit. It is same for runtime.hchan.
Maybe I can hard code string and slice, they are simple enough and is not a template.

Thanks. The compiler already has code for synthesizing runtime type descriptors for map types though. For example: https://github.com/golang/go/blob/master/src/cmd/compile/internal/reflectdata/reflect.go#L199
Can we just reuse those type descriptions?
Alternatively, can we just using DW_TAG_typedef to cross-reference bucket<int,int> to runtime.bmap? I suppose that loses information like the keys and elems fields, but are those important to DWARF users?

Thanks. The compiler already has code for synthesizing runtime type descriptors for map types though. For example: https://github.com/golang/go/blob/master/src/cmd/compile/internal/reflectdata/reflect.go#L199
Can we just reuse those type descriptions?

I noticed these type descriptions before. For map, I think we can synthesize all the info from these. And the rusult can be as same as linker generate now.

Alternatively, can we just using DW_TAG_typedef to cross-reference bucket<int,int> to runtime.bmap? I suppose that loses information like the keys and elems fields, but are those important to DWARF users

I I'm afraid we can't, this is a change for  DWARF users, I can't determine, maybe CC @thanm .
And a more important reason is the difference of instances is not only the name of it, the size of bucket<T,T> is different,too.
This  bucket<string,string>, the size and offest of it is different with  bucket<int,int> in previous  comment.

 <1><64bcb>: Abbrev Number: 39 (DW_TAG_structure_type)
    <64bcc>   DW_AT_name        : bucket<string,string>
    <64be2>   DW_AT_byte_size   : 272
    <64be4>   Unknown AT value: 2900: 0
    <64be5>   Unknown AT value: 2904: 0x0
 <2><64bed>: Abbrev Number: 24 (DW_TAG_member)
    <64bee>   DW_AT_name        : tophash
    <64bf6>   DW_AT_data_member_location: 0
    <64bf7>   DW_AT_type        : <0x649c7>
    <64bfb>   Unknown AT value: 2903: 0
 <2><64bfc>: Abbrev Number: 24 (DW_TAG_member)
    <64bfd>   DW_AT_name        : keys
    <64c02>   DW_AT_data_member_location: 8
    <64c03>   DW_AT_type        : <0x64c29>
    <64c07>   Unknown AT value: 2903: 0
 <2><64c08>: Abbrev Number: 24 (DW_TAG_member)
    <64c09>   DW_AT_name        : values
    <64c10>   DW_AT_data_member_location: 136
    <64c12>   DW_AT_type        : <0x64c4e>
    <64c16>   Unknown AT value: 2903: 0
 <2><64c17>: Abbrev Number: 24 (DW_TAG_member)
    <64c18>   DW_AT_name        : overflow
    <64c21>   DW_AT_data_member_location: 264
    <64c23>   DW_AT_type        : <0x64ba6>
    <64c27>   Unknown AT value: 2903: 0
 <2><64c28>: Abbrev Number: 0

Now, I have refactored https://go-review.googlesource.com/c/go/+/399877. Not add a new mkprototype.go anymore. I extend the mkbuiltin.go and use the type description in pseudo runtime package. Now I think it is cleaner than before.
And I think and think how can we synthesize them with adding any hack things to compiler.  If I can absolutely not add anything like this.
For slice, string, iface and eface,  they can be esaily hard code when we need creating a die for them.
For map, we can get all the info from the description compiler already synthesized before.
But for chan,  there will be some change in the build result inevitably. compiler did't synthesize anything for it, we only have a runtime type description. So, we can't synthesize a die as it was. But I noticed that there is only one variable int hchan, waitq, sudog. It is the elem of  runtime.sudog,  I think it is not worthy to keep it as a templete type, we can use a directly typedef to define any chan T as  runtime.hchan .  And if I do as this, the dynamic link will loses dwarf type info for chan, I think it is not a good way. Certainly, I can't determine,too. CC @thanm.
I hope that I can keep the behaviors of dwarf not change and only add dynamic link support in this issue. Certainly, If I can absolutely not add anything in mkbuiltin.go.  I will do as this anymore.

Hi! @thanm , I have refactored my work tree. I remove much transitional code. And make changes aggregated in every cl. I think it will be more easy to review.
Now, I think all the tasks I marked in the content of this issue are done and they are ready to be reviewed. You can review them if you are available sometimes. I will do the remain tasks continue. Thank you.

Thanks.  I'll take a look once I clear up some time.

I'll take a look once I clear up some time.

Still tied up with pre-release-freeze development work. Hope to look at this next week.

I'll take a look once I clear up some time.

Still tied up with pre-release-freeze development work. Hope to look at this next week.

Thanks, and I wonder if it is possible to be merged into 1.19? If it is possible, I will do the remain things as soon as possible.

@thanm , Sorry for delay. I have rebased and solved confliction. Then I solved some comments. Can we continue to review these and make it more closer to merging?

@thanm @mdempsky Could we continue to review these and make it more closer to merging? Or which patch do you think that I need to refactor it?

One observation is that all of the types of a go program appear in compile units called runtime. Is there any intention to associate the types with the compile unit that exists for the package? If so, would that be covered by this work?


No reaction from E-Mail address provided in chrome web store

Hello UI5 Inspector Team,
on 20th of August 2020 I've sent an E-Mail to<EMAIL_ADDRESS>which is the one linked in the chrome web store
https://chrome.google.com/webstore/detail/ui5-inspector/bebecogbafbighhaildooiibipcnbngo
listing behind "Contact Developer". Unfortunately I haven't received any reply. Perhaps it would be better to link to the GitHub issues instead.
Best regards
Gregor

Hello @gregorwolf,
The Google Chrome Webstore requires an email to create and account. This is also another organisation's email - the one that manages the SAP account in this respective store and colleagues are not specialised in UI5 Inspector.
For anything else, please contact us via the issues here and we will try our best to help.
Thanks and best regards,
Jordan


Invalid conversion from runtime type String to Decimal

Hi I've just installed version 1.0.38 (namespaced) and am getting the below error when run from the Recalculation button or via the Recalculated Rollup tab:
17:57:55.0 (220478232)|SOQL_EXECUTE_BEGIN|[51]|Aggregations:0|SELECT owner_count__c,id,admin_count__c,CurrencyIsoCode
FROM Contact
WHERE Id = :objIds
17:57:55.0 (227549898)|SOQL_EXECUTE_END|[51]|Rows:1
17:57:55.0 (233552885)|USER_DEBUG|[74]|INFO|Rollup v1.5.65: starting rollup for:
Type: please.RollupAsyncProcessor.QueueableProcessor
Invocation Point: FROM_SINGULAR_PARENT_RECALC_LWC
Is Full Recalc: true
Is No Op: false
Is Conductor: false
Inner rollups: 0
Rollup Metadata: {
  "attributes" : {
    "type" : "please__Rollup__mdt",
    "url" : "/services/data/v58.0/sobjects/please__Rollup__mdt/m0K3H0000008Y6JUAU"
  },
  "please__LookupFieldOnLookupObject__c" : "Id",
  "please__RollupControl__c" : "m0B3H00000009ffUAA",
  "please__ShouldRunWithoutCustomSettingEnabled__c" : false,
  "please__SplitConcatDelimiterOnCalcItem__c" : false,
  "please__CalcItem__c" : "PlanContactRelation__c",
  "please__CalcItemWhereClause__c" : "Role__c = 'Owner' AND Contact__c = '0033H00000bYrbHQAS'",
  "MasterLabel" : "Owner Count To Contact",
  "please__RollupOperation__c" : "COUNT",
  "please__RollupFieldOnLookupObject__c" : "Owner_Count__c",
  "please__GroupByFields__c" : "Role__c",
  "please__IsRollupStartedFromParent__c" : false,
  "please__IsTableFormatted__c" : false,
  "please__RollupFieldOnCalcItem__c" : "Id",
  "please__IsFullRecordSet__c" : true,
  "please__LookupObject__c" : "Contact",
  "please__LookupFieldOnCalcItem__c" : "Contact__c",
  "Id" : "m0K3H0000008Y6JUAU",
  "DeveloperName" : "Owner_Count_To_Contact",
  "please__RollupToUltimateParent__c" : false,
  "please__SharingMode__c" : "System"
}
Rollup Control: {
  "attributes" : {
    "type" : "please__RollupControl__mdt",
    "url" : "/services/data/v58.0/sobjects/please__RollupControl__mdt/m0B3H00000009ff"
  },
  "please__BatchChunkSize__c" : 200,
  "please__TriggerOrInvocableName__c" : null,
  "please__MaxLookupRowsBeforeBatching__c" : 1000,
  "Label" : "Connect Team Membership Rollups",
  "please__MaxRollupRetries__c" : 10,
  "please__ShouldRunAs__c" : "Synchronous Rollup",
  "MasterLabel" : "Connect Team Membership Rollups",
  "Language" : "en_US",
  "please__ReplaceCalcItemsAsyncWhenOverCount__c" : 1,
  "please__IsDevEdOrTrialOrg__c" : false,
  "please__MaxNumberOfQueries__c" : 50,
  "please__MaxParentRowsUpdatedAtOnce__c" : 200,
  "DeveloperName" : "Connect_Team_Membership_Rollups",
  "please__IsRollupLoggingEnabled__c" : true,
  "NamespacePrefix" : null,
  "please__OnlyRunInFlowContexts__c" : null,
  "please__IsMergeReparentingEnabled__c" : true,
  "please__ShouldDuplicateRulesBeIgnored__c" : false,
  "please__ShouldRunSingleRecordsSynchronously__c" : false,
  "SystemModstamp" : "2023-05-18T16:57:49.000+0000",
  "please__ShouldAbortRun__c" : false,
  "QualifiedApiName" : "Connect_Team_Membership_Rollups",
  "please__MaxQueryRows__c" : 25000,
  "Id" : "m0B3H00000009ff",
  "please__ShouldSkipResettingParentFields__c" : false
}
Calc Items: [ {
  "attributes" : {
    "type" : "PlanContactRelation__c",
    "url" : "/services/data/v58.0/sobjects/PlanContactRelation__c/a0R3H000000jeX3UAI"
  },
  "Id" : "a0R3H000000jeX3UAI",
  "Contact__c" : "0033H00000bYrbHQAS",
  "Role__c" : "Owner",
  "CurrencyIsoCode" : "GBP"
}, {
  "attributes" : {
    "type" : "PlanContactRelation__c",
    "url" : "/services/data/v58.0/sobjects/PlanContactRelation__c/a0R3H000000jeX8UAI"
  },
  "Id" : "a0R3H000000jeX8UAI",
  "Contact__c" : "0033H00000bYrbHQAS",
  "Role__c" : "Admin",
  "CurrencyIsoCode" : "GBP"
}, {
  "attributes" : {
    "type" : "PlanContactRelation__c",
    "url" : "/services/data/v58.0/sobjects/PlanContactRelation__c/a0R3H000000jlUEUAY"
  },
  "Id" : "a0R3H000000jlUEUAY",
  "Contact__c" : "0033H00000bYrbHQAS",
  "Role__c" : "Admin",
  "CurrencyIsoCode" : "GBP"
} ]
Full Recalc Processor: "please.RollupDeferredFullRecalcProcessor"
Is Processed?: true
Class.please.RollupAsyncProcessor.process: line 671, column 1
Class.please.RollupAsyncProcessor.runCalc: line 291, column 1
Class.please.Rollup.batch: line 2366, column 1
Class.please.Rollup.performSerializedBulkFullRecalc: line 577, column 1

17:57:55.0 (242954562)|SOQL_EXECUTE_BEGIN|[62]|Aggregations:0|SELECT Count()
FROM PlanContactRelation__c
WHERE Id != :objIds
AND Contact__c = :recordIds
17:57:55.0 (248394452)|SOQL_EXECUTE_END|[62]|Rows:0
17:57:55.0 (249562654)|USER_DEBUG|[74]|DEBUG|Rollup v1.5.65: Returned amount: 0
SELECT Count()
FROM PlanContactRelation__c
WHERE Id != :objIds
AND Contact__c = :recordIds
Bind keys: {objIds, recordIds}
Access level: SYSTEM_MODE
Class.please.RollupRepository.createQueryLog: line 78, column 1
Class.please.RollupRepository.getCount: line 69, column 1
Class.please.RollupAsyncProcessor.retrieveAdditionalCalcItems: line 576, column 1
Class.please.RollupAsyncProcessor.getUpdatedLookupItemsByRollup: line 1179, column 1
Class.please.RollupAsyncProcessor.process: line 672, column 1
Class.please.RollupAsyncProcessor.runCalc: line 291, column 1
Class.please.Rollup.batch: line 2366, column 1
Class.please.Rollup.performSerializedBulkFullRecalc: line 577, column 1

17:57:55.0 (283904937)|EXCEPTION_THROWN|[518]|System.TypeException: Invalid conversion from runtime type String to Decimal
17:57:55.0 (284000453)|SYSTEM_MODE_EXIT|true
17:57:55.0 (284255566)|FATAL_ERROR|System.TypeException: Invalid conversion from runtime type String to Decimal

Class.please.RollupCalculator.DecimalRollupCalculator.setDefaultValues: line 518, column 1
Class.please.RollupCalculator.GroupByCalculator.performRollup: line 1342, column 1
Class.please.RollupAsyncProcessor.getCalculator: line 1308, column 1
Class.please.RollupAsyncProcessor.getUpdatedLookupItemsByRollup: line 1213, column 1
Class.please.RollupAsyncProcessor.process: line 672, column 1
Class.please.RollupAsyncProcessor.runCalc: line 291, column 1
Class.please.Rollup.batch: line 2366, column 1
Class.please.Rollup.performSerializedBulkFullRecalc: line 577, column 1
17:57:55.0 (284293341)|FATAL_ERROR|System.TypeException: Invalid conversion from runtime type String to Decimal

Here are my CMDTs:

Do you have any ideas on what is causing this?
Thanks!

This may be an actual bug, but I think for your purposes all you need to do to get this working is remove Role__c from the Group By fields. You aren't trying to do a group by rollup - which basically spits out text grouping by the field in question - and I know that because the where clause you're using for each of these rollups is specific to one role each.

Hi James thanks for the advice. I’ve tried with and without the role
grouping and it didn’t fix it. I’ll try again tomorrow and report back.
On Thu, 18 May 2023 at 18:49, James Simone @.***> wrote:

This may be an actual bug, but I think for your purposes all you need
to do to get this working is remove Role__c from the Group By fields. You
aren't trying to do a group by rollup - which basically spits out text
grouping by the field in question - and I know that because the where
clause you're using for each of these rollups is specific to one role each.
—
Reply to this email directly, view it on GitHub
https://github.com/jamessimone/apex-rollup/issues/443#issuecomment-1553408515,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4CBU7PNJSGVLKAUELJRZTXGZOK5ANCNFSM6AAAAAAYGXBJ7Q
.
You are receiving this because you authored the thread.Message ID:
@.***>

@garymscott if you are doing this from a full recalc app page, you need to refresh the page after updating the custom metadata values. The values are cached when the page loads. You should be all set - closing this for now.

Hi James you were absolutely right I was running into caching issues so didn't consider the grouping to be an issue when actually it was. Thanks again for your help!


hope some clarification about current design

Hi Snowfork team,
First thanks for the open source project and great job you've done, much appreciated.  Recently I've read some of the docs/codes and still have some questions and look forward clarification from your team.
My understanding for the substrate->ethereum bridge there are 2 rounds of verification including:

verify Relay Chain MMR roots signed by the correct set of Polkadot validators

uses Parachain Commitments to verify individual bridge messages

and for the first round of beefy verification we also need 2 phase commit
newSignatureCommitment
completeSignatureCommitment
My question are:

since beefy commitment already contains the required information such as mmr root and all signatures which we can verify easily in BeefyLightClient contract, will one step of SignatureCommitment  enough? what is the benifit of such 2 phase commit design?

from the current implementation seems required SignatureCommitment threshhold will be met only as 12%%, is that safe enough for the verification?

notice the incencitive channel charging from sender will pay for the honest worker, is there any punishment mechanism for the dishonest ones or just be unintentionally offline and fail it's duty?  could anyone run as relay worker?

1 - much cheaper
2 - yes, will be sharing docs on this in time
3 - it is not possible to be dishonest, the tx will be rejected if so. and yes anyone can run it
in future please feel free to ping us on our Element channel for general questions, rather than creating Github issues: https://matrix.to/#/%23snowbridge:matrix.org

@musnit  Get your point, first convert the initial signature array to some folded bit set array to save storage resource, and in second phase only sample some required signatures to save computing resource.  Really nice design!
Btw, notice this doc which may cover some details , but seems something wrong with the formula typesetting.
Ok, I would seek help from element channel from now on. Thanks for your reply again.


Crash during boot time on Mac OS 10.12.6

Hi. DNSCrypt ver 1.0.14 worked fine for several months. Today, after reboot i got the crash report, see below. There is the string 'BSD process name corresponding to current thread: dnscrypt-proxy'. Maybe something  wrong in your code?
Mon Dec  4 09:47:15 2017

*** Panic Report ***
panic(cpu 3 caller 0xffffff801f7c7e65): "soclose: NOFDREF"@/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.71.6/bsd/kern/uipc_socket.c:1406
Backtrace (CPU 3), Frame : Return Address
0xffffff912c5b3d90 : 0xffffff801f2ea56c
0xffffff912c5b3e10 : 0xffffff801f7c7e65
0xffffff912c5b3e60 : 0xffffff801f7c82ba
0xffffff912c5b3e80 : 0xffffff801f7c85b4
0xffffff912c5b3ec0 : 0xffffff801f7d874c
0xffffff912c5b3f50 : 0xffffff801f824995
0xffffff912c5b3fb0 : 0xffffff801f29bd96

BSD process name corresponding to current thread: dnscrypt-proxy

Mac OS version:
16G1036

Kernel version:
Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64
Kernel UUID: F487A842-6E21-37AB-83C3-83F951218734
Kernel slide:     0x000000001f000000
Kernel text base: 0xffffff801f200000
__HIB  text base: 0xffffff801f100000
System model name: MacBookPro11,1 (Mac-189A3D4F975D5FFC)

System uptime in nanoseconds:<PHONE_NUMBER>3
...

According to this crash dump, the crash actually happened in the kernel. This is a bit more serious than a bug in dnscrypt-proxy.
This can be due to bad RAM modules, or to a bug in the macOS kernel. Since it was triggered by a userland app, you may even have hit a security issue.
This should be reported to Apple: https://developer.apple.com/bug-reporting/


add komga

Closing issue for now.  Komga only supports SQLLite.  Another alternative Kavita also only supports SQLLIte (without SSO support).


Typo in functions-states.md

Issue #, if available:
Description of changes:
Typo fix
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thank you for pointing out the typo.


Add option to specify separator for text output

Added --separator <str> flag for taplo get.
From the helpdoc:
 --separator <SEPARATOR>
        A string that separates array values when printing to stdout.

        If `--separator` is specified with a non text output format, the operation will fail.

Thanks for the PR!
Out of curiosity, what's the motivation behind this change? Which separator do you want to use and in which context?

This would be to pass in the result of taplo get -f rust-toolchain.toml 'toolchain.components' to the rust toolchain github action, the GHA asks for a comma separated string to installs said components


Add Harem scan

Source name
El Harem de Kira
Source link
https://haremscann.es/
Source language
Spanish
Other details
NSFW: YES
Acknowledgements

[X] I have checked that the extension does not already exist by searching the GitHub repository and verified it does not appear in the code base.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a meaningful title with the source name.
[X] I will fill out all of the requested information in this form.

That site seems to be under construction or just a template, there is nothing of value on it

Is this carteldemanhwas.com the new URL? If it is, it uses mangareader theme

They are uploading to CartelDeManhwas now, that extension already exist.


Use CRI-O as runtime for node throughput tests.

Changes:

Disable the existing containerd based node throughput tests on Prow, until the fix for high PodStartupLatency is identified.
Enable node-throughput tests using CRIO as runtime.

Notes:
This is a follow-up PR post merge of https://github.com/ppc64le-cloud/k8s-ansible/pull/52, followed by submodule updation in kubetest2-plugins repository.

/hold

/cc @mkumatag @Rajalakshmi-Girish

/unhold


Safari Private Browsing

Hello,
I have a problem with login in private browsing. Everything works ok but it can not save the token in localStorage. So user is logged out after navigating to another link. It would be great to somehow degrade to cookies if localStorage is not awailable. Is this possible?
Thank you for your help!

Nice recommendation. It is pretty easy to implement. You can add two options to the config - storageType cookie and a degradeToCookie option. Then add the logic to store the token as a cookie to the Storage class.
This month I don't have much time so I'd appreciate a pull request. If you don't it may take a small while until I implement it myself.

I also don't have much time at the moment. I will try to do this as soon as possible... If you don't do it first...

any news about this?

It should be pretty easy to implement document.cookie = ... instead of localStorage.setItem(...) if certain config parameters are set. If you need it you are welcome to submit a pull request, I'd be happy to merge it.

now supporting 'cookie' and 'sessionCookie' as storage methods in version 7.0.1

How can i overwrite the storageType:'cookie' in CustomConfig


chore: Fix typos in README.md

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 80.59%. Comparing base (347b006) to head (90b644b).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #25   +/-   ##
=======================================
  Coverage   80.59%   80.59%
=======================================
  Files           2        2
  Lines         541      541
  Branches       73       73
=======================================
  Hits          436      436
  Misses        104      104
  Partials        1        1

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


fix(debug/android): improve reliability of Android debug attachment

This fixes a couple inconsistent issues around attaching to the Android debugger. It moves to using
a random port every time (unless specified by the user) due to an issue where a debug session could
fail to start due to the port already being in use, and adds a small delay to the attachment process
to allow time for the app to have got the debugger ready for attaching to

Warnings

:warning:

src/debugger/titaniumDebugAdapter.ts#L31 - src/debugger/titaniumDebugAdapter.ts line 31 – Unexpected any. Specify a different type. (@typescript-eslint/no-explicit-any)

:warning:

src/project.ts#L26 - src/project.ts line 26 – Unexpected any. Specify a different type. (@typescript-eslint/no-explicit-any)

:warning:

src/project.ts#L128 - src/project.ts line 128 – Unexpected any. Specify a different type. (@typescript-eslint/no-explicit-any)

Messages

:book:

:white_check_mark: All tests are passing
Nice one! All 32 tests are passing.

:book:

:floppy_disk: Here's the built vsix for this change.

  Generated by :no_entry_sign: dangerJS against 19d8b20b1c59665b7008da469645e9f46ab1d32d


Make JRuby-related versions via ScriptingContainerDelegate

Making JRuby version ("<IP_ADDRESS>" at this time) and Ruby compatibility version ("2.3.3" then) available through ScriptingContainerDelegate. It will (not yet) be used for making .ruby-version in plugin code generated by embulk bundle, migrate, and new.
@sakama @muga Can you have a look?

Thanks!


Excel and Docx not showing in the viewer

I converted it to open source document.Still not showing in the viewer,it is getting downloaded

Hi. To be able to help you we need more information.
How are you trying to use ViewerJS? What url are you using as src for the iframe? Does it work for files which are originally in PDF or one of the ODF formats? Try e.g. with the example files on viewerjs.org by downloading them and putting on your server
Are the files you are using public? So could you make them available by a link, so we could test with the files?

Ping? Without the requested info we will have to close this issue as there is nothing we can do otherwise to help or find a bug. Closing March 31, if there is no reply from you.

Closing due to no further info provided.


API - Compilation Lifecycle

i.e which compilation stages/events happen in which order, what they do by default, what properties are available within the handler, what they can be used to do, what they should/shouldn't be used to do, and how they relate to other bits of the lifecycle.
Flow diagrams (which really aid understanding of complex flows, and are sorely lacking in webpack 1 docs) would be a great addition too
PS. Excellent to hear that webpack 2 documentation is being given such careful thought

Yes I think this would be a great companion to the API - Plugins section, maybe a secondary companion to the complete API hooks.
@bebraw thoughts?

Go for it. Great addition to plugin docs.

@TheLarkInn, just an idea, perhaps we could use the scheme that you used for readthesource here?

@sebastiandeutsch Can you make a web friendly png or jpeg of the UMD you created for me the other day?

@TheLarkInn yes sure. What's the width that you need?

Here you go: https://webpack.slack.com/files/sippndipp/F367L1ABH/webpack_2_-_uml.png

@TheLarkInn here you go: http://imgur.com/a/JQIxm

Related: #469 -- Maybe someone can take a stab at recreating that chart in mermaid? Also based on @bebraw's comment in #487 I think we need to make sure that image is still accurate for webpack 3.

Just in case anyone comes across this -- @hulkish has expressed interest in tackling this one... I believe he'll be sharing some thoughts soon.

@skipjack yes, I'm currently putting together a small script that will produce this in a way that's easily updatable.

Ok dug into this a little bit since it seems to have gone inactive again...

which compilation stages/events happen in which order, what they do by default, what properties are available within the handler, what they can be used to do, what they should/shouldn't be used to do, and how they relate to other bits of the lifecycle.

I'm not sure when it was added but this section seems to do exactly what you describe. The events are listed in order (as far as I can tell) with a description, callback parameters, and some details on how they relate to the other events. Maybe we can just flesh it out a little, or even break it out into a separate Lifecycle page with more detailed sections on each event?
I added a note to #469 re the flow chart. @hulkish did you ever get any farther with that script?

Ok I'm going to close this out as it's become fairly inactive but I'll keep in mind the idea I mentioned about refactoring that table into a separate "Lifecycle" page as we continue to clean up the API section. If someone has time and would like to flesh it out, please drop a comment here and feel free to submit a PR.

Trying to learn about how webpack internally works, i found on https://github.com/fanjunzhi/lifecycle-webpack-plugin this diagram : https://img.alicdn.com/tps/TB1GVGFNXXXXXaTapXXXXXXXXXX-4436-4244.jpg.
It would be great to have an updated version into documentation (and also in english =P).
A separate "Lifecycle" page would be great in order to fully understand what is happening, especially for plugin maker.


Revert "Update gce starting guide to use get.k8s.io"

Reverting #6019 because it doesn't work if gcloud is a system install.
Reverts GoogleCloudPlatform/kubernetes#6019

hrmph, I call that a bug in Jenkins...

It would fail the same way for anyone using a GCE VM to run kube-up.sh :)
Anyways, I'm sure we can work out better logic; reverting it was faster.
On Mar 26, 2015 10:18 PM, "Brendan Burns"<EMAIL_ADDRESS>wrote:

hrmph, I call that a bug in Jenkins...
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/6041#issuecomment-86828416
.


.htaccess file is no longer working

Hello,
I had everything working great then my IP upgraded his  version of Apache web server and upgraded my PHP to 5.6  I started getting Server 500 errors and I think I trace it back to the
.htaccess file,  I'm using the below code. (which was working).
is there a upgrade to this file for newer Apache server or should it work on any version of  Apache
Apache 2.2 to 2.4
# Apache needs to let you overwrite this (AllowOverride Indexes or AllowOverride All)
DirectoryIndex index.php
<IfModule mod_rewrite.c>
	# Turn Rewrite Engine on
	RewriteEngine On
	# Send all requests to index.php (index.php will parse the request url and routes accordingly)
	RewriteRule ^.*$ index.php [QSA,L]
</IfModule>

okay there seem to be a different in how the Apache server 2.4 is handling the rewrite calls.
the above .htaccess file didn't work any longer however the below one does. This is how I fixed it.
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !index\.php$
RewriteRule ^(.*)$ index.php [QSA,L]

okay there seem to be a different in how the Apache server 2.4 is handling the rewrite calls.
the above .htaccess file didn't work any longer however the below one does. This is how I fixed it.
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !index\.php$
RewriteRule ^(.*)$ index.php [QSA,L]


More weather data

Forward more weather data with Amazmod:

Sunrise
Sunset
Moon phase
Tide
Visibility
Air quality

An idea is to pull some data from this API.

update weather/temperature/city from Google weather notifications

moon phase also requested

Amazmod has now integrated KieronQuinn's AmazfitInternetCompanion and it will be easier to get the data above.
Mind that moon phase is already integrated by AndreaOmodeo

AFAIK air quality is also provided by Huami, but I am not sure if the data is available outside China.

AFAIK air quality is also provided by Huami, but I am not sure if the data is available outside China.

If I remember correctly, data are included in Huami's weather app are not populated. Thus, you must be correct.

The following new widgets where added. Latest bleeding edge Amazmod version is needed along with its custom weather.

Sunrise
Sunset
Visibility
Clouds

Commit 2c5be1d512ad895ba46a459c98f528cf26fd9252
Current issue will close as most requested widgets are already scripted.


[rmkit] update rmkit apps to latest (12/21/2020)

correctly suspend on remux for rM2
add fix to remux so that koreader doesn't restart when resumed

I guess someone with a rM2 has to review this.

we only have two (or three?) people with rM2 :-( need to get more reviewers who have an rM2


Remove dependency for toro project

Given that the Toro project for tornado (https://toro.readthedocs.io/en/stable/) is deprecated (since the project has been merged to mainline Tornado), there is no point on mantaining this dependency (which will be incompatible with Python 3.7).
Tornado itself has the exact same toro.Lock() functionality builtin.

Request sent to wrong branch...


Web: Clear results if package is changed

Not sure if I see the value of this.
Also, if we do agree to do this, then the results should be cleared whenever any of the input values changed, not just the package.

This was coming from the view of switching units, since the conversion is dependent on the package used. I.e. if you switch package, the conversion from Sm3/d -> kg/d is different. But it can maybe be solved in a different way.

Not doing


Unexpected character '�'

Hi,
I'm using "@xenova/transformers": "2.6.2" with nextjs app router. I set up serverComponentsExternalPackages: ['sharp', 'onnxruntime-node'] in my config. It works with npm but not with pnpm.
Is there any workaround or is this a nextjs issue?
Thanks for your help,

Related to https://github.com/xenova/transformers.js/issues/183

Hi there 👋 As I mentioned here, this does look like a pnpm/next.js issue (related to the experimental serverComponentsExternalPackages flag (see docs). So, we won't be able to solve it here. Perhaps others have found a workaround which might help?
There is also an open issue for this here.

Great thanks, let's close the issue here and hopefully this will be addressed soon.

For anyone facing the same issue, I've created an api endpoint in the pages folder for now and this works.


upload/aws: double the timeout for snapshot import

us-east-1 seems to very slow these days, some imports can take up to
15 minutes. This commit raises the timeout from 10 to 20 minutes.

Thanks for feedback! I made the commit message clearer:

This commit raises the number of attempts before we give up. Previously, we did 40 attempts, each delayed by 15 seconds, making the total timeout equal to 10 minutes. Now we do 80 attempts with the same delay, making the total timeout 20 minutes.

This might be unrelated, but the documantation for Waiter states that

This type should not be used directly. The API operations provided in the service packages prefixed with "WaitUntil" should be used instead.

There isn't WaitUntilSnapshotImported method in the library, so I guess that's why Tom, that implemented this originally, had to implement the wait method himself.

Yes, I only implemented it as it was missing


Export setConsole function

Ooooo good find. Wanna write a test for setConsole?

Sure, but I have a dilemma:

test setConsole using useMutation hook (a bit overkill)
or
test setConsole by importing Console from 'utils' (private API)

What do you think?

Wow, you're right. I think the only thorough way would be to do setConsole + useQuery/useMutation and trigger an error


Add link to a text-based course on the Elixir language

What does this PR do?
Add resource(s) | Remove resource(s) | Add info | Improve repo
For resources
Description
Add a section dedicated to the Elixir language and included a link to an Elixir language course "Учебный курс по языку программирования Эликсир".
Why is this valuable (or not)?
The course seemed useful.
How do we know it's really free?
This github link is freely accessible by everyone.
For book lists, is it a book? For course lists, is it a course? etc.
It's a course
Checklist:

[*] Read our contributing guidelines.
[*] Search for duplicates.
[*] Include author(s) and platform where appropriate.
[*] Put lists in alphabetical order, correct spacing.
[*] Add needed indications (PDF, access notes, under construction).
[*] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

The title has been corrected

Thanks, and welcome to free-programming-books!


VIS Export and KML Export

Hello,
I am following the tutorial to learn KML/COLLADA/glTF Export, but my Importer-Exporter only has VIS export, what is the difference between these two? How can I have KML export?
Thanks!

The tutorial is based on an older version of the Importer/Exporter. The KML/COLLADA/glTF Export tab has been renamed to VIS Export in the meantime, but this change is not yet reflected in the tutorial. Although the UI elements have been rearranged and updated, the functionality of the VIS Export remains the same and you can still use it to do a KML export. Please refer to our user manual in addition to the tutorial.


[Bug]The Theme does not show on the voice chat and text channels on servers (Including Transparency on).

Describe the Bug

To Reproduce

Expected Behavior

Screenshots

Discord Version

Additional Context

Wait for your theme to be updated for the latest Discord changes.

thank you


I have set the font size for the p element, but it still does not recognize that I have written the correct statement

Challenge Change the Font Size of an Element has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
 Your code doesn't include that rule.

@psomdeb25 Thank you for reporting this issue.
Your code is wrong.
Instead of asking for help here, please click the "Help" button on the challenge on freeCodeCamp, which will take you to the help chatroom for that specific challenge. You can also view our full list of official chatrooms.
Thank you, and happy coding.


How does tags work in blackout rule

Hello,
I want to know how does tags work in blackout rules.
For example : I have an alert - A1 which has following tags - tag1, tag2, tag3, tag4
then alert - A2 which has following tags - tag3, tag4
Now I have a blackout rule which has tag3
I expected above rule  to suppress both alerts A1 and A2 but it's not suppressing them. What am I missing? How to achieve the above? please let me know.

It was issue with timings. It is working as expected.


Alias for AutoMigrate

Describe the feature
Have another alias for AutoMigrate to make it easier to understand what the function does for newcomers. Having an alias such as SyncSchema.
Motivation
Was recently working on a project and despite following the documentation posted, it was confusing seeing AutoMigrate being used but as it does not have any hint that it creates the tables, it left me baffled for a while.
Related Issues
N/A

Let's work together to improve the documentation. More APIs are not necessarily better for the project's development and can be ambiguous.


"Error starting app!" message for Shiny Express examples

At least two examples in the Shiny Express docs seem to be broken and are showing the following error message:
Traceback (most recent call last):
  File "<exec>", line 384, in _start_app
  File "<exec>", line 357, in __init__
  File "/lib/python3.12/site-packages/shiny/express/_run.py", line 62, in wrap_express_app
    app_module = importlib.import_module(package_name)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/lib/python312.zip/importlib/__init__.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "/lib/python3.12/site-packages/shiny/express/_run.py", line 102, in exec_module
    module.app = create_express_app(  # pyright: ignore[reportAttributeAccessIssue]
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/lib/python3.12/site-packages/shiny/express/_run.py", line 132, in create_express_app
    app_ui = run_express(file, package_name).tagify()
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/lib/python3.12/site-packages/shiny/express/_run.py", line 220, in run_express
    exec(
  File "/home/pyodide/app_t9jwvn5ng0beenxubec5/app.py", line 1, in <module>
    from icons import question_circle_fill
ModuleNotFoundError: No module named 'icons'

Looks like whatever environment is running the examples is missing a dependency?
Examples checked:

express.ui.tooltip
express.ui.popover

Also value_box
Previously the examples had a second icons.py file included as a part of the example.

Thanks for the report! We have an issue upstream in py-shiny (where the fix needs to be) that's tracking this.

It turns out the issue is probably happening in this repo after all. I can't reproduce the issue locally (note that we're using Python 3.10 in the GHA workflow that builds the docs) and the problem doesn't appear in our dev docs build.
In investigating, I noticed that if you view the page source for the value box example for the release docs, you can see that the supporting icons.py file isn't included in the shinylive chunk.

More investigation:

https://6697d5703d3ccfd3aee21bef--pyshiny.netlify.app/api/core/ui.value_box.html has the supporting file (commit, GHA run)
https://669988109dd1e06850104ad4--pyshiny.netlify.app/api/core/ui.value_box.html does not  (commit, GHA run)

So something changed with the rc-v1.0.0 commit

Just adding on to the rc-v1.0.0 observation:

The icons.py file was included in the PR just before the 1.0.0 PR:

#166
https://pr-166--pyshiny.netlify.app/api/core/ui.value_box.html#examples

The icons.py was not present in the 1.0.0 PR:

#167
https://pr-166--pyshiny.netlify.app/api/core/ui.value_box.html#examples

Looking through the deployments for each commit in #167, it appears that:

The first commit that shows the problem is f87ea2aca27647e232e3ef1e71aa043293223da6.
From the GHA logs, we can find that it's deployed at https://6697cb511b075ac6f6af3e8e--pyshiny.netlify.app/api/core/ui.value_box.html

@gadenbuie: @schloerke and I did some investigating, and we think it's likely that the issue is due to these commits:

83647e2126306caa7ca8f7bcd6dc98a04374e1aa
f4039e2b9775d8f11628db555a844b21bd7af65d

When the site is built, it uses a venv and installs py-shiny to it, so that statement would evaluate to is_support_file=False for all files.
Note that when the docs are built from py-shiny main, it does not use a venv, so in that case it would have is_support_file=True.
@schloerke is working on a PR to use a pip install -e for py-shiny, so in that case it would not be in the venv/ directory. But that could be a bit fragile because if we later decide to install shiny the regular way, then this problem would surface again.
Why do we need to avoid venv directories for support files? Can we remove that logic?

When the site is built, it uses a venv and installs py-shiny to it, so that statement would evaluate to is_support_file=False for all files.

Ah that makes sense!

Why do we need to avoid venv directories for support files? Can we remove that logic?

During development I've used a local .venv inside the api-examples folder to test an example with dev versions of other packages. That's more of a "me" problem than an everyone problem, but I think it's worth taking into account.
I think the updated logic would look at the path parts relative to the api-examples folder and not in the absolute path parts.


fix: cuertino dialog action background blur effect

#20784

below images show the difference between before fix and after.
run on iPhone7 plus
flutter --version
Flutter 1.0.0 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 5391447fae (7 days ago) • 2018-11-29 19:41:26 -0800
Engine • revision 7375a0f414
Tools • Dart 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

Thanks for the PR to fix the issue.
At the moment I'm having trouble remembering why we used Rect.largest, but there was definitely a reason at the time, so I'm going to need a little time to test this PR and to discover that history.
I'm currently busy with some other things, so if you have some free cycles and you'd like to help verify this work even more, you might consider testing the dialog on top of more complex backgrounds.
One concern that I need to investigate is edge effects.  We may have used Rect.largest to avoid rendering artifacts near the edges of the dialog.  In your screenshots there do not appear to be any edge effects, but then again it's rendering on a very simple and solid background.  The more unusual the content beneath the dialog, the better the chances that we discover edge effects.

Thanks for the PR to fix the issue.
At the moment I'm having trouble remembering why we used Rect.largest, but there was definitely a reason at the time, so I'm going to need a little time to test this PR and to discover that history.
I'm currently busy with some other things, so if you have some free cycles and you'd like to help verify this work even more, you might consider testing the dialog on top of more complex backgrounds.
One concern that I need to investigate is edge effects. We may have used Rect.largest to avoid rendering artifacts near the edges of the dialog. In your screenshots there do not appear to be any edge effects, but then again it's rendering on a very simple and solid background. The more unusual the content beneath the dialog, the better the chances that we discover edge effects.

I have tried some other content beneath the dialog, like a video/another dialog/text and image, it looks good.

Thanks for the extra testing! LGTM
Matt can help you merge in when he's ready.


ui: Fix migrate systemVM icon when stopped

Description
This icon for migrating systemVM when it is stopped.

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[X] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[ ] Minor
[X] Trivial

Screenshots (if appropriate):
How Has This Been Tested?
 I'll keep you posted as I make progress.

UI build: :heavy_check_mark:
Live QA URL: http://qa.cloudstack.cloud:8080/client/pr/6337 (SL-JID-1496)


Update how-to-enable-app-insights.md

metadata cleanup

@j-martens : Thanks for your contribution! The author, @marthalc, has been notified to review your proposed change.


Can't start kvs stream. Codec private data was not found in GST_CAPS event

I've built the C++ producer on Windows and can get a video stream into Kinesis successfully. Now I'm trying to add a mux layer for audio on top of the video, and am getting this error. I can produce the file locally to file system and it contains audio and video, the error comes when trying to send out to the kvssink. I've tried using matroskamux and mpegtsmux both which give the same error.  Currently, we only support elementary stream for h264 out-of-the-box in the GStreamer plugin. We are working on making a generic support for multi-pad which will handle audio as well.
In this case, the plugin gets confused as it can't extract and process Codec Private Data which in case of H264 is SPS and PPS.

Thanks @MushMal. What would be the recommended route to get a stream which either includes audio, or perhaps audio only?

@jonathanmesser thanks. While we are working on to provide out-of-the-box support for multi-stream/multi-track solution for the GStreamer plugin, in the interim, you could use an example of the sample application where you could construct two separate GStreamer pipelines (audio and video) and in the app sinks create two separate KVS streams. Send the audio and video in their respective streams - similar to https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/kinesis-video-gst-demo/kinesis_video_gstreamer_sample_multistream_app.cpp
We hope to provide multi-stream solution very soon.


Remove guidance against id properties

Previously the documentation advised against naming schema properties id since they would conflict with a hidden sync table column with the same. With the recent updates to the sync table infrastructure this is no longer the case, so the recommendation no longer makes sense.
This PR removed the best practice and updates sample code and snippets to use id properties. It also fixes a small bug with the sync table snippet.

Assigning to on-call: @gary-codaio


Window.ModalWindows does not report all modal windows

In our application we have a progress bar dialog that is displayed before a file is opened, and the first action the user needs to do is to pick the file in a Open File dialog. Both dialogs are displayed with ShowDialog so they are both modal, but the Window.ModalWindows only reports the first progress dialog.
As you can see the file dialog is a child of the progress bar dialog:

Code using ModalWindows:
Window[] windows = App.MainWindow.ModalWindows;
// windows.Length == 1

Progress dialog has the following pattern:
IsTopMost=False
CanMinimize=False
CanMaximize=False
WindowVisualState=Normal
WindowInteractionState=BlockedByAModalWindow

File dialog has the following pattern:
IsTopMost=False
CanMinimize=False
CanMaximize=False
WindowVisualState=Normal
WindowInteractionState=ReadyForUserInteraction

The ModalWindows property only returns the modal windows which are a child element of the window (and not any descendant). If it would return any modal window, it might get complicated to identify the correct window in the end so it's probably better to search for the window on your own or at least call mainwindow.ModalWindows[0].ModalWindows[0].

Ok. I understand. Im closing this issue.


fix non-portable uname usage (-p)

As the manual of GNU coreutils tells, both uname -p and uname -i is non-portable, even across GNU/Linux distributions. They are not aborigines in the Linux world.
FISCO-BCOS relies both on uname -m and uname -p to distinguish the architecture but the latter is redundant. Only a few GNU/Linux distributions return processor (-p) info by patching coreutils. The patch, for example, the one that Ubuntu uses, is pretty dirty and actually generates -p from -m. Thus, there's no need to rely on uname -p since it is generated from uname -m. In fact, Debian, as the upstream distribution of Ubuntu, never applies the ugly-and-dirty patch. The usage of uname -p in the convenient shell scripts of FISCO-BCOS effectively makes the latter fail on Debian, even if FISCO-BCOS itself works perfectly on Debian itself and most distributions based on Debian (though only Ubuntu is officially supported, being better supporting other distributions is not a bad deal).
As for macOS, uname -p is also unreliable. Both old x86 Macs and new x86_64 Macs return i386, but the one and only binary officially provided by FISCO-BCOS, the x86_64 binary, is obviously unable to run on old x86 Macs. A far more serious conclusion is that depending on uname -p on macOS could potentially make things buggy.
This PR fixes these problems by migrating all uname -p usages to the uname -m one.
Ref
https://en.wikipedia.org/wiki/Uname
https://www.gnu.org/software/coreutils/manual/html_node/uname-invocation.html#uname-invocation
https://git.launchpad.net/ubuntu/+source/coreutils/tree/debian/patches/80_fedora_sysinfo.patch?h=applied/ubuntu/kinetic
https://unix.stackexchange.com/questions/307955/uname-p-i-are-unknown
简短的中文翻译
uname -p，不可移植，标准阙如，各行其道，返回随意，补丁肮脏，自囿其足，不应使用；uname -m，为其根本，处处可用，返回可靠，应予迁移。
Note
I've noticed that the convenient shell scripts in master-2.0 branch are different from but newer than the ones in master branch and this fix should port or backport to other branches if approved IMO. I strictly follow the instructions documented in 揭秘FISCO BCOS开源项目开发协作 to make the PR point to the master branch since I consider it as a "bug". If asked, I may also open other PRs to port this fix to other branches.

It is recommended to mention the PR to the release-3.0.0-rc4 branch, please resolve the conflict to the release-3.0.0-rc4 branch.

It is recommended to mention the PR to the release-3.0.0-rc4 branch, please resolve the conflict to the release-3.0.0-rc4 branch.

Done.


bump to ray 2.7.1, remove setproctitle pinning, remove stale comments

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

@conda-forge-admin please rerender

replaces https://github.com/conda-forge/ray-packages-feedstock/pull/113

@conda-forge-admin please rerender

@conda-forge-admin please rerender

@conda-forge-admin please rerender

can't rerender so will reopen


Issue #7659 foreach warning on adding gateway RELENG_2_3

Backport of PR #3764
Note: the code in master for 2.4 is different, so the fix was in gwlb.inc - in RELENG_2_3 the code is still in system_gateways_edit.php
Signed-off-by: Phil Davis<EMAIL_ADDRESS>

Already cherry-picked from #3766


Brochure: remove space in "-0, 234"

In relation to https://github.com/metanorma/bipm-si-brochure/issues/189
This:
[example]
====
stem:[−0,234] +
mais pas +
stem:["−,234"]
====

renders:

The asciidoc/Asciimath parser we have been using to date is not localised:
-0.6 is recognised as a single number
-0,6 , -,6, -.6 are not: they are being processed as:
<mo>−</mo><mn>0</mn><mo>,</mo><mn>234</mn> for -0,234 (which renders with the space shown)
><mtext>−,234</mtext> for -,234
If we enter -0.234, that is not only recognised as a number, but is correctly rendered with its decimal point converted to a comma.
But the Asciimath parser has to cope to begin with with commas in numbers.
I'm switching our Asciimath parser to Plurimath, and... well, we're signing up for a lot of regression testing.

Right now:

our native Asciimath parser (Plurimath) does not recognise any decimals, comma or point
our current Asciimath parser (Asciidoctor) only recognises decimal points
getting our native Asciimath parser (Plurimath)  to the level of maturity of the Asciidoctor parser is a big job, especially given the underspecification of Asciimath

Our options are:

to ban all use of decimal comma in Asciidoctor French source: localisation will render decimal points as decimal commas correctly. This is anglocentric (you can only enter maths using English conventions, however you render them), but it's not the worst thing that has ever happen; the metalanguage of our markup is English, after all.
to map all decimal commas in Asciidoctor French source to decimal points in preprocessing. I don't think that's absurd.
to ask Asciidoctor Asciimath to recognise decimal commas. I'm not convinced that they should, and that decimal commas even are correct Asciimath
to wait for Plurimath Asciimath to catch up with Asciidoctor Asciimath. I think making a major deliverable like the BIPM Brochure subject to a complete reimplementation of Asciimath would be a very foolish thing to do, this late in the process.

In fact, in this instance, we have been using decimal point in French throughout; this is a one-off exception, which I've fixed. This issue will come back to us, but for now, we will just document that Asciimath markup requires decimal points.

Correct, and in fact, the -0,234 and 0,234 statements were meant to be "counter-examples", so let's not generalize this issue.
We probably want to support the decimal comma but NOT until we decide what the French use for separators (e.g. in matrices).


Upgrade builds from Ubuntu Precise to Trusty for newer JDK

Currently the default OracleJDK on Precise is 1.8.0_31 and the default on Trusty is 1.8.0_111 (one release behind current).
This is an alternate to #988 to in hopes of tracking down metaspace problems.

Wow.  If we're looking for a way to fail builds, running them on Trusty seems to be a winner!
In three builds:
3804

3804.1 - OutOfMemoryError: Metaspace
3804.3 - Failed tests: org.http4s.client.blaze.ClientTimeoutSpec

3805

3805.3 - Error during tests: org.http4s.client.asynchttpclient.AsyncHttpClientSpec
3805.4 - likely deadlock (length has exceeded the limit of 4 MB)

3806

3806.1 - likely deadlock (length has exceeded the limit of 4 MB)

Most Trusty builds were also in the 10-25 minute range.  5-7 minutes is normal for well-running build on Precise.
It's possible the TLS change in a0354be9 is a factor, but doubtful it's a primary one given #988 also uses TLS and fared much better with Travis.


Disable SSL Certificate check

Hello,
I'm having some trouble with SSL certificate. Why not add an option to ignore invalid SSL certificates ? This could temporarily fix my trouble.
My trouble (maybe I should open another issue) : I'm using rclone linux 32bits binary on DNS-320L using Alt-F firmware. I can download files from my website using wget (SSL certificate is trusted) but I get an error with rclone :
Failed to create file system for "hubic:": Get https://hubic.ga/v1.0: x509: failed to load system roots and no roots provided
Best regards,
Axtux

Go tries to load the root certificates from these places on linux.
	"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc.
	"/etc/pki/tls/certs/ca-bundle.crt",   // Fedora/RHEL
	"/etc/ssl/ca-bundle.pem",             // OpenSUSE
	"/etc/pki/tls/cacert.pem",            // OpenELEC

Do you have something in one of those places? Or maybe somewhere else?
I wonder where wget is looking for the certs?  Maybe you could strace it and find out?
I have thought about putting an --insecure flag in which would ignore the certificate check, but I'm not sure it would help in the case of this error.

PS it might be possible to support hubic directly - rclone knows how to do oauth

Thanks for your fast answer. As a workaround, I took the file /etc/ssl/certs/ca-certificates.crt from my debian 8 and copied it into my NAS. Now rclone is accepting my server certificate. Not sure where wget is looking for CA but I don't have debug tools on my NAS to strace it.
The insecure flag should help for testing. In my case, I had to set a valid certificate to start testing rclone. I think should be easy to implement and would be very useful.
The gateway is just one PHP file + one SSL certificate (free with CloudFlare) https://github.com/oderwat/hubic2swiftgate and only used for authentication process, file transfer connects directly to Hubic openstack API to get full speed. As hubic authentication is not "standard", I don't see the point to implement it. The gateway is still needed for other applications that refused to implement Hubic as CyberDuck https://trac.cyberduck.io/ticket/7764 Though, if you want to implement it, Hubic API Docs can be found here https://api.hubic.com/console/ and a sandbox here https://api.hubic.com/sandbox/

You can find the --no-check-certificate in v1.24 if you need it


Sensei DB

Sensei DB's website has moved. The current link points to a spam page.

Could you create a PR please?

@onurakpolat I see you've already made the change yourself, so no need for a PR.


add headers to examples checker

Currently, only query and body examples are tested.  The checker should also test header parameter examples since they are now fully supported in the schema.

Hey @marina-p ,
I guess this issue is solved in this part https://github.com/microsoft/restler-fuzzer/blob/main/restler/checkers/examples_checker.py#L111
or is there anything else to contribute ?


Updates

For https://github.com/avajs/ava/issues/1598.

[ ] https://github.com/power-assert-js/babel-plugin-espower/pull/23 needs to be released
[ ] https://github.com/avajs/babel-plugin-throws-helper/pull/9 needs to be released

FYI: babel-plugin-espower v3.0.0-beta.1: The first beta version of Babel7 support (2017-12-25) 🎅


Auth0 JWT example not working on reload

Unfortunately the example does not work properly if generated.
If you go to https://nuxt-auth0.surge.sh and sign in, there is a redirect to the main page showing "You are authenticated" and the secret div is displayed.
But then reloading this page results in the unexpected "You're not authenticated yet"?
The only way to make the example work after a reload is to manually go to https://nuxt-auth0.surge.sh/secret and start the navigation from there.

You should create this in that example page.

If you bother to check that page, you'll find that it already have that issue - https://github.com/nuxt/example-auth0/issues/8


chronos package

adding chronos package to repository in order to be able to launch it by mantl-api.

@ryane @stevendborrelli this code has already been tested and is proven to work.
Please merge it so we can update https://github.com/CiscoCloud/microservices-infrastructure/pull/883.

Thanks! this currently doesn't work with mesos authentication enabled (the default on mantl clusters) and is missing a health check. I am going to be on a plane this morning but I'll make sure to consolidate this with the package/chronos branch (https://github.com/CiscoCloud/mantl-universe/compare/package/chronos) and merge later today.

thanks for this! I went ahead and merged #15 as it was basically the same but with the needed support to make it run on mantl


Support for KDE Plasma Color Schemes

New theme template request
Since KDE Plasma Color Schemes are just .colors files that need RGB color values, themer could probably support those too.
Website
Here's the official documentation of color schemes, although I feel its a bit lacking https://docs.kde.org/stable5/en/plasma-workspace/kcontrol/colors/index.html#idm35
Example theme file
One of the official theme files:
https://github.com/KDE/breeze/blob/master/colors/BreezeDark.colors
Additional theme information
My thoughts are that the color scheme could follow pretty closely to the one made in themer, but have some variation when it comes to inactive fields. Those could be made dimmer by default. Hovers could either be dimmer or lighter variation of the base color.
Also there's a contrast slider that could be set 4 or 5 by default, but user can change it if they wish.

@Akselmo , I just deployed @themerdev/kde-plasma-colors to npm and added it to the web UI as well.
I installed Kubuntu in a VM to test, but I don't use KDE full-time so feel free to take a look and let me know if I screwed up any of the color mappings. PRs welcome for any improvements there. 👍


Generate-Token.sh not working

I tried to generate my spotify token file on both my Pi running RasbianOS and on WSL using Ubuntu with neither of them generating the file in the Spotipi directory.

Did you ever find a fix? Sorry for the ping

Did you check for hidden files?


Allow setting a custom transport when instantiating clients

Hey 👋
I might be missing it, but I can't see any way to provide a custom http transport to the client.
For people building integrations inside larger applications, it's normal to provide a custom transport to provide standardised logging/tracing/retrying into their third-party clients.
Would you consider adding another client.Option that supports configuring a base transport?
Thanks!

Hey @lawrencejones - I would be open to this but I think that area of code to provide this is going to need a major refactor/cleanup so it might be a heavy lift.  If you are willing to work on this refactor i'm open to reviewing and testing out your solution.  Our team currently is a bit too small and behind on product features so we won't beable to take this on within our Q2 roadmap so it would have to wait to be scheduled for Q3.  Let me know what you think.  Thanks!


remove amitaekbote from owners.json

High-level description
What features does this change enable? What bugs does this change fix?
Amita no longer works at Mesosphere. This is a backport of https://github.com/dcos/dcos/pull/3145
Corresponding DC/OS tickets (obligatory)
These DC/OS JIRA ticket(s) must be updated (ideally closed) in the moment this PR lands:

DCOS_OSS- Foo the Bar so it stops Bazzing.

Related tickets (optional)
Other tickets related to this change:

DCOS_OSS- Foo the Bar so it stops Bazzing.

Checklist for all PRs

[ ] Added a comprehensible changelog entry to CHANGES.md or explain why this is not a user-facing change:
[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[ ] Read the DC/OS contributing guidelines
[ ] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[ ] Change log from the last version integrated (this should be a link to commits for easy verification and review): example
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

PLEASE FILL IN THE TEMPLATE ABOVE / DO NOT REMOVE ANY SECTIONS ABOVE THIS LINE
Instructions and review process
What is the review process and when will my changes land?
All PRs require 2 approvals using GitHub's pull request reviews.
Reviewers should be:

Developers who understand the code being modified.
Developers responsible for code that interacts with or depends on the code being modified.

It is best to proactively ask for 2 reviews by @mentioning the candidate reviewers in the PR comments area. The responsibility is on the developer submitting the PR to follow-up with reviewers and make sure a PR is reviewed in a timely manner. Once a PR has 2 ship-it's, no red reviews, and all tests are green it will be included in the next train.

@mesosphere-mergebot bump-ee

@mesosphere-mergebot label ready for review

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

@mesosphere-mergebot label  ship-it


Add words filtering skill

Based on a list of words, filter the list by words containing a specific letter.
This attempts to fix the following issue:

Filter the following list of words by keeping only the words that include the letter 'i': dog, cat, mouse, dentist
The filtered list of words is: cat, dentist

If your PR is related to a contribution to the taxonomy, please, fill
out the following questionnaire. If not, replace this whole text and the
following questionnaire with whatever information is applicable to your PR.
Describe the contribution to the taxonomy

fix capability to filter words by on the 'include letter x' predicate

Input given at the prompt
Filter the following list of words by keeping only the words that include the letter 'i': dog, cat, mouse, dentist

Response that was received
The filtered list of words is: cat, dentist

Response that is now received instead
I unfortunately don't see a differences in the replies after running lab generate and restarting the lab chat command. So guidance is welcome
  ...

Contribution checklist

[x] Contribution was tested with lab generate
[x] No errors or warnings were produced by lab generate
[ ] All commits are signed off (DCO)
[] The qna.yaml file was linted and prettified (yaml-validator can do both)

Thank you for your contribution to InstructLab! Unfortunately, once a Github repo is made public, all open PRs are automatically closed since they link against a private repo. We have detected that your PR might have been one of the ones affected by this change. If you are still interested in contributing your improvement, please fill out the following short form by no later than May 3rd, and we will get back to you with the additional steps necessary once we have had time to assess the PRs of those still interested:
https://forms.gle/V7SrPPMZDo6iGDYu8