Use the latest build-deploy controller and update active-standby task to use patch

Checklist

[ ] Affected Issues have been mentioned in the Closing issues section
[ ] Documentation has been written/updated
[ ] PR title is ready for changelog and subsystem label(s) applied

This brings the lagoon build-deploy controller up to be the latest version with fixes for using the lagoon-deployer token to create task pods, and also updates the active-standby task to use a patch operation instead of update.

@shreddedbacon - we need this against main too, don't we?

@tobybellwood yes, probably. But main also needs a bunch of other stuff still...


Introduce login button for mobile users

Description:
Currently, the login button is not visible on the mobile page, which creates difficulty for mobile users to access the login page. To improve user experience, it is recommended to introduce a login redirect button that is clearly visible and accessible on the mobile page to direct users to the login page seamlessly.
Why:
Enhance the accessibility and usability of the platform for mobile users.

It appears that this issue has been resolved. I am leaving a comment for notification purposes.

@devysi0827
Sorry, but it seems this issue is related to the yorkie-team/yorkie-team.github.io repository. I have clarified this bug and created a new issue here: https://github.com/yorkie-team/yorkie-team.github.io/issues/146. Please refer to that issue.
I will close this issue now.


Security regression in Devise 4: plain text confirmation tokens?

Hey,
In Devise 3, confirmation tokens were one-way encrypted:
http://blog.plataformatec.com.br/2013/08/devise-3-1-now-with-more-secure-defaults/
In Devise 4 this appears not to be the case - friendly_token is used in the generate_confirmation_token method instead, which is the same value sent out by the mailer - thus the plaintext token is stored in the db. I can't find anything to explain why this change was made (or even anything documenting that the change happened. No mention in CHANGELOG.MD) , and it seems like a security regression?
Is the best 'solution' to override the generate_confirmation_token method in my resource model?

https://github.com/plataformatec/devise/commit/d122faf410e0d6f7589adf9aa624ea4ee5bff8b9
https://github.com/plataformatec/devise/commit/eb640ed344fb5e227e82b1f3a914ca9fabb938e0
Seem to be the relevant commits. Unfortunately the latter doesn't have an explanation of the decision to no longer digest security tokens?

From the PR (#3661) and issue it addresses (#3640) looks to be considered safe primarily because users aren't authenticated after confirmation anymore, so this doesn't give someone access to an account if the plain text confirmation token is compromised.
Password reset tokens etc are still securely stored in the database.

In my application the user is authenticated on confirmation (are you saying this isn't default Devise behaviour?), so a new account can be compromised if the token leaks.

Yeah since 3.1 the default Devise behaviour is not to log users in after confirmation. The threat vector was if the email was compromised, confirming the account allowed an attacker access to that user's (newly confirmed) account automatically, rather than requiring them to subsequently log in, presumably with a password they don't know.
That being said, if they've got access to email, they can just request a password rest token, and get in that way, so not entirely sure what real problem that solved.
Read more here: http://blog.plataformatec.com.br/2013/08/devise-3-1-now-with-more-secure-defaults/
From the above, you can enable sign in after confirmation by adding:
config.allow_insecure_sign_in_after_confirmation = true
To your devise initializer (which perhaps your app has, or maybe you're using Devise < 3.1?).

See issue https://github.com/plataformatec/devise/issues/3640 for more context on why this changed.
Thanks!


DRILL-4574: Avro Plugin: Flatten does not work correctly on record items

See https://issues.apache.org/jira/browse/DRILL-4574

Nice first patch. Thanks for the contribution.
+1
Can you collapse this into a single commit and make sure the commit message matches the Drill style:
DRILL-XXXX: A short description
Longer description....

Done!
On Wed, Apr 13, 2016 at 5:53 PM, Jacques Nadeau<EMAIL_ADDRESS>wrote:

Nice first patch. Thanks for the contribution.
+1
Can you collapse this into a single commit and make sure the commit
message matches the Drill style:
DRILL-XXXX: A short description
Longer description....
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/apache/drill/pull/459#issuecomment-209521505

I ran the unit tests with your pull request on top of the current master branch   One of your new tests failed.  Can you take a look ?
Results :
Failed tests:
AvroFormatTest.testFlattenEmptyComplexArray:394 Different number of records returned expected:<10000> but was:<0>
Tests run: 1743, Failures: 1, Errors: 0, Skipped: 128

@amansinha100 It looks like the expected output of the test is just wrong, flattening an empty array should produce 0 rows.

@amansinha100 Thanks for helping out! As for the empty arrays: This is kind of embarassing: Creating a failing test asserting wrong behaviour that fails and issueing a pull request.
I will update the pull request..

I corrected the test and rebased the current master. Thanks for the input!

Hello Team,
Any lead or help if there is a patch on Drill 1.5 or 1.6 to
support CQL or Cassandra ??
Appreciate your feedback or lead..
Thanks,
Lokesh

@Lceeba can you ask your question on the drill user list instead of in the pull request (you might want to check the mailing list first for prior similar question).

@baunz  unit test looks good now.  +1


Split out library target logic from target.bzl

Moves library target logic into library_targets.bzl

Title is fine. I'll adjust the checker to allow this.


Rule ForbiddenComment - regexp support

I think that the rule ForbiddenComment is not flexible enough. In my case I'd like to flag every usage of TODO,TODO:,etc... but if it contains a ticket number then it should pass the check.
Noncompliant code:
// TODO remove this code later
fun deprecatedFunction() {}

Compliant code:
// TODO DTK-2019 remove this code later

The main difference for me is that I can disallow usage of TODOs unless a task is tracked in any task system.
Does it make sense to have something like that in Detekt or I should create a custom rule?

There's no need to prefix a ticket with TODO. Hence I'd just reference the ticket and leave the todo as is. A ticket implies that there is something missing.

@vanniktech makes sense. I guess I can adjust IDEA to show such comments in the same way it shows TODOs. I'll leave this ticket open if someone has other ideas, but feel free to close it.

Yes you can do that. I'm coloring links for instance:

That might be a new rule, feel free to open an issue for that. It will need reference solving which is not yet used in detekt though.

Is there any way to suppress suppress ForbiddenComment? We have several distinct todo's we dealt
with and bound them to TD tickets. I got @vanniktech 's point that we do not need "todo" in a such kinda of comments. I almost agree with that. However

I worked on a several projects with different teams in different domains and can prove it is a quite common pattern to leave "//TODO TICKET-1234" comments when they agreed upon during a code review stage. It is convenient and has IDE support out of the box.
Given (1) I have to force all team members to share the same IDE config and argue with them on why we can't use an approach they used to use for years.

I agree with @mikekudzin and @AndreiZaitcev here.
Next to values there should be allowedPatterns to handle ticket numbers.


GTA Vice City

GTA Vice City crashes after new game loading screen. Doesn't happen with wined3d.
Software information
GTA Vice City
System information

GPU: R9 380
Driver: 22.2.1
Wine version: WINE-GE 31
D8VK version: https://github.com/AlpyneDreams/d8vk/commit/7cd4c8b37f563c37068be51e92b925730411b6c5

Apitrace file(s)
https://mega.nz/file/50xxXA6T#dgJKdYr781jUSEFGKZEUaZ2F6rtnViZotvfvf2lzz-k
Reproduces in the trace
Log files
gta-vc_d3d9.log
d3d8 empty

Retested with latest master (https://github.com/AlpyneDreams/d8vk/commit/3c701a6b200675eaadab527a443b12ddec5a1a69) just for good measure and it's still an issue.

Latest commit should fix this. Let me know if the game works.

Game is looking good now. Haven't found any issues in my short playtime


Small fix for sparse prior sample

Small fix for when KDE.select_prior_data hits the limit of 20 sigma and doesn't reach the target 100 to compute the prior.

@nielsenmb BTW - The checks are not working again. Is this just because we are back on master and all the fixes are in CPnest branch?

I was wondering about the tests. Is it the test that's failing or something else? To me it just says 'Some checks haven't completed yet', and then 'build (3.6) Expected — Waiting for status to be reported'. I can't see what's wrong.

'build (3.6) Expected — Waiting for status to be reported'. I can't see what's wrong.

Me too - I'm going to ignore for now.
Shall I merge this?

Yep!
On Wed, 25 Mar 2020, 13:50 Guy Davies<EMAIL_ADDRESS>wrote:

'build (3.6) Expected — Waiting for status to be reported'. I can't see
what's wrong.
Me too - I'm going to ignore for now.
Shall I merge this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grd349/PBjam/pull/233#issuecomment-603850240, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AEJWO36SEBPHYM26ZOHHKKDRJID2HANCNFSM4LSAXZ2Q
.


⚠ Bofrost.at has degraded performance

In eceb087, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 934 ms

Resolved: Bofrost.at performance has improved in 1edcb92.


elasticache: cannot create users with passwords

What happened?
The latest provider-aws release (v0.20.0) cannot create Elasticache users with passwords set via .spec.forProvider.passwordsSecretRef.
Apparently such field is not translated into its terraform equivalent here.
How can we reproduce it?

install and configure provider-aws
create the secretkubectl -n crossplane-system create secret generic user-passwords --from-literal pwd-1=mypass1 --from-literal pwd-2=mypass2

apply this example from the git repo or copy it and adjust the AWS region if needed:kubectl apply -f https://raw.githubusercontent.com/upbound/provider-aws/v0.20.0/examples/elasticache/user.yaml

observe the object's status:kubectl get users.elasticache.aws.upbound.io sample-user -o yaml

The LastAsyncOperation condition reportsmessage: "apply failed: error creating ElastiCache User: InvalidParameterValue:
  Input Authentication type: null is not in the allowed list: [password,no-password-required,iam]\n\tstatus
  code: 400, request id: e98ac4d4-66e3-4ebb-839c-be68fdde2416: "
reason: ApplyFailure
status: "False"
type: LastAsyncOperation

which is the same error the AWS CLI returns when trying to create a user with no --passwords nor --no-password-required$ aws elasticache create-user --user-id sample-user --user-name sample-user --engine REDIS --access-string "on ~* +@all"

An error occurred (InvalidParameterValue) when calling the CreateUser operation: Input Authentication type: null is not in the allowed list: [password,no-password-required,iam]

What environment did it happen in?

Universal Crossplane Version: v1.10.1-up.1
Provider Version: v0.20.0
Cloud provider: AWS
Kubernetes distribution: EKS
Kubernetes version: v1.23.13-eks-fb459a0

The issue reproduced.

The relevant upstream issue has been fixed and closed, will test this issue after upgrading the https://github.com/crossplane/upjet

This issue has been fixed with Provider versions 0.47.3 and 1.1.1. I am closing this now, feel free to reopen it if you encounter any issues.


Request textDocument/inlayHint failed with message

[Error - 7:59:09 AM] Request textDocument/inlayHint failed.
  Message: Request textDocument/inlayHint failed with message: A document with the URI 'file:///x/y/z/someFile.someExt' is already present.

@msujew do you have any idea what could cause this?
is it possible there are races?

@cdietrich Yes, it's likely a race condition. I would assume that https://github.com/eclipse-langium/langium/pull/1640 would resolve this.


remove resources we no longer use

Multiple refactors have led to confusing cruft that has a long life on our clusters.  This removes that we don't use or honor

/retest

/retest
Ci flake (release "release-latest" failed: pod release-latest was already deleted)

/lgtm

/retest

/test all


WIP: Prestwich/preflight-gas

Preflight xapp gas requirements

the main blocker for reviewing / merging this PR is getting unit tests ported back into the monorepo so we can check the functionality (@odyslam is working on this rn)

just rebased this onto main :)

made obsolete by https://github.com/nomad-xyz/monorepo/pull/311/files


Add contract implementation with better type support

It would be useful to export a function to actually create contract instances with the ABI based types. This could then be used in the starknet.js and starknet-react libs, providing better type support there. This is what happens when using wagmi, for example.
The usage could be something like:
const contract = getContract(abi, address, account);

const bal = await contract.balanceOf... <-- IDE autocomplete, args validation, and typed return value

Does this make sense? I could open a PR for this feature.

Thanks @tabaktoni
I can see 2 ways of doing this: one is creating the contract instance in this lib, which would imply adding starknet as a dep here. The other is only exporting the type for contract methods, and it would be the responsibility of other libs to use it.
Which do you think would be better?

@tabaktoni ping about the question above :)
Anyway, the project got additional funds for this month so we can proceed with all relevant changes!
cc: @thomas-quadratic

It should be independent lib that should be used by starknetjs or other, without starknet as dep.

Thanks, that makes sense 👍

Is this still relevant ?


Implement auto deriving without derives clause for scala 3

Like circe:
import io.circe.generic.auto._

If we could do this. There will be less boilerplate code.
For example , use tapir to generate openapi, if i use zio-json as json plugin, i have to write at least 10+ gen statement.
I tried to add auto deriving with
 inline given [T: Mirror.Of]: JsonCodec[T] = DeriveJsonCodec.gen[T]

but get a compile error infinite inline loops on recursive structure.

Most likely releated: https://github.com/lampepfl/dotty/issues/8183

Most likely releated: lampepfl/dotty#8183

This might has been solved. Use by name param in product and sum.
def eqSum[T](s: Mirror.SumOf[T], elems: => List[Eq[_]]): Eq[T] =
    new Eq[T]:
      def eqv(x: T, y: T): Boolean =
        val ordx = s.ordinal(x)
        (s.ordinal(y) == ordx) && check(elems(ordx))(x, y)

  def eqProduct[T](p: Mirror.ProductOf[T], elems: => List[Eq[_]]): Eq[T] =
    new Eq[T]:
      def eqv(x: T, y: T): Boolean =
        iterator(x).zip(iterator(y)).zip(elems.iterator).forall {
          case ((x, y), elem) => check(elem)(x, y)
        }

  inline given derived[T](using m: Mirror.Of[T]): Eq[T] =
    lazy val elemInstances = summonAll[m.MirroredElemTypes]
    inline m match
      case s: Mirror.SumOf[T]     => eqSum(s, elemInstances)
      case p: Mirror.ProductOf[T] => eqProduct(p, elemInstances)

Hi do you have a work around to deal with recursive types in Scala 3 ?

Hi do you have a work around to deal with recursive types in Scala 3 ?

I build a codec layer on circe here
liewhite/json

If the request is to bring the Circe import io.circe.generic.auto._ magic to zio-json, I'm pretty much against this request. It makes your code very fragile and is an anti-pattern IMO


a game with ebiten.SetRunnableOnUnfocused(false) doesn't show a window on ChromeOS Linux environment

Ebitengine Version
813e3b28afb154a66bd8d7ffd91aadbd11545a6b
Operating System

[ ] Windows
[ ] macOS
[X] Linux
[ ] FreeBSD
[ ] OpenBSD
[ ] Android
[ ] iOS
[ ] Nintendo Switch
[ ] PlayStation 5
[ ] Xbox
[ ] Web Browsers

Go Version (go version)
go version go1.23.0 linux/amd64
What steps will reproduce the problem?
Apply this change:
diff --git a/examples/keyboard/main.go b/examples/keyboard/main.go
index 3f5b00206..612bf5865 100644
--- a/examples/keyboard/main.go
+++ b/examples/keyboard/main.go
@@ -102,6 +102,7 @@ func (g *Game) Layout(outsideWidth, outsideHeight int) (int, int) {
 }

 func main() {
+       ebiten.SetRunnableOnUnfocused(false)
        ebiten.SetWindowSize(screenWidth*2, screenHeight*2)
        ebiten.SetWindowTitle("Keyboard (Ebitengine Demo)")
        if err := ebiten.RunGame(&Game{}); err != nil {

Then run the "keyboard" example.
What is the expected result?
Keyboard window comes up.
What happens instead?
Program hangs "forever".
Anything else you feel useful to add?
Issue is specific to ChromeOS. It happens neither on Linux/X.org nor on Linux/Wayland/XWayland.
I have not tested, but it might be reproducible if one finds a way to run ChromeOS's "sommelier" server on desktop Linux too.

Confirmed.

Another reproducible case is
go run ./examples/windowsize/ -runnableonunfocused=false

99ffe09b63e0d906cc1f502c24f4d2325e6cc09d should fix the issue.

Thank you!

@divVerent Do you want me to cherry-pick this fix to the stable branch?

Not needed for me in particular - if it'll be in the next major release, this change seems self contained enough that I can keep cherrpicking it on top of the stable releases.
Having said that - it's probably a good idea to merge it into Ebitengine stable, simply because it makes Chrome OS support more reliable in general. Not sure if this also fixes operation with some specific X11 window managers.

Well, then I will not merge the fix, since I cannot say that any changes are 100% safe and the fix itself might cause another issue. Thanks!


Fix: Ec2 - add VPCPeeringConnections region response support.

Fix: Ec2 - add VPCPeeringConnections region response support.

Coverage decreased (-0.01%) to 94.365% when pulling 7a801a888e2b083c326803062ed8dcb0acbb06e2 on ninhkd:add-region-response-vpc-peering-connections into b225e96ae0de5a1bad477df78949073f9249fe4b on spulec:master.


FIXED: Cannot read property 'style' of undefined

FIXED: Cannot read property 'style' of undefined

I also got the same error. I am using current version of react native and react-native-keyboard-spacer.


Support Admonitions

If you get HTML working, then supporting admonitions would be really cool.  Its a feature I have used a lot!
Like Remark Admonitions

@P3N-101 this is indeed the plan. I will work on shortcode support. Which could have admonitions support as well.


Introducing new Error handling in the client

:building_construction: Architectural change
Currently, error handling is a bit messy in the client as it doesn't really follow any guidelines.
The plan

New error reducer - save the errors in the store
The errors will have the following format:

{
  pathname: "/login",
  code: "404",
  message: "Wrong username or password"
}

The containers will do all the error displaying (will use the error store)
The containers will refresh all its errors on mount
Can add, remove, clean errors using actions
All fetch errors will use the ADD_ERROR action instead of simply throwing errors

Some further work that needs to be done later will be to find a way to add more control over the cleaning aspect of the errors. I will merge this for now and improve the error system when it's actually used a bit more.


Documentation enhancement (Still WIP)

moved relevant pieces to https://github.com/ClickHouse/clickhouse-docs/pull/1504


Magic Numbers in Exit Codes

It seems that exit codes are following the BSD Standard.
As shown here (74 For input/output error EX_IOERR)
https://github.com/wren-lang/wren/blob/master/src/cli/vm.c#L56
And here (70 For Internal sofrware error EX_SOFTWARE)
https://github.com/wren-lang/wren-cli/blob/master/src/module/scheduler.c#L29
More info about exit codes here
https://krueger.report/programming/exit-status-codes/
Code List

    0 - Successful termination
    1 - Unspecified error
    2 - (grep) Incorrect command usage | (bash) I/O error
    64 - Command line usage error
    65 - Data format error
    66 - Input is not openable
    67 - Addressee unknown
    68 - Unknown host name
    69 - Service unavailable
    70 - Internal software error
    71 - System error
    72 - Critical OS file missing
    73 - Can no create output file
    74 - I/O error
    75 - Temporary failure
    76 - Remote error in protocol
    77 - Permission denied
    78 - Configuration error
    126 - Command found but not executable
    127 - Command not found
    128 - Invalid exit code
    128 + n - Fatal error signal n, i.e. kill -9 $PPID (128 + 9 = 137)
    130 - Command terminated by Ctrl-C
    255+ - Exit code out of range

I would recommend to include a header file like BSD sysexits.h. So these magic numbers can replaced with a more meaningful alternative.
BSD sysexits.h
/*	$OpenBSD: sysexits.h,v 1.5 2003/06/02 19:34:12 millert Exp $	*/
/*	$NetBSD: sysexits.h,v 1.4 1994/10/26 00:56:33 cgd Exp $	*/

/*
 * Copyright (c) 1987 Regents of the University of California.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the University nor the names of its contributors
 *    may be used to endorse or promote products derived from this software
 *    without specific prior written permission.
   IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 *	@(#)sysexits.h	4.8 (Berkeley) 4/3/91
 */

#ifndef	_SYSEXITS_H_
#define	_SYSEXITS_H_

/*
 *  SYSEXITS.H -- Exit status codes for system programs.
 *
 *	This include file attempts to categorize possible error
 *	exit statuses for system programs, notably delivermail
 *	and the Berkeley network.
 *
 *	Error numbers begin at EX__BASE to reduce the possibility of
 *	clashing with other exit statuses that random programs may
 *	already return.  The meaning of the codes is approximately
 *	as follows:
 *
 *	EX_USAGE -- The command was used incorrectly, e.g., with
 *		the wrong number of arguments, a bad flag, a bad
 *		syntax in a parameter, or whatever.
 *	EX_DATAERR -- The input data was incorrect in some way.
 *		This should only be used for user's data & not
 *		system files.
 *	EX_NOINPUT -- An input file (not a system file) did not
 *		exist or was not readable.  This could also include
 *		errors like "No message" to a mailer (if it cared
 *		to catch it).
 *	EX_NOUSER -- The user specified did not exist.  This might
 *		be used for mail addresses or remote logins.
 *	EX_NOHOST -- The host specified did not exist.  This is used
 *		in mail addresses or network requests.
 *	EX_UNAVAILABLE -- A service is unavailable.  This can occur
 *		if a support program or file does not exist.  This
 *		can also be used as a catchall message when something
 *		you wanted to do doesn't work, but you don't know
 *		why.
 *	EX_SOFTWARE -- An internal software error has been detected.
 *		This should be limited to non-operating system related
 *		errors as possible.
 *	EX_OSERR -- An operating system error has been detected.
 *		This is intended to be used for such things as "cannot
 *		fork", "cannot create pipe", or the like.  It includes
 *		things like getuid returning a user that does not
 *		exist in the passwd file.
 *	EX_OSFILE -- Some system file (e.g., /etc/passwd, /var/run/utmp,
 *		etc.) does not exist, cannot be opened, or has some
 *		sort of error (e.g., syntax error).
 *	EX_CANTCREAT -- A (user specified) output file cannot be
 *		created.
 *	EX_IOERR -- An error occurred while doing I/O on some file.
 *	EX_TEMPFAIL -- temporary failure, indicating something that
 *		is not really an error.  In sendmail, this means
 *		that a mailer (e.g.) could not create a connection,
 *		and the request should be reattempted later.
 *	EX_PROTOCOL -- the remote system returned something that
 *		was "not possible" during a protocol exchange.
 *	EX_NOPERM -- You did not have sufficient permission to
 *		perform the operation.  This is not intended for
 *		file system problems, which should use EX_NOINPUT or
 *		EX_CANTCREAT, but rather for higher level permissions.
 *	EX_CONFIG -- Something was found in an unconfigured or
 *		misconfigured state.
 */

#define EX_OK		0	/* successful termination */

#define EX__BASE	64	/* base value for error messages */

#define EX_USAGE	64	/* command line usage error */
#define EX_DATAERR	65	/* data format error */
#define EX_NOINPUT	66	/* cannot open input */
#define EX_NOUSER	67	/* addressee unknown */
#define EX_NOHOST	68	/* host name unknown */
#define EX_UNAVAILABLE	69	/* service unavailable */
#define EX_SOFTWARE	70	/* internal software error */
#define EX_OSERR	71	/* system error (e.g., can't fork) */
#define EX_OSFILE	72	/* critical OS file missing */
#define EX_CANTCREAT	73	/* can't create (user) output file */
#define EX_IOERR	74	/* input/output error */
#define EX_TEMPFAIL	75	/* temp failure; user is invited to retry */
#define EX_PROTOCOL	76	/* remote error in protocol */
#define EX_NOPERM	77	/* permission denied */
#define EX_CONFIG	78	/* configuration error */

#define EX__MAX		78	/* maximum listed value */

#endif /* !_SYSEXITS_H_ */

Thanks 👍

I am in favor of removing magic numbers, but there are issues on relying on
system dependent includes.
It would be better to define them ourself and mention at definition that
they should (with no guarantee) be compatible with BSD error code.
And in addition these are EX_* which afaik is not POSIX standard.

Ok.  I made this file proposal :)
src/include/wren_sysexits.h
#ifndef wren_sysexits_h
#define wren_sysexits_h

// Based on OpenBSD sysexits.h + Wren Specifics

#define EX_OK               0   /* successful termination */
#define EX_UNKNOWN          1   /* unspecified error */
#define EX__BASE            64  /* base value for error messages */

#define EX_USAGE            64  /* command line usage error */
#define EX_DATAERR          65  /* data format error */
#define EX_NOINPUT          66  /* cannot open input */
#define EX_NOUSER           67  /* addressee unknown */
#define EX_NOHOST           68  /* host name unknown */
#define EX_UNAVAILABLE      69  /* service unavailable */
#define EX_SOFTWARE         70  /* internal software error */
#define EX_OSERR            71  /* system error (e.g., can't fork) */
#define EX_OSFILE           72  /* critical OS file missing */
#define EX_CANTCREAT        73  /* can't create (user) output file */
#define EX_IOERR            74  /* input/output error */
#define EX_TEMPFAIL         75  /* temp failure; user is invited to retry */
#define EX_PROTOCOL         76  /* remote error in protocol */
#define EX_NOPERM           77  /* permission denied */
#define EX_CONFIG           78  /* configuration error */
#define EX_NOTEXECUTABLE    126 /* command found but not executable */
#define EX_NOTFOUND         127 /* command not found */
#define EX_INVALID          128 /*  invalid exit code */
#define EX_KILL             128 /* + n - Fatal error signal n, i.e. kill -9 $PPID (128 + 9 = 137) */
#define EX_SIGINTC          140 /* command terminated by Ctrl-C */
#define EX_SIGINTD          141 /* command terminated by Ctrl-D */

#define EX__MAX             255 /* maximum listed value */

#endif

Do a pull request out of it, also take into consideration that wren cli and
VM will be splitter for next version.

I will wait to hear @underscorediscovery opinion before making a pr. maybe better plans are ahead 👍

I recommend that they should be made enums instead of #defines. It'll become more clear that they are error codes and the chances of someone mixing them up with other codes in the future will be less.

#ifndef wren_sysexits_h
#define wren_sysexits_h

// Based on OpenBSD sysexits.h + Wren Specifics

enum WrenSysExits {

    // Standard Values
    OK              = 0,   // successful termination
    UNKNOWN         = 1,   // unspecified error

    // Meta Values
    MIN             = 0,   // min listed value
    MAX             = 255, // max possible value
    BASE            = 64,  // base value for error messages
    TOP             = 141, // top listed value

    // Wren Specifics
    USAGE           = 64,  // command line usage error
    DATAERR         = 65,  // data format error
    NOINPUT         = 66,  // cannot open input
    NOUSER          = 67,  // addressee unknown
    NOHOST          = 68,  // host name unknown
    UNAVAILABLE     = 69,  // service unavailable
    SOFTWARE        = 70,  // internal software error
    OSERR           = 71,  // system error (e.g., can't fork)
    OSFILE          = 72,  // critical OS file missing
    CANTCREAT       = 73,  // can't create (user) output file
    IOERR           = 74,  // input/output error
    TEMPFAIL        = 75,  // temp failure; user is invited to retry
    PROTOCOL        = 76,  // remote error in protocol
    NOPERM          = 77,  // permission denied
    CONFIG          = 78,  // configuration error
    NOTEXECUTABLE   = 126, // command found but not executable
    NOTFOUND        = 127, // command not found
    INVALID         = 128, //  invalid exit code
    KILL            = 128, // + n - Fatal error signal n, i.e. kill -9 $PPID (128 + 9 = 137)
    SIGINTC         = 140, // command terminated by Ctrl-C
    SIGINTD         = 141, // command terminated by Ctrl-D
};

#endif

I think it is necessary to prefix these values with something like WREN_E
to avoid namespace pollution.
In addition I think you can remove most meta values, we only really need
MAX (and move it at the end), as it the only interesting value to specify
storage.
For KILL I like the idea, and if it goes in, maybe it should have
WREN_ESIG* values available.

#ifndef wren_sysexits_h
#define wren_sysexits_h

// Based on OpenBSD sysexits.h + Wren Specifics

typedef struct {

    // Standard Values
    int OK              ; // successful termination
    int UNKNOWN         ; // unspecified error

    // Meta Values
    int MIN             ; // min listed value
    int MAX             ; // max possible value

    // Wren Specifics
    int USAGE           ; // command line usage error
    int DATAERR         ; // data format error
    int NOINPUT         ; // cannot open input
    int NOUSER          ; // addressee unknown
    int NOHOST          ; // host name unknown
    int UNAVAILABLE     ; // service unavailable
    int SOFTWARE        ; // internal software error
    int OSERR           ; // system error (e.g., can't fork)
    int OSFILE          ; // critical OS file missing
    int CANTCREAT       ; // can't create (user) output file
    int IOERR           ; // input/output error
    int TEMPFAIL        ; // temp failure; user is invited to retry
    int PROTOCOL        ; // remote error in protocol
    int NOPERM          ; // permission denied
    int CONFIG          ; // configuration error
    int NOTEXECUTABLE   ; // command found but not executable
    int NOTFOUND        ; // command not found
    int INVALID         ; //  invalid exit code
    int KILL            ; // + n - Fatal error signal n, i.e. kill -9 $PPID (128 + 9 ;
    int SIGINTC         ; // command terminated by Ctrl-C
    int SIGINTD         ; // command terminated by Ctrl-D
} WREN_SYSEXISTS_STRUCT;

WREN_SYSEXISTS_STRUCT WrenSysExits;

// Standard Values
WrenSysExits.OK              = 0;
WrenSysExits.UNKNOWN         = 1;

// Meta Values
WrenSysExits.MIN             = 0;
WrenSysExits.MAX             = 255;

// Wren Specifics
WrenSysExits.USAGE           = 64;
WrenSysExits.DATAERR         = 65;
WrenSysExits.NOINPUT         = 66;
WrenSysExits.NOUSER          = 67;
WrenSysExits.NOHOST          = 68;
WrenSysExits.UNAVAILABLE     = 69;
WrenSysExits.SOFTWARE        = 70;
WrenSysExits.OSERR           = 71;
WrenSysExits.OSFILE          = 72;
WrenSysExits.CANTCREAT       = 73;
WrenSysExits.IOERR           = 74;
WrenSysExits.TEMPFAIL        = 75;
WrenSysExits.PROTOCOL        = 76;
WrenSysExits.NOPERM          = 77;
WrenSysExits.CONFIG          = 78;
WrenSysExits.NOTEXECUTABLE   = 126;
WrenSysExits.NOTFOUND        = 127;
WrenSysExits.INVALID         = 128;
WrenSysExits.KILL            = 128;
WrenSysExits.SIGINTC         = 140;
WrenSysExits.SIGINTD         = 141;

#endif

Interesting, but it remove const correctness and unified typing. While it
is easy to bring the first one, the second one seems really problematic,
unless a second name is introduced. (But it does not solve the high
probability of poor generated code, because compiler has to decide whether
or not to optimise the reading of a const struct of constant fields in best
case.)
Not sure it is worth the effort thought. Other languages have fancies ways
to deals with enums and name conflicts. But it is C/C++ code here, and
traditionally names conflicts are solved by prefixing names.
That said it might be nice to be able to maintain C and wren enum types in
sync somehow. So there is potential room for some trades off here,
depending on the tooling.

#ifndef wren_sysexits_h
#define wren_sysexits_h

// Based on OpenBSD sysexits.h + Wren Specifics

enum WrenSysExits {

    // Standard Values
    WREN_EXIT_OK              = 0,   // successful termination
    WREN_EXIT_UNKNOWN         = 1,   // unspecified error

    // Meta Values
    WREN_EXIT_MIN             = 0,   // min listed value
    WREN_EXIT_MAX             = 255, // max possible value
    WREN_EXIT_BASE            = 64,  // base value for error messages
    WREN_EXIT_TOP             = 141, // top listed value

    // Wren Specifics
    WREN_EXIT_USAGE           = 64,  // command line usage error
    WREN_EXIT_DATAERR         = 65,  // data format error
    WREN_EXIT_NOINPUT         = 66,  // cannot open input
    WREN_EXIT_NOUSER          = 67,  // addressee unknown
    WREN_EXIT_NOHOST          = 68,  // host name unknown
    WREN_EXIT_UNAVAILABLE     = 69,  // service unavailable
    WREN_EXIT_SOFTWARE        = 70,  // internal software error
    WREN_EXIT_OSERR           = 71,  // system error (e.g., can't fork)
    WREN_EXIT_OSFILE          = 72,  // critical OS file missing
    WREN_EXIT_CANTCREAT       = 73,  // can't create (user) output file
    WREN_EXIT_IOERR           = 74,  // input/output error
    WREN_EXIT_TEMPFAIL        = 75,  // temp failure; user is invited to retry
    WREN_EXIT_PROTOCOL        = 76,  // remote error in protocol
    WREN_EXIT_NOPERM          = 77,  // permission denied
    WREN_EXIT_CONFIG          = 78,  // configuration error
    WREN_EXIT_NOTEXECUTABLE   = 126, // command found but not executable
    WREN_EXIT_NOTFOUND        = 127, // command not found
    WREN_EXIT_INVALID         = 128, //  invalid exit code
    WREN_EXIT_KILL            = 128, // + n - Fatal error signal n, i.e. kill -9 $PPID (128 + 9 = 137)
    WREN_EXIT_SIGINTC         = 140, // command terminated by Ctrl-C
    WREN_EXIT_SIGINTD         = 141, // command terminated by Ctrl-D
};

#endif


Correction of the link of unitree_legged_msgs

The link for unitree_legged_msgs is incorrect

Thank you, I merged your commit.


Linux support

sys.platform
'linux'
/usr/local/lib/python3.5/dist-packages/turicreate/data_structures/sframe.py in explore(self, title)
if sys.platform != 'darwin' and sys.platform != 'linux2':
raise NotImplementedError('Visualization is currently supported only on macOS and Linux.')
why linux2?

@veonua - Sorry you are having this issue. What type of Linux and which version are you using? Can you try locally changing that line to if sys.platform != 'darwin' and sys.platform != 'linux': and let us know ifexplore works?

Are you using python3?

yes it's python3
https://docs.python.org/3/library/sys.html

Fixed with #404.


Deprecate then remove ShapeIndex

ShapeIndex is an abstraction that basically is a map of ShapeId to Shape. A Model contains a ShapeIndex, metadata, and a version. A ShapeIndex as a separate abstraction from Model makes code harder to write and adds no value in its separation. I propose we release a backward compatible change that first adds the ShapeIndex API into Model and deprecates any ShapeIndex based API. Then, in the next major version (i.e., 0.10.0), we will remove ShapeIndex and the deprecated APIs. This will take probably several days of super lame find, replace, and edit changes, but I think it's a win for API clarity.

[x] Deprecate ShapeIndex in 0.9.x
[ ] Remove ShapeIndex in 0.10.x

Can this be resolved?
Refs: #209

No, it also tracks the removal in a future version.


Immutable DB: Support EBBs?

In the previous API based on RelativeSlot EBBs could be stored at the end of an epoch. This is not possible anymore now that the immutable DB uses Slot, as an EBB will actually share a Slot with an ordinary block.
For now we decided to work around this by having client code store a pair of a regular block and an EBB at the final slot of an epoch. This keeps the design of the immutable DB simple and regular. It is not yet entirely clear though if this will add too much complexity to clients. If it turns out that it does, we should probably add explicit support for EBBs to the immutable DB.

/cc @mrBliss @avieth @dcoutts

Duplicate of #349.


discord: add libuuid to nativeBuildInputs

The libuuid.so.1 file can't be found and this allows the package builder to find it.
Should fix #90265

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Thank you for the fix!


Show docstrings in rendered tables

Sometimes data classes have docstrings, for the overall class or for individual attributes. It may be useful to be able to show those docstrings.
How the visual design will work is an open question. The tables are currently compact and easy to read—it may require some creativity to add docstrings in a way that don't detract too much from that.

Some new functionality that partially addresses this feature: erdantic now includes the class docstring as a tooltip on the Graphviz graph. This will work for rendered SVG outputs, which you can test out here: https://raw.githubusercontent.com/drivendataorg/erdantic/main/docs/docs/examples/pydantic.svg
Note that raw SVG embeddings can sometimes be used for XSS attacks, so GitHub considers it unsafe and will only render rich SVG displays as an image. This means, for example, the SVG rendered on the README will not be interactive and won't have the tooltips.
Commit that has this all working: https://github.com/drivendataorg/erdantic/commit/d4d735f0be950276185e700ef2baec1577ad1771

I am not sure it should be in this issue or if I should create a new one, but it would be interesting for pydantic users to use the Field types and display it in the SVG too. It holds a description that could be fetched instead of the docstrings along with some information, e.g default value.
e.g:
class MyModel(BaseModel):
    my_field: Optional[int] = Field(default=1234, description="Long description of the field")

PS: thanks for working on erdantic, it really helps to have such a tool

I'm going to close this issue for now since I don't think there will be any more active work on this. I think the SVG tooltips work okay. Unfortunately, I think rendering docstrings directly in the image is too difficult for these kinds of diagrams. If folks have specific proposals/mockups, post here, we can potentially revisit the topic.
With regards to the pydantic.Field descriptions, that is addressed in #42 and released in v0.4.0.


Config should merge everything

Instead of forcing users to either config via the files or with the passed in options, we should probably allow overrides at every level. I think it makes sense that config files are lower specificity than code, so I think the order of loading configuration could be as follows:

Load the eureka-client.yml config. (this is the base config)
Merge the eureka-client-${env}.yml config into the base config.
Merge the config object passed to the client constructor into the base config.

Unless anyone has an issue with this I'll probably implement it as described.

Object.assign is a great way to merge the configurations together, using a priority of base -> env -> passed in config.

Object.assign doesn't do deep merging though, which I thought was kind of essential in this case?

Yeah, in most cases all the settings will be the same for different environments and you really just need to change 1 value (like the eureka host in your -test.yml config, for example). The other values should inherit from your base configuration.


[port] ventcawling from starligth

port from Starligth https://github.com/ss14Starlight/space-station-14
under Starligth License
About the PR

adds ventrawling
makes some mobs abel to crawl in vents
adds a contotionis unifrom to atmos job for 30tc
under starligth licence. Durk you can controll if any license file is missing.
Why / Balance

Technical details

Media

Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

:cl: VigersRay, Rinary

add: Added Ventcrawling

durk and piras make sure the correct names are in the changelog

We do not accept any code under the Starlight license

someone paste the copypasta

Sorry, we do not accept any code under the Starlight license
—————————————————
This text blob is in accordance withProject Starlight's license
In order to do so, when referencing Project Starlight, in every single message or post referencing Project Starlight, you must:

Refer to it as Project Starlight
Link Project Starlight's their Discord
Link Project Starlight's Social media platforms (e.g., Facebook groups)
Link Project Starlight's Documentation and other official materials
Link Project Starlight's Repository

Here are the following relevant links:
Repository Discord Documentation Website
Email<EMAIL_ADDRESS>

FUCKIN LICENSE HNNNNNNNNNNGHHHH :goberserk:


[DOCFIX]Add java doc for docs/_data/table/en/master-configuration.yml

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/15789/
Test PASSed.


[eslint-config] Support optional chaining

As of right now, eslint erroneously shows a no-unused-expression error on optional chaining function calls / field access.
In eslint-config/index.js there's this rule:
  overrides: [
    {
      files: ['**/test/**/*.js', '**/demo/**/*.js', '**/stories/**/*.js'],
      rules: {
        'no-console': 'off',
        'no-unused-expressions': 'off',
        'class-methods-use-this': 'off',
      },
    },
  ],

Why was no-unused-expressions disabled for those cases? I'm trying to evaluate the best workaround to support optional chaining. Right now the best option seems to be https://github.com/eslint/eslint/issues/11045#issuecomment-436685184 but it would add a dependency on eslint-plugin-babel

Just realized babel-parser already depends on eslint-babel-plugin, so that particular fix would be a 2 line change. Shall we go with it?

Babel is about to release optional chaining support by default, I wonder if we get this out of the box then?

Unfortunately, we will not get this out of the box, until eslint supports this by default. As mentioned by @doplumi, we can use/add babel's eslint plugin (eslint-plugin-babel). The idea would be to use their specific rule (babel/no-unused-expressions) instead of the regular one (no-unused-expression).
I just tested this today in my project and it works great (only 3 extra deps) It would be even better though our eslint-config supported this out of the box. Care for a PR, @LarsDenBakker ? 😃

Doesnt eslint do stage 4 by default? But lets use babel eslint then.

Yes, they are working on it: https://github.com/eslint/eslint/issues/12642, but they are blocked for now.
Also, some teams might not be able to upgrade to the latest eslint yet. The bug will probably only be fixed in one of the upcoming 7.x releases.


[BUG]: ERROR:torch.distributed.elastic.multiprocessing.api:failed (exitcode: -9) local_rank: 7 (pid: 2860777) of binary:

🐛 Describe the bug
use： gpt2_configs/gpt2_zero3.py
run：Error: failed to run torchrun --nproc_per_node=8 --nnodes=1 --node_rank=0 --rdzv_backend=c10d --rdzv_endpoint=<IP_ADDRESS>:29500 --rdzv_id=colossalai-default-job train_gpt.py --config=gpt2_configs/gpt2_zero3.py --from_torch on <IP_ADDRESS>
bug log:
WARNING  colossalai - ShardedOptimizerV2 - WARNING: found inf during ShardedOptimV2 step
WARNING  colossalai - ShardedOptimizerV2 - WARNING: found inf during ShardedOptimV2 step
[Epoch 0 / Train]:   1%|▌                                                                                | 19/2839 [15:02<33:39:30, 42.97s/it, loss=2580.0, lr=0.0167, throughput=0.38035 sample_per_sec, 12.996 Tflops[Epoch 0 / Train]:   1%|▌                                                                                | 20/2839 [15:02<33:31:36, 42.82s/it, loss=2580.0, lr=0.0167, throughput=0.38035 sample_per_sec, 12.996 Tflops]WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 2860767 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 2860768 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 2860769 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 2860770 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 2860771 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 2860772 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 2860776 closing signal SIGTERM
ERROR:torch.distributed.elastic.multiprocessing.api:failed (exitcode: -9) local_rank: 7 (pid: 2860777) of binary: /home/jovyan/miniconda3/envs/colossalai-test/bin/python
Traceback (most recent call last):
File "/home/jovyan/miniconda3/envs/colossalai-test/bin/torchrun", line 8, in
sys.exit(main())
File "/home/jovyan/miniconda3/envs/colossalai-test/lib/python3.8/site-packages/torch/distributed/elastic/multiprocessing/errors/init.py", line 345, in wrapper
return f(*args, **kwargs)
File "/home/jovyan/miniconda3/envs/colossalai-test/lib/python3.8/site-packages/torch/distributed/run.py", line 719, in main
run(args)
File "/home/jovyan/miniconda3/envs/colossalai-test/lib/python3.8/site-packages/torch/distributed/run.py", line 710, in run
elastic_launch(
File "/home/jovyan/miniconda3/envs/colossalai-test/lib/python3.8/site-packages/torch/distributed/launcher/api.py", line 131, in call
return launch_agent(self._config, self._entrypoint, list(args))
File "/home/jovyan/miniconda3/envs/colossalai-test/lib/python3.8/site-packages/torch/distributed/launcher/api.py", line 259, in launch_agent
raise ChildFailedError(
torch.distributed.elastic.multiprocessing.errors.ChildFailedError:

Environment
lastest
No response

This is expected because torchrun cannot do graceful shutdown for now. It is not a bug.

This code only runs 20 steps on purpose since it is only a demo. You should be able to find in code that the the program will be stopped after 20 steps.

I used the code in https://github.com/hpcaitech/ColossalAI-Examples/blob/main/language/gpt/train_gpt.py。
config.py :
from colossalai.nn.optimizer import HybridAdam
from colossalai.zero.shard_utils import TensorShardStrategy
from titans.model.gpt import gpt2_small, gpt2_36B
BATCH_SIZE = 2
NUM_EPOCHS = 60
SEQ_LEN = 1024
zero = dict(
model_config=dict(
tensor_placement_policy='cpu',
shard_strategy=TensorShardStrategy(),
reuse_fp16_shard=True
),
optimizer_config=dict()
)
optimizer = dict(
type=HybridAdam,
lr=0.001,
weight_decay=1e-2,
)
model = dict(
type=gpt2_small,
checkpoint=True,
)
model = dict(
type=gpt2_36B,
vocab_size=53227,
checkpoint=True,
)
Where can I look for the code stopped after 20 steps?

Hi @Tron1994 We have updated a lot. You can check our new example.
https://github.com/hpcaitech/ColossalAI/tree/main/examples/language/gpt
This issue was closed due to inactivity. Thanks.


console.font is correctly set, but then unset

Describe the bug
A clear and concise description of what the bug is.
I've just set up a new machine with nixos-23.11. I have the following lines in my configuration.nix:
console = {
    earlySetup = true;
    packages = [ pkgs.terminus_font ];
    font = "ter-122n";
};

When I boot up, I see the font get correctly set, but then for some reason the screen goes blank and reloads with the font reverted. See the gif below:

A couple of additional points:

Removing earlySetup doesn't help.
The workaround described here doesn't work, so I think this is a separate issue.

Steps To Reproduce

Build device with nixos-23.11
Set console.font
Reboot

Expected behavior
The font ter-122n is correctly set and remains set.
Notify maintainers
@Artturin
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.67, NixOS, 23.11 (Tapir), 23.11.1779.cf28ee258fd5`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"nixos-23.11, nixos-unstable"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

I solved this by adding the config for my device from https://github.com/NixOS/nixos-hardware (this one).
My guess is it's one of these settings:
https://github.com/NixOS/nixos-hardware/blob/7763c6fd1f299cb9361ff2abf755ed9619ef01d6/common/gpu/intel/default.nix#L3-L15
https://github.com/NixOS/nixos-hardware/blob/7763c6fd1f299cb9361ff2abf755ed9619ef01d6/common/cpu/intel/cpu-only.nix#L4-L5


Add plugin to compute time offsets per chunk

What does the code in this PR do / what does it improve?
Plugin which computes time offsets between detectors.

I opened the draft as a reference. I think this plugin should cover all current and future edge-cases for our offsets. It is not nice but should work.

Okay I checked it with different runs and things seem to work properly. I only had to exclude the VetoSync plugins from testing since it requires synced test data.


dir support

Here is an attempt at implementing direct encryption by eliding the CEK generation process and using a provided symmetric key directly. I found this useful for password-protecting private keys in storage using scrypt as a KDF; if there is sufficient interest in pushing that functionality into js-jose itself, that might be possible.
I believe you already have a contributor agreement on record for me when I added some minor stuff to  your go-jose project. Thanks again for providing these projects!

This looks good to me. Could you please add a test (see https://github.com/square/js-jose/blob/master/test/)?

Test added.

:+1:


cri-o randomly fails by getting unexpected stdin

Description of problem
Recently on azure CI some cri-o test started to fail randomly all fails trying check an exacted output but ti does not exist.
Example:
17:21:43 not ok 13 ctr device add
17:21:43 # (in test file crio.bats, line 530)
17:21:43 #   `[[ "$output" =~ "/dev/mynull" ]]' failed
17:21:43 # 0
17:21:43 # time="2018-02-08 17:21:38.832696169Z" level=debug msg="[graphdriver] trying provided driver "devicemapper""
17:21:43 # time="2018-02-08 17:21:38.833122083Z" level=debug msg="devicemapper: kernel dm driver version is 4.37.0"
17:21:43 # time="2018-02-08 17:21:38.833233487Z" level=debug msg="devmapper: Generated prefix: container-8:1-784941"
17:21:43 # time="2018-02-08 17:21:38.833248687Z" level=debug msg="devmapper: Checking for existence of the pool container-8:1-784941-pool"
17:21:43 # time="2018-02-08 17:21:38.833501096Z" level=debug msg="devmapper: Pool doesn't exist. Creating it."
17:21:43 # time="2018-02-08 17:21:38.926425572Z" level=debug msg="devmapper: loadDeviceFilesOnStart()"

Expected result
All cri-o test passing all the time and not fail randomly.
Actual result
(replace this text with details of what actually happened)

(replace this text with the output of the cc-collect-data.sh script, after you have
reviewed its content to ensure it does not contain any private information).

cc @sboeuf @chavafg

Thanks @jcvenegas !

First investigation make me think we have something wrong with the output of exec'ed  processes.

@jcvenegas docker exec and cc-runtime exec does not print anything to stdout. I'm seeing the following error in the proxy logs:
time="2018-02-08T22:58:55.358961143Z" level=debug msg="{\\\"error\\\":\\\"read /dev/ptmx: file already closed\\\",\\\"level\\\":\\\"info\\\",\\\"msg\\\":\\\"Sequence has been closed\\\",\\\"name\\\":\\\"cc-agent\\\",\\\"pid\\\":133,\\\"sequence\\\":5,\\\"time\\\":\\\"2018-02-08T22:58:55.34883174Z\\\"}" name=cc-proxy pid=1688 source=qemu vm=28cb50ca4b82ffd917a2f026ea8981ad2183dab1538f465e2eaaa3bfa37eb5f5

@erick0z yeah I am working on a fix right now. I'll keep you posted about this issue.

Issue fixed here: https://github.com/clearcontainers/agent/pull/208


Prevent CMAKE_Fortran_COMPILER_VERSION from becoming undefined

[x] CMAKE_Fortran_COMPILER_VERSION was added to CACHE to prevent it from becoming unset after the second configuring. Previously, this variable was sometimes automatically unset which in turn affected variables such as opencoarrays_aware_compiler. I reported a bug about this so let's wait for a little while for the response.
[ ] The variable CMAKE_Fortran_COMPILER_VERSION is present starting with CMake 3.3 and therefore I think it's better to write the conditional not as (CMAKE_VERSION VERSION_GREATER 3.2.3) but (NOT CMAKE_VERSION VERSION_LESS 3.3). Similarly, at line 45, if the intention is to test whether GCC is at least version 5, it would be better to have (NOT CMAKE_Fortran_COMPILER_VERSION VERSION_LESS 5). In other places, I can see conditionals such as (CMAKE_Fortran_COMPILER_VERSION VERSION_GREATER 4.9.2) (note that 4.9.3 has been released). If you agree with me, then I'd like to replace VERSION_GREATER with NOT ... VERSION_LESS and make the necessary changes everywhere.

Regarding the first issue - the bug has been confirmed and will be fixed starting with CMake 3.3.1. A temporary fix is required only until then.

Thanks for the pull request.  I just merged it into the master branch.  My apologies for the delayed review.  I returned to work on Wednesday after a 10 days of business travel and vacation travel.


ARROW-18420: [C++][Parquet] Introduce ColumnIndex & OffsetIndex

Basically this patch has defined the interface of ColumnIndex and OffsetIndex. Implementation classes are also provided to deserialize byte stream, wrap thrift message and provide access to their attributes.
BTW, the naming style throughout the code base looks confusing to me. I have tried to follow what I have understood from the parquet sub-directory. Please correct me if anything is incorrect.

@pitrou @emkornfield Can you please take a look at the proposed interface and implementation? Once they are finalized, I will add unit tests. Thank you very much!

In the last commit, I have removed all the per-page accessors. They are now actually thin wrappers to the corresponding thrift class. How about this? @emkornfield @pitrou

I just realized: in this API, encoded_min_values and min_values use different conventions? (one is dense, the other is sparse).

I just realized: in this API, encoded_min_values and min_values use different conventions? (one is dense, the other is sparse).

After checking the potential use cases of ColumnIndex, I think it makes sense to follow same convention for encoded_min_values() and min_values() to have same number of pages. For predicate push down, the binary search for sorted column index can be simply done by iterating page_ids returned from non_null_page_indices(). The latest commit reflects this change. Please take a look, thanks! @pitrou

Thanks @wgtmac . Is it possible to add some tests for this? One option is to rely on data files from https://github.com/apache/parquet-testing/tree/master/data (you might also upload your own there if desired)

I have added page_index_test.cc to test deserialization of page index objects. Please take a look, thanks!

@wgtmac Feel free to ping when this is ready for review again.

Thanks a lot! I think this is good to go now, will just wait for CI.


with error "ExtendedTextSelectionState" is missing implementations for <TextInputClient.didChangeInputControl>&&<TextInputClient.performSelector>

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
when i run command  ->    flutter build apk
it takes error!
my flutter version information is below:
C:\Users\nocoah>flutter --version
Flutter 3.7.1 • channel master • https://github.com/flutter/flutter.git
Framework • revision 7048ed95a5 (4 months ago) • 2023-02-01 09:07:31 -0800
Engine • revision 800594f1f4
Tools • Dart 2.19.1 • DevTools 2.20.1
i had tried like these:
delete folder build
delete pubspec.lock
flutter clean
flutter pub get
Actual results
Flutter assets will be downloaded from https://mirrors.tuna.tsinghua.edu.cn/flutter. Make sure you trust this source!
Building with sound null safety
Flutter assets will be downloaded from https://mirrors.tuna.tsinghua.edu.cn/flutter. Make sure you trust this source!
/C:/Users/nocoah/AppData/Local/Pub/Cache/hosted/mirrors.tuna.tsinghua.edu.cn%2547dart-pub%2547/extended_text-9.1.2/lib/src/selection/extended_text_selection.dart:151:7: Error: The non-abstract class 'ExtendedTextSelectionState' is missing implementations for these members:

TextInputClient.didChangeInputControl
TextInputClient.performSelector
Try to either
provide an implementation,
inherit an implementation from a superclass or mixin,
mark the class as abstract, or
provide a 'noSuchMethod' implementation.

class ExtendedTextSelectionState extends State
^^^^^^^^^^^^^^^^^^^^^^^^^^
/E:/flutter/packages/flutter/lib/src/services/text_input.dart:1163:8: Context: 'TextInputClient.didChangeInputControl' is defined here.
void didChangeInputControl(TextInputControl? oldControl, TextInputControl? newControl) {}
^^^^^^^^^^^^^^^^^^^^^
/E:/flutter/packages/flutter/lib/src/services/text_input.dart:1184:8: Context: 'TextInputClient.performSelector' is defined here.
void performSelector(String selectorName) {}
^^^^^^^^^^^^^^^
Target kernel_snapshot failed: Exception
FAILURE: Build failed with an exception.

Where:
Script 'E:\flutter\packages\flutter_tools\gradle\flutter.gradle' line: 1155

What went wrong:
Execution failed for task ':app:compileFlutterBuildRelease'.

Process 'command 'E:\flutter\bin\flutter.bat'' finished with non-zero exit value 1

Try:

Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 32s
Running Gradle task 'assembleRelease'...                           33.7s
Gradle task assembleRelease failed with exit code 1
Logs
No response
Flutter Doctor output
C:\Users\nocoah>flutter doctor -v
Flutter assets will be downloaded from https://mirrors.tuna.tsinghua.edu.cn/flutter. Make sure you trust this source!
[√] Flutter (Channel master, 3.7.1, on Microsoft Windows [版本 10.0.19044.2965], locale zh-CN)
• Flutter version 3.7.1 on channel master at E:\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 7048ed95a5 (4 months ago), 2023-02-01 09:07:31 -0800
• Engine revision 800594f1f4
• Dart version 2.19.1
• DevTools version 2.20.1
• Pub download mirror https://mirrors.tuna.tsinghua.edu.cn/dart-pub
• Flutter download mirror https://mirrors.tuna.tsinghua.edu.cn/flutter
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
• Android SDK at C:\Users\nocoah\AppData\Local\Android\sdk
• Platform android-34, build-tools 34.0.0
• Java binary at: E:\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 17+35-2724)
• All Android licenses accepted.
[√] Chrome - develop for the web
• Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.0.5)
• Visual Studio at E:\vs2022
• Visual Studio Community 2022 version 17.0.32112.339
• Windows 10 SDK version 10.0.19041.0
[√] Android Studio (version 2022.2)
• Android Studio at E:\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 17+35-2724)
[√] IntelliJ IDEA Ultimate Edition (version 2021.1)
• IntelliJ at E:\IntelliJ IDEA 2021.1.3
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
[√] Connected device (3 available)
• Windows (desktop) • windows • windows-x64    • Microsoft Windows [版本 10.0.19044.2965]
• Chrome (web)      • chrome  • web-javascript • Google Chrome 113.0.5672.64
• Edge (web)        • edge    • web-javascript • Microsoft Edge 110.0.1587.63
[√] HTTP Host Availability
• All required HTTP hosts are available
• No issues found!

Hi @nocoah
This is an issue with extended_text which is a 3rd party package so you should report there for better support.
Regarding your issue, I see there was a known issue (https://github.com/fluttercandies/extended_text/issues/137). It might be fixed on newer package version.
Closing the issue as it's not Flutter framework or 1st party plugin issue.


Added ValueFilloutTask

Codecov Report

Merging #114 into develop will increase coverage by 0.24%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop     #114      +/-   ##
===========================================
+ Coverage    74.94%   75.19%   +0.24%
===========================================
  Files           37       37
  Lines         3892     3930      +38
===========================================
+ Hits          2917     2955      +38
  Misses         975      975

Impacted Files
Coverage Δ

features/eolearn/features/feature_manipulation.py
95% <100%> (+4.52%)
:arrow_up:

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 00a8161...4ad7bba. Read the comment docs.

Tests are now updated.


Add Van-Component

Simple function to create a standard Web Component from a VanJS component.
Example
import van from "vanjs-core";
import { createComponent } from "vanjs-component";
const { button, div, slot } = van.tags;

createComponent("custom-counter", () => {
  const counter = van.state(0);
  return div(
    slot(),
    " ",
    counter,
    " ",
    button({ onclick: () => ++counter.val }, "+"),
    button({ onclick: () => --counter.val }, "-")
  );
});

and usage in HTML
<custom-counter>❤</custom-counter>

<custom-counter>👌</custom-counter>

If that can help, I can work on an example page in the spirit of Van Component by example. Web components can be confusing so it might help others get a better understanding of what is possible!

If that can help, I can work on an example page in the spirit of Van Component by example. Web components can be confusing so it might help others get a better understanding of what is possible!

Yes, that would be great!

@Atmos4,
I'm going to merging this PR first. If you want to add an example page in the future, you can send out a separate PR.

@Tao-VanJS I wanted to move at my own pace with this, so I took the liberty to create my own Git repo: https://github.com/Atmos4/van-element
Here are the changes I made since this PR:

rename to van-element. The npm package is now vanjs-element.
rename createComponent to define
define type definition is now:

import { State, ChildDom } from "vanjs-core";

export declare const define: (
  name: string,
  element: (
    props: Record<string, State<string>> & {
      onMount: (mountFunction: (element: HTMLElement) => void) => void;
      element: HTMLElement;
    }
  ) => ChildDom,
  options?: { observed?: string[]; disableShadow?: boolean }
) => void;

element method parameters:

a Record of attributes
onMount function (I plan to add onDismount or accept a return dismount function in future versions)
element which is the element itself

options:

observed will make the component reactive to attribute changes.
disableShadow will disable Shadow DOM. This will turn the component into a normal custom element.

I will create a new PR to update this repo with the up-to-date code.
Do you think it makes sense that I keep development on a separate repo, and merge code with this monorepo when I release a new version?

Do you think it makes sense that I keep development on a separate repo, and merge code with this monorepo when I release a new version?

Yeah, that looks good to me.

@Tao-VanJS here is the demo page: https://codepen.io/atmos4/pen/ZEPEvvB
I updated the main repo. It is now in a state that I am happy about, so I will publish a PR soon! Don't hesitate to check it out and shout in issues if there are things you dislike

Cool! This is great! Looking forward to your new PR.


Fix docs rendering issue

Some whitespace in docs/index.md was causing the docs to render like so:

Coverage remained the same at 28.216% when pulling df946d3c57d2b7f16b60a2c6000c56547bb672af on ThinkChaos:docs-fix into 5d0963938013b42a0ce26d2a64917efebc9af4f9 on tomv564:master.


add withErrorReporting and withBusyState wrappers

Adds two 'higher order async functions' to factor out some common boilerplate. These functions effectively transform one async function to another, and so can be composed as needed.
withErrorReporting catches any exceptions and sends them to reportError along with the given title string. The returned wrapper function's promise will never reject. Note that this does not preclude handling specific kinds of errors inside the wrapped function.
withBusyState wraps the original function with a busy flag by calling the provided function with true on invocation, and false on exit.

What if these were built with _.curry, so they could be called ()() or (,)`?

Good call, done.

I changed the class methods to 'class fields' instead, which allows us to avoid the extra level of indirection.


Style properties don't get cleared when removing and re-adding nodes

Here is an example where I'm adding, then removing, then re-adding two nodes with DOMElements attached. Depending on the order that I add and remove them, I can end up in a state where the border-radius that is only supposed to be applied to the circle node gets applied to the square node. I think this is due to the way that Engine is recycling divs but I haven't gotten the change to dig into the code.
'use strict';

// Famous dependencies
var DOMElement = require('famous/dom-renderables/DOMElement');
var FamousEngine = require('famous/core/FamousEngine');

// Boilerplate code to make your life easier
FamousEngine.init();

// Initialize with a scene; then, add a 'node' to the scene root
var root = FamousEngine.createScene().addChild();
var circle;
var square;
var el;

function addCircle() {
    circle = root.addChild();
    circle.setSizeMode(1,1,1);
    circle.setAbsoluteSize(300, 300);
    el = new DOMElement(circle);
    el.setProperty('border', '5px solid red');
    el.setProperty('border-radius', '50%');
    el.setContent('circle');
}

function addSquare() {
    square = root.addChild();
    square.setSizeMode(1,1,1);
    square.setAbsoluteSize(300, 300);
    square.setPosition(400, 0);
    el = new DOMElement(square);
    el.setProperty('border', '5px solid green');
    el.setContent('square');
}

addCircle();
addSquare();

setTimeout(function (){
    root.removeChild(square);
    root.removeChild(circle)

    setTimeout(function() {

        // Seems like the node that was was allocated to circle
        // gets reallocated to square but the border-radius property
        // doesn't get properly wiped away.
        addSquare();

        setTimeout(function() {
            addCircle();
        }, 750)
    }, 750)
}, 750);

I experienced the same thing, we're tracking it in https://github.com/Famous/engine/issues/245.

Closing to keep the conversation in one thread


[SILGen] Emit default arg generator for stored property kind

In order to properly serialize stored property default arguments, we need to emit a default arg generator.
I chose to emit the parent initializer expression instead of the apply to the variable initializer because SIL would eventually just inline the function definition anyway (or at least in most cases from my findings) and this was a lot cleaner and cheaper implementation wise. I've updated the SILGen tests and added a serialization test.
cc: @slavapestov @jrose-apple

The approach looks good to me but I think Slava should check the details. Thank you, Alejandro!

I'm questioning whether whether we need a special default arg kind anymore with this implementation. Also, I feel like I explored this route in the initial patch, but just couldn't make it work then.

Oh I didn't know this was the case for expression. 👍

@slavapestov I believe I did this correctly, but would love feedback. I've added some more tests to exercise indirect results.

@swift-ci Please smoke test

@swift-ci Please test source compatibility

@slavapestov okay, I believe I have fixed the TBD test, as well as pull in your test changes as well.

@swift-ci Please smoke test

@swift-ci Please test source compatibility

PromiseKit failure looks real. :-( https://ci.swift.org/job/swift-PR-source-compat-suite-debug/976/artifact/swift-source-compat-suite/FAIL_PromiseKit-PromiseKit.xcodeproj_4.0.3_BuildXcodeProjectTarget_PromiseKit_generic-platform-macOS.log

I don’t believe the Linux failure is related, but I’m not sure why debug source compat failed, but release didn’t?

Release is usually a whole-module build; maybe you have a default arg generator being emitted from one file that references an initial value in another file, or something like that?

Thanks Jordan! I think I see the issue, will work on this when I get home.

@slavapestov I hate to ping you again, but I believe this is the one!

@swift-ci Please test source compatibility

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - ca1cb7112ceda88f3fdb8988a8b1687b6b85c958

@swift-ci Please test macOS

@swift-ci Please test source compatibility

Build failed
Swift Test OS X Platform
Git Sha - ca1cb7112ceda88f3fdb8988a8b1687b6b85c958

Thanks @Azoy!


AVG flags installer as EvoGen malware

I was surprised, but this apparently happens from time to time.
https://www.gsmarena.com/no_our_android_app_doesnt_contain_a_virus-news-52893.php
Honestly not sure what you could possibly do about it, but I thought I should let you know anyway.

Yes, it's come up before, I'm not quite sure what to do about it.  It's a false positive.
I think in some cases one can add a signed credential to bias the virus scanners, but I haven't looked into it.


Would a PR to switch to '#pragma once' be accepted?

Would switch the #ifdef, #define, #endif entries to a single #pragma once at the top of each header file. #pragma once is widely supported at this point.

I think it's hard to use this since:
1.NuttX need comatablie with C89 standard
2.#pragma once isn't defined in C standard
I also don't see the benefit to switch #ifndef/#define/#endif to #pragma once, do you have any particular reason?

@xiaoxiang781216 just seeing a lot of complex header protection defines that someone has to put together (or script) that would go away.
@patacongo I appreciate that, normally I wouldn't advocate for a pragma as they are compiler implementation specific. It's too bad that it hasn't made its way into the language standard proper yet. It's been supported by basically all compilers for a dozen years now.
If, at some point, an exception would be made for this particular pragma, let me know!

No worth it.  There is no real benefit and a very, very big downside.  We must not introduce ANY compiler dependencies in the source code.  We have followed that rule for a dozen years and it will not change now..  Let's not consider this.

Very bad idea.


Table created with nullable column

Is your feature request related to a problem? Please describe.
ClickHouse do support NULLABLE column (https://clickhouse.com/docs/en/sql-reference/data-types/nullable) (However, this is not recommended).
Although, sometimes there is a need to create a nullable column within dbt operation (creating tmp table,...)
For the output table of a dbt-model, I can use pre-hook to create table manually, but this appoarch would not work with auto generated tables of dbt (_tmp table, or _backup)
Describe the solution you'd like
There is a config that allows defining nullable columns.
Describe alternatives you've considered
Additional context

Column type in created table is detected by column type from SELECT. No need in any settings. Just make your column Nullable type in query, otherwise you will not be able to insert data if your select differs from table.
SELECT toNullable(1) AS col

This will create table with column type col Nullable(UInt8)

@simpl1g thanks for your suggestion.
I just find out that if columns are not in order, uniq,... they will be configured as Nullable as default.
My previous mistake is not casting type of clickhouse in correct way:

select created_at::date >> DB::Exception: Cannot convert NULL value to non-Nullable type: while executing.
select toDate(created_at) >> it works.


patch: export utilities

:tada: This PR is included in version 4.0.13 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


build: remove python fallback in overlay builds

Remove the Python 2 fallback from the standalone overlay build.  This
is part of the migration to Python 3.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please smoke test

Please hold off from merging this PR, I would like to run additional testing on this. Thanks!

This is associated with #32496 but both can be merged individually.

@swift-ci please smoke test


Feature Request: add global.ios = true

I would like to add some feature parity here.
I can currently easily do:  if (global.android) { /* Do some android code */ }
I would love to have a readonly global.ios set to a boolean true in the iOS runtime.
As I currently do:
if ( ! global.android) { /* iOS Code */ }
However, it will break if windows runtime is ever released...   I don't like code that can break easily even though I suspect windows is still a ways out...
I have had many people ask me why I do if (!global.android) to detect iOS and why I don't just use if (global.ios) and I have to tell them because the iOS runtime doesn't have that support.
Now, because I know how the runtimes work I am WELL aware the reason global.android works is because it is a side effect of the design of NativeScript.      But most people using the platform don't really understand the design and why 'global.android' works, so the iOS team looks, well....
I am willing to do a pull request for this if you are willing to accept it.   I personally think this would be a great simple new feature to add to the upcoming 3.0 release, and would make a lot of my plugins have  code that isn't as brittle.   :grinning:
Thoughts, discussion?

@NathanaelA
Does if (global.NSObject) check work for you?
If you find global.ios to be more convenient you can define a property:
Object.defineProperty(global, 'ios', {
    __proto__: null,
    value: (global.NSObject != undefined),
    configurable: false
});

If you find the check global.NSObject != undefined not being strong enough, you can combine it with more iOS specific APIs (e.g. global.NSObject && global.NSString && global.UIDevice). Alternatively, you can define the global variable in an module with *.ios.js extension and rely on the CLI to prepare it only on iOS. You can see a similar solution in tns-core-modules: iOS check, Android check.

import { isAndroid, isIOS } from "platform";
if (isIOS) {
} else if (isAndroid) {
}

@ivanbuhov -
if (global.NSObject && global.NSString && typeof global.ios === "undefined") {
	global.ios = true;
	Object.freeze(global.ios);
}

Was added to my NS-Master-technology plugin well over a year ago.  ;-)     I use it (ns-master-technology) in most my apps.   I'm not as worried about my apps; that code is trivial to add to the app.js file so it is set at the start of the app.
I was thinking in general this would be a good feature just so that it could be used in plugins in general.     I have developed over 30 plugins;  I find the missing (global.ios) an annoyance, it isn't a "major" issue; but it is just annoying.   I can work around it; but I don't see why I should always have to work around it, since it is such a trivial fix for the runtime engine and I can give you a pull request if you are willing to accept it...  ;-)
@PanayotCankov -
I'm well aware of platform  ;-)    -   However bringing in platform has caused crashes at app startup in past versions of NativeScript.   I haven't tested it recently (so it still might be the case), but once burned, you tend to eliminate any code you can't control..  ;-)
  In addition using "global.android" requires NO parsing of any additional JS code because it doesn't have to require anything, making the plugin less dependent on things especially with webpack blowing up things frequently.   This also eliminates ~1000 lines of code that has to be parsed and loaded in if you don't have to require `platform` (and what it brings in with it -- although I do realize this code (platform) is brought in at some point by application and other calls; it is safer if people when using my plugins before application if I don't bring in anything out of sequence....

If this is change is not willing to be accepted/changed;  I can make my plugin generator add that code to any of my new plugins, so that I can use "global.ios" throughout the rest of the plugin codebase, but it seems like this is something better left to the runtime engine, which is why I was suggesting it.   ;-)

@NathanaelA
Do you find if (global.NSObject) to be more annoying and less convenient than if (global.ios)?

@NathanaelA Ya ok, it is just that we suggested the runtimes to support some fields that can be used to check the runtime for ios vs android and debug vs release environments in the past but the result is what's now in "platforms". Obviously we have more arguments this time as well as support from the community so If it makes it to the runtimes this time, I'd be more than happy to deprecate the isAndroid/isIOS in the "platform".

@ivanbuhov - The reason I don't just use NSObject/NSString is I can see someone creating an emulation class in NativeScript for Android and calling it NSObject, NSString, etc...  So that the functionality actually is more cross platform and so they can call something like NSString.characterAtIndex(0,1) and it would work on both platforms.    You know someone will do it...  ;-)
I know this is a remote possibility; and so that is the reason I actually check TWO different objects; and more recently switched to checking NSString and UIDevice (so that way one of them is NOT prefixed with NS).         I believe this technique of checking at least two different unrelated objects is fairly safe; but it is  still not as safe as if the runtime had a built-in .ios property.  ;-)
Like I said before I can easily detect it; and I can start including the:
if (global.UIDevice && global.NSString && typeof global.ios === "undefined") {
	global.ios = true;
	Object.freeze(global.ios);
}

in all my own plugins; but I figured I would see if we could just get global.ios dropped into the runtimes, rather than me working around it in all my plugins.
Again this is more to eliminate an minor annoyance; not a major issue as I can easily work around it with the above code that I already use in a couple of my plugins.      I just would rather not have the annoyance.  And would be willing to submit a pull request if there is the possibility of it being accepted.  ;-)

@NathanaelA I agree that such checks for API availability (like if (global.NSObject)) are not 100% reliable because of the tiny possibility of someone mocking the API on the other platform. Keep in mind that this argument is valid if we introduce global.ios, too, because everyone can easily define global.ios on Android.
Currently, in case you don't want to consume the platform module from the cross-platform modules, the only 100% reliable method of checking the platform is having platform-specific files in your app/plugin:
// os.android.js
module.exports = { android: true };

// os.ios.js
module.exports = { ios: true };

// in a random module
var os = require('./os');
if (os.ios) {
}
else if (os.android) {
}

I agree that in some cases introducing two additional files to be able to check the platform may be too much work for a simple task.
A possible solution that has the strengths of both methods (the convenience of if (global.NSObject) and the reliability of using platform-specific modules) is to introduce read-only global.__platform property both in iOS and Android Runtimes (ping @Plamen5kov). The check will look like this:
if (global.__platform == "ios") { ... }
else if (global.__platform == "android") { ... }

or
if (global.__platform.ios) { ... }
else if (global.__platform.android) { ... }

The question here is whether the inconvenience of introducing two additional files (in the cases when you can't use the platform module) just to check the platform you are running on is a bigger issue than introducing yet another property on the global object. It's quite a subjective topic so I will appreciate more opinions here.

That is true someone could define a global.ios on android; unless we went one step farther and created them on both platforms as false and readonly.    ;-)     Then you would have it bulletproof.  If you wanted I am willing to do a pull for that also.
I actually have my own platform module (to work around a couple bugs in core modules, pulls already fix them but plugins need some backwards compatibility) myself as one of my plugins.
In that plugin I declare globally global.nsPlatform = {ios: x, android:x, windows:x, ...}  and then I freeze the nsPlatform object; but I am trying to eliminate dependencies on even my own plugins.     Simpler code to me is always better, less dependencies mean less things to go wrong.     I find it is way easier to write if (global.android) than require('nativescript-platform'); if (global.nsPlatform.android)  and so my platform module is only used in a couple of my plugins because it is way simpler to use the if (global.android) or if (!global.android)  vs making it a dependency and requiring it at the top of the app.
My pref is to add global.ios to the ios engine, if not; I already have plenty of ways to work around it and have used most the techniques somewhere.  ;-)

@NathanaelA The problem can be solved by having a plugin that has two separate files .android.js/.ios.js with content: export export const isIOS = true; for .ios.js and isAndroid for android.
Cli will take care of putting the files wherever necessary and you can require the plugin in your code similar to what @PanayotCankov suggested: import { isAndroid, isIOS } from "platform";, then check the platform.
I don't see a need to introduce special properties in the runtimes, for the soul purpose of checking the platform.

I'm well aware of platform ;-) - However bringing in platform has caused crashes at app startup in past versions of NativeScript. I haven't tested it recently (so it still might be the case), but once burned, you tend to eliminate any code you can't control.. ;-)

No need to depend on platform in this case. You can write your own plugin with 4 lines of code.

In addition using "global.android" requires NO parsing of any additional JS code because it doesn't have to require anything, making the plugin less dependent on things especially with webpack blowing up things frequently. This also eliminates ~1000 lines of code that has to be parsed and loaded in if you don't have to require platform (and what it brings in with it -- although I do realize this code (platform) is brought in at some point by application and other calls; it is safer if people when using my plugins before application if I don't bring in anything out of sequence....

No longer a problem because you wont be requiring platform, but your plugin.

@Plamen5kov - Might help if you read the ENTIRE thread before you respond, your message just re-iterates a solution I have ALREADY used in some of my plugins, and I even explained it in the message before your message.  ;-)
Let me put this in another fashion that might be easier to understand; How many plugins do you have Plamen?   I've written around 40 of them so far for NS.   I deal with this ISSUE almost every time I create and/or work on a plugin --- do I do:

Add a dependency to my ns-platforms plugin, and require it.
(Pro: Standard code, Con: extra dependency and potential issues with WebPack)
Cheat and do if (global.android) and if (!global.android) and figure the technical dept won't hit for a long time (if ever)
(Pro: Simple!   Con: Mythical Windows runtime  😀 ....).
Add: if (global.UIDevice && global.NSString && typeof global.ios === "undefined") {	global.ios = true; 	Object.freeze(global.ios); }
(Pro: Simple, Con: extra code which is assuming UIDevice and NSString will both never be defined on Android)

This is one of the few feature requests that I actually have multiple ways to solve the issue; I am NOT asking for how to solve the issue; I'm asking the team to simplify my task as a consumer of the engine and make global.ios a standard fixture in the ios runtime engine, so that it is a EASY way to detect which engine I'm on without having to jump through ANY extra hoops.    This is a real pain point for someone developing lots of plugins, not a MAJOR pain point; but a annoyance level pain point that I would love to get fixed so I no longer have to deal with it.
I have a plugin scaffolding generator that I wrote; it would be TRIVIAL for me to just add option 3 to it so that that is automatically added to all plugins that use a single JS/TS file.   But the best solution (imho) would be to add this to the engine.    Which is why I am making this request, my fallback plan is to just add option 3 to my generator and to all my existing plugins, as I think that is probably the best solution of the bunch outside of the engine change that we are discussing here.
I am willing to do a pull request for this; but the NS team is very opinionated and I've learned it is a lot safer to ask if a pull request will be accepted than to do all the work and then have it rejected...

Here is a prime example on how this ability on android solves my issue that just occurred two seconds ago.  (and it made me think of this issue right away) ---  I'm in the middle of tracing down a nasty bug in the Android runtimes with Pete so I have to  have global.__enableVerboseLogging(); enabled in the main app.js file.   I've passed the new test android version to my clients; so now I'm testing all the my new changes on iOS now...
Guess what happened when I started the app on iOS.   BOOOOOM, iOS obviously has no __enableVerboseLogging() command; so it fails out immediately.   Quick and SIMPLE solution:
if (global.android) {
  global.__enableVerboseLogging();
}

And I'm done!   No mucking about at all!   No need to worry about including platforms or ns-platforms, etc, just a simple if statement and I'm working again on BOTH platforms...     And I realize  that including platforms or ns-platforms is not that much more work (or annoyance); but then when you factor in when I go to delete this line of code I also have to go delete the import for platforms.   Why do I want any extra annoyance factor.   Keep it simple.  ;-)
And before we go off on a tangent -- yes I'm well aware their are other ways to skin this cat; if (global.android) is still way easier and faster to type than if (global.__enableVerboseLogging)...  ;-)

Summary:

We won't add global.ios because checking if (global.ios) is not any different than if (global.NSObject). It still has the same weaknesses.
Currently, if you want to have platform specific code you can use the platform cross-platform module - import { isAndroid, isIOS } from "platform";. If you are not using the cross-platform modules, you can still include the following logic in your app/plugin:

// platform.ios.js
exports.isIOS = true;

// platform.android.js
exports.isAndroid = true;

var platform = require('./platform');
if (platform.isIOS) {
    ...
}


Log Settings missing in VSQlik Settings

the loglevel should be editable via the settings in vscode for vsqlik

planned for settings change in #599 since i could only support the old format and not the new one, this is the reason it is not implemented currently.


Cant find dll (with out .h and .lib files). absolute path.

Node Version: 12.18.2
Platform: Windows10
Compiler: vs2019
Module: addons to import dll

Verbose output (from npm or node-gyp):
no error but dll is null
HMODULE hDLL = LoadLibrary("F:\\mydll.dll");

When i use nodejs addons to import dll. I found it cant find dll and i dont know why.

You are trying to use LoadLibrary from a node native module, right?
If the module is null, use GetLastError to get the error code.

I'll guess that whatever the issue was, it is gone now. Feel free to reopen if you provide more info.


credentials do not work

Hello,
I tried to take a look into the live demo but I couldn't login in and I get this error
QueryException in Connection.php line 666:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'demo_gymie_in.mst_users' doesn't exist (SQL: select * from `mst_users` where `email` =<EMAIL_ADDRESS>and `status` = 1 limit 1)

Thank you so much

The demo is fixed we had some issue with demo refresh cron job.


MEDIUM: Complete "push to parent"

@JmillsExpensify can you flesh out this issue with a P/S?

Sure will do. Aiming to get a discussion going this week.

Continuing the discussion here: https://expensify.slack.com/archives/C0671JDRKQW/p1703747091970109?thread_ts=1703746238.011989&cid=C0671JDRKQW

I'm going to move this one to weekly as I'm now prioritizing it on that timeframe.

I have had trouble prioritizing this one so far this week. Still keeping the weekly label in place, though I don't expect to ship the design doc this week.

I've got a couple of wave-related projects in front of this one, which are:

Details / three dot overflow simplification
7-day hold
Simplified Collect implementation
Money pre-designs

My plan is to post discussions on the first two today, which leaves the Money pre-design in front of this one. I'd like to get the first Money discussion posted by Friday. As soon as Money gets kicked off, I can post a better ETA of when I think I'll be able to prioritize this.
Additionally, I will start to look for someone that can help push this forward. I won't be able to lead this for a couple of weeks, though I can help out with it now.

Alright, the main and last thing standing in the way of this initiative is now Money / Search. As soon as that HL doc goes out, I will circle back on this initiative and put it to paper.

Still below Money / Search. That design doc started this week.

Same as above. Still below search.

Pretty far down in the priority queue at the moment.

This is super far down in my queue at the moment. Currently above it:

Search v2
Search v3
Workspace rules

I'll prioritize it as it becomes more of a priority in vip-vsb.

Not going to be a priority anytime soon, so making this a monthly

vip-vsb is on pause.

Not a priority so I'm going to close this issue.


Document how to upgrade OSM when minKubeVersion is bumped.

Please describe what should be documented
OSM v0.9 supports k8s v1.18.0+, while OSM v0.10 supports v1.19.0+, so upgrading from v0.9 -> v0.10 requires the underlying k8s cluster to be upgraded.
This needs to be documented and the e2 test needs to be updated to work around this if necessary.
Please suggest where in the repo the document should be located
osm-docs upgrade docs

https://github.com/openservicemesh/osm-docs/pull/178