Add config test feature to faucet

So here's a great idea: if we can somehow run faucet in a mode where it just parses the config then exits returning either a success or error code depending on whether the config is valid or not then operators can use this as part of an ansible deploy to decide if it's safe to reload faucet or not.
Have assigned to Chris because he offered to code the feature for me in IRC :smile:

I love that idea!
On Wed, Jan 11, 2017 at 2:13 PM, Brad Cowie<EMAIL_ADDRESS>wrote:

So here's a great idea: if we can somehow run faucet in a mode where it
just parses the config then exits returning either a success or error code
depending on whether the config is valid or not then operators can use this
as part of an ansible deploy to decide if it's safe to reload faucet or not.
Have assigned to Chris because he offered to code the feature for me in
IRC 😄
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/359, or mute the thread
https://github.com/notifications/unsubscribe-auth/AEgZ16vjaiIDlDN_mhlOUehAmdHhxld-ks5rRCywgaJpZM4LgFff
.

https://github.com/anarkiwi/faucet/commit/489250cebd7f21e5d57dcd018810a4db0bffbf2e


Joins, and joining columns

We've got some details to sort out
Inner join on overlapping column (no issue)
df1.join(df2, how='inner', left_on='a', right_on='a')

Then, clearly, the output should contain a single occurrence of column 'a'. E.g.
If we do an inner join, then the output should clearly be:
In [44]: left = pd.DataFrame({'a': [1,2]})
    ...: right = pd.DataFrame({'a': [2, 3], 'b': [2,4]})
    ...: left.merge(right, left_on='a', right_on='a')
Out[44]:
   a  b
0  2  2

In [45]: left = pl.DataFrame({'a': [1,2]})
    ...: right = pl.DataFrame({'a': [2, 3], 'b': [2,4]})
    ...: left.join(right, left_on='a', right_on='a')
Out[45]:
shape: (1, 2)
┌─────┬─────┐
│ a   ┆ b   │
│ --- ┆ --- │
│ i64 ┆ i64 │
╞═════╪═════╡
│ 2   ┆ 2   │
└─────┴─────┘

Inner join on non-overlapping column - keep both joining columns?
Here pandas and polars differ:
In [47]: left = pd.DataFrame({'a': [1,2]})
    ...: right = pd.DataFrame({'b': [2,4]})
    ...: left.merge(right, left_on='a', right_on='b')
Out[47]:
   a  b
0  2  2

In [48]: left = pl.DataFrame({'a': [1,2]})
    ...: right = pl.DataFrame({'b': [2,4]})
    ...: left.join(right, left_on='a', right_on='b')
Out[48]:
shape: (1, 1)
┌─────┐
│ a   │
│ --- │
│ i64 │
╞═════╡
│ 2   │
└─────┘

The joining columns are guaranteed to have the same values at all rows in an inner join, so I think the extra column in the pandas case is redundant?
Left join on overlapping column
Here I think I'd have expected both joining columns to appear, as they're not guaranteed to be the same on each row.
But neither pandas nor polars do that
In [61]: left = pd.DataFrame({'a': [1,2]})
    ...: right = pd.DataFrame({'a': [2,4]})
    ...: left.merge(right, left_on='a', right_on='a', how='left')
Out[61]:
   a
0  1
1  2

In [62]: left = pl.DataFrame({'a': [1,2]})
    ...: right = pl.DataFrame({'a': [2,4]})
    ...: left.join(right, left_on='a', right_on='a', how='left')
Out[62]:
shape: (2, 1)
┌─────┐
│ a   │
│ --- │
│ i64 │
╞═════╡
│ 1   │
│ 2   │
└─────┘

Left join on non-overlapping column
In [54]: left = pd.DataFrame({'a': [1,2]})
    ...: right = pd.DataFrame({'b': [2,4]})
    ...: left.merge(right, left_on='a', right_on='b', how='left')
Out[54]:
   a    b
0  1  NaN
1  2  2.0

In [55]: left = pl.DataFrame({'a': [1,2]})
    ...: right = pl.DataFrame({'b': [2,4]})
    ...: left.join(right, left_on='a', right_on='b', how='left')
Out[55]:
shape: (2, 1)
┌─────┐
│ a   │
│ --- │
│ i64 │
╞═════╡
│ 1   │
│ 2   │
└─────┘

In a left join, there's no guarantee that the joining columns will be equal on each row, so I think the pandas one is more complete here?
Outer join on overlapping column
In [56]: left = pd.DataFrame({'a': [1,2]})
    ...: right = pd.DataFrame({'a': [2,4]})
    ...: left.merge(right, left_on='a', right_on='a', how='outer')
Out[56]:
   a
0  1
1  2
2  4

In [57]: left = pl.DataFrame({'a': [1,2]})
    ...: right = pl.DataFrame({'a': [2,4]})
    ...: left.join(right, left_on='a', right_on='a', how='outer')
Out[57]:
shape: (3, 2)
┌──────┬─────────┐
│ a    ┆ a_right │
│ ---  ┆ ---     │
│ i64  ┆ i64     │
╞══════╪═════════╡
│ 2    ┆ 2       │
│ null ┆ 4       │
│ 1    ┆ null    │
└──────┴─────────┘

Even though the joining column has the same name, Polars keeps track of its values for each row from the original dataframes, and appends '_right' to one of the names. I think this one's more complete here
Outer join, non-overlapping columns
Both keep both, no issue
In [58]: left = pd.DataFrame({'a': [1,2]})
    ...: right = pd.DataFrame({'b': [2,4]})
    ...: left.merge(right, left_on='a', right_on='b', how='outer')
Out[58]:
     a    b
0  1.0  NaN
1  2.0  2.0
2  NaN  4.0

In [59]: left = pl.DataFrame({'a': [1,2]})
    ...: right = pl.DataFrame({'b': [2,4]})
    ...: left.join(right, left_on='a', right_on='b', how='outer')
Out[59]:
shape: (3, 2)
┌──────┬──────┐
│ a    ┆ b    │
│ ---  ┆ ---  │
│ i64  ┆ i64  │
╞══════╪══════╡
│ 2    ┆ 2    │
│ null ┆ 4    │
│ 1    ┆ null │
└──────┴──────┘

Inner join on non-overlapping column - keep both joining columns?

The joining columns are guaranteed to have the same values at all rows in an inner join, so I think the extra column in the pandas case is redundant?

+1 we will reduce memory consumption.

Left join on overlapping column

Here I think I'd have expected both joining columns to appear, as they're not guaranteed to be the same on each row.

I guess the idea here is to do it by analogy with the outer join in Polars? By storing this data, one can understand which keys were not in the right operand, but is this data always needed? It turns out that memory will be wasted in cases where the user does not need it.

Left join on non-overlapping column

In a left join, there's no guarantee that the joining columns will be equal on each row, so I think the pandas one is more complete here?

If the names of the columns used to perform the merge (left_on, right_on) were ignored, then the behavior would be consistent with the previous option.

Outer join on overlapping column

Even though the joining column has the same name, Polars keeps track of its values for each row from the original dataframes, and appends '_right' to one of the names. I think this one's more complete here

It seems great to have this information, but not everyone needs it. It’s like pandas used to do sorting by default for some operation (I don’t remember exactly), and then it stopped being the default, while users have the opportunity to enable it if necessary.

I'd suggest returning both, if users want the coalesced version they can coalesce
And regarding memory, I'd say that it's up to the implementation to optimise that

From discussion today:
Some other options could be:

user has to specify which columns to keep, e.g. df1.join(df2, how='left', left_on='a', right_on='a', left_columns=['a', 'b', 'c'], right_columns=['d', 'e']), which would raise if left_columns and right_columns overlap
always coalesce, keep left-hand-side. Users can dodf1.assign(df1.col('a').rename('a_left')).join(df2.assign(df1.col('a').rename('a_right')), how='outer', left_on='a', right_on='a')`

coalesce if column names overlap, else keep both. Users can still get the behaviour they want by renaming beforehand

Of these options, it seems there was most appetite for the last one


Allow a custom value attribute for checkboxes

This is needed in case of repeated checkboxes. Instead of returning a list of booleans to the controller this allows to return a list of strings.
A list of booleans is not sufficient since play only returns those set to true, thus making it impossible to determine which checkboxes are checked and which ones are not.
This change allows the following use case:
@for((options,i) <- options.zipWithIndex) {
   @helpers.checkbox( registerForm("options["+ i +"]"), '_label -> Messages(option), 'value -> option )
}

Thanks! I'm working these days on the version 1.0, so I don't expect to touch anything on this one. But don't worry, I'll add it to the new one.

@adrianhurt What will be different in version 1.0? What are your plans?

I'm planning to release it between this night or a couple of days. It's mainly the same, but I've rewrite the core to separate it and share it for Bootstrap 3 and 4. And I will rename the project and host the web directly in github. I will add every change in the changelog. I think the project is now stable in its functionality so I don't expect new main features in the short future...

@adrianhurt Nice! Maybe you can also start to tag every release using git tag.
Thanks for all the work!

It's done with this feature added. And @mkurz, I will add tags for every non-SNAPSHOT version. I think it's more clear now without a specific branch for each version as I had before.


RNFetchBlob fetch params

Thanks for the lib.
I needed to add Authorization headers for some images I am requesting, but wanted to use your library. So I added the ability to pass params to the fetch method in download.
If you want to merge this, let me know if you want any changes. I'm not familiar with TypeScript, but I linted it using their tool and got no errors, apart from some TouchEvent stuff, which I don't think is related:
369     interface TouchEvent<T> extends SyntheticEvent<T> {
                  ~~~~~~~~~~
node_modules/@types/react/index.d.ts(369,15): error TS2430: Interface 'TouchEvent<T>' incorrectly extends interface 'SyntheticEvent<T>'.
  Types of property 'nativeEvent' are incompatible.
    Type 'NativeTouchEvent' is not assignable to type 'Event'.
      Property 'bubbles' is missing in type 'NativeTouchEvent'.

427     type TouchEventHandler<T> = EventHandler<TouchEvent<T>>;
                                                 ~~~~~~~~~~~~~
node_modules/@types/react/index.d.ts(427,46): error TS2344: Type 'TouchEvent<T>' does not satisfy the constraint 'SyntheticEvent<any>'.
  Types of property 'nativeEvent' are incompatible.

By the way, how do you develop this locally? The only way I could get it to work was to build the tsx file and copy the contents into the node_modules/react-native-img-cache/build folder.

@rdougan Thks for this PR! I'm currently looking to see if there is a way to transparently support the request parameter supported by ImageURISource instead of an adhoc parameter as you did. I will keep you posted.


sdd playlist.txt error

This project only supports Linux at the current time. We are using a XLib library which is only available on Linux.
To "fix" this issue "easily," we could add some OS checks around the XLib portions, which would effectively turn off features on a specific OS. We could then add in libraries for those platforms to get the same functionality.
Unfortunately, I don't have a windows system to dev/test on.

#3 for further discussions

When to support windows


Fix works-for-you scrolling

Thanks to @alloy for discovering this bug  🙌
The problem was

the GenericGrid component initially renders with a height of 0, then measures it's own width before populating the grid with artworks.
in WorksForYou (Artists tab on home screen) GenericGrids were being rendered in a FlatList
When you scroll far enough in a FlatList things that are off-screen will be unmounted and removed. When you scroll back they will be mounted and shown again.
When a component re-mounts with a different height FlatList rightly adjusts the top offset of succeeding items to match.
Scrolling far down in WorksForYou and then scrolling back up was a disco funky janky mess.

This has been a problem since the recent react-native upgrade when all of our ListView components were refactored to use FlatList. WorksForYou was one of those.
The solution: calculate the width at a higher level and pass it down to the GenericGrid instances so they can do their layout synchronously on first render.

we'll need to apply this fix to other areas where we have paging GenericGrids, like the Partner page, right?

Yeah I'll do a proper audit now.

@alloy That Street Sharks gif is giving me strong 90's nostalgia 🤩


reader: unit-tests

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

8 of 8 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 98.055%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
2521

Relevant Lines:
2571

💛  - Coveralls


Memory leak when disposing Document objects.

In my app that opens and disposes millions of document objects, I'll start to get OutOfMemory exceptions in various places. I believe it is caused by the ToPool() methods in Pool.cs.  Don't we need a size check on the underlying stacks?  Otherwise they'll just continue to fill up until .NET runs out of memory (especially in a 32-bit process).
Exception of type 'System.OutOfMemoryException' was thrown.
at System.Text.StringBuilder.set_Length(Int32 value)
   at AngleSharp.TextSource.Dispose()
   at AngleSharp.Dom.Document.Dispose()
... truncated ...

Good question. Usually, the pool should be reused and there are size limitations afaik. I'll look into it / improving it!

@jlchmura Can you post a reproducible example please?

I'll close this one due to inactivity.
If a reproducible test comes out or someone finds something to improve feel free to bump the issue. 👀


"main redeclared in this block"

I tried to build this library go build ./... and got error:
# github.com/seancfoley/ipaddress-go/ipaddr/cmd
ipaddr/cmd/test.go:25:6: main redeclared in this block
        ipaddr/cmd/main.go:37:6: other declaration of main

I've taken a look at this issue and your associated PR.
I haven't quite made up my mind, but it's likely that I will not merge your associated PR as the solution, which moves the test.go main function into the ipaddr/test package, because the test package is meant to contain code for that package only and not a second package.  AFAIK, the usual go convention is to avoid having a go "main" package source file in the same folder as other packages, so as not to mix the library or test code with application code to create binaries.
I've looked into how the go community usually handles this situation of having multiple binaries, and while there are not a lot of resources out there addressing this, I have found more than one resource suggesting that each binary should be in its own subfolder of the cmd folder, so I'm likely gonna do that, which should address this.

fixed in version 1.5.5


Fix formatting on wallet utilities

Describe the bug
Fix the formatting on wallet utilities page
To Reproduce
Steps to reproduce the behavior:
Go to https://dev.near.org/wallet-utilities
Expected behavior
Human friendly formatting
Screenshots

Hi! I'd like to work on this issue. Please assign it to me.

Hey @Pawar7349 thanks for taking that up!


throw an error if you use unwrap without checking first if you have a none or some

I'm not sure this is a good idea or not yet, but what if we keep track per instance if a given Option has been "checked", and if you attempt to unwrap before checking we throw an error, even if it is a some.
If you are working with ts, this probably isnt as much of a concern - but if you are working from javascript directly, theres nothing to prevent you from misunderstanding the api and not checking first.  If you just happen to only test with values that produce somes, you might never realize you forgot a check to make sure thats safe first.
Imagine a newcomer writing code like this:
service.methodThatReturnsAPromiseOfAnOption()
   .then(o => o.unwrap())
   .then(doSomethingCool);

They're new to Options, they read enough of the api to know that unwrap is how they get the value they care about out and they move along.
The error could say something like

You attempted to unwrap an Option without first checking to make sure it has a value! see this url for more information, but consider using unwrapOr or using .isSome() or .isNone() to test if it is safe to unwrap first!

I'm not certain if there would be edge cases where they could know its safe but we cant know that they know - might be something around where we create new instances in some operations, but would need to think about that more - most of those operations could return null and so the point of creating a new instance is to make that a safe operation - meaning if you did check before (on an earlier instance) that doesn't mean you are still safe now.
Also not certain if there should be a way to say "leave me alone, I know what im doing" - or what it would look like if there were.

Letting this sit in my mind for a bit as I'm not sure how I feel about it yet.  I think I like where you're going, but I'm not sure about those edge-cases you mentioned.  Will get back to you on this soon.

I like the spirit of this, but I'm not sure I think this is the right solution to the problem.  Some drawbacks I can see are:

extra processing and storage internally (maybe it's not enough to matter, but still something to consider)
slightly more complexity to the logic in the library (again maybe not enough to matter, but still)
you already basically mentioned this, but what if I'm prototyping something and I'm fine with just using unwrap() temporarily (assuming I know what I'm doing).
there are definitely edge-cases that we probably won't be able to detect (or even think of).  And as long as these exist, what can we really do?  We can't throw an error because if there is an edge-case, then people who run into that can't use the library at all, right? (unless I'm missing something).

However, I do like the error message you wrote up and I don't see why we couldn't just use that (maybe slightly tweaked) for the normal error message when you unwrap a None.  I think that would help a great deal when someone does get to the point of unwrapping what they thought was a Some.
The root of the problem here though is preventing that scenario before it even happens, but I'm not sure if that's really possible in all scenarios.  IMHO, we just need to make this as easy as possible for people who are new to Optional types, and I think that is best solved with good documentation.
Italics / bold in the docs for unwrap specifically would probably help.  And it would also be really good to have a section front and center both in the readme and in the docs called "New to Option-types?" or something like that.  It would also probably be nice to have a section for people who aren't new to Optional types which just gives the high-level overview so they know which set of terminology this library uses (Maybe/Option, Just/Some, Nothing/None, get/unwrap, etc.).

I'm still not convinced this is a good idea either, but let me argue for it a little longer.
re: 1 and 2, those are not good reasons imo.  The impact to storage, processing and logic is tiny.  We are talking about a boolean field intialized to false when a new Option is instantiated and flipped to true when you call certain methods - with a single if when you call unwrap and only then.

what if I'm prototyping something and I'm fine with just using unwrap() temporarily (assuming I know what I'm doing)

You don't know what you're doing... unsafe code is unsafe code.  There is no way to call unwrap safely without first checking that it contains a some.  Even in prototype code, its just wrong.  In a type safe language you would be prevented from doing it.  And I mean thats kinda the point of using this this pattern in the first place - you need more safety in your life.  If you want to play it fast and loose, why would you use an Option?

there are definitely edge-cases that we probably won't be able to detect (or even think of). And as long as these exist, what can we really do? We can't throw an error because if there is an edge-case, then people who run into that can't use the library at all, right?

I haven't been able to come up with a single one.  Even a hypothetical.  The only time I can conceive of that it would happen is if there were other methods you could call that would let you know that it is indeed safe to call unwrap besides isSome and isNone.  I don't think there are, but if we find that is the case, we add the setting of the flag to that method and we're done.  There shouldn't ever be a case you couldn't fall back to using isSome and isNone though.

The root of the problem here though is preventing that scenario before it even happens, but I'm not sure if that's really possible in all scenarios. IMHO, we just need to make this as easy as possible for people who are new to Optional types, and I think that is best achieved with good documentation.

Even if you read the documentation and think you understand it, you could still accidentally make this mistake.  And in your testing you never hit a case where the Option is none and so you dont notice.  And then you blow up in production - so what good was this library at that point?  Again, in other languages you have the luxury of the compiler being able to tell you if you do this stupid thing - we have to do it at runtime.
The documentation improvements would still be nice though - if we don't end up doing anything but that then I think this has been a worthwhile exercise.  But I'll assert that most people don't read the documentation and they write some code and feel around till they get something working and they ship it.

re: 1 and 2, those are not good reasons imo.[...]

Fair points here, just wanted to bring it up.  I think it's slightly more complicated than that, but more on that later.

You don't know what you're doing... unsafe code is unsafe code[...]

I get this argument (and I kindof agree with it), but I feel like it's a bit too idealistic to say that without any caveats at all.  Generally speaking, I don't want people to use a given library improperly nor do I want them to build bad habits; but I also don't want to try to control how people write their own programs too much.  I think it's fine (and very much a good idea) to design an API such that we encourage "proper" usage, but I also wouldn't want to make it more difficult than necessary to use the API just to be "pure" about the approach.

In a type safe language you would be prevented from doing it.[...]

I'm not sure this is entirely true.  (safe) Rust is type-safe (iirc), and you can absolutely call unwrap on a None value.  It's just that the unwrap call will result in a panic which will dump the stack and halt the program.  The supposed return type of unwrap is still T, so the types don't mismatch and there's no compile-time issue here.  Regardless though:

If you want to play it fast and loose, why would you use an Option?

I totally agree with the sentiment here.  I think the only issue is, if you are using a library that provides an API that already uses Options, you don't have a choice.

I haven't been able to come up with a single one.[ ... ]if there were other methods you could call that would let you know that it is indeed safe to call unwrap besides isSome and isNone

So, just to list out the items we'd need to modify:

filter
flatMap
forEach
isNone
isSome
map
match
orElse
unwrapOr
unwrapOrElse

Basically, anything that takes a function as an argument (we don't know what side-effects those functions can cause), isNone / isSome, and unwrapOr because you could then check the return value and then optionally call unwrap.
However, let's say that we add that logic to all of those functions, what happens when someone writes this:
// initialized "hasChecked" to false;
const nope = OptionT.none();

// set "hasChecked" to true because they may have saved some information from within that lambda
const nada = nope.map(val => val * 2);

// now they can call unwrap without getting the special error message
const originalVal = nope.unwrap();

With that in mind, I'm not sure how we could consistently prevent the consumer from running into this issue.  We might be able to in some cases, but there are definitely cases where we can't know whether or not they know what the state of the OptionT is in.  We know they could know, but not whether or not they do know.

I don't think we are on the same page.
None of those methods besides isNone or isSome will tell you if you have a some or none.  Lets take map for instance.
https://repl.it/repls/WigglySelfassuredGnuassembler
let a = OptionT.some(1);
let b = OptionT.some(1).map(x => x > 2 ? x : null);
console.log(b);// None()

You could have known you had a some - but then once you map you dont know that any longer.  Remember that it has to be this way because all of these methods return new Options, not the same one.  Even if we were to keep track of hasChecked  with these methods it wouldn't matter because we would then just create a new Option for the resulting value.
Saving information from inside of lambdas is not something we should support.  Even if you could do it reliably, thats not how it should be used.  Remember that in the example you gave the lambda wasn't even called at all, because it was a none.

So, you're correct, we weren't on the same page.  In your example above, I agree that the only way you can tell what b is would be to call isSome or isNone.
However, I think my previous point wasn't quite clear and it may still be of some concern.  Consider this slightly tweaked example:
https://repl.it/repls/RobustElementaryPentagon
let a = OptionT.some(5);
let b = a.map(x => x > 2 ? x : null);

if (b.isSome()) {
  console.log(a.unwrap());
}

or even more contrived:
let canUseA = false;

let a = OptionT.some(1);
let b = a.map(x => {
  canUseA = true;
  return x * 2;
});

if (canUseA) {
  console.log(a.unwrap());
}

In those scenarios, we'd be preventing them from unwrapping a even though they know that it's safe to do so.

So your second example is exactly what im saying we shouldn't support.  We have a way for them to determine if they can use a or not, its isSome or isNone - imo we shouldn't worry about that use case at all.
I can kinda see where you are coming from on your first example - I think just more simply stated youre saying that because they are the ones using .some() to create the option then they know its a Some - but I don't think this is really a representative case. I think 95% of the time or more, the consumer, the one doing the unwraping is not going to be the one that created the Option in the first place - some other code has done that and returned the Option to you.
Maybe a middle ground is to make another method besides unwrap that allows you to declare that you know what you're doing.  unsafeUnwrap() or unwrapOrThrow() or something like that. Basically like an assertion, I know this is safe even though you don't think I should be able to.  But at the end of the day, is it really that bad to force them to use isSome/isNone or unwrapOr? The spirit of the library is safety - my goal is just to guide them in how to use it safely.

So your second example is exactly what im saying we shouldn't support.

Understood, and I thought about that as I was writing it, but wasn't 100% sure so I figured I'd included it anyway.  I have mixed feelings on this.  Part of me wants to be "pure" about this and guarantee that a feature like this can't get in the way of someone doing something valid even if what they're doing is strange or not quite the recommended way to do things.  However, I do understand that - as you said (slightly tweaked) - the whole point of this library is to get in people's way and make them do things differently.

[...]youre saying that because they are the ones using .some() to create the option[...]

Actually, I see how you got there, but that wasn't really my point.  I was trying to show that in certain cases they could check one option and therefore know information about another option.  For example:
https://repl.it/@iwburns/FluidTurquoiseValue
function getOption() {
  if (Math.random() > 0.5) {
    return OptionT.some(1);
  }
  return OptionT.none();
}

let a = getOption();
let b = a.map(x => x * 2);

if (b.isSome()) { // check b, but get info about a
  console.log(a.unwrap());
} else {
  console.log('a is a none');
}

In this scenario, it is guaranteed that if b.isSome() is true, a.isSome() will be too.  In fact, I think this is true regardless of the lambda passed to map (as long as the lambda doesn't reassign a).
Side Note (just a fun observation): The opposite isn't necessarily true, in other words if b.isSome() is false we don't know that a.isSome() would also be false.
I do think that the above isn't likely to be very common though.  And I agree, I think a good middle ground here would be to have a separate function that behaves as unwrap() currently does and the change the way unwrap() behaves as you described originally.  I'm not against unsafeUnwrap() and unwrapOrThrow(), but just to toss another name out there; what do you think of forceUnwrap()?

@ryanguill I've been busy lately and haven't looked at this in a bit. Do you have any more thoughts on this approach?

On mobile, so my formatting may be poor.
Your filter example is a good one. The only other thing I can think of would be an if condition with an and/or chain with an isSome at the end and then a bunch of unwraps in the if-body.
Because of the way that and and or work, the isSome would only affect the one that it happened to get called on and we wouldn't know exactly which one without first knowing whether or not they're  a some or a none.

updating this with a code example now that I'm not on mobile:
let a = OptionT.some(1);
let b = OptionT.some(2);
let c = OptionT.some(3);

if (a.and(b).and(c).isSome()) {
  // here we know that a, b, and c are all okay to unwrap
  // but only c would be marked as one that we've checked.
  doStuff(a.unwrap(), b.unwrap(), c.unwrap());
}

The more I think about it, or shouldn't be an issue here.  Logically it wouldn't make much sense to do:
if (a.or(b).or(c).isSome()) {
  // here we only know that one of them is okay to unwrap.
  // so blindly unwrapping all of them here is a bad idea and could very likely throw an error already
  doStuff(a.unwrap(), b.unwrap(), c.unwrap());
}

With that said though, I'm not sure how often the first example here would even come up.  I've actually never written code like that before while using Option-types, but that doesn't mean it never could be the right thing to do.

I think what we can do is [...]

I believe you are correct.  I'm not seeing how you could get into a weird scenario with this, do you mind giving an example?  Even so, I agree that it probably won't be too hard for someone to figure out what's going on.
So, summarizing the current path forward (assuming we implement this), we need to modify isSome, isNone, and and to all set the internal "checked" flag to true.  In addition, we need to modify unwrap to throw a special message if the internal "checked" flag is false on both Some and None types.  Otherwise, those methods should follow their normal behavior.
Does that all sound right?

the scenario is something like this:
let a = OptionT.some(1);
let b = OptionT.none();

let c = a.and(b);
doStuff(a.unwrap);// we have set the flag on `a` because you called `and` so we let this `unwrap` happen.

I think your summary is correct, but we also need to implement forceUnwrap which also throws a console warning that it isnt intended for production use, discouraged, etc.

Ah, yep that would do it.  And I agree, I don't see any problem with allowing the unwrap call there.  Worst case scenario is that a is actually a none and they get the "normal" called-unwrap-on-a-none error message.
And good call about forceUnwrap; somehow forgot about that one.  My main use-case example for wanting a way to forceUnwrap something is for writing tests or something similar where if the unwrap fails, the test (or whatever) should probably fail as well.  I think a console.warn is probably fine in that case, but I wanted to run it by you just in case you had any thoughts on that.

not sure I understand what youre after, but you can capture thrown errors in your unit tests and you can also mock the console object.

I'm just making a case for when I think using forceUnwrap would be acceptable.  Let's say you're writing a test for the following function:
function safeParseInt(value) {
  const parsed = Number.parseInt(value, 10);
  if (Number.isNaN(parsed) {
    return OptionT.none();
  }
  return OptionT.some(parsed);
}

You might then write the following tests:
let parsed = safeParseInt('1');
expect(parsed.forceUnwrap()).to.equal(1);

parsed = safeParseInt('-1');
expect(parsed.forceUnwrap()).to.equal(-1);

You'll get some warnings from this, but I think this is a perfectly reasonable test to write.  If the unwrap fails, it means your function isn't doing what it's supposed to.
One could argue that you should instead write:
let parsed = safeParseInt('1');
parsed.match({
  some: val => { expect(val).to.equal(1); },
  none: () => { throw new Error('safeParseInt gave a None when a Some(1) was expected.'); },
});

But I think that's not really that much more useful, especially for those more simple unit tests.
With all of that said, do you think it's reasonable to expect console warnings from tests that use that strategy?  I'm personally a bit torn.

I think you should instead write
let parsed = safeParseInt('1');
expect(parsed.unwrapOr(NaN)).to.equal(1);

If you used unwrap or forcedUnwrap and it is a none, meaning your test fails, you will get an error - which depending on the test suite might bomb the test instead of failing the assertion.  Using unwrapOr allows you to easily provide some other value than the expected to check against.
My personal opinion is forceUnwrap should be used for quick prototyping (not including tests) or as an escape hatch, and if you need the escape hatch we should be encouraging you to file an issue here so we can fix the underlying issue.

[...] which depending on the test suite might bomb the test instead of failing the assertion [...]

Fair point, I didn't think about that.  And I agree that unwrapOr is a very good candidate to use in this example (and probably most others).  Thinking more on it, the only situation I can think of where unwrapOr isn't what you want is when you're dealing with objects or arrays.  And in those cases, forceUnwrap wouldn't be what you would want either; instead you'd probably need to filter or match (or something similar) to get your desired information.

My personal opinion is [...]

I think I agree here.
I don't really have anything to add to the discussion here at this point.  How do you feel about this feature now that we've (I think fully?) talked it out?

I still think it would be worthwhile.  The only thing I think we are adding to the api is the forceUnwrap, everything else we could walk back from if we find that its not a good idea for some reason.  I think its a good way to help make sure people aren't using it incorrectly.

I agree.  If we had to walk it back in the future, worst case scenario is that forceUnwrap and unwrap end up doing the same thing.  That's obv. not ideal and I kindof doubt that will happen, but even if it does it's not that big of a deal.
Also, if we did end up walking this back and want to remove forceUnwrap, I'd say that's a pretty minor breaking change.  It would of course still warrant a major version bump, but the migration guide for that change would be pretty straightforward.
I'm game to move this forward past the discussion phase if you are.  I don't really care who works on it.  I should have some free time over the next few days to implement this, but if you have time feel free to move forward on it as well.  Just let me know so we don't double work it; I'll do the same whenever I sit down to work on it.

working on this now, should have a first draft ready tonight or tomorrow


Integration with the UIs of the other major projects [Question]/[Suggestion]

Hey, neat project and/but I'm wondering how one could approach to integrating a project like this to/with the big ones like oobabooga/text-generation-webui & SillyTavern.
Both support extensions. Wouldn't it be cool if all the extra features of these somehow magically worked with separate efforts like this one?
Asking to hopefully get the discussions rolling.

Hi, I created it in such a way that it can be integrated into other Python projects easily (see main.py). For example, chatdocs add command can be called from Python code as:
from chatdocs.add import add
from chatdocs.config import get_config

config = get_config()
add(config=config, source_directory="/path/to/documents")

But I'm planning to refactor some of the code to simplify its usage, so the Python API is not stable yet. I will let you know when it is ready.

Thanks! Keep up the good work.

Can someone guide me how can i integrate this into a streamlit app. So when i run it i can replicate the html file code into my app


NelderMeadSimplex Does Not Always Return Best Evaluated Point

If TryToScaleSimplex(-1.0,...) (line 146) results in a converged state, and then TryToScaleSimplex(2.0,...) (line 151) or TryToScaleSimplex(0.5,...) (line 159) is immediately run, the ObjectiveFunction will contain the point and value states of the latter, which can be worse than the previously established vertices.
For a discontinuous function or a function with a steep valley, this can result in a significantly erroneous result.
For example:
 var result = NelderMeadSimplex.Minimum(ObjectiveFunction.Value(
                x =>
                {
                    if (x[0] < 0.0 || x[0] >= 1) return Double.MaxValue;
                    return Math.Pow(x[0], 6.0);
                }),
                Vector<double>.Build.Dense(new[] { 0.5 }), 0.0000000000000000001);
Console.WriteLine($"{result.MinimizingPoint[0]} {result.FunctionInfoAtMinimum.Value} {result.Iterations}");

Output:
-4.44089209850063E-16 1.79769313486232E+308 64

By adding a final
objectiveFunction.EvaluateAt(vertices[errorProfile.LowestIndex]);
prior to instantiating the MinimizationResult, the objectiveFunction will be set to the proper state, and the MinimizationResult will be initialized with the proper values.
The code above then properly outputs
6.10351562455592E-06 5.1698788261995E-32 64

PR to fix.

Thanks for the analysis and the PR!

Thanks!

@EricScottSalem: Since you are using Nelder Mead Simplex. Beware of this bug, essentially it fails to find the minimum for completely symmetrical functions. Since you solved this problem, perhaps you are aware of how to solve #501 as well?

@eriove Hi, I am aware of that problem (I hesitate to call it a bug as I believe the code implements the original Nelder Mead Simplex algo accurately).
I am not an expert in this area, but I believe this is something of a known problem and can be found discussed in various literature; Googling "Nelder Mead convergence" produces many interesting hits.
I am not quite sure which of these would solve this (and all other) problems.
A dirty fix, in this case, is to perturb the simplex one more time after convergence to ensure it remains converged.  I hesitate to put up a PR to do this as it has no real theoretical basis, nor any paper I can cite, and it's ugly.
That being said, the following code gets 1 + x^2 to converge:
               if (HasConverged(convergenceTolerance, errorProfile, errorValues))
                {
                    numTimesHasConverged++;
                }
                else
                {
                    numTimesHasConverged = 0;
                }

                if (numTimesHasConverged == 2)
                {
                    exitCondition = ExitCondition.Converged;
                    break;
                }

Thanks, @EricScottSalem
@cdrnet : Would you accept a pull request with this change? In that case I'll add some tests and make the change. It would make the results much more intuitive even if it isn't strictly correct.

@eriove @cdrnet I've consulted with some colleagues who also think this change is would be beneficial and think I was being overly cautious with my initial hesitation.


Cassandra Parser:  Unit tests and fixes for 'batch' requests and 'prepared queries'

Adding unit test coverage for some of the more advanced protocol capabilities, including batch requests and prepared queries.   Found and fixed some bugs in those areas.

This change is

Coverage increased (+0.1%) to 43.049% when pulling be5daf960deff7ba42662ce7973bcc8a3ff95dd2 on danwent:cass-parser-improvements into 279a3086f0797f2c9d065820418ba6474fea545f on cilium:master.

test-me-please

test-me-please

test-me-please

Thanks @jrajahalme  .  I rebased, added two more unit tests, and fixed more more bug (to ensure that "use" queries do not generate a "DROP" response).

test-me-please


[HEVC][encode]error message appeared when using VEGA tool to playback HEVC CQP 4K encoded bitstreams

1.Testing environment:
Libva: (master)575be3f0b5868f842b12473fe21ceab72360cde0
Libva_intel_driver: (master)6f2ea35f5caaf39e81617e7087f20f4885b51985
libyami: (hevc-rebased) 97f8a3ebd4f04869fe321f08b90d1f426dbc3dcc
ffmpeg: (master)  61009a709c76ec2a8529c0fcf15057d82bed6454
2.Test command:
./yamiencode -W 3840 -H 2160 -i /$input/4K_2013_3840_2160_300frames.yuv -o /$output/4k_qp10_ipb_0.265 --ipbmode 0 --qp 10
3.error message:
ps_max_dec_pic_buffering[i]         out of range. Found 6 at index 0. Allowed 0 to 5(MaxDpbSize) Inclusively
sps_max_dec_pic_buffering_minus1[i]  out of range. Found 6 at index 0. Allowed 0 to 5(MaxDpbSize-1) Inclusively
N.A                                  POC Removed. POC(1) is removed forcefully to make space for current picture in DPB

Issue fixed. Please check my latest hevc-rebased branch.

After verified with the latest hevc-rebased branch, this issue has not existed anymore, so close this bug.


Possible multi-process transaction side effect visibility bug

For a test that reproduces the issue see: https://github.com/team-alembic/possible-ecto-concurrency-and-transactions-bug/blob/master/test/possible_ecto_transaction_bug_test.exs
Environment

Elixir version (elixir -v):

Erlang/OTP 20 [erts-9.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [hipe] [kernel-poll:false]

Elixir 1.5.1

Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.):

psql --version
psql (PostgreSQL) 9.6.2

Ecto version (mix deps):

2.2.6

Database adapter and version (mix deps):

postgrex 0.13.3

Operating system:

macOS High Sierra
Current behavior
The effect of a committed transaction in an ExUnit test is not visible from another process that is spun up after the transaction is committed. I'm using the Sandbox mode :auto which I believe gives me the ability to control my own transactions within a unit test.
Expected behavior
That the side effect (new record in the database) is visible from another process.

For reference, this is the failing test from the referenced git repo:

The failing line is:

@freshtonic :auto means the transactions are checked out automatically but each test and each process still runs on their own transaction/connection. If you want to share them, you need to explicitly allow processes or you need to set the mode to shared.

@josevalim I want each process to have its own transaction and connection. That is what I’m trying to test. Database transaction semantics should ensure visibility of committed transactions to other connections. If using auto my test should have a different connection to the asynchronous task, right? If so then any committed transaction in the test should be visible from the task.
Is this just a limitation of the Sandbox?
 I don’t think shared mode is what I want.

Is this just a limitation of the Sandbox?

Yes, the sandbox creates its own transaction that you cannot commit to guarantee that the work in one test cannot be seen by others. This means that you need to explicitly list which other processes collaborate with a given test process.

@josevalim ok that mostly makes sense. I was under the false impression that it was possibly to bust out of that behaviour using auto.

@freshtonic you can explicitly checkout a connection and disable the sandbox: https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/adapters/sql/sandbox.ex#L457
But then it means any change you do in the database in that test will be visible on all tests. If you want to have collaboration between processes in your tests while still using the sandbox, then the answer is using the allowance mechanism or the shared mode.

@josevalim That cleared up my misunderstanding and now I have a passing test. Thanks mate!


adding prerendering for search engines

Description

Since switching to WASM is the only way to view the docs, search engines and other crawlers have problems correctly fetching the pages. This PR has a middleware, that when a crawler is detected, it forces to send a pre-rendered version of it, in all other cases the "index.html" is sent to the browser, which kickstarts the application startup as before.
In addition, pre-rendered pages are cached in memory to serve those requests faster.
The detection of a crawler is based on the user-agent header. I've found a list in this repo (https://github.com/monperrus/crawler-user-agents/blob/master/crawler-user-agents.json)  and copied it. The list loads during startup. The delay of this middleware for "normal" requests should be very low. Besides the host header, a second approach will force to serve pretender files. If the request contains the query parameter "force-prerender" - the value doesn't matter - the pre-rendered page will be displayed.
How Has This Been Tested?

The tests have all been manual. There are no unit tests for this middleware. Since this middleware is more of an experiment to see if the google ranking improves, I'll add unit tests if it is successful.
If you start the sever project and use a browser for testing, the docs page should be as it was before. If you are using a tool like postman and append the parameter force-prerender (https://localhost:5001/components/table?force-prerender=true) to the URL, you will see the entire page. Or you can the user agent of ones listed in the list like
 Googlebot/2.1 (+http://www.google.com/bot.html)

or
DuckDuckBot/1.1; (+http://duckduckgo.com/duckduckbot.html)

and should also see the pre-rendered version.
Observe the time for the first request to the path and the second for testing the cache. The second should be much lower.
Types of changes

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

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[ ] I've added relevant tests.

@mikes-gh  I'd say we merge and test it with dev.mudblazor.com ?

@henon Lets publish it to test first?

@just-the-benno Great job.  Can you check https://mudblazor-test.azurewebsites.net/components/table?force-prerender=true
It seems the prerendered page doesnt include the subcontents section which appears to render twice after the cache page has been served.

I think the concept is sound. However, there are some issues around the content. You can see that the app bar is also empty. I have some ideas about why and will investigate. Thanks for the feedback and testing @mikes-gh.

After some research and tries I can explain the general issue here.
Some components like MudHidden have significant logic inside the OnAfterRender or on OnAfterRenderAsync method. However, in pre-rendering this method are not called. That is the reason, why we can't see a content navigation or the app bar. I've tried a few different "counter measures" but they all ending up being incomplete and having drawings on their own.
My suggestion, though, is to proceed, merge and see the results. Yes, the sites are incomplete, but not as "bad" as it is now. If this approach proves to be a solution, we can think about better "renderes" like headless browser to make a snapshot of the final pages and serve them to crawlers.
In general, being aware of this behaviour should influence us, when we rewriting or inventing new components.
I think, despite the issues, we should merge it.


Resorting data order after initial upload

I could see a way to order the measurements uploaded after the initial upload being useful for my research tracking surface topography over time. For example, I uploaded in the order 3,1,2 and I want to reorder them in 1,2,3 so 1 plots the darkest and 3 plots the lightest when running calculations later. At the moment, my only solution is to be very careful uploading the first time, and not uploading in batches

This is in an interesting suggestion. We haven't really thought about this in a structured manner.
Right now, the topographies in the upload view are sorted by name, i.e. they will reorder when you load the page.
The ones in the results plots probably show by upload order.
It would be easy to add some form of sort index, i.e. give the user control over the sort order. I can see why this would be useful. I'll but this on our to do list.


Adding Comments Section (Implementation Details)

Each event will have a comment section whereby users can interact with other users

The comment section is stored as a string for each event in the eventmanager.xml file in the data folder. The users of this application can add and reply comments and the admin can add, reply and delete comments.
A Comments class is created in the logic folder to parse and build comments to be stored in the eventmanager.xml file.
AddComment, DeleteComment and ReplyComment class inherit from the Comments class to fulfil their specific function.
AddComment has the addComment(String comment) function to add a comment to the end of the comments section.
DeleteComment has the deleteComment(int line) function to delete a comment at the given line parameter.
ReplyComment has the replyComment(String comment, int line) function to reply a comment at the given line parameter.


test removing s3 trigger in dev deployment

renamed the branch to test it in dev

@richaagarwal if this change also makes sense to you we can merge it

@potating-potato I am fine if you want to proceed based on Draga's review, especially given this is blocking releases at the moment. See this comment - https://github.com/chanzuckerberg/napari-hub/pull/583#discussion_r906290478 - I can set up additional time with either you or Draga to understand this a little better; right now I'm confused about which lambdas control which functions.


Remove usage description from plugin.xml

Closes #597

In Apache plugins we did major, but as people using some of the Apache plugins will already have the edit-config for the camera usage description now, I think it's less breaking change at this moment.


Update hooks-faq.md

I tripped up slightly while reading this example for using the callback form of a state setter inside an effect. I've added a few lines that might help a hook newbie grok the differences between the examples.

Sorry, copyediting myself here...

Thanks that is helpful


Code freezes when trying to open file with a lot of strings

Issue Type: Bug
I have a source c++ file with one variable that has a lot of concatenated strings. When I try to open it Code just hangs/freezes until a message box appears to wait, retry or close.
I try with the all the extensions disabled but no luck. It freezes. In other editor such as Visual Studio or Notepad++ don't have this problem.
I try  to have all the "substrings" in just one big string but It still freezes.
Perhaps is too big for Code the value of this variable?
Thank you.
VS Code version: Code 1.36.0 (0f3794b38477eea13fb47fbe15a42798e6129338, 2019-07-03T13:25:46.372Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (8 x 2592)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwareoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_deferred_display_list: disabled_offskia_renderer: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.86GB (2.87GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (25)

Extension
Author (truncated)
Version

Bookmarks
ale
10.4.4

clipboard-history
Anj
1.0.7

doxdocgen
csc
0.5.0

githistory
don
0.4.6

gitlens
eam
9.8.2

auto-close-tag
for
0.5.6

gc-excelviewer
Gra
2.1.32

todo-tree
Gru
0.0.138

vscode-edit-csv
jan
0.0.12

plantuml
jeb
2.11.1

sftp
lix
1.12.7

vscode-language-pack-es
MS-
1.36.2

remote-containers
ms-
0.66.0

remote-ssh
ms-
0.44.0

remote-ssh-edit
ms-
0.44.0

remote-ssh-explorer
ms-
0.44.0

remote-wsl
ms-
0.38.7

vscode-remote-extensionpack
ms-
0.15.0

cpptools
ms-
0.24.0

vs-keybindings
ms-
0.2.0

qub-xml-vscode
qub
1.2.8

vscode-qt-for-python
sea
0.3.0

vscode-hexdump
sle
1.7.2

shell-launcher
Tyr
0.3.0

debug
web
0.23.1

[problem.zip](https://github.com/microsoft/vscode/files/3362589/problem.zip)

Looks like this issue is duplicate of #76710

@fazaldegui This should be fixed upstream with version 1.12.15 of https://marketplace.visualstudio.com/items?itemName=jeff-hykin.better-cpp-syntax.
if you want the changes immediately, install the Better C++ Syntax extension
if you're okay with waiting a few days, you can use the VS Code Insider's release
if you're okay with waiting a while, the changes will eventually be pulled into VS Code stable

Thank you :)


Global Planner: update obstacle avoidance interface

This PR brings the new obstacle avoidance interface on the global planner

I tried this, but somehow it never advances to the first mission item after takeoff. Similar to the corner case we found with the local planner, but more consistent. Do you experience this too?

I'll look into it

Hey guys, @nicovanduijn @mrivi. Do either of you plan to have a look at this soon?

I've been using it in SITL and it works just fine. I'm not doing any actual flight testing these days, so I can't do that.
Not sure if this is a priority for @mrivi or @baumanta, but it would of course be nice to support the global planner again at some point

Is the mission getting stuck issue still present with the latest Firmwares changes?

@mhkabir no, it's solved

@baumanta @mrivi What is the status of this PR?

@LorenzMeier it has been used in simulation by @nicovanduijn for his thesis but it has never been tested on hardware

I think we should merge this.
The global planner hasn't been flight-tested in so long that without this, it won't even be testable (using the offboard & RViz is just a pain), and this pr at least brings it into a state that works in SITL and is somewhat in sync with the local planner in terms of the interface.
LGTM


Vector config for consul and vault observability

Added configs to collect metrics and logs from vault and consul clusters and ship them to Grafana.

:+1:


Grayscale toggle

Right now the map is in grayscale by default, but it would be nice to have a toggle for swapping between color and grayscale. This is controlled by a css rule in the MapContainer.vue file: https://github.com/willismonroe/anax/blob/efb244ab3e06afc8c12f587f75a7bc5240e82d13/src/components/MapContainer.vue#L143-L145

Hey @willismonroe, I am new to the community and I am interested in working on this issue. Please assign this issue to me.

Hi @snehalchaudhari98 submit a PR and I'll assign it to you. Have you tried running the project locally?

Can I work on this?

Hello @willismonroe i have added the button To Toggle Color of Map
Link of Repo:-https://github.com/DeepakSaini420/anax

@DeepakSaini420 You duplicated the onMounted function, it would be better to keep everything in one call. Also in Vue you don't need to use document.getElementbyID, you can just use ref's

Hey, I have submitted a PR request. Kindly take a look and let me know how I can improve.


PLT-910: babbage technical debt

It's probably best to review this commit by commit, since the changes are not related.

Pre-submit checklist:

Branch

[ ] Tests are provided (if possible)
[x] Commit sequence broadly makes sense
[x] Key commits have useful messages
[x] Formatting, PNG optimization, etc. are updated

PR

[x] Self-reviewed the diff
[x] Useful pull request description
[ ] Reference the ADR in the PR and reference the PR in the ADR (if revelant)
[x] Reviewer requested

I think the only thing I see missing is the name changes of some constraints in TxConstraints in order to have them be more consistent.
The ones is spotted are:
mustPayToTheScript -> mustPayToTheScriptWithDatumHash
mustPayWithDatumToPubKey -> mustPayWithDatumHashToPubKey
mustPayWithDatumInTxToPubKey -> mustPayToPubKeyWithDatumInTx
mustPayWithInlineDatumToPubKey -> mustPayToPubKeyWithInlineDatum
mustPayWithDatumToPubKeyAddress -> mustPayToPubKeyAddressWithDatumHash
mustPayWithDatumInTxToPubKeyAddress -> mustPayToPubKeyAddressWithDatumInTx
mustPayWithInlineDatumToPubKeyAddress -> mustPayToPubKeyAddressWithInlineDatum
mustPayToOtherScript -> mustPayToOtherScriptWithDatumHash
mustPayToOtherScriptAddress -> mustPayToOtherScriptAddressWithDatumHash
mustPayToAddressWithDatum -> mustPayToAddressWithDatumHash

@koslambrou Ah, I misread that part of the ticket and wanted to discuss with you, but now it's clear, thanks!

@koslambrou Done. Can you do a quick re-review?


Unable to configure SSL

Describe Your Problem:

Hello, when I add the ssl configuration to my JSON, there appears to be no change in behavior. The site fails to load when specifying HTTPS. The HTTP version continue to load. This persists after restarting homebridge, computer, etc.
Logs:

Show the Homebridge / Homebridge Config UI X logs here.
 {
            "platform": "config",
            "name": "Config",
            "port": 8080,
            "restart": "sudo -n systemctl restart homebridge",
            "ssl": {
                "key": "/private/etc/apache2/ssl/idanemacminiprivkey.key",
                "cert": "/private/etc/acpach2/ssl/idanemacminicertificate.crt"
            },
            "log": {
                "method": "file",
                "path": "/Users/danewallace/.homebridge/logfile.log"
            }
        },

**Homebridge Config:**

```json
Show your homebridge config.json here

Screenshots:

Environment:

Node.js Version:
12.7.0

NPM Version:
6.10.3

Homebridge Version:
0.4.50

Homebridge Config UI X Version:
Current

Operating System: Raspbian / Ubuntu / Debian / Windows / macOS / Docker / other
macOS Mojave (current)

Process Supervisor: Docker / Systemd / init.d / pm2 / launchctl / other / none
launchctl

While I don't use the SSL feature myself; I have just tested this feature and confirmed it is working.
Please check certificate and key file paths are correct and you have a valid certificate (self signed is ok).
How I tested:
Create self signed cert:
openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem

Updated config:
"ssl": {
    "key": "/Users/username/.homebridge/key.pem",
    "cert": "/Users/username/.homebridge/certificate.pem"
}

Restart Homebridge. Browser to https://localhost:8080. Accept self signed certificate warning.

Ah, must have had an issue with the file extensions. Once they were both output as .pem files everything seemed to fall into place. Thanks for the help.


Add support for Airthings Renew

Hi!
I'm interested in adding support for the Airthings Renew.

If this is not the right repo, please let me know. If it is, I wish I could have just submitted a PR outright, but I'll need a bit of help on where to look, and how to test things (both BLE and the integration with Home Assistant).

I've already gotten some Bluetooth output from Bluetility about the device [1].
I have not registered the device to an Airthings account.
I am pretty comfortable setting up the testing environment with the instructions provided.

Output from Bluetility [1]
Peripheral: Renew AP-1 didDiscoverCharacteristics: [Model Number String, Manufacturer Name String, System ID, Serial Number String, Firmware Revision String, Hardware Revision String, Software Revision String] for: Device Information
Peripheral: Renew AP-1 didUpdateValueFor: Model Number String to: 343130
Peripheral: Renew AP-1 didUpdateValueFor: Manufacturer Name String to:<PHONE_NUMBER>696E6773204153
Peripheral: Renew AP-1 didUpdateValueFor: System ID to: <system ID>
Peripheral: Renew AP-1 didUpdateValueFor: Serial Number String to: <serial number>
Peripheral: Renew AP-1 didUpdateValueFor: Firmware Revision String to: 482D5749462D312E302E32
Peripheral: Renew AP-1 didUpdateValueFor: Hardware Revision String to:<PHONE_NUMBER>
Peripheral: Renew AP-1 didUpdateValueFor: Software Revision String to: 312E302E30

Peripheral: Renew AP-1 didDiscoverCharacteristics: [B42EB73A-ADE7-11E4-89D3-123B93F75CBA, B42EB9F6-ADE7-11E4-89D3-123B93F75CBA, B42EBC9E-ADE7-11E4-89D3-123B93F75CBA] for: B42EB4A6-ADE7-11E4-89D3-123B93F75CBA

Congratulations on your new Renew device! 🎉 As you've mentioned, the device does support BLE, but it doesn't provide any sensor data or allow for changing/reading modes over BLE.


Config plugin bug with array of string (║24 & only one element recive)

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?
Ref: https://github.com/alexandreh2ag/traefik-ipfilter-basicauth/issues/3
I use my own plugin https://github.com/alexandreh2ag/traefik-ipfilter-basicauth/releases/tag/v1.0.3 with config like :
type BasicAuth struct {
	Users        []string `json:"users,omitempty"`
	UsersFile    string   `json:"usersFile,omitempty"`
	Realm        string   `json:"realm,omitempty"`
	RemoveHeader bool     `json:"removeHeader,omitempty"`
	HeaderField  string   `json:"headerField,omitempty"`
}

type IPWhiteList struct {
	SourceRange []string `json:"sourceRange,omitempty"`
}

// Config the plugin configuration.
type Config struct {
	BasicAuth   BasicAuth   `json:"basicAuth,omitempty"`
	IPWhiteList IPWhiteList `json:"ipWhiteList,omitempty"`
}

http:
  middlewares:
    auth:
      plugin:
        auth:
          basicAuth:
            realm: "Test"
            useAuthCustomHeader: true
            headerField: "X-Test-Authorization"
            users: ["test:test"]
          ipWhiteList:
            sourceRange:
              - "<IP_ADDRESS>/27"
              - "<IP_ADDRESS>"

I except a value of struct Config in func New (ctx context.Context, next http.Handler, config *Config, name string) (http.Handler, error):
Config:
    IPWhiteList:
        SourceRange: []string{"<IP_ADDRESS>/27", <IP_ADDRESS>"}

What did you see instead?
I got a value of struct Config in func New (ctx context.Context, next http.Handler, config *Config, name string) (http.Handler, error):
Config:
    IPWhiteList:
        SourceRange: []string{"║24║<IP_ADDRESS>/27║<IP_ADDRESS>"}

I think this issue was introduce with #8885.
What version of Traefik are you using?
This issue occurred since v2.8.2 and my plugin work with v2.8.1 and lower.
What is your environment & configuration?
static config
accessLog: {}
api:
  dashboard: true
  insecure: true
entryPoints:
  traefik:
    address: <IP_ADDRESS>:8080
  web:
    address: <IP_ADDRESS>:80
experimental:
  localPlugins:
    auth:
      moduleName: github.com/alexandreh2ag/traefik-ipfilter-basicauth
global:
  checkNewVersion: false
  sendAnonymousUsage: false
log:
  level: DEBUG

providers:
  file:
    directory: ./config
    watch: true

dynamic config
http:
  middlewares:
    auth:
      plugin:
        auth:
          basicAuth:
            realm: "Test"
            useAuthCustomHeader: true
            headerField: "X-Test-Authorization"
            users: ["test:test"]
          ipWhiteList:
            sourceRange:
              - "<IP_ADDRESS>/27"
              - "<IP_ADDRESS>"

  routers:
    traefik_dashboard_http:
      entrypoints:
        - web
      middlewares:
        - auth@file
      rule: "Host(`localhost`)"
      service: api@internal

If applicable, please paste the log output in DEBUG level
Log provided by my code:
ERRO[2023-01-03T18:35:16+01:00] cannot parse CIDR whitelist [║24║<IP_ADDRESS>/27║<IP_ADDRESS>]: parsing CIDR trusted IPs <nil>: invalid CIDR address: ║24║<IP_ADDRESS>/27║<IP_ADDRESS>  routerName=traefik_dashboard_http@file entryPointName=web

Hello,
Can you provide your Traefik version?

Hello @ldez,
Yes, i use v2.9.6 but the issue started with v2.8.2.

Hello,
I found that the problem occurred when []string is in a nested struct.
This is not working:
type IPWhiteList struct {
	SourceRange []string `json:"sourceRange,omitempty"`
}

type Config struct {
	IPWhiteList IPWhiteList `json:"ipWhiteList,omitempty"`
}

This is working:
type Config struct {
	SourceRange []string `json:"sourceRange,omitempty"`
}

Fixed by #9671


[BUG] libpq.so.5: cannot open shared object file

User job failing using the databricks container:  libpq.so.5: cannot open shared object file: No such file or directory
we likely need to install postgresql

Note this was on an older 22.10 released version, I see we pull libpq-dev so see if that satisfies it.

nope, looks like we temporarily put in libpq-dev but then purge it.  I think we need to install libpq5 to get this library.


Replaced Android Client Id with Web Client Id

Codecov Report

Merging #57 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #57   +/-   ##
=========================================
  Coverage     71.49%   71.49%
  Complexity      435      435
=========================================
  Files            60       60
  Lines          2421     2421
  Branches        247      247
=========================================
  Hits           1731     1731
  Misses          619      619
  Partials         71       71

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 3f6ea12...e15ba36. Read the comment docs.


Run the generated WebApi project error.

System Information (please complete the following information):

Model Builder Version (available in Manage Extensions dialog): <IP_ADDRESS>1701
Microsoft Visual Studio Enterprise 2022 (64-bit) Version 17.1.0

Describe the bug

On which step of the process did you run into an issue: Run the generated WebApi project
Clear description of the problem: closed the Microsoft Visual Studio dialog and re-run the project, this issue not occurs.

To Reproduce
Steps to reproduce the behavior:

Select Create a new project from the Visual Studio 2022 start window;
Choose the C# Console App (.NET Core) project template with .Net 6.0;
Add model builder by right click on the project;
After trained;
Add WebApi project to solution on Consume page;
Run the generated WebAPI project, prompts Microsoft Visual Studio box said: Object reference not set to an instance of an object.

Expected behavior
No error when running the generated WebAPI project.
Screenshots

Additional context
Add any other context about the problem here.

Looks like the error is from model builder, not web api project.

The bug is also repro on the latest main branch version: <IP_ADDRESS>6001 for VS2022.

@beccamc the bug is still repro on the latest main branch <IP_ADDRESS>5901 for VS2022.

@beccamc The bug has been fixed on the latest main branch <IP_ADDRESS>6601 for VS2022.


[Bug] These links are no longer working needs to be reviewed and updated/removed

File Full Path
Issues

./07-building-chat-applications/python/aoai-assignment.ipynb
1. https://aka.ms/airangers?WT.mc_id=academic-105485-koreyst

./07-building-chat-applications/python/oai-assignment.ipynb
1. https://aka.ms/airangers?WT.mc_id=academic-105485-koreyst

fixed by https://github.com/microsoft/generative-ai-for-beginners/pull/371


Update ruby from 3.3.1 to 3.4.0 and rubygems from 3.5.16 to 3.6.0

What are you trying to accomplish?

Anything you want to highlight for special attention from reviewers?

How will you know you've accomplished your goal?

Checklist

[ ] I have run the complete test suite to ensure all tests and linters pass.
[ ] I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
[ ] I have written clear and descriptive commit messages.
[ ] I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
[ ] I have ensured that the code is well-documented and easy to understand.

Closing this for now. Will reopen once #10250 is merged.


UCD-Agent offline after container restart

If I do a restart of the UDC Agent Container, then the previous Agent connection in UDC Deploy Server is offline and a new agent is automatically registered. In Description with the message "Error: New name agent-0f475ec59174 is already in use by another agent". Is there no way to connect the initially created agent?
Thanks for helping.
Regards
Peter

Hi @s3n29t,
This issue is being resolved with pull request #11!
-Nick

Today DockerHub UCD v<IP_ADDRESS>.929926 images have been released and PR #11 has been merged. Now you can specify an AGENT_NAME environment variable to persist agents between docker starts and stops.

This needs to be re-opened. #11 did not fix this. The agentStart.sh file used for the container entrypoint removes the agent.id property as the very first step.
This causes a new agentID to be generated on each container start, which still triggers the autogeneration of a new agent resource using agent-[agent.id] as the agent name in the uc server resource list.

If you uncomment line 24 in the docker-compose.yaml file and then rebuild the docker-compose containers, does that resolve your issue? You can give the agent any name you would like.
Uncomment this line:
https://github.com/IBM-UrbanCode/UCD-Docker-Images/blob/222ae2de6be40fe21ecfe1f876c20c05f60b20b3/compose/Deploy/docker-compose.yaml#L24
By default, an agent without an id will generate a new id on each agent start time. Therefore, by giving it a name, it will have an ID to associate with it's configuration.


wtforms is not xhtml-compatible

Documentation says:
"Widgets are classes whose purpose are to render a field to its usable representation, usually XHTML"
All input-elements generated by wtforms are invalid xhtml, because /> is missing (<input ...> vs <input ... />).  Required-attributes are also invalid.

Happy to  consider a PR that changes it to "HTML".

How about making wtforms really xhtml-compatible? it would not need many changes. I am having trouble because of this incompatibility. For earlier wtforms there was a
Flask-WTF-Polyglot -library that fixed this but it does not work with the new version of wtforms.

We don't plan to support XHTML at this time. We will focus on HTML only.

If it helps, the WTForms-Polyglot and Flask-WTF-Polyglot packages should now work with WTForms 3.x.


Validation fails on an empty list

The following model validation fails on an empty list:
import polars as pl
from patito import Model

class TestModel(Model):
    list_field: list[str]

df = pl.DataFrame({"list_field": [["a", "b"], []]})
TestModel.validate(df)

With the error message:
DataFrameValidationError: 1 validation error for TestModel
list_field
  1 missing value in lists (type=value_error.missingvalues)

I would expect an empty list to validate as list[str], at least Pydantic thinks so:
from pydantic import BaseModel

class TestPydanticModel(BaseModel):
    list_field: list[str]

TestPydanticModel(list_field=[])  # happy

Changing to list_field: list[str | None] passes validation.

Can you rerun this from the master branch instead of the latest release and see if this is still an issue? If not, this should be a pretty easy fix.

Ok I confirm this is present on main. Thank you for raising this.


Exporting only specific metrics from detailed index metrics

Hi, I know this might not be a standard use case, but I will try to ask anyways.
When exporting detailed metrics, the size of a scrape is pretty large in our case and of course grows with more indices.
We don't want to "throw" the metrics away on the prometheus/vicotriametrics level, as this doesnt solve the issue with very large metrics (even hitting some thesholds in prometheus resulting in errors) .
Isn't it somehow possible to export detailed metrics, but lets say only one single metric, example: doc count per index ?
Regards,
Michal

Hi @hagaram,
I know that we need to make the metric pulling more flexible because there are limitations on metric stores and sooner or later these are hit as the OpenSearch cluster grows. So the idea that all metrics can be pulled within a single request/response does not fit a lot of practical use cases. I was playing with an idea to make it possible to pull various metric sets at various intervals because "Not all metrics are born equal".
In a short term I think there should be a way how to help you. There is an indices filter config option that you can use to get info about specific indices only. At this point this filter is config level only but it shouldn't be hard to allow for this filter to be overridden by URL parameter.
What that means is that then you could define several targets for scraping in Prometheus and each would be using a different mask to include a different "slice of indices". For instance you could defined three targets each using distinct index name mask like: ["product-", "catalog-", "system-*"].
Then the amount of metrics that is pulled from OpenSearch would not be matter of configuration of the plugin but configuration in Prometheus.
WDYT?


[BUG] Vue and Svelte CSUI inline-mount not working

What happened?
When using CSUI mount feature with vue or svelte, they don't mount onto the right place!
Version
Latest
What OS are you seeing the problem on?
No response
What browsers are you seeing the problem on?
No response
Relevant log output
No response
(OPTIONAL) Contact Details
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate problems.

https://github.com/hehehai/packclue/blob/main/src/contents/plasmo-inline.vue

Svelte works - you just need to make sure it's a module! (this ways, svelte compiles the source into module instead of single class)
Example updated:
https://github.com/PlasmoHQ/examples/blob/main/with-svelte/contents/plasmo-inline.svelte#L1-L11

https://github.com/PlasmoHQ/examples/blob/dc2b935966b17a6f5e87e22bd93f61ebbbe6a0c2/with-svelte/contents/plasmo-inline.svelte#L1-L11

Vue is also now working - you must use the option API and export a plasmo object with all the plasmo-related CSUI functions for this to work!
Example:
https://github.com/PlasmoHQ/examples/blob/main/with-vue/contents/plasmo-inline.vue#L22-L36


Clarify Conditional Access controls

Please clarify on the Conditional Access Policy Controls. The article states

For this feature to not trigger on a managed device, an eligible Azure AD Premium P1 or P2 subscription, and a specific Conditional Access policy, is required. See below for further details.

But there are no further details below regarding "not triggering on managed devices". Instead the following paragraph is about "Idle session timeout on unmanaged devices".

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

ID: ccb07d88-8193-95d8-0e19-aa96f2d1668c
Version Independent ID: ccb07d88-8193-95d8-0e19-aa96f2d1668c
Content: Idle session timeout for Microsoft 365 - Microsoft 365 admin
Content Source: microsoft-365/admin/manage/idle-session-timeout-web-apps.md
Service: o365-administration
GitHub Login: @KwekuA
Microsoft Alias: kwekua

@diecknet Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/9132
Once the author approves, the changes will be live.
Thanks
Sri

This still does not make sense with the new PR.
The changed section still refers to "for this feature to not trigger on an unmanaged device...a specific Conditional Access policy is required. See below for further details."
The next section, "Idle session timeout on unmanaged devices" reads "for idle session timeout to get triggered on unmanaged devices, you'll need to add a Conditional Access policy."
So which is it? For idle session timeout on unmanaged devices, is the CA policy required for it to work at all? Or is a CA policy required to exempt specific users/situations?

@msbemba

@msbemba Thank you very much for the contribution and updating the documentation with PR. @diecknet Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Replace rand with ark_std::rand

Description
This PR replaces all the use of rand with ark_std::rand.
In addition, XorShiftRng is likely outdated and should be replaced by ark_std::test_rng. This PR also makes this change.

[x] Targeted PR against correct branch (master)
[x] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[x] Wrote unit tests
[x] Updated relevant documentation in the code
[x] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[x] Re-reviewed Files changed in the Github PR explorer

Amazing, thanks for this!


No support for MySQL INSERT IGNORE.

The idiomatic way to insert a record, falling back to a noop if the record is a duplicate, is to prepend the INSERT statement with IGNORE. I’m happy to take a shot at implementing this, though I might need a degree of guidance regarding the internals.
cc @tclem, who ran into this.

There are a couple of permutations of this. As an alternative to INSERT IGNORE you can also use REPLACE. It's also possible to define what to do on duplicate key with INSERT INTO .. VALUES .. ON DUPLICATE KEY UPDATE ...


Update mesa-geo to sync with mesa >=2.3.0

update to geoagent, tile_layers,raster_layers pass in mesa.Model so compatible with AgentSets
update visualization to use solara with Jupyter_viz and leaflet_viz
remove js visualization
update tests

Since the code is functional anyway, rather than having this in PR limbo due to the blocker being lots of boilerplate code, I'd rather approve this and then refactor later.

I am okay with this being merged after conflicts are resolved.

Apologies, I need to close this an reopen to fix the history conflicts so it can be merged.

Thanks for this effort!
On a bit wider note, I am (still) a proponent of moving towards a monorepo. See:

https://monorepo.tools/
Misconceptions about Monorepos: Monorepo != Monolith


Unable to specify a double quote in a string default value

Bug description
I am unable to specify a " character in a string default value in the Prisma schema.
How to reproduce
model MyTable {
  id                         Int                    @id @default(autoincrement())
  myColumn                   String                 @default("unable to specify a double quote in this string")
}

@default('"') is invalid
@default("\"") is invalid
@default("""") is invalid
Expected behavior
There should be a way to specify a double quote in a string default value.
Prisma information
model MyTable {
  id                         Int                    @id @default(autoincrement())
  myColumn                   String                 @default("unable to specify a double quote in this string")
}

No client queries yet because I am unable to write a valid Prisma schema.
This is actually a simplified reproduction of my use case which is a Postgres Jsonb column:
myColumn              Json                   @default("{'1': {}, '2': {}, '3': {}, '4': {}}")
This is valid Prisma, but will result in invalid JSON. It should be {"1": {}, "2": {}, "3": {}, "4": {}} but I am unable to specify this in the schema.
My current workaround is letting the migrate fail, then hand-editing migration.sql to have the correct default value.
Environment & setup

OS: Mac OS
Database: PostgreSQL
Node.js version: v15.6.0

Prisma Version
prisma               : 2.29.1
@prisma/client       : 2.29.1
Current platform     : darwin
Query Engine         : query-engine 1be4cd60b89afa04b192acb1ef47758a39810f3a (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli 1be4cd60b89afa04b192acb1ef47758a39810f3a (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core 1be4cd60b89afa04b192acb1ef47758a39810f3a (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt 1be4cd60b89afa04b192acb1ef47758a39810f3a (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : 1be4cd60b89afa04b192acb1ef47758a39810f3a
Studio               : 0.419.0

Another instance of https://github.com/prisma/prisma/issues/4167

I wrote a test to try to reproduce this problem in https://github.com/prisma/prisma-engines/pull/2260 — additionally, I checked that we do already have a test for migrate that this works, so I'm a bit at a loss about fixing this. Can you still reproduce the issue with a recent (3+) version of Prisma?

I'm not sure this is the fix, since I haven't tried reproducing the issue on 2.29. I'll spend some time doing that.

Ok I did try with 2.29.1, and \" seems to work. My schema:
datasource db {
    provider = "sqlite"
    url = "file:dev.db"
}

model MyTable {
  id                         Int                    @id @default(autoincrement())
  myColumn                   String                 @default("unable to specify a \"double quote in this string")
}

It passes validation. I also created and applied a (sqlite) migration:
-- CreateTable
CREATE TABLE "MyTable" (
    "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    "myColumn" TEXT NOT NULL DEFAULT 'unable to specify a "double quote in this string'
);

which applies cleanly.
I then did the same on postgres:
-- CreateTable
CREATE TABLE "MyTable" (
    "id" SERIAL NOT NULL,
    "myColumn" TEXT NOT NULL DEFAULT E'unable to specify a "double quote in this string',

    PRIMARY KEY ("id")
);

Which also seems to apply cleanly.
prisma               : 2.29.1
@prisma/client       : Not found
Current platform     : debian-openssl-1.1.x
Query Engine         : query-engine 1be4cd60b89afa04b192acb1ef47758a39810f3a (at<EMAIL_ADDRESS>Migration Engine     : migration-engine-cli 1be4cd60b89afa04b192acb1ef47758a39810f3a (at<EMAIL_ADDRESS>Introspection Engine : introspection-core 1be4cd60b89afa04b192acb1ef47758a39810f3a (at<EMAIL_ADDRESS>Format Binary        : prisma-fmt 1be4cd60b89afa04b192acb1ef47758a39810f3a (at<EMAIL_ADDRESS>Default Engines Hash : 1be4cd60b89afa04b192acb1ef47758a39810f3a
Studio               : 0.419.0

Can you still reproduce the problem on 2.29.1?

i just checked, and it \" does indeed seem to work
i'm mystified now as to why it wasn't working in the first place... closest i can figure is maybe it was working the whole time but vscode mistakenly showed it as invalid
apologies for the wild goose chase

No problem, glad it's working now :) One possible explanation is that you maybe had an old version of the vscode extension. We definitely had problems with string literal escaping in the Prisma Schema Language in the past because they're ill defined (it's a bit of a pet peeve of mine), so it's likely that it didn't work until a few months ago.


Digital miners start themselves after server reboot

I've watched this happen multiple times.  If you stop a digital miner, and then reboot a server, the digital miner will start itself and begin mining.

Fixed!


Sieve of Eratosthenes method, for computing prime number

Algorithm:
In mathematics, the sieve of Eratosthenes is an ancient algorithm for finding all prime numbers up to any given limit.
It does so by iteratively marking as composite (i.e., not prime) the multiples of each prime, starting with the first prime number,
The multiples of a given prime are generated as a sequence of numbers starting from that prime, with a constant difference between them that is equal to that prime.
This is the sieve's key distinction from using trial division to sequentially test each candidate number for divisibility by each prime.
Languages Supported:
Python.

C
C++ [ Assigned to @asaxena012 ]
Java
Javascript
Python [ Assigned to @keshav304 ]

I would like to work on this issue using Python.

@HarshCasper @ricardoprins Please assign this issue to me in C++. Thanks.

Thanks for making this Issue @keshav304 and carrying the true spirit of Open-Source 👀
I have assigned the Issue in C++ to @asaxena012 and in Python to @keshav304. You can start working on it now.

@HarshCasper I would like to work in java.

I would like to take this issue in C.

Whoever is working on this, you'll get a special mention if you implement not only the original sieve, but also some of its variations :D

@Himanshu70565 and @atarax665 , game on!