job_start("bin") - some bin do not execute inside a function

If I directly execute
:let j=job_start("some_exe")
with some_exe=gvim | xpdf | gv | xdvi, all works as expected.
If I put the same statement inside a function, gv & xdvi no longer run, but, gvim & xpdf do. job_info(j) & job_status(j) show no errors. Also, inside the function
call system(bin &)
operates properly on all 4 arguments given above. (But, I do not want to use the system() function)
Feature or bug?

What I reported was a vim instance run in a xterm running a bash shell.
Could you be more specific?
On Wed, Jun 13, 2018 at 11:27 AM, Christian Brabandt <
<EMAIL_ADDRESS>wrote:

Try to run it in a shell and capture stdout and stderr output.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397038803, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmpisLuYNWw3Qc6_2poP0uAZTFDexhks5t8VmKgaJpZM4Ulj49
.

Some appplication might require tty output. And those might deny output to the pipe.

The only obvious difference between gv, xdvi & the other examples I cited
is that they run an autoreload ("watch file") function to update changes on
the screen from the input src file.  So, maybe, that's it? job_status()
says it's running, but, nothing is on the screen & htop displays no such
process. I'm using system() with an &. It works.
On Wed, Jun 13, 2018 at 6:45 PM, mattn<EMAIL_ADDRESS>wrote:

Some appplication might require tty output. And those might deny output to
the pipe.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397140495, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmpgVAS2cDAn0ykTbHM8cfpkadZ-q2ks5t8cBEgaJpZM4Ulj49
.

What I reported was a vim instance run in a xterm running a bash shell.

Instead of your pipe, run a bash -c <pipecommand> 2> /foobar  command, so you can capture the stderr of your command in the job_start function. I also suspect a missing pty or something similar.

This works
function Test()
let j=job_start('bash -c "gv 2> /tmp/err"')     "gv -> xdvi is also ok.
end function
File err has minor message about missing charset (not important)
If I omit 2> /tmp/err, it will not work. (Can't write to stderr)
If I use as arg for job_start "gv 2> /tmp/err", it will not work.
Inside a function, I need both a shell to launch + a path to an error file.
Outside a function, as part of a map statement, for example, all I need is
let j=job_start("gv")
Same, of course, if I simple give that command preceded by a :
So I ask again. Bug? Feature? Native characteristic? Add documentation to
Channels.txt?
On Wed, Jun 13, 2018 at 10:12 PM, Christian Brabandt <
<EMAIL_ADDRESS>wrote:

What I reported was a vim instance run in a xterm running a bash shell.
Instead of your pipe, run a bash -c  2> /foobar command, so
you can capture the stderr of your command in the job_start function. I
also suspect a missing pty or something similar.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397172630, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmpiC1rvFDAM24R6AbFluLRvSXuckEks5t8fC1gaJpZM4Ulj49
.

The help for job_start says:

            The command is executed directly, not through a shell, the
            'shell' option is not used.  To use the shell:

Piping things is a property of the shell, it won't work when executing jobs directly. So you need to use a shell.

But, why, then, the difference between inside & outside a vim function?
On Thu, Jun 14, 2018 at 12:36 PM, Christian Brabandt <
<EMAIL_ADDRESS>wrote:

Closed #3003 https://github.com/vim/vim/issues/3003.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#event-1681989388, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AhBmpsShLXtSVwn4WvseyyHP9AFXmupBks5t8rtSgaJpZM4Ulj49
.

In the statement
let j = job_start(some_exe)

run outside a function, j is a global variable. When the same line is used inside a function, j is local to the function. To access a global variable inside a function, you ned to explicitly specify the global scope, by calling the variable g:j instead.
Maybe that makes a difference?
Best regards,
Tony.

Not sure what you mean with inside the function and outside the function. I found your message hard to read. Please state clearly what works and what doesn't.
However note, that 2> redirection is a property of your shell, so you need to use a shell command to the job_start()

Brilliant! You're right j -> g.j does it. I'm embarrassed by my oversight.
Thanks!
Guido99
On Thu, Jun 14, 2018 at 1:06 PM, Tony Mechelynck<EMAIL_ADDRESS>wrote:

In the statement
let j = job_start(some_exe)
run outside a function, j is a global variable. When the same line is used
inside a function, j is local to the function. To access a global variable
inside a function, you ned to explicitly specify the global scope, by
calling the variable g:j instead.
Maybe that makes a difference?
Best regards,
Tony.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397422060, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmpoln4m5RtR8lIYmgZU2p7p4Z5cvJks5t8sJVgaJpZM4Ulj49
.

Please try to be concise and state clearly your problem, I have problems understanding your issue. So please be precise and clearly state what you do, what you expect and what you saw.
Please ask user questions on the vim_use mailinglist or use vi.stackexchange.com. This here is a bug tracker for problems with Vim. We cannot provide individual help here. Closing.

I did my best to describe in detail with code examples of what I thought
was a bug. It is clear that the explanation of job_start() is inadequate in
its current form inside doc/channel.txt (my opinion).
On Thu, Jun 14, 2018 at 1:29 PM, Christian Brabandt <
<EMAIL_ADDRESS>wrote:

Please try to be concise and state clearly your problem, I have problems
understanding your issue. So please be precise and clearly state what you
do, what you expect and what you saw.
Please ask user questions on the vim_use mailinglist or use
vi.stackexchange.com. This here is a bug tracker for problems with Vim.
We cannot provide individual help here. Closing.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397428158, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmpmgvE_9mweZODoGMtKez6uAOVttLks5t8se7gaJpZM4Ulj49
.

It is clear that the explanation of job_start() is inadequate in its current form inside doc/channel.txt

In what way? What do you think is missing?

@guido99 See :help job_start.

The command is executed directly, not through a shell, the 'shell' option is not used.  To use the shell:

job_start() works as expected. And documents is right.

Also piping thing is a feature of shell. This is basically knowledge of UNIX not Vim things.

Unlike other functions
call job_start(...)

will not work. That should be noted in docs.
But, most importantly, the variable, eg, jobnum, as in
let jobnum=job_start(...)

must be global, not local. Inside a VimScript function, such a variable
must be denoted explicitly as g:jobnum.
I think these two items are important because the function job_start() is
highly useful. With it, I have built a simple integrated environment (a
VimScript function) to create & edit Latex, Postscript, .. files.
On Thu, Jun 14, 2018 at 11:14 PM, Christian Brabandt <
<EMAIL_ADDRESS>wrote:

It is clear that the explanation of job_start() is inadequate in its
current form inside doc/channel.txt
In what way? What do you think is missing?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397523986, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmptCd3bmFajZSod4f4mN1oJP6xYGKks5t81CrgaJpZM4Ulj49
.

Unlike other functions call job_start(...) will not work

It works just fine, as long as you don't need to access the job object later.

But, most importantly, the variable, eg, jobnum, as in let jobnum=job_start(...) must be global, not local.

No, that's not true either.  The only requirement is that the variable is accessible for the lifetime that you need it.  If it needs to be accessed outside of a function, then it can be stored inside a script-local variable, buffer-local variable, or whatever makes sense for your plugin.

None of what you say is correct. I have tested numerous cases. What I
describe is true & accurate.
What you claim will work occasionally, not consistently. For example,
inside a function, let j=job_start("gvim") is ok, but if I use gv instead
of gvim, it won't. Other examples are readily found.
On Fri, Jun 15, 2018 at 9:39 AM, James McCoy<EMAIL_ADDRESS>wrote:

Unlike other functions call job_start(...) will not work
It works just fine, as long as you don't need to access the job object
later.
But, most importantly, the variable, eg, jobnum, as in let
jobnum=job_start(...) must be global, not local.
No, that's not true either. The only requirement is that the variable is
accessible for the lifetime that you need it. If it needs to be accessed
outside of a function, then it can be stored inside a script-local
variable, buffer-local variable, or whatever makes sense for your plugin.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397677004, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmpvd-rll5SXlZRm8dItn-hhkPe0oDks5t8-MpgaJpZM4Ulj49
.

This comment is unrelated to job_start(), but, is to documentation. A
simple example:
The VimScript operator for concatenation is a period char (.) I often
forget that because I code in many languages. It's documented in Vim, but,
hard to find when I forget. Maybe, someone (BM?) add a tag or a few more
words in the text so I could quickly locate it?
On Thu, Jun 14, 2018 at 11:14 PM, Christian Brabandt <
<EMAIL_ADDRESS>wrote:

It is clear that the explanation of job_start() is inadequate in its
current form inside doc/channel.txt
In what way? What do you think is missing?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397523986, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmptCd3bmFajZSod4f4mN1oJP6xYGKks5t81CrgaJpZM4Ulj49
.

You have not read or have not understood all the memos I sent based on
exhaustive testing concerning this issue. (I never claimed there is a
bug.)  One Vim GitHub contributor, Tony M..., fully understood the
situation AND provided the guidance I need to make Vim function as I
desire. Now, let's just drop the matter.
On Fri, Jun 15, 2018 at 10:34 AM, Christian Brabandt <
<EMAIL_ADDRESS>wrote:

Wrong. Please understand, that you cannot use shell constructs inside the
job_start() function, as the job is started directly (without a shell in
between). That means using | or redirection >.. 2>, globbing * or && ||
logical catenation of jobs (and similar ones) etc is a feature of your
shell and not of the command being run. So if you want to use those, you
need to explicitly call a shell with the job being given as parameter.
Running a command most of the time works, as long as the program does not
expect to have a terminal available (or stdin attached to it) or similar.
There is nothing we can fix this in Vim.
What you claim will work occasionally, not consistently. For example,
inside a function, let j=job_start("gvim") is ok, but if I use gv instead
of gvim, it won't. Other examples are readily found.
yes it does. If not, please give concrete examples for what does not work.
The VimScript operator for concatenation is a period char (.) I often
forget that because I code in many languages. It's documented in Vim, but,
hard to find when I forget. Maybe, someone (BM?) add a tag or a few more
words in the text so I could quickly locate it?
Those tags already there, e.g. see :h expr-. See :help summary for
finding efficiently the topics you need. Also please note, ask user
questions on the vim_use mailinglist or use vi.stackexchange.com. This
here is a bug tracker for problems with Vim. We cannot provide individual
help here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397691539, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmppE9-hNJuz8ad74lxzK8bL26rnwBks5t8_AugaJpZM4Ulj49
.

This thread is off the rails.. but there is actually something important here which has not yet been clearly understood.  There is an actual difference (for me) between the following lines typed into the cmdline:
:call job_start('xdvi')
and
:let j = job_start('xdvi')
In the former there is no xdvi window popup while in the latter, there is.  This is extremely surprising to me and I assume for anyone else experienced with vimscript.  If it is expected behavior, it is not clearly documented.
@chrisbra, @jamessan are you saying both examples produce the same result for you?

Testing with both 8.0.1766 (current Debian package) terminal vim and gvim and freshly built 8.1.0055, both of those commands start xdvi for me.

Same for me in vim/gvim terminal! (8.1.0039.)
On Fri, Jun 15, 2018 at 12:42 PM, James McCoy<EMAIL_ADDRESS>wrote:

Testing with both 8.0.1766 (current Debian package) terminal vim and gvim
and freshly built 8.1.0055, both of those commands start xdvi for me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/3003#issuecomment-397723259, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AhBmpka55ezK-lM_IdeUFkOLL4m71kSJks5t9A4WgaJpZM4Ulj49
.


Feature/css3ify

This resets CSS3 styles. It also normalizes form elements, using mainly Chrome Webkit as a reference
I updated the targeted HTML5 tags and made them a bit future proof.
There's also a test document that I used to compare cleanslate elements to default styling. This is only for form elements.

@premasagar besides the merge conflicts, can you comment on this? :+1: :-1: ?

Oh wow. This was 6 months ago. Apologies to Mat; I meant to have merged
this.

I haven't yet gone through the PR line by line, considering the impact of
each rule. In general though, this came as the result of a good deal of
research and testing on modern desktop/mobile browsers. That was around 15
months ago. I worked on a big project with Mat and we used the updates he's
providing here and it worked very well for us.
So Jay, that's a thumbs up from me. If you resolve merge conflicts and want
to resubmit the PR, please do. Let me know how you find the updates.
--
Prem Rose
premasagar.com

Merged in 35bdf0


Added dataset collection

I would also run flake8 and black here, there is some bad code style present. Flake should fix it for you. Good work!


Refactor LPSPI with word packing, futures

Instead of using LPSPI continuous transactions, we pack the user's data
into u32 words. The primitives for translating the user's data to / from
the data FIFOs should help us as we consider async LPSPI drivers. And,
in order to implement embedded-hal 1.0 traits, we'll need something like
the dummy transmit / receive helpers, since we need to handle differing
transmit / receive buffer sizes. The included unit tests don't trigger
an error in Miri, and they try to simulate how we'd use the primitives
in firmware. (This is an "it's not obviously wrong" test, not an "it's
correct" test; help me review here.)
The commit introduces spinning futures into the LPSPI driver. By
combining and spinning on these futures, we can realize in-place
transfers, read-only transactions, write-only transactions, etc.
We no longer return the Busy error; we'll wait for transmit FIFO space.
We also never return the NoData error, instead returning success when
there's no I/O to do. Since this commit is a non-breaking change, the
two errors are still available in the error enum. I'll remove them
later.
I'm moving the blocking SPI example into RTIC and rewriting the driver
test. The tests demonstrate overlapping writes, writes with flushes, and
in-place transfers with a physical loopback. There's also tests that
show how word sizes and bit orders interact. I'd appreciate if folks
could test these changes in their system, since it affects how the
embedded-hal implementations behave. I'm only testing this commit on a
1170EVK with the new example.

Thanks for the feedback. One thing I noticed about this change: without a spin on the busy flag, this driver reduces the delay between transfers, or the time that chip select is deasserted between subsequent transactions. Given a 1MHz CLK, I see a reduction from 1430ns to 530ns for that delay.

That's interesting. I had tested the EVK yesterday and thought I saw the opposite result. So I re-tested and it turns out that inter-transfer gaps can be really strange at higher clock frequencies (I had 11 MHz). There are sometimes gaps in the order of multiple microseconds. Toggling a GPIO between each write() call indicates that in these cases there is actually more time spend in the write() call. However, that is AFAICT not a regression, and there are interactions with I-cache that might cause this, so it's probably fine.
The implication being that this is absolutely fine on i.MX RT 1021 and at least as far as bus performance goes does not appear to have a negative impact. Rather spinning on FIFO space instead of Busy seems to be an improvement.

If your workaround includes a spin on the busy flag, if you're bursting write(...)s, and if you were previous at your SPI display's minimum delay between transfers, then this could affect you.

Fortunately (because that would have been virtually impossible to fix) it's likely something else. For one the minimum allowed transfer gap is specified as 40ns, but I've also realized something else:
SPI MIPI interfaces typically have a separate D/C (data/command) pin, which is used to indicate what the data on the SPI bus means. This requires the SPI transfers to be blocking, or at least the ability to flush. That does not entirely explain why spinning for Busy on subsequent write() calls worked, but fundamentally brings us back to a variation on the original bug report: Users of e-h 0.2 expect the trait's methods to block. e-h 1.0 allows not blocking for the SpiBus trait, adding flush(). The SpiDevice trait's methods are however still blocking (implicitly flush).

There's some refactoring we could do to reclaim code space. I pushed a commit to show those changes. I agree that it's still not optimal; in particular, defining transfer with a try_join combinator doesn't get close to what might be ideal.

Interesting, that having two spin_on() (one via wait_for_fifo_space()) calls per operation reduces code size. I assume that is partially due to the inliner refusing to inline the wait_for_fifo_space().

It's convenient (and fun) to define I/O like this, but I'm happy to drop it if folks need that space. mciantyre/imxrt-hal@ab053df isn't applied here, but it drops the futures from this branch.

It's probably better to worry about this later. Having the bug fixed and e-h 1.0 support is more important than code size at least to me. If this turns out to be a real problem we can still try to optimize further down the line.

SPI MIPI interfaces typically have a separate D/C (data/command) pin, which is used to indicate what the data on the SPI bus means. This requires the SPI transfers to be blocking, or at least the ability to flush. That does not entirely explain why spinning for Busy on subsequent write() calls worked, but fundamentally brings us back to a variation on the original bug report: Users of e-h 0.2 expect the trait's methods to block.

I keep forgetting folks want to synchronize external components with the LPSPI through these eh02 interfaces. The latest commit adds a flush at the end of writes and transfers, striving for approach 1 in #136. I'm also not sure why a busy spin in the subsequent write worked, but a concluding flush should provide better guarantees.
Any other thoughts on these changes? Otherwise, I plan to release this into the 0.5 series for more user testing.

Thanks for the reviews!

I guess if you move to an async API some form of completion notification (interrupt) would be needed to mark a Future<> complete is that right? Is there an interrupt for FIFO empty/FIFO watermark/FIFO full events? I'd guess so?

Yup, the LPSPI supports watermarks and interrupt events for both FIFOs. We could use those to drive async I/O.


Use folders my man

Use folders and put inside them the classes, Your project will look alot better.
For example take a look at my RAT project that I'm currently working on:
https://github.com/DanielSparta/2024-RAT-projet
alot more beutiful when you have folder called "Socket" that have things like accept, create.. Or when you  have folder for the client that have class send, receive.... or Tools folder for all the tools, setup folder for all the things such as persistence... GUI folder for GUI's...
Think about It :)

Also, I can see that every class you have, have too many "garbage" code, make your project more clearly and simple to read.
If you will have specific Folders for every thing, and class for every topic, your project can be alot better!
For example, look at my client side RAT:
https://github.com/DanielSparta/2024-RAT-projet/tree/main/Desktop Control panel/RATserverSparta
Looks so good..

tbh, idc, its my coding style and makes it eaiser for me to read, i dont want to switch through 50 different files just to change one thing. have fun and gl with your project.

tbh, idc, its my coding style and makes it eaiser for me to read, i dont want to switch through 50 different files just to change one thing. have fun and gl with your project.

I see there are alot script kiddies on your project, "Valus3000" :/ well, thats a RAT after all.
Anyways, your visual studio as IDE? I think its alot more easy to read when you just double clicking
well thanks I will keep working on my project, just think about that.. folders and more classes..

for me when i have a structured layout in my mind its just easier. well
everything is eaiser when you know where things are. its just a personal
preference, and this isnt some super high tier project, its just my
learning project. I do understand what you mean, having a nice oraganized
way of doing things is always nice, especially if you want a new person to
look at it and understand it. but this project is mainly just for me, its
just a learning project.
On Sun, Feb 4, 2024, 12:43 p.m. Daniel Sparta @.***>
wrote:

tbh, idc, its my coding style and makes it eaiser for me to read, i dont
want to switch through 50 different files just to change one thing. have
fun and gl with your project.
I see there are alot script kiddies on your project, "Valus3000" :/ well,
thats a RAT after all.
Anyways, your visual studio as IDE? I think its alot more easy to read
when you just double clicking
well thanks I will keep working on my project, just think about that..
folders and more classes..
—
Reply to this email directly, view it on GitHub
https://github.com/moom825/xeno-rat/issues/27#issuecomment-1925860206,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APCSZAUUU6BPIESVJAUH3CDYR7CFLAVCNFSM6AAAAABCYWL6MWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVHA3DAMRQGY
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


How to generate COCO annotation file with different species and constraints

I am trying to generate a COCO annotation file for species with the following constraints:
For Anoplopoma fimbria > 700 meters depth
For Gonatus onyx > 1000 meters depth
For Sebastes > 32 degrees latitude
For Sebastolobus > 38 degrees latitude
For Dosidicus gigas  < 500 meters depth
For Nanomia bijuga: > 500 meters
I tried:
fathomnet-generate -c "Anoplopoma fimbria" --min-depth 701
-c "Gonatus onyx" --min-depth 1001
-c "Nanomia bijuga" --min-depth 501
-c "Dosidicus gigas" --max-depth 500
-c "Sebastes"  --min-latitude 32.1
-c "Sebastolobus" --min-latitude 38.1
--format coco -o out_of_region
This did not generate anything.
How can I do this? Do I need to generate each file separately?
This may not be ideal since the id's would not be different for the different species.
Thanks again for your help.

I apologize for the bold font. I just pasted from my bash script and it had "#"

Hi @mi2celis, you are correct, this would need to be done separately; the constraints you specify apply to all concepts you include. In other words, it's not currently possible to specify constraints per-concept. Per-concept constraints could be a feature we add in the future.
Alternatively, you could generate these sub-datasets in the VOC format, then combine the XMLs into one directory (though annotations for images in common would need to be composited). From there, a conversion from VOC to COCO can be done with another tool, e.g. https://github.com/yukkyo/voc2coco.


Hinders in the release apk building process

Hinders in the release apk building process

add the flipper redux  and this FPRD plugin as a dev dependency
build as a staging scheme/flavors.  all works fine on both OS

but when making a release build-out of android it causes failure to make a build!

Make sure to require the plugin behind a DEV check, and update
react-native-flipper to the latest version
On Tue, Jun 30, 2020 at 4:18 PM rizwanCB<EMAIL_ADDRESS>wrote:

Hinders in the release apk building process

add the flipper redux and this FPRD plugin as a dev dependency

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jk-gan/flipper-plugin-redux-debugger/issues/25, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBA25ML6FGCNG6AA4WTRZH63JANCNFSM4OMLAT5Q
.

You might be hitting https://github.com/facebook/flipper/issues/1303 , which should hopefully be fixed soon (or you can work around it by using manual linking instead of autolinking for react-native-flipper)


[Feature]: Provide GitHub's Blame like feature on Appsmith

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
Sometimes we want to know who made a certain change to the application and when. For e.g. is someone marked some action to be run on page load or if someone changed a line in a JS object, another application developer might be interested in knowing who made that change and when.
Why should this be worked on?
Helps with collaborative development.

Stats

Stat
Values

Reach
274

Effort (months)
1


Documented istio-cni config

Also, this needs a page in the differences between us and upstream. And probably a few notices too since this will break user flows using manual injection.

Added comparison with upstream
Added cni section to the full install docs

Added a note that multitenancy must be enabled
Added a link to the CNI spec


Promise support

Is there a way of using Promises with cloudscraper ?

For anyone wondering, here's a wrapper function to make it into a Promise.
function cs(options) {
  return new Promise((resolve,reject) => {
    cloudscraper.request(options, (error, response, body) => {
      if (error) {
        reject(error);
      } else {
        resolve(body);
      }
    });
  })
}

This will be done in the near future.


Feature 1442 file_list

Is there a version of this app available on one of the NCAR machines that I could use to ensure the changes work with METplus?

Compiling now in eyewall:/d1/johnhg/MET/MET_development/MET-feature_1442_file_list/met/bin/tc_gen
Please give it 10 minutes or so.

I tested the METplus wrapper with the changes from this PR and it ran successfully. However, there was an odd error when I tried to run the old method of building the command (a -genesis/-track item for each input found). John is investigating the issue. Once that is resolved, this can be approved.

I tested this potential issue locally but was not able to replicate the problem George describes. I passed the tool 77 instances of the "-genesis" command line option, one for each input file, and tc_gen processed those command line args the same as using "-genesis" once with 77 arguments.
My next step in debugging is running George's exact command on eyewall.

Running unit_tc_gen.xml on eyewall yields the exact same runtime error that George was getting:
terminate called after throwing an instance of 'std::ios_base::failure[abi:cxx11]'
  what():  basic_filebuf::underflow error reading the file: iostream error
Aborted

So the underlying problem is the eyewall build environment and not the code changes themselves. Since I tested those on my local machine and confirmed they worked, I'll proceed with merging this into the develop branch. At the same time, I'll continue debugging the eyewall environment.


Unable to connect to Workgroup database for "What's Going On" TabMon dashboard

Hello !
I am fairly new to this environment...so, please bear with me :)
I installed TabMon on one of our distributed(clustered) Tableau Dev servers (Windows 10) and could get through the PostgresSQL (TabMon) connection but the PostgresSQL (Server Auditing) connection is failing.
Server : localhost, Port: 8060
Database: workgroup
Username: readonly
Password: readonly
I did create the user prior to installing TabMon and restarted the services too
tabadmin dbpass --username readonly readonly
The error I am getting is "could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 8060? could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "localhost" (<IP_ADDRESS>) and accepting TCP/IP connections on port 8060?"
I did follow the leads online and on Github pertaining to modifying the pg_hba.conf and postgres.sql files under the C:\ProgramData\Tableau\Tableau Server\data\tabsvc\config but am just not able to identify the issue.
Under Local Connections, I have these entries.
host    all         rails         <IP_ADDRESS>/32          md5
host    all         tblwgadmin         <IP_ADDRESS>/32          md5
host    all         tableau     <IP_ADDRESS>/32          md5
host    all         readonly     <IP_ADDRESS>/32          md5
host    all         all         <IP_ADDRESS>/32          md5
host    all         rails         0:0:0:0:0:0:0:1/128          md5
host    all         tblwgadmin         0:0:0:0:0:0:0:1/128          md5
host    all         tableau     0:0:0:0:0:0:0:1/128          md5
host    all         readonly     0:0:0:0:0:0:0:1/128          md5
host    all         all         0:0:0:0:0:0:0:1/128          md5
Included the following line in postgressql.conf
listen_addresses = '*'
Any guidance is appreciated.
Best
Sanjeev

Thanks for the response.
TabMon is installed on the same system as the Tableau server and yes, it is otherwise functioning correctly. I can access the other dashboards in TabMon except "What's going on Dashboard?"
I'll double check the firewall rules but am doubtful that we have anything inhibiting those connections but I might be wrong. Do I need to check port 8060 in particular ?
Thanks again for getting back. Appreciate it.

Correct, it is TCP 8060 and should be from <IP_ADDRESS> -> <IP_ADDRESS> and/or ::1 -> ::1 given the way I am reading your current config correctly and the report is already published to Tableau Server, or you are using Tableau Desktop installed on the same server.
FYI: When you start to actually get a connection to the server, you should either connect successfully or your errors will change to something like:
'psql: FATAL:  password authentication failed for user readonly' or
'psql: FATAL: no pg_hba.conf entry for host "", user "readonly", database "workgroup", SSL off'

As a matter of fact I did install Tableau Desktop on the same system where I have Tableau Server installed.
So, there might be 3 instances of Postgres.
So I have TabMon, Tableau Desktop and Tableau Server, all installed on the same server.

Just a quick update. Since we are in a clustered environment, I figured the postgres repository sits on one of the worker nodes. In order to access "What's going on" Dashboard, the connection had to be directed to the worker node instead of the primary node. That resolved the issue.

Hello,
Thanks for the update! I'm glad you were able to resolve the issue. If you have any other questions or issues please let me know!
Thanks,
Dan


Methods to find VS

The registry method is broken, it does not find the SDK. I see no good way to fix it, and the registry variable itself is unreliable. I think it should be removed.
Is there any case where the Powershell method (first one) fails and others succeed?
So, shouldn't there be only one method (Powershell)?

I have yet to find a reproducible scenario that fails for the first one. But....
Failing builds is one of the most frustrating and FAQed issues out there, so I feel that having a backup is good.

So.... I fixed try_registry ;)


onRegionChangeComplete props Callback triggering infinitely without any user input on Android.

i am not using fitToSuppliedMarkers as another issue mentioned, only plain MapComponent . For some reason on Android onRegionChangeComplete is being called infinitely many times. However it is working correctly on IOS.
React native - 0.35
react-native-maps - 0.10.4

if you use region prop along with onRegionChangeComplete , the onRegionChangeComplete is called as a callback. onRegionChangeComplete is called whenever onChange event occurs natively. it could be due to user dragging map, animation on map or even setting up of gps location. If possible another prop should be added like onPanDragComplete so that we get callback only when user drags map and finishes dragging it.

Did you make it work and how? i am also having problem with infinite loop

<MapView           ref={(ref) => { this.map = ref; }}           style={styles.map}           initialRegion={this.props.initialRegion}           loadingEnabled           onRegionChangeComplete={(region) => {             // do something             }           }}         > </MapView>
This is my new mapComponent. It turns out i was using region prop and was only setting state of region. removing it also works.
I don't know how to use both together. If you look at components/MapView.js there is a particular function
_onChange(event) {     this.__lastRegion = event.nativeEvent.region;     if (event.nativeEvent.continuous) {       if (this.props.onRegionChange) {         this.props.onRegionChange(event.nativeEvent.region);       }     } else if (this.props.onRegionChangeComplete) {       this.props.onRegionChangeComplete(event.nativeEvent.region);     }   }
The _onChange method is called whenever any event happens.If whatever you write in onRegionChangeComplete triggers a call to region prop , region prop in itself triggers an _onChange event which causes onRegionChangeComplete to call. This quickly spirals to an infinite loop each callback trigering each other. You can put logs in MapView.js file to see it for yourself.
I think something like a panDragComplete in this case would do the trick. I am not sure if mapkit or google maps provider provide a native event for this or not. But until then make sure onRegionChangeComplete has code without any side effects. Or if you can't do that, remove region prop, it worked for me

Thanks for the input i will try to edit the component so i might get something (or will at the do without region change until they make something like you suggested). You should leave this issue open.

I have an app flow like so:

user enters map scene
user's location is passed to region prop of MapView component
user's location is updated
new location is passed to region prop of MapView component
when onRegionChangeComplete is executed, dispatch some actions to update the state, so we can update some markers on the map

On iOS this works normally. OnRegionChangeComplete gets called twice, as you would expect.
On android, as @akshay2604 mentioned, if a re-render or state change happens during an onRegionChangeComplete callback, then onRegionChangeComplete callbacks get called repeatedly causing an infinite loop.
In order to work around this for now I implemented a check in my onRegionChangeComplete callback to determine if the region has actually changed. If not, return early instead of dispatching actions. This at least eliminates multiple HTTP requests or re-renders occurring.
Example Code:
<MapView
        style={style.map}
        onRegionChangeComplete={(region) => {
          const {initialRegion} = this.state;

          if (initialRegion && isEqual(initialRegion, region)) {
            return;
          }

          this.setState({initialRegion: region});

          // dispatch some actions
        }}
/>

Using version 0.15.2, I solved this problem by having 2 different region props in the state: mapRegion and setMapRegion.
mapRegion:

Used when doing stuff when ever map region changes.
Gets updated in onRegionChange and onRegionChangeComplete.

setMapRegion:

Is bound to the MapView's region property.
Is set when ever I want update the region manually.

My MapView component looks like this:
<MapView
  region={this.state.setMapRegion}
  onRegionChange={(region) => {
      this.setState({
          mapRegion: region,
      })
      ...
  }}
  onRegionChangeComplete={(region) => {
      this.setState({
          mapRegion: region,
      })
      ...
  }}
/>

I just had the same problem i.e.:

I have a button that changes the map position by changing the "region" state variable
The "region" state variable is bound to the region property of MapView
so clicking the button triggers a render, which triggers onRegionChangeComplete()
onRegionChangeComplete changes some other state variable
which triggers a render() call
which triggers an onRegionChangeComplete() call again => infinite loop

and what fixed it was setting the "region" state variable in my onRegionChangeComplete() callback. I am now setting it to the argument being passed to onRegionChangeComplete().
I'm not entirely sure why this fixes it, but I assume it has something to do with the state being the same so it doesn't trigger additional render() calls?
I'm curious if this works for anyone else.
Cheers

I'm use onRegionChangeComplete={e => this.setState({ region: e })} is work

Should be fixed by PR #1710

I discourage controlling region state. Try this: https://github.com/react-community/react-native-maps/issues/209#issuecomment-350907665
Anyway it should be fixed with the PR above.

I found that when you zoom to max. The region from onRegionChangeComplete will be continue changing. The change is so small and about 15/16 significant decimal digits. Is it related to the permission?

@tsangwailam did u find a solution? I have the same problem, it only moves by itself when zoom is on max

Hi guys, any solution for this issue?

if you use region prop along with onRegionChangeComplete , the onRegionChangeComplete is called as a callback. onRegionChangeComplete is called whenever onChange event occurs natively. it could be due to user dragging map, animation on map or even setting up of gps location. If possible another prop should be added like onPanDragComplete so that we get callback only when user drags map and finishes dragging it.

Yes, you're right. Adding initialRegion instead of region solves the problem. However, there is one issue, after onRegionChangeComplete is done saving new region, the map is not updating with the new region we just saved. That only works with region prop. Is there any solution to this issue?

Did you get a fix for this?

For anyone using GoogleMaps, this is how I fixed it (version 1.2.0):
region={this.state.region}
onRegionChangeComplete={(region, gesture) => {
  if (gesture.isGesture) {
    this.setState({ region });
  }
}}

note: gesture.isGesture indicates if the change was made by user or animation.

For anyone using GoogleMaps, this is how I fixed it (version 1.2.0):
region={this.state.region}
onRegionChangeComplete={(region, gesture) => {
  if (gesture.isGesture) {
    this.setState({ region });
  }
}}

note: gesture.isGesture indicates if the change was made by user or animation.

Thanks


[Bug] Multiple active effects on damage card that shouldnt have an

When I roll the damage for the rogue's cunning strike with the activity Cunning Sneak Attack, it adds both the Cunning Strike: Poisoned and Cunning Strike: Tripped to the damage chat card. Now this could be an issue with the new Player's Handbook, but I think its a DnD5e issue, hence why i post it here

No modules besides version 1.0.0 of the Player's Handbook (2024)

DnD5e version 4.0.1
Foundry (Node version) 12.331

I used the rogue character from the phb and only levelled her up to 5 to check the ability

Also happens btw when you roll for the damage of the Bonus Hex Damage activity on the hex spell. also from the new phb

Closed by https://github.com/foundryvtt/dnd5e/pull/4306


Fix return of html.fragments_fromstring

If the string contains leading text, the first element of the returned list will be a str. Only if no_leading_text=True was specified can we guarantee that there will be no str fragment at the beginning.
Related documentation: https://lxml.de/apidoc/lxml.html.html#lxml.html.fragments_fromstring

You're right, I have forgotten the lxml.html counterpart of fragments_fromstring().


doesn't work with multiple kubeconfig files

v0.2.1 returns this error:
panic: stat /Users/ahmet/.kube/config:/Users/ahmet/.kube/twconfig: no such file or directory

if I set a KUBECONFIG=file1:file2:... format.

Thanks for this @ahmetb! I actually didn't realize this was a KUBECONFIG convention, but I am able to reproduce it by spinning up a couple of minikube clusters locally. Going to take a look to see what the most idiomatic way to address this is :slightly_smiling_face:

I recommend sticking to client-go library and methods it offers.

@ahmetb I opened a PR for this under the branch 35-support-multiple-kubeconfigs. Would you be willing to build from that and see if this addresses your use-case? It seems to work for me testing with multiple minikube clusters locally.
Also, given all your work in this space, I'd be interested if there's a better / more idiomatic approach to solving this, but following the client-go docs, using clientcmd.NewNonInteractiveDeferredLoadingClientConfig(loadingRules, configOverrides) seemed pretty much "built-in" to the library. I was pleasantly surprised!
Thanks again for raising this!

Thanks for filing this @ahmetb. We were able to get a fix, cut a release and get our updated version into Krew (https://github.com/kubernetes-sigs/krew-index/pull/2070)
Let us know if you find any other issues!


More bad ideas?

[ ] transition.text(value) - does interpolation, rather than setting on start
[ ] transition.property(name, value) - interpolate arbitrary values (e.g., for canvas)
[ ] transition.propertyTween(name, value) - interpolate arbitrary values (e.g., for canvas)
[ ] transition.styleInterpolate(name, interpolator) - like styleTween, when shared by all nodes
[ ] transition.attrInterpolate(name, interpolator) - like attrTween, when shared by all nodes

Related https://github.com/d3/d3-ease/issues/13#issuecomment-183018097.

Punting on this for now.


Switch (react-foundation) & Switch (react-router-dom)

Actually I was just about to install and use the react-foundation module when I realized the availability of the  component which is identical to ... that I use regularly with react router v4, and I was wondering before amending any of my react code if this will be an issue...?
Has anyone tried using both in the same component?

I think that shouldn't be a problem.
If you want to use both components in the same file you can just import them with different names.
For example you could  import Switch from react router as RouterSwitch to avoid name collision use:
import { Switch as RouterSwitch } from 'react-router-dom';

. . .
<RouterSwitch>
 . . .
</RouterSwitch>

(duhhh!!!) ... that did certainly slip my mind... Thanks a lot...


Not clear whether brand is machine readable or for humans

My take on that is to declare it a machine readable value, that stays the same across OS releases.
The ID values returned by the distro package provide that for Linux, and guarantee that the values don't change (it has a normalization support built in).
As a positive side effect, this would allow getting rid of the long list of Linux distros in osinfo, and to just use the distro.id() value.
The downside is that the osinfo Linux brand strings will change (once), compared to now.

The Linux code in _get_os_brand() would get reduced to:
elif os_type in OSType.Linux:
    return distro.id()

Closing this for now as the project is deprecated.


"Not found" when running on a folder and using buildStatic

Describe the bug
Everything in the bundled file uses / as the path, so it breaks when outputting to a folder, like in storage buckets.
The index.html page loads with a "Not found" text only, no extra requests are made.
window.__unlighthouse_payload is present though
Reproduction
No response
System / Nuxt Info
System:
    OS: Linux 5.15 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
    CPU: (6) x64 AMD Ryzen 7 5800X3D 8-Core Processor
    Memory: 14.30 GB / 15.62 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 18.16.0 - /usr/bin/node
    Yarn: 1.22.19 - /usr/bin/yarn
    npm: 9.5.1 - /usr/bin/npm
  Browsers:
    Chrome: 113.0.5672.92

@harlan-zw I'm already using it, getting the same result

The "Not found" seems to be caused by the vite-plugin-pages catch-all route in packages/client/pages/[...all].vue.
To reproduce visit https://vue-demo.unlighthouse.dev/index.html
As noted above and in #132 there are certain hostings where index.html is accessed directly instead of /. It would be great if unlighthouse would support this.

Thanks, guys, will try and solve it soon. Currently on a different project.
PRs welcome :)

The "Not found" seems to be caused by the vite-plugin-pages catch-all route in packages/client/pages/[...all].vue.
To reproduce visit vue-demo.unlighthouse.dev/index.html
As noted above and in #132 there are certain hostings where index.html is accessed directly instead of /. It would be great if unlighthouse would support this.

This was helpful, thanks again!
The vue-router plugin has been removed which fixes this issue, available in 0.9.0. Let me know if you have any issues with it.


Denom Metadata: Require unique denom strings and delimiter after SI prefix.

Summary
A denom string must uniquely identify a marker. If a denom string ambiguously refers to two or more markers, then we don't actually know the coin in question.
Problem Definition
Current restrictions require a denom unit name or alias to be either the root coin name, or an SI Prefix + the root coin name. This will cause a collision in some cases when new markers are being created. For example, if an existing marker has a root coin name of oocoin, it might have a denom unit for foocoin (being one "femto oocoin"). Then a new coin comes along named "foocoin". We create the marker for it including a denom unit for the root coin name "foocoin". Now, if someone is trying to do a transaction with "1000 foocoin", we don't know which one they're talking about.
Proposal

[ ] Require either a - or . between the SI prefix and root coin name of all denom unit names and aliases. Since the base name and display name must both be denom units, this applies to those as well (for free).
[ ] Update GetRootCoinName to remove any leading - or . (for cases when the root coin name isn't in a denom unit entry).
[ ] None of the denom unit names or aliases can start with a - or ..
[ ] Restrict denom names and aliases to 63 characters long (including any prefix and delimiter).
[ ] Require all denom unit names and aliases to be unique across the chain.

[ ] Create an index for all denom unit names and aliases in the kvstore.

[ ] The key should have this format: <key byte><denom name><delimiter byte><base name>

[ ] The  should just be a single byte that uniquely identifies the index entries.
[ ] The  should be the name as bytes.
[ ] The  can be anything as long as it's not possible in a denom name. Maybe just reuse the  here.
[ ] The  should be the base name as bytes (the same base name used in the kvstore key for the marker).

[ ] The value should just be 0x01.
[ ] Index entries should be made for all denom metadata.Denom strings, and all metadata.Aliases entry strings.
[ ] Create an iterator for the index that takes in a prefix to iterate over, breaks each key into the denom and base name, and calls a function with the denom and base name as parameters.

[ ] During ValidateDenomMetadataExtended check the index for existing entries for each denom name and alias that refer to different denom base names.

[ ] Update DenomMetadata query to use the new index for looking up the denom metadata by denom string.

Reasoning
By requiring a delimiter after the SI prefix, we can ensure that a prefixed denom for an existing coin does not collide with the root coin name of a new coin. E.g. "foocoin" must refer to the root coin name of "foocoin" because there's no delimiter, and "f-oocoin" must be a "femto oocoin". By also not allowing the root coin name to start with a delimiter, there is no room for ambiguity with "f-oocoin".
By indexing all the names an aliases, enforcing uniqueness becomes easy. It also opens up possibilities for more easily finding markers and their associated entries.

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Its important that the prefixes support the basic use cases of nhash, uatom, etc which would mean the base name wouldn’t have a separator from the prefix in these cases...

Its important that the prefixes support the basic use cases of nhash, uatom, etc which would mean the base name wouldn’t have a separator from the prefix in these cases...

We absolutely must have unique denom unit names and aliases though. Without the separator, we get ourselves into a sticky situation when a new coin comes out that has a name that is an SI prefix + another coin name. If the existing coin already has the new coin's name as a denom unit name or alias, then the new coin would not be allowed to have its root coin name as a denom unit. It'd only be allowed to have prefix+name entries. And then users wouldn't know (without doing a lookup) which marker the prefixed existing coin refers to.

Indeed that is the part that makes this complex... a separator isn’t going to be a reasonable easy way out here though... given the metadata is optional I would rather prohibit the extra metadata.

Also... @dwedul-figure  you may want to check the assumptions with the regex and matchstring on denom... while anchors are typically required I am positive that the base denom validation expression prevents denim's from starting with a number which a partial match would allow.

I am positive that the base denom validation expression prevents denim's from starting with a number which a partial match would allow.

#260 contains the updates to enforce anchors in the marker unrestricted regex the same way the SDK does for coin denom.

I'm going to close this as a "Won't Do" at least for now.
After discussions, it sounds like having a delimiter after the SI prefix is not something that's desired. We still might run into issues regarding uniqueness of names, but hopefully not any time soon.


New version: JetBrains.Kotlin.Compiler version 1.3-M2

Pull request has been created with Komac v1.9.1 :rocket:
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/116275&drop=dogfoodAlpha

@wingetbot waivers Add Validation-Executable-Error


Create NPM package

In addition to Bower package i suggest to add other popular repository - NPM.
It would be nice for Node.js users and frontenders who uses Browserify!

+1!

you can install NPM package from Git, temporary use my fork (it has project.json)
npm install yoyurec/blazy

That's great, thank you for doing that.

Thanks. Its added now

:+1:

Is this the current way to install then?
npm install dinbror/blazy --save

This didn't work:
npm install blazy --save

'blazy' is not in the npm registry
You should bug the author to publish it (or use the name yourself!)
NPM: [https://docs.npmjs.com/cli/publish](Publish a package)
Thanks

unfortuatnatly its not registered at npm @dinbror , this trick works: npm install --save git://github.com/dinbror/blazy

unfortuatnatly its not registered at npm

in addition - it has no CommonJS wrapper, only AMD & global (window) ((

@digitalkaoz, @jDeppen: Sorry about that. It is added now:
npm install blazy --save

@yoyurec: Do you need support for commonjs? I only work with commonjs serverside. Do you use it on the client?

Do you need support for commonjs?

it would be good

Do you use it on the client?

yes, with browserify

Thanks! And thank you for this library!
On Sat, Jan 31, 2015 at 2:36 PM dinbror<EMAIL_ADDRESS>wrote:

@digitalkaoz https://github.com/digitalkaoz, @jDeppen
https://github.com/jDeppen: Sorry about that. It is added now:
npm install blazy --save
@yoyurec https://github.com/yoyurec: Do you need support for commonjs?
I only work with commonjs serverside. Do you use it on the client?
—
Reply to this email directly or view it on GitHub
https://github.com/dinbror/blazy/issues/38#issuecomment-72332598.

yes, with browserify

Could you please test version 1.3.1 and see if everything is ok?

doesn't work for me ((
old version, with globals + my config = OK
new version, CommonJS + without config (default .b-lazy class) = OK
new version, CommonJS + my config = not OK :cry:
'use strict';

var blazy = require('blazy');

        var blazyinit = new blazy({
            selector: .mySelector
        });

Looks like options doesn't pass to Blazy (works only your default).

i do wrong init
you didn't complete CommonJS module (wrapper on top changed, but code needs to be changed too)


Added Basic FizzBuzz with Pascal

I just saw there is no basic fizzbuzz solution with pascal available in this repository, so I just create a basic one.

Thnx !!


Add support for forced scan for orders on packing.

What is the motivation for adding/enhancing this feature?

Need to give an option for force scan order items on packing order.
What are the acceptance criteria?

[ ] ...

Can you complete this feature request by yourself?

[ ] YES
[ ] NO

Additional information

Enhancement changes verified and working fine in release v2.5.0. Hence, closing it.


Handle send error

use closure to handle fullchannel error, test checking it
resolves #27

@Totodore that's a solution, but I put one todo, in case of error appears in binary payload send, will fix it when have  time

@Totodore Done. should we mention how many packets remaining inside of the closure?
I think it's mandatory to mention in documentation, that event is successfully delivered if there is no errors, and that resend closure can send some parts

Also I added dependency to easily implement Debug for Errors including closure
Maybe It's better to implement it manually without unnecessary dependencies, isn't it?

@Totodore in the last commit I replaced closure with Retryer struct. What do you think about that?

One thing that it is important to note is that due to the possibility to retry to send binary packet it could lead to binary desynchronization. EngineIo binary packets have to be sent next to the event packet, so if there is a retry for a binary packet error and that between the original attempt and the retry there is another event packet sent it will break the mecanism.

So I will think how to handle it. Looks like Socket should own buffer of failed messages to send them firstly or another Arc copy of retryer


Example Cluster Spec for Distributed YoutTube-8m challenge training

Hi,
Can you please post a  ClusterSpec for distributed training of the models defined in  the YouTube-8m Challenge code?
The code tries to load a cluster spec from TF_CONFIG environment variable. However, I'm not sure what the value for TF_CONFIG should be. I have access to 2 GPUs on one machine and just want to run the model with data-level parallelism.

This question is better asked on  StackOverflow since it is not a  bug or feature request. There is also a larger community that reads questions there. Thanks!


Email aliases?

I seem to remember that you could set email aliases in your profile before (similar to github) on your  account, so that your commits from a different email in your gitconfig would be picked up as you. This doesn't seem to exist in the new profile section.

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

ID: d28a6661-50d4-527e-9727-ab5974da951d
Version Independent ID: fdac329a-b9b4-77d0-916a-dee6d2576379
Content: View and change your user preferences - Azure DevOps & TFS
Content Source: docs/organizations/settings/set-your-preferences.md
Product: devops
GitHub Login: @chcomley
Microsoft Alias: chcomley

Hi @seeafish thanks for letting us know. I am looking into it and will respond back to this issue as soon as possible.

@seeafish We have always had support for a “contact email,” which is where notifications are directed.  We use this email when authoring commits (e.g. web commits, PR merge commits).  So, this leads to situations where users might be creating commits with multiple emails and they appear as coming from the same user.  But we never had a feature where you could add multiple email addresses in your profile to map them to your identity.

I am fairly sure it was there.  This wouldn't work unless VSTS had my private email stored as well. No matter what git tool I use (gitlan, github, bitbucket), the first thing I do is add an email alias so that I can use my standard gitconfig anywhere.
Of course I can't show where in VSTS it was, but in case there's confusion, it's similar to this page on GitHub https://github.com/settings/emails
If you're 100% it didn't exist, I'd be curious to know how can I commit using a different email yet still have my commits show up as me (name and display pic) on VSTS?
Thanks.

Glad you got it figured out. You can go here to see the Azure DevOps Features Timeline: https://docs.microsoft.com/en-us/azure/devops/release-notes/
And you can go here to request a feature: https://developercommunity.visualstudio.com/content/idea/post.html?space=21
Hope this helps, thanks.


Issue415 dns

Codecov Report

Merging #8 into stickler will decrease coverage by 4.58%.
The diff coverage is 83.00%.

@@             Coverage Diff              @@
##           stickler       #8      +/-   ##
============================================
- Coverage     80.36%   75.77%   -4.59%
============================================
  Files            21       22       +1
  Lines          3621     3720      +99
============================================
- Hits           2910     2819      -91
- Misses          711      901     +190

Flag
Coverage Δ

#aux
?

#base
?

#dhcp
72.31% <82.00%> (+0.94%)
:arrow_up:

#many
?

#modules
?

#topo
72.47% <71.66%> (-0.89%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

daq/gcp.py
30.31% <25.00%> (-0.71%)
:arrow_down:

daq/docker_test.py
75.42% <74.07%> (-22.14%)
:arrow_down:

daq/dhcp_monitor.py
89.74% <75.00%> (-10.26%)
:arrow_down:

daq/runner.py
79.78% <78.45%> (-8.46%)
:arrow_down:

daq/host.py
85.39% <83.14%> (-5.95%)
:arrow_down:

daq/ipaddr_test.py
91.80% <91.80%> (ø)

daq/base_module.py
100.00% <100.00%> (ø)

daq/faucet_event_client.py
92.20% <100.00%> (+0.05%)
:arrow_up:

daq/gateway.py
88.48% <100.00%> (-6.09%)
:arrow_down:

daq/network.py
92.30% <100.00%> (-4.49%)
:arrow_down:

... and 16 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bf7840a...f08737a. Read the comment docs.


.NET RecognizeNumberRange return wrong closing character

Describe the bug
In .NET RecognizeNumberRange function return the correct value but the closing character is wrong.
Example : between 13 and 55  should return as (13,55) or [13,55] but the value return like [13,55)
To Reproduce
Steps to reproduce the behavior:

crete a object for NumberRecognizer and call the RecognizeNumberRange function
function return the value with the wrong closing character

Expected behavior
Example : between 13 and 55  should return as (13,55) or [13,55]
Sample input/output
Platform (please complete the following information):

Platform:  .NET
Environment:Windows 10
Version of package [e.g. v<IP_ADDRESS>] - :

Hi @rvinothrajendran,
this is by design. All ranges in Recognizers text are inclusive of the start and exclusive of the end (unless marked in response as otherwise).
I'll close this for now, but fell free to comment further if you want to discuss alternatives or specific needs.


Is there any way to turn off dimming?

Description
Describe your issue here.
What type of issue is this? (place an x in one of the [ ])

[ ] bug
[ ] enhancement (feature request)
[x] question
[ ] documentation related
[ ] testing related
[ ] discussion

Requirements (place an x in each of the [ ])

[ ] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've searched for any related issues and avoided creating a duplicate issue.

Is there any way to turn off dimming? I don't want the presenter to be dimmed.

Yup, just set panModalBackgroundColor to .clear in your implementation of the PanModalPresentable protocol ⬇
    var panModalBackgroundColor: UIColor { .clear }

@jordanpichler  Thanks!


Adding this-escape for MaterializedStoreFactory implementors

Noticed the latest https://github.com/apache/kafka/pull/14741 failed compileJava on JDK 21 due to =>
> Task :streams:compileJava

/home/jenkins/jenkins-agent/workspace/Kafka_kafka-pr_PR-14741/streams/src/main/java/org/apache/kafka/streams/kstream/internals/WindowStoreMaterializer.java:46: warning: [this-escape] possible 'this' escape before subclass is fully initialized

        retentionPeriod = retentionPeriod();

                                         ^

error: warnings found and -Werror specified

This seems to be happening because this-escape is a new linter added in JDK 21, which warns about the constructor calling other methods. This PR is an attempt to check if this suppression helps in getting around this issue.

Thanks for looking into this but I just merged https://github.com/apache/kafka/pull/14740 to fix it.

Yes, I realised it later on :D


X-Debug header 'log-headers' should be documented in admin guide.

Documentation for 'log-headers' should be added to https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/xdebug.en.html .

Fixed by https://github.com/apache/trafficserver/commit/f1068d18733ae1551321d395a5bb591486d5abbd


Node bsc buy takes 10s so it's easy to lose money. I want it to complete the purchase in about 2-3 seconds

Minimum transaction time given in  bsc chain is 5 to 10 seconds can we reduce it. Is it possible

I bought within 3 seconds of notification today with 8 gwei gas price. Adjust your gas settings I noticed if gas price is too high it will take longer.


S3存储文件命名及文件夹问题

Describe the bug

配置好阿里云OSS存储之后，截图在编辑栏粘贴，图片上传
由于上传的图片名字 “image.png” 没有重命名成别的名字上传到OSS中，导致OSS中存储的文件名始终为“image.png”，实际情况就是新上传的图片将旧图片替换了
建议：上传时创建一个文件夹，如“memos”，然后上传的文件放在文件夹内（当前是放在oss的根目录下）；然后图片可以按“时间戳_随机数” 进行重命名，避免文件重名覆盖的情况

Steps to reproduce

直接截图在输入框上传，然后保存
再次截图在输入框上传，然后保存
刷新网页，发现第一次上传的图片被覆盖；查看oss的文件列表，只有最新的图片文件

Screenshots or additional context

Suggestion: Rename file before uploading, for example {year}/{month}/{md5}.{extName}
Besides, I personally suggest adding an option to compress file/convert to webp format before uploading

imageflow or https://wsrv.nl/ may fit for you to doing image convert
And we will add new feature to specific uploaded file name format

imageflow or https://wsrv.nl/ may fit for you to doing image convert And we will add new feature to specific uploaded file name format

The point is to compress images (direct img compress or webp format compress) and thus reduce bucket size + faster loading time, not about a specific format, but this is a good to have though.

I have the same issue. Renaming files automatically before uploading them seems to be a good workaround.

Issue is not in English. It has been translated automatically.

Title: S3 storage file naming and folder problems

测试

刚刚升级到0.11.1，发现这个问题没修复？
这不是普通bug，属于功能无法使用的bug，期待官方早点修复下。

I have the same problem and hope it can be resolved soon.


This reproduces a bug in AVA (maybe?). Just run $ npm t and you'll …

…get:
(node) warning: possible EventEmitter memory leak detected. 11 test listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at TestCollection.addListener (events.js:239:17)
    at Runner.run (/Users/kdodds/Developer/eslint-find-new-rules/node_modules/ava/lib/runner.js:127:13)
    at process.<anonymous> (/Users/kdodds/Developer/eslint-find-new-rules/node_modules/ava/index.js:90:10)
    at emitOne (events.js:77:13)
    at process.emit (events.js:169:7)
    at process.<anonymous> (/Users/kdodds/Developer/eslint-find-new-rules/node_modules/ava/lib/test-worker.js:124:10)
    at emitTwo (events.js:87:13)
    at process.emit (events.js:172:7)
    at handleMessage (internal/child_process.js:689:10)
    at Pipe.channel.onread (internal/child_process.js:440:11)

According to the hint to use proxyquireto mock fs, replacing the mock-fs setup with the following seems to solve the issue:
npm i -S proxyquire

import proxyquire from 'proxyquire'
import test from 'ava'

const findNewRules = proxyquire('./index', {
  fs: {
    readdirSync: () => ['foo-rule.js', 'bar-rule.js', 'baz-thing.js'],
  },
})

(Of course, findNewRules could also be assigned using test.before.)

Cool - this solves it even easier than I was thinking.
I was actually pointing to the mock.fs(..) method of the mock-fs module. It creates a fs clone without clobbering the native one.
Just an FYI - mount-fs looks like a way smarter way to use mock-fs. Use the mock.fs(..) method to create a clone, and mount it in a specific directory using  mount-fs.


~765M memory footprint without extensions...

VSCode Version: 1.18.0-insider
OS Version: Ubuntu 17.04

Steps to Reproduce:

Open VSC (vsc --disable-extensions) with an existing project. (One I tested on has about 423 local files and 19K in node_modules.)
Open System Monitor and gasp in horror.

Reproduces without extensions: Yes
I know, I know...this is web technology, but...I've developed full-fledged operating systems with complex UIs (Symbian) that used a fraction this amount RAM! A little perspective: Ubuntu Linux with Plasma (Desktop) uses about 1G.
This is, after all, an IDE. Is there any plan to tame this beast?

vscode is realy lightweight in install size but when it comes to ram it end up consuming more than Visual Studio the full IDE

I haven't noticed VSCode using too much ram. For reference this is my system currently:

Still happening?

Yes (latest insiders version)

@Panoplos can you find out which command line is the highest memory process in that list?

According to this:

Process is:
panoplos    7093  0.9  3.6 1553300 589148 ?      Sl   13:01   4:18 /usr/share/code-insiders/code-insiders /usr/share/code-insiders/resources/app/extensions/typescript/out/utils/electronForkStart.js /usr/share/code-insiders/resources/app/extensions/node_modules/typescript/lib/tsserver.js --useInferredProjectPerProjectRoot --enableTelemetry --cancellationPipeName /tmp/vscode-tscancellat...

As I am not even using TS, is there a way to disable it?

@mjbvz welcome

@Panoplos  TypeScript powers both our JS and TS language support.
If you are still seeing this issue, try setting up some jsconfig includes/excludes patterns to make sure only the JS files you want are being loaded. Here's a standard jsconfig the excludes all js files in node_modules
{
    "compilerOptions": {
        "target": "ES6"
    },
    "exclude": [
        "node_modules",
        "**/node_modules/*"
    ]
}

Closing as we cannot investigate this further without additional info


Scrollbar does not end properly on the bottom part of the pages

ISSUE: Whenever I scroll to the bottom most part of the page, the media bar is blocking the bottom portion and does not let me see through.
IMAGE:

Yeah, this is not a problem until it really is a problem.
The mobile app has the same floating media bar and it avoids this issue by adding empty space at the bottom of pages. Perhaps the same can be done in bloom to avoid this issue.

@stpnwf thanx
lets see what can we do

Fixed in latest version


Is there a way to get it works on mobile?

Hi thank you for your work.
I am trying to use tether for a fixed div in my website. it works great but when I resize the window, this div is still fixed. I tried to remove all the classes via js in case of resizing.. but it keeps a different position because it now has a different position in the html code, it's at the end of the body. Is there a way to fix it? Am i totally wrong?
Any help would be really appreciate!
Thanks again

I am also wondering how will we manipulate it on smaller screens.

Closing due to inactivity. Please feel free to reopen if you want to continue working on this issue!


xOrDefault

I love how your API is turning out.
I am still a bit concerned about making assumptions in your LinqIterableBase about what the defaults should be.   In respect to selecting 'nodes', null is obviously a valid default, but you (or I) might be better served providing an .xOrNull() method to be more explicit.
// TypeScript
textNodes.select(parseFloat).firstOrDefault() // if textNodes is empty, the value returned here is null.

// C#
textNodes.Select(double.Parse).FirstOrDefault() // if textNodes is empty, the value returned here is 0.

As I pointed out before, when calling an .xOrDefault(), if for some reason T is of type number you won't get 0 as the default as you would in C#.  And if you were attempting to filter by type: typeof null == 'object' where typeof undefined == 'undefined'.  So the behavior differs even though you are conforming to the .NET API.
Where I see having null as an acceptable default is whenever the expected type should be an object like a node.  It's just difficult to forsee how things might get weird if some amount of transformation is done by the consumer.
I'd also point to the weirdness in JS around 0 and null.  Really strange things can happen that simply won't happen in C#.
https://www.tutorialspoint.com/what-is-the-relation-between-null-and-0-in-javascript
https://blog.campvanilla.com/javascript-the-curious-case-of-null-0-7b131644e274?gi=bc5bbbc977f4
null > 0 || null == 0; // == false
undefined > 0 || undefined == 0; // == false
undefined >= 0 // == false
null >= 0; // == true WHAT!?

I think the important thing to keep in mind, is that in C#, the word "default" has a special meaning and expectation that simply can't apply to JavaScript.

Latest update includes xOrNull methods and eliminates hard T restrictions for xOrDefault methods.
https://github.com/tsdotnet/linq/releases/tag/v1.4.0

Hi @electricessence, I did think about this very carefully. However, I knowingly and willingly decided to accept the slight difference in behavior between C# and TypeScript/JavaScript. Here are some considerations:

In LINQ to XML, you almost always deal with reference types, where the default value is null and xOrDefault() is therefore expected to return null. "Almost always" in this case means that you had to remind me that xOrDefault() returns 0 for an empty IEnumerable<int>, for example. I had (almost completely) forgotten that it did that, likely because I almost never use such methods with value types ... mind you in the context of processing XML (such as Office Open XML), using either:

the strongly-typed classes (e.g., Paragraph, Run) provided by the Open XML SDK or
LINQ to XML (e.g., using the XElement class with XName instances corresponding to Paragraph or Run).

Forcing developers to use a different API just because of a difference between the return values of the C# vs. TypeScript counterparts in rare cases (effectively just the number type) did not feel right. Unless you are using .NET 6, to provide an explicit default value in C#, you would use the .DefaultIfEmpty() extension method, the counterpart of which is also offered in my API. Therefore, in those rare cases in which you deal with sequences of numbers (in LINQ to XML) and expect the return value of xOrDefault() to be 0 or some other numeric value (but not null), developers can use the defaultIfEmpty() method.
.NET 6 added further overloads to the xOrDefault() methods, including one that lets you provide just a default value and another one that lets you provide a predicate and a default value, in that order. I will consider adding those in a future release.
There are other LINQ-related implementations out there (see mihaifm/linq, for example) that also return either null or undefined. For the xOrDefault() methods, mihaifm/linq offers an optional default value as a second parameter (after the predicate): firstOrDefault(predicate?: (element: T, index: number) => boolean, defaultValue?: T): T | undefined;.

Structurally, my API is in sync with .NET 5 and earlier. The APIs offered by .NET 6 can be added later. The minor behavioral difference regarding the default value for essentially just the number type is acceptable in the LINQ to XML context.

Latest update includes xOrNull methods and eliminates hard T restrictions for xOrDefault methods. https://github.com/tsdotnet/linq/releases/tag/v1.4.0

I've not tested this, but would it be possible to do the following?
const emptyNumericSequence = linqExtended<number>([]);
const value = emptyNumericSequence.firstOrDefault('foo');

Since 'foo' is a string, the type of value would be number | string, matching your signature:
firstOrDefault<TDefault>(defaultValue: TDefault, predicate?: PredicateWithIndex<T>): T | TDefault;

If so, this would be weird. However, I have not seen any constraints that would prevent me from passing arbitrary default values.

I'd also point to the weirdness in JS around 0 and null. Really strange things can happen that simply won't happen in C#. https://www.tutorialspoint.com/what-is-the-relation-between-null-and-0-in-javascript https://blog.campvanilla.com/javascript-the-curious-case-of-null-0-7b131644e274?gi=bc5bbbc977f4
null > 0 || null == 0; // == false
undefined > 0 || undefined == 0; // == false
undefined >= 0 // == false
null >= 0; // == true WHAT!?

I never said JS isn't weird, which is why I never developed in JS but only TypeScript. In TypeScript, some of your above expressions would not even compile.
To check, I created a quick unit test:
test('weird stuff', () => {
  expect(null === true).toBe(false);
  expect(null == false).toBe(false);
  expect(null! > 0).toBe(false);
  expect(null! == 0).toBe(false);
  expect(null! >= 0).toBe(true);

  expect(undefined === true).toBe(false);
  expect(undefined == false).toBe(false);
  expect(undefined! > 0).toBe(false);
  expect(undefined == 0).toBe(false);
  expect(undefined! >= 0).toBe(false);
});

The fact that expect(null! >= 0).toBe(true); passes explains my hesitation to use JS. At least in TypeScript, null >= 0 (without the non-null assertion operator !) does not compile. Obviously, null! >= 0 may produce nonsense.
One thing that is consistent, though, is that undefined, null, 0, and false (and '') are all falsy. You could make use of that fact, for example.

https://github.com/OpenXmlDev/linq-to-xml/issues/2#issuecomment-1030703792
In respect to this.  Holding on too tightly to parity with .NET can bite you in the end.  Different languages, different environments, different norms, different coding standards.   Just my take as I went from conforming tightly to .NET to looking for ways to be more conforming to JS uses.

Side note: I'm totally okay with whatever decision you make.  I'm just providing an alternative view and looking for insight myself.

https://github.com/OpenXmlDev/linq-to-xml/issues/2#issuecomment-1030705164
'foo' is allowed.  This of course wouldn't be possible in C# with just T, but the point of TS is not to create an API that prevents you from doing things, but to provide type guidance (or type flow) for your code.  Without any typing, a JavaScript consumer (latest version or otherwise) could have done exactly that and it would have worked.
Since that is factually true for JavaScript, it is more important to ensure that the type definition correctly reflects it's behavior.
Consider:
const emptyNumericSequence = linqExtended<number>([]);
const value = emptyNumericSequence.firstOrDefault(null); // number | null

^ This may actually be desired behavior.  But with the previous typing, this would not be possible unless T of the numeric sequence was typed as number | null.

I never said JS isn't weird, which is why I never developed in JS but only TypeScript. In TypeScript, some of your above expressions would not even compile.

Depends on your tsconfig, but yes, you can make it compile and proves even more so how troublesome these kinds of evaluations can be:
https://www.typescriptlang.org/play/?ssl=7&ssc=29&pln=1&pc=1#code/MYewdgzgLgBAcgVQDJJgLhgQzATxgXhjAFcAbUgbgChRJYA1AeQEkARABnS1wJmLAAmAUwBmASzBCB1KohQwAfDE4AfFfGSp8hdhRgB6fQUIjMpCEKpM2nJavXWOx5XsPPT5y49s6DR7TAeFrKaijqu-oRQAE7EQjAA6gASAIIAKgCEAPxAA
const NULL : any = null;
const VOID0 : any = undefined;

NULL > 0 || NULL == 0; // == false
VOID0 > 0 || VOID0 == 0; // == false
VOID0 >= 0 // == false
NULL >= 0; // == true WHAT!?

One thing that is consistent, though, is that undefined, null, 0, and false (and '') are all falsy. You could make use of that fact, for example.

Yes.  In some cases, that can make things a bit easier.  But people need to know what they are doing and what side-effects it can cause.

The fact that expect(null! >= 0).toBe(true); passes explains my hesitation to use JS. At least in TypeScript, null >= 0 (without the non-null assertion operator !) does not compile. Obviously, null! >= 0 may produce nonsense.

TS is awesome.  But, ultimately it IS JavaScript.  It's a superset.  You can't separate JS from TS, but you can separate TS from JS.
I would hate to write in pure JS again, but if you're gonna be in a JS world (which TS is) you have to embrace it.  For example, conforming to standards like camelCasing instead of TitleCasing.  JavaScript devs wouldn't want to use a JS lib that used TitleCasing because it would get weird.
What you might not be getting with null >= 0 is that when negative side-effects occur, it won't be because someone wrote that explicitly.  It will occur like this:
// assume that numberSequence has a null value in it.  And that the following is your LinqIterable.
numberSequence.firstOrDefault(n => n >= 0);

Sure, this isn't likely to happen but I'm just pointing out that because JS has these strange effects, including the horrific introduction of null and undefined, (as I said before) holding on too tightly to parity may bite you in the future.

Hi @electricessence, this discussion inspired me to make a change to the API, which is already published as v0.9.0 on npmjs.com.
Both the README in this repo and the main page on npmjs.com talk about the language-specific differences between C# and TypeScript/JavaScript and in particular the differences between the default values used for non-nullable value types.
Based on the argumentation (which I am not repeating here), the API now looks like this for firstOrDefault(), lastOrDefault(), and singleOrDefault():
xOrDefault(): T | undefined;
xOrDefault(predicate: PredicateWithIndex<T>): T | undefined;
xOrDefault(defaultValue: T): T;
xOrDefault(predicate: PredicateWithIndex<T>, defaultValue: T): T;

The essential parts of the change are:

the additional overloads taking a default value and
the fact that the API no longer returns null but undefined.

The above API is 100% consistent with the corresponding API in .NET 6 (using T instead of TSource below):
public static T? FirstOrDefault<T>(this IEnumerable<T> source);
public static T? FirstOrDefault<T>(this IEnumerable<T> source, Func<T, bool> predicate);
public static T  FirstOrDefault<T>(this IEnumerable<T> source, T defaultValue);
public static T  FirstOrDefault<T>(this IEnumerable<T> source, Func<T, bool> predicate, T defaultValue);

You could still construct "interesting" edge cases such as sequences of "predicates" of type PredicateWithIndex<T> where you will not be able to distinguish between an actual predicate and a default value. However, those cases are really irrelevant for LINQ to XML, where you never deal with sequences of functions. Therefore, at run-time, the implementation treats any function as a predicate.
The next key question is whether I should consistently return undefined instead of null in other APIs as well. Looking at several arguments about undefined vs. null, I felt that null was the better return value for cases where you want to explicitly signal the non-existence or absence of a value as opposed to it not being initialized. What are your thoughts?

xOrDefault(): T | undefined;
xOrDefault(predicate: PredicateWithIndex<T>): T | undefined;
xOrDefault(defaultValue: T): T;
xOrDefault(predicate: PredicateWithIndex<T>, defaultValue: T): T;

There is a reason that I explained before why I DO NOT DO THIS overloading.
You will be unable to differentiate between a default value of a delegate.
TS overloads are fake.  They don't do anything other than define the potential type flow.
Here's where it will break (if this is even a possible use case with your lib):
delegateSequence = linq<Func<int>>(delegates);
delegate = delegateSequence.firstOrDefault(e=> e!=0 /* handle default case? */);

What do you see above that could go wrong?
Well the consumer might be trying to provide a default delegate, but instead end up with a where clause that is validating e which will never return any results even if there are some and only return the default delegate provided.
Hence why this is not a possible overload combination in .NET LINQ, but part of that is that there no need to because C# actually returns the default type as expected.

The API choices I've made with tsdotnet/linq have a lot to do with already grinding through these kinds of API conundrums.
Hence why the primary signature of xOrDefault methods is:
singleOrDefault<T, TDefault>(defaultValue?:TDefault, predicate?:PredicateWithIndex<T>)

Because there is no question about what is what here.

You will be unable to differentiate between a default value of a delegate. TS overloads are fake. They don't do anything other than define the potential type flow. Even so, this type of overloading is typically not done with delegates or tasks in .NET as it can create an API that is problematic.
Here's where it will break (if this is even a possible use case with your lib):
delegateSequence = linq<Func<int, bool>>(delegates);
delegate = delegateSequence.firstOrDefault(e=> e!=0 /* handle default case? */);

Since you made that point earlier, I am fully aware of this, which is why I added the following concluding remark in my comment above

One could still construct "interesting" edge cases such as sequences of "predicates" of type PredicateWithIndex where you will not be able to distinguish between an actual predicate and a default value. However, those cases are really irrelevant for LINQ to XML, where you never deal with sequences of functions. Therefore, at run-time, the implementation treats any function as a predicate.

In your response, you have done exactly that again, i.e., you have constructed an "interesting" edge case. However, your parenthetical is important: "if this is even a possible use case with your lib". To be very clear: That use case is of no practical relevance whatsoever. In LINQ to XML, we are not looking at sequences of functions. I would also guess that in LINQ (i.e., in a wider range of use cases), sequences of functions are an edge case. In the extreme case, we are talking about a case that is of purely theoretical interest.
Thus, weighing the purely theoretical nature of the above use case (at least for LINQ to XML) against more relevant factors such as consistency with the corresponding .NET APIs, I decided to be consistent with .NET 6. This makes it very easy for developers to consume those APIs.
In case anybody wanted to use sequences of functions, default values can be defined in the following two ways:
const sequence = linqIterable<PredicateWithIndex<number>>([]);
const defaultValue: PredicateWithIndex<number> = () => false;

// First option: use defaultIfEmpty() function.
const element1 = sequence.defaultIfEmpty(defaultValue).firstOrDefault();

// Second option: use firstOrDefault(predicate, defaultValue) overload.
const element2 = sequence.firstOrDefault(() => true, defaultValue);

The first option corresponds to what you would have to do prior to .NET 6. The second option leverages the overload that corresponds to one that was added in .NET 6. In this rare or even non-existent edge case, you would have to pass a predicate () => true that would not normally be required. This is not the best developer experience. However, this is a much better API design compromise than offering an API for the typical case where such API would not be regarded as "natural" by developers.
Let me illustrate that developer experience also with another simple example. Let's look at the ArgumentException class, which you also provide in your @tsdotnet/exceptions package.
In .NET, an ArgumentException instance can be constructed with the following overloads:
public ArgumentException();
public ArgumentException(string? message);
public ArgumentException(string? message, Exception? innerException);
public ArgumentException(string? message, string? paramName);
public ArgumentException(string? message, string? paramName, Exception? innerException);

In your package, an ArgumentException can be constructed with a single constructor:
constructor(paramName: string, message?: string, innerException?: unknown);

While it is possible to provide all parameters that the .NET counterpart supports, the arguments are in a different order, i.e., paramName and message are swapped. This can be a gotcha if you are used to the order of arguments in .NET. Secondly, the API does not allow undefined for paramName, which is an explicit use case in .NET. For example, I wanted to throw exceptions that are similar to what is thrown in LINQ to XML in .NET. Guess what, you will often enough come across something
like new ArgumentException(someMessage). While you can write something like throw new ArgumentException('', someMessage) in your API, it does not feel natural.

@electricessence, I just thought about one more thing.
Using singleOrDefault() as an example, the set of overloads that is most similar to their .NET 6 counterparts is this:
singleOrDefault(): T | undefined;
singleOrDefault(predicate: PredicateWithIndex<T>): T | undefined;
singleOrDefault(defaultValue: T): T;
singleOrDefault(predicate: PredicateWithIndex<T>, defaultValue: T): T;

The first two overloads existed prior to .NET 6 while the last two were added in .NET 6.
If sequences of functions were a thing, removing the singleOrDefault(defaultValue: T): T overload would remove any ambiguity as well. The set of overloads would then be this:
singleOrDefault(): T | undefined;
singleOrDefault(predicate: PredicateWithIndex<T>): T | undefined;
singleOrDefault(predicate: PredicateWithIndex<T>, defaultValue: T): T;

This is as unambiguous as your API while being consistent with the .NET API. Would you agree?

So here's the last couple things to consider:
If you write an overload that has a T as a first param, and another overload as PredicateWithIndex<T> as a first param.  Then for every call, you have do a type check in JS to see if what is being passed is a Function.
But the in lies the trouble.  Unless you can guarantee that the underlying iterable does not contain functions as its content, then you'll never be sure if you've misinterpreted what the consumer wanted.  Again, because ultimately, this is JS and not C#.
To your point above about ArgumentException.  Because this is a JavaScript environment, I avoid at all costs implementing special overload logic as it tends to make the code more likely to have bugs and testing is more complicated and troublesome.  So instead of fighting with parity in .NET, I normalize the parameters and stick with them.  If necessary, creating different methods solves these overload problems.  And in rare cases, where it clearly has a high value and if a type check/switch can ensure a proper code path, then I might implement special overloading.
I understand the desire to keep with parity, but as I mentioned, I lost that battle a long time ago, and found a balance that favored JS.  If you follow my API and make xOrDefault always have a defaultValue (it can't be omitted) as its first param, then there's no question about what it does.  Again, 'default' is a special word.  That has questionable meaning in JS.  So for me, I realized that it made more sense to be sure the consumer also understands what they need to do when using that method.  It provides more functionality, while being sure it does what it says.  Meanwhile, really think what you're trying to emulate is the xOrNull or xOrUndefined methods.  Which are totally fine because there is no question about the result and no need to provide a value.
I kind of like the new xOrNull methods because they're more brief.

Just gotta say:  I'm 100% supportive of your decisions.  I appreciate that you are clearly informed and like me have  a desire to figure out what's best.  I'm confident from our discussions that you get these challenges and for me, I see that some of these concepts may be trivial to your API.  In the end, I like to be sure you're going forward knowing what challenges you might face.

singleOrDefault(): T | undefined;
singleOrDefault(predicate: PredicateWithIndex<T>): T | undefined;
singleOrDefault(predicate: PredicateWithIndex<T>, defaultValue: T): T;

But what if i want to provide a default value and no predicate?
Again, it's the Default in xOrDefault that you're wrestling with.
As it has been true in the past for JS.  JS never had type flow overloads.   Sure, runtime overloading is possible, but causes you to write more code.

To my earlier point, consider this for C#:
Why does everything have a MethodName<T>(T value) and subsequent MethodNameAsync<T>(Task<T> task) version?
Why not just MethodName<T>(Task<T> value)?

Getting late here.  But I'm excited for how this project is going.

@electricessence, thanks for your latest answers.

To your point above about ArgumentException. Because this is a JavaScript environment, I avoid at all costs implementing special overload logic as it tends to make the code more likely to have bugs and testing is more complicated and troublesome.

My point is not about the single constructor or the absence of overloads. My point is about the "wrong" order of the arguments compared to the .NET counterpart. I believe you could have used the same order as in .NET, which would have been a good thing for a package scoped @tsdotnet. Developers will be surprised by this different order.

Again, it's the Default in xOrDefault that you're wrestling with.

I can confirm that I am not wrestling with the "Default". If you looked a the README, where I describe the language-specific differences regarding default values, I said the following:

On an abstract level, the C# and TypeScript counterparts behave in the same way. For empty sequences, they both return the respective default values. Let that sink in for a moment.
On a concrete level, however, the language-specific difference between the default values for non-nullable value types in C# (e.g., int, bool) and the corresponding types in TypeScript (e.g., number, boolean) is that:

in C#, the default values are 0 and false, respectively; and
in TypeScript, the default value is undefined in all cases.

I am embracing the fact that the default value in TypeScript is undefined in all cases. I even think that this behavior has advantages. Lastly, the behavior is well-documented in the API documentation. The only remark that I will likely add in a next release is that the overload taking just a default value should not be used for the edge case of sequences of functions.

Why does everything have a MethodName<T>(T value) and subsequent MethodNameAsync<T>(Task<T> task) version?
Why not just MethodName<T>(Task<T> value)?

I think what you mean are methods returning a T in the synchronous case and a Task<T> in the asynchronous case. Right? Firstly, the Async postfix is a naming convention that is just "helpful" because it signals that you'd have to await the results, for example. Secondly, consider the following synchronous method:
T MethodName(string value);

You cannot have an overload with the same name that only differs in its return type. Therefore, the corresponding asynchronous method looks like this by convention (ignoring further typical overloads adding a CancellationToken, for example):
Task<T> MethodNameAsync(string value);

You could use any other method name that does not clash with MethodName. Using Async as a postfix in such cases just makes a lot of sense.

My point is not about the single constructor or the absence of overloads. My point is about the "wrong" order of the arguments compared to the .NET counterpart. I believe you could have used the same order as in .NET, which would have been a good thing for a package scoped @tsdotnet. Developers will be surprised by this different order.

Well, that's a very interesting point indeed.  In .NET ArgumentException deviates from its sub-classes in that typically you provide the paramName first.  IMO, for years, I've always thought this was a very confusing choice as any ArgumentExeception you typically want to know which one.  I would quite often get confused and have these reversed as they are both strings.  So for consistency, I made tsdotnet's version of ArgumentException behave like it's sub classes. ArgumentNullException for example.

I am embracing the fact that the default value in TypeScript is undefined in all cases.

I think you're doing a great job and as the alternative to providing a defaultValue is that the consumer can easily do the following:
numericSequence.firstOrDefault() ?? 0
// or
numericSequence.firstOrDefault() || 0


feat: devnet 3 with evm + fix wss for lower envs

Adds devnet 3 with evm + fixes wss for lower envs

@JeremyParish69 addressed


#60: Change certain fields to integers

#60

Codecov Report

Merging #61 (2e19218) into main (e13792d) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #61   +/-   ##
=======================================
  Coverage   94.06%   94.06%
=======================================
  Files           8        8
  Lines         236      236
=======================================
  Hits          222      222
  Misses         10       10
  Partials        4        4

Impacted Files
Coverage Δ

formatter/formatter_csv.go
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e13792d...2e19218. Read the comment docs.


Sanitycheck improvements

sanitycheck: Fail test if the process returns != 0:
If the test process returns an error (return code != 0), it should be considered a failure, even if the handler considers the test passed.
One error was hidden due to this: #12043
Also without this, when running with valgrind, all valgrind errors are missed.
valgrind: Add error suppression file for POSIX arch
sanitycheck: Use suppression file for valgrind and dump valgrind's log into its own file so it can be inspected afterwards.

Blocked by #12043 (unless you want to risk that failure appearing in CI)

@andrewboie : If you like the changes, feel free to merge (I do not have write rights)

@myrdyr please review


Never finishes initizalization on UC Browser

It stays on the "Detecting Progressive Web App features…" screen forever.
I guess it is due to unhandled exception caused by missing relList support. But I have no idea how to debug it properly.

I reckon this is suboptimal, but as the tool is targeted at Web browsers and Web Views that have at least basic PWA support, I don't think supporting browsers that don't even know fat arrow functions yet makes a lot of sense.
FWIW, I have installed the latest version of UC Browser (v<IP_ADDRESS>8) on my phone, but it doesn't load a single page and there is no way to turn off data saving mode (which I suspect is causing the issue). I'm inclined to drop the mic here.


Mast: Watch (?-i:W6i3edNvsrU)(?#YouTube)

Mast requests the watch of the watch_keyword (?-i:W6i3edNvsrU)(?#YouTube). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

(?-i:W6i3edNvsrU)(?#YouTube) has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ