UnicodeEncodeError when trying to start a task with a name that contains the cedilla character

Command used was watson start myproject +flow +alteração.
  File "/usr/local/bin/watson", line 11, in <module>
    load_entry_point('td-watson==1.5.2', 'console_scripts', 'watson')()
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/pkg_resources/__init__.py", line 572, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2755, in load_entry_point
    return ep.load()
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2408, in load
    return self.resolve()
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2414, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/__main__.py", line 6, in <module>
    cli.cli()
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/decorators.py", line 27, in new_func
    return f(get_current_context().obj, *args, **kwargs)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/cli.py", line 154, in start
    _start(watson, project, tags)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/cli.py", line 109, in _start
    style('tags', current['tags']),
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/utils.py", line 49, in style
    return fmt(element)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/utils.py", line 26, in _style_tags
    style('tag', tag) for tag in tags
UnicodeEncodeError: 'ascii' codec can't encode characters in position 27-28: ordinal not in range(128)

:thinking: Hi @renatoliveira & thanks for the report! Looks like you've installed Watson via homebrew on MacOSX. I think there might be an issue with your locale not supporting utf8 encoding. Can you copy/paste the output of the following command?
$ locale

Hi, the output is this:
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

I suppose you haven't played with locale on your machine, right?
Can you type the following commands to test if its related to your locale?
$ export LC_ALL=en_US.UTF-8
$ export LANG=en_US.UTF-8
$ watson start myproject +flow +alteração

If it does not fix the issue, then I will need to ask for help.

Hi! It still happens... 😢
➜  ~ export LANG=en_US.UTF-8
➜  ~ watson start myproject +flow +alteração
Traceback (most recent call last):
  File "/usr/local/bin/watson", line 11, in <module>
    load_entry_point('td-watson==1.5.2', 'console_scripts', 'watson')()
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/pkg_resources/__init__.py", line 572, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2755, in load_entry_point
    return ep.load()
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2408, in load
    return self.resolve()
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2414, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/__main__.py", line 6, in <module>
    cli.cli()
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/decorators.py", line 27, in new_func
    return f(get_current_context().obj, *args, **kwargs)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/cli.py", line 154, in start
    _start(watson, project, tags)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/cli.py", line 109, in _start
    style('tags', current['tags']),
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/utils.py", line 49, in style
    return fmt(element)
  File "/usr/local/Cellar/watson/1.5.2_1/libexec/lib/python2.7/site-packages/watson/utils.py", line 26, in _style_tags
    style('tag', tag) for tag in tags
UnicodeEncodeError: 'ascii' codec can't encode characters in position 26-27: ordinal not in range(128)

Ping @k4nar, can you help us here?

I can reproduce, this is clearly a bug. I'll see if I can fix it easily.

Ok, so "easily" was clearly no the right term :laughing: . But I think #212 should improve things, at least locally I wasn't seeing any more encoding error.
This is hard to fix & test that systematically in Python 2 though, so if you want to use a lot of unicode characters with Watson I would strongly advise to install it with Python 3.

Yay, thanks.

@renatoliveira you'll need to wait for the next (homebrew) release. Until then you can try to install Watson from the master branch.

Not yet. I’ll keep you updated.


Error: RIFF file type not "WAVE" Whisper

Hi,
I have been able to get cuda, cudann and CPU Whisper Examples to work fine, except for when I try to pass in an audio file.  Are CLI inputs supported yet?
ubuntu@ip-172-31-21-63:~$ wget https://huggingface.co/datasets/Narsil/candle_demo/blob/main/samples_jfk.wav

ubuntu@ip-172-31-21-63:~/candle$ cargo run --features cuda --example whisper -- --task transcribe --input ../samples_jfk.wav
   Compiling cudarc v0.9.14
   Compiling candle-examples v0.2.0 (/home/ubuntu/candle/candle-examples)
   Compiling candle-kernels v0.2.0 (/home/ubuntu/candle/candle-kernels)
   Compiling candle-core v0.2.0 (/home/ubuntu/candle/candle-core)
   Compiling candle-nn v0.2.0 (/home/ubuntu/candle/candle-nn)
   Compiling candle-datasets v0.2.0 (/home/ubuntu/candle/candle-datasets)
   Compiling candle-transformers v0.2.0 (/home/ubuntu/candle/candle-transformers)
    Finished dev [unoptimized + debuginfo] target(s) in 14.57s
     Running `target/debug/examples/whisper --task transcribe --input ../samples_jfk.wav`
Error: RIFF file type not "WAVE"

I think your wget is grabbing the html page rather than the wav file itself :)

I think your wget is grabbing the html page rather than the wav file itself :) Note that if you don't pass any input argument, the download will happen automatically from the hub.

My original file was here
No worries on my end, I can dig into settings and flags and see if I can figure out what is going on.

Agreed that the whisper output is pretty disappointing on your example. The whisper setup is pretty involved and tweaking the flags may help though in that case I didn't get anywhere, I would just suggest increasing the model size as it usually helps.
cargo run --example whisper --profile=release-with-debug -- --input ~/Downloads/four-score.wav --model medium.en --task transcribe
loaded wav data: Header { audio_format: 1, channel_count: 2, sampling_rate: 16000, bytes_per_second: 64000, bytes_per_sample: 4, bits_per_sample: 16 }
pcm data loaded 636224
loaded mel: [1, 80, 6000]
0.0s -- 30.0s:  Fast forward and seven years ago our fathers bore forth on this continent a new nation conceived of liberty and dedicated to the proposition that all men are created equal.
30.0s -- 60.0s:  We are engaged in a great civil war. Testing whether that mission or any mission

Besides this it would be great if you have the openai whisper version at hand to give it a shot and if it performs well I can have a look at trying to understand the discrepancies.

Agreed that the whisper output is pretty disappointing on your example. The whisper setup is pretty involved and tweaking the flags may help though in that case I didn't get anywhere, I would just suggest increasing the model size as it usually helps.
cargo run --example whisper --profile=release-with-debug -- --input ~/Downloads/four-score.wav --model medium.en --task transcribe
loaded wav data: Header { audio_format: 1, channel_count: 2, sampling_rate: 16000, bytes_per_second: 64000, bytes_per_sample: 4, bits_per_sample: 16 }
pcm data loaded 636224
loaded mel: [1, 80, 6000]
0.0s -- 30.0s:  Fast forward and seven years ago our fathers bore forth on this continent a new nation conceived of liberty and dedicated to the proposition that all men are created equal.
30.0s -- 60.0s:  We are engaged in a great civil war. Testing whether that mission or any mission

Besides this it would be great if you have the openai whisper version at hand to give it a shot and if it performs well I can have a look at trying to understand the discrepancies.

Awesome!  Thanks, this was very helpful.  I will leave ticket open and do some tests and report back.  I have done quite a bit of work on Python MLOPs GPU GitHub Codespaces so it pretty easy to go back and forth to Python and Rust and test things out.
Also, the new ssh-remote workflow is not horrible on AWS, so I can test on those as well.

Closing this one as no recent activity, hopefully it's all sorted out.


fix Content-Type header in http response

A request does not carry Content-Type information in its headers, just leave it unset, and http.ServeFile will set it automatically.

Oh, nice catch.


user picture of bookmarked (or visited) user is broken link

Environment
Host

item
version

OS
macOS 10.15.4

GROWI
3.7.3-RC

node.js
12.14.0

npm
6.13.4

Using Docker
no

Using [growi-docker-compose][growi-docker-compose]
no

Client

item
version

OS
macOS 10.15.3

browser
chrome, firefox

How to reproduce? (再現手順)

Change user picture.
Add bookmark some pages.

What happens? (症状)

user picture of bookmarked (or visited) user is broken link.

What is the expected result? (期待される動作)

The uploaded picture appears.

Note

Growi uses user cache in local storage
this cache update only by a time trigger.
https://github.com/weseek/growi/blob/master/src/client/js/components/User/UserPictureList.jsx#L20

Resolved. Please update the Growi app to v4.0.5.


Clean up public API of Dependencies

The problem with Dependencies is that the parameter lists grow longer and longer, as more flags are added. I'll just add the flags to the parameter lists for now; any solution to the problem of the longer parameter lists will break binary compatibility anyway (though source compatibility might be retained).
One possible solution would be do to it like FAKE:
// define test dlls
let testDlls = !! (testDir + "/Test.*.dll")

Target "xUnitTest" (fun _ ->
    testDlls
        |> xUnit (fun p ->
            {p with
                ShadowCopy = false;
                HtmlOutput = true;
                XmlOutput = true;
                OutputDir = testDir })
)

What do you think of the syntax of the xUnit function?
Other possible syntax options:
The GitHub Repository dungpa/dsls-in-action-fsharp (which is worth reading by itself) contains a F# DSL Cheatsheet which lists syntax constructs in F# that are useful for creating DSLs, like the parameter specification DSL of FAKE.
Backwards compatibility
From the pull request #843 where this question originally arised:

@cr7pt0gr4ph7:
One important thing to know would be if you want to achieve binary backwards compatibility (which is hard in F#, escpecially for record types, as far as I know), or only source level backwards compatibility like FAKE?
Response by @forki:
we don't need binary backwards compat. There is only Paket.VisualStudio as consumer at the moment.

Using F# Computation Expressions in the way that is outlined here, for example, one can achieve the following syntax:
// Short form
Dependencies.Locate().InstallWithOptions { Force true; Hard false }

// Long form
Dependencies.Locate().InstallWithOptions {
    Force force
    Hard hard
    OnlyReferenced (results.Contains <@ InstallArgs.Install_Only_Referenced @>)
}

The code required for this looks like this:
type SmartInstallOptionsBuilder<'a>(run: SmartInstallOptions -> 'a) =
    member x.Yield (()) = SmartInstallOptions.Default

    member x.Run(options: SmartInstallOptions) = run(options)

    [<CustomOperation("Force")>]
    member x.Force (options: SmartInstallOptions, force: bool) =
        { options with Common = { options.Common with Force = force} }

    [<CustomOperation("Hard")>]
    member x.Hard (options: SmartInstallOptions, hard: bool) =
        { options with Common = { options.Common with Hard = hard } }

    [<CustomOperation("Redirects")>]
    member x.Redirects (options: SmartInstallOptions, redirects: bool) =
        { options with Common = { options.Common with Redirects = redirects } }

    [<CustomOperation("OnlyReferenced")>]
    member x.OnlyReferenced (options: SmartInstallOptions, onlyReferenced: bool) =
        { options with OnlyReferenced = onlyReferenced }

This code is purely boilerplate and could be automatically generated.
The best message perhaps is that this solution also supports binary backwards compatibility w.r.t. adding new methods.

Honestly I think this is a bit too much ;-)

Refactoring the options into a record is a very good idea. But the CE is not making things easier since we want to have good C# support and keeping the API easy to understand for newcomers.

C# support is definitely a problem. Idiomatic C# code is mostly not idiomatic F# code, and vice versa.
Therfore, in my opinion, the best solution would be two separate public interfaces: One for F#, and another one for C#, VB.NET and other imperative languages.
My aim is to get rid of the need to add a new parameter + new overload each time a new parameter gets added, while not breaking source compatibility with existing clients.
The best solution for C# would be a mutable builder object. The latter can be used from F# as well, but it's not really idomatic.
For F#, named optional parameters could be used, but one cannot guarantee that users call the functions using parameter names instead of positional parameters.
To illustrate the problem I'm trying to solve:
/// Installs all dependencies.
member this.Install(force: bool, hard: bool) = this.Install(force, hard, false)

/// Installs all dependencies.
member this.Install(force: bool, hard: bool, withBindingRedirects: bool): unit =
    this.Install(force, hard, withBindingRedirects, false)

/// Installs all dependencies.
member this.Install(force: bool, hard: bool, withBindingRedirects: bool, onlyReferenced: bool): unit =
    this.Install({ SmartInstallOptions.Default with
                      Common = { SmartInstallOptions.Default.Common with Force = force; Hard = hard; Redirects = withBindingRedirects }
                      OnlyReferenced = onlyReferenced })

But maybe that just because I was exposed to [Gradle]Gradle for quite some time.
An example from the Gradle User Guide:
task myCopy(type: Copy)

myCopy {
   from 'resources'
   into 'target'
   include('**/*.txt', '**/*.xml', '**/*.properties')
}

That's nice syntax, but it's not really common in F#/C#. We should try to create only one api which is C# friendly.

One option for F# is the copy-and-update-syntax:
Dependencies.Locate().Install (fun p -> {
    p with
    Common = {
        p.Common with
        Force = force
        Hard = hard
        Redirects = withBindingRedirects
    }
    OnlyReferenced = results.Contains <@ InstallArgs.Install_Only_Referenced @>
})

Because F# record types are compiled to a class with a single constructor, which contains all fields, they're not really C#-user-friendly.

Alternative 3: Immutable builder
Usage sample:
Dependencies.Locate().InstallFluent(
    SmartInstallOptionsFluentBuilder()
        .Force(force)
        .Hard(hard)
        .OnlyReferenced(results.Contains <@ InstallArgs.Install_Only_Referenced @>))

Dependencies.Locate().InstallFluent (fun p ->
    p.Force(force)
     .Hard(hard)
     .OnlyReferenced(results.Contains <@ InstallArgs.Install_Only_Referenced @>)
)

Definition:
type SmartInstallOptionsFluentBuilder(options: SmartInstallOptions)=
    new() = SmartInstallOptionsFluentBuilder(SmartInstallOptions.Default)

    member x.GetResult() = options

    member x.Force (force: bool) =
        SmartInstallOptionsFluentBuilder { options with Common = { options.Common with Force = force} }

    member x.Hard (hard: bool) =
        SmartInstallOptionsFluentBuilder { options with Common = { options.Common with Hard = hard } }

    member x.Redirects (redirects: bool) =
        SmartInstallOptionsFluentBuilder { options with Common = { options.Common with Redirects = redirects } }

    member x.OnlyReferenced (onlyReferenced: bool) =
        SmartInstallOptionsFluentBuilder { options with OnlyReferenced = onlyReferenced }

The advantage of this is that is usable both from C# and F#.
Variation: Return the builder and provide builder.Execute()
I'm a bit ambivalent about this variant. This alternative looks nicer, but it makes it possible for the user to forget the .Execute():
Dependencies.Locate().CreateInstallBuilder()
    .Force(force)
    .Hard(hard)
    .OnlyReferenced(results.Contains <@ InstallArgs.Install_Only_Referenced @>)
    .Execute()

It is usable both from F# and C#, and reasonably idomatic in both.

yes that would be better, but .Force() would be easier to use

For individual users, Force() would be easier to use. For the implementation of the Paket.exe command line, .Force(forceFlag) would be better. Therefore, I'd vote to have both .Force() and .Force(forceFlag: bool).

Alternative 5: Mutable objects
Just ignore immutability and use mutable objects:
Dependencies.Locate().Install (new InstallOptionsBuilder(Force = force, Hard = hard, OnlyReferenced = results.Contains <@ InstallArgs.Install_Only_Referenced @>))

This alternative is usable both from C# and F#, and looks quite nice. This is the pattern that is often used by C# libraries. The one disadvantage is that it is not really functional, and one has to be aware that the object must be cloned before it is changed.

Summary
To sum up, I think that only Alternative 4 (Return the builder) and Alternative 5 (Mutable objects) are fullfilling all of these constraints:

Common interface for C# and F#
Easy usability both from C# and F#
User code looks nice in both languages
Source level backwards compatibility possible
Binary backwards compatibility possible

I'm a bit indecisive between the two. From the standpoint of immutability, I would prefer Alternative 4. From the standpoint of concise code / amount of code required (both in Paket's library and in user code), Alternative 5 could be considered the winner.

@cr7pt0gr4ph7 good job! I agree we have a lot of huge parameter lists in the code base - not only in the public API.
I actually like Alternative 3 for public API and the generated records for internal processing...
I'm also not too concerned about breaking changes at this point.


Vim hangs with custom statusline in Windows

See itchyny/lightline.vim#121. I configured lightline.vim with:
let g:lightline = {
      \ 'component_function': {
      \   'filename': 'LightLineFilename' } }

function! LightLineFilename()
  let fname = expand('%:t')
  return fname == '__Tag_List__' ? '' :
        \ fname == 'ControlP' ? '' :
        \ fname =~ 'NERD_tree' ?
        \   (exists('g:NERDTreeFileNode') &&
        \     has_key(g:NERDTreeFileNode.GetSelected(), 'path') ?
        \     g:NERDTreeFileNode.GetSelected().path.getLastPathComponent(0) :
        \     '') :
        \ '' != fname ? fname : '[No Name]'
endfunction

Then statusline of NERDTree shows filename of the file node which cursor points to. But when I open gVim in C:\Users\<USER>, it hangs and I can't interact.

If I use empty statusline, then NERDTree opens with an error message NERDTree: 3 file(s) could not be loaded into the NERD tree. Also, if I open NERDTree on other directories and then change directory of it to the C:\Users\<USER>, there is no such problem.
I executed :debug NERDTree and it seems to stuck in redraw command on call nerdtree#echoWarning. How can I look into this problem?

Also this problem is reproducible without using lightline.vim. This is a minimal vimrc:
set nocompatible
filetype off
call plug#begin()
" Enable NERDTree
Plug 'scrooloose/nerdtree'
call plug#end()
filetype plugin indent on
syntax on

let g:NERDTreeStatusline = "%{exists('g:NERDTreeFileNode')&&" .
      \ "has_key(g:NERDTreeFileNode.GetSelected(),'path')?" .
      \ "g:NERDTreeFileNode.GetSelected().path.getLastPathComponent(0):''}"

Is it bug of NERDTree, or is it wrong using some NERDTree functions inside the statusline of NERDTree? Maybe I should find some workarounds.

@yous, I've been going through the backlog of issues. I cannot reproduce this issue, and it's possible a fix was introduced since you raised the issue. Can you provide more information about this, or close the issue?

Hi, @PhilRunninger. This issue is quite old, and I'm not using NERDTree now, so it would take some time to reproduce this. If this was fixed by recent updates, I'll close this.

Hi, I can tell this is still reproducible with Windows gVim and Vim.

Make a file with above minimal vimrc (e.g. tmp.vimrc)
Open Vim with tmp.vimrc (gvim.exe -u tmp.vimrc or vim.exe -u tmp.vimrc)
Run :NERDTree

Then Vim freezes until I press Ctrl-C, and after I press it, Vim doesn't accept inputs.
I used official gVim release:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Apr 23 2017 20:01:28)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-586
Compiled by mool@tororo
Huge version with GUI.   I was testing it on my Mac. I'll look at it later on my Windows machine.


Used dir prop of PanelGroup for rtl support instead of document.dir

This allow us to use this component in scenarios where PanelGroup is used as a component in an application where you don't have access to document.dir in order to change it for any reason, there is already a dir prop as it is standard HTMLElement prop we just have to use it instead of relying on document.dir which is not a good practice at all, one may choose to apply dir at any level below document to an element and its children, for example:

story book component
components with dir=rtl and ltr side by side in a single page
...

thanks for awesome library

I'm open to the idea of allow rtl/ltr to be specified on the component level, and I understand why you'd suggest using the dir attribute for this, but I think it complicates the DevX. TypeScript won't provide any hints about this value, but more importantly– having both direction and dir seems confusing.
We could address the first issue by updating the PanelGroupProps props definition to explicitly call out dir?: "auto" | "ltr" | "rtl" but I'm concerned about the awkward mix of dir and direction.
The only alternative approach that comes to mind would be to overload the direction prop to enable this (e.g. "direction" | "direction-ltr" | "direction-rtl")
What are your thoughts here?

OK, thanks for the response, here are my thoughts:

relying on document.anything is not recommended practice overall, as this is a component and should not assume access to outside of it's boundaries
dir is standard html attribute and by specifying HTMLAttributes<keyof HTMLElementTagNameMap> as part of the type for PanelGroup people expect dir to be there and work, the autocomplete also show dir to people
many design system and component libraries support providing a dir to their subtree through context api, for example in antd or radixui which shadcn is based on, the user base of these libraries are non-trivial, adopting the same practice would simplify things as lots of people are used to this, this change will likely be adopted by these ui libraries as for example shadcn uses this package
in libraries there is usually an orientation: 'horizontal' | 'vertical' instead of direction, direction is commonly used for writing direction in css
the changes should be in a way that does not break code that use this package and already rely on direction and document.dir hack
I would introduce an orientation?: 'horizontal' | 'vertical' prop that works exactly as the current direction and mark the direction as obsolete so people would gradually replace it, and use dir for rtl and ltr as it is already there, just not implemented

if you agree I would be happy to change this PR

dir is standard html attribute and by specifying HTMLAttributes<keyof HTMLElementTagNameMap> as part of the type for PanelGroup people expect dir to be there and work, the autocomplete also show dir to people

Yes, but it wouldn't suggest valid values for it.

I would introduce an orientation?: 'horizontal' | 'vertical' prop that works exactly as the current direction and mark the direction as obsolete so people would gradually replace it, and use dir for rtl and ltr as it is already there, just not implemented

I know we're getting into semantics now, but I think of "orientation" as being something related to a screen or a device (rotation, maybe aspect ration). "direction" in this case is the correct term, I think.

relying on document.anything is not recommended practice overall, as this is a component and should not assume access to outside of it's boundaries

Agreed that this library shouldn't be reading this value from the document. I think this is the most compelling point in the thread here, and we shouldn't be relying on either the document or requiring an explicit attribute. We should probably be using getComputedStyle to read the inherited direction style (which I think will work with both CSS direction and the dir attribute (based on my own testing).
I'll take a pass at this and tag you on a PR.

The change described above has been published in<EMAIL_ADDRESS>


Luca6804/snap edits

Description
@har13205 @JamesMBallard these are the changes I came up with for the list model. The UI could use some polishing still, but the general idea is there. I don't know that it reduces the overall number of lines of code, but I think it massively simplifies the UI and the state logic, and follows more established patterns. Let me know what you think. We can merge it into Harini's branch and have her continue on with it if we like the general idea
Type of change

[ ] Bug fix
[ ] New sample implementation
[ ] Sample viewer enhancement
[ ] Other enhancement

Platforms tested on:

[ ] Windows
[ ] Android
[ ] Linux
[ ] macOS
[ ] iOS

Checklist

[ ] Runs and compiles on all active platforms as a standalone sample
[ ] Runs and compiles in the sample viewer(s)
[ ] Branch is up to date with the latest main/v.next
[ ] All merge conflicts have been resolved
[ ] Self-review of changes
[ ] There are no warnings related to changes
[ ] No unrelated changes have been made to any other code or project files
[ ] Code is commented with correct formatting (CTRL+i)
[ ] All variable and method names are camel case
[ ] There is no leftover commented code
[ ] Screenshots are correct size and display in description tab (500px by 500px, platform agnostic)
[ ] If adding a new sample, it is added to the sample viewer
[ ] Cherry-picked to Main branch (if applicable)

@ldanzinger conflicts are resolved and the branch is ready to merge


glaze macro not working

Hi
Thanks for the awsome contributions, howerver, the macro dose not work. The test code sourced from glaze_example
cmake
cmake_minimum_required(VERSION 3.18)

project(
   glaze_example
   VERSION 0.0.1
   LANGUAGES CXX
)

file(GLOB srcs src/*.cpp include/*.hpp)

include(FetchContent)

FetchContent_Declare(
  glaze
  GIT_REPOSITORY https://github.com/stephenberry/glaze.git
  GIT_TAG main
  GIT_SHALLOW TRUE
)

FetchContent_MakeAvailable(glaze)

add_executable(${PROJECT_NAME} ${srcs})
set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 20)

target_include_directories(${PROJECT_NAME} PRIVATE include)
target_link_libraries(${PROJECT_NAME} PRIVATE glaze::glaze)

example
#include "example.hpp"

struct macro_t {
   double x = 5.0;
   std::string y = "yay!";
   int z = 55;
};

GLZ_META(macro_t, x, y, z);

struct local_macro_t {
   double x = 5.0;
   std::string y = "yay!";
   int z = 55;

   GLZ_LOCAL_META(local_macro_t, x, y, z);
};

int main()
{
    return 0;
}

errors
❯ make
Consolidate compiler generated dependencies of target glaze_example
[ 50%] Building CXX object CMakeFiles/glaze_example.dir/src/example.cpp.o
/home/swei/github/json/glaze_example/src/example.cpp:9:19: error: ‘x’ has not been declared
    9 | GLZ_META(macro_t, x, y, z);
      |                   ^
/home/swei/github/json/glaze_example/src/example.cpp:9:22: error: ‘y’ has not been declared
    9 | GLZ_META(macro_t, x, y, z);
      |                      ^
/home/swei/github/json/glaze_example/src/example.cpp:9:25: error: ‘z’ has not been declared
    9 | GLZ_META(macro_t, x, y, z);
      |                         ^
/home/swei/github/json/glaze_example/src/example.cpp:9:27: error: expected constructor, destructor, or type conversion before ‘;’ token
    9 | GLZ_META(macro_t, x, y, z);
      |                           ^
/home/swei/github/json/glaze_example/src/example.cpp:16:34: error: ‘x’ is not a type
   16 |    GLZ_LOCAL_META(local_macro_t, x, y, z);
      |                                  ^
/home/swei/github/json/glaze_example/src/example.cpp:16:37: error: ‘y’ is not a type
   16 |    GLZ_LOCAL_META(local_macro_t, x, y, z);
      |                                     ^
/home/swei/github/json/glaze_example/src/example.cpp:16:40: error: ‘z’ is not a type
   16 |    GLZ_LOCAL_META(local_macro_t, x, y, z);
      |                                        ^
/home/swei/github/json/glaze_example/src/example.cpp:16:4: error: ISO C++ forbids declaration of ‘GLZ_LOCAL_META’ with no type [-fpermissive]
   16 |    GLZ_LOCAL_META(local_macro_t, x, y, z);
      |    ^~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/glaze_example.dir/build.make:76: CMakeFiles/glaze_example.dir/src/example.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/glaze_example.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

Yeah, the glaze macros have to be explicitly included via: #include "glaze/core/macros.hpp"
We could automatically include the macros, but we try to avoid macros as much as possible and don't want to create potential conflicts.
We'll also try to document this better in the README

Superb! The compliler dose not complain about missing macro definition but variable-undefined, this solved the issue, the macro is so convenient, thanks!


For Graphql people can we create the client like this and instantiate on start. this is just an idea

import { ApolloClient, split, HttpLink, from } from '@apollo/client';

import { WebSocketLink } from '@apollo/client/link/ws';
import { SubscriptionClient } from 'subscriptions-transport-ws';

import Config from 'react-native-config';
import { stores } from '../../stores';

export class Client implements IService {
  private inited = false;
  private GQLClient = ApolloClient;
  private Token = '';
  private GRAPHQL_URI = '';
  private WS_URI = '';

  init = async (): PVoid => {
    if (!this.inited) {
      this.setToken();
      this.setHttpUrl();
      this.setWssUrl();
      this.inited = true;
    }
  };

  //httpLink
  private httpLink = new HttpLink({
    uri: this.GRAPHQL_URI,
    credentials: 'include',
  });

  //webSocketLink
  private wsClient = new SubscriptionClient(this.WS_URI, {
    lazy: true,
    reconnect: true,
    connectionParams: async () => {
      const token = this.Token;
      return {
        authToken: token ? `Bearer ${token}` : null,
      };
    },
  });

  setHttpUrl = (): void => {
    this.GRAPHQL_URI =
      Config.APP_ENV !== 'production' ? Config.LOCAL_SERVER_URL : Config.SERVER_URL;
  };

  setWssUrl = (): void => {
    this.WS_URI = Config.APP_ENV !== 'production' ? Config.LOCAL_SERVER_WS : Config.SERVER_WS;
  };

  setToken = (): void => {
    const token = stores.authUser.authUser.token;
    if (token) {
      this.Token = token;
    }
  };
}

Hello @Yasir5247! Is this a question? Or have you already tested this GQL service?

I have not tested it. but it's a good thing if we can have it.


update documented support for env variables

I'm pretty sure env variables work as expected, as you can see if you try running this app: https://github.com/dario-piotrowicz/next-apps-for-testing/blob/43f55d6b7e1538e5b8cb16221a3fea53896c8239/apps/simple-app-dir-13.3.1/next.config.js#L7

Screenshot from the test app's API response, demonstrating it working.


Google Drive's example refers to .xib outside of SVN project

https://code.google.com/p/google-api-objectivec-client/source/browse/trunk/Examp
les/DriveSample/DriveSample.xcodeproj/project.pbxproj#51 shows a reference to
GTMOAuth2Window.xib in "../../../gtm-oauth2/Source/Mac/GTMOAuth2Window.xib".
This directory doesn't exist. Since the OAuth2 source is in "Source/OAuth2",
the path should instead be "../../Source/OAuth2/Mac/GTMOAuth2Window.xib"

Xcode will fail to build the project as result.

Version 6.1 (6A1052d) on OS X 10.10 (14A389).

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 23 Oct 2014 at 5:42

I again have this problem with the file not found:

../../Source/OAuth2/Mac/GTMOAuth2Window.xib

But I don't see the folder OAuth2 under the source folder. Any idea?


InputEventPanGesture and InputEventMagnifyGesture wrongly interpreted as InputEventMouseButton on OSX (HTML5)

Godot version
v3.4.2.stable.official [45eaa2daf]
System information
Mac OSX (HTML5 Version)
Issue description
These input events are wrongly interpreted as InputEventMouseButton in HTML5 exports (and debug) even though they work correctly when running the app normally.
Steps to reproduce

Download the example repository
Start in web mode to see the incorrect event type
Start in normal mode to see the correct event type

Minimal reproduction project
https://github.com/tavurth/godot-pan-gesture

Duplicate of https://github.com/godotengine/godot/issues/13139.


Create PoC for template-set artifact manager

Follow up of: #1517
As a CobiGen GUI developer, I want CobiGen to store/manage the template-set artifacts so that the GUI can access this information in a timely manner.
Problems to solve:

Come up with a caching procedure (cache responses) in a separate file
Check if caching is necessary (performance wise)
Come up with an updating process (how to detect if template-set.xml's are outdated)
Find a state of CobiGen to initialize the storage process

use mvn for resolving template-set.xml files to reuse maven behavior for caching / snapshot resolution
lookup on UI startup
parallel lookup (if needed / max. non-virtual cores)


Workspace Manager Member S360 Corrective Change

ARM (Control Plane) API Specification Update Pull Request
PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

[1] ARM review queue (for merge queues, see [4])
The PRs are processed by time opened, ascending. Your PR may show up on 2nd or later page.
If you addressed Step 1 from the diagram and your PR is not showing up in the queue, ensure the label ARMChangesRequested
is removed from your PR. This should cause the label WaitForARMFeedback to be added.
[2] https://aka.ms/azsdk/support/specreview-channel
[3] List of SDK breaking changes approvers in pinned Teams announcement
[4] public repo merge queue, private repo merge queue (for ARM review queue, [1])
If you need further help with anything, see Getting help section below.
Purpose of this PR
What's the purpose of this PR? Check all that apply. This is mandatory!

[ ] New API version. (Such PR should have been generated with OpenAPI Hub, per this wiki doc.)
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[x] Update existing version to fix swagger quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[ ] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[ ] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to Step 2, "ARM Review", for this PR.

Breaking changes review (Step 1)

If the automation determines you have breaking changes, i.e. Step 1 from the diagram applies to you,
you must follow the breaking changes process.
IMPORTANT This applies even if:

The tool fails while it shouldn't, e.g. due to runtime exception, or incorrect detection of breaking changes.
You believe there is no need for you to request breaking change approval, for any reason.
Such claims must be reviewed, and the process is the same.

ARM API changes review (Step 2)

If this PR is in purview of ARM review then automation will add the ARMReview label.
If you want to force ARM review, add the label yourself.
Proceed according to the diagram at the top of this comment.

Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.
Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.
Getting help

For general PR approval workflow, see the diagram at the top of this comment.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

S360 Items:

https://openapihub.azure-devex-tools.com/amekpis/correctness/detail?errorId=9CAD6AFD-46F4-4002-AFAF-09AC38DC5622
https://openapihub.azure-devex-tools.com/amekpis/correctness/detail?errorId=19DCD436-951B-480A-ABA4-E3238334E1CF
https://openapihub.azure-devex-tools.com/amekpis/correctness/detail?errorId=0CFB49D5-159F-45AC-9E86-8CE9DCE96D74
https://openapihub.azure-devex-tools.com/amekpis/correctness/detail?errorId=60EEBEE7-C04C-4047-9078-6FEE560EE44C
https://openapihub.azure-devex-tools.com/amekpis/correctness/detail?errorId=52DEA1D3-91F9-44FE-B34E-63D23BDB46CC
https://openapihub.azure-devex-tools.com/amekpis/correctness/detail?errorId=8E200DA9-5BAE-4B44-A806-8CDEDF2A9BD5

/pr RequestMerge


chown -R on Alluxio 2.2.1 does not change all child inodes owner/group

Alluxio Version:
What version of Alluxio are you using?
2.2.1
Describe the bug
A clear and concise description of what the bug is.
chown -R can not change all subdir or file to correct user/group
To Reproduce
use alluxio fs chown -R user:group /path command to change /path owner
where will be 4 combination in subdir and file:
user_new:group_new
user_old:group_old
user_new:group_old
user_old:group_new
and which user/group will a subdir or path belong can not predict
there are no log even in debug mode

I had a session with @JySongWithZhangCe and confirmed on the above behavior.
The directory is not too deeply nested but pretty large each. We tried an example like /A/B1~100/C1~1000 where we did alluxio fs -R new_user:new_group /A. And we had the below observations:

This is very likely a regression. @JySongWithZhangCe 's team upgraded from 2.1 to 2.2.1 and immediately had this issue. Their team performs chown operations very frequently and they should be able to identify the same issue had it existed in 2.1. @JySongWithZhangCe can you please confirm on the open source version of Alluxio which is verified to be fine?

Many grand children are not successfully updated and end in one of the 4 combinations.

As far as we observe, ALL the children in one particular directory are in one user:group combination. @JySongWithZhangCe can you please confirm on this?

The call took only a few seconds to complete and completed successfully. We found no logs on master or client side regarding this chown operation.

I had a session with @JySongWithZhangCe and confirmed on the above behavior.
The directory is not too deeply nested but pretty large each. We tried an example like /A/B1-100/C1-1000 where we did alluxio fs -R new_user:new_group /A. And we had the below observations:

This is very likely a regression. @JySongWithZhangCe 's team upgraded from 2.1 to 2.2.1 and immediately had this issue. Their team performs chown operations very frequently and they should be able to identify the same issue had it existed in 2.1. @JySongWithZhangCe can you please confirm on the open source version of Alluxio which is verified to be fine?

Many grand children are not successfully updated and end in one of the 4 combinations.
As far as we observe, ALL the children in one particular directory are in one user:group combination. @JySongWithZhangCe can you please confirm on this?
The call took only a few seconds to complete and completed successfully. We found no logs on master or client side regarding this chown operation.

All Alluxio version used before did right work in this case, which are 1.7.0, 1.7.1, 1.8.1, 1.8.2, 2.1.1
4.Yes

I had a session with @JySongWithZhangCe and confirmed on the above behavior.
The directory is not too deeply nested but pretty large each. We tried an example like /A/B1-100/C1-1000 where we did alluxio fs -R new_user:new_group /A. And we had the below observations:

This is very likely a regression. @JySongWithZhangCe 's team upgraded from 2.1 to 2.2.1 and immediately had this issue. Their team performs chown operations very frequently and they should be able to identify the same issue had it existed in 2.1. @JySongWithZhangCe can you please confirm on the open source version of Alluxio which is verified to be fine?

Many grand children are not successfully updated and end in one of the 4 combinations.
As far as we observe, ALL the children in one particular directory are in one user:group combination. @JySongWithZhangCe can you please confirm on this?
The call took only a few seconds to complete and completed successfully. We found no logs on master or client side regarding this chown operation.

All Alluxio version used before did right work in this case, which are 1.7.0, 1.7.1, 1.8.1, 1.8.2, 2.1.1
4.Yes

I had a session with @JySongWithZhangCe and confirmed on the above behavior.
The directory is not too deeply nested but pretty large each. We tried an example like /A/B1-100/C1-1000 where we did alluxio fs -R new_user:new_group /A. And we had the below observations:

This is very likely a regression. @JySongWithZhangCe 's team upgraded from 2.1 to 2.2.1 and immediately had this issue. Their team performs chown operations very frequently and they should be able to identify the same issue had it existed in 2.1. @JySongWithZhangCe can you please confirm on the open source version of Alluxio which is verified to be fine?

Many grand children are not successfully updated and end in one of the 4 combinations.
As far as we observe, ALL the children in one particular directory are in one user:group combination. @JySongWithZhangCe can you please confirm on this?
The call took only a few seconds to complete and completed successfully. We found no logs on master or client side regarding this chown operation.

All Alluxio version used before did right work in this case, which are 1.7.0, 1.7.1, 1.8.1, 1.8.2, 2.1.1
4.Yes

@JySongWithZhangCe can you reproduce this issue with a single entry at each level, i.e., the tree is  /A/B/C and then alluxio fs chown -R new_user:new_group /A?

This is how I tried to reproduce
(base) ➜  alluxio git:(master) ✗ for i in $(seq 1 10); do for j in $(seq 1 10); do afs mkdir /a/b${i}/c${j}; done; done
(base) ➜  alluxio git:(master) ✗ afs ls /a/b8/
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:53:53:706  DIR /a/b8/c1
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:54:03:785  DIR /a/b8/c10
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:53:54:826  DIR /a/b8/c2
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:53:55:956  DIR /a/b8/c3
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:53:57:073  DIR /a/b8/c4
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:53:58:185  DIR /a/b8/c5
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:53:59:301  DIR /a/b8/c6
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:54:00:432  DIR /a/b8/c7
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:54:01:545  DIR /a/b8/c8
drwxr-xr-x  adit           staff                        0   NOT_PERSISTED 06-03-2020 08:54:02:666  DIR /a/b8/c9
(base) ➜  alluxio git:(master) ✗ afs chown -R root:wheel /a
Changed owner:group of /a to root:wheel.
(base) ➜  alluxio git:(master) ✗ afs ls /a/b8/
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:53:53:706  DIR /a/b8/c1
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:54:03:785  DIR /a/b8/c10
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:53:54:826  DIR /a/b8/c2
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:53:55:956  DIR /a/b8/c3
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:53:57:073  DIR /a/b8/c4
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:53:58:185  DIR /a/b8/c5
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:53:59:301  DIR /a/b8/c6
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:54:00:432  DIR /a/b8/c7
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:54:01:545  DIR /a/b8/c8
drwxr-xr-x  root           wheel                        0   NOT_PERSISTED 06-03-2020 08:54:02:666  DIR /a/b8/c9
(base) ➜  alluxio git:(master) ✗ afs ls /a/
drwxr-xr-x  root           wheel                        1   NOT_PERSISTED 06-03-2020 08:32:56:399  DIR /a/b
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:52:44:824  DIR /a/b1
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:54:27:836  DIR /a/b10
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:52:56:375  DIR /a/b2
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:53:07:523  DIR /a/b3
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:53:18:761  DIR /a/b4
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:53:30:055  DIR /a/b5
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:53:41:259  DIR /a/b6
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:53:52:577  DIR /a/b7
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:54:03:785  DIR /a/b8
drwxr-xr-x  root           wheel                       10   NOT_PERSISTED 06-03-2020 08:54:16:577  DIR /a/b9

@JySongWithZhangCe I am trying to reproduce this issue from our side. I assume /a /b and /c are all directories. Is there any possible for me to know the estimated number of files under each directory?

@JySongWithZhangCe I am trying to reproduce this issue from our side. I assume /a /b and /c are all directories. Is there any possible for me to know the estimated number of files under each directory?

Will close it for now, feel free to reopen it and contact us if this is still valid.


Advanced text selection

Many existing programs including web browsers incorporate this selection model:

[x] Click and hold, then drag around to select text from the exact point of your first click.
[ ] Double click to select a single word. Hold your second click and drag around to select whole words at once. Some programs pick trailing spaces, but let you unselect them, by draging back.
[ ] Triple click to select a paragraph. Hold your third click and drag around to select whole paragraphs. For preformatted blocks it could be just lines.

Lagrange currently implements just the first one, but I think it would be cool, if it did all three. I use this fairly often, to follow the text better, but obvously the primary usecase is time-efficient copy-pasting 😄

I agree on the usefulness, and actually have this on my to-do list. It has fallen pretty far down the list, though, with more important things having taken priority. Maybe it's now time to implement this..


deny-licenses mistakenly blocking LGPL-3.0 license

Summary:
When I list LGPL-2.0,LGPLLR as my deny-license list and have PyGitHub==2.1.1 as a third party in my requirements.txt file then the dependency-review action blocks the pull request as a incompatible issue. The problem is that PyGitHub is a LGPL-3.0, not LGPL-2.0 license.
Replicate:

Have dependency-review-action setup like below:

name: 'Dependency Review'
on: [pull_request]

permissions:
  contents: read
  pull-requests: write

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v3
      - name: 'Dependency Review'
        uses<EMAIL_ADDRESS>        with:
          comment-summary-in-pr: true
          deny-licenses: LGPL-2.0,LGPLLR

Open a pull request with a requirements.txt listing PyGithub==2.1.1
Check PR dependency-review-action failure.

Sample Output:

Hi @logan-porelle, I've been trying to reproduce this and I haven't been able to so far. Is it still something that you're running into?


Add failing test for matchAllStrictGroups

@staabm maybe whenever you have time you can have a look (after vacation! Really not urgent) here.
I tried adding the matchAll variants here https://github.com/composer/pcre/blob/5cc3c12e20f5ed14a45a481b474f7b9788156979/src/PHPStan/PregMatchTypeSpecifyingExtension.php#L85 but this does not help as it marks the wrong thing not-null I believe.
There is a secondary similar problem to this on the main branch with offset capture https://github.com/composer/pcre/commit/5cc3c12e20f5ed14a45a481b474f7b9788156979#diff-0809405debfb0987519b2d18d3b011f43563ef0ae298e425bd1c931f4b83e3a1R99 whereas this code here is not smart enough to handle the capture array shape https://github.com/composer/pcre/commit/5cc3c12e20f5ed14a45a481b474f7b9788156979#diff-decc762a6a5c114c9d14da4184465733952f6cf8c38f2b4afe7d82d3832169ecR59-R70

running the added test-case in isolation works for me
<?php // test.php

namespace PregMatchShapes;

require 'vendor/autoload.php';

use Composer\Pcre\Preg;

function assertType($s, $m) {
    var_dump($m);
}

function doFoo($s) {
    if (Preg::isMatchAllStrictGroups('/Price: (?<test>£|€)?\d+/', $s, $matches)) {
        assertType('array{0: list<string>, test: list<non-empty-string>, 1: list<non-empty-string>}', $matches);
    }
}

➜  pcre git:(2.x) ✗ vendor/bin/phpstan analyze test.php --debug
Note: Using configuration file /Users/staabm/workspace/pcre/phpstan.neon.dist.
/Users/staabm/workspace/pcre/test.php
 ------ -----------------------------------------------------------------------------------------------------
  Line   test.php
 ------ -----------------------------------------------------------------------------------------------------
  9      Function PregMatchShapes\assertType() has no return type specified.
  9      Function PregMatchShapes\assertType() has parameter $m with no type specified.
  9      Function PregMatchShapes\assertType() has parameter $s with no type specified.
  13     Function PregMatchShapes\doFoo() has no return type specified.
  13     Function PregMatchShapes\doFoo() has parameter $s with no type specified.
  14     The isMatchAllStrictGroups call is unsafe as match groups "test", "1" are optional and may be null.
 ------ -----------------------------------------------------------------------------------------------------

update: oh my bad.. found the bug in my repro

I am again at vacation but I guess we need a similar fix as the one recently merged but in a different extension

Yeah no rush, thanks. I tried to port that code but didn't manage..


changes in farsi lang :: Login page Title

hi dear Volkan. please use latest farsi language files. there are several problems in older ones.

Hi @misafer, i manually took your serenity.texts.fa.json, it contains german texts don't know why


Docs/faq update

FAQ entry for adding token directly into the database instead of using username/password

Thank you!

Happy to contribute, thank you for an AMAZING tool.


Actually smart tabbing

Vim's python's syntax file sets softtabstop to shiftwidth (or something equivalent). This won't work for haskell, but this might:
function! SoftBackspace()
python << endpython
import vim
# get current indent level
# get previous indent level
# get softtabstop
# get current position
# get subsequent softtabstop multiple
# if    softtabstop > 0 and
#       current_position < current_indent_level and
#       next_sts_pos < prev_indent_level < current_position:
#           dedent to prev_indent_level
# else:
#       call regular backspace
# if previous indent level within softtabstop:
def indent_of(line, tabsize):
    line = line.expandtabs(tabsize)
    return len(line) - len(line.lstrip())
# find next lower level index
# go back one line at a time, for a max of ... 50?
# stop condition: indent is less than current indent
#   return target indent
# stop condition: current indent is greater than previous indent (excluding current line)
#   bad idea -> multiple if clauses have plausible reindents. DO NOT DO THIS
# reach end of segment
#   fallback upon regular BS behaviour
#   trigger by returning 0
def previous_indent_first(idx, tabsize, cindent, limit=50):
    while idx>=0 and limit>0:
        line = vim.current.buffer[idx]
        if not line.isalpha():
            lindent = indent_of(line, tabsize)
            if lindent < cindent:
                return lindent
        idx -= 1
        limit -= 1
    return 0
def previous_indent_nearest(idx, tabsize, cindent, limit=50):
    indents = [0]
    while idx>=0 and limit>0:
        line = vim.current.buffer[idx]
        if not line.isalpha():
            idents.append(indent_of(line, tabsize))
        idx -= 1
        limit -= 1
    return min(abs(cindent-i) for i in indents)
def elide(string, start, stop):
    return string[:start] + string[stop:]
softtab = int(vim.eval("&softtabstop"))
row,col = vim.current.window.cursor
cindent = indent_of(vim.current.line, softtab)
pindent = previous_indent_first(row-2, softtab, cindent)
stsdent = divmod(col, softtab)[0] * softtab
if  (   softtab > 0
    and col <= cindent
    and stsdent < pindent < col
    ):
    vim.current.line = elide(vim.current.line, pindent, col)
else:
    vim.command(":normal! i\b")
endpython
endfunction

function! SoftTab()
python << endpython
import vim
endpython
endfunction

set lazyredraw

au FileType haskell inoremap <buffer> <silent> <BS>  <C-o>:call SoftDedentBackspace()<CR>
au FileType haskell inoremap <buffer> <silent> <Tab> <C-o>:call SoftDedentTab()<CR>

I'm posting this because

tangentially related to this project

Currently, not finished.

I'm not planning to make haskell-vim depend on python support. I'd rather make a rewrite in Lua once NeoVim shapes up.

Created as SofterTabstop.


Add additional conflict resolution and synchronization modes

Currently, conflict resolution needs to be manually resolved, which is probably the best option for majority of scenarios but this is a big problem when using mutagen when the agent is not guaranteed to be running all the time.
One specific example of this is when using mutagen to synchronize volumes between a docker container and your host file system. Specifically, if you had a container that was previously running but was stopped and code changes were made while the container was stopped, re-starting the container causes a conflict because the file in the container differs from the one on the host machine.
I'd like to propose a way to specify which of the mount points should be used as canonical source when a conflict happens. For example, I'd like to be able that specify that in case of conflicts, any source file changes on the host (alpha) should take precedence over the same file inside the container (beta).
Without this the list of conflicts (and therefore files that don't get propagated) can grow really fast, specially in large codebases with a lot of contributions. Doing a git pull while the container was stopped would cause tens or hundreds of conflicts.
This also causes files who have been deleted from the host to re-appear after the container/agent starts again, since they exist inside the container.

Sorry for the slow response, I've been offline for a few days.  This is a great idea and actually something I'm hoping to implement this week (for related reasons).
My proposal would be to add a session configuration option (probably only as a create flag, not as a global option), named something like --conflict-resolution, where values could be safe (what happens currently, which would remain the default), alpha-wins, or beta-wins.  This would break the symmetry of the synchronization endpoints and allow one to override the other in the event that a conflict arises.
Does that sound reasonable?
I've also been toying with the idea of allowing a unidirectional sync in Mutagen at some point, essentially providing a slightly more cross-platform version of the rsync command, but this idea is still sort of half-baked.

Yes, that sounds ideal.
Let me know if I can provide any help developing this. I have experience with Go but would need some pointers in terms of how this would fit into the current codebase.

Cool.  My only hesitation is baking in the "alpha" "beta" nomenclature into the interface by naming the conflict resolution options after them, but even that can be changed later without breaking the way the session configuration is stored.
Since this is probably best applied only on a per-session basis, I'll probably exclude this from being specified in ~/mutagen.toml.
I should be able to crank this out either this afternoon or tomorrow.  I appreciate the offer for help, but fortunately this isn't a big change.

+1 for this as well!

I just wanted to chime in with a progress update on automatic conflict resolution. The tl;dr version is that I've implemented this, it's in master, it would be great if people want to test it (by downloading/building from master), but I'm not quite ready to release it because I think it can actually be extended to handle unidirectionality as well, and I don't want to lock in configuration options and terminology that can't be changed later.
So the implementation can be seen in this commit range.
The basic idea is that there's now a ConflictResolutionMode type in the sync package with one mode corresponding to the default value and five modes with different behavior. These five modes are:

safe: This is Mutagen's current default behavior, which entails propagating any non-conflicting changes, as well as changes that only overwrite deletions (i.e. changes that don't cause any sort of data loss).
alpha-wins: This is the same as safe, except that the alpha endpoint wins in the case of conflicting changes.
beta-wins: This is the same as alpha-wins, except that winner/loser behavior is reversed.
alpha-wins-all: This is the same as alpha-wins, except that alpha also wins in the case that a deletion on alpha conflicts with a modification on beta
beta-wins-all: This is the same as alpha-wins-all, except that winner/loser behavior is reversed.

I'm open to suggestions on the names. They can be changed later in the CLI without breaking existing sessions. They can be set in mutagen.toml, e.g.
[synchronization]
conflictResolutionMode = "alpha-wins-all"

or on the command line, e.g.
mutagen create --conflict-resolution-mode=alpha-wins-all ...

One important thing to note is that these are all conflict modes used in bidirectional synchronization. Changes can still propagate from one side to the other, and the conflict resolution mode only enters the picture when conflicts arise.
Now, another thing that's been discussed is unidirectional synchronization (i.e. mirroring from alpha to beta or vice-versa). This would basically make Mutagen behave like rsync except with file monitoring and ongoing synchronization.
I had originally planned to implement an enumeration with a few values specifying synchronization mode:

default (bidirectional)
unidirectional
bidirectional

The conflict resolution mode options would only apply in the bidirectional case, and there would be an analagous enumeration specifying deletion behavior in the unidirectional case. There would be options along the lines of:

default (delete-conflicting)
delete-conflicting: This would only delete files on the destination necessary to propagate files from the source. This would be useful if you wanted to (e.g.) mirror a source tree that generated files on the remote.
delete-extraneous: This would be the same as delete-conflicting but additionally delete any extraneous files on the destination that were not on the source. This would be useful if you wanted to make an exact replica.

Both of these can be accomplished by replacing the Reconcile three-way merge function with a simple Diff operation during the synchronization cycle, with delete-conflicting additionally filtering out any pure-deletion changes that come out of Diff.
However, I realized there might be an additional mode that made sense: delete-propagated. This would delete only those files that had been successfully propagated from the source. Any files that had been added or modified on the destination wouldn't be touched, and any that prevented change propagation from the source would generate a conflict (to be resolved by deleting the file on the destination). This would essentially be a safer form of delete-conflicting.
The trouble is that delete-propagated requires an ancestor snapshot representing what's been successfully propagated and a full Reconcile operation. What's interesting is that delete-conflicting and delete-extraneous can also be done using Reconcile if you'd like, with an ancestor snapshot that really doesn't enter into things but has the same role. This opportunity results from the fact that Diff(base, target) can be computed as a subset of the results from Reconcile(base, base, target).
So, at the moment, I'm trying to assess whether it actually makes sense to make unidirectional and bidirectional synchronization conceptually separate, or if it makes sense to treat unidirectional synchronization as a subset of bidirectional synchronization behavior, implemented through additional conflict resolution modes. If we do that, delete-propagated, delete-conflicting, and delete-extraneous would become additional conflict resolution modes (probably specialized for alpha-to-beta and beta-to-alpha directionalities). The question at that point is whether or not we need the concept of a synchronization mode at all, and additionally whether or not the conflict resolution mode ought to be promoted to this more general synchronization mode or still be called a "conflict resolution" mode. I think this needs a little bit of time to simmer in my brain. In particular, I want to understand (a) whether or not these proposed modes are useful, (b) whether or not these proposed modes are theoretically sound, (c) whether there are additional modes in this space that I haven't considered, and (d) how difficult these are to implement.  I'd like whatever set of modes I choose to fully span the space of useful synchronization topologies for users' workflows.
There are also a few nice side-effects of moving to Reconcile-based unidirectional synchronization. First, less code needs to change - only Reconcile's internals need to be modified. Second, by saving the ancestor snapshot, we can eventually facilitate mode switching, allowing you to start in a unidirectional mode and switch to a bidirectional mode, while still retaining some amount of history information (though that needs a bit of thought as well - it might be better just to erase the ancestor and start fresh).
In any case, there's a little bit left to think about. I'm open to input as well.
If you'd like to play with the existing conflict resolution, please feel free to test with a local build. It'll currently build as v0.8.0-dev. Be aware though that sessions created with this temporary build are not likely to be loadable with the final version of v0.8.0 because some of the Protocol Buffers definitions will probably change if I take the route described in this post. It will work against existing sessions and shouldn't taint them in any way, but it's best to play things safe and not rely on that. I'd suggest relocating ~/.mutagen temporarily if testing a development build (making sure to shut down the daemon first).
I'm leaving on holiday tomorrow, so I won't have time to get this out in a release before then, but I'll let these ideas simmer and wait for feedback. I'm planning to put out v0.8.0 with this and a few other goodies in the first week of the new year, and many more updates will follow shortly thereafter.
Thanks to everyone who's provided input on this.  Happy holidays and upcoming year to everyone!

@havoc-io this is great news. We'll give the conflict resolution a try and report back.
Also, thanks for the detailed write-up of your plans and thoughts. Our main use case would actually fit nicely into a unidirectional mode.
The idea of having unidirectional as special cases of bidirectional + conflict resolution makes sense to me, but I'm not familiar with the internals to understand the impact on the implementation.
Thanks for all the work on this!

I've just published v0.8.0-beta1, which includes what I'm hoping will be the final iteration of the synchronization mode(s) design.  I'm sorry it's taken so long - it's just a really difficult problem to get right and this release turned out enormous.  Documentation is still pending (should be done tomorrow), but I wanted to get this out for you all to play with ASAP.
Please note the beta1 tag on the release.  Also please note that while this release is compatible with v0.7.0-created sessions, it is not compatible with sessions created by versions you may have built from master, so you'll want to remove those before firing up the beta.
The basic summary is that there are now four synchronization modes that can be specified with the -m/--sync-mode flag to create:

two-way-safe: The default and "classic" Mutagen synchronization mode.  This is a bidirectional mode that only automatically resolves conflicts if no data would be lost (i.e. modifications can overwrite deletions).
two-way-resolved: This is the same as two-way-safe, except that the alpha endpoint automatically wins all conflicts, including cases where alpha's deletions would overwrite beta's modifications or creations.  This is equivalent to the alpha-wins-all mode of previous designs.
one-way-safe: This is a unidirectional mode that only allows changes to propagate from alpha to beta.  Deletions on beta are overwritten by content from alpha (i.e. the content comes right back), but modifications and creations on beta can't be overwritten by alpha (unless both endpoints have made the same modifications or created the same content).  I think this may be the most interesting mode for your use cases.
one-way-replica: This is a unidirectional mode that makes beta an exact mirror of alpha (modulo any ignored paths).  This is conceptually similar to rsync with the --delete flag - any modifications or new content on beta will be obliterated.

So hopefully that covers it.  I'll leave this issue open until I've tagged v0.8.0, but that will depend on your feedback and testing, so please have a look.

Sent from my iPhone

On 12 Feb 2019, at 17:53, Jacob Howard<EMAIL_ADDRESS>wrote:
I've just published v0.8.0-beta1, which includes what I'm hoping will be the final iteration of the synchronization mode(s) design. I'm sorry it's taken so long - it's just a really difficult problem to get right and this release turned out enormous. Documentation is still pending (should be done tomorrow), but I wanted to get this out for you all to play with ASAP.
Please note the beta1 tag on the release. Also please note that while this release is compatible with v0.7.0-created sessions, it is not compatible with sessions created by versions you may have built from master, so you'll want to remove those before firing up the beta.
The basic summary is that there are now four synchronization modes that can be specified with the -m/--sync-mode flag to create:
two-way-safe: The default and "classic" Mutagen synchronization mode. This is a bidirectional mode that only automatically resolves conflicts if no data would be lost (i.e. modifications can overwrite deletions).
two-way-resolved: This is the same as two-way-safe, except that the alpha endpoint automatically wins all conflicts, including cases where alpha's deletions would overwrite beta's modifications or creations. This is equivalent to the alpha-wins-all mode of previous designs.
one-way-safe: This is a unidirectional mode that only allows changes to propagate from alpha to beta. Deletions on beta are overwritten by content from alpha (i.e. the content comes right back), but modifications and creations on beta can't be overwritten by alpha (unless both endpoints have made the same modifications or created the same content). I think this may be the most interesting mode for your use cases.
one-way-replica: This is a unidirectional mode that makes beta an exact mirror of alpha (modulo any ignored paths). This is conceptually similar to rsync with the --delete flag - any modifications or new content on beta will be obliterated.
So hopefully that covers it. I'll leave this issue open until I've tagged v0.8.0, but that will depend on your feedback and testing, so please have a look.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@havoc-io that's awesome. We'll play with the new design and report back.
It sounds like two-way-resolved is what we need (weve been using alpha-wins-all` successfully) because our use case also involves some code generation that happens inside the container (beta) and needs to be sync'ed back to the host (alpha).
Thanks for all the work on this.

@havoc-io I had created a one way sync session like this:
	mutagen create \
	    --symlink-mode ignore \
	    --sync-mode "one-way-safe" \
	    docker://$DOCKER_URL/var/www/app/logs ~/app/logs

But I still got a conflict... I though the one-way sync would eliminate conflicts!
Version: 0.8.0-beta1 (I know I'm 1 behind)
--------------------------------------------------------------------------------
Session: c9b19c5c-5c99-4993-9916-7d2c3cd3b836
Alpha:
	URL: docker://639798a27e58e158e4165305af1c13c27c9197ce4189efcc39056e4ae006796e/var/www/app/logs
		DOCKER_HOST=tcp://<IP_ADDRESS>:2376
		DOCKER_TLS_VERIFY=1
		DOCKER_CERT_PATH=/Users/mattgill/.docker/machine/machines/default
	Status: Connected
Beta:
	URL: /Users/mattgill/app/logs
	Status: Connected
Status: Watching for changes
Conflicts:
	(α) local.log (<non-existent> -> File (516912c7b1e78d6853b7c2036270260e3b3e6660))
	(β) local.log (<non-existent> -> File (1d57f8af491b061ae5a25bcad892c1b4a74bb77e))
--------------------------------------------------------------------------------

I'll try updating to beta2 and using one-way-replica to see if that helps...
Any ideas?

@matthew-gill
What this conflict is showing is that both alpha and beta have created the same file but with different contents.  In the "safe" one-way mode, alpha's changes won't overwrite modified or newly created content on beta, so a conflict arises.
If you were to use one-way-replica, then you wouldn't see these conflicts (beta's local.log file would be overwritten), but you also wouldn't be able to make any additions/modifications to beta that wouldn't immediately be deleted/overwritten to match the content on alpha.
If you're okay with an exact replica of alpha, then one-way-replica might work.
one-way-safe would be useful for cases where you want to create additional content on beta, but still only want the synchronization to be one-way.  For example, maybe you have a Python application for which you want to create a virtualenv on beta, and for which you might generate .pyc files or __pycache__ directories.  Or perhaps you have an web application that you want to build and host on beta without synchronizing those build artifacts or .node_modules directories back to alpha.  In that case, you can use one-way-safe, and beta is allowed to be a superset of alpha.  If you need to use one-way-safe for these reasons, but you also have a file (e.g. local.log) that will be generated on both endpoints and hence yield a conflict, you can either ignore the conflict (since it won't prevent anything else from synchronizing) or ignore the file with a -i/--ignore specification.
Does that make sense and/or answer your question?

Yes it makes sense, thank you. Strange as I never changed the log on alpha! It may have just been had content from a previous session which caused the mismatch.
Apart from that, all going well with one way sync!

I meant to ask, further to this, does the conflict-resolution-mode flag still work in unidirectional sync?

The --conflict-resolution-mode flag no longer exists — it is supplanted by synchronization modes.
The mapping from --conflict-resolution-mode to --sync-mode looks something like:

safe becomes two-way-safe
alpha-wins no longer exists
alpha-wins-all becomes two-way-resolved
beta-wins no longer exists
beta-wins-all is equivalent to swapping the URL order and using two-way-resolved

In terms of the mappings to unidirectional synchronization, one-way-safe is analogous to two-way-safe and one-way-replica is analogous to two-way-resolved.
I tend to think of it as a 2x2 table:

Bidirectional
Unidirectional

Safe conflict resolution
two-way-safe
one-way-safe

Full conflict resolution
two-way-resolved
one-way-replica

But you can also think of it as a symmetry-breaking spectrum, starting at full safe symmetry to unsafe asymmetry.  E.g., if -> denotes propagation direction, and ->| denotes propagation direction with a safety barrier to avoid overwriting modifications and new content, then the spectrum looks something like:

two-way-safe: α |<->| β
two-way-resolved: α |<-> β
one-way-safe: α ->| β
one-way-replica: α -> β

This may only make sense in my head, so let me know if it's not clear.

No that makes perfect sense, thank you!

Hey @havoc-io I've been thinking on this again and I think reintroducing the conflict resolution flag would be useful on 'one-way-safe' if at all possible.
Here's my use case....
One way safe code into docker container
Docker container builds a load of css files and dumps them back into the code folder (requiring one way safe)
HOWEVER, sometimes our developers close the container and switch branch before restarting the docker container resulting in conflicts between alpha and beta.
Having a conflict resolution flag would fix this :)
Any ideas?

Hey @matthew-gill, I'm not really sure I fully understand the situation or desired behavior.
Just some quick questions:

Does the local (alpha-side) build also generate these resources (with potentially conflicting contents) at the same locations?
Are the conflicts on the files themselves or somehow indirectly caused by them (e.g. at a parent or child path)?
Is the Docker container resumed or completely recreated?
Is the synchronization session paused/resumed or completed recreated?
After a branch switch, is the build system which generates these files smart enough to handle overwriting build products from the other branch?  Or do the build products from the other branch's build need to be removed?

Thinking more generally, I'm not sure how many conflict resolution strategies you can have in a unidirectional synchronization mode.  I can really only imagine safe conflict resolution and full conflict resolution (i.e. what amounts to the previous alpha-wins-all conflict resolution in a unidirectional sense), which essentially yields the following behavior:

Alpha Content
Beta Content
Result (on Beta)

Safe resolution
[nothing]
[nothing]
[nothing]

A
A
A

A
B
Conflict

A
[nothing]
A

[nothing]
B
B1

Full resolution
[nothing]
[nothing]
[nothing]

A
A
A

A
B
A

A
[nothing]
A

[nothing]
B
[nothing]

1 Unless B is a child of a folder that was created and then deleted on alpha, in which case this would be a conflict.
I'm not really sure what other behavioral patterns could exist, unless they were time-dependent (i.e. doing different things on different cycles) or content-dependent (i.e. acting differently on different content), but that gets weird and hard to grok quickly.
My initial thought would be to just -i/--ignore these paths, and then they won't cause conflicts, but I may not be fully understanding the situation.

Does the local (alpha-side) build also generate these resources (with potentially conflicting contents) at the same locations?
-> No

Are the conflicts on the files themselves or somehow indirectly caused by them (e.g. at a parent or child path)?
-> The files themselves (e.g. container has code, checked out branch (same file) has changed)

Is the Docker container resumed or completely recreated?
-> I believe resumed

Is the synchronization session paused/resumed or completed recreated?
-> recreated

After a branch switch, is the build system which generates these files smart enough to handle overwriting build products from the other branch?  Or do the build products from the other branch's build need to be removed?
-> smart enough to handle

The advice I've been giving the developers in our team is to always maintain the same branch locally as what's synced into the container, which gives less chance for conflict when resuming. However, I think it still does occur occasionally:

Developer checks out branch A on laptop (alpha)
Mutagen running as normally
branch A is synced into docker container (beta)
mutagen is terminated and beta is shutdown (with branch a code)
developer checks out branch B on alpha
docker container is restarted
mutagen session is recreated
--- conflicts

I think this is where the conflict resolution in the one way safe would be useful. Which is along the lines of, "you both have copies of this code which don't resolve, but alpha should overwrite these changes"
I hope that makes sense!!

Okay, I see what you're saying (I think).  But it doesn't seem like the generated build products on beta would be the paths causing the conflicts (since they wouldn't exist on alpha and would thus be ignored in one-way-safe mode). It seems like it would be every other path that was conflicted. Right?
I'm imagining something like:

Developer checks out branch A on laptop (alpha)

Alpha content looks like:

code.js (with contents code-A)

Mutagen running as normally
branch A is synced into docker container (beta)

Beta contents look like:

code.js (with contents code-A)

And lets say code.js is run on beta and generates output.html (which isn't synchronized back but also isn't deleted since we're in one-way-safe mode), so beta contents now look like:

code.js (with contents code-A)
output.html (with contents html-A)

mutagen is terminated and beta is shutdown (with branch a code)
developer checks out branch B on alpha

Alpha content looks like:

code.js (with contents code-B)

docker container is restarted

Beta contents still look like:

code.js (with contents code-A)
output.html (with contents html-A)

mutagen session is recreated
--- conflicts

Conflict exists on code.js (contents code-B on alpha, code-A on beta), but not on output.html which only exists on beta.
In order to resolve this, the behavior would have to be different across different synchronization cycles.  You'd have to have behavior equivalent to one-way-replica on the first round of synchronization, but then switch to one-way-safe after that (because if you specified that alpha should win on all conflicts on every synchronization round, then build products would be obliterated on beta).  My initial inclination is that this might be a little too bespoke and confusing, and potentially ill-defined (e.g. what happens if the first synchronization cycle doesn't complete?).
Is it possible to avoid recreating the Mutagen synchronization session since you're re-using the container?  If it can be left alive (by either pausing/resuming or just being disconnected and waiting to reconnect), then it would be able to track the content changes across the branch switch (seeing that alpha had changed and beta had not).  At the moment, Mutagen is seeing newly created files on both endpoints since it's starting a new session without any history.

Thanks @havoc-io I'll try that! Inching closer to perfection :)

Thank you @matthew-gill, just let me know if that still doesn't quite cut it, we'll figure something out.

Quick question... what happens if I don't pause the mutagen but the docker goes away, when it comes back will it automatically resume/recover?

Mutagen will detect1 the "disconnection" (i.e. the underlying docker exec command returning).  It then goes into a loop where it tries to reconnect automatically every 30 seconds (which it will be able to do when the container comes back up).  This 30 second interval isn't configurable, but if you don't want to wait, then you can do
mutagen resume <session-specification>

and it will force a reconnection attempt immediately.

1 I'm working on optimizing this detection with a heartbeat mechanism, but it should be essentially instant on most platforms already since it gets a `SIGPIPE`.

OK I was gonna be lazy and not clean up the sessions, just wait for docker to come back... but based on this I'll do my best to pause and resume sessions accordingly.
I definitely owe you a docker best practises readme at some point :)

OK I was gonna be lazy and not clean up the sessions, just wait for docker to come back... but based on this I'll do my best to pause and resume sessions accordingly.

It's really fine to let them disconnect abruptly, it won't hurt anything. Save yourself the pause command.  I do this when I close my laptop and move somewhere else.  They'll just reconnect once they can or once forced via resume.

@matthew-gill that's exactly the same issue we hit. Pausing/resuming the sessions is working really smooth for us for the past couple of weeks.

Thanks for letting me know @divoxx I made the code changes to our helper tool to pause/resume and will be using it in anger next week... Fingers crossed!

Now that v0.8.0 has shipped, I would consider initial support for this complete.  Mutagen may add additional synchronization modes in the future, but I think the motivation and design for those might be better discussed individually in separate issues, so please don't hesitate to file an issue if the current modes don't fully support your workflow.

FWIW, I was using the pre-release alpha-wins-all strategy and it took me a while to parse the meaning of two-way-resolved.   resolved is not a term that's familiar to me.  My mental model is to try to map to scp or rsync.  In this framing, my intuition is that the alpha and beta terminology should be replaced with source and destination and then the sync-mode options should be two-way, one-way, and source-wins.  The rest is governed by the URL ordering.

@tristanz The term "resolved" in this case is just meant to reflect the action of "resolving" a conflict - i.e. it's two-way synchronization where all conflicts are automatically resolved (in alpha's favor).  The choice of that particular verb stems from the term "conflict resolution."
The "alpha/beta" nomenclature was chosen to emphasize the bidirectional nature (with equal precedence) of two-way synchronization (Mutagen's original lone synchronization mode).  I should say that it's not my favorite terminology (which is why I've tried to deemphasize it in the CLI), but using the terms "source" and "destination" really only works in the context of unidirectional synchronization (I feel).  It seems unnatural to say "bidirectional synchronization between a source and destination."  Even in the case of two-way-resolved synchronization, where the symmetry is broken in favor of alpha winning conflicts, it still doesn't really make sense to identify one side as the "source" and one as the "destination," since data flows both ways.
I guess my mental model is that scp and rsync are special cases where a more general symmetry breaks down.  They break symmetry in two dimensions actually: First, they're unidirectional, and second, they require that at most one URL be remote.  Since Mutagen exhibits the more general bidirectional symmetry (with no requirements on the locality of endpoints), I feel like a different and more general endpoint terminology is required, or at least desirable.
I would be up for changing the terminology.  Even "alpha" and "beta" have a natural ordering to them as names, so they don't completely emphasize the symmetry, but I was hoping they'd be enough to make users stop and grok the larger symmetry at play.  In the end though, I feel like they're just causing more confusion.  This is partly a documentation issue (which is my focus at the moment), and partly a discoverability issue (for which better terminology might help).
However, no matter which terms are chosen for the endpoint names, the URLs still have to be entered on the command line in some order (even if you're giving them equal precedence in bidirectional synchronization) and I feel like that's always going to bring to mind rsync and scp.  It's unclear to me how to indicate to users that a far more general symmetry is available for them to use, other than though documentation.
I'm completely open for suggestions on this though, and I've been careful to avoid adding any code that would lock in the "alpha/beta" terminology.

Thanks for response. Totally understand the perspective.
I'm mainly searching for how to make mutagen not need a wrapper script for my workflow.   Right now there are a number of aspects that make it feel a little less familiar if you're coming from an scp, rsync background.  For instance alpha, beta, sync-mode, sessions, etc.  Even though source/dest don't make total sense, I think for the standard remote-development use case it's pretty common to have a source and destination and want two-way-resolved semantics.  For perspective I currently wrap mutagen like so:
#!/bin/bash
#
# Peforms two-way syncing using mutagen, treating the local copy as definitive
# to simplify conflict resolution on reconnects.
#
# This script doesn't ignore most things, including .git in order to allow git
# commands on both sides. While there are some caveats here, this is generally
# not problematic so long as you don't concurrently run git operations on both sides,
# which is rare when developing locally in VSCode but executing remotely.
#
# Requires mutagen 0.8+ (https://mutagen.io/)
#
# Usage: bin/sync-dev-mutagen.sh ./ root@devbox:~/project

if  [ -z "$1" ] || [ -z "$2" ]; then
    echo "Example usage: bin/sync-dev-mutagen.sh ./ root@devbox:~/project
    exit 1
fi

trap ctrl_c INT
function ctrl_c() {
    echo ""
    echo "Trapped CTRL-C, terminating sync session..."
    mutagen terminate --all
    mutagen list
    exit 0
}

mutagen terminate --all
mutagen create --ignore-vcs \
    --sync-mode=two-way-resolved \
    --ignore=bazel-* \
    --symlink-mode=posix-raw \
    $1 $2
mutagen monitor --long

This gives my a simple single-session workflow to sync from my laptop to devbox with a preference for my local laptop since my devbox often gets way behind.

Hey @tristanz, I think that script looks reasonable.  I think it might simplify a bit with the scriptability changes that I'm hoping to land soon (in either v0.9.0 or v0.10.0).  See issues #43 and #57 for additional information and discussion (and feel free to comment).  I'm not sure if any progress has been made on the proposed external orchestration tool, but I think the changes would help even at the simple scripting level.
Depending on whether or not you need artifacts synchronized back from the development box, the one-way-safe mode might also be a sensible option.
Regarding the comments in the script, I would still highly advise that you avoid syncing .git (including for the reasons mentioned in #76), though it seems like you're using the --ignore-vcs flag, so I guess maybe the comment is out-of-date?


docs: Adding runtimeConfig

After detecting a bug: https://github.com/Intevel/nuxt-directus/issues/160#issue-1753634297, I found the solution by adding the configuration of Directus with Nuxt using runtimeConfig https://github.com/Intevel/nuxt-directus/issues/160#issuecomment-1588152137

Types of changes

[x] Bug fix (a non-breaking change which fixes an issue)
[ ] New feature (a non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Checklist:

[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have added tests to cover my changes (if not applicable, please state why)

TY @halwesit for your pr.
LGTM, I just change the PR name to better fit the Semantic for git commit. TLDR on Git Commit Semantic if you want to take a look.


Remove Instagram section and mention of Instagram from Redirection apps and exentsions

Both of the listed front-ends for Instagram are dead, the fork for Barinsta has been dead for months (https://blog.avalos.me/2021/08/14/barinsta/), and Bibliogram just closed a few weeks ago (https://bibliogram.art/). All remaining public instances that are still up for Bibliogram lead to a 504 Gateway Time-out when trying to search anything.
All Redirection apps and extensions in the use Bibliogram, so their mention of Instagram should be removed.

Thank you for the update!


I want to use the ad muting and skipping features of this tool, but I don't want to use SponsorBlock. Many of the channels I watch actually do very funny sponsor segments and I enjoy them.
The obvious option seemed to be setting env var CSS_CATEGORIES.  CSS_CATEGORIES='' gives me default behaviour (the thing I don't want). So does CSS_CATEGORIES=' '. I had to really fool the config system with CSS_CATEGORIES=' , ' to get it to just have an empty list of zero categories.
This is a pretty rough user experience. Variables explicitly set as being empty should be interpreted as empty, not as unset. It's not the same.

@squeakyneb I agree that empty envs aren't the same as unset values, and that it should be possible to disable the SponsorBlock while keeping ad skip, but I also want to mention that loading these values from envs is handled by a package and not by me, so it must be desired behavior for a lot of projects.
Let me decide the best way to implement this. Should be a pretty quick thing to add. In the mean time, the fact that CSS_CATEGORIES=' , ' works is hilarious.

@squeakyneb I'm releasing v0.6.0 which lets you set CSS_SKIP_SPONSORS=false to disable sponsor skip.


replacing blacklist by blocklist and whitelist by allowlist

Description
opensearch should be open enough to avoid the words "blacklist" and "whitelist"
Issues Resolved
Check List

[x] All tests pass

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

We'd like to do this, however we also need to preserve backwards compatibility, see https://github.com/opensearch-project/OpenSearch/issues/472


Cannot find module 'binary-search-tree' when packaged with Electron app

NeDB all installed as documented. ^1.8.0
Everything works ok when developing app launched with electron .
After installing both Linux and macOS packaged apps on test machines, both immediately throw an error:

Uncaught Error: Cannot find module 'binary-search-tree'
    at Module._resolveFilename (internal/modules/cjs/loader.js:602)
    at Function.Module._resolveFilename (/Users/kosso/_SERVER…-search-paths.js:35)
    at Function.Module._load (internal/modules/cjs/loader.js:528)
    at Module.require (internal/modules/cjs/loader.js:658)
    at require (internal/modules/cjs/helpers.js:20)
    at Object.<anonymous> (/Users/kosso/_SERVER…db/lib/indexes.js:1)
    at Object.<anonymous> (/Users/kosso/_SERVER…/lib/indexes.js:296)
    at Module._compile (internal/modules/cjs/loader.js:711)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:722)
    at Module.load (internal/modules/cjs/loader.js:620)

I've tried manually installing the dependencies listed in package.json too. Same error.
Any ideas?
Is this even still supported?

It sounds more likely to be an issue with the Electron packager that you are using that with NeDB itself since it works in the local development mode. 🤷♂


Add Facebook Observer/Source

Page comments
Hashtag search
Search query
Someone tag user

Need to support posts comments in page.
Argument:

No of post to scrape.
Comments of post.
Filter comment based on some parameter.

Output of source:

Flattered list of all comments irrespective of post and comment tree.

Post which are tags for given page.

Fixed by #150


Added support for page() and screen() calls

Added support for page() and screen() calls. Includes passing tests.
Version number for release has not been bumped. Not sure what Segment's process is for release numbers.

Ping @amillet89 @ndhoule

Superseeded by #4


Change Quick Accent activation key

Description of the new feature / enhancement
Quick Accent should allow to change the activation key to others like Control, Shift or alt
Scenario when this would be used?
Sometimes when typing a lot of text or too fast it skips some spaces or the popup get stuck for some time and when it closes it adds the letter or a space out of place
Supporting information
No response

Related to this, I generally think that the Quick Accent shortcut should default should be changed altogether. It took me several days to figure out what was causing this behavior for me when typing because I (subconsciously!) hold down the letter slightly before hitting the space bar. I genuinely think this default is too prone to issues and should be changed to the right-arrow key default.

You can change the activation shortcut in the settings.

You can change the activation shortcut in the settings.

Yes, but it's limited to the space and the arrows. The request is to have other keys as well

You can change the activation shortcut in the settings.

Yes, but it's limited to the space and the arrows. The request is to have other keys as well

So you mean single keys?

Sorry for some reason I mixed up Quick Accent with PowerToys Peek😅. This feature request is of course valid.

/dup #20958


Missing package

Package browserify-shim is missing in package.json. You need to improve your docs Jam :D

@VojtechBartos Thank you Vojti! I really appreciate your feedback. I'm gonna fix it asap! :D


Multi-line formatting does not work properly

Description
It seems that multi-line formatting does not work correctly (e.g. lists, quotes)
Preview:

Could be this line?

This should be fixed in v0.22.0.


Re-enable Carthage tests.

Since it looks like Carthage is fixed - let's try to re-enable it.
Should fix #850.

Going to close it to remove the noise. It still fails :(


fixed page reload on login

Fixed issue #12
Instead of handling form submission as an onClick on the button added it as an onSubmit action on the form itself, now it is possible to login to the ClubAdmin page.

@Yash-Ainapure can you review and merge the pr?

@Yash-Ainapure can you review and merge the pr?

But the problem isn't fixed yet sir.
stiil when we enter logn button ,it gets refreshed/rerendered clearing the form and at 2nd time when we submit login credentials then only it works