Make docs fails after 130

The following error is reported after attempting to make docs - due to permission errors.
ubuntu@ubuntu:~/DroneCore$ make docs
(cd /usr/local/include/dronecore \
        && mkdir -p docs \
        && doxygen /home/ubuntu/DroneCore/.doxygen \
        && /home/ubuntu/DroneCore/generate_markdown_from_doxygen_xml.py docs docs)
mkdir: cannot create directory ‘docs’: Permission denied
Makefile:74: recipe for target 'docs' failed
make: [docs] Error 1 (ignored)
ubuntu@ubuntu:~/DroneCore$

If you do sudo it works, but the docs are created under /usr/local/include/dronecore/docs/markdown (which I suggest is not the best way).
Probably our previous behaviour would be good here. As part of docs build create /install/include/ etc etc. In any case, should not force sudo to build docs, or build them in such an unlikely location.

@julianoes When you have time, docs build broken.


Add UASZ

add university assane seck de ziguinchor to liste of accept domain for student licence

@thirtsoft I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host zig.sn not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


Re-think wallet utxos with datum/script references

Currently there are two issues I see:

We support paying into wallets with datum via mustPayToPubKey(Address)WithDatum, but no way of spending such utxos manually via mustSpendPubKeyOutput, as it checks there is no datum (possibly from legacy models about Ogmios).
In the presence of such utxos in the users wallet, the balancer may select them. This is an issue for inline datum, as it will make it impossible to construct the ScriptContext for any PlutusV1 script. We should kick into a PlutusV1 compatible selection mode when necessary, only selecting inputs which will make a valid transaction.

This may also be an issue with script references too

no way of spending such utxos manually via mustSpendPubKeyOutput, as it checks there is no datum

Can we just remove the check?

Totally agree

Can we just remove the check?

I think so, that's what I did for my initial testing anyway. We might have to attach the datum for the non-inline case, I'll do some testing

@klntsky Actually, I'm not sure what the expected behaviour should be in general (for plutus v2). Selecting wallet utxos that have datum/scripts attached will destroy that information, this is likely something the users do not want.
I'm thinking we should only allow spending of these 'rich' utxos when they've been explicitly set to do so via mustSpendPubKeyOutput, never by the balancer when balancing.

It's an interesting point. One of the main use cases for attaching a datum to a pubKeyOutPut is to prevent double spending from a validator in which case the user probably has no idea they even have a UTxO with a datum attached or what that means. And as soon as that UTxO enters the wallet the datum becomes useless.
Therefore I think wallet UTxOs with datums should be selectable but perhaps only after all valid UTxOs without a datum have been exhausted. Otherwise a user that's using a protocol that implements the above approach may very soon run into issues of not having any spendable UTxOs and very confusing errors.

One of the main use cases for attaching a datum to a pubKeyOutput is to prevent double spending from a validator

Can you explain this a bit further? I don't understand how that would be implemented
I think the biggest use for 'rich' utxos in the wallet would be as reference inputs (either for the datum or script), at least for testing purposes.

I think I get the idea: validator checks n amount is sent to an address, you could run multiple validators to get the same payment to count towards those validators so you tag the output with something specific to make it only valid for one payment

I think we should continue allowing spending wallet utxos with datum/inline datum/script refs (when possible), it seems there's no set expectations for what to do when they exist in a wallet

As an example:

Say you want to spend 2 inputs from NFT marketplace. To spend each you must pay 100 ADA to some PKH
Without datums you can pay 100 ADA once, and both inputs will pass validation
A common way prevent this is to enforce unique datums (eg. tx ref of spent input) to be attached to payment UTxOs

UTxOs as reference inputs can easily be stored at validators or multi-sig wallets that are for that use case only if the protocol doesn't want them being spent.
At the end of the day you have to think about the end user. Who probably doesn't even know what a datum is.


Provide a way to get list of buffers in diff mode / (re)set diff mode

I am seeing the following error from time to time, although only two diff windows are visible:

E101: More than two buffers in diff mode, don't know which one to use

This might happen when closing a window which had diff mode enabled, and there
appears no way to reset it easily?!
I've seen usage of getbufvar in that context, but the following returns all buffers when in a window with diff set, and is empty otherwise (although another window is in diff mode):
:echo filter(range(1, bufnr('$')), "getbufvar(v:val, '&diff')")

Is there a way to see for which buffers diff is set?
It could certainly be displayed with the E101 error (since it can only be 4 (E96)).
It seems like diffoff! could provide a way to turn it off, but that appears
to handle windows (and their buffers) only:
:diffo[ff]! Switch off diff mode for the current window and in all windows
        in the current tab page where 'diff' is set.  Resetting
        related options only happens in a window that has 'diff' set,
        if the current window does not have 'diff' set then no options
        in it are changed.

2016-04-07 3:24 GMT+03:00 Daniel Hahler<EMAIL_ADDRESS>
I am seeing the following error from time to time, although only two diff
windows are visible:
E101: More than two buffers in diff mode, don't know which one to use
This might happen when closing a window which had diff mode enabled, and
there
appears no way to reset it easily?!
I've seen usage of getbufvar in that context, but the following returns
all buffers when in a window with diff set, and is empty otherwise
(although another window is in diff mode):
:echo filter(range(1, bufnr('$')), "getbufvar(v:val, '&diff')")
Is there a way to see for which buffers diff is set?

&diff is window-local option. Your question has no sense, it may not be
set for any buffer. You may get a list of windows in which this option is
set and transform this into a list of buffers displayed in those windows.
getbufvar() is evaluated in the current window context, with different
buffer context. So, of course, your code does not work; but VimL is rather
permissive so it does not work, but as well does not throw any errors. If
you wrote
:python for buf in vim.buffers: print(buf.number, buf.options['diff'])

you would get KeyError because my python bindings are not that permissive:
you cannot use options attribute of vim.Buffer instance to get option
that is not buffer-local or buffer-local/global.

It could certainly be displayed with the E101 error (since it can only be
4 (E96)).
It seems like diffoff! could provide a way to turn it off, but that
appears
to handle windows (and their buffers) only:
:diffo[ff]! Switch off diff mode for the current window and in all windows
in the current tab page where 'diff' is set.  Resetting
related options only happens in a window that has 'diff' set,
if the current window does not have 'diff' set then no options
in it are changed.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/vim/vim/issues/736
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to<EMAIL_ADDRESS>For more options, visit https://groups.google.com/d/optout.

On Wed, Apr 06, 2016 at 05:24:36PM -0700, Daniel Hahler wrote:

I am seeing the following error from time to time, although only two diff windows are visible:

E101: More than two buffers in diff mode, don't know which one to use

This might happen when closing a window which had diff mode enabled, and there
appears no way to reset it easily?!

I'm convinced there's a bug in vim: sometimes when you switch away/close
a buffer with &diff enabled, vim still thinks there's an active diff for
it.
Internally vim maintains a list of diff-enabled buffers separately from
the buffer/window's own option structures, and these datasets sometimes
somehow get out of sync.  I spent hours trying to track it down with
gdb, but haven't succeeded.
I don't have a recipe for reproducing this -- when this happens, it
always happens unexpectedly in a long editing session when I diff things
and forget do :windo diffoff soon enough.  Luckily it happens rarely.
There's a workaround: you can open a new tab, close the old one, reopen
your windows as you like -- the diff state is reset because every tab
keeps its own diff state.
Regards,
Marius Gedminas
If you are good, you will be assigned all the work.  If you are real
good, you will get out of it.

Internally vim maintains a list of diff-enabled buffers separately from the buffer/window's own option structures, and these datasets sometimes somehow get out of sync.

Yes, that explains the main issue I'm having, and what I'm trying to get at from VimL.
Could the internal list of diff-enabled buffers be exposed, possibly only read-only?

getbufvar() is evaluated in the current window context, with different buffer context.

Thanks for explaining this.
This means that getbufvar(b, '&diff') is the same as just &diff?
E.g. the following does not work as expected:
https://github.com/kopischke/vim-stay/blob/89e5a31fcdfd39774945e61144f0022977f13365/autoload/stay.vim#L27

@blueyed actually, I think it should be getwinvar(<winnr>, '&diff'), as the option is window-local (as is the next one in that function, &previewwindow). I’ll fix that in the next stay release.

@kopischke
But that seems to be impossible given that you only have the bufnr input there.
You could try to find that buffer in open windows (which is not trivial IIRC), but that still means in the end that you would rather like to have an interface to the internal buffer-is-in-diff-mode list.

@blueyed it’s easy for stay as its operation is actually window based, but you are right as to the general usage case. I guess I was just trying to say your issue might be in part caused by the fact that you try to link &diff state to a buffer instead of a window and got sidetracked by the example taken from my plugin. Apologies for taking this OT, and I will leave further discussion to those more familiar with Vim’s diff than I am.

blueyed's question is born to have a workaround for that annoying diff problem. As written in the manual diffoff! runs for "windows" BUT the "buffers" are marked for diff. You can reproduce this like this:
a.txt
aaa
aaa
aaa
aaa
aaa
aaa
aaa
aaa
aaa

b.txt
aaa
aaa
aaa
bbb
bbb
bbb
aaa
aaa
aaa

c.txt
aaa
aaa
aaa
aaa
aaa
aaa
ccc
ccc
ccc

Open a new vim
:set hidden "dont delete buffers when closing windows
:%bd "kill all buffers
:e a.txt "open a.txt
:vert diffsplit b.txt "youll see the inner three lines as diff
:close "window closed, b.txt buffer still exists, diff in a.txt still shown
:diffoff! "window with a.txt no diff mode
:vert diffsplit c.txt "diff a.txt with c.txt --> you will see that a.txt + c.txt AND b.txt are diffed

So there is a flag on the hidden buffer for b, you can not get rid off with :diffoff!.
I think this is a BUG and we need a fix instead of a workaround.

Thanks!


Fix datatype handling for plpgsql function parameters

Currently all plpgql function parameters are returned as UNKNOWN. This patch changes function parameters to return actual type names used in the function definition.
Fixes #126

@svenklemm Thanks for the contribution - @msepga will take a look at this.

@msepga any update?

@lfittl looks like @msepga is MIA

@lfittl looks like @msepga is MIA

Just got a lot on our plate, but I'll make sure we can get this reviewed in the next days. Thanks for your patience!


[Getting Started with Sass] Watch fails in WSL

Hi guys, really impressed with your cli and tools for email authoring - I haven't used Ink for a year or so and you've improved it so much!
How can we reproduce this bug?
I have the dubious privilege of being a windows user (at work). I typically use WSL ("bash for windows") but have encountered the following error when running foundation watch on a new project:
$ foundation watch                                        ruby-2.3.3 python-2.7.6

><EMAIL_ADDRESS>start /mnt/c/Users/Developer/Sites/it-newsletter-template/it-newsletter-3
> gulp

[14:42:54] Requiring external module babel-register
/mnt/c/Users/Developer/Sites/it-newsletter-template/it-newsletter-3/node_modules/browser-sync/node_modules/dev-ip/lib/dev-ip.js:21
    var networkInterfaces = require("os").networkInterfaces();
                                          ^

Error: EINVAL: invalid argument, uv_interface_addresses
    at Error (native)
    at getIp (/mnt/c/Users/Developer/Sites/it-newsletter-template/it-newsletter-3/node_modules/browser-sync/node_modules/dev-ip/lib/dev-ip.js:21:43)
    at Object.<anonymous> (/mnt/c/Users/Developer/Sites/it-newsletter-template/it-newsletter-3/node_modules/browser-sync/lib/utils.js:4:38)
    at Module._compile (module.js:556:32)
    at Module._extensions..js (module.js:565:10)
    at Object.require.extensions.(anonymous function) [as .js] (/mnt/c/Users/Developer/Sites/it-newsletter-template/it-newsletter-3/node_modules/babel-register/lib/node.js:152:7)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Module.require (module.js:483:17)
Error<EMAIL_ADDRESS>start: `gulp`
Exit status 1
    at EventEmitter.<anonymous> (/usr/local/lib/node_modules/foundation-cli/node_modules/npm/lib/utils/lifecycle.js:217:16)
    at emitTwo (events.js:106:13)
    at EventEmitter.emit (events.js:191:7)
    at ChildProcess.<anonymous> (/usr/local/lib/node_modules/foundation-cli/node_modules/npm/lib/utils/spawn.js:24:14)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:877:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)

It looks to me from the interface that it's looking for some sockets that aren't supported in WSL yet. Not sure actually if this should be reported to you or the WSL team. Please close if that's the case.
I've switched to Power Shell and everything's working as expected, just thought Id mention it to you.
Regards
Ben

Never seen this. Might be a general issue with Node.js on Windows.

Closing as this is not caused by us.

Oh wow yeah sure 👍


chore: revised documentation to include dev-db info

Description
Fixes #

What work was done?
Documentation was updated to give information on developer database, new API route created for modifying tasks re: front end developer mode
Why was this work done?
This was done to onboard incoming developers and inform them of how to involve the development DB in their workflow, and to allow developers to modify the status of a task's hasRead hasDrawn & hasWritten values in one API call.
What feature / user story is it for?
"As a developer, I want to be able to use a development / staging server."
"As a developer, I want to be able to select Saturday/Sunday/Monday and modify the relevant state"
Any relevant links or images / screenshots

Type of change
Please delete options that are not relevant.

Updating documentation RE a new feature

Change Status

[x] Complete, but not tested (may need new tests)

Has This Been Tested

[x] No

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] My code has been reviewed by at least one peer
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] There are no merge conflicts

Nice work Sam! The documentation is really clear for future developers understanding.


2021-04 - root

See readme for contributing guidelines.

Why is Xavier being pronounced like that? Isn't it more like `[.0Xg.1ze.0vy.0R]? @amirsol81

@ultrasound1372 It's an attempt to mimic its Spanish counterpart, Javier. But you are right, I re-checked it with several sources and it's better to restore the pronunciation to its original. It will be done in the next commit.

@ultrasound1372 @thunderdrop Any chance of revisiting the vexing "Louis" issue and reverting to its original s-sounding pronunciation? I was just reading the following page and found the non-s pronunciation rather odd: https://www.npr.org/2021/04/13/986731926/henry-louis-gates-jr-on-the-black-church-and-his-own-bargain-with-jesus
Even the hostess uses the s-sounding pronunciation. It is also preferred by many TTS engines including Siri's voices and MS OneCore voices. So should I go ahead and restore the original Eloquence pronunciation for "Louis", which is, some local preferences aside, the Americanized norm?

I suppose, depending on what @thunderdrop thinks. Though I'd probably replace it with the same SPR for lewis, the way that it does it natively puts just a bit too much emphasis on the `[I] and just sounds off.

@ultrasound1372 Not that it's late, but would you please release this month's update?


Third doses

At least the follow provinces/territories are reporting third doses:

AB
NS
YT

Currently these are captured in "total doses". Likely, what will have to happen is we will have to rename vaccine completion to second doses and add another column for third doses. This will break things (including our own data processing pipeline), but it's hard to see an alternative.

NU reporting third doses as of today. If adding historical third dose data from PHAC, will have to be sure to add third doses to total doses, given how the latter was calculated (dose 1 + dose 2).

Historical data for NU has been added.


Hosted User Management

Switch Designer UI login to use Cognito Hosted Login. this will allow users to use the full features of Congito include password forgot/reset.

fixed in v2


Fix 1405 handle android back button in composer

Fixes #1405

@pfrazee I agree. We should. It will be used elsewhere too. I can update this PR to do that.

sg

I thought about this a lot but I don't see any reason to introduce another event listener since the only component that would fire this "event" would be the Composer itself. I think the code is good as is. @pfrazee

Does this run any chance of a double handling of the back button?

@ansh I still had open questions about this, it wasn't ready for a merge


ensure remote tagger do not block when starting

What does this PR do?
Ensure the remote tagger do not block during the boot process of the application
Motivation
The function startTaggerStream was called twice. One in the Start function, and another time in the run function in a separate Go routine.
The problem is that if the first call to startTaggerStream inside the Start function is not able to connect to the server it will block the boot process forever. Since we already call startTaggerStream inside the run function on a separate goroutine and in a loop we can safely remove the call to startTaggerStream inside the Start function.
Code for the run function:
func (t *remoteTagger) run() {
	for {
		select {
		case <-t.telemetryTicker.C:
			t.store.collectTelemetry()
			continue
		case <-t.ctx.Done():
			return
		default:
		}

		if t.stream == nil {
			if err := t.startTaggerStream(noTimeout); err != nil {
				t.log.Warnf("error received trying to start stream with target %q: %s", t.options.Target, err)
				continue
			}
		}

		var response *pb.StreamTagsResponse
		err := grpcutil.DoWithTimeout(func() error {
			var err error
			response, err = t.stream.Recv()
			return err
		}, streamRecvTimeout)
		if err != nil {
			t.streamCancel()

			t.telemetryStore.ClientStreamErrors.Inc()

			// when Recv() returns an error, the stream is aborted
			// and the contents of our store are considered out of
			// sync and therefore no longer valid, so the tagger
			// can no longer be considered ready, and the stream
			// must be re-established.
			t.ready = false
			t.stream = nil

			t.log.Warnf("error received from remote tagger: %s", err)

			continue
		}

		t.telemetryStore.Receives.Inc()

		err = t.processResponse(response)
		if err != nil {
			t.log.Warnf("error processing event received from remote tagger: %s", err)
			continue
		}
	}
}

Describe how to test/QA your changes
Added naive unit tests that test the main thread is not blocked
Possible Drawbacks / Trade-offs
Additional Notes

/merge


Add setup section for relay/transaction service

Related to https://github.com/gnosis/safe-transaction-service/issues/56

@rmeissner This should close gnosis/safe-transaction-service#56


sortBadges: [move Club badges down] link on profile page not needed

I think the 2nd link [move Club badges down] below the badges on the profile page is not needed. Hide option is enough. The "move Club badges down" on Badges page is more than enough.

OK. I've removed that second link.


Connection error instruct-pix2pix

I use [ns-train igs2gs --data ./poster --load-dir ./outputs/poster/nerfacto/2024-02-20_172727/nerfstudio_models  --pipeline.prompt "a chair" --pipeline.guidance-scale 12.5 --pipeline.image-guidance-scale 1.5 ]
and the error is

I konw there is something wrong with my net, so it means that I should pre-install instruct-pix2pix from https://huggingface.co/timbrooks/instruct-pix2pix to avoid this?

Ya maybe. Seems like some huggingface issue, so maybe search on those forums to find a solution.

Ya maybe. Seems like some huggingface issue, so maybe search on those forums to find a solution.

Thank you for your suggestion. I download pix2pix,v1-4 and v1-5 and it runs. However, another error occurs when loading the checkpoints.

Could you please offer me some advice?

Seems like some weird issue with loading the pre-trained GS. @cvachha any ideas here?

Hi, @2629630207 I'm not exactly sure why this issue is occurring. If the GS you are editing was trained before the Nerfstudio V1,0 release, that might cause this issue. I would recommend to try re-training the initial GS with splatfacto and then running igs2gs, but I'm not sure why loading a checkpoint is giving this error.
If you load a splatfacto checkpoint with ns-train splatfacto (without running igs2gs) does this error still occur?

Hi, @2629630207 I'm not exactly sure why this issue is occurring. If the GS you are editing was trained before the Nerfstudio V1,0 release, that might cause this issue. I would recommend to try re-training the initial GS with splatfacto and then running igs2gs, but I'm not sure why loading a checkpoint is giving this error. If you load a splatfacto checkpoint with ns-train splatfacto (without running igs2gs) does this error still occur?

Thank you for your reply.I try splatfacto and runn igs2gs, it works.

So I believe it's likely a version issue of Nerfstudio as you say. I will check the version.
Expressing my gratitude once again.

I have encountered the same problem as you. How did you solve it? thank you


Firefox input rendering should be optimized on focus

Describe the bug
The Input component rendered in Firefox is not the nicest. It is maybe a detailed, but perhaps it is not a big issue to optimize the border when "on-focus". This is a CSS optimization.
To Reproduce
Open the form documentation page on Chrome and Firefox and compare
https://docs.nativebase.io/form
Screenshots
On Firefox, we see "glitches" around the input component.

On Chrome it looks nice:

Platform
Everything latest as of today (January 2022)

Hi @fabarea, Thanks for reporting the issue. we will look into it .

Hello @fabarea, I'm closing this issue as it is fixed in latest version.


Added MinimumTLSVersion column to PaaS\Storage report in the Network Security Dashboard workbook

Due to removal of TLS 1.0 and TLS 1.1 from storage accounts on November 1, 2024, this change adds the 'Min TLS Version' column to the storage account report in the Network Security Dashboard to surface any storage accounts that are not set to TLS 1.2.

Features have already been considered in pullrequest #898 - this request can be closed.

Closing as requested change was addressed in #898


[Bug]: Intermittent error for invalid input on Input widget

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Seen this happen a couple of times for older apps so raising this issue. Input widget occasionally displays error for invalid input and clears only when page is refreshed.

Steps To Reproduce

Check behaviour of an input widget on a functional app that's a few days/weeks old and observe an "invalid input" error displayed for the widget
OR
go to the modal called "updateBearerToken" on this app and observe occasional error displayed as seen in the video
https://release.app.appsmith.com/applications/612332edfe755a38b6e6a9c2/pages/61a0f83a15961655bd407657/edit#avkkqlxnav

Environment
Release
Version
Cloud

@ramsaptami Could you share the app with me or make it public?

@Tooluloope were you able to investigate this?


Lookup join without boxing

We still see a large number of boxed integers when joining on an INT column, this replaces PrimaryKey with JoinKey which has a specialised implementation when all the keys are fixed width.

Codecov Report

Merging #8208 (a2614bc) into master (916d807) will decrease coverage by 56.90%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master    #8208       +/-   ##
=============================================
- Coverage     71.02%   14.12%   -56.91%
+ Complexity     4314       81     -4233
=============================================
  Files          1626     1584       -42
  Lines         84929    83153     -1776
  Branches      12783    12596      -187
=============================================
- Hits          60325    11743    -48582
- Misses        20462    70531    +50069
+ Partials       4142      879     -3263

Flag
Coverage Δ

integration1
?

integration2
?

unittests1
?

unittests2
14.12% <0.00%> (+0.01%)
:arrow_up:

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

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

I can't establish whether this actually improves performance or not, though it definitely reduces allocation rate. I'm closing this in favour of delaying joins until after group by evaluation. It can be reopened later if necessary.


[Feature] Move balance/billing to organisation level from individual

... discussion to be continued on this thread ...

Done in V2 release


Develop

Core source + types
jest unit tests + coverage
rollup build
circleci config (install, build, test, send coverage report)
vitepress docs
readme is work in progress

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@b76ab3c). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   94.76%
=======================================
  Files           ?        5
  Lines           ?      210
  Branches        ?       55
=======================================
  Hits            ?      199
  Misses          ?        2
  Partials        ?        9

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 b76ab3c...ef4cff8. Read the comment docs.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@b76ab3c). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   94.76%
=======================================
  Files           ?        5
  Lines           ?      210
  Branches        ?       55
=======================================
  Hits            ?      199
  Misses          ?        2
  Partials        ?        9

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 b76ab3c...ef4cff8. Read the comment docs.


Bump requirements to Android 5+, Java 8+

For the release OkHttp 3.13 I’d like to change our requirements from this:

Android 2.3+ (released December 6, 2010)
Java 7+ (released July 2011)

To this:

Android 5.0+ (released November 12, 2014)
Java 8+ (released March 2014)

These minimums ensure our TLS stack supports both TLSv1.2 and ALPN. Requiring TLSv1.2 is important because we’re soon going to disable TLSv1.0 and TLSv1.1 by default!
I think we want to ship Java 8 bytecode and use lambas and method references. Downstream Android applications may need to enable desugaring in D8 when building APKs.
We should avoid hard requirements on Java 8 APIs (java.time). We will instead continue to offer them as convenience overloads. Java 8 APIs aren’t available until API 26 (released August 2017).

Would we consider releasing 3.12.x with critical security fixes, or just abandon really old clients?  FWIW I'm for this, I just think it's worth stating what the plan would be.

OkHttp works with Okio 2, but doesn't require it. If you find bugs, we’ll fix ’em.
As for a general policy on what platforms we’ll require, it’s difficult because there’s many competing trade-offs. We want to our libraries to be secure, small, correct, and fast. Usually in that order of preference!
Requiring Android 5 is about TLSv1.2. We might also be able to get it working on Android 4.4 since that release has some opt-in support for TLSv1.2. Needs investigation!

My concern are caused because for example Moshi 1.8 did require Okio 2.1 and did not work with 2.0.
From your writing, if couroutines are added in Okio 2.x and not 3.x I can assume that it should work with OkHttp 3.12.x and you'll make necessary fixes if necessary?
Dropping 70K users with a large part paid ones is not an easy thing to do, specially when I maintain an app since more than 7 years and have a close relationship with the users.
Android 4.4 would be nice it's 85% of those 70k and seems more acceptable, even if a solution without https support for 16+ would be nice too.
Or is there a way to have Okio linked for Moshi and other usage but tell OkHttp to not use it at runtime?

I was maybe not clear, I do understand the implication about OkHttp and how to handle it.
The issue is about keeping OkHttp 3.12 preventing me to update the other things (Okio/Moshi) due to breaking changes that would be incompatible with OkHttp 3.12. If moshi 1.9 fix an issue for me or improve performance and require Okio 2.2 that does not work with OkHttp 3.12 then I will have an issue.
I already do ABI split, adding SDK split would start to be really hard to manage from version numbering point of view and would not solve this other libraries update issue.
If you can stay API 19+ I can plan and announce a 16-18 drop in the coming months, if you keep 21+ then I need to start a complete analysis about my internal Okio / Moshi usages to ensure to issues in the future with my planned refactoring and usages and eventually seek for alternatives.

All future releases of Okio 1.x and 2.x will work with OkHttp 3.12.x. We’re pretty strict about compatibility!

Ok thanks that was the main blocking point from my first comment :)
Now I'll just hope you'll find a way for 19+ to simplify my future life.

Can we be sure that TLS v1.2 is enabled on all devices on API 21, including Samsung? https://github.com/square/okhttp/issues/2372#issuecomment-244807676

@vibin I think we have the most tolerant code in place here https://github.com/square/okhttp/blob/a74901501e37aa8dc2939a306e5013f9d1aebe1b/okhttp/src/main/java/okhttp3/internal/platform/AndroidPlatform.java#L332
So on API 21 it should try "TLSv1.2", then fallback to "TLS"

Dropping support for API level 19 seems quite aggressive, given 7.6% of devices are still using it (according to https://developer.android.com/about/dashboards/). If the goal is to disable something by default, is it in any way feasible to do that based on Build.SDK_INT >= 19?

About Java 8+, note that some java 8 apis are only available on Android starting from Android 7/Nougat.

@calvarez-ov we're using a Maven plugin called Animal Sniffer to warn us if we inadvertently use an API we shouldn't.

Instead of install Google SSL provider by users, we can use Conscrypt library SSL provider inside Okhttp itself.
if (Build.VERSION.SDK_INT < 21 && Security.getProvider("Okhttp") == null){
    Security.insertProviderAt(new OpenSSLProvider("Okhttp"), 1);
}

@swankjesse Is there any chance to allow using new OkHttp along with Conscrypt on KitKat devices or is there a reason for not doing so? For now OkHttp will crash under this case due to a fail fast piece of code in Platform.kt. Then I tried with a bit code changed, and it runs well on the KitKat emulator.
The code causing crash:
val isSupported: Boolean = when {
      !isAndroid -> false
      else -> {
        // Fail Fast
        check(
            Build.VERSION.SDK_INT >= 21) { "Expected Android API level 21+ but was ${Build.VERSION.SDK_INT}" }

        true
      }
    }

I changed the check call to a comparison, plus a minor change in the ConscryptPlatform preventing a NoClassDefFoundError, then the code seems to run well with Conscrypt. But I did not test it thoroughly.

@hqzxzwb please build your own OkHttp .jar and try it!

I'm sure everyone that needs to has probably gotten this working but in the general case for Android API16 and higher (a reasonable minimum, at this point) TLS1.2 is not so hard, here is exactly how in an app with tons of users verifying it works: https://github.com/ankidroid/Anki-Android/pull/5658/commits/47feecb9ac2e215bc56f387d043ccf9b271c032d#diff-36861f300e525ff4bc27048485a2ae3dR211
But I'm mainly commenting to see if anyone has investigated all the fancy new de-sugaring in Android Studio 4.0 to see if that could allow me (with my thousands upon thousands of Android <5 users) to move forward on this dependency to the modern branches. I might try it myself but someone may have done so already

@mikehardy OkHttp 3.12.12 will already do most of what your Tls12SocketFactory does
https://github.com/square/okhttp/blob/okhttp_3.12.x/okhttp/src/main/java/okhttp3/internal/platform/AndroidPlatform.java#L445
Not sure about the rest of the code or desugaring.

How did I miss that? Thanks for the pointer @yschimke I will test that and likely be able to delete unnecessary code, a maintainer's favorite thing...


Add string constant

Description
Only stringname constants exist, while string constants do not.
Implementation ideas
No response

Hi @RadiantUwU please look for Make String from String.


[SPARK-11297] Add new code tags

@mengxr https://issues.apache.org/jira/browse/SPARK-11297
Add new code tags to hold the same look and feel with previous documents.

Merged build triggered.

Merged build started.

Test build #44306 has started for PR 9265 at commit 64a7c96.

Test build #44306 has finished for PR 9265 at commit 64a7c96.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44306/
Test PASSed.

Merged build finished. Test PASSed.

Can you post a before and after screenshot?

The original doc:

doc with include_example

doc with this PR:

I just saw the difference between include_example.rb generated HTML and the original {% highlight %} generated HTML. The latter one substitutes some labels like

 with null string, and adds some new labels such as . The code itself has no effect on the font size, but I saw the CSS file at spark/docs/_site/css does.

@yinxusen Could you check whether Pygments provides options to customize CSS? It seems possible from their doc: http://pygments.org/docs/quickstart/.

@mengxr Sure I'll try to do it.

@mengxr The simplest way to change the view is adding a css font constrain:
div .highlight pre {
  font-size: 12px;
}

It controls the elements inslide

xxxxxx

. I also check the font sizes of other code examples, and they are 12px, which is defined in bootstrap.min.css. Instead of changing the code tag, I think modifing the css is better.

Merged build triggered.

Merged build started.

Test build #44406 has started for PR 9265 at commit 7352bc4.

Test build #44406 has finished for PR 9265 at commit 7352bc4.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * public class JavaCountVectorizerExample \n  * public class JavaTfIdfExample \n  * public class JavaWord2VecExample \n

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44406/
Test PASSed.

LGTM. Merged into master. Thanks!


Declarative Docker containers are always wanted by multi-user.target

Describe the bug
I have a Docker container which I would like to run on a systemd timer at a certain time but I do not want to have it run on every boot of my machine.
Declarative Docker containers seem to be hardcoded to be wanted by the multi-user.target, so having them available as a service for running them on-demand but not start automatically on boot is not possible to my knowledge (which isn't much yet when it comes to Nix, feel free to educate me).
I have tried setting the systemd.services.docker-<name>.wantedBy = []; but that didn't override it.
To Reproduce
Steps to reproduce the behavior:

Declare a Docker container with docker-contianers.<name>
Don't want it to run on boot
Notice that it runs on boot with no obvious way to disable it

Expected behavior
An obvious flag to deactivate autostart like docker-contianers.<name>.startOnBoot = false; and/or docker-contianers.<name>.wantedBy = [];.
Additional context
The Docker container I want to run on a timer
Metadata

system: "x86_64-linux"
host os: Linux 5.3.9, NixOS, 19.09.1151.8e3698fee4b (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3
channels(root): "nixos-19.09.1155.bae4d7daa01, nixos-unstable-20.03pre200231.7827d3f4497"
channels(atemu): "nixos-19.09.1155.bae4d7daa01, nixos-unstable-20.03pre200231.7827d3f4497"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
  - virtualisation

After learning about NixOS and Nix the past few months, I found out about lib.mkForce which, as the name implies, overwrites what's been set in the module.
I still think it'd be nicer to have an integrated option so that you don't have to touch the systemd service manually.


Different behavior of {{@last}} when {{#each}} in {{#each}}

When {{#each}} on object, {{@last}} is undefined
When {{#each}} on array, {{@last}} will be true in last run
When {{#each}} inside another {{#each}} , {{@last}} will be set by outer {{#each}} and the behavior of 1 and 2 changed.

Sample code here:
http://jsfiddle.net/y4pd8qs2/1/

Released in 3.0.0


Adjust dialog resizing timing to ensure contents have time to render first

There are a couple issues at play here, which I'll comment on a bit more inline where they're relevant. The gist of these issues, however, is that Lit elements rendered inside dialogs don't always have time to render fully before our resizing kicks in, leading to a situation where the dialog height can end up rendered improperly on first resize.
This is most noticeable in Firefox, where it happened basically everywhere for all dialogs. If you render a Lit element and a native element inside a dialog in Firefox, its initial resize will only account for the native select element, as the Lit elements haven't rendered yet. Any kind of debugging attached prior to the first height calculation gives the elements sufficient time to render and the problem vanishes.

Visual diff failures are a bit odd... I wonder if focus is weird now?

Yep, just checked in the demo and focus is now not being applied properly; presumably because it's now happening too early.

Yeah okay, the focus issues come about because of the first _focusInitial call. Now that the dialog isn't visible until after, that first call focuses the document body.

[ ] Don't merge me until core is bumped!

I'll investigate those fullscreen tests explicitly. Unsure why they would be behaving differently than the non-fullscreen ones, but I'll figure it out.

Ok, so for the fullscreen stuff... It looks like before my change, focus was being set on the close button, whereas now it's being set on the tabs (inside the dialog). This... Seems good? But it's a change in behaviour so I'm less sure.

Ok, so for the fullscreen stuff... It looks like before my change, focus was being set on the close button, whereas now it's being set on the tabs (inside the dialog). This... Seems good? But it's a change in behaviour so I'm less sure.

Yeah I am surprised that the focus was being places on the abort button.  It's supposed to go on the first focusable in the content.  Are you sure it's going to the tab though... if it is, the focus style would look like this:

Yeah I am surprised that the focus was being placed on the abort button. It's supposed to go on the first focusable in the content. Are you sure it's going to the tab though... if it is, the focus style would look like this:

d2l-tabs becomes the active element for sure when I check on the demo page, but the focused tab definitely isn't getting focus-visible applied.

d2l-tabs becomes the active element for sure when I check on the demo page, but the first focused tab definitely isn't getting focus-visible applied. The latter ones definitely do when I arrow key around, and if I arrow key to the right, I end up on the second tab as I would expect.

I can also confirm that focus() is being called on the tab appropriately. I breakpointed into the d2l-tabs focus method and can confirm that it's selecting the right tab and focusing it. For some reason that's just not applying the focus-visible class.

Yeah I am surprised that the focus was being placed on the abort button. It's supposed to go on the first focusable in the content. Are you sure it's going to the tab though... if it is, the focus style would look like this:

d2l-tabs becomes the active element for sure when I check on the demo page, but the first focused tab definitely isn't getting focus-visible applied. The latter ones definitely do when I arrow key around, and if I arrow key to the right, I end up on the second tab as I would expect.

Ok great.  Yep I forgot about the focus-visible.

To re-open the loop (and then close it again), fixing the focus behaviour here is going to be a bit more work than initially expected, so I'm going to handle that in a separate PR.

[ ] Wait for tabs focus fix


fix link

Fix link to Simply DNS

@svx I had to make some changes and the CI failed again 😅 can I merge this PR, please?


add vm.tiktok.com for supported urls

Could or should *.tiktok.com be added?

I don't know why your checks are failing, considering you didn't change anything that would mess with the build. Could you rebase this on the dev branch? I try to leave merging into master until after I've better tested the features.
As for adding *.tiktok.com, I don't know if we should because the app does not yet support all of TikTok's features. We are still missing LiveStreams, messaging, etc. So I think we should keep the scope narrow until we add feature parity.
Looks good otherwise!

Just rebase and it should be good.

Just rebased.

I loose it, sorry ):


Do not hide "Module not found" errors during import

This can be alegit error from the user. Also simplify LoadFunctionModule to drop support for array of files.
Draft for now - still want to test the remote execution cases.

This was superseded by #36


Microsoft azure Billing monitoring

Would it be possible to add Azure billing monitoring? Would be helpful , if we have billing data.
Microsoft have billing API's for access to the Azure Usage and Rates.
https://docs.microsoft.com/en-us/rest/api/consumption/
https://docs.microsoft.com/en-us/rest/api/consumption/usagedetails/lis
https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/usage-rate-card-overview

This exporter only covers the monitor API, so if this information isn't available via that you'll want to find/create a different exporter.


[SPARK-50416][CORE] A more portable terminal / pipe test needed for bin/load-spark-env.sh

What changes were proposed in this pull request?
The last action in bin/load-spark-env.sh performs a test to determine whether running in a terminal or not, and whether stdin is reading from a pipe.   A more portable test is needed.
Why are the changes needed?
The current approach relies on ps with options that vary significantly between different Unix-like systems.  Specifically, it prints an error message in both cygwin and msys2 (and by extension, in all of the variations of git-for-windows).   It doesn't print an error message, but fails to detect a terminal session in Linux and Osx/Darwin homebrew (always thinks STDIN is a pipe).
Here's what the problem looks like in a cygwin64 session (with set -x just ahead of the section of interest):
If called directly:
$ bin/load-spark-env.sh
++ ps -o stat= -p 1947
ps: unknown option -- o
Try `ps --help' for more information.
+ [[ ! '' =~ \+ ]]
+ [[ -p /dev/stdin ]]
+ export 'SPARK_BEELINE_OPTS= -Djline.terminal=jline.UnsupportedTerminal'
+ SPARK_BEELINE_OPTS=' -Djline.terminal=jline.UnsupportedTerminal'

Interestingly, due to the 2-part test, it does the right thing w.r.t. the Terminal test, the main problem being the error message.
If called downstream from a pipe:
$ echo "yo" | bin/load-spark-env.sh
++ ps -o stat= -p 1955
ps: unknown option -- o
Try `ps --help' for more information.
+ [[ ! '' =~ \+ ]]
+ [[ -p /dev/stdin ]]

Again, it correctly detects the pipe environment, but with an error message.
In WSL2 Ubuntu, the test doesn't correctly detect a non-pipe terminal session:
# /opt/spark$ bin/load-spark-env.sh
++ ps -o stat= -p 1423
+ [[ ! S+ =~ \+ ]]
# echo "yo!" | bin/load-spark-env.sh
++ ps -o stat= -p 1416
+ [[ ! S+ =~ \+ ]]

In #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024, the same failure occurs (it doesn't recognize terminal environments).
Does this PR introduce any user-facing change?
This is a proposed bug fix, and, other than fixing the bug,  should be invisible to users.
How was this patch tested?
The patch was verified to behave as intended in terminal sessions, both interactive and piped, in the following 5 environments.

- Linux quadd 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
- Linux d5 <IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
- MINGW64_NT-10.0-22631 d5 3.5.4-0bc1222b.x86_64 2024-09-04 18:28 UTC x86_64 Msys
- CYGWIN_NT-10.0-22631 d5 3.5.3-1.x86_64 2024-04-03 17:25 UTC x86_64 Cygwin
- Darwin suemac.local 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:21 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T8103 arm64

The test was to manually run the following script, verifying the expected response to both pipe and terminal sessions.
#!/bin/bash
if [ -e /usr/bin/tty -a "`tty`" != "not a tty" -a ! -p /dev/stdin ]; then
  echo "not a pipe"
else
  echo "is a pipe"
fi

The output of the manual test in all 5 tested environments.
philwalk@quadd:/opt/spark
$ isPipe
not a pipe
#
$ echo "yo" | isPipe
is a pipe
#

Was this patch authored or co-authored using generative AI tooling?
No

Not sure what "workflow run detection" is, or how to correct it.
The output of git remote -vv is:
# git remote -vv
origin  https://github.com/philwalk/spark.git (fetch)
origin  https://github.com/philwalk/spark.git (push)

I enabled Build and Test on my forked repo.

Let's also file a JIRA, and add it into the PR description, see also https://spark.apache.org/contributing.html

The touched code seems to be borrowed from Apache Hive, would you like to also report the issue to the Hive community?

Let's also file a JIRA, and add it into the PR description, see also https://spark.apache.org/contributing.html
I requested a JIRA account, not yet created ...

Got it. I approved it a few minutes ago, @philwalk .

The touched code seems to be borrowed from Apache Hive, would you like to also report the issue to the Hive community?
Not at this time ...

Is this waiting on me to do something?


Issue #75 : upgrade to b2d-v17.09.0-ce

Can one of the admins verify this patch?

LGTM, we need higher version of docker for sure

Ok to test

retest this please

@xqianwang can you explain what you need from the higher version?

Current CI fails due to a mismatch in version of the NFS client. This means we might need manual testing to confirm if this is stil working as expected.

retest this please


cdylib target stops all verification

Kani errors when I add cdylib as a build target.
I tried this code:
[lib]
path = "src/lib.rs"
crate-type = ["lib", "cdylib"]

using the following command line invocation:
cargo kani

with Kani version:
warning: Skipped verification of `<program>` due to unsupported crate-type: `cdylib`.
Error: No supported targets were found.

Kani should still attempt to verify the "lib" target. Instead, I have to modify the crate-type to  crate-type = ["lib"] for Kani to do any work.

Hi @weaversa, thanks for reporting this issue. I believe this is the same root cause as #1915. Is this blocking you right now or can you change the crate type locally and keep running Kani?
Just to give a bit more background, cargo sets different rustc flags according to the library types. For cdylib, the compiler will try to generate a shared library, which we can't handle. We also have no mechanism to skip it yet.

Hi @celinval. I'm ok right now, and I look forward to when this is not an issue. I'm happy to close this in favor of #1915 if you wish.

Our workaround was to add an extra layer to the project. We restructured from (generically):
project
  | - Cargo.toml
  | - src
     | - lib.rs
     | - kani_proofs.rs
     | - unit_tests.rs

to
project
  | - Cargo.toml ([workspace] says "members= ["main", "cdylib"])
  | - main
      | - Cargo.toml
      | - src
         | - lib.rs
         | - kani_proofs.rs
         | - unit_tests.rs
  | - cdylib
      | - Cargo.toml
      | - src
           | - lib.rs (a stub that says 'pub use main::*')

Sorry that you had to make changes to your project layout. So if you don't mind, let's track this work on #1915.

@weaversa I just wanted to let you know that I've pushed a fix for this which shall be included in the next release.

Thank you!


Upgrade to .NET 7

This involves upgrading

[x] Service project
[x] Service test project
[x] Action for testing the service

No PR, committed directly to main...


Add tests

Coverage decreased (-0.04%) to 99.677% when pulling 15066f94b682ce6e1f8de308ff93bf22a19ae143 on add-tests into 716f807fadf97ea0224c72f48473b51007dff216 on master.


"dyld: Library not loaded" when installing on OS X

Package version (if known): The latest from the download page.
Python 3.7.8
Flask 1.1.2
Werkzeug 0.16.1
OS X Catalina, 0.15.6 (19G73)
Describe the bug
Hello, I've run into an installation error when trying to install invenio locally for testing. I am seeing this error.
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.66.dylib
Referenced from: /usr/local/bin/node
Reason: image not found

Steps to Reproduce

Run ./scripts/bootstrap, specifically it's this step that is failing: pipenv run invenio webpack buildall
See error

Additional context
I've been looking online and this looks like a known issue with OS X, but so far I have not found a workaround.

Actually, I found a fix! My version of node was out of date and I didn't realize it.
brew upgrade
brew cleanup


Analyze use cases and implementation choices for supporting OGC Features and Geometries JSON

Background
See the official github page about: OGC Features and Geometries JSON that is OGC's candidate standard.
According to documentation OGC Features and Geometries JSON will

include the ability to use Coordinate Reference Systems (CRSs) other than WGS84
follow the OGC Axis Order Policy,
allow the use of non-Euclidean metrics, in particular ellipsoidal metrics,
support solids and multi-solids as geometry types, and
provide guidance on how to represent feature properties, e.g., including temporal properties.

This might be one of candidate enhancements for Hakunapi after 1.0 version.
Before deciding some analysis is needed:

use cases and data sets for new geometry types like solids and multi-solids
how new capabilities of OGC Features and Geometries JSON would be used in vector data products or geospatial APIs by mapping agencies like NLS of Finland
how to define, implement and document application schemas when producing OGC API Features service that supports 1) GeoJSON content with CRS84 default coordinate system, 2) GeoJSON content with other coordinate systems according to OGC API Features Part 2 (CRS) and it's "Content-Crs" header (that provides also a method for axis-order issue), 3) JSON-FG content with CRS84 (content is same as GeoJSON) or other coordinate systems (content is something different to GeoJSON content)
implementation choices in Hakunapi (there's some internal notes by NLS of Finland on this topic)

Suggested first implementation targeting Hakunapi 1.1.0 version
Support at least these features first:

include the ability to use Coordinate Reference Systems (CRSs) other than WGS84
follow the OGC Axis Order Policy,
provide guidance on how to represent feature properties, e.g., including temporal properties.

Non goals (for first iteration):

allow the use of non-Euclidean metrics, in particular ellipsoidal metrics,
support solids and multi-solids as geometry types, and

Standard conformance classes to be supported (from the draft standard):

"Core": The Core conformance class extends GeoJSON with additional members that allow Temporal information, extended Geometry information (i.e. geometries in coordinate reference systems (CRS) other than CRS84 which is the GeoJSON CRS, and additional geometry types) and Reference systems information to be encoded in a JSON-FG document. The Core conformance class has a dependency on GeoJSON. This means that a JSON-FG document that conforms to Core must also conform to GeoJSON.

INSPIRE is currently accepting OGC API Features as an interface for Download services. However, only endorsed encodings are GML and GeoPackage.
Some good reasons implement JSON-FG and ask endorsement from European Commission:

JSON-FG supports coordinate reference systems other than WGS-84
JSON-FG is backward compatible (if geometry is populated) and therefore works also with tools supporting only GeoJSON
JSON-FG supports more complex geometry types, which are needed e.g. in TN (Transport Network)
NLS-FI is using EPSG:3067 in GeoJSON (which is not valid GeoJSON)

I would start with INSPIRE AD (which is already used as an example of hakunapi) even if though it only has point as a geometry type.

Just linking this issue to the initial implementation PR #73 that's still under development.

Pre-release 1.3.0-rc1 (https://github.com/nlsfi/hakunapi/releases/tag/1.3.0-rc1) supports now JSON-FG output.
Demo-service has this pre-release now installed.
For example JSONFG output in WGS84 lon-lat default coordinate reference system (CRS84) has geometry just like GeoJSON:
https://beta-paikkatieto.maanmittauslaitos.fi/inspire-addresses/features/v1/collections/addresses/items?limit=1&f=jsonfg
"geometry":{"type":"Point","coordinates":[23.2125784,62.9749241]}
WGS84 lat-lon non-default (EPSG:4326) has place with geometry:
https://beta-paikkatieto.maanmittauslaitos.fi/inspire-addresses/features/v1/collections/addresses/items?limit=1&f=jsonfg&crs=http://www.opengis.net/def/crs/EPSG/0/4326
``"place":{"type":"Point","coordinates":[23.2125784,62.9749241]} "geometry":{"type":"Point","coordinates":[23.2125784,62.9749241]}`
Maybe place should have coordinate azed in different way?
ETRS-TM35FIN seems to be ok, however different rounding?
https://beta-paikkatieto.maanmittauslaitos.fi/inspire-addresses/features/v1/collections/addresses/items?limit=1&f=jsonfg&crs=http://www.opengis.net/def/crs/EPSG/0/3067
"place":{"type":"Point","coordinates":[308075,6988449]}
"geometry":{"type":"Point","coordinates":[23.213,62.975]}


replace uri with uris

replace ElasticsearchJestProperties uri with uris

Hi @tuser4198 , thanks a lot for your contribution.
Do you mind if you try to keep the backward compatibility with "uri" properties ?


New IDF file (IW Mullion) and others

Patch Notes

IW Mullion environment has been added to this repository.
Updated env registers to correct standard (SimulationEngine-Building-WeatherType-ActionSpace-Stochasticity-version)
Opyplus doesn't check field length in order to allow larger fields inner IDF.
Added code example for gcloud API. With this code, it is possible to create instance groups automatically (MIGs)

Environments list has been updated in documentation and README.
Rebranding message for repository has been added in README.
Logo updated to Sinergym

For some reason the tests are not being triggered in last 2 commits... Could you check why? @AlejandroCN7 Thanks!


FR: steam store pages

Adds:

All Steam Store pages

Thank you very much! Merging this in! This has to be put on there manually, so it will take a bit to show.


[SPARK-6763][SQL] Add CountMinSketch to DataFrame for estimating frequencies

JIRA: https://issues.apache.org/jira/browse/SPARK-6763

Merged build triggered.

Merged build started.

Test build #33531 has started for   PR 6416 at commit 9972421.

Test build #33531 has finished for   PR 6416 at commit 9972421.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/33531/
Test PASSed.

Can you give an example of what your returned DataFrame looks like?

For input DataFrame with a column name "A":
  A
  1
 10
  5
 10
  8

The returned DataFrame has two columns "A" and "A_freq" where "A" lists the uniques values of the column "A" in the input DataFrame, and "A_freq" lists the corresponding minimum counts.
  A       A_freq
  1          1
 10          2
  5          1
  8          1

Merged build triggered.

@rxin Is it good to have this as an aggregation function too? If so, I will update it too.

@rxin @hvanhovell @yhuai  should this be synced up with #8362 in terms of implementation approach?

@MLnick I guess it depends. The other dataframe.stat functions have not been implemented as UDAFs, so this is not nessecary. However I do think that CMS is a usefull UDAF to have.


Relative Home Page URLs and Article URLs are not presented correctly.

When a feed has URLs relative, NetNewsWire Version 6.1 (6106) doesn't make them absolute by combining with the Feed URL, instead leaves them relative.
Example:

Feed URL: https://www.qemu.org/feed.xml
Home Page reference:<link href="/" rel="alternate" type="text/html" />

Article reference:<entry>
  <title type="html">QEMU version 7.0.0 released</title>
  <link href="/2022/04/19/qemu-7-0-0/" rel="alternate" type="text/html" title="QEMU version 7.0.0 released" />

Presented Home Page URL: http:///
Presented Article URL: /2022/04/19/qemu-7-0-0/

Another example: https://neverworkintheory.org/atom.xml
This feed's latest article is named "That Went Well". Tapping its headline text takes no action. The URL from the Share toolbar button, then Copy, is: /2022/04/30/that-went-well.html
The first link in the article is "first online event". Tapping the link also takes no action.

Another site which is broken because of this.
https://tess.oconnor.cx/feed


Add tests for trailers and wire validation

This PR seeks to add additional wire validation tests for gRPC, gRPC-web, and Connect. Essentially, it adds tests for all three protocols to verify how they handle trailers on the wire. Connect and gRPC-web should not send trailers and gRPC should.
To accomplish this, two new test yaml files were added - connect.yaml and grpc.yaml which house all tests specific to those protocols. The tests for verifying the wire details were added to this files.
In addition, any other files that were previously Connect-only have been deleted and merged into the connect.yaml file.

For gRPC, require that ...

Actually, it is okay if gRPC sends back no trailers. So only require this when the trailers are present and non-empty. If empty, then require that the reported response trailers are also empty and that there were no response messages (to double-check that this was a "trailers-only" response, where all data is actually in the HTTP headers).

I just realized you can't easily only check those things based no protocol because you don't know the protocol at that point.
I guess I can cherry-pick this little change related to that from a work-in-progress branch: https://github.com/connectrpc/conformance/compare/jh/tighten-up#diff-37ae526ec60373f25e21af5d36aebcdbd965e22fbcd5293bcf5bc4e55f47b537R159
That way, you have the entire test case available when making assertions.


mobx @observable conflicts with sort-comp

In my project using mobx and react, I would like to use the @observable like this followings:
{
static methods

@observable variable

life cycle methods
}

How do configure the sort-comp rule to allow this situation?

I'm afraid that sort-comp does not handle decorators yet.

This worked with<EMAIL_ADDRESS>        "order": [
          "type-annotations",
          "static-methods",
          "statics",
          "defaultProps",
          "/^observable/",
          "lifecycle",
          "everything-else",
          "render"
        ]

but does not work with 7.7.0

@dgcoffman can you clarify what "stopped working" with 7.7, and would you be able to figure out if it worked in 7.5 and 7.6?

Sure,
In 7.4.0, given the config above
class MyComponent extends React.Component<Props> {
  @observable aVariable: string;

  componentWillMount() { ... }

is allowed.
In 7.5.0+ (I tried every release), eslint produces error  aVariable should be placed after componentWillMount  react/sort-comp

I’m confused; in that example, it’s decorsting “aVariable” - so that’s what should get sorted (the decorator name just goes along for the ride)

I don't know the internals of the rule. Maybe up until 7.5.0 is was mis-identifying the variable name as "observable"? We liked it better that way.

Maybe so. Either way tho, the decorator name is irrelevant since it’s not the thing being sorted; we’d have to do something special to allow you to specify that you want the decorator name to apply.

Did anyone manage to resolve this?
I have<EMAIL_ADDRESS>and still running into this issue.
I tried different combinations mentioned above, and tried to specify the regex a bit more, but nothing works.
@observer
class someClass extends Component<Props> {
    @observable someObservable = '';

    static contextType = someContext;

    componentDidMount() { }
}

I get this warning:
someObservable should be placed after componentDidMount eslint(react/sort-comp)
The same goes for static contextType
Current config .eslintrc.json:
"react/sort-comp": [1, {
      "order": [
<EMAIL_ADDRESS>        "static-methods",
        "lifecycle",
        "everything-else",
        "render"
      ]
    }]

If this is still an issue with the latest version of the plugin, and someone can comment with repro code, I'll be happy to reopen.


Add MFA

Still in progress of mock testing, but reviews of current changes would be great!

@robframpton  Added the exception case for Verify, not sure where the mapping is going wrong for valid attribute in Verify, changed naming convention for the property Valid to IsValid.

@robframpton fixed to pass compilation, bumped version to 1.8.0-alpha.3 . Available for review and publish

@robframpton  published preleased version 1.8.0-alpha.3


Clean up uses of coerceSize

Now that https://github.com/GaloisInc/cryptol/pull/1713 has been merged, some use cases of coerceSize should be able to be removed from cryptol-specs, particularly in ML-KEM, e.g. https://github.com/GaloisInc/cryptol-specs/blob/049f57d681c3a45469d8b533a944be9dd42988d7/Primitive/Asymmetric/Cipher/ML-KEM/specification.cry#L198

If we make this change now, are we happy that cryptol-specs will depend on a nightly build of Cryptol, rather than a formally tagged release?  Put another way - should we create a release 3.2 of Cryptol before updating this repo?

cryptol-specs current target is nightly at the moment,
https://github.com/GaloisInc/cryptol-specs/blob/049f57d681c3a45469d8b533a944be9dd42988d7/.github/workflows/ci.yml#L13
However, the CI overhaul in the roadmap plans to test cryptol-specs against nightly and a predetermined set of releases of cryptol.
I am okay with holding off on this ticket until the new CI is in place (we can start cutting tickets over here for that as well).

OK... sounds good

Oops, I missed the discussion on this issue about waiting to fix. I have a branch that adds all the fixes, I'll just leave it as a draft PR until we're ready to stabilize CI and the version of cryptol with this fix in it. See #107.

Discussed this internally and we came to the conclusion of releasing a new Cryptol version and having cryptol-specs CI target nightly and the most recently released version of Cryptol as a starting point.


Update Features list on istio.io

Update this page for 1.1 release: https://istio.io/about/feature-stages/

@jasminejaksic Thanks for jumping in.
@jasminejaksic-zz Thank you too

@jasminejaksic do you still have time to do this?  If not please ask for it to be reassigned earlier rather later

@oaktowner was working on this last week but for some odd reason I can't assign this to him

This was updated with 1.2


wiki: add a page with a table for Go-related livestreams

Such a table would be useful to find regular livestreams mainly related to Go, such as Go coding or teaching aspects of the language to newcomers. It would be similar to https://github.com/golang/go/wiki/Conferences, but exclusively for regular livestreams.
Conferences, podcasts, and meetups would not be applicable in this table even if they have livestreams, because they all have their aggregated lists already.
The table could have the following columns:

Name
Topic (up to 40 characters)
Frequency (Daily, Weekly, Twice per week, Monthly, etc)
Link (Twitch, Youtube, etc)

I already have three entries to kickstart the table: @mdlayher, @stapelberg, and @mdempsky. I plan to add myself to the list soon enough :)

/cc @jordanlewis who also live streams Go content on a regular basis.

Please go ahead.

Done: https://github.com/golang/go/wiki/Livestreams
I filled the info for the three people I know, please update your information as each of you see fit. @stapelberg I could not find how frequent your livestreams are.
I didn't include @jordanlewis as his livestreams seem to be around CockroachDB - I'll leave it up to him to decide if that qualifies as a "Go livestream" :)

I stream once or twice a week. The topic is definitely CockroachDB, but it's CockroachDB internals, and CockroachDB is a Go program with lots of interesting Go problems to look at and talk about.  So, I'd be honored to be on the wiki, and will add myself unless you have an issue with it!

None at all, sounds good! It was just hard to judge what the content was like without actually watching entire videos :)


Fix LinearRing serialization issue while emitting task description in…

… a trace log

Description
[Describe what this change achieves]
Related Issues
Resolves https://github.com/opensearch-project/OpenSearch/issues/11688

Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
[x] Commits are signed per the DCO using --signoff
~- [ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)~
~- [ ] Public documentation issue/PR created~

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

This is the problem to solve.  @dblock  posted a solution for this as well: https://github.com/opensearch-project/OpenSearch/pull/12831

@rishabhmaurya is it fixed by https://github.com/opensearch-project/OpenSearch/pull/12834

I love that there is so much interest in fixing failing tests! Too bad everyone is focused on fixing the same test :)

I do not like the fact that the search task executes fine, its just when the trace logs are enabled and getDescription() on task is invoked which results in such failures. https://github.com/opensearch-project/OpenSearch/pull/12831 fixes it for linear ring but it could be some other field type tomorrow, originating from core/plugins.
I will close this one

We ended up merging a fix a little closer to what's here in https://github.com/opensearch-project/OpenSearch/pull/12834. Task description will not fail when it cannot be serialized, instead the description will contain the serialization error.

I love that there is so much interest in fixing failing tests! Too bad everyone is focused on fixing the same test :)

This was a well isolated one, and I enjoyed figuring out and debating the best way to fix it! Thanks @shwetathareja @rishabhmaurya @andrross @reta and anyone I forgot to mention.


[GE] Transparency Texture!

https://github.com/BabylonJS/ThePirateCove/issues/28

All checks are failing :-)
Want to check that?


Symbol information is missing in resource-path in ResourceAccessAction

When traversing through the nodes, It seems the resource path is consist of a list of BLangLiteral nodes. Therefore, the symbol information which we can use to build the compiler API symbols is missing.
referencing code:
public function test() {
    Client cl = new ("");
    cl-> /path2/<c1>[<c2>""]/path4.post();
}

Cursor positions c1>, <c2`
Originally posted by @dulajdilshan in https://github.com/ballerina-platform/ballerina-lang/issues/36889#issuecomment-1233989668

BLangResourceAccessInvocation.resourceAccessPathSegments is a list constructor expression. Hence type of each resource math segment will be BLangExpression

Need to decide whether we are going to add a symbol for resource path segments or let the consumers handle with the existing information.

When accessing the expression node of a ClientResourceAccessActionNode node via Semantic API semanticModel.symbol(clientResourceAccessActionNode.expression()), a ResourceMethodSymbol was returned.

Is this the intended output ? The expression node is originally a SimpleNameReference. Please refer ti the below code snippet.
http:Client fares_apiEndpoint = check new (fareAPIUrl);
fares_api:Fare fare = check fares_apiEndpoint->/fare/[flightNumber]/[flightDate].get;

Note : My effort is to access the display annotation of http:Client fares_apiEndpoint = check new (fareAPIUrl) by getting the symbol of fares_apiEndpoint.

This is a known issue @aneeshafedo Please refer https://github.com/ballerina-platform/ballerina-lang/issues/37977


Implement CParameterCombination::obtain_from_generic()

Iterating through parameter combinations in python as indicated in modelselection_parameter_tree_modular.py doesn't work since get_element() returns a CSGObject pointer.
This patch adds an obtain_from_generic() function to CParamterCombination that performs the type cast. The example was adopted.

Thanks for that! There is a minor thing. If you have a minute, it would be great if you can update. Otherwise I will merge soon

Great thanks!


Implementing OpenAI function calling

Hi Ovidijus,
Thank you for creating deep-chat. It's an amazing project!
I'm curious about integrating function calling feature using OpenAI's API
(https://platform.openai.com/docs/guides/gpt/function-calling)
Is this feasible within deep-chat?
Thank you!
Best

Hi @devpulse01, this does seem like something that Deep Chat can use.
I have personally not used functions before, so I will need to do some exploration to see what needs to be changed in Deep Chat to facilitate this.
I am currently in the process of working on another feature (disabling the submit button) and will be able to pick this up directly after it. For the moment I will close this issue and will re-open it when I start working on it. Thanks!

Hi, as promised I will now be focusing on exploring the OpenAI function API and seeing how I can integrate it into the Deep Chat. I will post updates here on the progress.

The timing of this issue is fortunate/unfortunate as today OpenAI announced a change to the function API via the use of tools. This change came in just as I was about to finish the function API so I had to refactor it all to the new version.
OpenAI has announced a few other new features which I will be integrating to the Deep Chat component in the coming few days, once all of that is finished I will be making a big release for the Deep Chat component. Thanks!

Thanks for the update!
With all the exciting changes, I was also wondering if you'll be integrating the new assistants API?

There are a lot of new interesting features that were announced and I will try to tackle them one by one (incl. assistants API).
To note, it appears that some features that were announced are not working working or are not fully rolled out (going by what I read in the forums), so this limitation may hinder my integration efforts.
Nonetheless, I will be continuously updating this thread on the latest developments.

I have revamped the OpenAI Audio API to now use two new speechToText and textToSpeech properties which will allow the use of all the latest OpenAI Audio features.
Stay tuned for other features.

The OpenAI chat now supports sending images for the new Vision API when using the gpt-4-vision-preview model.

Integrating Assistants API is proving is a little more tricky. I have started adding the initial code and will continue this feature tomorrow.

Thank you for the update :)

I have most of the Assistants functionality now complete.
The last bit that remains is the ability to upload files. The reason why I couldn't complete it today is because the API seems to be retuning errors most of the time for unrelated reasons. Hopefully this gets better tomorrow and I should get this all done.

All integration work is now complete. I am going to start updating the documentation and the playground.

The latest OpenAI features have been released in version 1.4.1!!!!! :tada: :tada: :tada: :tada:
You can check them out in the new OpenAI documentation page or try them out in the Playground.
I will be closing this issue now, however if you experience any problems or have suggestions for improvements (in the component and documentation) feel free to comment below or raise a new issue.
Thanks!

Hey Ovidijus,
Thank you for the update! 🎉 This is amazing :) I'm excited to explore the new features. However I'm planning to use the new APIs through a backend rather than a direct connection.
Do you plan to update the server examples to incorporate these new features? I've attempted to integrate them on my end but have faced some challenges.

Hi @devpulse01. Because this project is focused on the component itself and focuses on the use of multiple different AI APIs we are not planning to maintain specific server-side integration code and try to keep it as lightweight as possible.
The OpenAI documentation has examples on how to get started with their features which should hopefully help. Because I've also implemented them directly into Deep Chat I can perhaps lend a hand if you let me know what the specific problem you are having is.

Yes, ok I completely understand. If I have really specific questions, I'll come back to you :) Thank you.