Pasting no longer works correctly on foot terminal

Steps to reproduce

Have some text in your clipboard
Paste into Vim's insert mode with Ctrl+Shift+V

Expected behaviour
The contents of the clipboard should paste normally.
Instead an escape seems to be prepended to the clipboard? If the clipboard is "asdf" you will get "Sdf"
Unsetting the TERM environment variable gives the correct behavior.
Version of Vim
9.0.1107
Environment
OS: Alpine Linux
Terminal: Foot
TERM=foot
Shell: busybox ash
Logs and stack traces
No response

Steps to reproduce

Have some text in your clipboard
Paste into Vim's insert mode with Ctrl+Shift+V

Expected behaviour
The contents of the clipboard should paste normally.
Instead an escape seems to be prepended to the clipboard? If the clipboard is "asdf" you will get "Sdf"
Unsetting the TERM environment variable gives the correct behavior.
Version of Vim
9.0.1107
Environment
OS: Alpine Linux
Terminal: Foot
TERM=foot
Shell: busybox ash

Perhaps bracketed paste is enabled but not working properly?
See ":help xterm-bracketed-paste".
Check the output of:
verbose set t_BE t_BD t_PS t_PE
You could try:
  let &t_BE = ""
  let &t_BD = "\e[?2004l"
  exec "set t_PS=\e[200~"
  exec "set t_PE=\e[201~"
  !ls

The "!ls" command is get the t_BD code output.
This should disable bracketed paste, but still handle it if gets
switched on elsewhere somehow.
--
"Software is like sex... it's better when it's free."
-- Linus Torvalds, initiator of the free Linux OS
Makes me wonder what FSF stands for...?
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

maybe it related to keyprotocol ? the foot use kitty keyboard protocol by default.
and try vim v9.0.1117 in my case looks it helped bracketed paste issue which existed long time.
// thx bram very much. :-)
or just like bram said, disable it.

maybe it related to keyprotocol ? the foot use kitty keyboard protocol by default.
and try vim v9.0.1117 in my case looks it helped bracketed paste issue which existed long time.
// thx bram very much. :-)
or just like bram said, disable it.

Thank you for your quick responses.

Check the output of: verbose set t_BE t_BD t_PS t_PE

  t_BE=^[[?2004h
  t_BD=^[[?2004l
E846: Key code not set: t_PS

You could try: let &t_BE = "" let &t_BD = "\e[?2004l" exec "set t_PS=\e[200~" exec "set t_PE=\e[201~" !ls
The "!ls" command is get the t_BD code output.
This should disable bracketed paste, but still handle it if gets switched on elsewhere somehow.

This makes pasting work correctly! The !ls doesn't seem to be necessary though? I only point this out because I am putting this in my vimrc.

maybe it related to keyprotocol ? the foot use kitty keyboard protocol by default.

Setting keyprotocol=foot:mok2 or keyprotocol=foot:none doesn't seem to help?

and try vim v9.0.1117 in my case looks it helped bracketed paste issue which existed long time. // thx bram very much. :-)

That's good to hear, I'll look out for it when it comes down the Alpine pipeline and I'll be sure to update this issue if the update helps.

Thank you for your quick responses.

Check the output of: verbose set t_BE t_BD t_PS t_PE

  t_BE=^[[?2004h
  t_BD=^[[?2004l
E846: Key code not set: t_PS

That would explain the trouble: The terminal sends text surrounded by
the bracketed paste escape sequences, but Vim is not setup to recognize
them.
You will have to somehow figure out how it is possible that t_BE and
t_BD are set, but t_PS and t_PE are not.  You can try starting Vim in
different ways, e.g. "vim --clean" and "vim -u NONE".  Or try setting
$TERM to different values.
You mentioned before that $TERM was set to "foot", I wonder where it
gets these termcap entries then.  These codes are only just being added
to the terminfo database (part of ncurses 6.4) and won't be in a
distributed package yet.

You could try: let &t_BE = "" let &t_BD = "\e[?2004l" exec "set t_PS=\e[200~" exec "set t_PE=\e[201~" !ls
The "!ls" command is get the t_BD code output.
This should disable bracketed paste, but still handle it if gets switched on elsewhere somehow.

This makes pasting work correctly! The !ls doesn't seem to be
necessary though? I only point this out because I am putting this in
my vimrc.

The "!ls" is only needed if you make changes after starutp.

maybe it related to keyprotocol ? the foot use kitty keyboard
protocol by default.

Setting keyprotocol=foot:mok2 or keyprotocol=foot:none doesn't
seem to help?

I do not see a relation betwen what you report and 'keyprotocol'.

and try vim v9.0.1117 in my case looks it helped bracketed paste
issue which existed long time. // thx bram very much. :-)

That's good to hear, I'll look out for it when it comes down the
Alpine pipeline and I'll be sure to update this issue if the update
helps.

The update most likely doesn't change anything.  As mentioned above, the
terminfo entries are not expected to exist yet.  But perhaps someone
added them anyway (you can put anything in terminfo entries, there is no
tool to check the values for being valid).
--
Living on Earth includes an annual free trip around the Sun.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

If @AN3223 has an ncurses with the 2022-12-24 patch, where the terminfo entry names were incorrect, wouldn't that explain what we're seeing here?

@AN3223 what's the output of  infocmp -x | grep -E "BD|BE|PS|PE"?

Maybe also relevant: on vim-9.0.1046 (i.e. pre-9.0.1117), verbose set t_BE t_BD t_PS t_PE returns
  t_BE=^[[?2004h
  t_BD=^[[?2004l
E846: Key code not set: t_PS

despite the terminfo having all four capabilities:
infocmp -x | grep -E "BD|BE|PS|PE"
	u9=\E[c, vpa=\E[%i%p1%dd, BD=\E[?2004l, BE=\E[?2004h,
	Ms=\E]52;%p1%s;%p2%s\E\\, PE=\E[201~, PS=\E[200~,

Maybe also relevant: on vim-9.0.1046 (i.e. pre-9.0.1117), verbose set t_BE t_BD t_PS t_PE returns
  t_BE=^[[?2004h
  t_BD=^[[?2004l
E846: Key code not set: t_PS

despite the terminfo having all four capabilities:
infocmp -x | grep -E "BD|BE|PS|PE"
	u9=\E[c, vpa=\E[%i%p1%dd, BD=\E[?2004l, BE=\E[?2004h,
	Ms=\E]52;%p1%s;%p2%s\E\\, PE=\E[201~, PS=\E[200~,

Well, that was the reason to make that patch, the way the termcap
entries were fetched wasn't exactly right.  The builtin entries worked
though.
I wonder why your terminfo entry has these values, they were not really
supported until yesterday.  If you put random entries in terminfo, you
can't really predict what an application will do with them.  It's
hit-and-miss, there isn't really an official list of terminfo entries
that I know of, the Linux terminfo manpage seems to come closest.  I
also still have to see how the changes in ncurses 6.4 will be picked up
by those who make packages for distributions.
--
LETTERS TO THE EDITOR (The Times of London)
Dear Sir,
I am firmly opposed to the spread of microchips either to the home or
to the office.  We have more than enough of them foisted upon us in
public places.  They are a disgusting Americanism, and can only result
in the farmers being forced to grow smaller potatoes, which in turn
will cause massive unemployment in the already severely depressed
agricultural industry.
Yours faithfully,
        Capt. Quinton D'Arcy, J. P.
        Sevenoaks
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I wonder why your terminfo entry has these values, they were not really supported until yesterday.

The official terminfo for foot is distributed as part of ncurses. Some distributions keep up-to-date with ncurses patches, meaning it is possible @AN3223 got the new terminfo entries through an ncurses update. This is why I asked him to check the output of infocmp.
(There is also an optional terminfo shipped with foot itself. I did add the new terminfo capabilities to it today, but before that, id did not have any of the bracketed-paste capabilities).

Some distributions keep up-to-date with ncurses patches, meaning it is possible @AN3223 got the new terminfo entries through an ncurses update.

Alpine linux (which is what @AN3223 is using) seems to be one of those. It's ncurses version is currently 6.4_p20221231-r0

... and it was updated from 6.3_p20221224 (i.e. the one with the faulty names) today.

and try vim v9.0.1117 in my case looks it helped bracketed paste
issue which existed long time. // thx bram very much. :-)

The update most likely doesn't change anything.

interesting... but I suddenly find my case (https://github.com/vim/vim/issues/10632) works today morning anyway, i tried to bisect but failed, not sure why........ :smile:
my ncurses version: 6.3-2
and no output in infocmp -x | grep -E "BD|BE|PS|PE"

I wonder why your terminfo entry has these values, they were not
really supported until yesterday.

The official terminfo for foot is distributed as part of ncurses. Some
distributions keep up-to-date with ncurses patches, meaning it is
possible @AN3223 got the new terminfo entries through an ncurses
update. This is why I asked him to check the output of infocmp.
(There is also an optional terminfo shipped with foot itself. I did
add the new terminfo capabilities to it today, but before that, id
did not have any of the bracketed-paste capabilities).

An old Vim version does get the "BE and "BD" entries, thus if terminfo
is updated to have those entries, then the problem might happen.
The "PS" and "PE" entries were obtained before, but in the wrong way.
That is why patch 9.0.1117 is needed.  Thus updating the terminfo entry
without updating Vim would indeed cause this problem.  I had not
anticipated users updating terminfo that quickly.
Since I can't fix an older Vim, and apparently users do use an older Vim
version with the new terminfo entries, we may have to roll back these
terminfo changes.
To avoid the problem we probably need to use different terminfo entry
names instead of "BE" and "BD".  It's not nice, but I can't think of
another way right now.
--
ARTHUR: CHARGE!
[The mighty ARMY charges.  Thundering noise of feet.  Clatter of coconuts.
Shouts etc.   Suddenly there is a wail of a siren and a couple of police
cars roar round in front of the charging ARMY and the POLICE leap out and
stop them.  TWO POLICEMAN and the HISTORIAN'S WIFE.  Black Marias skid up
behind them.]
HISTORIAN'S WIFE: They're the ones, I'm sure.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Since I can't fix an older Vim, and apparently users do use an older Vim version with the new terminfo entries, we may have to roll back these terminfo changes.

My personal view: distributions that use bleeding edge ncurses are typically bleeding edge all around. Including vim itself. For example, Alpine updated vim to 9.0.1128 yesterday. And with that, I think the problem should be gone for @AN3223 ?
Thus, it may be best to just let the distributions catch up with vim, rather than going through a full terminfo rollback.

Since I can't fix an older Vim, and apparently users do use an older
Vim version with the new terminfo entries, we may have to roll back
these terminfo changes.

My personal view: distributions that use bleeding edge ncurses are
typically bleeding edge all around. Including vim itself. For example,
Alpine updated vim to 9.0.1128 yesterday. And with that, I think the
problem should be gone for @AN3223 ?
Thus, it may be best to just let the distributions catch up with vim,
rather than going through a full terminfo rollback.

I hope so.  Debian mentioned including the relevant Vim patch.
Another solution than a rollback would be to use different names.  But
that is a workaround (might even call it a hack) that would then remain
distributed for years.  It would also mess up the ncurses rollout.
The Vim patch is small and I don't think it conflicts with other recent
changes.  Relying on including this fix might indeed be the best
solution.
--
NEIL INNES PLAYED: THE FIRST SELF-DESTRUCTIVE MONK, ROBIN'S LEAST FAVORITE
MINSTREL, THE PAGE CRUSHED BY A RABBIT, THE OWNER OF A DUCK
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Arch, an allegedly bleeding edge rolling distro, is still on 9.0.1046, which it retrieves directly from the Github releases tags page. It is not applying any patches, and nobody has filed an out of date notice for it.

vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 11 2022 13:50:40)
Included patches: 1-1046
Compiled by Arch Linux

kitty 0.26.5
:set t_BE t_BD t_PS t_PE
  t_BE=^[[?2004h
  t_BD=^[[?2004l
t_PS <PasteStart> ^[[200~
t_PE <PasteEnd>  ^[[201~

infocmp -x | grep -E "BD|BE|PS|PE"
	kBEG=\E[1;2E, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,
	Smulx=\E[4:%p1%dm, Sync=\EP=%p1%ds\E\\, kBEG3=\E[1;3E,
	kBEG4=\E[1;4E, kBEG5=\E[1;5E, kBEG6=\E[1;6E,
	kBEG7=\E[1;7E, kDC3=\E[3;3~, kDC4=\E[3;4~, kDC5=\E[3;5~,

foot 1.13.1
:set t_BE t_BD t_PS t_PE
  t_BE=^[[?2004h
  t_BD=^[[?2004l
E846: Key code not set: t_PS

infocmp -x | grep -E "BD|BE|PS|PE"
	u9=\E[c, vpa=\E[%i%p1%dd, BD=\E[?2004l, BE=\E[?2004h,
	Ms=\E]52;%p1%s;%p2%s\E\\, PE=\E[201~, PS=\E[200~,

vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 11 2022 13:50:40)
Included patches: 1-1046
Compiled by Arch Linux

kitty 0.26.5
:set t_BE t_BD t_PS t_PE
  t_BE=^[[?2004h
  t_BD=^[[?2004l
t_PS <PasteStart> ^[[200~
t_PE <PasteEnd>  ^[[201~

infocmp -x | grep -E "BD|BE|PS|PE"
	kBEG=\E[1;2E, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,
	Smulx=\E[4:%p1%dm, Sync=\EP=%p1%ds\E\\, kBEG3=\E[1;3E,
	kBEG4=\E[1;4E, kBEG5=\E[1;5E, kBEG6=\E[1;6E,
	kBEG7=\E[1;7E, kDC3=\E[3;3~, kDC4=\E[3;4~, kDC5=\E[3;5~,

foot 1.13.1
:set t_BE t_BD t_PS t_PE
  t_BE=^[[?2004h
  t_BD=^[[?2004l
E846: Key code not set: t_PS

infocmp -x | grep -E "BD|BE|PS|PE"
	u9=\E[c, vpa=\E[%i%p1%dd, BD=\E[?2004l, BE=\E[?2004h,
	Ms=\E]52;%p1%s;%p2%s\E\\, PE=\E[201~, PS=\E[200~,

vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 11 2022 13:50:40)
Included patches: 1-1046
Compiled by Arch Linux

kitty 0.26.5
:set t_BE t_BD t_PS t_PE
  t_BE=^[[?2004h
  t_BD=^[[?2004l
t_PS <PasteStart> ^[[200~
t_PE <PasteEnd>  ^[[201~

infocmp -x | grep -E "BD|BE|PS|PE"
	kBEG=\E[1;2E, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,
	Smulx=\E[4:%p1%dm, Sync=\EP=%p1%ds\E\\, kBEG3=\E[1;3E,
	kBEG4=\E[1;4E, kBEG5=\E[1;5E, kBEG6=\E[1;6E,
	kBEG7=\E[1;7E, kDC3=\E[3;3~, kDC4=\E[3;4~, kDC5=\E[3;5~,

foot 1.13.1
:set t_BE t_BD t_PS t_PE
  t_BE=^[[?2004h
  t_BD=^[[?2004l
E846: Key code not set: t_PS

infocmp -x | grep -E "BD|BE|PS|PE"
	u9=\E[c, vpa=\E[%i%p1%dd, BD=\E[?2004l, BE=\E[?2004h,
	Ms=\E]52;%p1%s;%p2%s\E\\, PE=\E[201~, PS=\E[200~,

I tried the latest vim (version 9.0.1153) which has fixed this bug
foot
  t_BE=^[[?2004h
  t_BD=^[[?2004l
t_PS <PasteStart> ^[[200~
t_PE <PasteEnd>  ^[[201~

vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 11 2022 13:50:40)
Included patches: 1-1046
Compiled by Arch Linux

kitty 0.26.5
:set t_BE t_BD t_PS t_PE
  t_BE=^[[?2004h
  t_BD=^[[?2004l
t_PS <PasteStart> ^[[200~
t_PE <PasteEnd>  ^[[201~

infocmp -x | grep -E "BD|BE|PS|PE"
	kBEG=\E[1;2E, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,
	Smulx=\E[4:%p1%dm, Sync=\EP=%p1%ds\E\\, kBEG3=\E[1;3E,
	kBEG4=\E[1;4E, kBEG5=\E[1;5E, kBEG6=\E[1;6E,
	kBEG7=\E[1;7E, kDC3=\E[3;3~, kDC4=\E[3;4~, kDC5=\E[3;5~,

I guess $TERM here is "xterm-kitty".  Since this Vim is older it picks
up the builtin xterm termcap, which defines the bracketed paste entries.
The terminfo doesn't matter.

foot 1.13.1
:set t_BE t_BD t_PS t_PE
  t_BE=^[[?2004h
  t_BD=^[[?2004l
E846: Key code not set: t_PS

infocmp -x | grep -E "BD|BE|PS|PE"
	u9=\E[c, vpa=\E[%i%p1%dd, BD=\E[?2004l, BE=\E[?2004h,
	Ms=\E]52;%p1%s;%p2%s\E\\, PE=\E[201~, PS=\E[200~,

I wonder who put these bracketed-paste entries into the foot terminfo
entry?  Does this system have ncurses 6.4 perhaps?
You need patch 9.0.1117 to make this work.
That the terminfo entries for bracketed paste don't work is a very old
problem that nobody noticed until terminfo was updated (with ncurses
6.4).  It was fixed quickly, but an older Vim with new terminfo entries
won't work.  There doesn't appear to be another solution than making
sure Vim has that patch.
--
LARGE MAN:   Who's that then?
CART DRIVER: (Grudgingly) I dunno, Must be a king.
LARGE MAN:   Why?

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Just thought I'd add, Arch doesn't have a terminfo built in for foot. You have to install a separate foot-terminfo package, which is version matched with the foot package.

This isn't entirely true. The default terminfo used by the foot package on Arch is provided by ncurses.
The foot-terminfo package is an optional dependency, providing an alternative terminfo (that defines more capabilities than the one from ncurses). The user has to explicitly configure foot to make use of the alternative terminfo.

I'm having the same issue, running debian bookworm on a docker container. See https://www.reddit.com/r/vim/comments/1063k5p/pasting_takes_me_out_of_insert_mode/ for more details.

OK, so it appears changing $TERM to something more generic fixes the issue. If it's set to xterm for example, the problem goes away.

Since I can't fix an older Vim, and apparently users do use an older Vim version with the new terminfo entries, we may have to roll back these terminfo changes.

My personal view: distributions that use bleeding edge ncurses are typically bleeding edge all around. Including vim itself. For example, Alpine updated vim to 9.0.1128 yesterday. And with that, I think the problem should be gone for @AN3223 ?
Thus, it may be best to just let the distributions catch up with vim, rather than going through a full terminfo rollback.

Yes the problem is gone now after an update. Sorry for the late response, the thread was moving a little fast (not a complaint!) and I had COVID, lol.
I guess I will close this issue now? :)

Since I can't fix an older Vim, and apparently users do use an
older Vim version with the new terminfo entries, we may have to
roll back these terminfo changes.

My personal view: distributions that use bleeding edge ncurses are
typically bleeding edge all around. Including vim itself. For
example, Alpine updated vim to 9.0.1128 yesterday. And with that, I
think the problem should be gone for @AN3223 ?
Thus, it may be best to just let the distributions catch up with
vim, rather than going through a full terminfo rollback.

Yes the problem is gone now after an update.

Glad to hear that.  I haven't heard ideas for another solution, thus
we'll leave it at this.
Note that I plan to do a few similar changes to support terminals
automatically, without the need for users to tune their setup.  We
learned from this mistake, the "RV" entry was heading in the same
direction.  We can fix that before it gets released.
So, keep checking new versions for working properly.  Feedback from
users using the latest version of everything is very much appreciated.

Sorry for the late response, the thread was moving a little fast (not
a complaint!) and I had COVID, lol.

I hope you recover 100%!
--
"You're fired." (1980)
"You're laid off." (1985)
"You're downsized." (1990)
"You're rightsized." (1992)
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///


Fix unique slugs with the TreeSlugHandler

Added test case for #1429 and #1604
Added new callback before the slug's uniqueness is ensured while maintaining backwards compatibility.

Maybe I should've targeted the 2.4 branch. Hmm.

I will review that when I can, currently have a busy schedule ;)


cdaweb access through requests

Partial fix for #79.  Replaces ftplib with requests in cdaweb_methods.download to allow access to cdaweb data via HTTPS.  Allows for future implementation of restful web services with cdaweb server.

This build had a problem with pyglow for some reason. Other two errors related to kp and dst. Gonna restart tests for the pyglow check.

@rstoneback, I'm still getting the following error:
TypeError: download() got multiple values for argument 'supported_tags'

Any thoughts?

OK,found it.  Download does not treat supported_tags as a keyword, whereas list_files does.

Clearly my reading comprehension is not so great in the morning :)
Please ignore my last comment. supported_tags is not a keyword, as you stated.
On Feb 4, 2019, at 10:17 PM, Jeff Klenzing <notifications<EMAIL_ADDRESS>wrote:
OK,found it. Download does not treat supported_tags as a keyword, whereas list_files does.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/rstoneback/pysat/pull/143#issuecomment-460507267, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADbdedZb7PsmSVIbhRbDNUlOH9jJj6Stks5vKQW_gaJpZM4aUSa3.

Thanks again Jeff. I’m planning on hitting pysat reviews and other things tonight!
Cheers,
Russell

I added a test file for ftp instruments. It should only run when on travis. I also added support to exclude particular sat_id and tag combinations from download testing.
I switched a printed warning to an actual warning (when downloads don't work). As part of this, I realized that the Dst filename standard was updated on the remote server end. Added that minor fix.

rerunning to check timeout errors

Looking at the logs for builds 1590 and 1592 on Travis, kp still runs and errors on 1590, dst on 1592.  There is no difference between the codes other than some whitespace.  Not sure why these are inconsistently still being tested on travis.

I haven't sorted out why dst is being checked either. It doesn't run on my local system. Anyway, I fixed up a few things, checking to see how it runs on the server side.

My Travis check is bad, the FTP tests are still being run.

Remaining issues: pyglow errors, which aren't a part of this, and; supermag magnetometer indices download problem. Works locally ;) Trying things out again.

@aburrell I had to modify supermag since it wasn't passing a more strict download test. The latest code had 'indices' files mapped to 'all' but not quite everywhere. The test thought nothing was downloaded, even though a new file was on disk. My final fix in init may be the best of them, assuming I went in the correct direction.

@rstoneback that seems sensible.  It was a bit of a judgement call on organizing a subset of data that is normally only downloaded alongside a different data product but a lot of people use instead.

Thanks! No worries about the org, just making sure I'm staying with the original intent. Looks like the 'indices' tag was sorted out, now downloads are complaining about tag='' .

@jklenzing the testing ftp testing file needs a way to add an instrument tag and not all tags of a particular instrument.

Currently, test_sw.py requires downloads of FTP data as part of the setup structure.  This should be rewritten using fake data.  Conversely, we can turn these tests on in Travis CI and open new issues to expand testing for now.

Currently, test_sw.py requires downloads of FTP data as part of the setup structure. This should be rewritten using fake data. Conversely, we can turn these tests on in Travis CI and open new issues to expand testing for now.

Never mind.  self.download=False not being flagged in three tests for combine_kp for some reason.

@jklenzing the testing ftp testing file needs a way to add an instrument tag and not all tags of a particular instrument.

@aburrell, I agree, but I'd like to close this off as the scope has grown significantly beyond the original pull request.  Going to write up some new issues for other changes to improve the handling of instrument download testing within travis.

One remaining Error in 3.6 as of #1678 in Travis CI:
ERROR: Failure: RuntimeWarning (Download for supermag magnetometer   was not successful.)

This fails both on Travis and locally.
2.7 still has the pyglow issues as well (fixed in #155).

Found areas in supermag where tag=None was used in checks instead of tag=''.  Fixed these.  Unit tests now run locally.
Note: ucar_tiegcm is now popping up with errors locally.  Since there is no supported download routine, added this to exclude_list.

removed ucar_tiegcm from exclude list.  Was an issue with how I am running nosetests locally.

@aburrell, @rstoneback, could you take a look at supermag?  Still getting errors locally.  If I try to run and download through ipython,I get this error message:
~/code/pysat/pysat/instruments/supermag_magnetometer.py in append_ascii_data(file_strings, tag)
    928         lsplit = re.split('\t+', out_lines[i])
    929         dtime = pds.datetime.strptime(" ".join(lsplit[0:-1]),
--> 930                                       "%Y %m %d %H %M %S")
    931         date_list.append(dtime)
    932         num_stations.append(int(lsplit[-1]))

Not really sure what is going on in the append_ascii_data method.  After updating the tag structure, I was able to successfully download once for the test data, but I'm getting this error now.

@jklenzing  can you send me the code snippet that you ran to get this error?

import pysat
mag = pysat.Instrument(platform='supermag', name='magnetometer')
t0 = pysat.datetime(2009, 1, 1)
mag.download(t0, t0, user=username)

where username is my user name as a string.

Hey Folks!
I’ve been covered up on some other projects but there is a light at the end of the tunnel. Hopefully I can start contributing positively back here pretty soon.
I think I saw some comments about an inclusive list for ftp downloads that is tag specific. I’m planning on adding this but if someone wants to jump ahead I recently added an exclusion list that supports tags. In the FTP instrument file you can do the inverse of that solution. The current package support already there sets up the groundwork.
Cheers,
Russell
On Feb 11, 2019, at 12:02 PM, Jeff Klenzing <notifications<EMAIL_ADDRESS>wrote:
import pysat
mag = pysat.Instrument(platform='supermag', name='magnetometer')
t0 = pysat.datetime(2009, 1, 1)
mag.download(t0, t0, user=username)
where username is my user name as a string.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/rstoneback/pysat/pull/143#issuecomment-462429781, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADbdeXd39U-Ij0A4vISw2uoeqeggnrHrks5vMbAXgaJpZM4aUSa3.

@rstoneback, I started working on the include_tags a bit (some remnants are in this branch), but instead I'm leaning toward a proposal that I outlined in #156 as a more permanent solution for customizing the testing functions.  Comments are welcome.  We should discuss at the next meeting.
As far as what needs to be done here, If we fix (or temporarily suppress) the supermag bug, then merge this PR and #155, we should be back to a passing build on Travis.  #155 is ready for review.

Not really sure what is going on in the append_ascii_data method. After updating the tag structure, I was able to successfully download once for the test data, but I'm getting this error now.

The error is occurring because the indices are not included when requesting just the magnetometer data, so ind_num should be zero with tag ''.

Thanks @aburrell.  Sticking ucar_tiegcm back in the exclude list for now.  Not sure why this one only errors when everything else seems to be fixed.  Crossing fingers...

I don’t think the TIEGCM code has a working download routine. All the files I’ve used it on have been sent to me by non-standard means.
If anyone knows of a data source that we can refer too we can add it in.
Cheers,
Russell
On Feb 12, 2019, at 5:24 PM, Jeff Klenzing <notifications<EMAIL_ADDRESS>wrote:
Thanks @aburrellhttps://github.com/aburrell. Sticking ucar_tiegcm back in the exclude list for now. Not sure why this one only errors when everything else seems to be fixed. Crossing fingers...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/rstoneback/pysat/pull/143#issuecomment-462982862, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADbdeeqCT9mDAkI42SfP60OdWYEMqR8Jks5vM001gaJpZM4aUSa3.

@rstoneback, that's right, there's currently no download support.

Ok, this one’s ready for review.

WHAT?  All checks have passed?  :-O

I’m surprised too. Wasn’t expecting that until this was combined with #155

Hmm.  Supermag indices are now putting in an error.  Only changes post-review were changing
raise ValueError (estr)

to
raise ValueError(estr)

in a few places.  Restarting travis tests and running tests locally.

I'm ok with keeping the tiegcm in the exclude list. It isn't a fully 'complete' module.

Thanks Jeff!
On Feb 13, 2019, at 12:05 PM, Jeff Klenzing <notifications<EMAIL_ADDRESS>wrote:
Merged #143https://github.com/rstoneback/pysat/pull/143 into develop.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/rstoneback/pysat/pull/143#event-2137505699, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADbdeZ5hdcx1oak3nX1Ek_zt0TX2IFCSks5vNFP5gaJpZM4aUSa3.


Add killed and injured count per age group stacked

#1160 add killed and injured count per age group stacked Widge

@shaked-hayek can you review?


figma-enhancement | Pattern Collection

Figma branch: pattern-collection
Challenge
Pattern Analysis is a method where different common UI Elements are compared to each other to find the component that resolves a task in the UI the best. For example: A dropdown is visually cleaner than radio buttons, but requires an additional click to see the available options.
For a Pattern Analysis to be more efficient, a pattern collection is a valuable tool. Compared to the regular component definition it does not need to explained how the component should be used. It also only shows the component without any variants, in order to showcase many components alongside eachother.
Proposed Solution

I would add an additional page following this structure:

Layout: Screen, Grids
Navigation: High-Level Structure, Toplevel Navigation, Lower-Level Organization, Within Content
Editing: Single Choice, Multi Choice, Input

We can use screenshots of missing components to show components that are not yet available in the Figma version of the design system.

A separate file for the pattern library has been created. New components can be added there before they are moved to the design systems component library.


Update README.md

Issue #, if available:
Description of changes:
To run CI tests on your changes refer README.md
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@ddavydenko : Could we also update Issue Template? People who find issues might just create issues on github, without reading the README. Its good to have a note in that template as well.


autocomplete ignores user snippets in vscode when using the unocss extension

UnoCSS version
0.58.4
Describe the bug
I'm using cl in vscode by registering className="$1" as a snippet
<div cl // When typing up to this point, cl as a snippet should be recommended.
However, clear-both is recommended.

If i disabled the unocss extension, the correct snippet will be recommended.

Reproduction
If you type <div cl in order, UNOCSS's suggestion takes precedence.
<div cl + backspace + l is correctly snippet and suggestion together.
I'd like to change the settings so that vscode's suggestions take precedence even when no backspace is entered, or that unocss suggests autocomplete for the area after className=.
System Info
No response
Validations

[X] Read the Contributing Guidelines.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I think so too. Some components will provide hints for their internal props, but as unocss hints on attributes will make it difficult for me to find hints for their internal props. What I want is that there is a switch that is only for classes. There are unocss prompts only in the attribute. The other way is to find ways to reduce the unocss code prompts in the attribute.

+1

Has this issue been fixed in the latest version? It seems that the performance is as expected. I have closed it for now. If there is any problem, I can open it again at any time.

I have confirmed that the problem is not reproduced in the latest version 0.58.6 ! Thanks


[bug] fix continuous integration push failure

Description of Change

Problem being fixed: Push after code formatting fails in some cases.
Checklist

[x] Added description of change
[ ] Added file name matches File name guidelines
[x] Added tests and example, test must pass
[ ] Added documentation so that the program is self-explanatory and educational - Doxygen guidelines
[ ] Relevant documentation/comments is changed or added
[x] PR title follows semantic commit guidelines
[ ] Search previous suggestions before making a new one, as yours may be a duplicate.
[x] I acknowledge that all my contributions will be made under the project's license.

Notes:

This is to be expected as a precautionary measure:

to avoid multiple commits of the same change by the GitHub actions executing on both original repo and the author's forked repo
no commits to be pushed to the master branch without going through a pull-request and review first - even by a bot


Schema update for stack (environment)

@yasker @ibuildthecloud

LGTM
I'll do the go-rancher update later today


Remove unused "api_endpoint" setting

closes #142

Current coverage is 100% (diff: 100%)

Merging #171 into master will not change coverage

@@           master   #171   diff @@
====================================
  Files           9      9
  Lines         191    191
  Methods         0      0
  Messages        0      0
  Branches        0      0
====================================
  Hits          191    191
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last update fcd9c15...15d90e0

@ttmc pointed that we also need to remove in Basic Usage Examples:
$ docker-compose run --rm bdb-server bigchaindb show-config | grep api_endpoint
    "api_endpoint": "http://bdb-server:9984/api/v1",


Error on TPU V3-8 with XLA: RPC failed with status = "Unavailable: Socket closed"

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): I am using the XLA example of RoBERTa Pytorch-XLA https://cloud.google.com/tpu/docs/tutorials/roberta-pytorch
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): debian-9-torch-xla-v20201225 (GCP image)
GCP Machine type: Custom 8vCPUs, 256GB memory
TensorFlow installed from (source or binary): Provided on GCP image
TensorFlow version (use command below): torch-xla-1.7
Python version: Python 3.6.10 :: Anaconda, Inc.
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source): N/A
CUDA/cuDNN version: N/A
GPU model and memory: TPU V3-8

Describe the current behavior
The following error is happening after training with Pythorch-XLA  for some time:
2020-12-28 01:56:05.252085: W    1417 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.251970000","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC

*** Begin stack trace ***
        tensorflow::CurrentStackTrace()
        xla::XrtComputationClient::ReleaseHandles(std::vector<xla::XrtComputationClient::DeviceHandle, std::allocator<xla::XrtComputationClient::DeviceHandle> >*, std::function<xla::XrtSession::CachedNode const& (xla::XrtSession*, tensorflow::Scope const&, std::string const&)> const&, xla::metrics::Metric*, xla::metrics::Counter*)
        xla::XrtComputationClient::HandleReleaser()
        xla::util::TriggeredTask::Runner()

        clone
*** End stack trace ***

I was following the steps described here: https://cloud.google.com/tpu/docs/tutorials/roberta-pytorch with the same network parameters, just a different dataset.
I encountered an error before, but it was happening due to OOM on the VM after restoring a checkpoint, which reason why I increased VM memory.
It seems that the TPU is getting pre-empted somehow, but I don't have access to the runtime log as this happened overnight and it got automatically deleted by TFRC.
Describe the expected behavior
The training should continue as expected.
Standalone code to reproduce the issue
https://cloud.google.com/tpu/docs/tutorials/roberta-pytorch
Training data was around 40GB.
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.
| epoch 002 | training on xla:0/1:   4151 / 10099 loss=1.804, nll_loss=1.804, wps=17811, ups=0, wpb=117675.783, bsz=296.068, num_updates=14249, lr=0.000491148, gnorm=0.345, oom=0.000, wall=27948, train_wall=92610, now=01:54:20
| epoch 002 | training on xla:0/7:   4151 / 10099 loss=1.805, nll_loss=1.805, wps=17811, ups=0, wpb=117678.381, bsz=296.074, num_updates=14249, lr=0.000491148, gnorm=0.345, oom=0.000, wall=27948, train_wall=92609, now=01:54:20
| epoch 002 | training on xla:0/3:   4151 / 10099 loss=1.805, nll_loss=1.805, wps=17810, ups=0, wpb=117668.251, bsz=296.137, num_updates=14249, lr=0.000491148, gnorm=0.345, oom=0.000, wall=27949, train_wall=92608, now=01:54:20
2020-12-28 01:56:05.252059: W    1436 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.251908254","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252085: W    1417 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.251970000","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252085: W    1416 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.251940620","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252162: W    1379 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252025037","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252205: W    1438 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252117134","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252251: W    1465 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252143973","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252279: W    1483 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252130522","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252398: W    1464 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252301762","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252431: W    1428 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252333413","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252452: W    1341 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252361631","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252472: W    1400 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252380523","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252456: W    1345 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252299434","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252541: W    1378 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252405772","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252553: W    1423 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252493206","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252618: W    1397 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252489431","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
2020-12-28 01:56:05.252674: W    1480 tensorflow/core/distributed_runtime/rpc/grpc_remote_master.cc:160] RPC failed with status = "Unavailable: Socket closed" and grpc_error_string = "{"created":"@1609120565.252561700","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}", maybe retrying the RPC
terminate called after throwing an instance of 'std::runtime_error'
  what():  tensorflow/compiler/xla/xla_client/xrt_computation_client.cc:1110 : Check failed: session->session()->Run( feed_inputs, {}, {cached_node.operations[0]}, &outputs) == ::tensorflow::Status::OK() (Aborted: Session a57840b79b1bd972 is not found. vs. OK)
*** Begin stack trace ***
        tensorflow::CurrentStackTrace()
        xla::XrtComputationClient::ReleaseHandles(std::vector<xla::XrtComputationClient::DeviceHandle, std::allocator<xla::XrtComputationClient::DeviceHandle> >*, std::function<xla::XrtSession::CachedNode const& (xla::XrtSession*, tensorflow::Scope const&, std::string const&)> const&, xla::metrics::Metric*, xla::metrics::Counter*)
        xla::XrtComputationClient::HandleReleaser()
        xla::util::TriggeredTask::Runner()

        clone
*** End stack trace ***

Currently, I resumed training on another TPU node, but checking the memory usage it seems it is increasing at each training step. Is it possible that OOM happened on the TPU and it got unavailable?

Hi soares-f , I'm getting the same issue (though with a custom model), with a similar per-epoch increase in TPU memory.
Did you end up figuring out what the cause was?

Hi,
Thank you for opening this issue. Since this issue has been open for a long time, the code/debug information for this issue may not be relevant with the current state of the code base.
The Tensorflow team is constantly improving the framework by fixing bugs and adding new features. We suggest you try the latest TensorFlow version with the latest compatible hardware configuration which could potentially resolve the issue. If you are still facing the issue, please create a new GitHub issue with your latest findings, with all the debugging information which could help us investigate.
Please follow the release notes to stay up to date with the latest developments which are happening in the Tensorflow space.


add Seplosv3 support

This PR adds support for the Seplos v3 BMS which is using the modbus protocol

Very nice thanks! We will release a new stable version at the end of March and merge that PR after.

Very nice thanks! ~We will release a new stable version at the end of March and merge that PR after.~
I add it in the next release with a note that it wasn't completely tested yet.

Great. That will also make the testing easier for others.
Here it is working fine, but indeed would need more testing esp for people with multiple Seplos batteries connected on single rs485


Getting compile time error.

Error:com.android.builder.internal.aapt.AaptException: Failed to crunch file C:\Users\akundu\AndroidStudioProjects\Android-Face-Recognition-with-Deep-Learning-Test-Framework-master\app\build\intermediates\exploded-aar\com.android.support\appcompat-v7\23.3.0\res\drawable-ldrtl-hdpi-v17\abc_ic_ab_back_mtrl_am_alpha.png into C:\Users\akundu\AndroidStudioProjects\Android-Face-Recognition-with-Deep-Learning-Test-Framework-master\app\build\intermediates\res\merged\debug\drawable-ldrtl-hdpi-v17\abc_ic_ab_back_mtrl_am_alpha.png

seems to be a file path problem in Windows https://stackoverflow.com/a/39621978


Custom Client

We should have a custom client (web and/or mobile) to make on-boarding easier for people.

Closing this because we have our own Pinafor for now (see client.nerdfight.online) and we can revisit it later.


GROOVY-9257: ZipException, FNFE -> IOException, InvalidPathException

Reworked PackageHelperImpl.getPackageNames(URL) to handle IOException (parent of ZipException and FileNotFoundException) and InvalidPathException.  This should improve compatibility with Java 9+ for jars within jars.
See https://issues.apache.org/jira/browse/GROOVY-9257 for maven project that can be used to test this.

Merged. Thanks.


fix x_o and broken link tutorial 7

What does this implement/fix? Explain your changes
Tutorial 7, x_o needed to be redefined as a 4 dimensional vector for the second example. Additionally the link to the sampling tutorial was broken and is now updated.
Does this close any currently open issues?
Fixes #1000
Any relevant code examples, logs, error output, etc?
Tutorial 7 now runs from start to finish
Checklist
Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you're unsure about any of them, don't hesitate to ask. We're here to
help! This is simply a reminder of what we are going to look for before merging
your code.

[x ] I have read and understood the contribution
guidelines
[x ] I performed linting and formatting as described in the contribution
guidelines
[x] I rebased on main (or there are no conflicts with main)

Thanks @Matthijspals! Are you OK with the license change from AGPLv3 to Apache-2.0, see #997?

Thanks @Matthijspals! Are you OK with the license change from AGPLv3 to Apache-2.0, see #997?

yes!

@Matthijspals Would you mind correcting the typo in the heading? "mechansims" --> "mechanisms"

@Matthijspals Would you mind correcting the typo in the heading? "mechansims" --> "mechanisms"

updated!

Is this ready for review?

thanks!
nitpick: Can you please add a ; after the plotting call in the last cell to avoid the figure output 🤓

Done!


New relation list design

          @RafaelGB not sure if it fits here or if it could be a visual enhancement feature request.

Would it be possible to display the table name in the relation field the same as tags instead of a list?
I think by using a list there's too much wasted space there.  Even if we might have several tables it would still look better like in tags.

thank you!
Originally posted by @cesarpereira904 in https://github.com/RafaelGB/obsidian-db-folder/issues/581#issuecomment-1403507595

Also I added a selection color per column for the relations =)
https://user-images.githubusercontent.com/11924043/215267640-e380767a-a781-4545-95c9-b65c892a6a7f.mov

Commit 5a1a1078

Amanzing work Rafael, it looks neat!!!


Texture2D Plugin ResS in resources.assets https://github.com/SeriousCache/UABE/issues/73

So In UABEA it's still impossible to write textures in ResS, can it be added?

I don't plan on adding support for anything like this any time soon because of the reasons discussed in that issue. Editing the resS in the middle/beginning might cause a resize which means you have to find every texture and mesh and whatever asset types come in the future and update their size. It's a lot of work that could break things if not properly done.


Custom output format breaks jsbuild

What version of Hugo are you using (hugo version)?

$ hugo version
+hugo v0.82.0+extended darwin/amd64 BuildDate=unknown

Does this issue reproduce with the latest release?
Yes
Description
I've defined a custom output format to generate GeoJSON:
[mediaTypes]
  [mediaTypes."application/geo+json"]
    suffixes = ["geojson", "gjson"]

[outputFormats]
  [outputFormats.GEOJSON]
    mediaType = "application/geo+json"
    isPlainText = true
    isHTML = false
    baseName = "index"
    notAlternative = true

When this is added to config.toml, the following error message is displayed during the build:
Error: Error building site: JSBUILD: failed to transform "js/main.js" (application/geo+json): unsupported Media Type: "application/geo+json"

I suspect the error in 'resources/resource_transformers/js/options.go', line 319, somehow the media type get's passed there - I don't really understand why.
If it's just because of the application/ prefix of the media type some XML formats (application/xml) will suffer as well.
I've updated the example repository from #8370, see cmahnke/hugo-0.82-test

Changing the mediaType from application/geo+json to application/json fix this issue, but it's certainly not how it should work, since it isn't documented.
A mid term solution would be a flag like isHTML. It would be called isJS and would be evaluated in  resources/resource_transformers/js/options.go, if set to false the media type would be simply ignored there.

The mediaType is passed to esbuild in the options to determine which content loader esbuild should choose to process the file. esbuild only supports certain content types and cannot process custom formats in the way that Hugo does. The error message that you received seems like it is the correct way for this to be handled, indicating that you are attempting to use js.Build with an unsupported media type and so it does not know how to process the data.

I'm sorry but I can't see where I pass it, it seems to be passed implicit...
Cann you please point out the line here:
https://github.com/cmahnke/hugo-0.82-test/blob/main/layouts/partials/head.html

Going through your test program (which I did not see before, I apologize), I was wondering if either of the two js dependencies have an import statement that imports a geo+json file? Does Mirador have an import for that file type within its code?

It looks like openlayers defines a geoJSON type and imports it within the code. As js.Build goes through the files to create a single javascript file, it must attempt to import this file, does not recognize the type, and this is likely where the failure is occurring. I think that is the case, though I do not know how to address it.

Well, I've just updated my test case since there might have been the case that OpenLayers has to do something with this. But even without OpenLayers (or Mirador) this happens. It's a hugo issue (not ESBuild), since the error is risen here

When the custom media type is created, it creates a suffixesCSV which contains "geojson, gson." As Hugo processes the mediaTypes for javascript files, it checks to see the associated media types based on the suffix "js."
https://github.com/gohugoio/hugo/blob/33d5f805923eb50dfb309d024f6555c59a339846/media/mediaType.go#L307-L308
This code sees "js" in "geoJSon" and adds it as the first mediaType of javascript files which then passes it to the js.Build and creates the error. This is a bug.

@matt9189 Thanks for investigating - since there is a workaround and only a few affected suffixes I guess it has a lower priority.

I saw during my debugging that there was a "todo" regarding the ambiguous nature of mediaTypes in resource_spec.go. The above issue may be fixed by checking for an exact match in the suffixesCSV. I am not going to create a pull request, mostly because I am not very fluent at using github and I need someone to show me some stuff. I will post this here though as a possible fix for mediaType.go hasSuffix() function above.
https://github.com/gohugoio/hugo/blob/3ddffd064dbacf62aa854b26ea8ddc5d15ba1ef8/resources/resource_spec.go#L271-L276
func (m Type) hasSuffix(suffix string) bool {
	for _, s := range strings.Split(m.suffixesCSV, m.Delimiter) {
		if strings.EqualFold(suffix, s) {
			return true
		}
	}
	return false
}

Why do you pass these files into js.Build?

@bep: I don't pass anything - js.Build breaks if there is just such a definition in config.toml - the example doesn't even contain templates for this...

@cmahnke

The only way I see that error happen is if you pass a resource of MIME type application/geo+json to js.Build
I tested the GitHub project above, and I don't see any error

@beb: Maybe your using a development version of Hugo? Or am I missing something by reusing the #8370 test case?
Here is the problem with the example repository: https://github.com/cmahnke/hugo-0.82-test/runs/2383428063

@cmahnke no, I forgot to init the submodule when I cloned it. I get the error now, I will eventually get to it.

@bep: Thanks for fixing!
From my point of view there is no need to create a new release 0.82.1 just for this since I now use the described workaround.


add PureeConfiguration#register() method

#register() is an alternative interface to #source().to(). What do you think of it?
I think #source() is confusing because it does not return PureeConfiguration.Builder even if it seems a builder pattern. In fact, I can't understand how it works in the first impression.
register(FooLog.class, new FooOutput().withFilter(...)), instead, shows it requires a pair of (1) a JsonConvertible log class and (2) a PureeOutput class which might have some filter classes.
Usage
From PureeConfigurationTest.java:
current
        PureeConfiguration conf = new PureeConfiguration.Builder(context)
                .source(FooLog.class).to(new OutFoo())
                .source(FooLog.class).filters(new FooFilter()).to(new OutFoo())
                .source(FooLog.class).filter(new FooFilter()).filter(new BarFilter()).to(new OutBar())
                .source(BarLog.class).filter(new FooFilter()).to(new OutFoo())
                .build();

new
        PureeConfiguration conf = new PureeConfiguration.Builder(context)
                .register(FooLog.class, new OutFoo())
                .register(FooLog.class, new OutFoo().withFilters(new FooFilter()))
                .register(FooLog.class, new OutBar().withFilters(new FooFilter(), new BarFilter()))
                .register(BarLog.class, new OutFoo().withFilters(new FooFilter()))
                .build();

Backward Compatibility
This PR keeps backward compatibility.

@gfx It looks clear interface and nice compatibility support. I agree with you :+1:

@rejasupotaro Thanks to review my PR. Will merge after updating README.


YuMi Arm-angle Definition/Robtargets Issue

Hello,
I tried using the example code given in the installation instructions on the wiki in a ROS package:
from yumipy import YuMiRobot
start the robot interface
y = YuMiRobot(arm_type='remote')
getting the current pose of the right end effector
pose = y.right.get_pose()
move right arm forward by 5cm using goto_pose
pose.translation[0] += 0.05
y.right.goto_pose(pose)
move right arm back by 5cm using move delta
y.right.goto_pose_delta((-0.05,0,0))_
The program ran but I received the following error message on the FlexPendant for the YuMi robot:
Event Message 50488
Using old target definition
Description
The target for ROB_R is using the old definition for cfx.
This is not compatible with the new arm angle definition.
Actions
Convert robtargets in the RAPID program to the new arm-angle definition (recommended) or change the configuration parameter Arm-Angle definition topic Motion and type Robot to ‘Old’.
How should this change be made, is it possible to change this arm-angle definition using a conversion in the ROS code or is this something that has to be changed in the RAPID server?

Interesting, we have not seen this error before. I suspect that you are on a new version of RobotWare that changed the target definitions. What is your version? We are on <IP_ADDRESS>.

The RobotWare version running on the YuMi robot is <IP_ADDRESS>.

After a bit of searching, I recommend changing the parameter "Arm-Angle Definition" from "New" to "Old" as described here.
It seems that you can do this by navigating on the FlexPendant to "Control Panel"->"Configuration"->"Topics"->"Motion"->"Robot" and then clicking on the parameter.

Thank you for the advice, this solution has worked and we could control the robot with ROS. Whilst using the code mentioned in the first post of this thread we were successfully able to use the move delta command however we encountered errors with the commands relating to getting the current pose of the robot arm, applying a translation and moving the arm to the new position. These errors seemed to indicate that the pose used with the goto_pose was unreachable by the robot.
To ensure the requested pose was reachable, we modified the above code so that the current pose of the robot would be saved and printed to the computer screen, move delta would be used to move the arm forward 10 cm and goto_pose used to move back to the original pose. Every time we tried to move the robot back to its original pose using this sequence of commands we got the following errors:
Traceback (most recent call last):
File "/home/ezzdtb/YuMi_CAM_ws/src/yumitest/src/test.py", line 22, in
y.right.goto_pose(pose)
File "/home/ezzdtb/YuMi_CAM_ws/src/yumipy/./yumipy/yumi_arm.py", line 1184, in handle_remote_call
raise RuntimeError("Service call failed: {0}".format(str(e)))
RuntimeError: Service call failed: service [/yumi_robot/right_arm] responded with an error: error processing request: Failed Request!
_Req: REQ_PACKET(req='1 229.1 -334.4 176 -0.06499 0.65488 0.06799 0.74986 #', timeout=8, return_res=True)
_Res: RAW_RES(mirror_code=1, res_code=0, message='Unreachable Pose')
This seems to indicate that the error is due to an unreachable pose however the pose requested should be within the robot's reach. The only difference between the position printed and that displayed on the FlexPendant was that the signs on each of the values of the Quaternion were the opposite i.e. one being negative where the other gives positive with the same absolute value however I don't think this would make a difference. How is a pose defined within ROS for the YuMi robot and how would this be input as Python code?

YuMi's motion planner sometimes acts in unintuitive ways. It is rarely this case but it is possible to perform for the YuMi to go to a pose from a starting pose w/o any errors but triggering an unreachable pose error when going back to the starting pose.
To help us debug, could you:

Paste the exact series of commands you've run to trigger this error, including the initial poses of the robot
Try performing the movement at a different starting pose.
Try to perform the backwards motion w/ goto_pose_delta instead of goto_pose

Note that if the optional arg "relative" is set to True in goto_pose (it defaults to False), then goto_pose will compute the relative pose and call goto_pose_delta.

The exact series of commands used in this case are:
from yumipy import YuMiRobot
y = YuMiRobot(arm_type='remote')
pose = y.right.get_pose()
print(pose)
y.right.goto_pose_delta((+0.10,0,0))
y.right.goto_pose(pose)
The original position was:
Tra: [ 0.22910002 -0.33443001  0.17604001]
Rot: [[-0.13382395  0.18651025  0.97329599]
[-0.00841685 -0.98230862  0.18708003]
[ 0.99096938  0.0168437   0.13302625]]
Qtn: [-0.06498785  0.65487755  0.06798729  0.74985979]
When the move delta command was executed the position was given on the FlexPendant as:
Tra: [0.32909 -0.33444  0.17604]
Qtn: [0.06498  -0.65522  -0.06793  -0.74957]
Following the successful execution of this command the error occurred.
We tried running the robot from a few different positions before and the go to pose command did work on one occasion, however I do not have the positions for this, but otherwise kept hitting the same error.
I will try this code again for different arm positions and provide the response however I will be unable to do this until next week.

I was able to reproduce the error with your commands, starting at the home pose of the YuMi. Unfortunately there isn't much we can do here, as YuMi's internal motion planners are not "consistent" in the sense that successfully commanding a sequence of poses one way does not guarantee that the same sequence of poses can be successfully executed in reverse.
In contrast, a sequence of reachable joints should always be able to be executed with the same success forwards and backwards.
For our applications we have yet to run into scenarios where YuMi's pose inconsistency became a significant problem, as it doesn't occur for most of the workspace. If it is crucial for your application that you need that specific pose for some trajectory, I'd recommend using joints for that step instead.


webdav fails after docker build

I am looking for a hint how to fix the below ...
I cloned the latest bits.
I build the Dockerfile: docker build -t my-webdav .
and run it using docker-compose.yml
I left the config files as is & set USERNAME, PASSWORD and AUTH_TYPE in my docker-compose.yml
I can mount the webdav share ok and see the files & folders that I put on the filesystem for test.
I can not create files or folders. When I try that I get the errors below.
[Wed Feb 13 20:27:42.239529 2019] [dav_fs:crit] [pid 14:tid<PHONE_NUMBER>08464] (20019)DSO load failed: AH00576: The DBM driver could not be loaded
[Wed Feb 13 20:27:42.239560 2019] [dav:error] [pid 14:tid<PHONE_NUMBER>08464] [client <IP_ADDRESS>:40760] The locks could not be queried for verification against a possible "If:" header.  [500, #0]
[Wed Feb 13 20:27:42.239568 2019] [dav:error] [pid 14:tid<PHONE_NUMBER>08464] [client <IP_ADDRESS>:40760] Could not open the lock database.  [500, #400]
[Wed Feb 13 20:27:42.239571 2019] [dav:error] [pid 14:tid<PHONE_NUMBER>08464] (20019)DSO load failed: [client <IP_ADDRESS>:40760] Could not open property database.  [500, #1]
<IP_ADDRESS> - henri [13/Feb/2019:20:27:42 +0000] "MKCOL /test/ HTTP/1.1" 500 528 "-" "davfs2/1.5.4 neon/0.30.2"
Notes: on the webdav-share:/var/lib/dav I see

data folder
DavLock
Not created are these (I found these on the working machine using bytemark/webdav image):
DavLock.dir
DavLock.pag

PS: The prebuild bytemark/webdav image works fine on my machine but I want to modify it a bit.

Using an earlier httpd:alpine image fixed this for me: when I said FROM httpd:2.4.37-alpine in Dockerfile the error went away.
2.4.37 seems to be the version the bytemark/webdav image on dockerhub was built with.

Thanks for getting back. httpd:2.4.37-alpine works for me too. Also httpd:2.4.39-alpine (latest from 5 days ago) is working. So there seems to be an incompatibility with just httpd:2.4.38-alpine.
Van: Andreas Zapf<EMAIL_ADDRESS>Verzonden: zondag 7 april 2019 23:03
Aan: BytemarkHosting/docker-webdav<EMAIL_ADDRESS>CC: Henri<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Onderwerp: Re: [BytemarkHosting/docker-webdav] webdav fails after docker build (#8)
Using an earlier httpd:alpine image fixed this for me: when I said FROM httpd:2.4.37-alpine in Dockerfile the error went away.
2.4.37 seems to be the version the bytemark/webdav image on dockerhub was built with.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/BytemarkHosting/docker-webdav/issues/8#issuecomment-480629432 , or mute the thread https://github.com/notifications/unsubscribe-auth/AOHR1qy40l5aLyGnwPvT4WyaPIrZLybHks5vel0GgaJpZM4a6PJO .  https://github.com/notifications/beacon/AOHR1oVSy3EVfprZVM87mtYrC-qdid4Hks5vel0GgaJpZM4a6PJO.gif


Homebrew version updates?

Hey.
The homebrew tap is still only installing v1.5.1. Is it expected to get the newer versions or should I move to a different install method?

Hi @grantyoung, we deprecated the binaries in v 1.5.2, which directly affects homebrew.
We strongly suggest you to move to using our docker images.
let us know if you need any help on that!

Oh ok, thanks. Will do that.

Although you may want to remove the docs section then?


Should the Bruker reco_map_slope parameter be multiplied or divided?

the function slope_corrector applies the slope like data[]=data[]*slope, however
Here, the slope is applied as data[]=data[]/slope+offset
In my own data, applying the reco_map_slope values by dividing produces reasonable results: the values in the diffusion directions are smaller that those for b0 (the images look 'darker').

Thanks your help in improving bruker2nifti, your feedback is very useful!
Thanks for the link. Please check the screenshot (page D2-66)
to the ParaVision manual (let me know if you need more pages and how can I send the to you).
About the intensity, to my understanding the b0 should have a lower intensity than the others, being the magnetic field some Tesla less stronger. Please correct me if I am wrong.

Thank you for bruker2nifti! I had started hacking my own converter just by reading the reco, etc, files (here). I'm very happy that you are doing it right :D
You are correct about the b0. I had a vague image  of an exponential decrease in image intensity, but this is the first dwi data i analyse, i'm just starting to learn about it : )
I just realised that the value you are using for correcting the slope is not the same I was using! You use VisuCoreDataSlope from visu_pars and I used RECO_map_slope from reco. I started using the RECO_map_slope correction because without it the tensor fitting produced values >1. The problem is what was describe here: http://community.mrtrix.org/t/using-bruker-2dseq-file-beware-reco-slope/613
The RECO_map_slope also comes with a RECO_map_offset, but that offset value seems to be always set to 0.

[and i'd be happy to have the complete format definition if it's ok!]

I'm starting to learn about it too.
Initially also this converter was based on the RECO param-file. Using only the visu_pars solved more issues that the one it created, so it may be a better option.
For the complete format definition let me know where I can send you some files.

I tried multiplying the slope factor in RECO_map_slope, and the results are really awful. I continued to the tensor fitting, and the result were also abnormal.
I think that in fact the values are ment to be divided to recover the original image. In fact, in the manual (D-7-25) when they talk about reconstruction it's not the reconstruction of the original data, but the reconstruction of the data that's saved into the file:

Image Mapping 7.17
Image mapping is the phrase which is used to describe the way in which the final image data are generated. Since the reconstruction uses a floating point data representation internally and since all of the currently fully supported image formats use some integer representation of the data, a mapping function of some kind must always be used to generate the final images. The mapping function which is used is always a linear function, but the way in which it is selected is determined primarily by two parameters, the RECO_wordtype and the RECO_map_mode.

The conversion formula is like this:
m = RECO_map_min[i]
M = RECO_map_max[i]
b = RECO_map_offset[i]
s = RECO_map_slope[i]
x = floating point internal value
y = image pixel value

y = (M-b) if x>=M
y = (x-b)*s if m<x<M
y = (m-b)*s if x<=m

The important point is that the y values are the values stored in the file, and the x values are the original, floating point, internal values. So, to recover the original data, the transformation has to be inverted to:
x = y/s+b

Where b is most of the time zero, so that the transformation is basically x=y/s. When I use that transformation in the code, the tensor fitting and the FA make sense.

Interesting!
For my data, both PV version 5 and 6, the conversion worked well as in the version proposed, i.e. by multiplying for the visu_pars slope.
What is the ParaVision version used to create the files?
Do we have to assume this depends on the PV version or on something else?
Would be helpful to have a copy of the RECO and visu_pars of your data.
For what I understood, the visu_pars is filled from the reco file and other parameter files (method and acqp) to provide a stand-alone parameter file to convert to DICOM.
My guess, that needs further investigations, is that the translation from reco+method+acqp to visu_pars for the DICOM conversion has not always been successful, in particular for old versions (check for example issue #11).
Integrating this ParaVision "feature" into the converter may be not that straight.
Probably @neurolabusc may have encountered this before.

this link to my data should be working now:
https://files.osf.io/v1/resources/x36aa/providers/osfstorage/5993d759b83f690250db72f8?action=download&version=1&direct

Thanks, I see that the VisuCreatorVersion is 5.1 and the VisuCorePosition is HeadSupine.
So we can't rely on these variables as criteria to discriminate between datasets to change orientation and slope correction function.
And I agree the salt and pepper artefact can be caused by a mis-correction of the slope.
Time-points between 163 and 165 seems problematic, as if the problem was also in the slice reconstruction other than the slope (in particular 165 slice z=41).
Interestingly enough the protocol you used for the acquisition is a 2D (VisuAcqSize as dimension 2), while for my dataset is a 3D.
As a consequence the VisuCorePosition is in your case a matrix (n_slices x 3) , increasing from the y coordinate (stack are left to right), mine is a 1 x 3 matrix for the DWI with 3D protocol.
More interestingly, in the data I have, acquired with a 2D protocol (that are correctly converted), the VisuCorePosition is again a (n_slices x 3) increasing from the z coordinate (stacks are inferior to superior).
I think the "stack-direction" (x, y or z) when the acquisition protocol is 2D needs to be taken into account as a new variable. And this has an impact both on the orientation and the slope correction.
Need to do more tests and will let you know! Thanks again for the data.

Function get_stack_direction_from_VisuCorePosition in _getters implemented. It will be integrated (in the next patch release) in the compute_affine_from_visu_pars as an additional information to decode the orientation matrix.


Occident, Gloaming, Weltschmerz

@jillhkm Please check Weltschmerz.json file. You'll see an additional comma after the second definition. Remove it and commit again.

@jillhkm Fixed and merged. @Niweera  Thanks for pointing it out
Thanks for contributing


Error while registering!

I've successfully connected to mongodb and started lablabel-server and client but I'm getting following error while registering a user.
Unhandled Rejection (TypeError): Cannot read property 'msg' of null
C:/Users/msk/Desktop/open_source/LabelLab/labellab-client/src/actions/index.js:74

@msk4862 I have updated the code and implemented checks on passing arguments.


Donut Jenkins Plugin missing in Jenkins 2.89.4

Jenkins plugin for Donut reporting framework is missing.
Tried creating hpi file using checked out project got installed successfully.
However plugin is not visible under post build actions.

Seeing above error when importing maven dependency

Hi ketu4u2010,
We haven't been able to update the maven/jenkins plugins for a while. It may take some time to investigate. In the meantime, is it  possible to use the jar directly - you can follow the steps here: https://github.com/DonutReport/donut. You could execute the donut on Jenkins as well.
Also, since this is an open source project, feel free to submit a PR if you're up for it.
Regards,
Amit

Hi Amit,
Thanks for prompt response. I tried running batch command on Jenkins and modified certain settings too. Problem  I am facing are as follows.

Pie charts are not being displayed on Jenkins
Unable to view screenshot for failed cases

Arguments set are as follows in Jenkins.xml
-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle "-Dhudson.model.DirectoryBrowserSupport.CSP=sandbox allow-same-origin allow-scripts; default-src 'self'; script-src * 'unsafe-eval'; img-src *; style-src * 'unsafe-inline'; font-src *;" -jar "%BASE%\jenkins.war" --httpPort=8080 --webroot="%BASE%\war"
do we need to add any other parameters for it to work?

In addition, Please correct if below understanding is correct or not.
Donut reports are not generating a trend which is being generated by other framework such as Cucumber, Allure etc.
This is due to fact that Donut was executed at command line and not by Jenkins. Once Jenkins plugin is in place, it will generate the same.
Kindly confirm.

Hello Guys,
I tried using Jar file directly but then facing few issues.

Unable to view Pie chat for feature and scenario
Screenshots are not clickable. Same works fine when you download report
to your local
History for past results not available.

Can you please help me to sort out this issue.
Regards
Ketu
On Fri, Feb 16, 2018 at 9:50 AM, temyers<EMAIL_ADDRESS>wrote:

Hi @ketu4u2010 https://github.com/ketu4u2010
The errors you see in Eclipse are down to the fact that those plugins add
stages to the Maven Lifecycle, but do not provide Eclipse Connectors. As
such, they will not be triggered during the Eclipse build process.
These should be excluded from the build, using Maven from the command line
for building.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/DonutReport/donut-jenkins-plugin/issues/5#issuecomment-366140513,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AfASTE5F6lhUR2E7Pfpi-aZbJfMkjRFtks5tVQIWgaJpZM4SGozD
.

Hi Ketu,
Apologies for the delay.
We are looking into this, please bear with us.

Hi Ketu,
I could not reproduce the behaviour in our jenkins box.
When I installed the .hpi file, was able to select the Generate Donut report from the post-build step.
I have this setup in my test-suites pom:

io.magentys
donut-maven-plugin
0.0.5

execution
post-integration-test

generate

${project.build.directory}/cucumber-reports
${project.build.directory}/donut/
${maven.build.timestamp}

${project.name}
${project.name}
${project.version}

Could you please describe what were the steps you did?
Thank you for your help.
Best Regards,
Attila

Hi Attila,
Can you please share the hpi file that you are trying. When we tried building the same, we were unable to install.
In addition,  we are directly executing java -jar donut.jar command via jenkins execute command via ssh.
Regards
Ketu

Hey,
Hope you're doing fine.
I attached the hpi file I was using on my side.
Bets Regards,
Attila
donut-jenkins-plugin.hpi.zip

Hi Attila,
Appreciate your prompt response. We were able to get hpi installed and generate the report cleanly. However faced below issue.

Pie charts does not get displayed on Chrome
Can not generate history/trend for same set of results.

Have you faced any similar issues?
Regards
Ketu

Hi Ketu,
We did not face these issues.
Is that issue coming only on chrome? Which version of chrome are you using?
Regards,
Attila


Double backticks do not follow syntax rules in function arguments, i.e. can be used without spaces

Arguments to a function must be separated by spaces. But if an argument is an identifier written with double backticks, adjacent arguments can be given without spaces.
Same is true for combining backtick-identifiers with non-back-identifiers.
Repro steps
Minimal repro:
let ``hi`` = 12
let ``bye`` = 13
let f x y = x + y
let g = f``hi````bye``   // no spaces between f, ``hi`` and ``bye``

Or even sillier:
let ``hi`` = 12
let ``bye`` = 13
let hi2 = 14
let bye2 = 15
let f w x y z = w + x + y + z
let g = f``hi``hi2``bye``bye2    // no spaces between backticked and non-backticked idents

Expected behavior
This syntax is illegal according to the F# Spec. Identifiers must be separated by spaces.
Actual behavior
No syntax error is thrown.
Known workarounds
n/a
Related information
Seen on F# 4.0, F# 4.1, VS2015, VS2017.

In fact, it is worse. I thought it was only when the idents are used, but it also happens on definition, this appears legal:
let ``hi````bye`` = 3     // creates a function ``hi`` with argument ``bye``, not expected

but the spec clearly says (p27):

Any sequence of characters that is enclosed in double-backtick marks ( ), excluding newlines,
tabs, and double-backtick pairs themselves, is treated as an identifier.

I think we would adjust/clarify  the spec in these cases. Do you have a section reference for "Identifiers must be separated by spaces"? A better wording would be must be separate tokens
On the second one - to me the spec says that hi and bye are separate tokens?  Hence one is a function and one an argument

@dsyme, I checked, but couldn't find it. But the syntax, which sends some variant of ebnf does require spaces between about every token. When we were writing the XPath specification, we had a general statement on whitespace being allowed between tokens, except when marked as whitespace explicit (for instance in F# that would be with UL and the like, abs a minority of the operators).
If this isn't meant to be whitespace specific, it behaves differently from the section I copied in in the original post. If it is, I think it's ambiguous in the spec. If we cab solve this by fixing the spec retrospectively it would be great.
Does an annotated ebnf exist for f#? Or something more parsable or readable than what's used in the spec?

Closing this out by adding it to https://github.com/fsharp/fsfoundation/issues/841


Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Installation issue.
Brief description of your issue
installation fails with error 0x80070422 : "The service cannot be started, either because it is disabled or because it has no enabled devices associated with it."
Steps to reproduce
winget install Microsoft.VCLibs.Desktop.14
Actual behavior
winget install Microsoft.VCLibs.Desktop.14
Found an existing package already installed. Trying to upgrade the installed package...
Found Microsoft Visual C++ 2015 UWP Desktop Runtime Package [Microsoft.VCLibs.Desktop.14] Version 14.0.33321.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...
Installer failed with exit code: 0x80070422 : The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

Expected behavior
a succesfull installation
Environment
winget --info
Windows Package Manager v1.6.3482
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19044.3930
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.3482.0

Screenshots and Logs
No response

@BOY0038v2 - have you tried installing VCLibs 14 directly and not using winget? It seems that error is coming directly from the installer.
Are there any log files like Winget.Microsoft.VCLibs.14... in your winget logs directory that you can share?

No, i haven't tried to install in directly
Anyway, here are the logs after running winget upgrade Microsoft.VCLibs.Desktop.14
2024-02-08 10:52:48.217 [CORE] WinGet, version [1.6.3482], activity [{EB7B4C03-069E-46A2-B48A-55BBE2733BC2}]
2024-02-08 10:52:48.217 [CORE] OS: Windows.Desktop v10.0.19044.3930
2024-02-08 10:52:48.217 [CORE] Command line Args: winget  upgrade Microsoft.VCLibs.Desktop.14
2024-02-08 10:52:48.217 [CORE] Package: Microsoft.DesktopAppInstaller v1.21.3482.0
2024-02-08 10:52:48.217 [CORE] IsCOMCall:0; Caller: winget-cli
2024-02-08 10:52:48.221 [CLI ] WinGet invoked with arguments: 'upgrade' 'Microsoft.VCLibs.Desktop.14'
2024-02-08 10:52:48.221 [CLI ] Found subcommand: upgrade
2024-02-08 10:52:48.221 [CLI ] Leaf command to execute: root:upgrade
2024-02-08 10:52:48.223 [CLI ] Executing command: upgrade
2024-02-08 10:52:48.224 [REPO] Default source requested, multiple sources available, adding all to source references.
2024-02-08 10:52:48.224 [REPO] Adding to source references msstore
2024-02-08 10:52:48.224 [REPO] Adding to source references winget
2024-02-08 10:52:48.231 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2024-02-08 10:52:48.231 [CORE] Found matching extension.
2024-02-08 10:52:48.233 [REPO] Multiple sources available, creating aggregated source.
2024-02-08 10:52:48.233 [REPO] Adding to aggregated source: msstore
2024-02-08 10:52:48.233 [REPO] Sending http GET request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/information
2024-02-08 10:52:48.468 [REPO] Response status: 200
2024-02-08 10:52:48.468 [REPO] Sending http GET request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/information
2024-02-08 10:52:48.487 [REPO] Response status: 200
2024-02-08 10:52:48.487 [REPO] Adding to aggregated source: winget
2024-02-08 10:52:48.491 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2024-02-08 10:52:48.492 [CORE] Found matching extension.
2024-02-08 10:52:48.502 [REPO] Opening SQLite Index for ImmutableRead at 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2024.208.644.297_neutral__8wekyb3d8bbwe\Public\index.db'
2024-02-08 10:52:48.502 [SQL ] Opening SQLite connection #1: 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2024.208.644.297_neutral__8wekyb3d8bbwe\Public\index.db' [1, 40]
2024-02-08 10:52:48.502 [REPO] Opened SQLite Index with version [1.7], last write [2024-02-08 06:43:36.000]
2024-02-08 10:52:48.594 [REPO] Creating new SQLite Index with version [Latest] at ':memory:'
2024-02-08 10:52:48.594 [SQL ] Opening SQLite connection #2: ':memory:' [6, 0]
2024-02-08 10:52:48.597 [REPO] Reading MSI UpgradeCodes
2024-02-08 10:52:48.615 [REPO] Reading MSI UpgradeCodes
2024-02-08 10:52:48.627 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\Schema\1_0\Interface_1_0.cpp(197)\WindowsPackageManager.dll!00007FFBF2DA597D: (caller: 00007FFBF2DABE09) Exception(1) tid(17a4) 800700B7 Cannot create a file when that file already exists.

2024-02-08 10:52:48.630 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\Schema\1_0\Interface_1_0.cpp(197)\WindowsPackageManager.dll!00007FFBF2DA597D: (caller: 00007FFBF2DABE09) Exception(2) tid(17a4) 800700B7 Cannot create a file when that file already exists.

2024-02-08 10:52:48.636 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\Schema\1_0\Interface_1_0.cpp(197)\WindowsPackageManager.dll!00007FFBF2DA597D: (caller: 00007FFBF2DABE09) Exception(3) tid(17a4) 800700B7 Cannot create a file when that file already exists.

2024-02-08 10:52:48.637 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\Schema\1_0\Interface_1_0.cpp(197)\WindowsPackageManager.dll!00007FFBF2DA597D: (caller: 00007FFBF2DABE09) Exception(4) tid(17a4) 800700B7 Cannot create a file when that file already exists.

2024-02-08 10:52:48.640 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\Schema\1_0\Interface_1_0.cpp(197)\WindowsPackageManager.dll!00007FFBF2DA597D: (caller: 00007FFBF2DABE09) Exception(5) tid(17a4) 800700B7 Cannot create a file when that file already exists.

2024-02-08 10:52:48.653 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\Schema\1_0\Interface_1_0.cpp(197)\WindowsPackageManager.dll!00007FFBF2DA597D: (caller: 00007FFBF2DABE09) Exception(6) tid(17a4) 800700B7 Cannot create a file when that file already exists.

2024-02-08 10:52:48.655 [SQL ] Opening SQLite connection #3: ':memory:' [6, 0]
2024-02-08 10:52:48.706 [REPO] Opening SQLite Index for ReadWrite at 'C:\Users\user1\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\StoreEdgeFD\installed.db'
2024-02-08 10:52:48.706 [SQL ] Opening SQLite connection #4: 'C:\Users\user1\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\StoreEdgeFD\installed.db' [2, 0]
2024-02-08 10:52:48.706 [REPO] Opened SQLite Index with version [1.5], last write [2023-07-12 00:16:38.000]
2024-02-08 10:52:48.708 [REPO] Sending http POST request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/manifestSearch
2024-02-08 10:52:48.966 [REPO] Response status: 200
2024-02-08 10:52:48.969 [REPO] Opening SQLite Index for ReadWrite at 'C:\Users\user1\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db'
2024-02-08 10:52:48.969 [SQL ] Opening SQLite connection #5: 'C:\Users\user1\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db' [2, 0]
2024-02-08 10:52:48.969 [REPO] Opened SQLite Index with version [1.5], last write [2024-02-07 22:30:28.000]
2024-02-08 10:52:48.983 [REPO] Finding installed package from available package using system reference search: Query:[none] Include:PackageFamilyName='microsoft.vclibs.140.00.uwpdesktop_8wekyb3d8bbwe'[Exact] Include:NormalizedNameAndPublisher='microsoftvisualc2015uwpdesktopruntimepackage'+'microsoftplatformextensions'[Exact]
2024-02-08 10:52:48.986 [REPO] Opening pinning index
2024-02-08 10:52:48.986 [REPO] Opening existing pinning index
2024-02-08 10:52:48.986 [REPO] Opening SQLite Index for ReadWrite at 'C:\Users\user1\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\pinning.db'
2024-02-08 10:52:48.986 [SQL ] Opening SQLite connection #6: 'C:\Users\user1\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\pinning.db' [2, 0]
2024-02-08 10:52:48.986 [REPO] Opened Pinning Index with version [1.0], last write [2023-07-06 22:49:42.000]
2024-02-08 10:52:48.987 [CLI ] Found one app. App id: Microsoft.VCLibs.Desktop.14 App name: Microsoft Visual C++ 2015 UWP Desktop Runtime Package
2024-02-08 10:52:48.988 [REPO] Downloading manifest
2024-02-08 10:52:48.988 [CORE] WinINet downloading from url: https://cdn.winget.microsoft.com/cache/manifests/m/Microsoft/VCLibs/Desktop/14/14.0.33321.0/0235
2024-02-08 10:52:49.573 [CORE] Download hash: 3756dc023687ff0441d13c2ee62b142ef18479c8166d47e78293982e2cab55e9
2024-02-08 10:52:49.573 [CORE] Download completed.
2024-02-08 10:52:49.574 [CLI ] Manifest fields: Name [Microsoft Visual C++ 2015 UWP Desktop Runtime Package], Version [14.0.33321.0]
2024-02-08 10:52:49.776 [CLI ] Installer hash verified
2024-02-08 10:52:49.859 [CORE] Starting StagePackageAsync operation #0: https://download.microsoft.com/download/4/7/c/47c6134b-d61f-4024-83bd-b9c9ea951c25/Microsoft.VCLibs.x64.14.00.Desktop.appx
2024-02-08 10:52:49.860 [CORE] Begin waiting for operation #0
2024-02-08 10:52:49.860 [CORE] Begin blocking for operation #0
2024-02-08 10:52:49.863 [CORE] Deployment operation #0: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

2024-02-08 10:52:49.863 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFBF2D30C60: (caller: 00007FFBF2D31A80) Exception(7) tid(17a4) 80070422 The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

    Msg:[Operation failed: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

]

2024-02-08 10:52:49.863 [CORE] Starting RemovePackage operation #1: Microsoft.VCLibs.140.00.UWPDesktop_14.0.33321.0_x64__8wekyb3d8bbwe
2024-02-08 10:52:49.868 [CORE] Begin waiting for operation #1
2024-02-08 10:52:49.868 [CORE] Begin blocking for operation #1
2024-02-08 10:52:49.886 [CORE] Deployment operation #1: Windows cannot remove Microsoft.VCLibs.140.00.UWPDesktop_14.0.33321.0_x64__8wekyb3d8bbwe because the current user does not have that package installed. Use Get-AppxPackage to see the list of packages installed.
2024-02-08 10:52:49.886 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFBF2D30C60: (caller: 00007FFBF2D3226C) Exception(8) tid(17a4) 80073CF1 Package was not found.

    Msg:[Operation failed: Windows cannot remove Microsoft.VCLibs.140.00.UWPDesktop_14.0.33321.0_x64__8wekyb3d8bbwe because the current user does not have that package installed. Use Get-AppxPackage to see the list of packages installed.]

2024-02-08 10:52:49.886 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(126)\WindowsPackageManager.dll!00007FFBF2EAC0D1: (caller: 00007FFBF2D33783) LogHr(1) tid(17a4) 80073CF1 Package was not found.

    Msg:[C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFBF2D30C60: (caller: 00007FFBF2D3226C) Exception(8) tid(17a4) 80073CF1 Package was not found.

    Msg:[Operation failed: Windows cannot remove Microsoft.VCLibs.140.00.UWPDesktop_14.0.33321.0_x64__8wekyb3d8bbwe because the current user does not have that package installed. Use Get-AppxPackage to see the list of packages installed.]
]

2024-02-08 10:52:50.154 [CLI ] MSIX installer failed:<PHONE_NUMBER>
2024-02-08 10:52:50.154 [CLI ] Terminating context: 0x80070422 at C:\__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\InstallFlow.cpp:1fe

Interesting . . .
@denelon - I wonder if this is more of a CLI issue? It seems that if the removal fails, the context is terminated instead of the install being continued?

any update on this problem? It still won't succesfully upgrade


bug: removed the negative value from item prices

Under GSSOC'23
Fixes Issue
Issue solved #705

Changes proposed
I founded a bug in the about section. So in this PR, i have removed all the negative values in the about section price list.

Screenshots
before:

after:

Note to reviewers

hey @Anupkjha2601, can you please check this PR and make it merge!

hey @Anupkjha2601, can you please check this PR and make it merge!


[3.x] [Net] Fix WebRTC returning packets from peers too early.

Due to the async nature of WebRTC implementations, the multiplayer peer could end up having queued packets from a given connection before it is able to emit the "peer_added" signal.
This commit ensures that packets from peers which are not notified yet are skipped by get_packet and get_available_packet_count.
3.x version of: #55952

Thanks!

Cherry-picked for 3.4.1.


Large overhead for vectorized ans encoding

Hi,
Thank you for this wonderful repo! I have a question about vectorized ans encoding.
The situation is that my images have the size 256x256. When I am using ans encoding, the file size is about 1kb. But after switching to vectorized ans encoding, the file size comes to 6kb. I think it's a large overhead.
Do you have any idea about that? Or, are there any relevant parameters I need to finetune? Thank you again!

Hi,
IIRC rANS incurs a constant overhead when encoding that becomes negligble for long sequences. Vectorized rANS incurs multiple copies of this constant overhead, so is even more wasteful (see discussion in Section2 here 1 and this paper 2) - but again, this becomes negligible for long sequences - unless we are working with small filesizes, which is what you seem to be doing. I was planning to fix this but got distracted unfortunately.
I think your best bet is to write an arithmetic coder that uses the PDFs/CDFs learnt in this repository if fast, efficient compression is important for you. Fabian Mentzer has a cool implementation in his torchac repo 3/

Thank you! That makes sense.

hey @xjh19971, did you manage to use ans encoding (from this repo or the one @Justin-Tan mentioned? Thank you all!


Error underlining fails in composite project setup

TypeScript Version:  3.7.2
Visual Studio Version:  VS 2019 Community (16.4)
Search Terms:
error underlining
Repro Steps

Project A contains 'library' code in file aaa.ts (Project has 'composite' set to true).
Project B references A and consumes a interface Foo declared in aaa.ts
Ensure all files in B are closed.
Open file aaa.ts.
Add a new method to interface Foo (which would cause breakage in B).
Rebuild B and check the output window for the expected error.
In the output window double click on the error line to see the error.
This will open the offending file in B.

Expected behavior:
The file in B should have the error underlined
Actual behavior:
There is no error underlining.
Other points to note:

Restarting Visual Studio causes the error underlining to show up correctly.
If the offending file in Project B is already open then the error underlining works correctly.

There is no way to reproduce this as the error occurs only in a very large project set up. However, we have captured language service logs according to the instructions. Please provide a contact email to send through the logs. I cannot post them here as there is potentially sensitive information.
Usual spiel on why this should be fixed urgently
We are basically operating in the dark without error underlining.

Please email me the logs, Email id is shkamat at microsoft dot com

@sheetalkamat thanks. I've emailed the logs. FYI I've just upgraded to TS 3.7.3 and the bug is still there.

@sheetalkamat thanks for the email. I need to look into this and will try to get back tomorrow.

Adding @PranavSenthilnathan and @uniqueiniquity  to investigate the VS side for this. I have forwarded your logs to them to take a look at it.


fix: Webview rescale when orientation changed

When device orientation changes, Webview loses its position and sizing on the screen.

Please post a screen recording that shows the problem.

Please post a screen recording that shows the problem.

Il mail it to you.

Somehow WebView gets a frame of CGFloat width 0.0 and height 0.0 after screen resize i have no idea how or where. After noticing this and setting it back to UIScreen width and height it seems te be fine.