reason for issue with ubuntu 20.04

ubuntu 20.04 & nginx have unknown issues? i recommend using 18.04

apparently osu uses older tls 1.2 or 1.1 which ubuntu 20.04 doesn't support but 18.04 does.
I tried adding
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:@SECLEVEL=1";

to nginx config but it didn't work.
So if you can somehow enable TLS 1.0/1.1 then it should work.
Alternatively you could just use cloudflare, which supports it.

Ooh interesting, I wasn't aware 20.04 dropped support for older versions.. I'll do some further research and update the readme accordingly to advise people, thanks!


question: are the commands executed before or after uploading the files?

I was looking at this example and I had a small doubt, are these commands executed before or after the files are in the vps? ( I hope that extends what I said )

It took me a while to answer "+" I made my own kkkkk sorry


Made application mobile friendly

Fixes #7
Made the application look appropriate on all the screen sizes.
Me and @archikirar30  will pick this issue again at the end to make things responsive after the addition of new features by other pod mates (as discussed in the meeting on Friday i.e, 14th April, 2023).
@akshgpt7  can you please review it? Let me know if there is any issue in this PR.

Hey @akshgpt7 , I just seen a merge conflict in this PR. I've resolved it. Please merge it and let me know if it still require some changes.
Thanks!

LGTM!


a-list

a-list allows for users to receive a list of all users in the conversation along with their permission levels. Currently, only UUIDs are shown since they make up the key set of the HashMap containing the users and their permission levels.

LGTM


C# LSP failing suddenly on diagnostics

REPO: https://github.com/timheuer/xunitplay
Document open is TestProject2/UnitTest1.cs
When I open this workspace I'm met with a log of error notifications:

Log:
csharpoutputlog.txt
VS Code Extensions
ms-dotnettools.csdevkit: 1.8.10
ms-dotnettools.csharp: 2.36.19
ms-dotnettools.dotnet-maui: 1.1.14
Host:
Version:      8.0.6
Architecture: x64
Commit:       3b8b000a0e
.NET SDKs installed:
8.0.300 [C:\Program Files\dotnet\sdk]
8.0.400-preview.0.24312.1 [C:\Program Files\dotnet\sdk]

No local repro on mac. Looking at the logs, there seems to be a off by one parsing error. I see a double quote and a close brace that dont belong.
[Error - 8:45:20 AM] Request textDocument/documentSymbol failed.
Message: Unsupported extension '.cs%22,%22ref%22:%22~%22%7D' and LSP language id ''
Code: -32000
[object Object]
[Error - 8:45:20 AM] Request textDocument/semanticTokens/range failed.
Message: Unsupported extension '.cs%22,%22ref%22:%22~%22%7D' and LSP language id ''
Code: -32000

There is a known issue here with temp files and git diff files (potentially other areas) where there is a race determining the language from the document.  I'm hoping to have a fix for that this week, which should also fix this issue.
However I wouldn't have expected it to occur for a regular .cs file.  @timheuer did you by chance have a diff window open, or something similar?

did you by chance have a diff window open

Indeed the document was in a diff view at the time.

Good to know.  Duplicate of https://github.com/dotnet/vscode-csharp/issues/7290 and I'm hoping to get the fix in next week.


DOC-2103 HTTP step assertions update

https://harness.atlassian.net/browse/DOC-2103
Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[x ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

https://harness.atlassian.net/browse/DOC-2103

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app


Docker event documentation incorrect

Hello,
It looks like the documentation for events has become out of date, in particular around the kill event.  Prior to Docker 1.7.0, the kill event was only emitted on SIGKILL being sent to the container via docker kill.  Since 1.7.0, the semantic changed and the kill event started to be emitted on any signal sent via docker kill, and since 1.8.0 the semantic changed again and the kill event started to be emitted for any signal sent at all (including SIGTERM and SIGKILL sent as part of docker stop).  These changes in behavior led to a bug with the Amazon ECS Agent, which we will be correcting with our next release.
  Other events are emitted with type network and volume.
Note that kill is emitted under many more circumstances in recent versions of Docker, and that the ordering of die, kill changed to kill, die with Docker 1.8.0 as well.  The available documentation for events is fairly light as a whole, but the event diagram has been out of date at least since 1.7.0.
It would be fantastic if the semantics of the different events were documented and any semantic changes were called out in the changelog for releases.
Thanks!
Sam

Hi @samuelkarp - going through old issues; would you be interested in opening a PR if you think this still needs changes in the docs?

@thaJeztah Yes, I think this still needs changes as the docs are still incorrect with respect to the kill event.  I'd be happy to open a PR, but I don't know when I'm going to have the time to do so (especially since I don't have the source of the current diagram in the docs).  I'd also be interested in your thoughts on how you'd address the semantics of events changing over time (e.g., which events are emitted under which situation and how they change in different Docker versions).

The source of the graphic is actually in the repo; https://github.com/docker/docker/blob/master/docs/reference/api/images/event_state.gliffy, which can be used on https://www.gliffy.com :smile:

Oh neat!  Now the bigger question is finding time.  If anyone else wants to pick this up before I've had the chance, please do!

:smile:

I can update the docs but it looks like these links are out of date.
The events documentation @samuelkarp mentioned redirects to https://docs.docker.com/engine/api/ and the graphic event_state.gliffy no longer exists.
Is this still an issue?  If so, can someone point me to the docs that need to be updated?

@dccurtis It looks like the event documentation was moved here, though now it contains no lifecycle information about container events.  I don't know if that was an intentional omission or not.

I'll have to ask @bfirsh @mstanleyjones if that was deliberate or just got lost in the process

@thaJeztah Sounds good.  I'll stay tuned to see if I can help out with this.

Probably lost in the process. At least, I don't remember removing it intentionally. Sorry about that!

🤷♀


newrelic cli commands need to be updated in the newrelic-cli/blob/master/docs/GETTING_STARTED.md.

Description
The cli commands in the readme page https://github.com/newrelic/newrelic-cli/blob/master/docs/GETTING_STARTED.md all need updates.
Go Version
Not Applicable
Current behavior
I was able to find correct commands for:

Find application ID for your app:  newrelic apm application search -n
Create tag:  newrelic entity tags create --guid  --tag key:value
Add multiple tags: newrelic entity tags create --guid  --tag key1:value1,key2:value2
Read tags for the give entity: newrelic entity tags get --guid
Deployment marker: newrelic apm deployment create --applicationId  --revision  --change-log  --description  --user

Expected behavior
Update readme document
Steps To Reproduce
Not Applicable
Debug Output (if applicable)
Not Applicable
Additional Context
Not Applicable
References or Related Issues
Not Applicable

Looks like this document wasn't updated with the last round of UX changes to the CLI, and should be easy enough to get resolved.  Also a great issue for the community to submit a PR.


Added fix for swap video not working on screenshare

https://app.clickup.com/t/8556478/APP-4570

Created release/fpe-1.0.2 for new releases


CYC-111 Add Store + Update function to Purchase Attach Controller

Description
There should be an endpoint that allows for modifying the inventory item that a purchase order is attached to

For now only update is needed.


extern types

Add extern type declarations for declaring types from external libraries which have an unknown size/layout.
Rendered

Given that this is declaring a new type and not an alias to an existing type (presumably you should be allowed to write trait impls for it, and so on), I think it should be extern struct rather than extern type.

What does size_of/align_of return for extern types?

@petrochenkov it's a DST, you mean {size,align}_of_val? Those shouldn't work either, see https://github.com/rust-lang/rfcs/pull/1524#issuecomment-273542116.

Oh, right, size_of_val.
What do you mean "shouldn't work", report an error during monomorphization?
size_of_val is usable unconditionally, so it can be used with type parameters that can become extern types later.

@petrochenkov I think will need to change https://github.com/rust-lang/rfcs/pull/1524#issuecomment-273542116

@glaebhoerl
It's sort of like a "truely" abstract type, so I think extern type is OK.

But it's a nominal type that's knowably disjoint from all other types, isn't it?

I think the fact that it is called a "struct" in C tips me over the fence into @glaebhoerl's camp. Yes, this is used as a hack around not having real abstract types in C (and there should be a way to make the size of a concrete struct with private fields abstract in Rust!), but I'm OK with skeuomorphisms for FFI.

I may be a struct in C, or it may be a union, or it may be just a malloc-ated storage.

presumably you should be allowed to write trait impls for it, and so on

I wonder why would you need to do such a thing.
Extern type refers to some type on C side, you don't know anything about it, what traits can you possibly implement?

Thanks @Ericson2314 for some much-needed extra material.

Given that this is declaring a new type and not an alias to an existing type (presumably you should be allowed to write trait impls for it, and so on), I think it should be extern struct rather than extern type.

The fact they can only appear in extern blocks (where things already look wierd), and that they don't have = Something after them should help prevent them from being confused with type aliases. Besides, in some sense they are a type alias - they're an alias to some type in an external library.
I'd feel a little weird calling them structs when the type might not actually be a struct. That feels like a bit of a C-anachronism.

Extern type refers to some type on C side, you don't know anything about it, what traits can you possibly implement?

There's a lot of object-oriented C APIs that work with pointers to some opaque type. You could wrap these APIs and expose safe versions of the C functions as methods on the extern type.

I'd feel a little weird calling them structs when the type might not actually be a struct. That feels like a bit of a C-anachronism.

I think it'd be fine to just allow struct, enum, and union interchangeably fwiw.
I feel that the difference between whether it's an alias or a fresh type is much more significant than what variety of fresh type it is (especially given that the representation is hidden so that the difference is academic). type is pretty well entrenched as denoting an alias in Rust. Yes, this is an "alias to an external type" in some sense, but it's not an alias from the perspective of Rust's actual in-language semantics which is what really matters, given that it's what the Rust programmer will be dealing with.

I really want a feature like this but have a couple of concerns about the semantics of this proposal:

Personally, I wouldn't call these DSTs (dynamically sized). I'd call them unsized types. That's why we have to be careful about size_of_val and friends.
They're not really extern. Unlike every other extern item, the name doesn't matter: they don't necessarily refer to some existing external item.
They're useful beyond externally defined structures. For example, CStr should be defined as an unsized type (&CStr should be a thin pointer) but is currently a DST.

An alternative is to drop the extern part and allow type MyType;:

type A = B; means there exists a type A that is equivalent to type B.
type A; means there is a type A that isn't equivalent to anything. It's not a struct, enum, union, etc. Just a  type, no defined structure.

Posted separately to allow separate reactions (I like this alternative more then the proposal but I'm not entirely sure about it).

The main issue I see with type A; is that it doesn't indicate explicitly that it is a FFI-compatible type or not. #[repr(C)] type A; or extern { type A; } makes it clear that it is FFI-compatible. I guess #[repr(C)] type A; is more consistent with #[repr(C)] struct A { ... } so I suggest going with that.
type A; makes the most sense of all alternatives proposed above. Using struct A; to refer to a type defined as a non-struct type in C would be confusing to newcomers, and distracting to the pedantic (e.g. me). Allowing all of enum, union, and struct means that we'd potentially need to add more such options for non-C languages (class for C++, for example, or a Haskell tuple type) or be at risk of the same kind of confusion when interfacing with non-C languages.
The RFC should be updated to specifically mention that references to such types are allowed. It should also mention that moves from these types are not allowed.

I guess #[repr(C)] type A; is more consistent with #[repr(C)] struct A { ... } so I suggest going with that.

type A; wouldn't have a defined representation so repr wouldn't really make sense. Instead of passing an A across FFI boundaries, you'd pass a *mut|const A (which is repr(C)).

Instead of provide a way to create opaque types, an alternative would be to just offer one distinguished type (core::marker::OpaqueData or something like that). Then, to create new opaque types, you could just declare a struct with a member of type OpaqueData. This has the advantage of introducing no new syntax, and issues like FFI-compatibility would fall out of existing rules.

There are many possibilities regarding syntax. I suggest that we just ask the language team to do a straw poll on the syntax, so that we can make progress from there. IMO, any syntax proposed so far is better than the current alternatives we have (that I know of).

I think this should be done as a part of the custom DST work.
Until then, the sanctioned solution is:
#[repr(C)]
pub struct Opaque([u8; 0]);

I think this should be done as a part of the custom DST work.

Why?

Instead of provide a way to create opaque types, an alternative would be to just offer one distinguished type (core::marker::OpaqueData or something like that). Then, to create new opaque types, you could just declare a struct with a member of type OpaqueData. This has the advantage of introducing no new syntax, and issues like FFI-compatibility would fall out of existing rules.

I think you may also need #[repr(C)] and/or #[repr(transparent)] for the wrapper type. Maybe those could be implicit, but IMO it would cloud people's understanding of when #[repr(transparent)] is needed and when it is not.

Thanks, @canndrew, for this well-written RFC!
I'm personally in favor of providing this functionality by some means. I do agree with @Stebalien's comment though: the use of extern here doesn't quite feel like a perfect match, since the name is insignificant. On the other hand, I think it's going to be a common idiom (and good practice) to generate some form of newtype for different uses of void *, to try to provide greater type safety -- and the approach proposed here makes that particularly ergonomic.
In the interest of moving discussion along: is there anyone who objects to having some means of expressing a type like this?

I think there's no real reason this pattern couldn't just be expressed as a ZST struct with a private field (mod extern_types { pub struct MyExternType(()); }), except that the improper_ctypes_lint improperly warns about it, which we should just fix! (We should fix it either way.) But there's also no harm in having special support for it with this proposed feature, to make it slightly nicer.

According to the safety rules in the book, in the reference and in the nomicon the conversion of () into any zero-sized type is considered safe. This means that it is always possible to create instances of zero-sized types even if they have private fields.

I think there's no real reason this pattern couldn't just be expressed as a ZST struct with a private field

You can move a zero-sized type out of a Box, for example. The types proposed here would unsized, so they would not be allowed at all inline on the stack.

@ranma42 Using an unsafe transmute(), yes, but that's not really what we're trying to guard against here.
@SimonSapin I'm... not sure that's a real issue? I was going to say, "accessing a zero-sized type is a no-op, so no harm, no foul on that front, but improperly freeing a Box is a problem", but the Box would be freed anyway when it gets dropped, so that would need to work correctly either way (which I'm not sure if it can?). And the moving of the ZST itself is, again, a no-op, so moving out of the Box is just the same thing as dropping it.

@briansmith

I think this should be done as a part of the custom DST work.
Why?

I think a "zero-sized" extern type is of insufficient advantage over a zero-sized struct. OTOH, I think that "custom" DSTs and opaque types mesh quite well together - for example, if we get unsized library C strings, they would also be a sort of an "opaque", non-ADT type.
@ranma42
That only means that creating values of ZSTs is not immediately UB.arbitrarily. There are many things you can do from unsafe code (e.g. fancy mmap games) that are not UB by themselves but can end up being quite confusing - there's a reason it's called unsafe.

@glaebhoerl I disagree on that point. I would love if the Rust compiler  prevented me from incorrectly creating an (invalid) instance of an external type.
Note that it would be safe to perform that transmute. In particular, the following function definition (with no unsafe modifier) is legitimate according to the current unsafety rules :
pub fn new_extern() -> my_extern_types::MyExternType {
    unsafe { std::mem::transmute(()) }
}

AFAICT the ZST approach would make it impossible to wrap a C API in a safe Rust interface, because the type system would be unable to distinguish the "good" values (created by the C API+wrapper) from "bad" values (created by transmuting).
As an alternative, we could say that new_zst is wrong, but in order to forbid it we would have to change the safety rules (for example by requiring that producing invalid values should not happen in general, not only for primitive values).

@ranma42
That's hardly the worst thing you can do with transmute.

@arielb1 Are there other transmute usage patterns that would result in programs that are safe (according to the rules) to perform bad memory accesses or otherwise result in undefined behaviour?
If this is the case we might want to keep track of the known ones and revisit the safety rules (this might better happen in another RFC, though).
(I skimmed through the open issues about transmute. I found https://github.com/rust-lang/rust/pull/34198 and https://github.com/rust-lang/rust/issues/29702, but neither of them seems to indicate that new_extern is considered "bad")

@ranma42 I'm not sure I understand. new_extern uses an unsafe block to do something that cannot be done. How is that any different than if it created a null &i32?

@sfackler Why is new_extern doing something that cannot be done? It looks like it is not infringing any of the safety rules.

@sfackler
A null &i32 would be instant UB. A more interesting example would be an &i32 that points to some unexpected place.

@ranma42 "should not" is more accurate than "cannot", sorry.

https://internals.rust-lang.org/t/pre-rfc-opaque-structs/4005 is my earlier approach to this problem, and it proposes an alternate syntax which could be used - namely a new lang item, and the corresponding struct in core, which has the property of being unsized, and can be used to make structs unsized.
I feel like something like that should at least be mentioned in the alternatives section of this RFC.

@glaebhoerl woah woah woah, the RFC tries to lay out why and 0-isomorphic, 1-isomorphic or un-statically-sized types with dynamically-known size are all a bad fit for this. The main point of this RFC is new semantics.

@mystor that's a fine alternative and I'd be fine adding. I suspect that what is written here will be better in conjunction with custom DSTs---in which case there are infinite possible metas so trying to pick them off with magic lang-item types is kind of indirect.

Like @arielb1, my first thought reading this RFC was that it was a decent fit for the custom DST work, though that is also an awfully big hammer for a relatively little problem.
Like @glaebhoerl, I feel a bit confused. Are these meant to be newtypes? It seems like they are, right?
That said, you can start to see some problems arising where the custom DST machinery might come into play:

As a DST, size_of and align_of do not work, but we must also be careful that size_of_val and align_of_val do not work either, as there is not necessarily a way at run-time to get the size of extern types either. For an initial implementation, those methods can just panic, but before this is stabilized there should be some trait bound or similar on them that prevents their use statically.

I don't know how I feel about having a trait bound for this case, which feels pretty obscure, though I certainly see the appeal.
(If these were defined as a custom DST, then certainly users could define the size_of_val methods to just panic on their own. (Presumably one might use a macro to declare said types.)

(If these were defined as a custom DST, then certainly users could define the size_of_val methods to just panic on their own. (Presumably one might use a macro to declare said types.)

That would be unfortunate. The idea behind statically-typed languages is to allow the compiler to reject using types in contexts for which they don't make sense. Applying that principle here means that attempting size_of_val and such on these types should be rejected statically by the compiler. Also, generally, we should discourage the use of panic!.

@Ericson2314 I would also mention the impl !Sized solution as well (something like custom DSTs). The reason why I didn't suggest that originally, and instead suggested the lang item, was that it wouldn't lock down the DST syntax at all, otherwise I would just say we do something like:
impl !Sized for Foo {
    fn size_of_val(&self) -> usize { panic!() }
    fn align_of_val(&self) -> usize { panic!() }
}

Where we could theoretically add a type Meta which is defaulted to () to the !Sized nega-trait when we need it for custom DSTs.
@briansmith I agree that panic!() in size_of_val would be pretty awful and hacky, but I'm not sure what the best way to get around the stableness of size_of_val would be without suddenly requiring functions which would accept one of these opaque types to add a T: !DynSized bound. Theoretically we could do something similar to what happens with mem::transmute where calling it fails at monomorphizaion time, but that seems kinda gross :-/ and doesn't handle trait objects made from these unsized types well.

Theoretically we could do something similar to what happens with mem::transmute where calling it fails at monomorphizaion time, but that seems kinda gross :-/

This has not been the case for several versions now - transmute nowadays only allows types with known size or pointers that have the same potentially-unsized "tail" (a type parameter or an associated type).

@nikomatsakis

My first thought reading this RFC was that it was a decent fit for the custom DST work.

This is true. I don't regret this RFC existing on its own for the moment though. If I my say so as the author of the "How We Teach This" section :), this on its own, unlike with custom DSTs in general, specifically relates to existing 2017 priorities of teaching and FFI. The status quo has the trifecta of lousy syntax, lousy semantics, and lousy pedagogy.

Are these meant to be nominal types?

Yes. Nobody disagrees on that semantics at least.

I don't know how I feel about having a trait bound for this case, which feels pretty obscure, though I certainly see the appeal.

https://github.com/rust-lang/rfcs/pull/1524#issuecomment-273542116 I try to layout more usecases for having another trait (DynSized) in the hierarchy.

(If these were defined as a custom DST, then certainly users could define the size_of_val methods to just panic on their own. (Presumably one might use a macro to declare said types.)

Yes, I am thinking that we have some syntax for opaque, and then the user can either derive Referent<Meta=()> for this use-case, or manually implement it for the use-cases in the custom DST RFC. To be clear, this derive-or-manually-implement route is a viable option whether or not we introduce a DynSized trait or rely on panicking.

@mystor If I am understanding you, your idea is basically the opposite of what I just said? The magic lang-item type in core allows us to move on this now, but also turn the lang-item type into a normal definition if/when custom DST is implemented and the traits fleshed out? Hmm, Sounds compelling :)!

@Ericson2314 Yup, pretty much. The idea would be that right now it's implemented as, say:
/// WARNING: Bikeshed syntax ahead
#[lang = "thin_unsized_type"]
pub struct ThinUnsized;

But in the future that lang item could be removed and replaced with:
/// WARNING: Even more bikeshed syntax ahead
pub struct ThinUnsized;
impl !Sized for ThinUnsized {
    // However DSTs work... Who even knows.
}

However, all downstream consumers could continue using it without having to worry about the change, just as they had before, by writing:
#[repr(C)] // Should this be used? Who knows! It probably makes very little difference.
struct MyExternStruct(ThinUnsized);

I really like @mystor's suggestion of a std::Opaque.  Reading or typing struct Foo(Opaque); is approximately as clear/easy as any of the other options, yet it has the huge advantage being just the same old "I wanted something structurally-the-same but nominally-different, so I used a newtype".

#[repr(C)] // Should this be used? Who knows! It probably makes very little difference.
struct MyExternStruct(Opaque);

Unless there's a special rule for the Opaque type, you would either need #[repr(C)] or #[repr(transparent)]. Otherwise we wouldn't need #[repr(transparent)] in the first place. In particular, I assume the Rust compiler reserves the right to do anything it wants, including inserting hidden padding or hidden members that it reads and writes before the first element of a struct that is #[repr(Rust)], and everything is ``#[repr(Rust)]` by default.

@briansmith Given that Rust can't look into a value of such a type, does it even matter what the repr is?  Maybe this is "a special rule for the Opaque type", but it feels like any pointer-to-UST (as opposed to pointer-to-DST) is automatically anything-compatible, since Rust can't use it as anything other than an address.

Given that Rust can't look into a value of such a type,

Consider struct MyExternStruct(Opaque); Since it is #[repr(Rust)], the Rust compiler is free to treat it as struct MyExternStruct { hidden_member: WhateverType, value: Opaque }. That is, it can't into Opaque part, but it can look into, and change, any such wrapper, unless the wrapper has a non-Rust representation.

@briansmith is right. But I suppose either of those reprs will suffice?

I think "unsized types" are useful outside of FFI too, and so I wouldn't want to conflate them with "extern" necessarily...

@Ericson2314 woah woah woah woah, I read the RFC and apparently it didn't make me see the semantic need for the feature. :) Can you provide some examples of where the "private ZST" approach leads to actual problems (like, bugs)?
My theory continues to be (as I find myself repeating in every comment), that any operation on a ZST is a no-op, that is: it may look like the typechecker lets you write various operations involving the type, but in reality, those operations do not exist. They don't do anything. There is no observable semantic difference between (a) not writing an operation, and (b) writing an operation that doesn't do anything. It may be preferable on aesthetic grounds if the typechecker did not let you write the operations which do nothing, but on semantic grounds, the two are equivalent.
The potential exceptions to this, that is size_of and friends, are also the ones which can't be solved simply and cleanly (requiring either more invasive type system changes or panics). So, I think the only motivation for this RFC is aesthetics and ergonomics.
But again: I think aesthetics and ergonomics are a fine motivation.

If we do add some formulation of this, I would really strongly prefer some variant on the original formulation where you can declare an external type (whether type or struct/enum/union) inside of an extern block, together with the external functions which operate on it.
That is:
extern {
    struct Foo;
    fn make_a_foo() -> *mut Foo;
    fn frobble_a_foo(foo: *mut Foo, frob: u8);
    fn free_a_foo(foo: *mut Foo);
}

This has the advantage of making the "intuitively obvious" way to do it coincide with the correct way to do it. That is, the thing you would "naturally expect to be able to do" is actually a thing you can do! This makes the language feel simpler and easier. That has real value! (See also: the principle of least surprise.) Replacing the current non-obvious but correct way to do it with a different and slightly shorter non-obvious but correct way to do it also has value, but not as much.

@glaebhoerl Ok, that makes sense :). I guess I'm more worried about generic code: fn deref_and_store<T>(*const T) -> Vec<T> for example will be, yes, harmless, but not free (its a counter).
I am hoping that between all the uses DynSized (https://github.com/rust-lang/rfcs/pull/1524#issuecomment-273542116, I just edited in another), the deeper hierarchy is worth it.

I've added @gereeter's OpaqueData suggestion to the RFC as an alternative.

When I suggested in the internals thread the extern type, I really meant that the user will be able to write:
extern {
    type Foo; // or really any other syntax that denotes "I declare the existence of Foo"
    fn make_a_foo() -> *mut Foo;
    fn frobble_a_foo(foo: *mut Foo, frob: u8);
    fn free_a_foo(foo: *mut Foo);
}

That is, the user here intends to use an opaque type, not define it.
In C parlance:
struct Foo; is a Declaration, it denotes "there exists a struct Foo" vs.  struct Foo {...} which is a Definition of the struct Foo.
Rust doesn't have a language construct for the former since struct Foo; denotes "here's a Definition of a concrete struct type Foo, it has zero fields".
This language addition aligns with Rust's goal of improving ergonomics for the 2017 roadmap.

One thing I think may be worth noting is that if this RFC were accepted, it would provide all the machinery needed for (the semantic portions of) RFC 996, which is potentially of value for JITs, dlopen(), and various other use cases.

One thing I think may be worth noting is that if this RFC were accepted, it would provide all the machinery needed for (the semantic portions of) RFC 996, which is potentially of value for JITs, dlopen(), and various other use cases.

I would hope that there would be a distinction between extern data types and extern function types, such that extern data types and extern function types are mutually exclusive, so I think additional work would still be needed.

briansmith: Note "machinery needed for" - the underlying "sticking point" making that RFC inexpressible in Rust was in fact the lack of "incomplete" types, which this would resolve. From there, one could implement the rest in a crate.

From there, one could implement the rest (short of the syntax) in a crate.

Maybe we're talking past each other, but I would expect an extern type T to be guaranteed to not be a function pointer, just like struct T; is guaranteed to not point to a function in C.

@briansmith

Maybe we're talking past each other, but I would expect an extern type T to be guaranteed to not be a function pointer, just like struct T; is guaranteed to not point to a function in C.

Ah, I was not aware of that! (But also slight terminology tweak: It'd be *const T, not T, that would be a function pointer.) For anyone else who may have been in the same position as I was, the C99 standard says:

<IP_ADDRESS>:8 A pointer to a function of one type may be converted to a pointer to a function of another type and back again; the result shall compare equal to the original pointer. If a converted pointer is used to call a function whose type is not compatible with the pointed-to type, the behavior is undefined.

(As this gives no conversions between data pointer types and function pointer types, such conversions are undefined, and thus a pointer to one can't possibly be valid as a pointer to the other.)
The rationale I saw given when I looked was that data and function pointers may not be the same size.
However, Rust is not C, and this should probably fall under the aegis of the Rust unsafe semantics - permitting it may be of value. I've filed an issue raising that question.

Something that occurred to me: right now, for any trait Trait there is a corresponding dynamically-sized type Trait. This is what allows us to write things like Box<Debug> etc.
In theory, we should be able to combine traits and write things like Box<Debug + Display>. This doesn't work at the moment but (I believe) there's plans to make it work. Pointers to these objects will be fatter than normal because they have to contain multiple pointers to vtables (eg. for both Debug and Display). So you'll be able to have trait object pointers that contain 1 vtable, 2 vtables, 3 vtables etc. but not 0 vtables. This seems like an arbitrary restriction (and is yet another example of unfair discrimination against the natural number zero).
Also, when we use a trait as a type there's an implicit Sized bound on the trait. Box<Debug> is actually Box<Debug + Sized> and you can't (currently) have a type like Box<Debug + ?Sized>. This is another unnecessary restriction.
So what if we removed both these restrictions? What would the trait ?Sized (with no other bounds) look like as a type? I say it would just be OpaqueData: some kind of data that we don't even know the size of and whose pointer is just a vanilla pointer because it doesn't have any attached vtables.
Food for thought. I'd still like to have an extern type syntax but we can add OpaqueData just by loosening the rules around trait objects and without adding a new magic lang item.

Would Box<Debug + Display> contain two vtable pointers, rather than a single pointer to a "combined" vtable? Also, IIRC even with no virtual method available the "vtable" contains at least a size so that Box::drop knows how much space to deallocate. (And also an optional pointer to a Drop::drop impl for the boxed value?)

Would Box<Debug + Display> contain two vtable pointers, rather than a single pointer to a "combined" vtable?

That would be another way of implementing it. Although I think I recall someone saying it would be done the way I described.

Also, IIRC even with no virtual method available the "vtable" contains at least a size so that Box::drop knows how much space to deallocate.

You would not be able to box a ?Sized because of this. Just like you shouldn't be able to call size_of_val on one. This would require the extra traits from the custom DST RFCs so that we can talk about types that don't even have a size at runtime.

@canndrew

Also, when we use a trait as a type there's an implicit Sized bound on the trait. Box<Debug> is actually Box<Debug + Sized> and you can't (currently) have a type like Box<Debug + ?Sized>. This is another unnecessary restriction.

I don't believe this restriction is unnecessary. The problem is that if you can convert a fat pointer into a trait, then you wind up not with a "data pointer plus metadata" but rather a "data pointer of unknown size".  Am I missing something here?

@canndrew

What would the trait ?Sized (with no other bounds) look like as a type?

Also, I'm not sure if you're just speaking loosely here, but ?Sized is not a trait. In particular, a T: ?Sized bound is really the absence of a bound, in the sense that (unlike say T: Trait) adding T: ?Sized allows T to refer to a superset of the types it might otherwise have been bound to.

@nikomatsakis I hope Box<Debug + ?Size + Referent<Meta=usize>> would work eventually.

A pointer to an OpaqueData is morally equivalent to using void* in C whereas this RFC talks about a related but different approach that would look like the following in C using declaration of incomplete types:
// in my_header.h
struct Foo;
struct Bar;
Foo* createFoo();
Bar* createBar();
void do_something(Foo* foo, Bar* bar);

// in client.c
#include "my_header.h"
int main() {
    do_something(createFoo(), createBar()); // works
    do_something(createBar(), createFoo()); // doesn't compile
}

Rust lacks the ability to express the same pattern because we lack the syntax to declare existence of an abstract type (Foo & Bar above). While it is also useful to have something equivalent for void* I think that it's a separate (though related) feature.

@nikomatsakis
The way I was imagining this being implemented is how @Ericson2314 is hinting at. That is, right now we store the size in the vtable, but if we wanted to allow multiple vtables and unsized types it might make more sense to store the size directly in the fat pointer. So under this scheme we'd have
// Box<Debug> represented as
struct Repr {
    data_ptr: *mut (),
    sized_metadata: usize,
    debug_metadata: *mut (), // the vtable
}

// Box<Debug + Display> represented as
struct Repr {
    data_ptr: *mut (),
    sized_metadata: usize,
    debug_metadata: *mut (), // the vtable
    display_metadata: *mut (), // the vtable
}

// Box<Debug + ?Sized> represented as
struct Repr {
    data_ptr: *mut (),
    debug_metadata: *mut (), // the vtable
}

// Box<Debug + Display + ?Sized> represented as
struct Repr {
    data_ptr: *mut (),
    debug_metadata: *mut (), // the vtable
    display_metadata: *mut (), // the vtable
}

// Box<?Sized> represented as
struct Repr {
    data_ptr: *mut (),
}

@nikomatsakis

Also, I'm not sure if you're just speaking loosely here, but ...

Yes, that's the way I meant it. We don't have a way of representing the unit/zero trait, ie. the trait which is the identity of the TraitA + TraitB operation. But since all traits have an implicit + Sized on them when being used as types, we can just use Sized to represent the union of all traits in the set { Sized } and ?Sized to represent the union of all traits in the set { }.

@canndrew: Apologies if I'm missing something, but... is all the indirection really even needed?
The sizes of the vtables are all known to the compiler, and which vtables are needed are similarly known. Is there any reason not to model all these reprs more like so?
// Box<Debug + Display > represented as
struct Repr {
    data_ptr: *mut (),
    concatenated_debug_and_display_and_size_metadata: *mut ()
}

That is, the compiler has generated essentially (DebugVTable, DisplayVTable, usize) and points to that? Casting that to a Box<Debug> would just swap the metadata pointer from referring to one spot in .rodata to a different spot in .rodata.

@canndrew

We don't have a way of representing the unit/zero trait, ie. the trait which is the identity of the TraitA + TraitB operation.

Hm, this seems off to me - in particular, + on traits seems to have more in common with set union or bitwise or, as far as I can tell.
Let 0, 1, ..., N be a numbering of all traits in the program, and let trait bounds and objects be represented by a bitfield of length N. A trait bound on or object of trait T, then, would have ones at the trait's index, and the indices of all its supertraits. Applying the + operation to the trait itself, or any of the supertraits it has, is the identity. The lack of a distinguished "zero trait", then, makes perfect sense - as it would be a trait representing the absence of traits, a Gödelian nightmare. Any such syntax would necessarily not be a trait at all.

@eternaleye I would instead interpret the + as an intersection, as it is a way to name a type which needs to satisfy the constraints of each of the two traits.

@ranma42: Hm, I suppose that depends on whether you view the "sets" involved as "sets of eligible types" or "sets of behaviors that can be relied on, given such an object" - I meant the latter, given the context (representing the vtables of trait objects).

@eternaleye

Apologies if I'm missing something, but...

Sure, that would be another way of doing it. You'd either need to duplicate some vtables or have another layer of indirection (eg. a vtable of vtables), but you'd get to make the pointers smaller.

... it would be a trait representing the absence of traits, a state of affairs disturbingly akin to Russel's paradox. Any such syntax would necessarily not be a trait at all.

I don't get this. What's the relation to Russel's paradox? Are you afraid that it could put the compiler into an infinite loop by showing that the type ?Sized satisfies ?Sized? (Or something like that?)

@eternaleye
Passing a Box<A+B+C+D+E+F+G> to Box<A+D+F> is easy when the fat pointer is represented in parallel as (data_ptr, vtable_of_T_for_A, _for_B, ... , _for_G), but not so when you concatenate all the vtables together.
Either you need to determine that combined_vtable_of_T_for_ABCDEFG belongs to type T and then find the corresponding combined_vtable_of_T_for_ADF, or you need to memcpy a new table.
Furthermore, concatenated vtable requires the ABI to establish an order of the traits if we want to treat Box<P+Q> and Box<Q+P> the same type.

@canndrew perhaps I am just being dense, but I still don't get how you could convert a value of unsized type into an object. Walk me through it a bit more. Imagine I have -- say -- a &'a [T] and I want to produce a &'a (Debug + ?Sized), say (presume T: Debug). The Self type of this new object would be [T], so we have to carry the length somewhere. But unless we want &(Debug + ?Sized) to itself be ?Sized, then I still don't quite get where it's supposed to go. It can't live behind the data pointer, since the data pointer for the &(Debug+?Sized) and the data pointer for the &[T] must be the same (in particular, a *const T) -- or else you couldn't assign the fat pointer the same lifetime of 'a. Hence it has to go in the fat pointer auxiliary somewhere.

I think some of the confusion is caused by the little practical difference between reprs for statically-sized and dynamically-sized types when the type in question is itself dynamic (existentially quantified). In either case the dynamism of the type means we must keep track of the size (or the meta which allows recovering the size). Only with truly unsized types can we forget about the size altogether.
If we want to forget the length of the array in a trait object we need to do &[...]: &(Trait + ?DynSized) I don't see a way to express this trait object without the DynSized trait existing (to opt out of).

@nikomatsakis
Sorry you're right, I'm being dense and I didn't understand what you were getting at. Yes, the pointer to the trait object would also need to contain the metadata for the pointer to the underlying object so that it can reconstruct it for calling &self methods . But that means we can't know the size of the trait object pointer because (eg.) different implementors of Debug may have different pointer metadata (they may be sized with Meta=(), unsized with Meta=usize, or a 2d array of pixels or something with Meta=(usize, usize)).

Are associated constants object safe today? Then we have the following pleasant scenario:

Size is an associated constant in Sized
Single-field vtables (or vtables otherwise deemed sufficiently small) can be inlined into the fat pointer
The size field in trait objects today is simply the inlined Sized vtable.

@Ericson2314 That's an interesting topic on its own. How do we extract the associated constant from the trait object? Neither trait_object::SIZE nor trait_object.SIZE doesn't quite make sense. If you cannot extract associated constant from trait object then putting them into the vtable is a waste.

@kennytm <typeof(trait_object) as Sized>::SIZE is probably wanted by some people. I might prefer explicit vtables trait_object.get_vtable::<Sized>().SIZE. With proper existentials, we can also make method pointers usable in that way. (Using a magic get method allows for my inlining trick to work, though associated fields with dereference and type parameters would also suffice.)

The RFC should be updated to specifically mention that references to such types are allowed. It should also mention that moves from these types are not allowed.

Why hasn't the RFC been updated with this? This is an extremely important detail that is essential in order for me to support this RFC.

@retep998 probably no-one has gotten around to it. Certainly both of those were intended from the beginning, and neither are controversial (IIRC), so this is just an oversight of leaving something less explicit than it should be.

@canndrew Do you think you'd be able to update the RFC with some of the latest comments?

Sorry, I've been distracted lately. I've updated it with some of the comments.

I'm curious what folks see as the primary downsides of simply introducing a single new type, std::mem::OpaqueData, mentioned in the alternatives section. That seems like a much more conservative change, but is equally expressive. I feel like constructing newtypes is a very well-established pattern, and I'm not sure that doing it automatically through extern type is actually a win in terms of ergonomics or learnability.
Put more strongly: I would be happy to head toward FCP on such a conservative RFC. I'll note that it's easily forward-compatible with the current RFC.

I'm curious what folks see as the primary downsides of simply introducing a single new type, std::mem::OpaqueData.

What would the declaration of std::mem::OpaqueData be? Every tool that processes Rust code would potentially need to know how to handle its declaration.
Also, it would have to be core::mem::OpaqueData for #![no_std] use.

I don't particularly object to core::mem::OpaqueData as long as it is an unsized type that forbids mem::replace and is safe to have pointers/references to, while attempting to have a value of it would result in a compile error.

I can write up an RFC for the minimal version based on OpaqueData as I already have a partially complete one from before this RFC. There are still a couple of questions related to it but we should probably discuss them in a separate thread.
I'll try to have it up by the end of the week.

@briansmith It'd be a lang item, just like other primitive types. I suspect the burden on tooling here is much less than with the full-blown extern type feature.

@mystor Sounds great to me!

@aturon that's fine with me.
I think that just leaves the question of should {align,size}_of_val panic, or should we have theDynSized opt-out marker trait, required to use those functions, which OpaqueData and types containing it alone wouldn't implement.

Also, I would like to be able to have OpaqueData as the last field of a struct, thus transferring its properties to that struct, but still allowing access to the fields before it.

@aturon
I'm not sure how would this be easier than an extern type. The primary concerns are the size_of_val story and how this meshes with custom DSTs.

@arielb1 I'm trying to push back on @briansmith's argument that OpaqueData will be difficult for tooling. I think it will be strictly easier than extern type for e.g. IDEs to deal with (no new syntax or forms of type definition, etc).

I think that just leaves the question of should {align,size}_of_val panic

Probably I'm misunderstanding you, but IMO it would be terrible to have those functions panic, especially when the information to avoid the panic is available at compile time.

@arielb1 I'm trying to push back on @briansmith's argument that OpaqueData will be difficult for tooling.

Just to clarify, I did not say that it would be difficult for tooling. It's important to know the definition of OpaqueData to evaluate the proposal to know whether or not it would be difficult for tooling.

@briansmith Let me try to make my point a different way. Whether we expose this concept via OpaqueData or extern type, tooling will have to treat the resulting types in exactly the same way, i.e. with built-in knowledge about how they behave. In addition, with extern type tooling needs to support additional syntax and kinds of type definitions.

The main thing I wanted to know is whether it would be a lang item or a type alias to some (unspecified) type. That was answered already. I agree that defining it as a lang item isn't problematic, AFAICT.

@briansmith In the new RFC which I am working on I plan to implement it as a lang item.

I'm curious what folks see as the primary downsides of simply introducing a single new type, std::mem::OpaqueData, mentioned in the alternatives section. That seems like a much more conservative change, but is equally expressive.

Basically, I think there's two issues here we might potentially care about: correctness (safety) and UX (learnability, ergonomics, intuitiveness etc.).
If we only care about correctness, then we don't need to do anything, because the current approach of using a ZST already works perfectly well and no actual deficiencies have surfaced in the course of the discussion. We should just fix the improper improper_ctypes lint against it, the currently correct pattern, (which is just silly!), and call it a day.
While if the motivation is UX, I think OpaqueData would only be a minor improvement and extern type would be a much bigger improvement, and if we care enough to do something we should go for the bigger improvement.

I feel like constructing newtypes is a very well-established pattern, and I'm not sure that doing it automatically through extern type is actually a win in terms of ergonomics or learnability.

...but it seems you feel differently, which is interesting. I wonder to what extent we can surface and unpack the "why" regarding our different intuitions here?
I think what's beneath it in my case is that for functions, the way to do FFI is:

You write some C functions in your C file
You put an extern { ... } block in your Rust file
You write the signatures of the C functions (without their bodies) in the extern block, transliterated to Rust types and syntax.

So I would "naively expect" the process for types to be likewise:

You write some C types in your C file
You have an extern { ... } block in your Rust file
You write the "signatures" of the C types (without their bodies) in the extern block, transliterated to Rust syntax.

So everything from the C header can just be transliterated together into the extern block with the same structure and grouping.

@briansmith I personally agree completely, but I've never gotten much enthusiasm for DynSized here or the custom DST thread, and I don't want that to take down the rest of this proposal.

(A bit of anecdata I forgot to put in my previous comment: before this RFC I had semi-frequently seen people independently requesting an extern type feature, out of a belief that there was no correct way to do it at present (most likely fueled by the improper improper_ctypes lint), and thought it was misguided given that ZSTs do actually work correctly. I haven't seen anybody bring up the idea of OpaqueData before this thread. This is also part of what leads me to believe that extern type is what people "expect" to work on some level.)

@glaebhoerl I don't understand what you mean. Consider, in C, struct BIGNUM;. In code that has access to just that declaration, I cannot instantiate a value of BIGNUM and the compiler statically rejects things like sizeof(BIGNUM) from such code. How do you get the same effects with ZSTs?

I think "ZST"s in this thread actually mean the empty type i.e. enum Void {}?

@briansmith Instantiation is prevented by using a private field. I agree that it doesn't solve sizeof, but sizeof is the hardest problem to solve and I think it's equally hard to solve no matter which approach we go with (i.e., it's kind of orthogonal to whether we go with extern type or OpaqueData or whatever). (It's also not directly a safety issue.)
@kennytm No, they mean the unit type. Except with a private constructor (by having a private field). I was referring to them as simply "ZSTs" because I thought the approach was known and packing every bit of nuance into every sentence quickly makes the actual point unintelligible.

@kennytm The empty type is kinda annoying because it doesn't prevent you from working with it by value, it just makes it undefined behavior. What we need is a type that statically prevents the programmer from making such mistakes at compile time,

@aturon and co. I've filed a new RFC focused on the Opaque struct idea in #1993.

@glaebhoerl Thanks much for your recent comment, which brought back to the fore the UX issues at play here. I was succumbing to a kind of argument that I usually try to push back on!
In particular, we have a situation here where:

There are some underlying mechanisms we could introduce that, used together, achieve the desired goal (namely, OpaqueData plus using the newtype pattern). That would be the minimal expansion of the language surface, and the interactions with the rest of the language are well understood. It's very easy to get attracted to seeming minimality and orthogonality.

Providing this feature through extern type provides a much better overall UX; it's more neatly targeted at one of the primary use-cases, and makes it easier to get things right by following your intuition. The (seeming) downside is that it couples two more basic mechanisms together, so feels less minimal. But there's a key point: precisely because it has such a decomposition, it doesn't introduce meaningful new complexity to the language beyond the OpaqueData solution. (And in fact, we could introduce OpaqueData as well and simply desugar extern type internally to use it).

This kind of design -- thinking in terms of well-behaved and orthogonal underlying mechanisms, but giving higher level, more sugary "workflow" based on those mechanisms -- is an approach we think about a lot on the lang team, and are striving to do more of. I often think of closures in this way, for example. I think it'd be good to try to write up these principles in a more general way, sort of like the ergonomics initiative post...
Anyway, I'm now pretty well convinced that offering extern type has significant upsides and little downside; it's also not mutually exclusive with https://github.com/rust-lang/rfcs/pull/1993, which we could also add (again, at essentially zero semantic cost, since it would just be part of the desugaring for extern type). But for now, I propose we try to reach a resolution on this RFC, and consider OpaqueData separately.
@rfcbot fcp merge

@aturon I agree with your analysis, namely that the extern type syntax is more ergonomic, easier to teach, and adds minimal additional language complexity over OpaqueData.
However, I don't think a consensus as to the semantics of an extern type has been reached. We still have the problems from my OpaqueData rfc of deciding what should happen when size_of_value or align_of_value is called on one of these types.
When you suggest to merge this RFC as written, what semantics for those functions are you expecting?

@aturon I agree with your analysis, namely that the extern type syntax is more ergonomic, easier to teach, and adds minimal additional language complexity over OpaqueData.
However, I don't think a consensus as to the semantics of an extern type has been reached. We still have the problems from my OpaqueData rfc of deciding what should happen when size_of_value or align_of_value is called on one of these types.
When you suggest to merge this RFC as written, what semantics for those functions are you expecting?

@mystor
The RFC as written says:

As a DST, size_of and align_of do not work, but we must also be careful that size_of_val and align_of_val do not work either, as there is not necessarily a way at run-time to get the size of extern types either. For an initial implementation, those methods can just panic, but before this is stabilized there should be some trait bound or similar on them that prevents their use statically. The exact mechanism is more the domain of the custom DST RFC, RFC 1524, and so figuring that mechanism out will be delegated to it.

So presumably this is the semantics @aturon has in mind (?)

If that is the semantics we're going with, I would like to point out that #1524 is no longer an open RFC, and we should probably make that decision somewhere else. We could do it in #1993, as that is what most of the text is about, or perhaps a new RFC (if we decide to just close #1993 in favor of this RFC).

While I agree that an initial implementation of this could just panic on size_of/align_of, I think that the exact mechanism for statically preventing size_of/align_of from being used on extern types needs to be part of the RFC. Panicking is really a terrible option and so we need to make sure we know that there is a viable alternative. The only way we'll really know there is a viable solution is by agreeing on what that solution is. And, agreeing on that solution might teach us something about extern type that we didn't know before.

While I agree that an initial implementation of this could just panic on size_of/align_of, I think that the exact mechanism for statically preventing size_of/align_of from being used on extern types needs to be part of the RFC. Panicking is really a terrible option and so we need to make sure we know that there is a viable alternative. The only way we'll really know there is a viable solution is by agreeing on what that solution is. And, agreeing on that solution might teach us something about extern type that we didn't know before.

I agree (although preventing size_of and align_of is quite easy, just don't implement Sized for extern types - the problem is size_of_val and align_of_val). I think that figuring out how this will be represented and handled statically is quite important.

@rfcbot concern size_of_val
I agree we need to know the resolution of this static determination question. It seems this involves a new auto trait like Send or a new built-in trait like Sized. The cost of adding that is not small at all, and I'd like to have a plan to minimize those costs - e.g. users not using extern types should not need to learn about this trait.

I definitely vote for the DynSized solution. @mystor wrote it up beautifully, and that language fit's here verbatim.

Hmm, I'm definitely on the fence about DynSized. I see the point, and it may well be inevitable, but I am reluctant to introduce another split like sized into the world of types. panic! on size_of definitely feels pretty unclean though -- but I guess the question is how often we expect people to run afoul of it in practice. That seems kind of hard to answer in the abstract to me though.

I'm not sure whether I think this should block this RFC though -- I tend to think it's ok for this RFC to leave this question "open", but I do think we would want to resolve this before we stabilize. Basically, this feels like an orthogonal concern, and I think that we've found that it's better to let "interconnected" RFCs go forward independently, but block more around stabilization time, since that lets us explore the interactions more easily. To that end, I'm going to check my name off, despite having concerns similar to @withoutboats.

Would we implement initially with size_of_val and align_of_val == panic? That is the least invasive option for implementing for sure, but I'm worried about it not being compatible with existing unsafe code in the ecosystem which expects size_of_val and align_of_val not to panic.

What if we made them return 0? Can someone give a concrete example of how that might lead to a bug?
(My apologies if there's already been one!)

I'm imagining some sort of weird code like this? (This is a totally fabricated example, of course).
fn move_into_arena<T: ?Sized>(arena: &mut Arena, b: Box<T>) -> &T {
    let size = mem::size_of_val(&*b);
    let align = mem::align_of_val(&*b);
    unsafe {
        let ptr: *mut u8 = arena.raw_allocate(size, align);
        ptr::copy_nonoverlapping(&*b as *const T as *const u8, ptr, size);
        drop(mem::transmute::<Box<T>, Box<NoDrop<T>>>());
        &*ptr
    }
}

You'd suddenly have a pointer to random memory, as raw_allocate would allocate no bytes.

Box is already incompatible with such a type - allocation & deallocation are noops.

@eddyb Box is be incompatible in principle, but without DynSized what's going to prevent instantiating that function?
Many may not like more traits, but might this game of chicken with footguns in itself be less user friendly? With DynSized, the situation is obviously sound, and the errors up front. Without... I don't see how we avoid problems with unsafe code but even if we do it will be for very subtle reasons.
Also, while I've mentioned this many times on IRC I don't see it in this thread, @mystor's, or either RFC: the Sized-DynSized relationship exactly mirrors the Copy-Clone relationship. This makes the former easier to teach to existing users, and for new users post-dating adoption of this RFC, both would reinforce each other establishing the pattern.

You have to use the unsafe Box::from_raw to call that function but I agree it's a footgun.

It looks like everyone signed off on this, except for the size_of_val concern. Are people ok with @nikomatsakis's proposal to punt on this until stabilization?

@jethrogb Agreed, I think starting with a panic for now and gaining experience is the right way forward.
Due to issues with the bot, I'm going to cancel and restart the motion to FCP.
@rfcbot fcp cancel

@rfcbot fcp merge

@withoutboats, I checked off your box despite your earlier concern, since you're currently on vacation. I feel confident you'll agree that we can move this issue to block stabilization rather than the RFC.

Is the bot broken? It's been more than a week.

Nevermind it seems the period is actually 10 days

In Rust, pointers to DSTs carry metadata about the object being pointed to. For strings and slices this is the length of the buffer, for trait objects this is the object's vtable. For extern types the metadata is simply (). This means that a pointer to an extern type is identical to a raw pointer.

Saying that it is not 'fat pointer' is more clear for me.

@aturon So we're sweet to merge this baby yeah?

Huzzah! This RFC has been merged! Tracking issue.


Return date before start date

data = pdr.get_data_yahoo('A', actions='only', start='2017-04-01', end='2017-05-31') #actions only
Result:
[100%**]  1 of 1 downloaded
Date    value    action
2017-03-31  0.132  DIVIDEND
Why did I get 31 March 2017 if start Date is in April 2017?
Thank you once more! (is never enought :))

That's a question for Yahoo I guess. lol

Should I filter on my side?
Thanks

I've created a function to validate the dataframe, just in case anyone needs it, follows below:
def validatedataframe(start,df,logfile):
try:
for index, row in df.iterrows():
if left(str(index),10) < left(str(start),10):
logfile.write("Index removed " + left(str(index),10) + " for being earlier to " + left(str(start),10),1)
f.drop(index, inplace=True)
except Exception as err:
print("Error: " + inspect.stack()[0][3] + ": Validate Function Failed - " + str(err),0)
return df;
return df;


Use doccoms from signature and implementation files for quickinfo tooltips

The current way that documentation comments behave with quickinfo tooltips is rather odd and has been a pet peeve of mine for a long time.

When you add doccoms in the signature they don't show up in the corresponding implementation
If you open a different implementation file it uses the doccoms from the sig and overwrites any doccoms you may have added in the implementation file
Now it shows doccoms from the sig in its corresponding implementation file, and if you add additional doccoms in the implementation the tooltip will show both of them.

The doccoms from the implementation files are on the bottom because these are merely supplementary and will not be included in the xml documentation created for the project.

Awesome. What about showing a warning of some sort if documentation in sig and implementation files differ (and a quick fix to synchronize them in either way ;) ?

The doccoms in the implementation files are more like "design time" notes, things you want to show up in other implementer's tooltips but prefer not to expose publicly like the doccoms in the signature file.
I don't think synchronization adds anything useful as the doccoms from the signature will always show in the tooltips. If anything you'd want to delete the doccoms in the implementation file. Making them the same would just duplicate the content.

@cloudRoutine An alternative is to fix this within the compiler itself, so that the specification of documentation generation changes to combine documentation from signature and implementation. If implementation documentation is empty then it is uncontroversial to use signature documentation. However frequently documentation is duplicated in signature and implementation, which raises questions about what to do in that case.

build error:
"D:\j\workspace\release_ci_pa---3f142ccc\build-everything.proj" (default target) (1) ->
"D:\j\workspace\release_ci_pa---3f142ccc\vsintegration\fsharp-vsintegration-unittests-build.proj" (Build target) (38) ->
"D:\j\workspace\release_ci_pa---3f142ccc\vsintegration\tests\unittests\VisualFSharp.Unittests.fsproj" (Build target) (40) ->
(CoreCompile target) ->
  D:\j\workspace\release_ci_pa---3f142ccc\vsintegration\tests\unittests\QuickInfoProviderTests.fs(102,37): error FS0039: The field, constructor or member 'ProvideQuickInfo' is not defined. [D:\j\workspace\release_ci_pa---3f142ccc\vsintegration\tests\unittests\VisualFSharp.Unittests.fsproj]

    13 Warning(s)
    1 Error(s)

@KevinRansom an issue I've run into with testing new features built around the Roslyn functionality is that there's no easy way to create a workspace to test it out with. Since the default workspace implementations reject all code that isn't C# or vb funtions/methods that rely on Document or Project connections inside of a solution are really hard to test.

@dsyme maybe that can come later, but I'm trying to address a more immediate concern I've had while working on this repo in particular due to the extensive use of .fsi files.

However frequently documentation is duplicated in signature and implementation, which raises questions about what to do in that case.

this is a crude workaround due to inadequate tooling support and I think trying to account for it is going to end up in a lot of generated documentation suddenly becoming very messy. Trying to establish a good heuristic for when doccoms are similar enough to be duplicates seems like an invitation for kludges.

Is there anything else I need to do for this?

this might even encourage people to spend more time writing documentation in signature files since they'd actually get the benefit of it in their implementation files. the giant gross xml doccoms won't have to pollute their code.

@cloudRoutine agreed

@KevinRansom this'll be pretty useful when working on the parts of the compiler where there's extensive documentation in the signatures but barely any in the implementation files. So hopefully it can get merged soon.

@KevinRansom all green and resolved here too

integrated into https://github.com/Microsoft/visualfsharp/pull/2683


ARCore/ARKit Compatibility

Having some issues trying to use the stream from ARCore with this.

How do you reference the stream for ARCore or ARkit?

hum you are asking me question about another library I never used,
sorry but I don't think I can help you for this or anything related to ARCore.
This library is just a simple wrapper around unity API, so you can replace the part you dont want to use.
So for example, if you dont use the normal unity webcam, and want to use a 3rd party library, you have to write your own implementation of IWebcam or IScanner.


How to get the Thumbnail?

Is it possible to get the thumbnail of the video?

Try this just replace video ID
https://img.youtube.com/vi//default.jpg
For more details check
https://stackoverflow.com/questions/2068344/how-do-i-get-a-youtube-video-thumbnail-from-the-youtube-api


Configure renovatebot for rancher/rke-tools

Configure renovatebot for https://github.com/rancher/rke-tools to automate updates like https://github.com/rancher/rke-tools/pull/187 / https://github.com/rancher/rke-tools/pull/184
Exact scope as well as specific tools (though renovatebot is the standard) is open to updates/refinement.

PR for adding renovate workflow to rke-tools is merged.  The workflow is also running fine and automated PRs are being created for various components (like https://github.com/rancher/rke-tools/pull/193 and https://github.com/rancher/rke-tools/pull/201) hence closing the issue


autorender removes <link> tags

Currently, autorender removes <script>, <link>, and <style> tags that are in the template. This causes bugs when these tags are expected to be part of the page, for example a favicon:
<link rel="icon" type="image/png" href="/favicons/favicon-32x32.png" sizes="32x32">

Why are these removed?  What can be done to allow these types of tags?  Thanks!
cc @lkodai

Since creating this issue, I think I understand why it does this -> to prevent a double load of script, link, and style tags if the app has been server-side rendered (SSR).
The app using done-autorender is not using SSR, but it has things like <link rel="icon" type="image/png" href="/favicons/favicon-32x32.png" sizes="32x32"> in its "head".
I see a few options:
1.  Have this project only use <body> in index.stache
Presumably, much of what's in index.stache's <head> should be in the page that is being sent back by the server.  If people are using done-autorender in non SSR environments, we should probably encourage people to do this.
We could:

Detect if we aren't in an SSR environment and if there are script, head, or style tags in the head, we tell people to use the <body>-only version of done-autorender.
Detect when there is only a <body> or a lack of <body>.

2.  Support both served-<head> and autorendered-<head> elements
This could be tricky as the elements might not be the same.  We could do a diff and only add what's different.  But it feels strange to have a different behavior of the <body> vs the <head>.

You can put links in the body too, so #1 doesn't solve anything. I think we can do #2. We're only talking about links with an href and scripts here so not a big deal to keep a map of the ones already in the page.

Why not start with #3 as it's probably the easiest?
I still think we should do #1, but just warn people they should probably put it in the served HTML for better performance.
Sent from my iPhone

On Jan 12, 2017, at 7:22 AM, Matthew Phillips<EMAIL_ADDRESS>wrote:
You can put links in the body too, so #1 doesn't solve anything. I think we can do #2. We're only talking about links with an href and scripts here so not a big deal to keep a map of the ones already in the page.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Limiting done-autorender to only the <body> would remove some valid use-cases such as dynamically setting the title:
<head>
  <title>My site | {{page}}</title>
</head>
<body>
 ...
</body>

As far as #3 goes, how would you know that you're in a client-only rendering situation? The only thing I can think is to add some type of attribute to the markup. Maybe something like this:
<html autorender-all>
  ...
</html>

Sorry, to be clear, I'm not suggesting the body-only part of #1, I'm suggesting simply having a warning to tell people they probably should be putting these things in their served page.
Yes for #3 that's exactly what I suggested above:

How can we detect if we are SSR? Special attribute on the SSR-ed HTML?

It would probably be ideal if this was a className ... mostly because it would be easy to style the ssr-ed HTML in a disabled mode.

In a disabled mode? Can you clarify what you mean there?

I mean the style sheet can make the site look a shade of gray before re-attachment, to give the user a clear signal that the site is un-usable.
.done-ssred {
  color: #808080
}

If we remove that className after re-attachment, then the text color will go to black.

That makes omitting duplicate links/scripts an opt-in rather than opt-out feature. I don't think it should be opt-in.  I don't think anyone ever wants duplicates so they shouldn't have to add a class to prevent them.

After talking about it with @justinbmeyer sort of concluded that there is no good reason to put scripts or links into both the HTML and the Stache files. You would put them in one or the other, in which case there wouldn't be duplicates.
The only scenario for putting it in both is when server rendered. So we're going to have done-autorender add an attribute when being server rendered to the documentElement that gets removed after reattachment.
Some ideas for the attribute:

unresolved
unattached
not-live
reattaching

I kind of like unattached.

Need tests for:

[ ] - server rendered

The attribute should be added.

[ ] - Reattaching - SSR

The attribute should be removed.
No duplicates should exist.

[ ] - Reattaching - No SSR

all links/scripts should be copied over.

This is in 1.0.0-alpha.3, here's how to use it: https://github.com/donejs/autorender/tree/major#server-rendering

The existing solution has a bug where upon rerendering (for live-reload), because the data-detached attribute is gone it will insert scripts even though they are already there. This causes a problem where the Steal script tag is continuously reinserted and the entire app loads over and over and over.
I've reverted the fix since it's such a bad bug temporarily while I fix it.

I reverted this again. This is really hard to get right 😕  You have to maintain state to know if reattachment has occurred and if so, use the old behavior of not push in scripts.  Otherwise if you push in a steal script you'll get cycles as it continuously reinserts steal over and over again.
This feels a little dangerous to me and I'd like to back away from it and rethink it through a bit.

@chasenlehara why did you put this on the DoneJS 1.0 release? I don't think it should be. As I detailed about, this is really easy to get wrong and getting it wrong is very bad consequences (causing the browser to lock up, for example).

I put it in the 1.0 release epic because it’s a p1, but we can move it to another release epic or out completely if you don’t think we should address it now or schedule it for a future release. 🙂

I don't think this should be part of the 1.0 release or that it's a P1.

To clarify, I've fixed this twice only to find that it caused even worse bugs. Specifically when coupled with live-reload it would cause steal.js to be inserted multiple times which caused infinite recursion (each time steal.js was inserted it would then re-import your entire app including done-autorender which would then insert steal.js which would re-import your entire app, etc).
This can be fixed but given it is highly stately thing I'd want to refactor all of done-autorender to make sure that this feature could be isolated and properly tested for all scenarios. done-autorender's code is already not the best, so I wouldn't want to shove this feature in in a way that isn't readable.

@matthewp is this issue solved with the current 1.3 release?

Nope

so what is the current workaround?

Put the link tags into your stache file, I think.

as justin said https://github.com/donejs/autorender/issues/41#issue-200259686 , link tags get removed ... so putting them into the stache file dont work.
or do i something missunderstand?

In 2.0 you'll be able to keep elements in the DOM using a special data attribute. This is explained in the readme:
https://github.com/donejs/autorender/tree/major#keeping-elements-in-the-dom


Find a way to notify people that their parts will be shipped to them for the price stated without any further fees and not from Germany.

"All prices displayed take into consideration your provided location as well as that of the most ideal manufacturer, shipping and tax estimates included."


Enable data-validation validate custom-query row with only one query file

Currently both --source-query-file and --target-query-file are bot required to run a custom query row validation, i.e. validate custom-query row.
It might be the case that when migrating a table from source to target, the target version has a change that can be accounted for by a custom SQL on only one of the sides (source or target), without requiring two custom SQL.
For example, it is particularly common in BQ migrations to replace surrogate keys with composite natural keys. To do row comparison a custom SQL is needed to compute the composite natural in the source, therefore a --source-query-file is needed. Nevertheless the result from this custom SQL can be compared to the target table, thus the --target-query-file is not needed.
The easy workaround is to use a SELECT * in the --target-query-file, which brings to mind:

Having a SELECT * ... as a custom SQL is evidence enough that the custom sql is not needed
I would expect that performing a SELECT * ... would incur in additional computational costs compared to accessing the table directly, specially in the case of random row validation

If (2) holds true, I believe this request to be relevant. If not this is just a nice to have

Custom query generates a nested query in which the user-provided query will be the "table" on which we add our validation SQL logic. So in the SELECT * case, you would see something like SELECT col_a, col_b FROM (SELECT * FROM my_dataset.table)) if you were running a row validation on col_a,col_b.
Comparing that query with a regular row validation SELECT col_a, col_b FROM my_dataset.table in BigQuery, the bytes scanned are the same. I'm not sure about other databases though.
If we were to implement this, we would need to consider how to pass in the schema/table of the target, since we rely on the custom query to identify the table.


Error when start 'php artisan orchid:install'

Actual Behavior

%Migrating: 2016_08_07_125128_create_orch id_attachmentstable_table                                                                                Illuminate\Database\QueryException  : SQLSTATE[42000]: Syntax error or access  violation: 1064 You have an error in your SQL syntax; check the manual that cor responds to your MySQL server version for the right syntax to use near '('0'),  sort

Steps to Reproduce the Problem

php artisan orchid:install

Specifications

ORCHID Version: 6*
Laravel Version: 6.0.2
PHP Version: 7.3
Database Version: MySQL 5.7

Other Notes
I try to new install orchid use this documentation

Now I tried to install orchid, and installation completed successfully. I think problem was in right privileges to the folders.


[MAGI-05] - set default locale to utf-8

# All of this locale has to do with elixir expecitng UTF-8
RUN apt-get update && apt-get install -y --no-install-recommends locales
RUN sed -i -e 's/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen && \
    locale-gen
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV LC_ALL en_US.UTF-8```

seems this was already done


A user should be able to set the LLM parameters such as temprature, max_tokens etc.

⚠ Please check that this feature request hasn't been suggested before.

[X] I searched previous Ideas in Discussions didn't find any similar feature requests.
[X] I searched previous Issues didn't find any similar feature requests.

🔖 Feature description
TBD
📝 Additional Context
No response
Acknowledgements

[X] My issue title is concise and descriptive.
[X] I have searched the existing issues to make sure this feature has not been requested yet.
[X] I have provided enough information for the maintainers to understand and evaluate this request.

I am considering whether to treat these parameters as attributes of the agent or as attributes of a session. If it's a property of the session, it should be sufficient to store it on the frontend, typically in local storage, based on the sessionId. How do you see it?

I am considering whether to treat these parameters as attributes of the agent or as attributes of a session. If it's a property of the session, it should be sufficient to store it on the frontend, typically in local storage, based on the sessionId. How do you see it?

This should be passed via the Agent IMO

I am considering whether to treat these parameters as attributes of the agent or as attributes of a session. If it's a property of the session, it should be sufficient to store it on the frontend, typically in local storage, based on the sessionId. How do you see it?

This should be passed via the Agent IMO

Currently, services are primarily provided by the agent, which will be shared or incorporated into a workflow. It might be more appropriate to include it in the agent's attributes. I am considering adding a JSON type field named llmOption in the agent record to document parameters such as stream, max_token, temperature, and memory_size.

@elisalimli this is already possible to do when configuring the LLM. But perhaps this should be an option in the Agent as well? I'm thinking on the agent/invoke perhaps. What are your thoughts?

@elisalimli this is already possible to do when configuring the LLM. But perhaps this should be an option in the Agent as well? I'm thinking on the agent/invoke perhaps. What are your thoughts?

These parameters won't change quite often, right? So, I think we should store it in the database. We can pass the parameters to the agents/invoke API endpoint, but I don't think it is necessary.

It's already stored in the llm object. so no need to re-store it. question here is if we should expose them in agent invocation to make it more easy to manipulate.

expose them in agent invocation

this sounds feasible.

expose them in agent invocation

this sounds feasible since the options stored in the LLM table, not the AgentLLM

Go for it


Take block mainnet

Codecov Report

Merging #358 (7c29ec0) into main (6ca52ea) will decrease coverage by 0.2%.
The diff coverage is 0.7%.

@@           Coverage Diff           @@
##            main    #358     +/-   ##
=======================================
- Coverage   14.0%   13.8%   -0.2%
=======================================
  Files         27      27
  Lines       7260    7396    +136
=======================================
+ Hits        1019    1020      +1
- Misses      6241    6376    +135

Impacted Files
Coverage Δ

src/farcasterd/runtime.rs
0.0% <0.0%> (ø)

src/peerd/runtime.rs
0.0% <0.0%> (ø)

src/rpc/request.rs
15.5% <0.0%> (ø)

src/swapd/runtime.rs
0.0% <0.0%> (ø)

src/walletd/runtime.rs
0.0% <0.0%> (ø)

src/cli/command.rs
31.1% <20.0%> (-0.5%)
:arrow_down:

src/cli/opts.rs
52.5% <50.0%> (ø)

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 6ca52ea...7c29ec0. Read the comment docs.


Model inside a model support in response definition

I have the following model definitions:
/**
 * @rest\model address object defining station address.
 * @rest\property string address_line1 address line1
 * @rest\property string address_line2 address line2
 * @rest\property string city city
 * @rest\property string state state
 * @rest\property string postal_code postal code
 * @rest\property string country_code country code
 * @rest\property string phone phone
 * @rest\property string fax fax
 *
 * @rest\model stations Returns list of station for a given supplier id.
 * @rest\property int id supplier Id
 * @rest\property int supplier supplier Id
 * @rest\property string name  Supplier Name
 * @rest\property address Address Station Address
 * @rest\property string latitude latitude
 * @rest\property string longitude longitude
 * @rest\property string timezone timezone
 * @rest\property string station_type Station Type
 */

and later on declaring the response type as follows:
 /** @rest\endpoint /stations/{supplier_id}
     * @rest\method GET Returns list of station for a given supplier id.
     * @rest\response 200 stations
    */

so I'm trying to make a reference of a model inside another model.  but when I execute, I get the following exception: Property format not recognized: 'address'
is model inside a model supported the same way as an array of models?
if the definition is changed as follows, the generation executes successfuly, but does not match the real output of my API
/**
 * @rest\model address object defining station address.
 * @rest\property string address_line1 address line1
 * @rest\property string address_line2 address line2
 * @rest\property string city city
 * @rest\property string state state
 * @rest\property string postal_code postal code
 * @rest\property string country_code country code
 * @rest\property string phone phone
 * @rest\property string fax fax
 *
 * @rest\model stations Returns list of station for a given supplier id.
 * @rest\property int id supplier Id
 * @rest\property int supplier supplier Id
 * @rest\property string name  Supplier Name
 * @rest\property array(address) Address Station Address
 * @rest\property string latitude latitude
 * @rest\property string longitude longitude
 * @rest\property string timezone timezone
 * @rest\property string station_type Station Type
 */

thank you

That's a good idea!
From the top of my head, I don't know if the Swagger/Open-API spec permits this type of referencing. If it does, than implementing it should be easy. If it does not, it could still be implemented but will take a bit more effort.
The current "support" for array references is probably a bug; this was not intentional and has to do with the way SG handles types. Could you describe what you think the result should be and what SG currently generates?
I'll try to find some time this weekend to look into this.

I think Swagger does permit, at least at swagger editor.  Consider the following yaml:
swagger: '2.0'
info:
  title: API
  description: Description
  version: "1.0"
host: myhost.com
schemes:
  - https
basePath: /
consumes:
  - application/json
produces:
  - application/json
paths:
  /stations:
    get:
      description: |
        Returns list of station for a given supplier id.
      responses:
        200:
          description: An Object defining response from Station
          schema:
              $ref: '#/definitions/Stations'
        default:
          description: Unexpected error
          schema:
            $ref: '#/definitions/Error'
definitions:
  Error:
    type: object
    properties:
      code:
        type: integer
        format: int32
      message:
        type: string
      fields:
        type: string
  Address:
    description: Object defining Address.
    properties:
      address_line1:
        type: string
      address_line2:
        type: string
      city:
        type: string
      state:
        type: string
      postal_code:
        type: string
      country_code:
        type: string
      phone:
        type: string
      fax:
        type: string
  Stations:
    type: array
    items:
      $ref: '#/definitions/Station'
  Station:
    description: Detailsof station.
    properties:
      id:
        type: integer
      name:
        type: string
      address:
        $ref: '#/definitions/Address'

As you can see, the Stations schema contains and array of Station objects (that is why I was expecting that @rest\property array(address) to work fine).  At the same time, Station contains a reference to the address object.  This way, editor.swagger.io does not complaints and produces the following output:

I can get SG to generate an array of referenced objects, but fail to generate a referenced object within another referenced object.
Hope this helps, please let me know if you need additional information.  I would like to contribute, but at this time I find myself with very limited time :(  I'm also attaching YAML above converted to JSON
Thanks!
swagger (1).json.zip

This was a pretty simple fix, adding some useful functionality.
Thanks for the issue and all the example code, which greatly helped finding and fixing this issue.
Fix and unittest coverage included in 2.3.7
Please let me know if this works for you.

Awesome!
Will update and test, and will let you know.

Confirming the generated docs work as expected in the swagger editor using version 2.3.7.  Thanks


Removed obsolete reference in "browser support" to Opera not supporting radial gradients

Fingers crossed for my first ever pull request to someone else's repo.....

Merged, thanks!


Correct configuration for cri-o proxy settings

Proxy for cri-o is found under /usr/lib/systemd/system/crio.service in the Environment variable, under [Service]. It appears values just need to be space-separated, like shown below.
Be careful that only one Environment statement can be declared. Default settings include Environment=GOTRACEBACK=crash without any quotes.
If the UI passes PROXY=on (or True), the fix should destroy that line and create a new one as shown below:
[Unit]
Description=Container Runtime Interface for OCI (CRI-O)
Documentation=https://github.com/cri-o/cri-o
Wants=network-online.target
Before=kubelet.service
After=network-online.target
[Service]
Type=notify
EnvironmentFile=-/etc/default/crio
Environment=HTTPS_PROXY=http://proxy.esl.cisco.com:80 NO_PROXY=localhost,<IP_ADDRESS>/16 GOTRACEBACK=crash
ExecStart=/usr/bin/crio
$CRIO_CONFIG_OPTIONS
$CRIO_RUNTIME_OPTIONS
$CRIO_STORAGE_OPTIONS
$CRIO_NETWORK_OPTIONS
$CRIO_METRICS_OPTIONS
ExecReload=/bin/kill -s HUP $MAINPID
TasksMax=infinity
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity
OOMScoreAdjust=-999
TimeoutStartSec=0
Restart=on-abnormal
[Install]
WantedBy=multi-user.target
Alias=cri-o.service

Proxy env variables are set in file /etc/systemd/system/crio.service.d/http-proxy.conf
it appears it can be set multiple times:
cisco@nkt-master-1:~$ systemctl show cri-o  | grep proxy
Environment=GOTRACEBACK=crash HTTP_PROXY=http://proxy.esl.cisco.com:80 HTTPS_PROXY=http://proxy.esl.cisco.com:80 http_proxy=http://proxy.esl.cisco.com:80 https_proxy=http://proxy.esl.cisco.com:80 [unprintable] [unprintable]
DropInPaths=/etc/systemd/system/crio.service.d/http-proxy.conf

However, do found the crio proxy config task will be skipped when sandbox_status is set to false.
not sure if that's your issue.

@cpaggen did you have time to check this one out?


gitlab-ci-local: 4.52.2 -> 4.53.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for gitlab-ci-local is: Run gitlab pipelines locally as shell executor or docker executor
meta.homepage for gitlab-ci-local is: https://github.com/firecow/gitlab-ci-local
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.53.0 with grep in /nix/store/rfcrdg8v8s0zwvfdcg0aidz7f5y8yn05-gitlab-ci-local-4.53.0
found 4.53.0 in filename of file in /nix/store/rfcrdg8v8s0zwvfdcg0aidz7f5y8yn05-gitlab-ci-local-4.53.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

gitlab-ci-local

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/rfcrdg8v8s0zwvfdcg0aidz7f5y8yn05-gitlab-ci-local-4.53.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A gitlab-ci-local https://github.com/r-ryantm/nixpkgs/archive/417697da63f5a62c93fb7df5cf0143ca9aa2b5f4.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/417697da63f5a62c93fb7df5cf0143ca9aa2b5f4#gitlab-ci-local

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/rfcrdg8v8s0zwvfdcg0aidz7f5y8yn05-gitlab-ci-local-4.53.0
ls -la /nix/store/rfcrdg8v8s0zwvfdcg0aidz7f5y8yn05-gitlab-ci-local-4.53.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

gitlab-ci-local

Maintainer pings
cc @pineapplehunter for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


Implement Spectrum Scale REST connector for Ubiquity

Implement V2 REST API support for Ubiquity. For this I have implemented following interfaces
GetClusterId
IsFilesystemMounted
ListFilesystems
GetFilesystemMountpoint
CreateFileset
DeleteFileset
LinkFileset
UnlinkFileset
ListFileset
ListFilesets
IsFilesetLinked
SetFilesetQuota
ListFilesetQuota
ExportNfs
UnexportNfs
I have tested the interfaces with ubiquity-docker-plugin and ubiquity-K8’s plugin.
Currently I am writing  Unit test case for it using ginkgo/gomega
Update (14/06/2017) ===
Fixed certain issues found while running Unit test cases.  For example  in ListFilesets function below was the change
Before:
listFilesetURL := utils.FormatURL(s.endpoint, "scalemgmt/v2/filesystems/%s/filesets",filesystemName)
After Fix:
listFilesetURL := utils.FormatURL(s.endpoint, fmt.Sprintf("scalemgmt/v2/filesystems/%s/filesets",filesystemName))

@aswarke can we close this issue?  is it still relevant?


PyPi Setup

@ambroisie Thank you for the help! Would you mind taking a quick look over these changes and let me know if I've done anything stupid?


[v5] Data actor

This PR adds fromData(...), which makes it easy to work with plain data:
const dataActor = interpret(fromData({ count: 0 }));

dataActor.send({
  type: 'set',
  data: { count: dataActor.getSnapshot().count + 1 }
});

dataActor.getSnapshot();
// { count: 1 }

This is more of a user-land abstraction