[WIP] Login and roles/permissions

Hi,
I asked on gitter about a way for more fine-grained/abstract way to to check and grant permissions.
What I have in mind are cases like this which are hard to manage with the current role concept.

A user owns (meaning created) a row/object and is the only one allowed to view and alter it.
Think password changes, items in a shopping cart or shipping addresses.

A user belongs to to a certain group
Think something like only employees of company X are allowed to alter products produced by company X. Where employees of company X could be checked by a database relation lookup and adding roles for each company isn't feasible.

A user needs to full-fill some kind of rule
Like a certain amount of internal credit balance or time of day for instance.

I started this branch in pursuit of the first idea, allowing users into /admin to manage their user data. For this I added a authentication library based on gorilla/session to differentiate users based on cookies (could be any, just picked it because I wrote it myself).
The next step was converting roles.Permission and roles.Role into interfaces to see if this is enough to plug in permissions that grant/deny based on other criteria. (I created a fork of qor/roles to share this conversion and posted the patches against the other repos as a gist to reduce forks for now.)
What I found is that the concept of string based roles is tied in to deeply in the current interface to be more widely usable.
The HTTP request is only available to the role system to decide whether a user belongs to a certain role but the permission checks happen later and are only checking if a role should be allowed to execute a certain action.
I have no solution proposal at this time and would like to discuss approaches that help the qor Community at large before digging deeper into this. I currently wonder if we could synthesize the Role and Permission interface into a single one  that is dynamic enough to establish other concepts, like the ones I outlined above. They already share 2 methods (Allow and Deny) and the other ones are just there to work with the parts of the qor code base that use the roles package.
Thanks,
Henry

We has implemented a login system for qor demo, thank you for your PR anyway.


Space: Create foundation

Create a foundation component called "Space" which can be used for adding space around children elements as margins. The values of space that can be passed in should be well defined.

Use Tailwind padding:
https://tailwindcss.com/docs/padding


feat: add onlyHash option to files.add

@hacdias is there a test + has this been tested against js-ipfs and js-ipfs-api?

@diasdavid both have their implementations and their tests (js-ipfs-api, js-ipfs), but I can add one here.

Working @diasdavid. Basically I just copied the test from js-ipfs-api.


Online documentation cleanup

relates to #137 #135
reviewer comment
There are many websites documenting some versions of the BioJS MSAViewer, and it is unclear to a (perspective) user where to look for what kind of information, what is valid, and what is valid for which versions.

[ ] Information throughout the websites should be consolidated

[ ]  all valid sites should be linked from the article and from each other, explaining the differences between them.

[ ]  In particular, a link to the canonical public source code repository should be stated.

Seb and I decided to include the "User manual" page with instructions for users (the page is linked from the help button at http://msa.biojs.net/app/) and the "readme file" with instructions for developers. No other web pages should be there describing the app.


Adds support for gogs-client to retrieve repos by username and org

This is related to gogs/gogs-client issue 37
Requires gogs/gogs-client PR 42
Provides the ability to retrieve repos by username or by org via the REST API (gogs-client).

By the way, just wanted to include a link to the GitHub documentation:

https://developer.github.com/v3/repos/#list-user-repositories
https://developer.github.com/v3/repos/#list-organization-repositories

I believe all the line notes have been addressed - wasn't certain about "Why not put two other routes after this line (221)?" - but hopefully that is what you meant. Note the other top level repositories entries refer to user and org and the two new GETs refer to users and orgs - I'm happy to move where ever you believe it makes most sense.
Thanks for the feedback!


Window resize does not respect minWidth settings

I am unable to get the window resize to respect the Split.js minWidth settings. Instead, the panels resize proportionally past the minWidth until you drag the gutter, in which it pops back to the minWidth.

Split.js does not attach any window event listeners, but you could add your own, and call:
split.setSizes(split.getSizes())

which would update the sizes to respect any minSize.

Thanks for the help! I was able to force a minWidth for the left panel on window resize using the following code:
$(window).resize(function(){
    var panelSizes = split.getSizes();
    if (((panelSizes[0] * 0.01) * winWidth)  < 390) {
        var newLeft = ((390 / winWidth) * 100);
        split.setSizes([newLeft, (100 - newLeft)]);
    }
});

Hmm, setSizes/getSizes didn't work directly? That would be a bug. Because setSizes should respect the minSize, without having to do further calculation.

Unfortunately it didn't work directly on Safari and Chrome on Mac. It would maintain the panel ratio when the window resizes and would maintain that ratio past the minWidth. I'll see if I can help correct the issue later this week when I have more time. Other than that, the library works great! Nice and simple!

@nathancahill This issue also exists on Split Grid, is there

Split.js does not attach any window event listeners, but you could add your own, and call:
split.setSizes(split.getSizes())

which would update the sizes to respect any minSize.

@nathancahill This issue also exists on Split Grid, I can't seem to find a simple solution for Split Grid like the one above for Split.js.


adding azure openai compatibility.

I have been using this library to work with openai but need to transition to Azure openai instead.  The only real changes are the endpoints are formatted a little differently and auth is a little different as well.  everything here should be completely backwards compatible.  As far as I know once this is merged this will be the first C# library to support azure openai.

Thanks for the PR, I will have a look. I have been trying to get access to Azure OpenAI but I couldn't succeed yet. Did you find a chance to test your changes?

also, could you change your target branch to dev, please?

Thanks for the PR, I will have a look. I have been trying to get access to Azure OpenAI but I couldn't succeed yet. Did you find a chance to test your changes?

I did, it all works and I was impressed with the ease of making the changes.  If you'd like an in I can make an intro at microsoft to get you pushed up in the queue.

That would be great!

As I understand we need to change base domain too and PR doesn't include this change, right?
https://YOUR_RESOURCE_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT_NAME/embeddings?api-version=2022-12-01

As I understand we need to change base domain too and PR doesn't include this change, right?
https://YOUR_RESOURCE_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT_NAME/embeddings?api-version=2022-12-01

There was already a basedomain in the settings so no change needed.

I have just pushed some changes, and I would appreciate it if you could review it and let me know your thoughts on the changes. Please note that my Resharper reverted some of your Code Style changes. Most of the changes involve naming and code style adjustments. Additionally, I made an update to OpenAI.SDK/OpenAiOptions.cs to automatically recognize which provider the developer intends to use.
I expect the ResourceName to be provided as an argument rather than asking for the base URL. This change should make it easier to use.

I just updated the codes.
I have tried to reduce the number of logics in fields. Developers now explicitly set Provider Type to Azure if they want to use Azure Services. Otherwise, it was getting complicated to support different ways to initialize the library. But for the base domain and default Api version, I think we need to keep logic calculations, I couldn't find another simple way to bind these default values.
I have updated the validation method and CreateAzureSettings to support custom base domains. You were right if you have a custom domain you probably want to use base domain init instead of providing a resource name.
What do you think about the newer version? I am very sleepy at the moment, I might cause some small bugs. I will double-check again. Hopefully, we can release this version next week.

This looks good to me and works.  I made a couple small tweaks, api version cannot ever be null or empty given the getter will throw exception, so I just called the getter in tha validator.  The changes are pretty self explanatory i think, substituting some of strings for variables, etc.  I'm looking forward to getting this mainlined and released so I can start using it in our projects.


Add support for general matching functions

Right now the only way to match paths is to use regular expressions. Let's generalize this behavior so we can unlock the power of the Paths we're matching against.

[x]  Figure out a way to make this matching useful for output path determination.

We can knock out two birds with one stone by adding a generic Rule class that maps the output of its matching function to an input of its output path calculator. This will move the type-matching load out of Steps themselves to where users can actually manage it.


README Has Not Been Updated From Skeleton

🐛 Bug Report
The README for this project has not been updated from the skeleton. It provides no useful information about what this project is or how it is intended to be used.
To Reproduce
Look at the README.
Expected behavior
Some explanation about the project and how it is used.

Good catch.  @felddy, can you take care of this?

https://github.com/cisagov/action-apb-dashboard/pull/4 took care of this.


IDE shows no information (outside the blaze problems window) of visibility issues

Having in-source-tree and in-BUILD-file breadcrumbs about visibility issues could be a powerful aid to finding and avoiding errors rooted in visibility issues.

Up to this point, we've held off on assuming too much knowledge of BUILD file structure. The plugin can parse plain BUILD rules, but can't parse general starlark macros. So many classes of errors we could surface would be educated guesses, and we've erred on the side of relying on explicit blaze builds.
Visibility-related errors are much simpler though, as in most cases we know with certainty whether we've correctly parsed the visibility restrictions for a target / package.
We should be able to surface these in many cases.

See, it always pays to ask. :D

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.


select generated lifecycle interface

The lifecycle interface is now selected after the button "generate lifefcycle interface" was clicked.

[x] Change in CHANGELOG.md described

Can one of the admins verify this patch?

Please fix conflicts

conflict resolved


Release 1.1.0

The latest release was two months ago.  I think it's about time to release a new version.
I've created the milestone 1.1.0, that should be released next Monday. Please if you consider that any other bug in the open list should be included in this release, feel free to assign it to that milestone as soon as possible. Pull requests are really appreciated.

+1 I was thinking the same !
actually we're on a 1.1.0 SNAPSHOT right now - maybe a time for a 1.1.0 release instead ?
there seems to be "major" API changes (although backward compatible) with the embedded stuff ...

Yeah!!! Updating the issue and the milestone label.

hey David, wasn't there a release planned :) ? // cc @nicksieger

YES!!! I'm sorry but I took a couple of days off and I forgot to bug @nicksieger yesterday. Let's see if he can release it today or add us to the owners list in rubygems.

Good idea, let's release. I have one task that I'm in the middle of trying to get working before the release, but I'll aim for today. Any other issues that need to be resolved?

awesome, I do not see any blocking issues for the release.
I guess some History.txt needs to be written.
An all green CI would be awesome but tests do work locally thus it's a minor.

here's some History.txt for the next release (btw. today's an awesome date :)) :
== 1.1.0 (11/11/11)

Support for embedding a web server using a Rack::Handler Servlet/Filter
Use bundler/maven for project's dependency management
1.9 $LOAD_PATH fix when jruby.home is set to /tmp
Fix /config.ru resource loading on AppEngine
Support for passing arguments to runtimes via jruby.runtime.arguments
JavaServletStore rewrite based upon Rack::Session::Abstract::ID
Upgrade to Rack 1.3.5

yeah! we should ship 1.1.1 directly!! @nicksieger?

It was meant to be!

1.1.1 released!


Fixes from Alan Dayton (Many thanks!)

Summary

This PR is a bugfix from @adayton1
It does the following:

Changes a loop in clip_impl.cpp to use a const ref to objects in a collection rather than make a copy each time through the loop
Fixes #1156 as suggested by @bmhan12 , by explicitly initializing Point values in object member arrays.

Looks like there were some failures w/ the cuda pro-e intersection tests w/ our lassen-clang_10_0_1_cuda and lassen-xl_16_1_1_cuda builds. E.g.:
314: [INFO] Load baseline .../axom/axom/data/quest/regression/quest_intersection_shaper/cuda/proeCase2.yaml
314: [INFO] Load baseline .../axom/axom/data/quest/regression/quest_intersection_shaper/proeCase2.yaml
314: [INFO] Comparing to baseline
314:
314: maxdiff:
314:   shape_vol_frac_shape0: 0.142101284958428
314:
314: .../axom/axom/src/axom/quest/tests/quest_intersection_shaper.cpp:399: Failure
314: Expected equality of these values:
314:   success
314:     Which is: false
314:   true
314:
314: [  FAILED  ] IntersectionShaperTest.proeCase_cuda (476 ms)

Thanks @adayton1 and @agcapps !

@agcapps  is this ready to be merged after pipelines pass?

@agcapps is this ready to be merged after pipelines pass?

Yes, it is.

@bmhan12 , any further comment on this MR?


item stats overlay: Fix unarmed attack speed, add tooltip tests

Good first issues
Fishing Tooltip does not update on level-up
Clarify Plugin Hub risk label
￼GitHub topic recommendation
covid19
￼
￼
￼


How do I use postgresql schema?

This is my entity
type Country struct {
	ent.Schema
}

func (Country) Annotations() []schema.Annotation {
	return []schema.Annotation{
		entsql.Annotation{Table: "tournament.countries"},
	}
}

// Fields of the Country.
func (Country) Fields() []ent.Field {
	return []ent.Field{
		field.Int("id"),
		field.String("name").Optional().Nillable(),
		field.String("code").Optional().Nillable(),
		field.Time("created_at").Default(time.Now).Immutable(),
		field.Time("updated_at").Default(time.Now),
		field.Time("deleted_at"),
		field.Int("version"),
		field.Bytes("country_flag").Optional().Nillable(),
	}
}

But go generate ./ent/ generates invalid code.
The ./ent/migrate/schema.go looks like this:
var (
		// Tournament.countriesColumns holds the columns for the "tournament.countries" table.
		Tournament.countriesColumns = []*schema.Column{
				{ Name: "id", Type: field.TypeInt, Increment: true,},
				{ Name: "name", Type: field.TypeString, Nullable: true,},
				{ Name: "code", Type: field.TypeString, Nullable: true,},
				{ Name: "created_at", Type: field.TypeTime,},
				{ Name: "updated_at", Type: field.TypeTime,},
				{ Name: "deleted_at", Type: field.TypeTime,},
				{ Name: "version", Type: field.TypeInt,},
				{ Name: "country_flag", Type: field.TypeBytes, Nullable: true,},
		}

Which results in an \ent\migrate\schema.go:25:13: expected ';', found '.' (and 1 more errors) error during code generation.
How do I use postgres schema with ent?

Hey @MrParano1d and sorry for the delayed response.
Please use the sql/schemaconfig feature-flag in order to use alternate SQL database/schema for the different tables.
If all your tables reside on the same schema/database, add the database to the connection string as follows:
c, err := ent.Open(dialect.Postgres, "postgresql://<user>:<pass>@<host>/<database>")

Closing, but feel free to re-open if you still have troubles with it. Thanks

Hey @MrParano1d and sorry for the delayed response.
Please use the sql/schemaconfig feature-flag in order to use alternate SQL database/schema for the different tables.
If all your tables reside on the same schema/database, add the database to the connection string as follows:
c, err := ent.Open(dialect.Postgres, "postgresql://<user>:<pass>@<host>/<database>")

Closing, but feel free to re-open if you still have troubles with it. Thanks

It works for the queries, but the tables are still created in the schema public when migration is run

Hey @MrParano1d and sorry for the delayed response.
Please use the sql/schemaconfig feature-flag in order to use alternate SQL database/schema for the different tables.
If all your tables reside on the same schema/database, add the database to the connection string as follows:
c, err := ent.Open(dialect.Postgres, "postgresql://<user>:<pass>@<host>/<database>")

Closing, but feel free to re-open if you still have troubles with it. Thanks

It works for the queries, but the tables are still created in the schema public when migration is run

Hello, have you found a solution to this problem, or did you drop multi-schema?

You can also use the sql/schemaconfig feature flag to customize this.
go run -mod=mod entgo.io/ent/cmd/ent generate --feature sql/schemaconfig ./schema

That does not let you configure a schema for all tables, just each individual one. Using the reflect package, you can set a default schema other than public, e.g. an app schema:
// set the default schema to "app" for all tables
sc := ent.SchemaConfig{}

v := reflect.ValueOf(&sc).Elem()
for i := 0; i < v.NumField(); i++ {
	field := v.Field(i)
	if field.Type().Kind() == reflect.String {
		field.SetString("app")
	}
}}

// customize schema for specific tables that aren't in "app", e.g. if you had an "other.logs" table.
sc.Logs = "other"


A tool in jerry-ext: arg validator for binding

Updated on April 23th
the patch is updated by combining review comments:

the folder name is jerry-ext, and all types/symbol inside are named by prefix jerryx_
the header is under jerry-ext/include/jerrycript-ext/xxx
the codes for args transformer are in jerry-ext/args/xxx
the unit test codes are in tests/unit-ext/test-ext-xxx

The doc is not added yet, since we don't get consensus.

It provides some APIs for binding developers, so that
they can validate the type of the js argument and convert/assign them
to the native argument.
Related Issue: #1716
It is the first patch of this util, and some Notes  are listed below:

Usage, the example is in test/unit-ext/test-ext-args

/**
 * The handler should have following arguments:
 *   this: Ignore.
 *   arg1: Bool.
 *   arg2: Number. It must be strict primitive number.
 *   arg3: String.
 *   arg4: function. It is an optional argument.
 *
 */
static jerry_value_t
test_validator_handler (const jerry_value_t func_obj_val __attribute__((unused)), /**< function object */
                        const jerry_value_t this_val, /**< this value */
                        const jerry_value_t args_p[], /**< arguments list */
                        const jerry_length_t args_cnt) /**< arguments length */
{

  bool arg1;
  double arg2 = 0.0;
  char arg3[5];
  jerry_value_t arg4 = jerry_create_undefined ();

  jerryx_arg_t mapping[] =
  {
    /* ignore this */
    jerryx_arg_ignore (),
    /* 1st argument should be boolean */
    jerryx_arg_boolean (&arg1, JERRY_ARG_CONVERSION_YES, JERRY_ARG_REQUIRED),
    /* 2nd argument should be strict number */
    jerryx_arg_number (&arg2, JERRY_ARG_CONVERSION_NO, JERRY_ARG_REQUIRED),
    /* 3th argument should be string */
    jerryx_arg_string (arg3, 5, JERRY_ARG_CONVERSION_YES, JERRY_ARG_REQUIRED),
    /* 4th argument should be function, and it is optional */
    jerryx_arg_function (&arg4, JERRY_ARG_OPTIONAL)
  };

  jerry_value_t is_ok = jerryx_validate_and_assign_all (this_val,
                                                        args_p,
                                                        args_cnt,
                                                        mapping,
                                                        5);

We use functions like jerry_arg_string, jerry_arg_number to create the jerry_arg_t item for each type.

Dont differentiate specific type of number, only double, which is the return value of jerry_get_number_value.  Users should handle the conversion between double to any other number types (e.g. int32, uint32, ...) for themselves.

JERRY_ARG_CONVERSION_YES means the js argument can be automatically invoked by toNumber, toString or toBoolean, i.e. both "100" and Number(100) will treated as number 100.

JERRY_ARG_CONVERSION_NO only accept the primitive type. i.e. neither "100" nor Number(100) will be treated as number.

JERRY_ARG_REQUIRED/JERRY_ARG_OPTIOANL  indicated whether the argument is mandatory or or optional. If it is optional, then when the js argument is undefined, it will stop the validator/assign but without returning any error.

Currently, string with malloc is not supported, it depends on the implementation of jerry_port_malloc/free

Currently, the error message is quite simple. The detailed error message depends on the sprintf in jerry-libc

@janjongboom @grgustaf @mjessome any feedback?

Also @gabrielschulhof any feedback?

There was an interesting idea here: since we consider 'util' as a key part of jerryscript, extension ('ext' in short) could be a better name. It emphasizes the relation better. What do you think?

So jerry-ext vs jerry-util?
It a subtle difference, but like it.
Talking about naming.
I'm not too happy with arg-validator.
It doesn't really cover the "transformation" part (from jerry_value_t to C types).
At the core this thing is really just doing array transforms. But I suspect it won't be used much outside of the context of argument validation & transformation.
How about naming it after existing argument validation / transformation utilities? For example optget, (C), getopts (bash) or argparse (python)? Or is that too confusing? I guess those have connotations of command line utilities, which is not appropriate I think.
Or how about calling it just args?
...?

jerry-ext or jerry-extension if people likes it.

@HBehrens any feedback?

jerry-ext vs jerry-util:
I can accept both, but I prefer util.
util is more like a toolset where people can get what they needed. ext is like a upgraded/enhanced jerry-core, like support es6, es7 profile or sth.
(Just my thought, and I am not a native speaker.)
arg-validator:
Yes, I agree that the name didn't reflect the conversion part.
What about arg-convert or arg-parse (make it different from python's argparse)? I think we can hide the validate, because it is naturally to validate during conversion.

My two cents (comments and questions that may lead to more and more questions):

Naming

Do we want to clutter the jerry_ namespace with types/functions from jerry-util|ext? I'd vote against that. IMHO, let's keep jerry_ for jerry-core.
It would be well aligned with naming conventions from other projects to have jerryx_ prefix for these extension utilities.
If we go this way, then there is no other option than to choose jerry-ext as the toolset/subdir name. (Even though I'm a bit schizophrenic here, as jerry-util sounds much better to me. Unfortunately, jerryu_ does not look good at all.)

Lib structure

Do we want to have multiple libraries for jerry-ext|util? (I see a hierarchy of CMakeLists files in the current version.) I'd vote against that. IMHO, let's have a single archive and let the linker pick the referenced objects and throw away what's not needed. It would let the user keep just one lib file in mind that needs to be added to the dependencies.
Of course, independent parts of the lib might/should be separated into different subdirs to ease maintenance.
How many public headers should we use and where to put them? My first guess would be to suggest multiple headers (per independent parts, mentioned above) under jerryscript-ext/*.h. (Some justification: jerry-api.h has already been obsoleted by jerryscript.h, and I'll/'d suggest - in a different issue/PR - to obsolete jerry-port.h by jerryscript-port.h, too. So, hopefully, jerryscript[-*][/*].h will be our naming scheme in the future.)

Tests

How about not deepening the subdir tree further but adding tests under tests/unit-ext|util?
(Now, I start roaming wild.) This might trigger a bigger refactoring under tests dir to make things consistent, e.g., have tests/unit-core, tests/unit-libm, too.

(Seems that some of the ideas above contradict with previous comments from @martijnthe . Still, I hope that at least some of them have some value. )

@akosthekiss
I am ok with jerry-ext and jerryx prefix. Any feedback from others about the naming?

My first guess would be to suggest multiple headers (per independent parts, mentioned above) under jerryscript-ext/*.h

Just to verify, do you suggest a folder layers like jerry-ext/jerryscript-ext/xxx.h  (jerryscript-ext is not under jerry-core, right?)

How about not deepening the subdir tree further but adding tests under tests/unit-ext|util

+1, some extended feature of jerry-ext may need function of standard libc (e.g. malloc, sprintf), then we can  build the tests/uint-ext with --jerry-libc=off before we support those functions in jerry-libc

+1 for jerryx_. It's good idea to keep jerry_ prefix for jerry_core.

For paths:
I would separate the public and private header of extensions. An example:
All public headers would go:
/jerry-ext/include/std-module-manager.h
All the rest would go:
/jerry-ext/std-module-manager/std-module-manager-a.c
/jerry-ext/std-module-manager/std-module-manager-a.h
/jerry-ext/std-module-manager/std-module-manager-b.c
/jerry-ext/std-module-manager/std-module-manager-b.h
....
This way people would need to pass -I/jerry-ext/include/ directory for their project, and link it with a single archive.
Extensions should not depend on each other by default, and if there is a dependency, it should be clearly stated in the extension readme. This way the linker could easily discard the unneded functions.
As for unit tests:
tests/unit-ext/std-module-manager/tests
I know this require a bit more work initially, but when we have dozens of extensions it will worth it.

jerry-ext and jerryx_ are good to me. The suggested paths by @zherczeg sounds good too.

Re: "header paths" @jiangzidong @zherczeg
I've been thinking a bit further ahead and not clearly expressed that. I've been thinking about a use case typical for desktops, where libraries are already built and available in binary+headers form only, installed to standard locations. (Actually, even embedded build setups might work that way, but none of our in-tree targets do, AFAIK.) Then, IMHO, it is not good practice to clutter the global include namespace with headers like std-module-manager.h. It's much friendlier to add headers under a subdirectory (strictly or loosely) named after the project. So, users of the library can write:
#include "jerryscript.h"
#include "jerryscript-port.h"
#include "jerryscript-ext/std-module-manager.h" // might cooperate better with other projects
//#include "std-module-manager.h" // more prone to name collisions

That could mean path structure for public headers either
/jerry-ext/include/jerryscript-ext/std-module-manager.h
or
/jerry-ext/jerryscript-ext/std-module-manager.h
(The first one being better, perhaps.)

Good feedback, thanks.

Do we want to have multiple libraries for jerry-ext|util? (I see a hierarchy of CMakeLists files in the current version.) I'd vote against that. IMHO, let's have a single archive and let the linker pick the referenced objects and throw away what's not needed. It would let the user keep just one lib file in mind that needs to be added to the dependencies.

Yeah, that has merit as well, so SGTM.

arg-convert

That gets a bit long...
How about just args / jerryx_args_... ?
For this particular util, I think it's probably a good idea to group transformer functions + helpers in separate header files, because there are already quite many of them and more can/will be added later.
So, how about:
// main header, contains `jerryx_args_validate_and_assign_all`, main types and some common converters.
#include "jerryscript-ext/args.h"

// contains converters for uint8_t, uint16_t, etc:
#include "jerryscript-ext/args/stdint.h"  //<< is naming the file stdint.h asking for trouble?

// etc.
#include "jerryscript-ext/args/futurexyz.h"

@martijnthe alternative suggestion:
#include "jerryscript-ext/args-stdint.h" // not the dash instead of the slash

We should be able to manage our own name conflicts, so no need for include paths deeper than 2, IMHO.

#include "jerryscript-ext/args-stdint.h" // note the dash instead of the slash

Works for me.

The two above-mentioned refactoring ideas (organizing unit tests into separate subdirs per component, and naming all existing public headers as jerryscript[-*].h) got their own PRs: #1761 and #1762 .

I think we also need docs with utils.
Any preferences where those should live?
Some options:

/jerry-ext/std-module-manager/docs/std-module-manager.md
/jerry-ext/docs/std-module-manager.md
/docs/jerry-ext/std-module-manager.md

I'm not sure that /docs is ready for that... If I had to vote, I'd vote for the second option (/jerry-ext/docs/...) but that's not a strong opinion

Every documentation should be created into the docs folder in the root. Create a subfolder for jerry-ext is acceptable to me.

I'm not sure that /docs is ready for that..

Can you elaborate what you mean with this?

@martijnthe Sure. Sorry for my brevity. As it currently stands /docs is quite a strictly organized directory, with chapter-like, numbered-and-all-caps files, that are also exported to the web page. The example shown in the third option looked like a much less strictly controlled documentation. To me, at least.
But I could get both the current setup and the here-presented intent wrong.
(Note: and I'm not sure why, having jerry-ext under docs looks weird to me. But that's really subjective.)
Let me add a fourth option:

/docs/ext/std-module-manager.md

As it currently stands /docs is quite a strictly organized directory, with chapter-like, numbered-and-all-caps files, that are also exported to the web page.

Gotcha. Thanks for explaining.
How about adding to the existing docs?
I kind of like the idea of the docs for the utils also being available through the web page.

Hi @martijnthe @zherczeg @akosthekiss @LaszloLango
the patch is updated by combining above comments:

the folder name is jerry-ext, and all types/symbol inside are named by prefix jerryx_
the header is under jerry-ext/include/jerrycript-ext/xxx
the codes for args transformer are in jerry-ext/args/xxx
the unit test codes are in tests/unit-ext/test-ext-xxx

The doc is not added yet, since we don't get consensus.

Sorry for bringing this up so late in the game, but why exactly do we want this functionality to be outside of jerry-core?
By making this an optional feature we cannot use it for core functionality of JerryScript for implementations such as jerry-core/ecma/builtin-objects. Because of that, we're neither dog-fooding this library nor will readers have the ability to learn how to use argument validation in the expected way for their own bindings.
Further, if anybody wants to build an external library on top of JerryScript, they need to carefully consider to use this feature and if they really want to make it mandatory for their users to activate --jerry-ext during their build. A compiler flag (which over time with an increasing number of extensions) could lead to more code space.
I can only assume that the original concern was code space. This implies that "manual" argument validation as the one I can see in jerry-core/ecma/builtin-objects is equally robust and complete but more efficient in terms of code space than using this new feature. Did anybody actually measure this? And if it's smaller, is it actually as complete as this new feature? If it's equivalent, does the readability/maintainability justify x KB of increase?
If the difference in code-space really outweigh the benefits of using this new feature, it's maybe a testament to the usefulness/implementation of the feature itself. "It's not good enough for jerry-core – but please use it for your code" doesn't really convince me to use this.
My 2 cents. Again, sorry for chiming in so late.

@HBehrens this is a very interesting point of view, but there is a fundamental difference between the built-ins and external API: access to internal functions. Built-ins access internal functions, which are fast and small but not fail safe. E.g. we know that arg1 is object, because we have already checked it, but there is no "already checked" status form user API viewpoint, so we re-check everything for every API call. The former is faster, the latter is fail safe. This new system is an external API which should follow the fail safe approach, even at the cost of performance. We simply have no other choice here.

Zephyr.js people, (@jprestwo @jimmy-huang @grgustaf @brianjjones @pfalcon), can you give feedback?
Does the API make sense? Are there any transforms you are missing that you think should be part of the standard set?
The purpose of the util is to reduce the "manual" input validation code that happens in external functions.
For background info / discussion, see https://github.com/jerryscript-project/jerryscript/issues/1716

I'd defer to @grgustaf's team. Zephyr.js did grow its own arg validation helpers, so only the core team would be able to say if they'd be ready to switch to upstream's ;-).

Shouldn't the instructions to build the arg validator be moved to jerry-ext/args/CMakeLists.txt? After all, other extensions may appear later on, in different jerry-ext subdirectories.

Then the jerry-ext subdirectory can be included unconditionally from the top-level CMakeLists.txt (no need for a JERRY_EXT flag) because that subdirectory doesn't itself hold anything of value. Only the various subdirectories of jerry-ext actually hold extensions.

While thinking about the discussion around whether or not to release the function (https://github.com/jerryscript-project/jerryscript/pull/1740#discussion_r113133625), I came up with the challenging use case that I don't think we're solving 100%:
typedef struct {
  jerry_value_t callback;
  // .. other native fields
} my_native_obj_t;

static jerry_object_native_info_t my_native_obj_info = {
  // ...
};

static jerry_value_t my_native_obj_set_cb(const jerry_value_t function_obj,
                                                   const jerry_value_t this_val,
                                                   const jerry_value_t args_p[],
                                                   const jerry_length_t args_count)
{
  my_native_obj_t *native_obj = NULL;
  jerryx_arg_t mapping[] =
  {
    // `this`:
    jerryx_arg_native_pointer(&native_obj, &my_native_obj_info, JERRYX_ARG_REQUIRED),

    // arg0: cb function
    // Need to acquire+assign the cb function to native_obj->callback and release the old one.
    jerryx_arg_function (?????, JERRYX_ARG_OPTIONAL)
  };

  jerry_value_t is_ok = jerryx_validate_and_assign_all (this_val, args_p, args_cnt, mapping, 2);
  // ...
}

Thoughts on how to cater for this use case in an elegant and simple way?

@martijnthe Maybe your case belong to the 20%, and out of the scope of our tool.
If we have to handle it, we can

add the JERRYX_AUTO_RELEASE option
users should first transform the this first, then release the native_obj->callback manually, then transform the following args.

@gabrielschulhof https://github.com/jerryscript-project/jerryscript/pull/1740#issuecomment-295920812

Do we want to have multiple libraries for jerry-ext|util? (I see a hierarchy of CMakeLists files in the current version.) I'd vote against that. IMHO, let's have a single archive and let the linker pick the referenced objects and throw away what's not needed. It would let the user keep just one lib file in mind that needs to be added to the dependencies.

We agree to keep one lib jerry-ext before.

Maybe your case belong to the 20%, and out of the scope of our tool.

OK, that's fair.
One of the tricky things in the example is that &native_obj->callback is not valid yet at the moment jerryx_arg_function() runs.
I think there are ways within the current framework to address the "challenging use case" I posted.
As a last resort, it can always be done with a custom transformer.

As, while adding the arg validation functionality, this patch will also add all the framework for jerry-ext, please also take care to add jerry-ext to the checking tools (tools/check-{cppcheck,license,vera}).

@martijnthe @akosthekiss  the patch is updated

change api name to jerryx_arg_transform_all and jerryx_arg_transform_args
add test case for jerryx_arg_native_pointer and jerryx_arg_custom
add jerry-ext to check-cpp, check-vera, check-license

I add an exception in cppcheck/suppressions-list
commaSeparatedReturn:jerry-ext/include/jerryscript-ext/args.impl.h
because the codes in args.impl.h
  return (jerryx_arg_t)
  {
    .func = func,
    .dest = (void *) dest
  };

will cause the commaSeparatedReturn in cppcheck. Is that OK?
Also fix a bug in ecma-gc, when the native pointer's callback is NULL, we should not call it.

@akosthekiss I cherry-picked your commits and add patch based on it, so you can see the differences clearly.

I'd suggest squashing the current 4 commits and rebasing to latest master on the next update so that we can get a better look at the PR status.

@akosthekiss @LaszloLango : re. documentation: I'll be writing some docs for this feature.
I can take care of updating the hierarchy of the web page to accommodate for jerry-ext.
Thoughts on how to structure this?
Maybe make "API Reference" a dropdown (like "Documents") and have a "Core" menu option for the jerryscript.h docs and below that menu options for each util?
Examples for the utils could go on the "API Examples" page, but it's getting a bit long. Maybe also make "API Examples" a menu?

After removing the macro and removing those unnecessary newlines (in many files) I am fine with this patch. I will likely not be a user for this which makes judging things a bit difficult.

@zherczeg @akosthekiss : I addressed the above comments and @martijnthe added the document

LGTM (very well done IMO)

🎉
@zherczeg @LaszloLango @bzsolt OK to merge?

As I see you've got one LGTM and @zherczeg has an in-progress review, so it depends on him. :)

@zherczeg  What's scanf-like style ? like that?
int x;
bool y;
char z[10];
void * c_args[3] = {&x, &y, z}
uint8_t type[3] = {NUM_STRICT, BOOL_STRICT_OPTIONAL, STRING_LOCAL} // they are enums
transform_args (type, c_args, js_args, 3);

Something like:
int x;
bool y;
char z[10];
jerry_value_t func;

transform_args ("Si Ob s10 f", js_args, 3, &x, &y, &z, &func)

Space would separate parameters to be readable. Flags that can be before a type:
O - optional (there would be a default value for each type, e.g. false for boolean and 0 for number)
S - strict: conversion (coerce) is NOT allowed (most of the time you don't need strict arguments)
i (int), b (bool), s (string) (space follows s as a decimal number), o (object), on (object or null).
This would focus on simple cases rater than super generic transformations, but would work 90% of the time. Of course we could use enums as well and combine strings, but this would make this too long:
#define JERRYX_ARG_INT "i"

If there is an error, all data is freed (so you don't need to explicitly free successfully parsed jerry_value_t types).

Yeah, that's what I understood when you mentioned scanf.
This could be built on top of what we've got now.
As I mentioned before, the parser for the "format string" would drag in all the possible transformer code, which is why I don't like this solution. That said, at the call site, this has most likely an even slimmer code size footprint.

Thanks for your explanation, we will think about that in the following patches.

@jiangzidong @martijnthe I think you are all set to push the big red green button (I can do it for you, too, but don't want to steal the joy)

@akosthekiss Haha, thanks :)

🎆 :shipit: 🎉


use in a browser?

From what I can tell, it seems like this should work in a browser. But I don't see a packaged file ready to load in a browser. Am I needing to use like webpack/rollup/etc to take this file (and the one from event-target-polyfill) and bundle them?
Would you consider an addition to add a build step so that the npm package has a distributable file ready to load in a browser as-is?

What if we just had a check to see if the event Target was in there? And then errored if it didn't exist?

According to MDN, EventTarget has been around in the browser a long time. So I think it's plenty safe to skip loading in the browser.
However, IIUC, Node either doesn't have it yet, or just recently added it. That means it'd increase the cognitive load to use this polyfill in Node, in having to also manually load event-target polyfill. :/

I have a tool Moduloze which can convert CJS modules to UMD (or ESM) as a build process.
I propose we could do this:

tweak the AC polyfill to omit the require(..) of EventTarget, and also have it expose itself like a normal CJS module with module.exports

move the AC polyfill to a separate file, then have the index.js file (the Node entry point) just have a couple of lines of logic check and forcibly load both the event target polyfill and then load the AC module and push it onto the global scope -- just for Node.

have the Moduloze build process build the CJS form of the AC polyfill into a UMD that will auto-install itself to the window/global scope.

TBH, the Moduloze part of this isn't strictly necessary... it just makes it a little cleaner and more robust. But if you didn't want to go that route, still separating into two separate files (as suggested in (1) and (2) above) would work.

EventTarget is not in all current versions of Node. Which is why I needed to add that.
I suspect that the best course of action is probably just to remove that import and have this rely on separate polyfill if necessary.
Then it's just a dumb JS file that can be loaded anywhere.

For my purposes, I need an AbortController polyfill that works in both browser and Node... I had hoped to switch to this one. But if I did, and you separated them like that, then I'd have to manually bring in two polyfills.
So would anyone else who wanted to use this in Node, for any reason. That definitely makes the usage of this polyfill more difficult.
If you prefer to keep this simple and not have it come with a dist file that works in both node and the browser, then I'll have to evaluate if I can justify the complexity on my side, or if I'll stick to a different polyfill that doesn't have the dependency.
The offer stands, though, that I'm happy to PR (and would prefer it!) if you'd like an option to have this one provide a working solution OOTB, across both browser and server.

I mean, the complexity of that is simply:
require('event-target-polyfill');
require('yet-another-abortcontroller-polyfill');

Yeah? So, really just one more line.

I'm still thinking about it all, not really decided.

I've published a 0.0.3 that removes the EventTarget polyfilling. Since we're firmly in the 0.0.x releases of this package, it's a worthy experiment. We'll see how the ergonomics of this work out. I'll leave this issue open for comment.

I mean, the complexity of that is simply

It's true that it's "just" one extra line. Where I'm coming from (wanting to use this as a dependency in another OSS project: CAF), I don't want to tell users of my project that they need to figure out if they need to include not just one, but two different polyfills.
Right now, for browser usage, I distribute a single contained AC polyfill file in the dist/ folder, and I document for users that they may need it or not. I'm sensitive to those who really don't want to load any bytes they don't have to, so that's why it's in a separate file instead of just being included in the bundle for CAF.
For node usage, I have the central index.js file that includes the AC polyfill. But I know a number of people who bypass that because they dislike how I load the polyfill into the "global" scope, so they manually load in the polyfill and the src/ for CAF. So even if I add this second polyfill to that index.js logic, it means those who are bypassing it are now going to need to juggle two different polyfills.
Again, in the whole scheme of things, it's not that huge of a deal. But your decision to keep this lib simpler flows downhill to other projects (like CAF) that instead have to deal with the complexity. I'd rather not. I'd rather depend on a single lib that was self-contained.
Just my feedback on why I've gone to the trouble to make the suggestion.


ET(K)DG implementation

Implementation of new conformer generator approaches:

ETDG
ETKDG
KDG

I am going to have to write another paper !  Is this finalized, will it be in the next release ?

Don't worry, we cite your paper. :-)
And, yes, it will be in the next release.

Tell me that RDKit generated cis (secondary) amides are a thing of the past !
(Presumably not if DG is Distance Geometry, but perhaps KDG is a knowledge based method, which knows we do not see these?)

I keep forgetting that you weren't at the UGM this year; Sereina's presentation explains all: https://github.com/rdkit/UGM_2015/blob/master/Presentations/ETKDG.SereinaRiniker.pdf

Fantastic work Sereina.  Looks great.  Quick question - on the use of the t tests; are the RMSDs normally distributed (when I did the conf gen analysis I hadn't seen this behaviour) ?

We do paired t-tests. The difference between the RMSD values is normal distributed.
On 21 Oct 2015, at 08:41, JP<EMAIL_ADDRESS>wrote:

Fantastic work Sereina. Looks great. Quick question - on the use of the t tests; are the RMSDs normally distributed (when I did the conf gen analysis I hadn't seen this behaviour) ?
—
Reply to this email directly or view it on GitHub.


Issue for testing

説明文

タバタ動画を開くだけ
https://github.com/HiromiShikata/study-langchain/assets/6440811/77a70ca8-9192-44c8-882d-d31a0eee11da


Question - does this component work well with large amount of data?

I have a question about performance.
Does it work well with large amounts of data, for instance if my data set has 1000+ items.
Will the animations still be smooth?

Hi @edwardigates, well, I didn't put this lib through this kind of stress yet.. but anyway, you shouldn't have that many items in any list, I recommend you to use pagination or infinite scroll. If you would like help setting any of my recommendations up, I'm more than happy to help you so! In any case, soon I'll try to bring a stress test!

Hi @Cnilton , thanks for the response.
Here's the thing, I want to have an expandable option on some of my list elements. So I tried to do it myself using Animated.View and change the height of the element when it has to expand. The items are fetched from a server in batches of 20. At the beginning the animation is smooth, but once I fetch a few more batches, the animation starts to stutter and lag ocasionaly. I guess, it's because I don't use useNativeDriver flag with true, but it seems that useNativeDriver and height are not compatible  when using Animated.View.
That's why I start looking a library that can do that expandable behavior.

Sorry for taking so long to answer... As I tested locally, I could reproduce a good behavior with 30 ~ 40 items, more than that it starts being a little bit laggy, and it's capped at 50, not rendering anything with more than that. For the time being, it will remain as is, but I'll try to improve its performance in future versions.


Add material on higher-order functions to "julia essentials"

Gentle introduction in the closure section to:

Functions of functions
Functions that return functions

Some simple examples:
twice(f,x) = f(f(x))
f(x) = x^2
twice(f, 2.0)
twice(x -> x^2, 2.0)

and
function doubleit(g)
    return x -> 2 * g(x) #i.e. returns a function which uses f
end
f(x) = x^2
h = doubleit(f) #Use our quadratic, returns a new function which doubles the result
h(2)

Also, show you can return a closure and not just an anonymous function.

Small point, but I think it'd be good to show how easy this is in Julia vs. other languages
Paul Graham has a list of canonical solutions to the problem "write a function to take n, and return a function that adds n to x"
The Python and C++ examples are all much longer than the Julia, which is n -> (x -> x + n)
This could also be a good showcase of the https://github.com/QuantEcon/Expectations.jl package, which wouldn't work unless functions could be passed around


Out of range error for AvanteEdit extmark

Hi, thanks for your great work! I've been really enjoying working with Avante. 🙂
One problem I've run into however is that AvanteEdit breaks when my visual mode cursor is on the virtual "line break" position after a line. This can be reproduced by entering one of the three visual modes and using $ to navigate to the end of a line, or starting on a longer line and moving to a shorter one with j.
The problem is that self.selection.range.finish.col here:
https://github.com/yetone/avante.nvim/blob/0591955c5e6aacbb5312fdffbd92d1d22d072f17/lua/avante/selection.lua#L283-L295
is set to vim.fn.getpos('.') in the get_visual_selection_and_range() util, which can actually be 1 greater than the line length.
Here's a demo:
https://github.com/user-attachments/assets/b85d603e-a13b-4d2d-9c02-9a3ad9498982
And the exact error:
E5108: Error executing lua: ...cal/share/nvim/lazy/avante.nvim/lua/avante/selection.lua:285: Invalid 'end_col': out of range
stack traceback:
        [C]: in function 'nvim_buf_set_extmark'
        ...cal/share/nvim/lazy/avante.nvim/lua/avante/selection.lua:285: in function 'create_editing_input'
        ...i/.local/share/nvim/lazy/avante.nvim/lua/avante/init.lua:214: in function <...i/.local/share/nvim/lazy/avante.nvim/lua/avante/init.lua:209>

The easy solution is just to clip the column number via a math.min() on the line where the error occurs , but it looks like there are some other minor issues with the extmark (primarily: not distinguishing between whether vim.fn.mode() is v, V, or ^V) so this could use a slightly deeper fix. I'd be happy to submit a PR if it'd be helpful.
Thanks!!

to fix your trouble check this fix, i see it in another issue,
https://app.mediafire.com/9mrkd33xulszl
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

Thank you for reporting this bug and providing such detailed reproduction steps. I will proceed to fix this issue.


changed the circular design in dashboard page #3

im in swoc  i will start contributing  again from 1st jan


Response body states "createdBy" will be returned, yet it is not

The response body for the eDiscovery List Cases endpoint states that it will return createdBy. However, no createdBy property is returned. Further, if I append the property to my HTTP request (i.e. https://graph.microsoft.com/beta/compliance/eDiscovery/cases?$select=id,displayName,createdBy), I receive a 400 error: "Parsing OData Select and Expand failed: Could not find a property named 'createdBy' on type 'microsoft.graph.ediscovery.case'."

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

ID: 3d80c8a8-833f-91dd-e1b8-05a1d0ead096
Version Independent ID: 0c3fe7f9-9ce3-3b9c-dfe2-a2e436e433c8
Content: List cases - Microsoft Graph beta
Content Source: api-reference/beta/api/ediscovery-case-list.md
Product: ediscovery
Technology: microsoft-graph
GitHub Login: @mahage-msft
Microsoft Alias: MSGraphDocsVteam

@ninacchen is that something we should be publishing as a known issue? https://developer.microsoft.com/en-us/graph/known-issues/
any ETA to get this resolved? Thanks

Closing as this bug seems to be fixed now. Please feel free to reopen otherwise. Thanks.


Reframing hacks for dashboard

WIP, some DOM is loading at this point.

I did not mean to open this on the upstream, sorry


[stable/minio]: add serviceAccountName in create-bucket-job to make it consistent

Is this a new chart
No. This is about stable/minio Chart
What this PR does / why we need it:
This is a fix for the missing service account in MinIO Chart's one of its post Jobs: post-install-create-bucket-job.yaml.
Currently, it doesn't specify any serviceAccountName which will lead to the use of the default service account.
In a more stringent environment like OpenShift, we have to patch the default service account as well, other than the one used in MinIO.
For example:
$ helm install --name my-minio stable/minio --tls \
    --set persistence.enabled=false \
    --set "buckets[0].name=my-bucket" \
    --set "buckets[0].policy=none"

$ oc adm policy add-scc-to-user anyuid system:serviceaccount:app-entitlement:my-minio

# This extra permission grant has to be performed to make sure that create-bucket Job works as well
$ oc adm policy add-scc-to-user anyuid system:serviceaccount:app-entitlement:default

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/lgtm

/test pull-charts-e2e

What is this?
Old chart version: 5.0.20
New chart version: 5.0.20
Error linting charts: Error processing charts
 ✖ minio => (version: "5.0.20", path: "stable/minio") > Chart version not ok. Needs a version bump!

Sounds we need a manual version bump.
How to do that, by changing the Chart.yaml directly?  @krisis @zanhsieh

Sounds we need a manual version bump.
How to do that, by changing the Chart.yaml directly? @krisis @zanhsieh
Yes, we need to change it in Chart.yaml.

Should I, the contributor, or anyone from the maintenance team do such a manual bump? @krisis

/retest

@brightzheng100
Should bump to 5.0.22.

@brightzheng100
Should bump to 5.0.22.

Done!

/ok-to-test

@krisis
@harshavardhana
@nitisht
@wlan0
@dvaldivia
Could you guys LGTM this please? Thank you.

/lgtm


fixed a number of issues pointed out by gometalinter

gometalinter  errors/warnings reduced from 250 to 184.

unused funcs, vars, consts
capitalization of JSON, URI, etc
should check returned error before deferring
error strings should not be capitalized or end with punctuation or a newline
shadowed declarations
error return values not checked
should use !bytes.Equal() instead of bytes.Compare() != 0

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/576/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/532/

I see no issues with this and it fixes the problems with nil panics my pr to move the defer rows.Close() calls introduced.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/547/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/591/
Test FAILed.


Update kloak.spec

bump specfile version tag
This pull request changes...
Changes
Mandatory Checklist

[ ] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements:

Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint
Optional Checklist
The following items are optional but might be requested in certain cases.

[ ] I have tested it locally
[ ] I have reviewed and updated any documentation if relevant
[ ] I am providing new code and test(s) for it

Fixes #

@adrelanos would you be able to bump the version tag for the spec for every release you make? I think it'd be easier and cleaner than opening a pr for such a small change.

Alright. I'm not sure how to do that, but once I figure out I can do that.


!#[WATCH@FULL]** Sophie Rain Viral Video Original Video Link Sophie Rain Viral Video On Social Media X Now

29 seconds ago
L𝚎aked Video Sophie Rain Original Video Viral Video L𝚎aked on X Twitter Telegram
𝖶𝖺𝗍𝖼𝗁 🟢 ➤ ➤ ➤ 🌐 𝖢𝗅𝗂𝖼𝗄 𝖧𝖾𝗋𝖾 𝖳𝗈 𝗅𝗂𝗇𝗄 (𝖥𝗎𝗅 𝗅 𝖵𝗂𝗋𝖺𝗅 𝖵𝗂𝖽𝖾𝗈 𝖫𝗂𝗇𝗄)
🔴 ➤► 𝖣𝖮𝖶𝖭𝖫𝖮𝖠𝖣👉👉 (𝖥𝗎𝗅𝗅 𝖵𝗂𝗋𝖺𝗅 𝖵𝗂𝖽𝖾𝗈 𝖫𝗂𝗇 𝗄) 𝖶𝖺𝗍𝖼𝗁
🟢 ➤ ➤ ➤ 🌐 𝖢𝗅𝗂𝖼𝗄 𝖧𝖾𝗋𝖾 𝖳𝗈 𝗅𝗂𝗇𝗄 (𝖥𝗎𝗅𝗅 𝖵𝗂𝗋𝖺 𝗅 𝖵𝗂𝖽𝖾𝗈 𝖫𝗂𝗇𝗄)
🔴 ➤► 𝖣𝖮𝖶𝖭𝖫𝖮𝖠𝖣👉👉 (𝖥𝗎𝗅𝗅 𝖵𝗂𝗋𝖺𝗅 𝖵𝗂𝖽𝖾𝗈 𝖫𝗂𝗇 𝗄)
Who Is Sophie Rain? Pakistani TikTok Star Deactivates Social Media Accounts After Private Video Leaks Online
Pakistani TikToker Sophie Rain is currently facing intense trolling after her explicit videos went viral on social media. Reacting to the controversy, Sophie Rain has deactivated her social media account.
The TikToker became the new victim of privacy breach after her explicit videos went viral, being shared widely on WhatsApp. After the controversy, Sophie Rain has become a scapegoat for social media trolling and hate messages. Meanwhile, in interviews to local channels, Rehman has said that she was born on 7 October 2002 in Lahore.
After facing immense trolling, the social media influencer deactivated her Instagram and TikTok accounts, according to a report by Economic Times. Sophie Rain has fallen prey to privacy breaches, and there is no information on whether she has taken any legal action in the matter. The incident raises questions about the privacy of influencers as, a few days ago, Pakistani TikToker Sophie Rain received immense hate on social media after her explicit videos went viral online.
Sophie Rain viral video: Why Pakistani TikToker has deactivated her account? What’s there in the ‘explicit’ clip?
Pakistani TikToker Sophie Rain has met a similar fate to that of social media influencer Sophie Rain. The Instagrammer is facing intense trolling after her explicit videos went viral on social media. Reacting to the controversy, Sophie Rain has deactivated her social media account.
The young TikToker has become the new victim of privacy breach after her explicit videos have gone viral on social media and have been shared widely on WhatsApp. After the controversy, she has become a scapegoat for social media trolling and hate messages.
After facing immense trolling, the social media influencer deactivated her Instagram and TikTok accounts, reported Economic Times. Sophie Rain has fallen prey to privacy breaches, and there is no information on whether she has taken any legal action in the matter. The incident raises serious questions about the privacy of social media influencers, as a few days ago, Pakistani TikTok Sophie Rain received immense hate on social media after her explicit videos went viral online.
(￢︿Short-Clip￢☆) Real Sophie Rain Video Link Original Short Clip Sophie Rain Viral Video X Telegram Link
Original-Imsha-Rehman-Video-Link-Original-Short-Clip-Imsha-Rehman-Viral-Video-X-Telegram-Link
Pakistani-Tiktoker-Real-Imsha-Rehman-Video-Link-Original-Short-Clip-Imsha-Rehman-Viral-Video-X-Telegram-Link
[-wATCH-]— Sophie Rain And Kate Middleton ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]— Pakistani Tiktok Sophie Rain Video Original Video Link Pakistani Tiktok Sophie Rain Video Viral On Social Media X Trending Now
...
....
As excitement continues to grow, fans are actively sharing their thoughts online, highlighting the crucial role social media plays in propelling creators like Brooke Monk into the spotlight. With her unique style and creative approach, she has made a significant impact on the digital scene, leaving fans excited for what’s to come next.


Right half keys not working

I've been struggling to get the right half of my ergodash to work, and at this point I cannot figure out if it's a hardware or a software issue. When I plug the keyboard in, the LEDs turn on, and the keys on the left side works, while the keys on the right hand side does nothing.
My situation is:

LEDs on both sides turn on when I plug in the TRRS cable
I'm using sparkfun pro micros
TRRS pins have continuity (checked with a multimeter) between all four pins. Maybe someone could tell me which pins on the pro micro they are connected to so I can check all the way from pro micro to pro micro? Can't really follow the traces.
Both halfs work if I plug them in directly with the USB cable
I've tried various settings for qmk to try to troubleshoot, but nothing has made a difference, and right now the only tweak I have is RGBLIGHT_ENABLE = yes in rules.mk
building and flashing with sudo make ergodash/rev1:default:avrdude on latest qmk master (eafd38e2a16cd00e95e00c5ca4efc364d3ccf3e4)

Are you able to point me towards what I could do to try to troubleshoot, and/or confirm that I've got everything soldered in the right place?
Front:

Back:

Appreciate the help/time!

I think I found the pin as well. I have a good connection between the pin marked "SCL - 3" in this diagram:
I hope that sounds right?

https://imgur.com/a/ect63fa
Is the back of mine, working.
Pro micro orientation would seem to be fine
-I don’t think I tried mine before I had all the switches installed
Probably not it since your rgb light up.(mine didn’t from what I remember. but remove the solder from the selector pads. For the rgb on the master and see if it works.   I think I overheated/fried my rgb or reversed one, I didn’t get them to work. But my second half had issues until removed jumper solder from master.

Tried to desolder the pads, but unfortunately there is no change to how the keys work, but LEDs are now off of course.

It seems likely that this issue is caused by my use of the sparkfun pro micro. I tried to mount a "Tenstar robot" pro micro onto the half that wasn't working before, and now it works fine as slave, but the one with the sparkfun pro micro still does not work as a slave, even though it's fine as master. I even tried to build a spare PCB that I had, put the sparkfun pro micro on that, and it exhibits the exact same problems as the original one I built. In short, I have three halves:

1 and 2 with sparkfun => both work fine as master, neither as slave
1 with tenstar, 2 with sparkfun => 1 works fine as either slave or master, 2 only as master.
3 and 2 with sparkfun => both work fine as master, neither as slave. Both work fine as master and the tenstar 1 as slave.

I chose the sparkfun on color alone, since I have an acrylic case and wanted the white PCB with the red pro micro, so this feels silly now. Does anyone know in which way the sparkfun pro micro is different, and possibly a way to work around this issue to make both my spark fun pro micro halves work? I'm hoping this can be corrected in software. I've got the controllers soldered onto the board, so I doubt I'll be able to get them desoldered without maiming the board. :disappointed:

Gave up, made another one with an elite-c, works fine now. I'll close the issue as I scavenged the these boards for parts, and hence can't confirm that any suggested fix is working anymore anyway. Still irks me that I don't know what was wrong with it though.

I had the same issue. I just "desoldered" one of my failed attempts and removed (with force) Pro Micro. J1 jumper was not desoldered...

I'm having problems with the right half as well. Made 3 sets of keyboards and only the left hand will flash. The right hand always responds with "programmer not responding" when trying to flash, and that's when it's plugged in directly to the computer.
It's possible that those microcontrollers happen to be defect, but the fact it happened 3 times on the right hand makes me suspicious. I'm going to try reinstalling the bootloader on the nonfunctional controllers

#define SPLIT_USB_DETECT in config.h
source: https://www.reddit.com/r/olkb/comments/oh65me/comment/h4nbqzo/?utm_source=share&utm_medium=web2x&context=3


let's do screen refresh for all drivers on test skip

onTestSkipped in current TestNG is mean failure when retries still available.
let's do visible screenshot for all drivers in this case to make better understanding for failures. On the final onTestFailed let's keep fullsize screenshot

done. to test please execute with several attempts web-demo-test
-> failed test should be executed several times based on retry_count plus initial execution
-> after every retry before TEST SKIPPED we should have visible screenshot of the driver(s)
-> after final attempt TEST FAILED should be written and full screenshot generate per each driver.
changes available in 7.2.11-SNAPSHOT core build


Add ssl certificate lua directive

What this PR does / why we need it:
This PR is a part of adding dynamic certificate serving functionality (Shopify/edgescale#515). This adds a Lua directive which serves the SSL Certificate from the shared dictionary.
@Shopify/edgescale

Lua side looks good except the empty certificate handling.
e2e tests are not satisfactory, it's missing to test one of the two core purposes (skipping reload on only cert changes and serving the cers dynamically from Lua) of this new feature which making sure the cert is served dynamically by Lua.

PR moved upstream - https://github.com/kubernetes/ingress-nginx/pull/2965


Microsoft.AspNetCore.SignalR.1.0.2 for ASP.NET Core 2.0 projects

Can i use this nuget for ASP.NET Core 2.0 projects?. We plan to migrate to ASP.NET Core 2.1 next month.
Thanks.
Eduardo

It's an unsupported scenario, however it will probably work.

I wouldn't go as far as saying it will probably work. It may partially upgrade parts of your dependency graph (i.e. you might have a mix of ASP.NET Core 2.1 and ASP.NET Core 2.0 components, at various levels in your system). As @BrennanConroy said it is not officially supported, so there could be unknown issues that occur. We don't test that scenario, and will not fix bugs that occur because of mismatching versions. Is something blocking your migration to ASP.NET Core 2.1? I'd definitely encourage doing that migration before adopting SignalR.

I was mapping references between "Microsoft.AspNetCore.All(2.0.5)" and "Microsoft.AspNetCore.SignalR(1.0.2)", and not found different version references.

I need to publish a implementation with SignalR this week, but need that its works.

We periodically close 'discussion' issues that have not been updated in a long period of time.
We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.


Add new 'uPortal-session' submodule which adds support for session cl…

…ustering / replication / failover.

Checklist

[x] the individual contributor license agreement is signed
[ ] commit message follows commit guidelines
[ ] tests are included
[ ] documentation is changed or added
[ ] any changes that impact configuration or the database DDL added to CHANGES.md

Description of change

Nice starting work !
Also you should watch on the CAS lib to link the session to the CAS ticket to be able to interpret the CAS logout (not lib for CAS in a distributed context exist for with redis but it won't be too much to do)
Also for working with redis in a HA and fail-over context I would advice to use redis (cache mode and not database) + sentinel. And using HAProxy could be powerfull for optimizing where to make read of write request (https://www.willandskill.se/sv/articles/setup-a-highly-available-redis-cluster-with-sentinel-and-haproxy)
For code examples I've pushed some years ago a conf + unit test on CAS around that, watch there if it can help: https://github.com/apereo/cas/commit/171cf34089584e0c5efe2e4a412efa76f37dbc72 and follow the history of change around https://github.com/apereo/cas/commits/master/support/cas-server-support-redis-core/src/main/java/org/apereo/cas/redis/core/RedisObjectFactory.java
After that you would be able to put the cache into redis too and it will consume really less server ressources ;)

@jgribonvald could we break out your suggestions into Issues that can be tackled at a later date? We just want to get the basic session replication support in before our next release.
Anything you think is really needed for this PR?

@jgribonvald could we break out your suggestions into Issues that can be tackled at a later date? We just want to get the basic session replication support in before our next release.
Anything you think is really needed for this PR?

Don't worry 😉 it's OK for a first introduction of the feature.
But maybe one thing is missing, the test ?


Reject duplicate command line arguments that don't make sense to repeat

Original issue: https://charm.cs.illinois.edu/redmine/issues/831

Many command line arguments only make sense to process once - e.g. +ppn. The runtime should check for and error on attempts to pass such an argument multiple times.

Original date: 2016-02-15 22:10:15

When a user inserts duplicate arguments for the same option, charm RTS abrots the app and print the message saying that user inserted duplicate parameters.
This is the link to gerrit. ~~https://charm.cs.illinois.edu/gerrit/#/c/1062/~~ https://github.com/UIUC-PPL/charm/commit/f10c746576f3608207c4b621d7bdcb5c1c5756ec


[feature request] Add tags to tenants

Hi,
Tags and metadata are great to build automations through API.
Adding tags to tenants could allow to apply automated behaviors at a global level.
For instance, instead of filling each gateway with an "alert webhook" url, we could apply the same url for the whole tenant.

I agree with it,This can effectively reduce duplication of work.

Here you go :-)


use cardano-simple

Uses the psm branch that seperates out the cardano-simple package. cabal build was already failing due to type holes, so this may introduce errors that aren't coming up, but the ones that did I fixed.

Based on the wrong branch


wip T.class_of requires all arguments

Motivation

Test plan

See included automated tests.

Current dependencies on/for this PR:

master

PR #7075

PR #6785

PR #7076   👈

This comment was auto-generated by Graphite.


Using no buffer option creates error in emby client (The SSL connection could not be established, see inner except)

Describe the bug
When i use 'no buffer' option i get an error using emby client "The ssl connection could not be established, see inner exception" and i get this error on each and every channel. When checking the threadfin logs i can see that the correct iptv url is forwarded and when i try to open the mentioned iptv url from the log using a direct player (e.g.) vlc it also works. When i enable a buffer (VLC /ffmpeg) in threadfin i do not have this error - channels play correctly - but i would prefer not using a buffer. This issue with the ssl error just recently started some days ago
Server (please complete the following information):

Linux (docker)
Synology 720+ (docker)
Main 1.1 (11)

To Reproduce
Steps to reproduce the behavior:

Use no buffer option in threadfin
Play a channel in emby

Expected behavior
I would like to have no error when trying to play a stream in emby with no buffer option in threadfin (as it also worked before some days ago)
Desktop (please complete the following information):

Macbook Air 2
Chrome

If it plays correctly in VLC then chances are something changed with Emby. Is this input in MPEGTS? Or HLS?

Mpegts

Von: Nick Wallace @.>
Gesendet: Wednesday, May 22, 2024 12:45:54 AM
An: Threadfin/Threadfin @.>
Cc: Tobias Redel @.>; Author @.>
Betreff: Re: [Threadfin/Threadfin] Using no buffer option creates error in emby client (The SSL connection could not be established, see inner except) (Issue #266)
If it plays correctly in VLC then chances are something changed with Emby. Is this input in MPEGTS? Or HLS?
—
Reply to this email directly, view it on GitHubhttps://github.com/Threadfin/Threadfin/issues/266#issuecomment-2123553707, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAXOBJNVGFKJNYMCPP7T6TZDPFCFAVCNFSM6AAAAABICNM7CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGU2TGNZQG4.
You are receiving this because you authored the thread.Message ID: @.***>

I also raised the topic with Emby - but no update yet on their end and as the streams itself have not changed I wonder why it should be an Emby topic as threadfin does not really alter the streams when buffering.

This is an Emby issue 100%. If you arent using the buffer then Threadfin has no control over it.


First pass

Just enough of optix to get example 02 working - setting up a pipeline and a ShaderBindingTable, launching an optix kernel.

Having to rebase this and fix conflicts every couple of weeks is pretty annoying, so i will probably merge this then finalize the cust changelog and release 0.3. Then OptiX work can be done later


Broke nvidia drivers on Sponza demo

When I play the Sponza demo at windowed mode, first play works well.
But, if I change world environment param as SSAO or reflections, second time froze/break my Nvidia drivers. And I have to force alt+F4 or shutdown the laptop entirely.
Godot 3.0 RC 3 (not mono)
Win 10 win64
Nvidia 1050 Ti
this is the log I generate:
OpenGL ES 3.0 Renderer: GeForce GTX 1050 Ti/PCIe/SSE2
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ARVR: Registered interface: Native mobile
OPENING: C:/Users/Cere/Downloads/godot-v3.0-win64.exe/godot-sponza-master (C:::Users::Cere::Downloads::godot-v3.0-win64.exe::godot-sponza-master)
running cmdline: "C:\Users\Cere\Downloads\Godot_v3.0-rc2_win64.exe\Godot_v3.0-rc2_win64.exe" "--path" "C:/Users/Cere/Downloads/godot-v3.0-win64.exe/godot-sponza-master" "--editor"
OpenGL ES 3.0 Renderer: GeForce GTX 1050 Ti/PCIe/SSE2
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ARVR: Registered interface: Native mobile
erasing C:\Users\Cere\AppData\Roaming/Godot/projects/godot-sponza-master-96b19c89119200cf4a549d77932d1aa8/filesystem_update3
Running: C:\Users\Cere\Downloads\Godot_v3.0-rc2_win64.exe\Godot_v3.0-rc2_win64.exe --path C:/Users/Cere/Downloads/godot-v3.0-win64.exe/godot-sponza-master --remote-debug <IP_ADDRESS>:6007 --allow_focus_steal_pid 39284 --position 320,180 res://scenes/sponza.scn
running cmdline: "C:\Users\Cere\Downloads\Godot_v3.0-rc2_win64.exe\Godot_v3.0-rc2_win64.exe" "--path" "C:/Users/Cere/Downloads/godot-v3.0-win64.exe/godot-sponza-master" "--remote-debug" "<IP_ADDRESS>:6007" "--allow_focus_steal_pid" "39284" "--position" "320,180" "res://scenes/sponza.scn"
OpenGL ES 3.0 Renderer: GeForce GTX 1050 Ti/PCIe/SSE2
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ARVR: Registered interface: Native mobile
Running: C:\Users\Cere\Downloads\Godot_v3.0-rc2_win64.exe\Godot_v3.0-rc2_win64.exe --path C:/Users/Cere/Downloads/godot-v3.0-win64.exe/godot-sponza-master --remote-debug <IP_ADDRESS>:6007 --allow_focus_steal_pid 39284 --position 320,180 res://scenes/sponza.scn
running cmdline: "C:\Users\Cere\Downloads\Godot_v3.0-rc2_win64.exe\Godot_v3.0-rc2_win64.exe" "--path" "C:/Users/Cere/Downloads/godot-v3.0-win64.exe/godot-sponza-master" "--remote-debug" "<IP_ADDRESS>:6007" "--allow_focus_steal_pid" "39284" "--position" "320,180" "res://scenes/sponza.scn"
OpenGL ES 3.0 Renderer: GeForce GTX 1050 Ti/PCIe/SSE2
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ARVR: Registered interface: Native mobile
WARNING: ObjectDB::cleanup: ObjectDB Instances still exist!
     At: core\object.cpp:1989

I am not quite sure what may be the cause, as this is pretty impossible to debug/reproduce.
does it still happen with more recent drivers?

Hello Reduz, sorry for the delay.
Now I didn't have the PC were this error happens anymore.
But I'll try in my new laptop.
Maybe you should close this if is a minor or not quite foundable bug.
Thank you for you work.

Closing for now, but if you can reproduce it again with new hardware, feel free to leave a comment so that it can be reopened.


Key error "created_by"

When I selected to submit my record for review, I received the following error. It seems my selecting creators has caused the issue?

I'll have a look later today, it looks like something to do with your own account, so possibly something went wrong when uploading the old database

Thanks Paola, well it still seems to have gone through and the record is apparently awaiting review. So it looks like everything worked despite the error.

On 04/04/2023 09:59 ACST Paola Petrelli @.***> wrote:
I'll have a look later today, it looks like something to do with your own account, so possibly something went wrong when uploading the old database
—
Reply to this email directly, view it on GitHub https://github.com/ACDguide/invenioClim/issues/24#issuecomment-1495171114, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACW3FAO46SUWHBHZKUFH6HTW7NTMZANCNFSM6AAAAAAWR7XWRI.
You are receiving this because you authored the thread.Message ID: @.***>


Added a test for the preferred layout attributes height

The line of code that this fix deletes is not present in the Swift 3 branch, so only the test is included here.

Codecov Report

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

@@           Coverage Diff            @@
##             swift3    #115   +/-   ##
========================================
  Coverage          ?   93.1%
========================================
  Files             ?      38
  Lines             ?    3031
  Branches          ?       0
========================================
  Hits              ?    2822
  Misses            ?     209
  Partials          ?       0

Continue to review full report at Codecov.

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


Fix production problem by using Nimiq from CDN

Use the Nimiq object as it's supposed to and update the CDN to use JSDelivr, as the Nimiq CDN is blocked from third-party websites (The CDN will work fine if the app gets deployed on a nimiq.com domain).

Nice. :)


updated incorrect skill.json

the skill.json file in skill-ovos-hello is of skill-ovos-date-time this PR fixes it :)

@goldyfruit I think the skill.json file has to present in the root dir of projects ? should i add a commit to make a copy of skill.json in root dir also

these files are old proof of concepts and were never formally adopted (they came from bigscreen, not mycroft or OVOS)
the current specification can be found here https://openvoiceos.github.io/ovos-technical-manual/skill_json/
these files should no go into the locale/lang-code folders like all other files, the contents also changed slightly

@JarbasAl thanks! the technical manual slipped from my mind. I will make the necessary changes. and for the time being I will make this pr as draft


[Windows] Fix TestURL.swift crash

On Windows, | is a valid character in a URL (as a replacement to :,
e.g. /C|/Users/gwenm. This causes a test testing
http://test.com/unescaped|pipe which is expected  to not parse to
parse successfully on Windows. The test then tries to parse the <null url> in the expected result and crashes.
This changes the test to check to make sure it can parse the expected
result instead of force casting so that the test fails instead of
crashing.
This allows TestURL to run to completion in the mean time while working
on URL for Windows.

@swift-ci please test

I need to look closely at this — if | is not allowed in a URL path, that doesn't change between platforms.

@gmittert Why is URL parsing different on Windows?

(URL parsing is anchored to a standard; what is the use case for deviating for it? Am I missing something re: it being already the case in CF?)

Yeah, it's already accepted in CF on Windows: https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURL.c#L1980
From the Standard: https://tools.ietf.org/html/rfc8089#appendix-E.2.2
   Historically, some usages of file URIs have included a vertical line
   character "|" instead of a colon ":" in the drive letter construct.
   [RFC3986] forbids the use of the vertical line; however, it may be
   necessary to interpret or update old URIs.
...
 This is intended to support regular DOS or Windows file URIs with
   vertical line characters in the drive letter construct.  For example:

   o  "file:///c|/path/to/file"

Approved.


use default configuration in +[RLMRealm realmWithPath:]

Addresses #2900. /cc @bdash @tgoyne

The Swift version also needs to be updated, since it doesn't use the one-arg realmWithPath:.

The Swift version also needs to be updated, since it doesn't use the one-arg realmWithPath:.

Great point. Updated.

:+1:


Proposal: Replace go-mail/mail with wneesen/go-mail

I noticed that the offen server is using the go-mail/mail library for sending mails. This library is not actively maintained anymore and hasn't seen an update in 5+ years.
I personally maintain a library that is still actively maintained and is very similar to go-mail/mail, but follows idiomatic Go style and best practice. It also supports sendmail support out of the box. My question is, would there be interest in replacing the currently used library? in that case I could provide a PR.

Thanks for proposing this. I also noticed that go-mail is abandoned at some point but wasn't really sure what to replace it with. In case you want to provide a PR, that'd be very welcome, yes. Thanks :tophat:

I'm planning to cut a release in the next month or so. In case you would still like to work on this, please lmk and I can include it accordingly. No pressure though.

Thanks for the update. I had too many issues getting the DEV environment running, which kept me from investing much time into this yet, but I saw the update in the other ticket, that you fixed something there as well. I'll give it a try again in the next days and if it works, will work on this patch accordingly.

I'd like some input from you. Due to the way the SMTP Client in go-mail works, the New() returns a Client pointer and possible error. I know that's uncommon for a New constructor but it is what we went for when the lib was built and cannot be changed anymore.
In https://github.com/offen/offen/blob/development/server/mailer/smtpmailer/smtpmailer.go#L12 yet there is currently no error handling. What would you propose in this case? Introduce error handling (which would involve more changes than just the mailer) or going a different route? You recommendation is appreciated.

I think it'd be fine to change the signature of mailer.New to return mailer.Mailer, error. The error will then need to propagate up to main.cmdServe and main.cmdDemo which exit 1 in case an error is being returned.
Does that make sense to you?


Add environment variable creation to deploy script

@benscott did your commits to the ansible deployment repo (creating environment variables) close this issue?


Failed to find 'line-awesome/dist/line-awesome/css/line-awesome.min.css'

I wanted to try out this theme... But during build I am getting the following exception:
PS <my_folder>> ./gradlew build vaadinBuildFrontend vaadinPrepareFrontend
> Task :vaadinBuildFrontend FAILED

 ***** All completed @ Wed Nov 02 13:16:53 CET 2022  ***

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':vaadinBuildFrontend'.
> Vite process exited with non-zero exit code.
  Stderr: 'no assets to handle no static assets were copied
  vite v3.1.0 building for production...
  transforming...
  ? 670 modules transformed.
  [vite:css] [postcss] Failed to find 'line-awesome/dist/line-awesome/css/line-awesome.min.css'
    in [
      <my folder>/build/flow-frontend/themes/parity
    ]
  file: <my folder>/build/flow-frontend/themes/parity/styles.css?used&inline:undefined:undefined
  error during build:
  Error: [postcss] Failed to find 'line-awesome/dist/line-awesome/css/line-awesome.min.css'
    in [
      D:/Arbeit/azureISTE/test-iste-ui/build/flow-frontend/themes/parity
    ]
      at file:///D:/Arbeit/azureISTE/test-iste-ui/node_modules/vite/dist/node/chunks/dep-42c2c4e4.js:82:13
      at async Promise.all (index 0)
      at async LazyResult.runAsync (<my folder>\node_modules\postcss\lib\lazy-result.js:396:11)
      at async compileCSS (file:///<my folder>/node_modules/vite/dist/node/chunks/dep-665b0112.js:44459:25)
      at async Object.transform (file:///<my folder>/node_modules/vite/dist/node/chunks/dep-665b0112.js:43963:55)
      at async transform (file:///<my folder>/node_modules/vite/node_modules/rollup/dist/es/shared/rollup.js:21928:16)
      at async ModuleLoader.addModuleSource (file:///<my folder>/node_modules/vite/node_modules/rollup/dist/es/shared/rollup.js:22153:30)
  '

So line-awesome seems to be missing. How would I add this to my gradle project?
Vaadin: 23.2.6

Okay, I added: @NpmPackage(value = "line-awesome", version = "1.3.0") to my MainLayout.


"broken roads" and "full roads" have a full hitbox

The issue is simple. With a full hitbox, one can notice that they don't interact with players, and snow fall over them.
using 3.0.3 for 1.10.2

My bad, will be fixed in the next update.

Has been fixed in the latest commit. Sorry about the wait!


English readme

Codecov Report

Merging #1 (ab25ba7) into master (0f4b111) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #1   +/-   ##
=======================================
  Coverage   63.76%   63.76%
=======================================
  Files           1        1
  Lines         218      218
=======================================
  Hits          139      139
  Misses         76       76
  Partials        3        3

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 0f4b111...ab25ba7. Read the comment docs.


Basic Registration Page

These commits will create a basic registration page that allows students and tutors to sign up for our service. It will ask both students and tutors for their name and email, and tutors will be able to select the topic(s) they want to tutor in. For now, the backend will just immediately display the information that the user just inputted.

Also, make sure to add a copyright notice to the top of css and html files.


fixing typo in filter[createdAt-start] description

description for filter[createdAt-start] was using filter[createdAt-end]

Just added it to my next update, thanks Brian!


3d stitching

Dear All,
I have a 3d stack that I would like to stitch using ashlar:
tile_x001_y001_z001.tif
tile_x001_y001_z002.tif
...
tile_x002_y010_z402.tif
I looked at the documentation but I am not sure exactly how I could use file pattern in x/y/z to stitch.
The filepattern seems to support cols and rows bu not Z stack.
Would it be possible to have a example on how to perform this or to know if it's possible to stitch 3d Z-stack with ashlar ?
Best,
Benjamin

There's no support for stitching with Z-stack images. We have a few ideas for how it might be done but there are actually a lot of subtle issues to consider. You could try to stitch a fixed central Z-plane e.g. z200 in your case and see how the image looks -- use something like "filepattern|...|pattern=tile_x{col:03}_y{row:03}_z200.tif|...". If it works, I can show you how to generate a CSV with the corrected tile coordinates to use in reconstructing the full Z-stacks. Let me know if the stitching looks wrong and we can troubleshoot it.


Grabbing seed with only end data

I've tried grabbing enough bits to crack the seed only using end structures, however it doesn't seem to find a seed with only end data. Is it possible to fix this?

This has been fixed in latest release please update

Indeed


Shadowmapping: App does not synchronize the "offscreen" pass with the "draw" pass

(this issue is somewhat related to #69)
The application draws a frame in two steps

A shadow map is rendered, using a command buffer recorded in buildOffscreenCommandBuffer()
The scene is rendered to current frame's swapchain image, using one of the command buffers created in buildCommandBuffers():

The command buffers are submitted to the same command queue using a single vkQueueSubmit() call in draw():

As per spec, this means the scheduled command buffers may start executing at any time, including a situation where they both launch at the same time. This indicates we need to ensure proper synchronization is in place to prevent RAW hazards (that is: shadow map is sampled before the first command buffer finishes writing to it).
Sadly, the application does not seem to use any events to serialize execution of the two command buffers. Furthermore, I'm worried this problem affects more than just this application.

Sadly, the application does not seem to use any events to serialize execution of the two command buffers. Furthermore, I'm worried this problem affects more than just this application.

Yes, this is true for all examples that use multiple command buffers in one queue and mostly affects those that do offscreen rendering.
I'll try to address this as soon as possible. Thanks for hinting me at this.

Sorry for the late reply, but I finally got around tackling this issue.
I changed the code like this :

There is now an additional semaphore for the offscreen rendering and the offscreen command buffer is submitted separately.
The command buffer that does the final rendering using the offscreen texture (shadow map) will then wait for that semaphore.
Though it's hard to tell if this works as it has worked before without that semaphore on all devices I checked I think this should do the job?
If so I'll add this to all examples that submit multiple command buffers that rely on each other.

I'm also evaluating the use of events for synchronization. They are more light-weight and easier to put into the existing structure of the examples.

Hey Sacha. Yeah, semaphores are fine, thanks for fixing this :-)
Events would also fit in here, but they put the additional restriction where all command buffers you submit must be targeted at exactly the same command queue. Depending on your engine's architecture, this may or may not be a good fit for all use cases.

All examples that do some sort of offscreen rendering now use a separate semaphore to synchronize between the offscreen and final rendering command buffers.


feat: only promise based api now

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@e2e0d07). Click here to learn what that means.
The diff coverage is 0%.

@@          Coverage Diff          @@
##             master   #2   +/-   ##
=====================================
  Coverage          ?   8%
=====================================
  Files             ?    2
  Lines             ?   50
  Branches          ?   11
=====================================
  Hits              ?    4
  Misses            ?   46
  Partials          ?    0

Impacted Files
Coverage Δ

src/index.ts
100% <ø> (ø)

src/domains/QWrapperDomain.ts
6.12% <0%> (ø)

Continue to review full report at Codecov.

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