Hydrator generation fails silently when using custom types

Bug Report

Only some Hydrator classes are generated when using a custom type. Once the HydratorFactory tries to generate a Hydrator for a custom type, it fails silently and just stops generating the rest. Subsequent tests then fail at a require which cannot find the Hydrator file it is expecting.

Q
A

BC Break
no

Version
1.2.5

Summary

This only happens when generating as a part of cache warmup, but succeeds when running the doctrine command to generate hydrators, i.e.
# THIS FAILS
$ app/console cache:clear -e test
$ ./vendor/bin/phpunit -c app/phpunit.ci.xml --filter testCreateProductWithNumericPrice src

# THIS SUCCEEDS
$ app/console cache:clear -e test
$ app/console doctrine:mongodb:generate:hydrators -e test
$ ./vendor/bin/phpunit -c app/phpunit.ci.xml --filter testCreateProductWithNumericPrice src

I have stepped through and made some debugging output from the HydratorFactory and I can see that in the first case Hydrators are actually being created - the code is being run and is expected to create 203 classes. However, it only generates about 80, after which a hydrator for my custom class is expected to be created and the execution stops, with no errors logged.
The actual error when running PHPUnit is:
./vendor/bin/phpunit -c app/phpunit.ci.xml --exclude-group stats,integration,heavy --log-junit /tmp/phpunit_test_results.xml src/
PHP Warning:  require(/home/example/platform/app/cache/test/doctrine/odm/mongodb/Hydrators/RHLocationBundleDocumentLocationHydrator.php): failed to open stream: "VCR\Util\StreamProcessor::stream_open" call failed in /home/example/platform/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/HydratorFactory.php on line 142
PHP Fatal error:  require(): Failed opening required '/home/example/platform/app/cache/test/doctrine/odm/mongodb/Hydrators/RHLocationBundleDocumentLocationHydrator.php' (include_path='.:/usr/share/php') in /home/example/platform/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/HydratorFactory.php on line 142
PHP Fatal error:  Uncaught Error: Class 'Symfony\Component\Debug\Exception\FatalErrorException' not found in /home/example/platform/vendor/symfony/symfony/src/Symfony/Component/Debug/ErrorHandler.php:670
Stack trace:
#0 [internal function]: Symfony\Component\Debug\ErrorHandler::handleFatalError()
#1 {main}
  thrown in /home/example/platform/vendor/symfony/symfony/src/Symfony/Component/Debug/ErrorHandler.php on line 670
Script ./vendor/bin/phpunit -c app/phpunit.ci.xml --exclude-group stats,integration,heavy --log-junit /tmp/phpunit_test_results.xml src/ handling the test-ci event returned with error code 255

The custom class implementation is this:
use Doctrine\ODM\MongoDB\Types\Type;

/**
 * Custom type for storing instances of \Money\Money in MongoDB.
 */
class MoneyMongoType extends Type
{
    public function convertToDatabaseValue($value)
    {
        return [
            'amount' => $value->getAmount(),
            'currency' => $value->getCurrency()->getCode()
        ];
    }

    public function convertToPHPValue($value)
    {
        return new \Money\Money($value['amount'], new \Money\Currency($value['currency']));
    }

    public function closureToPHP()
    {
        return '$return = new \Money\Money($value[\'amount\'], new \Money\Currency($value[\'currency\']));';
    }

}

Everything works as long as I do not include my custom type in any Entity.mongodb.yml configuration - i.e. as long as no Hydrator has to be generated for that custom type.
Expected behavior
I should not need to run the command to generate hydrators manually, when the generation is executed after clearing the cache anyway.

I have stepped through and made some debugging output from the HydratorFactory and I can see that in the first case Hydrators are actually being created - the code is being run and is expected to create 203 classes. However, it only generates about 80, after which a hydrator for my custom class is expected to be created and the execution stops, with no errors logged.

Any chance you could step over generation process and see exactly what is failing? My first idea is that somehow custom types are not registered during cache warmup, but that's a blind guess.

Sorry for the long wait. I have tried stepping through it when I encountered the issue, but that was quite hard because no exception was raised. What I know for sure is that this happened in HydratorFactory::generateHydratorClass(). That leads me to believe that the custom type was registered, but somehow the generation failed.
This was a feature we needed to ship so I worked around it and didn't end up using a custom type. I will try and see if I can reproduce if I have some time in the near future.

Closing as nothing happened here in 5 years 👼


d_rawmsg debug destination doesn't work

Docs mention using a d_rawmsg destination to log raw messages locally in /opt/sc4s/archive by sourcetype. How to enable this isn't mentioned. Some info in Slack lead to adding SC4S_DEST_GLOBAL_ALTERNATES=d_rawmsg to the env_file, but this doesn't work and may be from a previous version. Confirmation of this functionality and instruction to enable it is needed.

For now it can be implemented using templating , GLOBAL_ALTERNATES are nearly deprecated, i am posting an example below how you can see the RAWMSG , it is not good practise to do it in this way , its very costly process.
block parser app-postfilter-cisco_asa_new_metadata() {
    channel {
       rewrite {
           r_set_splunk_dest_default(
               index("test_sc4s")
               template('t_fallback_kv')
           );
       };
   };
};
application app-postfilter-cisco_asa_new_metadata[sc4s-postfilter] {
    filter {
        'cisco' eq "${fields.sc4s_vendor}"
        and 'asa' eq "${fields.sc4s_product}"
    };
    parser { app-postfilter-cisco_asa_new_metadata(); };
};

It will append all the cisco asa message with RAWMSG, please feel free to change it as per your usecase.


API Ref: Universally Broken Links (Wrong Repo Target)

In the API reference, every Edit this page and View Source link targets a location under https://github.com/steffen-wilke/darkfx/.

Hmm, it's a template referenced as Dark Theme for output documentation. Seems like a bug in DocFX.

Glad to be of help!

Edit Page fixed as well.


Lobby: "Back" and "Play" buttons are hard to see/press on small phone-sized devices

This was on the iPod Touch.

I am going to either redesign the lobby screen to account for screen spacing on small devices in browser, or we are going to not allow folks to play in browser on iOS devices 5 and below,  redirecting them to download the app. This will hopefully resolve this problem. I will place this in the icebox for now.

Finished complete overhaul redesign of lobby to address this and many other issues.


fix: allow CORS requests

When testing in a browser environment, if the request is "non-trivial", the browser will trigger a preflight request first and expect the server to allow it.
The rrweb makes "non-trivial" requests as it uses a mime type that per CORS rules requires a preflight request.
Resolves #105

released in<EMAIL_ADDRESS>


Hamburger Button should not have animation enabled with full height Navigation Drawer.

I just wanted to let you know that you made an error in not manually disabling the animation for the hamburger button used for the Navigation Drawer. There is a bug in the design libraries which causes this animation to be enabled by default.
I will post two paragraphs from an article hosted on a third-party site in which Roman Nurik (A well-known Design Advocate that works for Google) explains that an animated hamburger button should not be used for a Navigation Drawer at all.
"One of the solutions Google came up with between pre-L and L designs was the spinning arrow animation. As Roman Nurik has explained, this animation doesn't actually belong in a navigation drawer interaction. It's a beautiful bit of interface chrome, but it's worth looking at why it doesn't belong.
The animation was created for instances where a hamburger button appeared consistently, but the user entered a secondary view on top of the first. For an example of this, see the yet unreleased Google Search update. The hamburger icon lives in the search bar, so when the user transitions to the bar with search suggestions, the icon transforms into an arrow."
Here is the link to the full article in which Roman Nurik (Design Advocate working for Google) explains that the spinning arrow should not be used for a navigation drawer at all: http://www.androidpolice.com/2014/10/30/google-turns-design-inconsistency-ten-latest-round-navigation-drawers/
Since this article was posted last year, the correct usage of the animated hamburger button, as defined by Roman Nurik, has been implemented in the Google Search and Google Play Store applications which you can take a look at.
I'm going to provide a link to another third-party site which explains why this hamburger button animation should be disabled and how to do it. Refer to the section titled "The Spin Bars". https://medium.com/@sotti/navigation-drawer-styling-according-material-design-5306190da08f
You can also refer to the official Gmail, Inbox by Gmail, Google Calendar, Google Docs, Google Drive, Google Hangouts, Google I/O 2015, Google Keep, Google Photos, Google Sheets, and Google Play Store applications for an example of the correct implementation.

holy tl;dr batman


Vespa-App

For this project the following functionalities were created:

Allow user to login
Allow user to create account
Allow user to logout
Allow normal user to see the list of all products
Allow admin user to see the list of all products with the delete option
Allow all users to see reserve products and delete reservations

Backend Link

Thank you, we will make the changes.

We will fix. Thank you!

Thanks!


[DO NOT MERGE] Add new user satisfaction survey

For: https://trello.com/c/b4J4OpaM/218-emotional-survey-test-banner  This survey is to run 1 in 6 frequency, on all pages (hence the lack of any activeWhen arguments in the definition) and only last for one week (Thursday -> Monday).

Flagged as DNM as I just need to confirm the dates for the survey with Sean.

Removed DNM as confirmed dates with Sean.


Expose py_run! macro

Currently, we have a macro named py_run in tests/common.rs.
I think this macro is useful for users (e.g. when testing libraries).
When exposing this macro, I made a modification.
When string literal is passed, we use indoc to generate an indented string in compile time.
In other cases, we do string conversion in runtime.

@birkenfeld
Thanks for your review!

To be generally useful, I think this should not panic on exceptions, or reflect this in the name?

Since this macro is mainly for testing, I think unwrapping is OK and more convenient.
In the latest commit I added a note about it in the document.

And I rewrote _indoc_runtime(former called indoc) so that it behaves the same as indoc! macro.


Update Frame shortcut

Correct

CI:

Linux
Linux-aarch64
Windows

Backport to foxy/humble?

Backport to foxy/humble?

I think we could; it doesn't really change API/ABI.  On the other hand, it seems like a simple cleanup, so I'm not sure it is worth it.  What's your interest in the backport?

Cleaning up my new tutorial

I'll open up the backport to Humble, though I want to have some soak time in Rolling/Iron before we merge this in.
I'm less inclined to do it for Foxy since we are so close to its EOL.

@Mergifyio backport humble


point-wise refine moduls

I read the code ，it do not have the point-wise refine moduls，Can you share？？

please refer to https://github.com/xinge008/Cylinder3D/issues/28

Thank you very much


[FLINK-14926] [state backends] Make sure no resource leak of RocksObject

What is the purpose of the change
Introduce a RocksDBOptionsContainer to make sure all RocksDB options are created, recorded, and properly freed.
Brief change log

Introduce a new RocksDBOptionsContainer class to encapsulate PredefinedOptions and OptionsFactory, as well as recording all DBOptions and ColumnFamilyOptions produced in runtime.
Close the RocksDBOptionsContainer instance whenever the RocksDB backend is disposed or error occurred during checkpoint restore or backend building process.
Change PredefinedOptions to implement AutoClosable interface.
Add a default close method in OptionsFactory for necessary clean up.

Verifying this change
This change added tests and can be verified as follows:

Added a new RocksDBOptionsContainerTest test case for the newly introduced class.
Verify all existing tests, including all tests in flink-statebackend-rocksdb module, HAQueryableStateRocksDBBackendITCase, NonHAQueryableStateRocksDBBackendITCase and LocalRecoveryITCase could pass.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

Making enum implementing AutoCloseable is a little bit anti-pattern since normally an AutoCloseable is stateful, as already reflected in PredefineOptions.SPINNING_DISK_OPTIMIZED_HIGH_MEM. On the other hand, changing PredefinedOptions from enum to class may require a bigger change, so I'm hesitating to fix it now or mark it as a TODO.

I think the closing logic on PredefinedOptions is not going to work.
It is an enum and hence a singleton instance. If someone calls close on the enum, the resource from some other call to createColumnOptions() will be disposed. That can even lead to seg faults under concurrency.
The root cause is that objects with life cycle and enums do not go together well.

I think we have three options:

Have a single the BloomFilter object that lives forever is used across RocksDB instances (is that even possible). Is the BloomFilter object large, would that be a problem?

Remove the bloom filter from the predefined options.

Special case the cleanup of the DB options to search for the BloomFilter object and close it.

I think this is a good example why I think we should move away from the predefined options in 1.10.
Having good out of the box values for memory (with the shared per-slot cache) and then OptionFactories (that can dispose their values) should make PredefinedOptions less needed in the future.

Is the BloomFilter object large, would that be a problem?
This is something I'm not that sure, need some time for investigation.

Remove the bloom filter from the predefined options.
From the javadoc SPINNING_DISK_OPTIMIZED_HIGH_MEM is for better performance on regular spinning hard disks. If user is using this in production, I guess w/ and w/o bloom filter would make a big difference...

move away from the predefined options in 1.10
I think the purpose of predefined options is not for resource management, but trying to supply an easy way of config for different use cases, especially for HDD_DISK, HDD_DISK+MEM, and FLASH_SSD. I would suggest a survey first in our ML before removing it.

What do you think if we change PredefinedOptions from enum to some instantiated class and make the configuration unchanged? Thanks.

I think that would be API breaking.
If we want to deprecate the Predefined options anyways, I would be fine with not solving this in that release (or maybe the special case option mentioned above) and then it is solved properly anyways with the removal in the next release.

About the purpose of PredefinedOptions:
I guess we want this as a default anyways for all cases. We could simply set these always, like the option to create database if missing and to disable WAL.
DBOptions
    .setIncreaseParallelism(4)
    .setUseFsync(false)
    .setMaxOpenFiles(-1)
    .setInfoLogLevel(InfoLogLevel.HEADER_LEVEL)
    .setStatsDumpPeriodSec(0);

ColumnFamilyOptions
    .setCompactionStyle(CompactionStyle.LEVEL)
    .setLevelCompactionDynamicLevelBytes(true)

The remainder are only in SPINNING_DISK_OPTIMIZED_HIGH_MEM and should pretty much be subsumed by the new memory management. In some sense new memory management is the better version of predefined options.
Am I overlooking some use cases?

I would merge this PR now without the change to PredefinedOptions and we keep trying to figure out how to best handle that in the meantime.

Actually, I think we cannot merge the options factory change either. It has the same problem as the PredefinedOptions. There is one factory (configured once on the RocksDBStateBackendObject` and from that factory, mulitple sets of options are created. If one RocksDB instance is closed, the close() method on the factory is called and may close objects also from other created options.

How about this: We change the OptionsFactory that way:
public interface OptionsFactory extends java.io.Serializable {

    DBOptions createDBOptions(DBOptions currentOptions, Collection<AutoClosable> handlesToClose);
}

Any handle created in that method can be added to that set, and the container will close those once the keyed state backend is cleared. The DBOptions object itself can also be in that collection so we only need to close one collection in the end.
The same trick also works for the PredefinedOptions.

Latest implementation following review suggestions and rebased on top of #10449 could be found  here.

Rebased with the latest code base.

I think we still have a bit of a mismatch here, between different types. You can see that at the "serializable" warnings you get for the RocksDBResourceContainer. The class is serializable but contains a lot of non-serializable fields.
We need to clearly distinguish between the handling of

"factories", like PredefinedOptions and the "OptionsFactory": These are serializable, because they do not actually contain options (with native objects).
The actual "options objects", which hold native resources.

The factories are configured on the RocksDBStateBackend and are shipped. The Resources must exist only on the RocksDBKeyedStateBackend during Task execution. The RocksDBResourceContainer handles both: it contains the factories and the options (with native resources). I think that is the root of the inconsistency.
I think the RocksDBResourceContainer should only be created when we create the keyed state backend, and not exist as a field in the RocksDBStateBackend class. Then it also would not need to be serializable, which would be consistent.

One more question: Do we consider OptionsFactory to be a stable public interface? In that case, I guess we would need some default method so ensure backwards compatibility.

@StephanEwen Thanks for the comments and suggestions! Codes updated accordingly and already got a green build in local travis, FYI.


not colored "#" and ">" after "$" in markdown

Issue Type: Bug
When I create a markdown file in Visual Studio Code, the # and > are usually colored, but the # and > on the line after the $ are not colored.
VS Code version: Code 1.62.3 (ccbaa2d27e38e5afa3e5c21c1c7bef4657064247, 2021-11-17T08:11:14.551Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No

In a new markdown file:
(colored)

 (colored)

(This is OK)
But, the following contents are not colored:
$      (not colored)
(not colored)

 (not colored)

(This is NG)
when there are even number of $, # and > seem to be colored.
$      (not colored)
$      (not colored)
(colored)

 (colored)

I hope this is reproduced.

$$
#
>

Even if there are two $ in the same line, # and > are not colored.
$$$$
#
>

if there are four $ in the same line, # and > are colored.
Umm...

/duplicate of #136535 which is fixed for the next release (1.63) due in December.
If you are able to install Insiders you can verify this.


Catch Divide-By-Zero faults instead of Page Faults in “Catching Exceptions” Post

Currently, we try to catch page faults using a simple extern "C" fn() -> ! handler function. The problem is that the CPU pushes an error code on page faults, which leads to a wrong stack pointer alignment. Thus the final code causes a general protection fault on real hardware (or in QEMU with -enable-kvm) (reported by @nxnfufunezn in #179).
Possible solutions:

Insert a random push 0 in the handler, without a detailed explanation.
Add a Testing on real Hardware section at the end of Catching Exceptions, where we discover the bug. Debug the GP fault in the upcoming post.
Avoid the GP fault by catching Divide-By-Zero error (DE) instead of page faults. The DE doesn't push an error code, so the stack is correctly aligned.

I don't like option 1, since it's only a hacky workaround. Option 2 is fine and emphasizes the differences between QEMU and real hardware (QEMU doesn't check alignment on movaps instructions). However, newer QEMU version might do the alignment check and then our code doesn't work anymore.
So I think that option 3 is the best solution.

I added two macro for isr with and without err.
https://github.com/nxnfufunezn/RstyOS/blob/fix-idt/src/interrupts/idt.rs#L45-L70
Is it ok ?


index out of bounds

I am facing below error, Please check it
Finished dev [unoptimized + debuginfo] target(s) in 17.43s
Running `target/debug/examples/echo`
thread '<unnamed>' panicked at 'index out of bounds: the len is 148 but the index is 148', src/node_wire.rs:206:39

Fixed on master


feat(no-unused-prop-types): support nextProps

Sample
shouldComponentUpdate(nextProps: Object) {
  return !!nextProps.shouldUpdate;
}

I'm closing this out due to inactivity. @yutin1987 please feel free to re-open.


How I take the keywords value from schema where can not use $data?

v 6.52
I want to use the keywords value from schema, I find a way to use it in minimum and somewhere, but what should I do if I want to use them in some other way?, like this
{
  type: 'object',
  properties: {
    size: {
      type: 'integer',
      minimum: xbytes(MIN_VOLUME_INCREASE_SIZE + 'MB'),
      maximum: xbytes(MAX_VOLUME_SIZE + 'TB'), // size <= maxSize
      exclusiveMinimum: { $data: '1/staticSize' }, // size > staticSize
      errorMessage: {
        maximum: t('storage can not bigger than %s TB!', {args: MAX_VOLUME_SIZE}),
        minimum: t('should smaller than %s MB', {args: MIN_VOLUME_INCREASE_SIZE}),
      }
    },
  },
  errorMessage: {
    properties: {
      size: t('please assign storage between %s and  %s', {args: [params_from_schema1, params_from_schema2]}),
    }
  }
}

see the params_from_schema1 and params_from_schema2 in the fourth row from the bottom.
and my validate function:
function validate(schema, values) { // values is the value ready to validate
  const ajvValidate = ajv.compile(schemas[schema]);
  const valid = ajvValidate(values);
  console.log(ajvValidate.errors)
  if (!valid) {
    throw new SubmissionError({
      _error: ajvValidate.errors[0],
    });
  }
}

$data uses some part of data instance (only available at run time) as the value of keyword schema. Schema is under control of you application, you can access any values in it in variety of ways.


Is there a good reason why we're not using jQuery CDNs?

The problem
The files are in assets directory in this repo.
Suggestions
Eliminate them and just point the HTML snippets to one of the official CDNs.

I am against the use of CDNs when we can easily serve the files ourselves. Some people agree https://github.com/perl6/doc/issues/652#issuecomment-230087753.

Can you please clarify why?
Using CDNs allows us to use the latest version so that we don't have to
worry about updating these files from time to time. But if we decide to
have them in our very repo, the right way to do it would be to create a
webpack deployment file that downloads and generates whatever version we
have. Having them in the repository is the least optimal option.

Yeah, and it also will make users execute unknown third-party javascript from a third-party source. You can fix that using SRI, but that negates the benefit of having ever-changing versions.

El jue., 18 jul. 2019 a las 19:40, Aleks-Daniel Jakimenko-Aleksejev (<
<EMAIL_ADDRESS>escribió:

Yeah, and it also will make users execute unknown third-party javascript
from a third-party source. You can fix that using SRI
https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/,
but that negates the benefit of having ever-changing versions.

We'll, it still is third-party javascript, only we're also hosting it in
our own repo. I don't think anything is going to be safer than the official
CDNs.
I'll check and see what are the best practices in this area and try and
stick to them.

There was one unnecessary “third-party” in my comment :)
See also: https://meta.stackoverflow.com/questions/258288/use-of-ajax-googleapis-com-not-china-friendly

But check out #3 in the answer. We can use MAXCDN, for instance.

The advice here is to use jQuery's own CDN with a statically hosted
fallback version
https://www.dotnetcurry.com/jquery/1020/jquery-cdn-fallback-best-practices

You sure about 3? :)

Can we discuss this in problem-solving, btw? I see that what we do is inconsistent. rakudo.org selfhosts everything, moravm.org uses https://code.jquery.com/jquery.js, perl6.org uses https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js.
I think deciding what to do once and then using that for every web resource is a good idea.

Yep, what it says is that you're not going to get the same performance out
of your local, non-replicated server than from a CDN.
I don't see why this should be consistent across all repos. It's not as if
we're deciding on a new mascot... But whatever. The more opinions are
heard, the better.

I don't see why this should be consistent across all repos

For example, if googleapis is fragile for countries with restricted access to the internet, then we want to have fallbacks everywhere we use it.

what it says is that you're not going to get the same performance

It depends. https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/

Also, it doesn't look like our performance is bound by jquery, and instead search.js is an issue:

search.js is definitely an issue - was hoping most of it would eventually go away by making the site dynamic instead of static.

We could create a deploy script that downloaded jquery and minified
search.js...

followup on https://github.com/Raku/doc-website/discussions/115


enhancement support high performance mode for log4j to escape potential bottleneck for doris read and write

Proposed changes
Issue Number: close #xxx
As we know, log4j2 some times may be bottleneck in doris fe when there are many logs to be output in sync mode while asynchronous logging has a better performance， and we find that capturing caller location has a similar impact across all logging libraries, and slows down asynchronous logging by about 30-100x. so, here we provide three log mode for log4j2 to meet the needs of different users.
refer to https://logging.apache.org/log4j/2.x/performance.html
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


[INFINITY-2895] Switch to using .aws/credentials instead of environment variables

Due to the switch to maws (https://github.com/mesosphere/maws) for controlling access to AWS, the test.sh script needs some reworking.
This PR removes support for using envvars for AWS and requires that the ~/.aws/credentials file exists.
@gabrielhartmann @benclarkwood this does not affect any of the tests themselves, but only running locally.

Can you document an example please?


Caching fails when writing NANs to cache file

Describe the bug

When using cache=True in read function and there are NANs in non-numeric columns, writing to the cache file fails: TypeError: Can't implicitly convert non-string objects to strings. This happens not because of the encoder does not encodes it in X (it does). But we need to store the original values somewhere (uns in our case), and those nan values will be stored there too.
To Reproduce
Steps to reproduce the behavior:

Get a .csv file with some numerical and non-numerical columns (and non numerical columns misses at least one value)
Run read('my_file_path', cache=True)
See error

Expected behavior

Cache should work.
Possible solution
I'm not quite sure, what's the way to go here.
One solution would be replace like all nan in the original values with like "" or something (just an empty string) and cast it back while reading from the cache file.
Any ideas here @Zethson ?

One solution would be replace like all nan in the original values with like "" or something (just an empty string) and cast it back while reading from the cache file.
Since we are handling such edge cases anyways I think this should be fine?

One solution would be replace like all nan in the original values with like "" or something (just an empty string) and cast it back while reading from the cache file.
Since we are handling such edge cases anyways I think this should be fine?

Yeah, I mean would be just a "hidden" step of Data imputation. I mean when writing, the user won't notify this at all.
But what what about when reading. Do we need to "cast" it back, or just "leave it as it is", sine this step would be required anyways later on?

One solution would be replace like all nan in the original values with like "" or something (just an empty string) and cast it back while reading from the cache file.
Since we are handling such edge cases anyways I think this should be fine?

Yeah, I mean would be just a "hidden" step of Data imputation. I mean when writing, the user won't notify this at all. But what what about when reading. Do we need to "cast" it back, or just "leave it as it is", sine this step would be required anyways later on?

Think we have to go with casting back to NaNs. They user may decide to impute the strings and not leave them as empty strings. Agree?

What about just treating empty strings as nans? Regarding imputation etc.?


How to use pdf.js with requirejs

I believe it's a good topic to be in the Wiki.
To implement it with RequireJS you must use the names to instantiate like this image below.

Reference: https://github.com/mozilla/pdf.js/issues/7287#issuecomment-348143963

You shouldn't be using the version from mozilla.github.io since it's always the latest master version, which may contains bugs from time to time. You should always use an official release from https://github.com/mozilla/pdf.js/releases instead, or use https://github.com/mozilla/pdfjs-dist (the NPM package).
Moreover, it's probably better to provide a good and self-contained example for RequireJS in https://github.com/mozilla/pdf.js/tree/master/examples since that is more likely to be found/used than the wiki for usage with external libraries; pull requests for this are welcome. (Also, we don't really provide support for using the PDF.js library with third-party libraries other than giving example usages.)

It is not working for me. Do you know if it still works?


fixed running within an iframe under Chrome

If protocolcheck.js is loaded within an iframe, the blur event gets attached to the iframe's window, not the browser window.

Looks good, thanks!


feat: add mode to convert functions

doesn't handle multi line commands, kills all whitespace
idk if we care about either
execute as MiniDigger at @s \
    run say hi

There should also be an additional warning that macros can't be handled and that multi-line commands will be absorbed into a single line


Installation Steps

Hello...
how to install this plug-in?
Just imported it and used it in Apex page (region),but it is asking for a table?!

Hi!
You can download and check out the template component on my sample application and how it is working.

Br,
Richard


Split gk_field into separate objects

As I start to add yet another option in apps/gk_field, I am daunted by all the branching. We should split this up into separate objects as it's been suggested before.

Yes, I very strongly support this. Please do not use if-statements to implement totally different functionality. Spend time in properly create independent objects, selecting them at initialization time. We need to get into the habit of properly designing code. In general if you have a if-statement that is called every step or in a loop to select between two completely different field solvers, for example, that part of the code needs to be likely refactored. I am glad this is being done.


Only show slowest 5% toggle if we have P95 data

Currently, if we don't have that data, we still show the toggle so it appears to have no effect

It happens when P50 and P95 have the same data.
Examples:
Request Breakdown

Duration Breakdown:

@doppleware, how will the user understand that he sees only one percentile because there are similar?

Hi Asaf,
The situation I'm seeing is that there is very little data.
For example only one request.
In that scenario there is no real Median/P95 and I don't want to see the toggle at all
I think the server will still return a P95 / Median data as identical but we need to set a threshold data level


Update plugin for Shrine 3.2

Shrine 3.2 changed Attacher.cached's arguments to accept options. The
shrine-tus plugin needs to be updated accordingly for compatibility with
v3.2.

Relevant commit in Shrine is at https://github.com/shrinerb/shrine/commit/0a75b46693999af986de1c07916c29ba301c5695#diff-70cb8d884897064dc50c12f9b27dddbcL339

Was there an automated test that failed when this broke?
Could/should there be?
And could/should this repo be set up for automatic tests with travis?
It would have been nice to have this breakage caught by automatic tests.
Not necessarily saying that's a pre-req to merge this PR, if there was no such breaking tests already.

Yes, we had a failing test in our application. Let me see if I can distill it down into a failing test in shrine-tus test suite.

The error is reproducible in the shrine-tus test suite when shrine_class.plugin :validation is enabled. If that plugin is enabled, it passes a validate: false option that eventually makes its way to Shrine::Plugins::Tus::AttacherMethods.cached, and an exception will be triggered. It looks to me like any plugin that passes an option to attach_cached will be incompatible with shrine-tus.
I've added a simple assertion to illustrate this by just passing options to assign, which I believe is now part of the the Shrine  Attacher API. I haven't used minitest much, so open to suggestions if there's a better way to illustrate the requirement.

Looks good, thank you for the patch! 🙏

Thanks for merging this, and for your hard work on Shrine! It's a great project!


[card.io] updated to latest versions of native SDK's for iOS and Android

@Redth  component.yaml for iOS need a version update.


jshint should warn when using undeclared/undefined default values (in function parameters)

Currently jshint does not seem to warn for these pieces of code:
// "global" is not defined
function test1(param = global) {
}

// "param" is declared, but always has the value undefined so it's likely not what the author intended.
function test2(param = +param) {
}

This is a good one.

related: #2422

this is fixed in 2.8.0 if you have undef: true on..
/* jshint undef: true */
function test1(param = global) {
}


Took long time for Docker Swarm service turn desired state from Ready to Running

Description
After I run "docker service update" it took around 60 seconds for each task from "Ready" to "Running" in desired states. It was around 25-35 seconds with the same application version and on the same docker swarm cluster. What could cause this issue? (I believe it is rather the servers than the docker itself) but how can I trouble shooting this? And I could not see any documentation described what "Ready" means for desired states
Describe the results you received:

docker service ps service
ID                         NAME             IMAGE                                                       NODE                      DESIRED STATE  CURRENT STATE          ERROR
663dyntbzxdwixoauzqwpxmr7  service.1  myNexus:18444/app/service:0.0.150  server1  Ready          Ready 59 seconds ago
alv8egzz7l3otbrukyp0w12up  service.2  myNexus:18444/app/service:0.0.140  server2  Running        Running 3 minutes ago

docker service ps service
ID                         NAME             IMAGE                                                       NODE                      DESIRED STATE  CURRENT STATE          ERROR
663dyntbzxdwixoauzqwpxmr7  service.1  myNexus:18444/app/service:0.0.150  server1  Running        Running 1 seconds ago
alv8egzz7l3otbrukyp0w12up  service.2  myNexus:18444/app/service:0.0.140  server2  Running        Running 3 minutes ago

Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
We used the same docker swarm master and 2 docker swarm workers. There are not much load on all these three servers and all with the same docker version and all servers are in the same sub network.
Output of docker version:
Docker version 1.12.3, build 6b644ec
Output of docker info:
Containers: 2
Running: 1
Paused: 0
Stopped: 1
Images: 29
Server Version: 1.12.3
Storage Driver: overlay
Backing Filesystem: xfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: overlay host null bridge
Swarm: active
NodeID: 72gvia35ix61itfohl7k3u6rg
Is Manager: true
ClusterID: 7cwfx7po774vp8pfj40algdlb
Managers: 1
Nodes: 3
Orchestration:
Task History Retention Limit: 1
Raft:
Snapshot Interval: 10000
Heartbeat Tick: 1
Election Tick: 3
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Node Address: <IP_ADDRESS>
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.28.3.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.703 GiB
Name: master1
ID: NTMK:JGIK:ZDHP:37KK:LYTO:BJJV:6LIA:LVAC:S4GX:SGWX:LWTS:Z2MP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 44
Goroutines: 141
System Time: 2016-11-11T09:33:07.023284896+01:00
EventsListeners: 0
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
<IP_ADDRESS>/8

Is there any setting for swarm to define how long time it should use for update a task?
looks all the tasks (even a different service) take the same amount of 60 seconds now.

after set back "docker swarm update --task-history-limit 5", problem solved!
so there is something wrong with the --task-history-limit which pauses the task for 1 minute and then start  pulling image + run container..........

It sounds like it's taking a long time for the old task to shut down. By default, a task is given up to a minute to shut down before proceeding with the update. You might want to try setting the --stop-grace-period option to something shorter.
I'm not sure why passing the --task-history-limit option would make a difference. This may be a coincidence - or something very strange is going on.

Thanks!
would have a try with --stop-grace-period and set --task-history-limit=1 again to see if still an issue there.

Hi again,
It did not work with --stop-grace-peroid...... no matter which value I set for --stop-grace-period, once --task-history-limit either =1 or =0, it still takes exactly 1 minute for each task in the service to change from "Ready" to "Running". and once set --task-history-limit back to 5, it just runs within 2 seconds to have the task done.

Something to do with healtcheck settings? Do you have a healthcheck defined?
How is it configured?

@cpuguy83 no healthcheck defined in the Docker file

Same issue here.

We need more info if you're running into this, otherwise it will be just "wild guessing";

daemon log-files (with debug enabled), and possibly log files of the container may show what's happening at each point, and where the delay is.
exact steps to reproduce (which image is used, how is the service configured, etc.)

Keep in mind that docker service update stops the running containers (tasks) and starts new ones to replace them, which could take time, depending on what's running in the container (e.g. writing data to disk if it's a statefull service, initializing on startup). Docker 1.12 also performs a docker pull on each update to check if a more recent version of the image is available. If the task ends on a different node, that image may not be in the local image cache yet

same issue here (on Docker 1.13.1)
This problem exhibits for --task-history-limit zero or one. Any service, any image.. Unrelated to docker pull or time to shutdown container.

exact steps to reproduce (which image is used, how is the service configured, etc.)

Steps to reproduce
Set swarm task history to 1
$ docker service ls
ID  NAME  MODE  REPLICAS  IMAGE
$ docker swarm update --task-history-limit 1
Swarm updated.

Create dummy service
$ docker service create --name top busybox top
4owezg5kku7bh18vnlcjzoo91
$ docker service scale top=3
top scaled to 3
$ docker service ps top
ID            NAME   IMAGE           NODE  DESIRED STATE  CURRENT STATE           ERROR  PORTS
pavf5i2gpnc0  top.1  busybox:latest  vm5   Running        Running 14 seconds ago
a4mbs9s237kg  top.2  busybox:latest  vm6   Running        Running 6 seconds ago
wg8yji6zp5dt  top.3  busybox:latest  vm6   Running        Running 6 seconds ago

Trigger service update
$ docker service update top --force
top

Expected result
Update to be completed within seconds. Just as it is the case for task-history >1.
Actual result
It takes three minutes to complete the update. One minute for each task, during which, the task is in "Ready" state
$ docker service ps top
ID            NAME   IMAGE           NODE  DESIRED STATE  CURRENT STATE           ERROR  PORTS
pavf5i2gpnc0  top.1  busybox:latest  vm5   Running        Running 44 seconds ago
nxvl7t35mj8a  top.2  busybox:latest  vm6   Ready          Ready 19 seconds ago
wg8yji6zp5dt  top.3  busybox:latest  vm6   Running        Running 37 seconds ago

Strange, I can't reproduce this.
$ docker version
Client:
 Version:      1.13.0-rc7
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   48a9e53
 Built:        Fri Jan 13 21:41:57 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      1.13.0-rc7
 API version:  1.25 (minimum version 1.12)
 Go version:   go1.7.3
 Git commit:   48a9e53
 Built:        Fri Jan 13 21:41:57 2017
 OS/Arch:      linux/amd64
 Experimental: true
$ docker swarm update --task-history-limit 1
Swarm updated.
$ docker service create --name top busybox top
x6akq7s1w54r58mp36q8p543s
$ docker service scale top=3
top scaled to 3
$ docker service ps top
ID            NAME   IMAGE           NODE  DESIRED STATE  CURRENT STATE           ERROR  PORTS
68qqap8156zf  top.1  busybox:latest  moby  Running        Running 11 seconds ago
weehc721jaqk  top.2  busybox:latest  moby  Running        Running 1 second ago
ncp2g2ktqb7c  top.3  busybox:latest  moby  Running        Running 1 second ago

@aaronlehmann I don't see the service update in your output.

My mistake. I can see the problem now and I'll work on a fix.

I've opened https://github.com/docker/swarmkit/pull/1948 to fix this. Thanks for the simple repro steps.


Stopped working

Something happened in the last couple of days.  Using docker version.  Server is not listening on the port anymore.
STDERR
Exception in thread "main" java.lang.IllegalArgumentException: Data key must not be empty
at org.jsoup.helper.Validate.notEmpty(Validate.java:102)
at org.jsoup.helper.HttpConnection$KeyVal.key(HttpConnection.java:874)
at org.jsoup.helper.HttpConnection$KeyVal.create(HttpConnection.java:864)
at org.jsoup.helper.HttpConnection.data(HttpConnection.java:143)
at net.ruippeixotog.scalascraper.browser.Browser.post(Browser.scala:20)
at net.ruippeixotog.ebaysniper.ebay.EbayLoginManager.forceLogin(EbayLoginManager.scala:30)
at net.ruippeixotog.ebaysniper.ebay.EbayClient.login(EbayClient.scala:26)
at net.ruippeixotog.ebaysniper.SnipeServer$.delayedEndpoint$net$ruippeixotog$ebaysniper$SnipeServer$1(SnipeServer.scala:34)
at net.ruippeixotog.ebaysniper.SnipeServer$delayedInit$body.apply(SnipeServer.scala:17)
at scala.Function0$class.apply$mcV$sp(Function0.scala:40)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.collection.immutable.List.foreach(List.scala:381)
at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
at scala.App$class.main(App.scala:76)
at net.ruippeixotog.ebaysniper.SnipeServer$.main(SnipeServer.scala:17)
at net.ruippeixotog.ebaysniper.SnipeServer.main(SnipeServer.scala)
APP.LOG
2016-06-25 18:22:56,684	INFO	Slf4jLogger	Slf4jLogger started
2016-06-25 18:22:56,703	INFO	SnipeServer$	Logging in into eBay
2016-06-25 18:22:56,703	DEBUG	EbayLoginManager	Getting the sign in cookie for ebay.com
2016-06-25 19:03:51,364	INFO	Slf4jLogger	Slf4jLogger started
2016-06-25 19:03:51,380	INFO	SnipeServer$	Logging in into eBay
2016-06-25 19:03:51,381	DEBUG	EbayLoginManager	Getting the sign in cookie for ebay.com

Hi @bthome! It seems that the server had an issue fetching the sign-in HTML form and did an invalid POST request because of that.
Unfortunately, the Docker version is a bit old and doesn't reflect the latest code base. I bumped the main dependency of this project, scala-scraper, to the first stable release and had some shortcomings arising from interfaces that changed. I intend to work a bit on these projects this weekend and update the ebay-snipe-server Docker image.

Hi! I have just updated the Docker image with the latest code on master. Can you please pull the new version and see if this problem occurs again?

Pulled the source..recompiled...installed and now working.  Thank you for the update.


ios notification_opened dosen´t work when app is in background

Hello together,
i found a bug in firebase messaging.
The notification_opened property dosen´t work on ios when the app is in the background.
It work fine when the app is closed and was started from a tap to the notification.
On Android it work fine when app is closed and in the background.
I check it like this:
if (message.notification_opened) {         const QString key = QStringLiteral("launchnotification");         data.insert(key, true);     }
Regards Isy

Thanks for the report. I'll investigate the issue.

Was the error reproducible?

Sorry for the lack of feedback. This issue should be fixed in the 4.1.0 release. If you're still seeing the issue let me know.

@isipisi281  I think problem do not resolved

This is my current output:
2017-12-06 11:23:53.892957+0100 App[868:594072] FCM: Initialize Firebase Messaging
2017-12-06 11:23:53.893041+0100 App[868:594072] FCM: Using FCM senderID 56*********
2017-12-06 11:23:53.893442+0100 App[868:594072] FCM: Retrieve registration token
fg********:********************************************************

I then push the home button - and get:
2017-12-06 11:24:03.612624+0100 App[868:594072] FCM: Disconnect FCM service

Send out a message via the firebase console
Then I enter the app again:
2017-12-06 11:25:15.182992+0100 App[868:594072] FCM: Connected to FCM
2017-12-06 11:25:16.472608+0100 App[868:594072] FCM: Received message

So the message comes in when the app is opened back up - but I haven't seen any notifications yet :/

@Larpon  Yes there is no notification popup at all only console log show message received
My full log
2017-12-06 14:11:44.815526+0330 Project[3185:968912] [DYMTLInitPlatform] platform initialization successful
2017-12-06 14:11:44.927146+0330 Project[3185:968763] FCM: Loading UIApplication FIRFCM category
2017-12-06 14:11:45.745470+0330 Project[3185:968763] Setting up iOS 10 message delegate.
JIT is disabled for QML. Property bindings and animations will be very slow. Visit https://wiki.qt.io/V4 to learn about possible solutions for your platform.
stale focus object QObject(0x0) , doing manual update
libpng warning: iCCP: known incorrect sRGB profile
QtFirebaseMessaging(0x12b40a180) ::QtFirebaseMessaging singleton
QObject(0x0) :QtFirebase(QObject* parent)
2017-12-06 14:11:48.133277+0330 Project[3185:968895] [Firebase/Analytics][I-ACS023007] Firebase Analytics v.40005000 started
QtFirebase::requestInit created the Firebase App (27ec38b0)
QtFirebase(0x12b409f50) ::requestInit initialized
2017-12-06 14:11:48.225572+0330 Project[3185:968927] [Firebase/Analytics][I-ACS023008] To enable debug logging set the following application argument: -FIRAnalyticsDebugEnabled (see http://goo.gl/RfcP7r)
2017-12-06 14:11:48.295736+0330 Project[3185:968763] FCM: Initialize Firebase Messaging
2017-12-06 14:11:48.295828+0330 Project[3185:968763] FCM: Using FCM senderID<PHONE_NUMBER>64
2017-12-06 14:11:48.296488+0330 Project[3185:968763] FCM: Retrieve registration token
" Token recived: eCBFY_IAapw:APA91bGocEz6TDkR6pl1zz9JI8mC1JKbOY9QwXiW6JhPrkJaeELTq-VJRDhAnnORJkTlLp4fXrxElet71kj3hjBFdkGPFMnuga3BCiH8wWBnzEe3tKTMt8VNJq1rf9m6QqvoPTiWk1BS"
2017-12-06 14:11:48.377603+0330 Project[3185:968763] FCM: Connected to FCM
2017-12-06 14:11:49.151582+0330 Project[3185:968895] TIC Read Status [1:0x0]: 1:57
2017-12-06 14:11:49.152354+0330 Project[3185:968895] TIC Read Status [1:0x0]: 1:57
2017-12-06 14:11:56.226105+0330 Project[3185:968763] FCM: Received message
2017-12-06 14:11:58.065572+0330 Project[3185:968763] FCM: Received message
2017-12-06 14:12:03.458103+0330 Project[3185:968763] FCM: Disconnect FCM service
2017-12-06 14:12:03.893158+0330 Project[3185:969067] TIC Read Status [3:0x0]: 1:57
2017-12-06 14:12:03.894013+0330 Project[3185:969067] TIC Read Status [3:0x0]: 1:57
2017-12-06 14:12:11.520373+0330 Project[3185:968763] FCM: Connected to FCM
2017-12-06 14:12:12.220608+0330 Project[3185:968763] FCM: Received message

Finally I resolved the problem
Please edit files in example
1- add

2-

3- Add UserNotifications framework !important
**4- Remove this section from plist file **
 <key>FirebaseAppDelegateProxyEnabled</key> <false/>
Worked like charm ;-)

@stewartmiles - looks like a false alarm then - sorry :)
@cinohee - Awesome. Can you add exactly that post you just made to the QtFirebase issue as well (for reference - until I get to update the example)?

@Larpon  I added the post :)


Investigate CI incorrectly passing code with compilation errors

Description
For context, see the PR comment here.  In summary, CI has been passing, a change is pushed up, and it starts failing on some unrelated code.  The failing code was pushed in a previous PR, and there is a sequence of passing CI checks before it finally fails here due to the MethodInputParametersMustBeFinal errorprone check.
I tried running the failing gradle task locally at the git commit where it finally failed in CI.  When running locally, the task passed without failure.  It looks like the -WError flag should always be applied (see build.gradle) so not sure why this is passing locally.
We should investigate this CI flakiness and make sure that we're actually enforcing all of the rules in CI consistently.

@macfarla for visibility

@non-fungible-nelson I've picked up this issue. This resulted in taking out Besu's custom errorprone into its own repo. Also, the class involved, looks like our errorprone check is not always able to pick it, so I've make a small refactoring in it. Will create a PR to cover this and other bits that are uncovered due to upgrading the errorprone. See https://github.com/hyperledger/besu/pull/6692 as well.


Add jobs for new kie-soup repo

We will need deploy and PR jobs for this new repo: https://github.com/kiegroup/kie-soup. It is supposed to be built before uberfire.

@psiroky
questions..:

master and 7.3.x?
errai, uberfire and dashbuilder (build and deployed before kie are also released. Has kie-soup a release cycle?
2a. Does it only apply to kieAlBuild daily jobs or also to the kieRelease jobs?
2b. Is this also as branch needed for gerrit?
2c. I assume this kie-soup rep is needed for community and for prod?

Only master
Even though kie-soup has the same version as other KIE projects, it needs to be built before uberfire.
2a. yes, applies to basically all jobs
2b. not sure I understand the question. There is no new branch needed. The repo will need to be part of the prod builds, but only when we actually start building the prod from master (which probably won't be for some time).
2c. yes

Argh, I'll leave this open for now, as we need to process https://github.com/kiegroup/kie-jenkins-scripts/pull/77

This seems to have been done some time, but we likely just forgot to close it. Closing now.


Use GitHub actions

This PR follows https://github.com/redis-store/redis-actionpack/pull/39 and configure GitHub Actions.
This PR is different from https://github.com/redis-store/redis-actionpack/pull/39:

Trigger all branches not only master
Support rack-test > 2.0
Revert CI target rails versions

Some fixes are required for rails 7.0 testing.

ugh


Add Python 3 Support to /contrib/linearize/

/contrib/linearize/linearize-hashes.py changed to python 3 format
/contrib/linearize/linearize-data.py changed to python 3 format
the files were pulled from the bitcoin repo, and confirmed working.

These changes, if accepted, would make making bootstraps possible on python 3.


armv7 automatic parallelization

Do you have any plan for automatic parallelization with @jit to support 32-bit architecture like arm v7?

Thanks for the question. I think it's the 32bit here that is the issue, opposed to ARM. The core dev team will discuss how hard removing the 64bit constraint will be at the next meeting.

I labeled this as a feature request.

Fast forward a year, and now we're seeing Raspberry Pi with a beta OS for 64-bit on the Raspberry Pi 3 and 4 released earlier this year.  Ubuntu 20.04 64-bit is also available (which I've used), and there is probably a Fedora/CentOS option as well now.  Note that this does leave behind the Pi Zero and Pi 1, which are ARMv6 hardware and the Pi 2, which started out with ARMv7 hardware.  Everything since that in the Raspberry Pi lineup has been 64-bit capable.  The Pi Zero and 1 are single core anyway, so the biggest guaranteed loss I see with not supporting 32-bit parallel compute is the quad-core Pi 2.
Obviously, there are lots of 64-bit capable multi-core Raspberry Pi's that aren't going to be upgraded to a 64-bit OS for a while, so I appreciate the need.  However, I suspect that by the time we have bandwidth to address this request, the ARM ecosystem will be mostly focused on 64-bit and the demand for this will continue to drop over time.  These sort of word-size issues are often tricky to fix across all architectures, with Windows being a huge source of unintentional problems.  Anyone who wants to tackle this should be prepared to spend a lot of time watching CI fail...

I'm going to close this as I think 64bit ARM will proliferate faster than Numba could implement support for the parallel target on 32bit systems. If anyone feels strongly otherwise please feel free to leave comments and this ticket can be reopened.


chore(main): release 0.0.2

:robot: I have created a release beep boop
0.0.2 (2024-10-17)
Features

loop game until ended (96db54c)
print winning state (5d0f73f)
progress the game (0717e33)
show game status (eee119a)
winning game (7013d19)

Miscellaneous Chores

add release action (1343fbc)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.0.2
:sunflower:


Xiaomi Flower Care - no data

Hi,
thank you for your module.
The Temp./Hum Sensor is working fine, but flower care give me only "no data".
Have of course double checked the address - it is ok.
Any idea - or can I send to you any additional information?
Thanks!
Michael

Hi.
Worked once, now I have the same problem.
I use this commands to get bluetooth working:
sudo hciconfig hci0 up
sudo setcap cap_net_raw,cap_net_admin+eip $(eval readlink -f which node)
Thanks in advance for your help.
Kind regards,
Torsten

Same here, randomly some flower cares start showing "no data" and even changing the battery, accesing by phone app etc doesn't make any change. Sometimes they come back for some time...


GiST support to qmol type

Adds support for substructure index on a qmol type columns, reported in #4463
Following is now possible for qmol:
CREATE INDEX qmols_ss_index ON func_groups USING gist (qmols);

Which you can query with smiles and it will be properly accelerated by index
SELECT * FROM func_groups WHERE qmols <@ 'CC(=O)Oc1ccccc1C(O)=O'::mol;

@greglandrum let me know if/where I should add some tests, as the PSQL Cartridge testing seems to be mostly manual.

@mwojcikowski : this looks good, but I'd like to try it myself when I'm back in the office (next week) before merging.

@mwojcikowski  I just did a PR against your branch to add some testing for this and resolve the merge conflicts.
Once you merge that and the CI builds pass here, I'm happy to merge this PR.

Thanks @mwojcikowski!


KAFKA-5980: FailOnInvalidTimestamp does not log error

Call for review @guozhangwang @dguy @bbejeck
Should be back port this to 0.11.0 and 0.10.2 ? (Not sure if there will be another bug fix release for those...)

Updates this. Thanks for the review @tedyu @dbolshak

Merged to trunk.


Shop is sending 8x notifications to customers and operator

PHP Version: 8.2.20   | Shopware Version: <IP_ADDRESS>  | Affected area / extension: Platform(Default)

Expected behaviour:
Only one e-mail should be sent to the customer and store operator.
Actual behaviour:
8 e-mails are sent to the customer and store operator for any notifications.
How to reproduce:
Unfortunately I don't know, I can only demonstrate it to you in our live system, but due to the problem we would put the store on maintenance and try to find the cause together with you.
According to Frosch MailArchive, the status is not set to sent.

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-38508
[created from NEXT-38508, comment 498678]

[public] We have not been able to reproduce this behaviour in the latest version of Shopware with the information available. Please create a new ticket with more information if you think this is a general behaviour. Otherwise, please contact our support team or visit the forum.
[created from NEXT-38508, comment 498751]

This why I write:

Unfortunately I don't know, I can only demonstrate it to you in our live system, but due to the problem we would put the store on maintenance and try to find the cause together with you.
According to Frosch MailArchive, the status is not set to sent.

[public] We have not been able to reproduce this behaviour in the latest version of Shopware with the information available. Please create a new ticket with more information if you think this is a general behaviour. Otherwise, please contact our support team or visit the forum.
[created from NEXT-38508, comment 498751]

This why I wrote:

try to find the cause together with you.
According to Frosch MailArchive, the status is not set to sent.


Get Ground truth from MITRE

Goals
We aim to develop two key metrics for the integration dashboard to evaluate Ask-xDD performance:

Retrieval Top-k Hit Rate: Requires the DOI or Cosmos ID for documents referenced in each question of the hackathon scenario.
BERT Score F1: Necessitates an overview of the decision-making process for each question.

Issues for discussion:

For most hackathon scenarios that begin with one or two pre-chosen papers, is it necessary to conduct evaluations on searches with no specific constraints?
Is there a paragraph or a summary of the information utilized for each question?
If not, should we just hand label a few?
What is the current dashboard looks like?

If this is blocked, we can consider using TruLens. It use LLM for eval.


Can anyone help to use vscode to build example

Please provide us with the following information:

This issue is for a: (mark with an x)
- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Any log messages given by the failure

[1084/1109] Building C object esp-idf/azure-iot-middleware-freertos/CMakeFiles/__idf_azure-iot-middleware-freertos.dir/b587fa35c5ad01fd19af7f6f470063a1/azure_iot.c.obj
FAILED: esp-idf/azure-iot-middleware-freertos/CMakeFiles/__idf_azure-iot-middleware-freertos.dir/b587fa35c5ad01fd19af7f6f470063a1/azure_iot.c.obj
Expected/desired behavior

I am using vscode to build the example, I got the error message :
[1084/1109] Building C object esp-idf/azure-iot-middleware-freertos/CMakeFiles/__idf_azure-iot-middleware-freertos.dir/b587fa35c5ad01fd19af7f6f470063a1/azure_iot.c.obj
FAILED: esp-idf/azure-iot-middleware-freertos/CMakeFiles/__idf_azure-iot-middleware-freertos.dir/b587fa35c5ad01fd19af7f6f470063a1/azure_iot.c.obj
OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

Versions

windows 11
IDF 4.4.3
Mention any other details that might be useful
I can successfully build the example by using ESP-IDF powershell.

Thanks! We'll be in touch soon.

Hello @JamesJian-tech! Currently we only support using the ESP-IDF to build the samples. Are you using the command line when you try and build the sample in vscode, or are you using an extension?

Yes, I have fixed now all good, thanks


attachTo in Programmers guide should be attachToAndFit

attachTo in Programmers guide should be attachToAndFit

Not needed after #108


Add Reset Default Functionality

I haven't added code for the Reset Defaults functionality on the timer config page

This was resolved in commit fd840c9


Router link error when pushing

Version
3.4.8
Steps to reproduce
When navigating back and forth through the router view, I get this error when using this.$router.push:
<router-link v-if="hasRoute" @click.native="navigate" :to="_route" exact tag="li">

  methods: {
    navigate (route) {
      this.$router.push(route).catch(failure => console.log(failure));
    }
  },

vue.runtime.esm.js?2b0e:1888 TypeError: relative.charAt is not a function
    at resolvePath (vue-router.esm.js?8c4f:460)
    at normalizeLocation (vue-router.esm.js?8c4f:1031)
    at Object.match (vue-router.esm.js?8c4f:1523)
    at VueRouter.match (vue-router.esm.js?8c4f:2867)
    at HTML5History.transitionTo (vue-router.esm.js?8c4f:2194)
    at HTML5History.push (vue-router.esm.js?8c4f:2544)
    at VueRouter.push (vue-router.esm.js?8c4f:2966)
    at VueComponent.nav (TextItem.vue?44a0:26)
    at click (eval at ./node_modules/cache-loader/dist/cjs.js?{"cacheDirectory":"node_modules/.cache/vue-loader","cacheIdentifier":"9a00ad72-vue-loader-template"}!./node_modules/vue-loader/lib/loaders/templateLoader.js?!./node_modules/cache-loader/dist/cjs.js?!./node_modules/vue-loader/lib/index.js?!./src/components/pages/breadcrumbs/TextItem.vue?vue&type=template&id=553682da& (app.4f4bad17703210e3baf8.hot-update.js:11), <anonymous>:15:26)
    at invokeWithErrorHandling (vue.runtime.esm.js?2b0e:1854)

When debugged, relative has the value of:
relative: Array(12)
0: span
1: a
2: li.router-link-exact-active.router-link-active
3: ul.v-breadcrumbs.theme--dark
4: div.v-toolbar__content
5: header.v-sheet.theme--dark.v-toolbar.v-toolbar--dense.v-app-bar.v-app-bar--clipped.v-app-bar--fixed
6: div.v-application--wrap
7: div#app.v-application.v-application--is-ltr.theme--dark
8: body
9: html
10: document
11: Window {window: Window, self: Window, document: document, name: "", location: Location, …}
length: 12
__proto__: Array(0)

What is expected?
For the navigation to actually happen correctly
What is actually happening?
Navigates to a previous link and shows an error when pushing

That description "When navigating back and forth through the router view" won't allow for a reproduction, please provide one.

Open a new issue once you have a reproduction thank you


fix(elasticsearch-client): allow connection to external Elasticsearch instance via proxy

We're running Datahub behind a proxy and need it to talk to an external Elasticsearch instance. To allow this, we needed to add this change to the Elasticsearch client that tells it to take system properties like http.proxyHost, https.proxyHost or http.nonProxyHosts into account.
Note: I think this client is used in both datahub-gms and datahub-upgrade.
Checklist

[x] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[x] Links to related issues (if applicable)
[x] Tests for the changes have been added/updated (if applicable)
[x] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[x] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Please run ./gradlew spotlessApply and we can get this merged! Thanks!

Please run ./gradlew spotlessApply and we can get this merged! Thanks!

@david-leifker I tried to run ./gradlew spotlessApply but got the following error message:
To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/8.0.2/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build
Configuration on demand is an incubating feature.

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'datahub-github'.
> Could not resolve all files for configuration ':classpath'.
   > Could not resolve org.springframework.boot:spring-boot-gradle-plugin:3.2.1.
     Required by:
         project :
      > No matching variant of org.springframework.boot:spring-boot-gradle-plugin:3.2.1 was found. The consumer was configured to find a library for use during runtime, compatible with Java 11, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.0.2' but:
          - Variant 'apiElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.2.1 declares a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component for use during compile-time, compatible with Java 17 and the consumer needed a component for use during runtime, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.0.2')
          - Variant 'javadocElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.2.1 declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 11)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.0.2')
          - Variant 'mavenOptionalApiElements' capability org.springframework.boot:spring-boot-gradle-plugin-maven-optional:3.2.1 declares a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component for use during compile-time, compatible with Java 17 and the consumer needed a component for use during runtime, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.0.2')
          - Variant 'mavenOptionalRuntimeElements' capability org.springframework.boot:spring-boot-gradle-plugin-maven-optional:3.2.1 declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.0.2')
          - Variant 'runtimeElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.2.1 declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.0.2')
          - Variant 'sourcesElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.2.1 declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 11)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.0.2')

Any idea what I need to do here?

Having these as actual datahub properties would work better for the project compared to loading from system props. There's a few components that talk to ES and having them as datahub properties would allow us to hook them up to the right containers/components. For example, setting global.elasticsearch.proxy in a Helm chart would allows us to propagate it to every container that needs it, instead of relying on users to figure that out and set the env vars for each individual component.
Ref Elasticsearch options: https://github.com/datahub-project/datahub/blob/3bfc1e4/metadata-service/configuration/src/main/resources/application.yml#L159
Also for completeness, the elasticsearch-setup job would need changes too https://github.com/datahub-project/datahub/tree/master/docker/elasticsearch-setup

Hi @darnaut, thanks for your feedback. Here are my thoughts about it:

It's not only about Elasticsearch. We need to define the proxy settings in the Java opts anyway (e.g. for the Kafka schema registry). This one-liner just makes sure that also the Elasticsearch client respects those values. So instead of defining the proxy for the different services (e.g. Elasticsearch, Kafka) specifically, we just need to define it in the Java opts and things work.

What we could do in the future, maybe, is having a central place in the Helm chart where people can configure the proxy settings for all the containers. But we would need to make sure that all images accept ENV vars that are used to correctly define the proxy settings for the Java process internally. However, we would still need the changes proposed in this PR and I think this would require quite some alignment and refactoring for different images to make things consistent. For example, in GMS, it seems that people can set JAVA_OPTS to define Java opts including the proxy settings. In the frontend, proxy settings can be defined specifically with variables like HTTP_NON_PROXY_HOSTS or HTTP_PROXY_HOST.

For now, I'd personally keep the changes as proposed. It's a one-liner that gives people the ability to connect to an external Elasticsearch via proxy. What do you think?
PS: The elasticsearch-setup job doesn't seem to be affected by this. We're able to run it successfully with the standard image provided by Acryl and didn't have to build a custom image for it. It's just a shell script that runs a bunch of curl commands against Elasticsearch, so it doesn't need any Java opts but probably looks at the standard ENV vars related to the proxy.

It's not only about Elasticsearch. We need to define the proxy settings in the Java opts anyway (e.g. for the Kafka schema registry). This one-liner just makes sure that also the Elasticsearch client respects those values. So instead of defining the proxy for the different services (e.g. Elasticsearch, Kafka) specifically, we just need to define it in the Java opts and things work.

But that's exactly the issue I'm concerned. It applies to everything that uses RestHighLevelClient, which today might only be (e.g. Elasticsearch, Kafka) but there's no guarantee it won't be used for other internal requests in the future. That's why I'm saying it's much better to make these choices (whether to use proxy) explicit. Right now this one line is gonna be basically invisible to most if not all developers working on Datahub and things might break in weird ways that will also cause issues for us if, for example, someone asks for support/help.
Just to reiterate, whether the proxy configuration in the Datahub configuration is global (applies to all external services) or service specific (e.g. kafka), that's fine either way. My suggestion is that having these as actual Datahub properties would work better for the project compared to loading from system props.

For now, I'd personally keep the changes as proposed. It's a one-liner that gives people the ability to connect to an external Elasticsearch via proxy. What do you think?

If users come to rely on it, changing it later would be breaking existing setups. Also same issue without this change, some user might have HTTP_PROXY set for other reasons and this will break it.
Also this is not much additional work, you just need to add the required Datahub properties.

But that's exactly the issue I'm concerned. It applies to everything that uses RestHighLevelClient, which today might only be (e.g. Elasticsearch, Kafka) but there's no guarantee it won't be used for other internal requests in the future. That's why I'm saying it's much better to make these choices (whether to use proxy) explicit. Right now this one line is gonna be basically invisible to most if not all developers working on Datahub and things might break in weird ways that will also cause issues for us if, for example, someone asks for support/help.
Just to reiterate, whether the proxy configuration in the Datahub configuration is global (applies to all external services) or service specific (e.g. kafka), that's fine either way. My suggestion is that having these as actual Datahub properties would work better for the project compared to loading from system props.
If users come to rely on it, changing it later would be breaking existing setups. Also same issue w/ this change, some user might have HTTP_PROXY set for other reasons and this will break it.
Also this is not much additional work, you just need to add the required Datahub properties.

@darnaut, the RestHighLevelClient comes from the Elasticsearch/Opensearch library and is exclusively used for Elasticsearch. See the import statement import org.opensearch.client.RestHighLevelClient.
Other clients, e.g. for Kafka already respect the proxy settings passed to the Java process (at least we didn't have any issues there). This one-liner only makes sure that also the Elasticsearch client respects them.
Usually, from my experience, when defining proxy settings developers do the following:

Specify standard ENV vars like HTTP_PROXY, HTTPS_PROXY, NO_PROXY for things like curl commands that operate on a operating system level and are not specific to Java.
For Java applications it is common to add Java specific system properties like http.proxyHost, http.proxyPort or http.nonProxyHosts. This is a known practice for developers to define proxy settings, and it's not "invisible". Also, this change should not cause Datahub to "break in weird ways" as it only affects people that specifically define their proxy in the Java system properties. The current issue in Datahub is, that these standard Java specific system properties are not respected by the Elasticsearch client (and only this client), which is why it's basically failing in "weird ways" right now.

It's perfectly fine (and mostly done) to define ENV vars like HTTP_PROXY and the Java specific system properties at the same time. This will not break anything.
So in my opinion, it doesn't really make sense to put this as Datahub properties. These Java system properties are set when starting the Java application, and we don't have any Datahub properties at this point.
We could define proxy related Datahub properties and then configure the proxy manually for all the different clients within the code, but that would be way more effort and requires deep knowledge of the whole Datahub codebase.
If this change is a deal-breaker for you guys, we can also close this PR, and we'll keep using custom images for now. Let me know what you think.


Configurable label annotation

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #3710
Type of changes
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

[ ] Test A

[ ] Test B

Logs

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Release note:

NONE

Re-running failed tests

/rerun-all - rerun all failed workflows.
/rerun-workflow <workflow name> - rerun a specific failed workflow. Only one workflow name can be specified. Multiple /rerun-workflow commands are allowed per comment.

Hi @andyi2it, looks like we did the same thing, I sent this PR last week https://github.com/kserve/kserve/pull/4030
we could merge both, on my version I decided to put it inside the inferenceServiceConfig because it is already injected on every place we need to use it.

@andyi2it sure, I'll handle it this week.


added missing link to identity readme

The Identity README was missing the link for the Azure subscription trial

API change check
API changes are not detected in this pull request.


Fix #22 : Add meta information about project

Closes #22.
For more information please see issue #22.
cc: @ashutosh1919 please review the PR.

@Sachin-chaurasiya , I am in dilemma too for this. But let us merge this as of now. Also, let me investigate on "Is there any additional benefit that Helmet would provide over this?" but by that time, we can go ahead with this.


Please consider attaching the Router to the NavigationInstruction passed into Activate()

See here for reference. Alternatively, pass the Router as a 4th parameter.
The use case is to navigate to another view in activate() if the result of an api call returns an error status code (e.g., 401/403/500).

After looking at the API that Router exposes, it looks like it would be cleaner/better API design to proxy only the navigate*() and generate methods. Having an actual instance of Router would not be appropriate in activate().

And diving a bit deeper, it looks like an instance of a NavigationContext would be perfect instead of the existing NavigationInstruction.

NavigationContext has internal data and functionality that I don't think should be exposed outside of the router.
If you return a Promise from activate that rejects with a navigation command, the current navigation will be cancelled and the command will be executed.
  activate(){
    return this.http.get(this.url).then(response => {
      this.data = response.content;
    }).catch(error => {
      return Promise.reject(new Redirect('/error'));
    });
  }

I do think we can make this a little easier to use -- maybe as part of #50. I also agree that passing a router to activate probably wouldn't be appropriate.
If you don't want to return the Promise from activate and the new navigation would take place after the last one has been committed, then I guess I think that you should have to inject the router. The navigation would be unrelated to the previous navigation and doesn't seem like it should be encouraged from the activate that ran as part of the previous navigation.

Also, if you don't want the actual router instance until you know you need it, you can use the Lazy resolver. http://aurelia.io/docs.html#dependency-injection


Fix PLP hydration error

Description

If you go to PLP and refresh the page, you'll see the following React hydration error

This is because the loading state on PLP causes the server side rendered content to be replaced by skeletons.
The following 3 things happens in serial when you land on PLP

initial paint from SSR

PLP isFetching state cause product list replaced by skeletons

Client side loading finished

Solution
This PR removes step 2 by using isRefetching instead of isFetching to avoid the initial page re-rendering.
The issue is only reproducible on MRT, if you want to verify the change, the fix is deployed -> https://scaffold-pwa-test-env.mobify-storefront.com/global/en-GB/category/womens-clothing-dresses

A quick question, is there a reason why this does not show up on local development?

A quick question, is there a reason why this does not show up on local development?

no idea :(


getContentProperty encodes > < characters

Describe the bug
getContentProperty in endpoint-micropub/lib/jf2.js encodes > & < tags that aren't part of HTML tags which results in plain text content needing to have HTML characters decoded to be rendered as Markdown.
To reproduce
Create a post with the following content (without the leading spaces):
    2 < 3 and 5 > 4

    > This is quoted text

    ```
    This is text with <script>getContent()</script>
    ```

View the saved post in IndieKit. The greater than and less than symbols are encoded, so the markdown preview won't include block quotes. HTML tags are stripped so <script> won't be included in the output.

Expected behaviour
Greater than and less than symbols should remain plain text so content doesn't have to be decoded before rendering as Markdown
Environment

Indiekit version: [e.g. v1.0.0-beta.0]
Browser: Safari 16,  Edge 108
Server/host: Node 18 running indieserve locally on Docker
Content store URL: @indiekit/store-file-system

Additional context
striptags includes an option to not encode < and > characters that can be used when rendering plain text (striptags(content, { encodePlaintextTagDelimiters: false })).

If striptags is removed altogether, the markup in code fences works as expected, but <script> tags included outside of code fences is executed when previewed in IndieKit.

Thanks for the report @bwlng. Required a bit of untangling, but hopefully the fix in #564 resolves this.

The fix in #564 works great. Tried it with some code samples in fences and a long Markdown test file.. All looks good 👌
Much appreciated


nowcasting_datamodel==1.1.36

Pull Request
Description
Upgrade datamodel
Fixes #
How Has This Been Tested?
Normal CI

[ ] Yes

Checklist:

[ ] My code follows OCF's coding style guidelines
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked my code and corrected any misspellings

Codecov Report

Merging #41 (e5b0920) into main (646716e) will not change coverage.
 Consider uploading reports for the commit f532bc7 to get more accurate results

@@           Coverage Diff           @@
##             main      #41   +/-   ##
=======================================
  Coverage   92.10%   92.10%
=======================================
  Files           4        4
  Lines         152      152
=======================================
  Hits          140      140
  Misses         12       12

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


feat: add a buffer period for ReplicaSet health evaluation

resolves: https://github.com/flanksource/is-healthy/issues/119

@moshloop if a user has notification setup for config.healthy event then they would face the same problem.


Alert on fail

Feature Request
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I have an issue when [...]
The terminal running the build and compile is often hidden behind another editor. I get so used to successful changes, I sometimes don't notice that the compile fails. I would be great if the terminal would issue an alert (beep) when the compile fails.
I use macOS, but I think most terminal windows can emit an alert. This would greatly enhance the tool.
By the way, I doubt you have many users at the moment, but once Gutenberg gets really going, I must say, I love your app. I really don't know React/JSX yet, but the startup creation of the project makes it pretty easy to figure out the basics!

Let me think about it how it impacts the workflow and what people generally feel about this feature. :)


enhance Implement FullRangeGetIterator to simplify iterating over a kv range

Proposed changes
Implement FullRangeGetIterator to simplify iterating over a kv range
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


nwg-shell nixos option

It would be nice to have a simple way to install the nwg-shell environment on nixos.
It is from what I see so far the most advanced sway 'Desktop Environment'.
It looks straightforward, stable and consistant.
Some parts are already packaged in nixpkgs which should hopefully help in creating the nixos option.

I would love this too!

Bumping this as well, would be really nice but hard to implement I imagine since its a meta package.

I vote for this as well and please have the meta-package detect hyprland andadjust accordingly.

me too


fix: make sure externalRoutes are only handled if dependencies exist

Looks like there is already a test https://github.com/ember-engines/ember-engines/blob/master/tests/unit/engine-instance-test.js#L45 maybe it doesn't do it the right way?

@knownasilya I think it is missing one of the potential branches. We need to test for the engineConfiguration being defined but the engineDependencies not being defined.

@knownasilya - Had a chance to add the test yet?

Not yet, I'll try to get to it this weekend. Thanks for the reminder.

@knownasilya - Mind adding a test?

So the tests are actually there. I'm not sure why they didn't catch this issue. The first test doesn't define dependencies in the parent app, and that test passes with this change. There is a second test, and that one does define dependencies: https://github.com/ember-engines/ember-engines/blob/master/tests/unit/engine-instance-test.js#L75

I added a test that resets app.engines to undefined.

Thanks for working through this! Can you double check and confirm the new test failed prior to the change? (I mostly want to doubly ensure this is testing the right scenario)

That was sneaky, thanks for figuring all this out @knownasilya!


Documentation standard

Before we get too far into writing documentation, we should standardize the format. I think https://github.com/vue-styleguidist/vue-styleguidist might be the way to go.

@griest024
Any reason you close this one? You think vue_styleguidist does not fit the bill?

Hi, I think that vue-styleguidist could help you keep documentation of your props automatically, and show a playground of your components.
Look at these examples:
http://rafaelescala.com/vue-styleguide/
https://croudsupport.github.io/Croud-Style-Guide/technical/


Certain characters for filename will crash the program

When the user tries to enter an invalid character for their file name, like <> it gives a nice runtime error:

should be fixed


GS-Wheel Is Inconsistent

The gs-wheel element currently uses a "values" attribute to determine what list of values to display. To display a list of numbers from one to one hundred, you would do something like this:
<gs-wheel values="1-100"></gs-wheel>

This is inconsistent with how we do list controls. It is also extremely downwind of anything other than a list of numbers. To fix this, we need to convert the element to be in the same format as a gs-select element. For example:
<gs-wheel>
    <option value="mon">Monday</option>
    <option value="tue">Tuesday</option>
    <option value="wed">Wednesday</option>
    <option value="thu">Thursday</option>
    <option value="fri">Friday</option>
    <option value="sat">Saturday</option>
    <option value="sun">Sunday</option>
</gs-wheel>

This will give us all the freedom that we need, be extremely upwind and be consistent with our coding practices.
Now, how do we handle backwards compatibility? For the time being, we include some code in the "inserted" lifecycle function to convert the old attributes ("values", "min", "max", "type") into the correct option elements inside the control. After that, everything will proceed normally. The element will mine the list and create an array and then fill the element with the display html.

Fixed in next release.