Proposed HDF5-centric dataset refactor

Following discussion on #35,

[ ] Refactor loading logic into low-level file format utilities for loading original source data.
[ ] Add HDF5DatasetFile class with load_in_memory attribute.
[ ] Add fuel-convert utility that uses the low-level utilities to load data and spit them out in HDF5.
[ ] Replace existing dataset classes with ones that use (Inherit, delegate?) to HDF5DatasetFIle.

Guys, do you want to make hdf-5 the only supported format in Fuel? I am not very happy to hear that. Can I ask what are the reasons behind this decision?

My understanding is that we would still support everything that's supported at the moment, but we would use HDF5 as the data format for the built-in datasets.

Here are some questions to stimulate the discussion:

h5py or pytables?

Do we commit to support both or only the package we use for built-in datasets?
What package will be used for built-in datasets?

What convention will we use for built-in datasets?

Do we use one file per dataset split (e.g. dataset_train.hdf5, dataset_test.hdf5), or do we regroup splits in one file as primary subgroups?
Do we adopt the convention that sources are named after their array name, or do we reserve a special attribute for source names?

h5py seems to be the cleaner option, and has better low-level exposition so
that e.g. if we want to speed things up, we can write custom Cython code
that calls into their Cython code, without incurring the speed penalty of
Python function calls and object unboxing. This is not a priority right now
but it leaves the door open to performance oriented optimizations, whereas
pytables probably makes this an awful lot harder. On the other hand,
pytables has some features that h5py does not: very fast compression, fast
indexing and lookup in table oriented structures, etc. I am not sure I see
a use case for the latter but I could be wrong; one thing might be if it
supports accessing non-contiguous batches in a faster manner or something.
It may be worth retaining some optional bits that require one while
standardizing on the other for most cases.
The train vs. test thing is interesting because it points to a bigger
problem: how to effectively share file handles between dataset instances. I
have a sneaking suspicion that one or both of the libraries may react
negatively to the same file being opened twice by the same program (might
be fine if they're opened in read only mode though), and there may be
performance penalties for doing so. So the case where you split the
canonical training set into train and valid, we have to determine if the
multiple opening thing is an issue and address it if so. This points to
using a delegated object rather than inheriting, though.
I'm unopinionated about the naming issue though adopting the convention of
naming the hdf5 entity after the source name seems like the simplest option.
One more thing to add is that there are lots of hdf5 hyperparameters that
affect data access speed and so on, and my opinion is that we should be
opinionated about the defaults but allow overriding them in fuel-convert.

@rizar The reasoning is that datasets are distributed in a wide array of formats. Some of these are problematic or very slow to read, especially when we can't load them into memory (e.g. large CSV files, large image datasets distributed as individual files). If we try to support all of them we will end up with a confused mixture of datasets, with varying levels of efficiency and support for random access, subsets, loading in-memory or out-of-core, etc.
So the proposal is then to prefer an approach where we convert datasets to HDF5 instead. This gives us a variety of advantages:

The user can choose whether to load the entire dataset into memory, or to read HDF5 from disk (which automatically comes with buffered reading and, at least in PyTables, with intelligent caching)
Ability to load subsets of the file into memory
One well-tested and feature-rich dataset handler instead of having one for CSV, one for NumPy files, one for images, etc. We will still support these of course, but we don't have to support every single feature.
HDF5 allows us to tag dimensions, which could be useful when implementing #13

@vdumoulin I prefer h5py as well, at least to begin with, because it seems cleaner. But in the long term we could maybe support both so that people can make use of some of PyTables' advanced features like Blosc compression.
I am inclined to put all sets in a single file. If we run into a dataset where this is really problematic, for some particular reason, we might still be able to solve that using the external links feature.
@dwf Opening the same file multiple times does indeed seem to be problematic in some cases (see here and here). That's a bit annoying, but I think it's relatively straightforward to solve. In the low-level H5F API there is a function, h5py.h5f.get_obj_ids(), that returns all open HDF5 file objects. So something along these lines should be enough:
dataset_filename = 'test.hdf5'
for dataset in h5py.h5f.get_obj_ids():
    if dataset.name == dataset_filename:
        break
else:
    dataset = h5py.File(dataset_filename)

@bartvm If we re-use the same file object multiple times we may run into problems when closing it.
For instance, say I have a training and a test set stored in one single file under two different subgroups. If I call close on the training set's file handle, then all operations on the test set file handle will raise errors.

There's two ways around this that I see:

Don't close it. h5py automatically closes files when the script exits, we could just rely on that behaviour, but I guess that it's not very clean.
Implement a very crude reference counter, basically just extend my previous code with

dataset.ref_count = getattr(dataset, 'ref_count', 0) + 1

and instead of doing dataset.close() we do
dataset.ref_count = getattr(dataset, 'ref_count', 0) - 1
if not dataset.ref_count:
    dataset.close()

Could we handle this with class attributes? Just a process-wide
registry of all files open with that class?

@bartvm, okay, those are good reasons.
I would also add one that at the conversion stage we can use libraries that have issues with pickling, such as into.
But I was scared with the following item of @dwf's todo list:

Refactor loading logic into low-level file format utilities for loading original source data.

I understood it as getting rid of all datasets we have and move their logic into conversion scripts. I think it is too radical, and we should keep the datasets we have. Moreover, if we are just are about to support some new format via conversion, let's better have conversion logic as a simple Dataset class. Even without nice features such as caching or picklability in the middle of the epoch it can be of some use. It seems to me that supporting IndexableDataset and IterableDataset interface is not that hard. The conversion scripts will then be able to use these dataset interfaces.

@rizar Good point about into. Could be very useful and make conversion very straightforward.
I don't think there are plans of getting rid of all dataset classes! There's a confusion here I think between "datasets" referring to the publicly available, file-based ones (MNIST, CIFAR-10, etc.) and "datasets" the classes in Fuel. @dwf was talking about the former i.e. instead of writing a CIFAR10(Dataset) class that unpickles CIFAR-10 we write a script that turns CIFAR-10 into HDF5 and load that. However, we should obviously keep Fuel datasets like IndexableDataset and IterableDataset allowing people to train on Python containers/iterators. I think it is also a good idea to still have datasets like TextDataset, CSVDataset, ImageDataset, NumPyFileDataset, etc. However, we don't need these to be super-efficient or to support all possible feature now. My idea is then that there are really 3 ways of creating a Fuel dataset then:

If you have a Python container or iterable, just use IndexableDataset or IterableDataset. Perfect for derived classes to use, for toy datasets, or for tests.
For quick and dirty experiments on data you have lying around, you can use e.g. CSVDataset, ImageDataset, etc. to read in data directly. However, these can be slow, you need to load everything in memory, they won't support start and stop, maybe no random access, etc.
Built-in datasets like MNIST, CIFAR-10 will be in HDF5, and we will provide conversion scripts (and a user can obviously easily convert their own dataset to HDF5 as well). We'll try to make sure that these classes iterate as soon as possible. The user has a range of options such as loading subsets, loading into memory or streaming from disk, random access, eventually we could support high-speed compression, etc.

@dwf Yeah, a class attribute would work too. I just figured it might be safer to keep the reference counter on the HDF5 file object directly, just in case multiple classes access the same file for some reason.

Good that we agree regarding  TextDataset, CSVDataset and so on: I also think that we should keep those.
But also when we have the loading logic for a custom (MNIST, CIFAR) dataset, it can be wrapped to be a Dataset with very little overhead. Just iteration logic is enough to make an IterableDataset, simply loading into memory makes  a small dataset an instance of IndexableDataset. I am not sure that we should delete the current MNIST and CIFAR classes and move the code from respective files in something like convert_mnist.py or convert_cifar.py.

What's the point of all this HDF5 stuff if we don't use it for any dataset?
MNIST should become something like
class MNIST(HDF5Dataset):
file = 'mnist.hdf5'
And people will need to run fuel-convert --mnist once in order to create
this file. The file-reading logic that is now in MNIST would go to this
conversion script.
For MNIST this seems overkill, but it's just for consistency. For larger
datasets (SVHN) or datasets stored in crappy file formats (binarised MNIST)
this is already worthwhile.
On Mar 8, 2015 11:02 AM, "Dmitry Bogdanov"<EMAIL_ADDRESS>wrote:

Good that we agree regarding TextDataset, CSVDataset and so on: I also
think that we should keep those.
But also when we have the loading logic for a custom (MNIST, CIFAR)
dataset, it can be wrapped to be a Dataset with very little overhead.
Just iteration logic is enough to make an IterableDataset, simply loading
into memory makes a small dataset an instance of IndexableDataset. I am
not sure that we should delete the current MNIST and CIFAR classes and
move the code from respective files in something like convert_mnist.py or
convert_cifar.py.
—
Reply to this email directly or view it on GitHub
https://github.com/bartvm/fuel/issues/41#issuecomment-77753872.

@bartvm The counter should probably go in the low-level FileID object, since that's what's returned by get_obj_ids().
I'm not too fond of monkeypatching FileID instances, however. It doesn't look very clean to me.

Yeah, in my example dataset is such an instance. We're not really monkey
patching though, since we're adding attributes, not overriding them. I
think that's okay.
On Mar 8, 2015 11:54 AM, "vdumoulin"<EMAIL_ADDRESS>wrote:

@bartvm https://github.com/bartvm The counter should probably go in the
low-level FileID object, since that's what's returned by get_obj_ids().
I'm not too fond of monkeypatching FileID instances, however. It doesn't
look very clean to me.
—
Reply to this email directly or view it on GitHub
https://github.com/bartvm/fuel/issues/41#issuecomment-77757121.

What's the point of all this HDF5 stuff if we don't use it for any dataset?

The point is that any dataset can be converted to HDF5, that instead of implementing advanced things like reading parts of file for every format, we will only have to concentrate on HDF5. But there is also "you don't pay for what you don't use" principle, and I do not think that forcing user to convert MNIST to HDF5 for the reason that HDF5 is the best solution for let's say ImageNet is a good idea. Anyway for conversion we will have to have at least sequential reading implemented for all the formats Fuel is aware off, so why not allow direct access to the data read bypassing HDF5 when it so easy?
Put it differently, I find it better to have such super-common cases as MNIST and CIFAR supported out of the box, without the conversion step, especially taking the low cost of doing this.

I disagree. For one, it's more consistent and doesn't leave us with two datasets, NumPyMNIST and HDF5MNIST, and leave users guessing "Is this dataset HDF5-only? Or does it support both? And which one should I use? Which one supports what features?" We'll also likely end up duplicating a bunch of code regarding flattening images, axes semantics (for #13), casting/scaling (i.e. if the user wants unsigned integer values instead of floating point values).
If the user insists on not converting, it's also one step away to do IndexableDataset({'features': read_mnist_images('train-images-idx3-ubyte'), 'labels': read_mnist_labels('train-labels-idx1-ubyte')}). In that case it is clear that the user is willing to accept a dataset with less features. But the normal use case would simply be:
cd FUEL_DATA_PATH/mnist
fuel-convert --mnist
python -c "from fuel.datasets import MNIST; MNIST('train')"

The payment for not using is two lines, and these two lines will make the general usage paradigm very clear to users. Special cases aren't special enough to break the rules I'd say here.

So the snippet below does not the whole story, if I understood you right! You do plan to support a lot of dataset specific features, don't you?
class MNIST(HDF5Dataset):
    file = 'mnist.hdf5'

What do you mean by dataset specific features? An HDF5 file can contain groups (in which we can define validation set, test set, etc.) and it allows for axis semantics (called "dimension scales"). The flattening, casting, etc. will be part of the HDF5Dataset class. So it could look something like
HDF5Dataset(Dataset):
    def __init__(self, flatten=None, mapping=None, ...):
        dataset = h5py.File(os.path.join(config.data_path, self.file))
        ...

class MNIST(HDF5Dataset):
    file = 'mnist.hdf5'

mnist = MNIST('train')  # Loads the /train/features and /train/targets nodes in the file
mnist = MNIST('train', flatten=True)  # Flattens all loaded data to be 2D
mnist = MNIST('train', flatten=True, mapping=[Cast(dtype='float32'), Scale(1/255)])  # Applies mapping
mnist = MNIST('train', load_into_memory=True)  # Does data = numpy.asarray(data) to load into memory

Looks like we'll have to find another place to put the reference counter than in the FileID object, as it appears to be immutable.

Mm, too bad. We could store it as a class attribute on HDF5Dataset as David
suggested e.g. as a dictionary of file-id: count.
On Mar 8, 2015 3:39 PM, "vdumoulin"<EMAIL_ADDRESS>wrote:

Looks like we'll have to find another place to put the reference counter
than in the FileID object, as it appears to be immutable.
—
Reply to this email directly or view it on GitHub
https://github.com/bartvm/fuel/issues/41#issuecomment-77769787.

Here's a very minimal example of what could be done:
class H5PYDataset(Dataset):
    """An HDF5 dataset.

    Parameters
    ----------
    path : str
        Path to the HDF5 file.
    which_set : str
        Subgroup containing the requested data.

    """
    ref_counts = dict()

    def __init__(self, path, which_set, **kwargs):
        self.path = path
        self.which_set = which_set
        h5file = self.open()
        self.provides_sources = h5file[self.which_set].keys()
        self.close(h5file)

        super(H5PYDataset, self).__init__(**kwargs)

    def open(self):
        file_ids = filter(
            lambda x: x.name == self.path, self.ref_counts.keys())
        name = file_ids[0] if file_ids else self.path
        h5file = h5py.File(name=name, mode="r")
        self.ref_counts[h5file.id] = self.ref_counts.get(h5file.id, 0) + 1
        return h5file

    def close(self, state):
        self.ref_counts[state.id] -= 1
        if not self.ref_counts[state.id]:
            del self.ref_counts[state.id]
            state.close()

    def get_data(self, state=None, request=None):
        return self.filter_sources([data_source[request] for data_source in
                                    state[self.which_set].values()])

The example lacks start and stop constructor arguments, but other than that it's functional.
It assumes that the HDF5 file has the following structure:

Subgroups of root correspond to the available splits (e.g. 'train', 'valid', 'test')
Children of these subgroups are datasets whose names correspond to the available data sources

self.ref_counts should probably be H5PYDataset.ref_counts so that different instances can share file handles.
I was thinking about the splits by the way, and whether it really makes sense to keep them in separate nodes. Perhaps I'm trying to be too general, but strictly speaking it seems strange to limit ourselves to one split and hard code that. One example I can think of where multiple splits are handy is for datasets that are a combination of multiple sources e.g. for machine translation you would want to keep track of which corpora the original sentences came from, but that doesn't necessarily overlap with the train, valid and test splits. There are also use cases I guess where you would want to load the entire dataset, which is impossible for e.g. MNIST right now, and implementing it would mean an awkward concatenation of the different sets.
For splits that are contiguous, we could easily store them as HDF5 attributes by just doing e.g. h5file.attrs['train'] = [0, 60000]; h5file.attrs['train'] = [60000, 70000]. If we ever run into a case where we want splits that are non-contiguous, we could use something like h5file.attrs['alternative_train'] = '/split/alternative_train' and store lists of indices in /split/alternative_train, /split/alternative_test, etc. The logic is then:

MNIST() loads the HDF5 file in its entirety
MNIST('train') checks the split = h5file.attrs['train'] attribute and loads

if it finds an array it slices h5file[source][split[0]:split[1]]
if it finds a string, it loads h5file[source][h5file[split]]

Err, self.ref_counts will resolve the class attribute on access, will it
not? (If we were replacing it for instance method code, that would be an
issue).
On Sun, Mar 8, 2015 at 5:10 PM, Bart van Merriënboer <
<EMAIL_ADDRESS>wrote:

self.ref_counts should probably be H5PYDataset.ref_counts so that
different instances can share file handles.
I was thinking about the splits by the way, and whether it really makes
sense to keep them in separate nodes. Perhaps I'm trying to be too general,
but strictly speaking it seems strange to limit ourselves to one split and
hard code that. One example I can think of where multiple splits are handy
is for datasets that are a combination of multiple sources e.g. for machine
translation you would want to keep track of which corpora the original
sentences came from, but that doesn't necessarily overlap with the train,
valid and test splits. There are also use cases I guess where you would
want to load the entire dataset, which is impossible for e.g. MNIST right
now, and implementing it would mean an awkward concatenation of the
different sets.
For splits that are contiguous, we could easily store them as HDF5
attributes by just doing e.g. h5file.attrs['train'] = [0, 60000];
h5file.attrs['train'] = [60000, 70000]. If we ever run into a case where
we want splits that are non-contiguous, we could use something like h5file.attrs['alternative_train']
= '/split/alternative_train' and store lists of indices in
/split/alternative_train, /split/alternative_test, etc. The logic is then:

MNIST() loads the HDF5 file in its entirety
MNIST('train') checks the split = h5file.attrs['train'] attribute
and loads

if it finds an array it slices h5file[source][split[0]:split[1]]
if it finds a string, it loads h5file[source][h5file[split]]

—
Reply to this email directly or view it on GitHub
https://github.com/bartvm/fuel/issues/41#issuecomment-77774481.

It would resolve to it when reading, but it won't when writing to it. In order to write, you need to explicitly access the class attribute.
class Foo(object):
    bar = 1

>>> foo = Foo()
>>> foo.bar = 2
>>> foo.bar
2
>>> Foo.bar
1

Right, but wouldn't be generally be mutating that dictionary rather than
overwriting the entire dictionary itself?
On Sun, Mar 8, 2015 at 7:39 PM, Bart van Merriënboer <
<EMAIL_ADDRESS>wrote:

It would resolve to it when reading, but it won't when writing to it. In
order to write, you need to explicitly access the class attribute.
class Foo(object):
bar = 1

foo = Foo()>>> foo.bar = 2>>> foo.bar2>>> Foo.bar1

—
Reply to this email directly or view it on GitHub
https://github.com/bartvm/fuel/issues/41#issuecomment-77782343.

Very good point, ignore me :)

I opened a WIP PR (#43) over the implementation of H5PYDataset.

One thing to keep in mind with all-in-one-file datasets is that using the 'core' driver option will load the entire file in memory, even though we might end up using only part of it.

I guess that would be the user's fault anyway, for passing core explicitly. But I'm wondering if that is actually true, the documentation says

Memory-map the entire file; all operations are performed in memory and written back out when the file is closed.

For writing this would mean that the entire file ends up in memory if you are creating it from scratch, but for reading that's not entirely clear to me. It seems to suggest copy-on-write behavior to me, so as long as you don't perform any writes you'll just be reading memory-mapped data, no?

I did a very informal test on an HDF5 version of binarized MNIST where I

instantiated the training and test sets,
called open() on the training set,
called close() on the training set,
called open() on the test set, and
called close() on the test set.

Memory usage increased by the same ~50M after step 2 and 4, which corresponds to the size of my HDF5 file on disk.

That might be the caching mechanism though. HDF5 is pretty smart about
keeping as much in memory as possible. I guess you'd have to try with a
file that is larger than your RAM.
Then again, do we care much about what happens in this particular driver
mode? Loading into memory can be done with something like
np.asarray(dset[slice]), which would only load a subset, so we don't need
this driver mode, do we?
On Mar 9, 2015 11:09 AM, "vdumoulin"<EMAIL_ADDRESS>wrote:

I did a very informal test on an HDF5 version of binarized MNIST where I

instantiated the training and test sets,
called open() on the training set,
called close() on the training set,
called open() on the test set, and
called close() on the test set.

Memory usage increased by the same ~50M after step 2 and 4, which
corresponds to the size of my HDF5 file on disk.
—
Reply to this email directly or view it on GitHub
https://github.com/bartvm/fuel/issues/41#issuecomment-77871275.

The core driver looks like the simplest way to have your dataset in memory from an implementation perspective, but you're right that loading into memory can be done by hand.

Concerning splits, I thought about @bartvm's suggestion to concatenate all splits and have the split information be an HDF5 dataset attribute, and I'm starting to think it's a pretty good idea.
Here are some additional thoughts:

We have to be careful not to accidentally load things into memory. That means some indexing gymnastics, especially in the non-contiguous case. It's not a dealbreaker, but it's something to keep in mind.
We need to think carefully about the semantics of which_set, start and stop. For instance, what does which_set, start, stop = 'test', 100, 500 mean? I propose the following:

which_set is resolved first
start and stop define a slice within the context of which_set

Another question for you guys: I started working on the data conversion script, and I was wondering where to put it.
Would a bin directory à la Theano fork for you?

Yes, but more à la Blocks i.e. with the command parsing in a bin
directory, while keeping the actual conversion logic in a converters
directory that is in the Fuel namespace (so importable).
On Mar 11, 2015 11:51 AM, "vdumoulin"<EMAIL_ADDRESS>wrote:

Another question for you guys: I started working on the data conversion
script, and I was wondering where to put it.
Would a bin directory à la Theano fork for you?
—
Reply to this email directly or view it on GitHub
https://github.com/bartvm/fuel/issues/41#issuecomment-78291282.

There are also use cases I guess where you would want to load the entire dataset, which is impossible for e.g. MNIST right now, and implementing it would mean an awkward concatenation of the different sets.

Can you give an example of where this might be useful? I'm having a hard time coming up with one.

Eh... Applying a kind of preprocessing to the entire dataset? Let's say I want to train on MNIST upside down or want to limit the vocabulary of my corpus, right now I need to load and apply the rotations/token replacements to each split separately.

That's convincing enough I guess.

I think we're in a state where this issue has been fixed. I'll close it, but feel free to re-open it if you feel like something's still missing.


Claude 3.5 Sonnet not giving full responses due to 'DiffInstructions'

Recently Claude 3.5 Sonnet has been giving very brief responses that don't provide any explanations, just code output. I did not instruct it to do so. When I asked Claude why it was behaving this way, it responded with:
I am following the specific instruction provided in the DiffInstructions:
<DiffInstructions>Please analyze the code and provide ONLY the modified code in your response. Do not include any explanations or comments. The response should contain just the modified code wrapped in a code block using the appropriate language identifier. If multiple files need to be modified, provide each file's content in a separate code block. </DiffInstructions>

I could not find any configuration in DevoxxGenie where this was set. The closest I could find was "LLM Git Diff View" but I don't have that enabled. Next I asked it what DiffInstructions are and where they were set. It replied with the following:
DiffInstructions appear to be part of the conversation context that instructs AI assistants like me to provide only code changes without explanations. They're being included in your messages as XML-style tags.

Without these instructions, I would typically provide:
1. Detailed explanations of code changes
2. Context and rationale for modifications
3. Additional suggestions and best practices
4. Examples and usage scenarios
5. Potential pitfalls to watch out for

The DiffInstructions are likely set by:
- The IDE plugin you're using
- The integration system between your IDE and the AI service
- The specific configuration of your development environment

Then I tried calling the model from curl to see if this was being set on Anthropic's side. I asked it if it was provided DiffInstructions. It replied with:
I aim to be direct and honest in my responses. I have not been provided with DiffInstructions and don't know what those are.
To me this makes it clear that DevoxxGenie is providing these instructions somehow. I'd like to know if this is the case and how to turn it off.
I also tried using OpenAI's o1-preview model and DiffInstructions make the model completely unusable.  I have no idea why this feature that neuters the models was added since we're using our own API keys and not costing DevoxxGenie.
I'm on DevoxxGenie 0.4.5

I uninstalled the plugin and reinstalled it again. It's no longer getting DiffInstructions. I'll close this ticket but still don't know why it was behaving the way it was. I checked the source code and it looked like DiffInstructions  are supposed to only be used when LLM Git Diff View feature is enable, which I didn't have enabled.


Release v0.0.7

@KingGorrin @Sol-Sanctum check the last commit.

Same result as in #22

@KingGorrin

\screen_capturer_plugin.cpp(10,10): fatal  error C1083: Cannot open include file: 'atlimage.h': No such file or directory

This might be due to a missing dependency. I was able to build the project with IntelliJ IDEA.
Related: https://stackoverflow.com/a/46304843

That did the trick! Thanks @Sol-Sanctum

@KingGorrin

\screen_capturer_plugin.cpp(10,10): fatal  error C1083: Cannot open include file: 'atlimage.h': No such file or directory

This might be due to a missing dependency. I was able to build the project with IntelliJ IDEA.
Related: https://stackoverflow.com/a/46304843

Indeed it requires Windows C++ ATL

So far, most things are working as expected on Windows.
Tested

WC with the Demo and Bridge sites*
Wallet backup process

* I'm able to consistently establish connections with the URL and screenshot methods, but the automatic Syrius Desktop trigger doesn't work often.
We may want to create an issue to keep track of this result and address it at a later time.

@alienc0der you need to request reviews before anyone can approve the PR.

What's in this release?

@alienc0der can you provide a comprehensive PR description of what this change entails and why?

Updated dependencies
Updated WalletConnect integration
Fixed charts and duplicated nodes in Node Management
Fixed metadata.dart when single quotes are present in the commit message
Added possibility to turn off the auto-receiver
Added possibility to open the logs directory
Added hardcoded community nodes
UX/UI improvements: badge for notifications icon

Please add your list to the first post in this thread
Here are some thoughts about the PR:

UX/UI improvements: badge for notifications icon

We should be able to acknowledge (read) notifications without deleting them.
An "Acknowledge all" option should be offered.

Node Management badges are misaligned

Added possibility to turn off the auto-receiver

Is this phrasing correct?
"Disable the auto-receiver to protect against dusting attacks" -- This implementation doesn't do that.
The UI doesn't indicate any pending inbound transfers or allow users to cherry-pick transactions. It effectively prevents users from receiving anything.
When I re-enabled it, I saw N number of "error -32000: account-block from-block already received" notifications, one for each pending tx. Not sure how often that will happen.
After it's re-enabled, wallets might be generating plasma for numerous transactions back-to-back. Is this acceptable UX?

Added hardcoded community nodes

Please add more than one: wss://node.zenonhub.io:35998
I believe these should not be hardcoded in the wallet. If it's not changed now, then we should create a backlog item/ticket to address this.

Can we disable the pulsating dot at the top right?

I like the lightning bolt and WalletConnect seems to work.

I've tried running the release from https://github.com/alienc0der/syrius/releases updated yesterday, which I assumed is the correct one this PR references. Unfortunately, I got the following error and the wallet window is just blank:
[ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: Null check operator used on a null value #0      Web3WalletService.getWeb3Wallet (package:zenon_syrius_wallet_flutter/services/web3wallet_service.dart:124) #1      new NoMService (package:zenon_syrius_wallet_flutter/blocs/wallet_connect/chains/nom_service.dart:58) #2      setup (package:zenon_syrius_wallet_flutter/main.dart:177) #3      main (package:zenon_syrius_wallet_flutter/main.dart:79) <asynchronous suspension>
OS: Ubuntu 23.04 x86_64
Any extra info/help testing a new release, let me know. Happy to help.

I tried the same release as coinselor but on OS X and got a similar issue, syrius opens to a black screen and freezes, I have to force quit it.
The following is from syrius/log
INFO WalletConnectService kWcProjectId missing 2023-09-14 21:10:47.922718: null null

I've tried running the Windows release from releases updated 4 days ago and got a blank screen when starting it up. Tried various things, even deleting the whole znn folder does not help.
The log only show the following line:
INFO WalletConnectService kWcProjectId missing 2023-09-16 18:14:08.116974: null null
I was able to build it from source and run it., but fails when trying to wrap 100 QSR. "Unable to make request and couldn't retry." The log has an -32000: account-block signature is invalid error.


No Run Options

Installed it and want to specify Python3, but don't see Run Options as mentioned in the Readme:

Use the "Configure Script" menu

Fixed in readme. Thanks!


[BEAM-8412] xlang test: set sdk worker parallelism to 1

I think cross language tests were relying on the fact that the default for this option was formerly 1, before changed to number of cores by #9785. (Multiple Docker SDK workers would have their own virtual filesystems.) We'll see if this fixes the test.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Run Python 2 PostCommit

Run CommunityMetrics PreCommit

Run Python 2 PostCommit

Py precommit flake unrelated (https://issues.apache.org/jira/browse/BEAM-8416)


fix: fixed the routes for casestudy

Description
The case study card was pointing to '/[id]' instead of the correct path 'casestudies/[id]' .
Resolves #3231

Closing this as duplicate


fix: Update yamls

Update yamls

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


bzip2 package doesn't produce libbz2.dylib on darwin

This seems fairly easy to fix, but I noticed that bzip2 has some unusual custom builder stuff going on and I wanted to see if anyone knew what was going on there before I went and changed it. Is there a reason we don't go with the usual configure && make && make install in that package?

That's because bzip2 doesn't use autoconf/automake but has it's custom makefiles (which only knows to build dynamic libs on ELF systems).
It'd be nice to get this fixed since bzip2 is currently blocking the multiple-outputs branch on Darwin (https://github.com/NixOS/nixpkgs/commit/5df65579ce44a30addf8bc3812b959d198bf4fcd for discussion). What'd need to be done is to patch Makefile-libbz2_so in the bzip2 source tree (https://gist.github.com/dezgeg/444ae4e59f04ec04574f) to work on Darwin.

I don't know... perhaps the best one can do is to add a few commands by hand https://trac.macports.org/browser/trunk/dports/archivers/bzip2/files/patch-Makefile-dylib.diff

Ah, Gentoo is probably the best shot: https://gitweb.gentoo.org/repo/proj/prefix.git/tree/app-arch/bzip2/files/bzip2-1.0.6-Makefile-libbz2_dylib

Yeah, the Gentoo one looks good.

Fixed in https://github.com/NixOS/nixpkgs/commit/31ab7d38f23e556fd4e25508bed02455474b6c97

Also, this affects nothing, but I'm confused as to why Gentoo would be hosting a darwin-specific makefile. @vcunat @dezgeg any ideas?

Gentoo has all kinds of things... also some FreeBSD stuff IIRC.

Now I'm even more confused :)
On Sat, Feb 13, 2016 at 11:25 Vladimír Čunát<EMAIL_ADDRESS>wrote:

Gentoo has all kinds of things... also some FreeBSD stuff IIRC.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/6504#issuecomment-183698879.

I expect it's just like NixOS.org having darwin-specific stuff ;-) (besides BSD, solaris, windows and others)


Store coins serialized in the roles table for easier rolling updates

This issue is imported from pivotal - Originaly created at Apr 29, 2019 by bstrooband
For settings of roles coins are used. Currently those are flattened in separate columns in the database. This will require migrations and that is relatively time consuming. We could prevent that by storing the coins serialized in a single column.
https://www.pivotaltracker.com/story/show/165311614
Estimation: 8 - 16h

Maybe we could directly overlook the names of the coin property in EB to become more descriptive. See: https://github.com/OpenConext/OpenConext-engineblock/pull/690#discussion_r279344335 (bstrooband - Apr 30, 2019)

Would keeping a whitelist of allowed coin metadata properties be a good additional requirement? This would prevent the aggregate from becoming cluttered, and would allow us to make the metadata assembler more generic in that area. (Michiel Kodde - May 2, 2019)

If we would use a separate value object we don't need a whitelist. We could delegate some responsibilities from the PushMetaAssembler to helper classes to make the assembler not cluttered, maybe a Assembler to assemble the coins into the object. This will have the added benefit of making the coins and the assembler also much better testable.
(bstrooband - May 3, 2019)

@bstrooband and @thijskh

Are there any fields that can be cleaned up in this release, hailing from the 5.10 release?
I've been playing with the idea to release this change as a 5.12 release, and put all the upcoming SFO change on a 5.13 release. What are your thoughts on this?
(Michiel Kodde - Jul 10, 2019)

I don't think there are.
Good idea (Thijs Kinkhorst - Jul 10, 2019)

Personally I don't want to clean up old coins now, because then it would be much harder to validate if it will work the same as before.
I would prefer to have a separate release with the serialized coins and maybe even an additional with the cleanup so we have a clean starting point without the need to support both ways because we then could immediately reap the benefits from the serialized coins and that would prevent us from having much maintenance work (and nightly deployments). (bstrooband - Jul 10, 2019)

We are on the same page then! (Michiel Kodde - Jul 10, 2019)


Combine suitable changes

We've recently started using Phinx in production, and one of the things I've spotted is that, where all changes in a migration are related to the same table, it does not combine them into a single query.
For my specific example, we are using MySQL, and are adding a new column to a table and then adding a foreign key linking that column to another table. This is being executed as two separate queries, which (because of the massive amount of data we have in that table) is taking rather a long time.
I'm not sure if this is a desired feature, but I intend to see if I can implement the functionality myself, and will submit a pull request once I'm ready :smile:

@stephenorr hi Stephen, I understand your frustration, but combing queries is probably a very difficult problem to engineer especially when it comes to edge cases. If you know you have a long running query you'd like to optimise I'd recommend use the query and execute methods for writing raw SQL.
Anyway best of luck if you decide to have a crack at it!


Do you really want to use html as configuration file format?

Let's format these html files to, for example, yaml?

@dimorinny HTML storing is a built-in feature of Astropy and also such data more human-readable and can be used separately from the app itself :)


Ideas

API Interface for documentation and clarity in breaking changes?
Better documentation.
Reduce API surface

Remove functions that create warnings and just return the warning instances.
Remove  under-used functions checkRegex, checkType, checkThrow, and checkBool.

Improve API

Add matches and between to go with nullable, required, and optional.

Improve naming?

Replace first with sequence.
Replace composeRules with all?
Replace restrictToSchema with schema?
Replace restrictToCollection with collection?
Replace hasSchema with ...?
Replace restrictToKeys with ...?

Ideally I'd like the rules to read correctly in the code.
validateData(hasObjectWhere({
  x: either(hasFloat, hasNull, hasUndefined), // x either has float, has null, (or) has undefined.
  y: hasString,
  z: only([
    hasObjectWhere({
      a: hasArrayWhere(item => hasFloat),
      b: isMatching('hello'),
      c: firstly(hasInteger, isBetween(0, 100)), // c firstly has integer (that) is between 0 (and) 100.
    }),
    hasFirstAMatchingC,
  ]), // z only has object where ... (and) has first a matching c.
}));

Potential New API
Rule: <D>(data: D, path: string) => ValidationError[]
Schema: { [key: string]: Rule }
validateData: <D>(rule: Rule<D>) => (data: D, path: string[]) => D // throws ValidationErrors
hasObjectWhere: (schema: Schema) => Rule // compound/reference rule
hasArrayWhere: ((item) => Rule) => Rule // compound/reference rule
hasString: Rule<string> // scalar rule
hasInteger: Rule<number> // scalar rule
hasFloat: Rule<number> // scalar rule
hasBoolean: Rule<boolean> // scalar rule
hasNull: Rule<null> // scalar rule
hasUndefined: Rule<undefined> // scalar rule
isBetween: (min = -Infinity, max = Infinity) => Rule<number> // conditional rule
isMatching: <V>(value: V) => Rule<V> // condition rule
firstly: <V>(...rules: Rule<V>[]) => Rule<V> // composer rule - sequential all
only: <V>(...rules: Rule<V>[]) => Rule<V> // composer rule - parallel all
either: <V>(...rules: Rule<V>[]) => Rule<V> // composer rule - parallel some

Should decide whether required or optional is superfluous. Required is probably superfluous because undefined is not a number, but undefined is an optional number.
Might be cool if it created a type based on the validation.

This actually allows type checking. Pretty awesome.
type ValidationError = string;
type Rule<D> = (data: D) => ValidationError[];
type UnruleProp<T> = T extends Rule<infer V> ? V : T;
type Schema<T> = {
  readonly [P in keyof T]: Rule<T[P]>;
}
type Unschema<T> = {
  readonly [P in keyof T]: UnruleProp<T[P]>;
}
type ValidateData = <D>(rule: Rule<D>) => (data: D) => D; // throws ValidationErrors
type HasObjectWhere = <T, S extends Schema<T>>(schema: S) => Rule<Unschema<S>>; // compound/reference rule
type HasString = Rule<string> // scalar rule
type HasInteger = Rule<number> // scalar rule
type HasFloat = Rule<number> // scalar rule
type HasBoolean = Rule<boolean> // scalar rule
type HasNull = Rule<null> // scalar rule
type HasUndefined = Rule<undefined> // scalar rule
type IsBetween = (min: number, max: number) => Rule<number> // conditional rule
type IsMatching = <V>(value: V) => Rule<V> // condition rule
type Firstly = <V>(...rules: Rule<V>[]) => Rule<V> // composer rule - sequential all
type Only = <V>(...rules: Rule<V>[]) => Rule<V> // composer rule - parallel all
type Either = <V>(...rules: Rule<V>[]) => Rule<V> // composer rule - parallel some

const firstly: Firstly = (...rules) => (data) => {
  return rules.reduce((errors, rule) => {
    if (errors.length === 0) {
      return rule(data);
    }
    return errors;
  }, []);
};

const either: Either = (...rules) => (data) => {
  const errorsOfRules = rules.map((rule) => {
    return rule(data);
  })
  const hasRuleWithoutErrors = errorsOfRules.filter((errors) => {
    return errors.length === 0;
  }).length !== 0;

  if (hasRuleWithoutErrors) {
    return [];
  }
  return [].concat(...errorsOfRules);
};

const hasObjectWhere: HasObjectWhere = (schema) => (data) => {
  return Object.keys(schema).reduce((errors, key) => {
    const rule = schema[key];
    return [...errors, rule(data[key])];
  }, []);
};

const isBetween: IsBetween = (min, max) => (data) => {
  if (min < data && data < max) {
    return [];
  }
  return ['not between min and max'];
};

const isMatching: IsMatching = (value) => (data) => {
  if (data === value) {
    return [];
  }
  return ['not matching value'];
}

const hasString: HasString = (data) => {
  if (typeof data === 'string') {
    return [];
  }
  return ['not a string'];
};

const hasInteger: HasInteger = (data) => {
  if (typeof data === 'number' && Math.floor(data) - data === data) {
    return [];
  }
  return ['not an integer'];
};

const validate: ValidateData = (rule) => (data) => {
  const errors = rule(data);
  if (errors.length === 0) {
      return data;
  }
  throw new Error(errors.join('\n'));
};

const myValidData = validate(hasObjectWhere({
    x: hasInteger,
    y: hasObjectWhere({
        z: either<string | number>(hasString, hasInteger),
    }),
}))({ x: 10, y: { z: 10 } });

Had been working on this in the v5 branch but now deprecating this repository in favour of https://github.com/pelotom/runtypes

Decided to continue this package due to runtype not providing all errors.

Closed by #51.


Custom abbreviation

Problem
I want to use the right alignment and no abbreviation at all, since I display only words, and even 'w' is obsolete in this case.
Idea
Allow to set a custom suffix instead of just abbreviated one.

Apologies, but I find it hard to believe a "w" bothers anyone enough to justify complicating the plugin settings further. I'm gonna say no on this one, feel free to fork the plugin.

Thanks! Testing it out.
When I checked 'Use advanced formatting', it used 'w' for the '[Note count] Custom suffix' for folders (while having 'notes' with the option disabled).
I replaced it with 'n' and it works.
For some reason the right alignment for folders is now off, and the data is put right after the folder name (even with the advanced formatting disabled):

As for the tip — I'd really love to :/ But Ko-fi is a Stripe-based service, and I can’t use it now, for known political reasons. PayPal is no longer supported here... Sorry :( I hope it changes someday.

Please check your settings - as part of this same release, you can now set different alignment options for folders and notes.

You’re correct! Changed Inline to Right-aligned, works.


Add swap in the VM

Change
Add swap in the VM
How
Implemented in https://github.com/code-ready/snc/pull/246
Expected and mesured improvements
Pros
Cons

Minkube has an option for swap but it's disabled by default.

https://github.com/kubernetes/kubernetes/issues/53533 have more details around it.

This is moving forward in https://github.com/crc-org/snc/issues/861


Duplicate wording

Connect Azure Functions to Azure Cosmos DB using Visual Studio Code page has duplicate wording in the "Add an output binding" section:
Specific attributes indicate the names of the container and its parent database. The connection string for your Azure Cosmos DB account is set by the ConnectionStringSettingAttribute.

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

ID: 62965f3a-d852-cbe8-3d01-a5126a16c660
Version Independent ID: 2af2bfc6-bf21-08c6-a874-467781a4af90
Content: Connect Azure Functions to Azure Cosmos DB using Visual Studio Code
Content Source: articles/azure-functions/functions-add-output-binding-cosmos-db-vs-code.md
Service: azure-functions
GitHub Login: @ThomasWeiss
Microsoft Alias: thweiss

@kev1010, thank you for bringing it to our attention. I will work on it and submit a PR for update.


Pub reply

A pub call should have the option of adding a callback for a reply, along with a deadline to garbage collect the subscription

Must satisfy #71


[camera_android] Fixes camera flash remaining lit after taking picture

This fixes an issue on some Android devices where once the camera flash is triggered by taking a photo (FlashMode auto or always) it won't turn off again.
This is a PR issued from the work of @gerken-tss, available here : https://github.com/gerken-tss/plugins/tree/issue-97501-flash-remains-lit/packages/camera. It works well on my device, but I didn't find any pull request so I created it.
Fixes https://github.com/flutter/flutter/issues/97501
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[x] I signed the CLA.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
[x] I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@letsar Are you planning on addressing the comments above?

Thank you for your contribution. I'm going to close this PR for now since there are outstanding comments, just to get this off our PR review queue. Please don't hesitate to submit a new PR if you have the time to address the review comments. Thanks!


add --env and --format flags to worktop.build pkg

Coordinate env/platform targets with create-worktop (#130)

The worktop.build package should offer a start export which is entirely a placeholder for a build-time alias. AKA, if you try to build your Worktop project with:
import { Router } from 'worktop';
import { start } from 'worktop.build';

const API = new Router;

start(API.run);

... and you DON'T rely on worktop.build for building the Worker (that'd be unlikely, since you have the pkg there for import), then you'll get invalid output since start does nothing by default.
The placeholder exists so that if/when you have this in your code, worktop.build (the CLI) will auto-inject the correct worktop/<env> target for you. All flag combinations (below) are determining which worktop/<env> module to alias.
Here are the valid flag combinations & their resulting targets:
# NOTE: Affects "worktop.build#start" alias only!

# build for Cloudflare as Module Worker (default)
$ worktop build
$ worktop build --env cloudflare
$ worktop build --env cloudflare --format module

# Build for Cloudflare as Service Worker ("deprecated")
$ worktop build --format sw
$ worktop build --env cloudflare --format sw

# Build for web as Service Worker
$ worktop build --env web
$ worktop build --env web --format sw

# Build for Deno Deploy
$ worktop build --env deno

# Build for Node.js
$ worktop build --env node

# Build for Node.js as GCP Function
$ worktop build --env node --format function

# Build for Node.js as AWS Lambda-like
$ worktop build --env node --format lambda

Important
If you are not importing start from the worktop.build package in your code, then these flag combinations will have no effect.

If the combination results in a CF Module Worker, then the CLI will have to check source for a default exported object somehow & either throw an error on missing or auto-insert it.

Regarding start mutations, it might be better just to have the developer export the Router instance directly from the file. I can still provide the aliases anyway, just in case, but I think it's safe to assume this logic:

"I'm building an agnostic Worker & therefore don't care where it's deployed"
"I'll use worktop.build aliases within my source code....if I need any" (eg, /<env>.ws #133)
"Because I'm using worktop.build, I need to export/initialize my App a certain way"

Then when building, worktop.build can import the entry file, grab the default export, and add the appropriate start bits.
Feels a lot safer to do that than to look for start import & usage within the entry script, then look for / replace / validate that export default start() is in place for CFW modules, await start is there (or added) for Deno, etc

Regarding start mutations, it might be better just to have the developer export the Router instance directly from the file. I can still provide the aliases anyway, just in case, but I think it's safe to assume this logic:

"I'm building an agnostic Worker & therefore don't care where it's deployed"
"I'll use worktop.build aliases within my source code....if I need any" (eg, /<env>.ws #133)
"Because I'm using worktop.build, I need to export/initialize my App a certain way"

Then when building, worktop.build can import the entry file, grab the default export, and add the appropriate start bits.
Feels a lot safer to do that than to look for start import & usage within the entry script, then look for / replace / validate that export default start() is in place for CFW modules, await start is there (or added) for Deno, etc

Closed via #135


Keptn and Other Tools (aka "Keptn vs." page)

@mehabhalodiya @StackScribe we drafted such a page. Did anything ever come of including it?

Yes, I believe we had discussed it earlier and came out with: https://gist.github.com/mehabhalodiya/3a30a4dc5e20a7c1bfd094f0c3d66653
I am not aware if @StackScribe has suggested any changes, or if she wants to add more.


Change dot cluster behavior

Closes #26
This should be the final behavior :partying_face:
I did go for a cluster segmentation algorithm (just a simple breadth first search) as opposed to the quadrant thing we discussed since it seemed more sensible when I started implementing it.
So we now split the dots into clusters (sets of connected dots) using the clustering algorithm in cluster.hpp. I did move the MazeAdapter and Cell class into maze.hpp and generalized it such that both the clustering algorithm and the A* could utilize these classes. For each cluster, we also compute the center by averaging the x and y coordinates and finding the dot closest to that position.
Given the clusters and their respective centers. the new behavior now plans a path from the current position to the center of the closest cluster except for the one that pacman might already be in and commits to it until one of the cluster dots has been reached.
There is one relatively unrelated commit in here:
c27930ef6eb906ae2bf66d497b066bc12247be18 Fixes a bug that caused a crash when pacman entered the tunnel while chasing or avoiding a ghost. It was a lot easier to fix on this branch because the positionConsideringTunnel function has been moved out of the A* class.

I had to rebase on top of pacman-demo and resolve some minor conflics (introduced by the review changes of the previous PR, I guess)
See also 063ae1e for some more optional use in A* – please check, if that makes sense :grin:

Thanks for the rebase, the optional Path stuff (which I meant to add but obviously forgot) and the detailed review. I skimmed through it briefly and I'm afraid I agree with pretty much all of your suggestion :joy:

Thanks for the rebase, the optional Path stuff (which I meant to add but obviously forgot) and the detailed review. I skimmed through it briefly and I'm afraid I agree with pretty much all of your suggestion :joy:


fixed #2063 - [closed]

In GitLab by @liyanq528 on Mar 29, 2019, 06:56
Merges issue#2063 -> dev

In GitLab by @wknet123 on Nov 13, 2019, 11:42
The test coverage for backend is 19.5%  38.81%  , check  console log

In GitLab by @wknet123 on Nov 13, 2019, 11:42
closed


Adding HandlerProvider support to list of handlers.

#258

@logi fyi

Hi @NicholasAzar,
Is there an example on how HandlerProviders would be added to the handler.yml?

@ddobrin it would be the same way as HttpHandlers without constructors. Nothing new in the handler.yml interface definition as part of this change.

@NicholasAzar : I agree that we should fail fast here, as we wish to support only certain type of handlers (if need be, it can be enhanced on demand later)


Installing nws adds git-hooks to my project

I want to use nws for serving static files in a simple npm script, but if I do an npm install nws in an existing project it adds a bunch of git hooks in my .git-folder. Now I can't commit my code without getting errors complaining about missing module ghooks.
This is both confusing and weird.. Please don't touch my .git-folder.

 I'll move that over to devdeps.

Published as v1.1.1.


Investigate bug with 'callbackNo'

VERBOSE-2:ui_dart_state.cc(209)] Unhandled Exception: NoSuchMethodError: Closure call with mismatched arguments: function 'DecisionStrategySpam.addSpamCards.<anonymous closure>.<anonymous closure>'
Receiver: Closure: (dynamic) => Future<bool>
Tried calling: DecisionStrategySpam.addSpamCards.<anonymous closure>.<anonymous closure>()
Found: DecisionStrategySpam.addSpamCards.<anonymous closure>.<anonymous closure>(dynamic) => Future<bool>
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:38:5)
#1      _objectNoSuchMethod (dart:core-patch/object_patch.dart:85:9)
#2      CardService.callbackNo (package:tiki_spam_cards/src/card/card_service.dart:29:64)
#3      ScreenController.removeCard (package:tiki_decision/src/screen/screen_controller.dart:14:35)
#4      ScreenViewLayout.build.<anonymous closure>.<anonymous closure>.<anonymous closure> (package:tiki_decision/src/screen/screen_view_layout.dart:32:63)
#5      _ScreenViewWidgetCardState.onDragEnd (package:tiki_decision/src/screen/screen_view<…>

Fixed thru a combination of
https://github.com/tiki/spam_card/releases/tag/0.0.9
https://github.com/tiki/decision/releases/tag/0.0.10
https://github.com/tiki/data/releases/tag/0.0.7


allow BREAKING CHANGE: with any verb.

I think we should amend the specification to allow BREAKING CHANGE: with any commit type (right now we indicate that a BREAKING CHANGE should be a fix, or feat).
I'm finding as I drop Node 0.10/0.12 support on some libraries, I have chore commits that are breaking.

Yes, see https://github.com/angular/angular/issues/5672
BTW, dropping Node 0.10/0.12 support should probably be a ci

@bcoe I agree with this. I think one should try for BREAKING CHANGEs to be a fix or feat, but we need to accept that even dependency changes can be flagged as breaking when one takes stability & semver seriously.

@bcoe Agreed, we have lots of precedent both in our own projects and in the community. standard-version has a BREAKING chore too (node 0.10/0.12).

I'm closing based on #11 — feel free to re-open as needed.


Installation method detect

Detect installation method and return error for domain/autoscaling update operations if installed by KnativeOperator.
In future domain/autoscaling update command should be able to handle operator mode.

@zhanggbj Just added two negative test cases for update command. PTAL.

/approve
/lgtm
@lanceliuu Thanks for the PR 👍 Merging it!


[OTHER] Reconciling sensor_format with camera_properties["ColorFilterArrangement"] value

The documentation (p. 21) indicates that the Picamera2.sensor_format attribute is indicative of the camera's Bayer matrix layout:

For a raw stream, the format normally begins with an S, followed by four characters that indicate the Bayer order of the sensor

This information can also theoretically be obtained via the Picamera2.camera_properties["ColorFilterArrangement"], which is described as (p. 72):

A number representing the native Bayer order of sensor (before any rotation is taken into account).

With 0 being RGGB, 1 GRBG, 2 GBRG, 3 BGGR, and 4 meaning monochrome.
However, I am seeing some pieces of information that seemingly contradict one another. This code:
from picamera2 import Picamera2
from pprint import pformat

picam = Picamera2()

print(f"\nCamera proprerties:\n{pformat(picam.camera_properties)}")
print(f"\nSensor format: {picam.sensor_format!r}")

Produces the output:

Camera proprerties:
{'ColorFilterArrangement': 0, # <- indicates RGGB, in theory
 'Location': 2,
 'Model': 'imx477',
 'PixelArrayActiveAreas': [(8, 16, 4056, 3040)],
 'PixelArraySize': (4056, 3040),
 'Rotation': 0,
 'ScalerCropMaximum': (0, 0, 0, 0),
 'SystemDevices': (20749, 20750, 20737, 20738, 20739),
 'UnitCellSize': (1550, 1550)}

Sensor format: 'SBGGR12_CSI2P'

The "ColorFilterArrangement" keyword's value being 0 indicates that the Bayer filter layout should be RGGB, yet the characters after the 'S' in the sensor format are 'BGGR'. Which is correct? Is this a bug, or expected behavior that I am just misunderstanding?

Hi, the problem has its roots in the fact that all the Raspberry Pi sensors are actually mounted upside down, and correcting the orientation of the images actually rotates the Bayer pattern.
Unfortunately libcamera has been through some different iterations in its implementation of all this, and actually I think it will change (be corrected, in my view) in the next update. The sensor_format property should change (back) to "SRGGB12_CSI2P" and match the colour filter arrangement.
But note that this doesn't describe the Bayer order of any raw stream that you request. For that you should always look at picam2.camera_configuration() after configuring the sensor. The format of the raw stream in there has always been and will always be correct. If you don't explicit demand a transform in your configuration, the sensor mounting rotation will be transparently corrected, and the Bayer order will actually be BGGR.
Hope that makes sense. All this rotation/transform stuff is actually highly confusing, as you can tell from the trouble libcamera has had with it!

Okay, thanks! I think I follow. So the sensor's "native" Bayer matrix is RGGB, but the 180° rotation of the sensor on the camera board makes it BGGR in practice? This would make the most "upper left" pixel of a captured image with no explicitly-specified transform a B—is that right?

That's right. The top left pixel will be B. If you ask explicitly for a 180 degree rotation it will go back to R (undoing the transparent fixing of the mounting rotation).


Better: Enforce UTF-16 code units validation on WA custom fields RD-2…

…0244
Changes:

WA List: header doesn't truncate anymore, enforces less or equal than 60 UTF-16 unit count
WA Template: same for footer, also specifies it's optional

LGTM 👍


Updating version

could this be noarch? (with python >=3.5 in the build/run requirements)

@CJ-Wright This package has a script, so my understanding is that noarch doesn't support that.  What benefits does being noarch confer?

Hmm ok the script means that it will need to wait for the next conda build, which should come out soon. Noarch packages only run in circleci so they reduce CI load and are faster.


Linux port / NoCombine

To run things on Linux we only really need a tiny subset of Combine, and the types for that are already prepared in Misc/NoCombine.swift.
We just need a way to track the sinks attached to a PassthroughSubject.
P.S.: A Swift 5.1 container would be also required of course.

Will OpenCombine help? OpenCombine

Possibly!

OpenCombine will nice alternative instead of the native framework!

If someone wants to give it a try, go ahead!
Things are now building OK on Linux, but some things won't work (e.g. the Navigation in AvocadoToast) because Combine is not available.

I created an OpenCombine branch, which at least compiles. Unfortunately OpenCombine is not yet tagged in any way and we don't want no branch deps :-)

I can create a tag for you.

No, w/ semantic versioning 0.1.0 should be fine, no alpha needed. Don't forget the included branched deps.

The alpha thing combined with zero major version is to emphasize that this is very-very early in developent not intended to be used in production :)

That's what 0.1.0 is good for. If that is still too much, use 0.0.1 :-)

Okay, went with 0.1.0.
https://github.com/broadwaylamb/OpenCombine/releases/tag/0.1.0

Very well, it's in and working! https://github.com/swiftwebui/SwiftWebUI/releases/tag/0.1.7


Update zio, zio-streams, zio-test-sbt to 1.0.14

Updates

dev.zio:zio
dev.zio:zio-streams
dev.zio:zio-test-sbt

from 1.0.10 to 1.0.14.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #407.

Superseded by #411.


[HUDI-1002] Ignore case when setting incremental mode in hive query

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request
*Ignore case when setting incremental mode in hive query
Brief change log
(for example:)

Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Codecov Report

Merging #1715 into master will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master    #1715      +/-   ##
============================================
- Coverage     18.19%   18.18%   -0.01%
  Complexity      857      857
============================================
  Files           348      348
  Lines         15358    15361       +3
  Branches       1525     1525
============================================
  Hits           2794     2794
- Misses        12206    12209       +3
  Partials        358      358

Impacted Files
Coverage Δ
Complexity Δ

...in/java/org/apache/hudi/hadoop/HoodieHiveUtil.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...i/common/table/view/HoodieTableFileSystemView.java
36.06% <0.00%> (-1.87%)
9.00% <0.00%> (ø%)

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 fb28393...3bbf939. Read the comment docs.

LGTM!


Tracker switching from stationary to away

I'm seeing what seems to be some odd behaviour. My wife went out earlier today, and here's what I'm seeing from ther ic3 device tracker:

She did stop off to do a couple of things, but on numerous occasions ic3 has put her in a stationary zone, only to then revert back to away a few seconds later. Looking my own tracker from yesterday I see similar behaviour. One of the times it did this for me was during a car journey during which I didn't stop off on the way - I would have stopped for lights etc, but nothing that should have triggered ic3 to believe I was stationary for any meaningful length of time.
Is it possible ic3 is being a bit too trigger happy in terms of when it puts a device into a stationary zone?

Check the still time on the Configuration Wizard  > Page 2 > Special Zones screen. A short time value will do that. The default is 8.
Check the Event Log. It shows when a device will move into a StatZone and if the time changes due to movement in the Results line.

I checked and it was set to 8 minutes. Its too late to grab the event log covering that period, but I can keep an eye on it over the next coupld of days and if I see the same thing I'll export the logs and provide an update.

We were away for the weekend so I thought I'd check out the tracking data when we got back to see if I was still seeing issues with the Stationary Zone triggering.
Looking at a 2.5 day period, my wife's phone went into a stationary zone 15 times - no issue there. However, in 10 of those cases, it then reverted back to Away within 15 seconds. For that to be legitimate, we'd be saying that in two thirds of cases, she was stationary just long enough to trigger the stationary zone (8 minues) and then immediately moved enough to break out of it. Clearly that's not the case.
Anyone else seeing anything like this?

Do you have any Log files that show any movement that would take her out of the zone?
What v3 beta version are you using?

The logs from the weekend are gone, but I do have one example from yesterday:

These are the log entries from that time:
11:39:31a	   UPDATED FamShr Data > RequestedBy-kalis_iphone⣇⠋•⠉richards_iphone, 11:20:52a/±35m → 11:22:49a/±13m⣇⠋✓⠈kal
					is_iphone, 11:20:53a/±7m → 11:21:12a/±9m
11:39:31a	   iCloud Acct Auth (#22) > Token, Last-11:20:47a (19 min ago)
11:39:31a	   ADDED StationaryZone-ic3_statzone_1
11:39:35a	   UPDATED iOSApp > kalis_iphone, Exit Zone, ⣇⠋•⠉Loc-11:26:21a, Home-12.9 km, (LONG, LAT/±5m)
11:39:40a	   UPDATED iOSApp > kalis_iphone, Exit Zone, ⣇⠋•⠉Loc-11:36:22a, Home-12.9 km, (LONG, LAT/±5m)
11:39:50a	   UPDATED iOSApp > kalis_iphone, Exit Zone, ⣇⠋•⠉Loc-11:39:40a, Home-12.8 km, (LONG, LAT/±4m)

I'm running v3.0.0b16b

Kalis exited a zone at 11:26, 11:36 and 11:39. Can you tell from the previous Event Log entries if she was in a zone and which one? Was that Exit processed them or ignored? I’m trying to tell if the exit was for another zone that took p place before the StatZone was created which should have been ignored.
Also, did the iosapp put her into the StatZone? Or did it still show her away?
If you can, send the log file to<EMAIL_ADDRESS>and I might be able to figure it out.

Did you review the Event Log to see what was going on at that time it was going into and out of the StatZone? You might notice something immediately that would take me a while. Also, and errors in the HA logs?

Looking at my phone, it went "stationary" 10 times over the course of the journey, rarely for more than 6 seconds. I took a look at 3 such events in the logs which occured in a cluster - from 12:23:35 to 12:36:46:
12:23:35p	   Updated > FamShr-12:16:04p/±5m → 12:16:09p/±5m (7 min ago), Moved-81 m
12:23:35p	   Located > FamShr-12:16:09p/±5m (iOSApp-11:59:54a)
12:23:35p	   Setting StatZone Location (StatZon) > StationarySince-12:15:35p (8 min ago), GPS-(51.31347, -0.35350)
12:23:40p	   iOSApp Monitor > Trigger-Exit Zone@11:59:54a (24 min ago), State-not_home@12:19:56p (4 min ago), LastTrig
					ger-FamShr@12:16:04, iOSAppData-11:59:54a, LastZoneExit-ic3_statzone_1@12:19:56p, WillUpdate-False-B

12:23:40p	   Updated > FamShr-12:16:09p/±5m → 12:23:39p/±5m (1 sec ago), Moved-4.17 km
12:23:40p	   Located > FamShr-12:23:39p/±5m (iOSApp-11:59:54a)
12:23:40p	   Trigger > Next Update Time Reached
12:23:40p	   Exited Stationary Zone (StatZon)
			┌─ iCloud update started > Next Update Time Reached
12:23:40p	│  Zone > Away > Care Home-14.7 km,Swimming-44.3 km,Home-47.8 km,Library-48.7 km,Forest School-49.2 km,Rose
			│		Cottage-54.1 km,Music Class-62.3 km, GPS-(51.30728, -0.41245/±5m)
12:23:40p	│  Nearby Devices (<20m) > ✓Kali/iPhone-2m/±5m
12:23:40p	│  Using Nearby Device Results > Kali, Distance-2 m
12:23:40p	├─ Results: From-Home > NextUpdate-1:06:55p, Interval-43 min, TravTime-1.2 hrs, Distance-45.3 mi, Direction-
			│		Towards, IntoStatZone-12:28:35p, Battery-80%
»Home		│  iOSAppState-Away, iCloud3Zone-Away, Interval-43 min, TravelTime-1.2 hrs, Distance-45.3 mi
			└─ iCloud update completed > Date source - FamShr
12:23:40p	   Device Monitor > famshr, Next Update Time Reached, AttrsZone-not_home, LocDataZone-not_home, Located-12:2
					3:39p (1 sec ago), iOSAppGPS-(51.31104, -0.37693/±5m), iOSAppState-not_home), GPS-(51.30728, -0.4124
12:23:45p	   iOSApp Monitor > Trigger-Sig Loc Change@11:59:54a (24 min ago), State-not_home@12:19:56p (4 min ago), Las
					tTrigger-FamShr@12:23:39, iOSAppData-11:59:54a, LastZoneExit-ic3_statzone_1@12:19:56p, WillUpdate-Fa

12:28:35p	   Updated > FamShr-12:23:39p/±5m → 12:23:44p/±5m (5 min ago), Moved-26 m
12:28:35p	   Located > FamShr-12:23:44p/±5m (iOSApp-11:59:54a)
12:28:35p	   Setting StatZone Location (StatZon) > StationarySince-12:20:35p (8 min ago), GPS-(51.30736, -0.41280)
12:28:35p	   Located > FamShr-12:23:44p/±5m (iOSApp-11:59:54a)
12:28:40p	   iOSApp Monitor > Trigger-Exit Zone@11:59:54a (29 min ago), State-not_home@12:24:57p (4 min ago), LastTrig
					ger-FamShr@12:23:39, iOSAppData-11:59:54a, LastZoneExit-ic3_statzone_1@12:24:57p, WillUpdate-False-B

12:28:40p	   Updated > FamShr-12:23:44p/±5m → 12:28:39p/±5m (1 sec ago), Moved-2.01 km
12:28:40p	   Located > FamShr-12:28:39p/±5m (iOSApp-11:59:54a)
12:28:40p	   Trigger > Next Update Time Reached
			┌─ iCloud update started > Next Update Time Reached
12:28:40p	│  Zone > Away > StatZon-2.01 km,Care Home-12.8 km,Swimming-42.6 km,Home-46.0 km,Library-47.0 km,Forest Scho
			│		ol-47.6 km,Rose Cottage-56.1 km,Music Class-60.6 km, GPS-(51.31655, -0.43761/±5m)
12:28:40p	│  Nearby Devices (<20m) > ✓Kali/iPhone-2m/±5m
12:28:40p	│  WazeHistDB > Get All Records, Table-locations, Criteria- lat_long_key=`51.3166:-0.4376`, RecdCnt-0
12:28:41p	│  Waze Route Info > TravTime-1.1 hrs, Dist-63.7 km, WazeMoved-2.04 km, CalcMoved-2.04 km, Took-1.61 secs
12:28:41p	├─ Results: From-Home > NextUpdate-1:09:05p, Interval-40 min, TravTime-1.1 hrs, Distance-39.6 mi, Direction-
			│		Towards, IntoStatZone-12:36:40p, Battery-80%
»Home		│  iOSAppState-Away, iCloud3Zone-Away, Interval-40 min, TravelTime-1.1 hrs, Distance-39.6 mi
			└─ iCloud update completed > Date source - FamShr
12:28:41p	   Device Monitor > famshr, Next Update Time Reached, AttrsZone-not_home, LocDataZone-not_home, Located-12:2
					8:39p (3 sec ago), iOSAppGPS-(51.30920, -0.41896/±5m), iOSAppState-not_home), GPS-(51.31655, -0.4376
12:28:45p	   iOSApp Monitor > Trigger-Sig Loc Change@11:59:54a (29 min ago), State-not_home@12:24:57p (4 min ago), Las
					tTrigger-FamShr@12:28:39, iOSAppData-11:59:54a, LastZoneExit-ic3_statzone_1@12:24:57p, WillUpdate-Fa

12:30:00p	   Nearby Devices (<20m) > ✓Kali/iPhone-2m/±5m, Checked-12:28:40p
12:36:40p	   Updated > FamShr-12:28:39p/±5m → 12:28:44p/±5m (8 min ago), Moved-13 m
12:36:40p	   Located > FamShr-12:28:44p/±5m (iOSApp-11:59:54a)
12:36:40p	   Setting StatZone Location (StatZon) > StationarySince-12:28:40p (8 min ago), GPS-(51.31662, -0.43775)
12:36:40p	   Located > FamShr-12:28:44p/±5m (iOSApp-11:59:54a)
12:36:45p	   iOSApp Monitor > Trigger-Exit Zone@11:59:54a (37 min ago), State-not_home@12:34:58p (2 min ago), LastTrig
					ger-FamShr@12:28:39, iOSAppData-11:59:54a, LastZoneExit-ic3_statzone_1@12:34:58p, WillUpdate-False-B

12:36:45p	   Updated > FamShr-12:28:44p/±5m → 12:36:44p/±5m (1 sec ago), Moved-4.45 km
12:36:45p	   Located > FamShr-12:36:44p/±5m (iOSApp-11:59:54a)
12:36:45p	   Trigger > Next Update Time Reached
			┌─ iCloud update started > Next Update Time Reached
12:36:45p	│  Zone > Away > StatZon-4.45 km,Care Home-8.34 km,Swimming-38.4 km,Home-41.9 km,Library-43.0 km,Forest Scho
			│		ol-43.7 km,Music Class-56.6 km,Rose Cottage-60.6 km, GPS-(51.34323, -0.48550/±5m)
12:36:45p	│  Nearby Devices (<20m) > »Kali/iPhone-4.5km/±5m
12:36:45p	│  WazeHistDB > Get All Records, Table-locations, Criteria- lat_long_key=`51.3432:-0.4855`, RecdCnt-0
12:36:46p	│  Waze Route Info > TravTime-1 hr, Dist-63.5 km, WazeMoved-4.91 km, CalcMoved-4.47 km, Took-1.32 secs
12:36:46p	├─ Results: From-Home > NextUpdate-1:12:55p, Interval-36 min, TravTime-1 hr, Distance-39.5 mi, Direction-Tow
			│		ards, IntoStatZone-12:44:45p, Battery-80%
»Home		│  iOSAppState-Away, iCloud3Zone-Away, Interval-36 min, TravelTime-1 hr, Distance-39.5 mi
			└─ iCloud update completed > Date source - FamShr
12:36:46p	   Device Monitor > famshr, Next Update Time Reached, AttrsZone-not_home, LocDataZone-not_home, Located-12:3
					6:44p (3 sec ago), iOSAppGPS-(51.33105, -0.48091/±5m), iOSAppState-not_home), GPS-(51.34323, -0.4855

Something that struck be as being very odd is that these 3 phases of it being stationary actually overlap. In other words, prior to the 2nd occurance of it being dropped into the StatZone, it was stationary for 8 minutes (the configured period), and this 8 minute period overlaps with the prior phase of it being stationary, from which it dropped out. So that's definitely odd.
I plotted the GPS locations and they're on the road I was on, fairly close. I'm confident that we were not stationary for 3 separate 8 minute periods, though I don't have specifics. I'm not suggesting the GPS is wrong here, and without something like Google Maps location history (which I had turned off) I don't have anything to correlate with. I may turn on Location History for now as that would be a useful reference.
So a bit inconclusive - its clearly not correct that my phone was stationary just 5 seconds longer than the threshold on 7 times out of 10, and those overlapping periods seem like they shouldn't be possible, but not sure if the logs are providing any real clue as to the cause.

One of the movements into the StatZone is:
12:28:35p          Updated > FamShr-12:23:39p/±5m → 12:23:44p/±5m (5 min ago), Moved-26 m
12:28:35p          Located > FamShr-12:23:44p/±5m (iOSApp-11:59:54a)
12:28:35p          Setting StatZone Location (StatZon) > StationarySince-12:20:35p (8 min ago),

12:28:40p	   Updated > FamShr-12:23:44p/±5m → 12:28:39p/±5m (1 sec ago), Moved-2.01 km
12:28:40p	   Located > FamShr-12:28:39p/±5m (iOSApp-11:59:54a)

At 12:38, The location data had been updated at 12:23 so that location was 5-minutes old. The StatZone timer started at 12:20, 3-minutes before the old data so really the timer should be based on the age of the data, not the current time or at least be reset to the data time of the data time is old. I’ll check it out and see what’s the best way to handle it.
Thanks.

I've added a check to not create a statzone when the current data is old.
UnzIp this into the /icloud3 directory and restart HA
icloud3_main.zip

OK I've got that running. We'll be travelling over the weekend so I'll report back on Monday on how it compares...

That seems to have done the trick - I didn't have any triggers of these very brief and/or overlapping Stationary Zones.

That seems to have done the trick - I didn't have any triggers of these very brief and/or overlapping Stationary Zones. Thanks again!

Great.


feat: add language tags to languages

#507  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @davidlj95 and the rest of your teammates on  Graphite


Rhv ansible

Base directory and role for RHV environment so far

@cwilkers looks like there is a bit of lint in one of the files https://travis-ci.org/openshift/openshift-ansible-contrib/jobs/235343729

D'oh! Looks like I forgot to read the style guide...
On May 23, 2017 1:47 PM, "Ryan Cook"<EMAIL_ADDRESS>wrote:

@cwilkers https://github.com/cwilkers looks like there is a bit of lint
in one of the files https://travis-ci.org/openshift/openshift-ansible-
contrib/jobs/235343729
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/openshift-ansible-contrib/pull/393#issuecomment-303493913,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVUWcnNJKTD8jc8aY8pKuL8J0TNhy5fGks5r8yhXgaJpZM4NkGui
.

Lint trap cleaned.

@cwilkers if you have any other commits you want to add and lint this I can review post morning meetings

@cooktheryan I'll be quiet now, I just mile-stoned getting gdeploy to actually work.

Woot will check pr soon.
On May 24, 2017 12:08 PM, "Chandler Wilkerson"<EMAIL_ADDRESS>wrote:

@cooktheryan https://github.com/cooktheryan I'll be quiet now, I just
mile-stoned getting gdeploy to actually work.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/openshift-ansible-contrib/pull/393#issuecomment-303772305,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADoslA3tERZjW56jK3SA7y4fBhNvlrzxks5r9FX0gaJpZM4NkGui
.


Bash

Rewrote the script in bash to replace the node script
Closes #7
Closes #8
Closes #9
Closes #14
Closes #15
Closes #19

@Trott it would be awesome if you could check this out and play with it a little to make sure it seems ok to you, but I feel pretty good about this.

validate.sh is the pre-commit hook that sort of acts as the master pre-commit hook? Does this mean Windows users are out of luck (or need to install PowerShell or CygWin or some tool like that which I know nothing about because I'm not a Windows user)?

It gets copied and can run as any hook. If you install the official git for windows package it includes bash, and I tested this script there successfully so I hope it covers at least the majority of users.

I might be doing something totally wrong or made a typo or missed a step, but when I tried to follow the README instructions verbatim, I got this:
fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git
cat: /package.json: No such file or directory
EXPECTED value GOT EOF

Note that the "No such file" for package.json is incorrect and is probably a result of the script not bailing after an error.
I ran git init to fix it, and ended up with:
EXPECTED , or } GOT "test"
no checks for validate.sh found.. skipping

Here's my .validate.json:
{
  "scripts": {
    "lint": "jshint ."
  },
  "pre-commit": ["lint"]
}

Whoops, looks like I had a typo in my package.json which was causing that error. Can probably improve the error message to indicate that it's in the package.json. I was hunting in .validate.json.
Anyway, now I get:
no checks for validate.sh found.. skipping

I'm not trying to do a git commit, I'm just running this:
./node_modules/git-validate/bin/validate.sh

So maybe that's the problem?

Right, the script uses the file name to determine what hook it's being run as and what key to look up the script array for. Try making a copy of the script named pre-commit and running that.
Error messages could definitely be improved, will work on that.

Copying it to .git/hooks/pre-commit and running it as that (but not actually doing a git commit) results in this:
running lint...not found!

Here's my .validate.json:
{
  "scripts": {
    "lint": "jshint ."
  },
  "pre-commit": ["lint"]
}

My .jshintrc:
{
  "node": true,

  "curly": true,
  "latedef": true,
  "quotmark": true,
  "undef": true,
  "unused": true,
  "trailing": true
}

My package.json:
{
  "name": "temp",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "install": "node install.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Rich Trott<EMAIL_ADDRESS>  "license": "ISC",
  "dependencies": {
    "git-validate": "^0.1.1"
  }
}

I have jshint installed globally and it's in my path, so I expected it to pick it up.

The "not found" message implies it's not finding the script named "lint", which is odd.. I'll check in to that.

With the typos you just fixed, I now get this:
running lint...passed!

While I didn't do an exhaustive test or review of the code, I can at least say: Works for me!

Wee! Ok, I'm going to leave this open until after I make error messages more clear, but I think we're super close on this being ready.

Added some better error messages. I think this is ready to merge.


Label spaces and fetch by label

There are some default spaces created by the CATs setup. These spaces
get a randomised GUID which is the default sorting field which means
sometimes the first 100 results for /v3/spaces includes a non-perf space
and then the GetGUIDs functions filters this space out. This causes some
assertions that 100 results were returned to fail (in the
security_groups test)

Ah this should probably be templated like #9. I'll wait for that to get merged


Brite Chart: Date formate on X-axis labels is inconsistent for bar graph

Have to display month and date format in BRITE CHARTS for bar graphs (attaching the screenshot taking an example for line graph(used brite charts to display) )
Tried to display the month and date format in X-axis. But the values are overlapping each other
Expected Behavior
Expected behavior: (NEED THE SAME DATE FORMAT TO BE DISPLAYED for bar chart too )
Current Behavior
Current behavior: (values in the X-axis are over-lapping one-other)
Screenshots (if appropriate)

Hi @florenceRency, thanks for opening this issue!
I understand you need to create a time series bar chart. We definitely don't cover that use case in Britecharts at the moment. Also, bar charts have a limitation when dealing with X-axis labels, as there is usually little room down there.
One workaround we usually suggest is to make it a horizontal bar chart. I understand from your screenshot that this won't work for your use case.
Another workaround would be to rotate those labels, if you add this:
<style>
.tick text {
  transform: rotate(-45deg);
}
</style>

You would probably need to play around with the margins to make it look good.
Hope this works!

Did this work for you @florenceRency?


[Bug] lidar_euclidean_cluster_detect doesn't work on CPU wo/ multiple thres

Bug
lidar_euclidean_cluster_detect doesn't work in my environment, NOT "use_gpu" and NOT "use_multiple_thres".
Specifications

Ubuntu version: 16.04
ROS version: Kinetic
Autoware branch: develop

can you please define, doesn't work?

@amc-nu Thanks for your comment! I found its multiple definition problem and fixed.


Swap out print statements with loguru logger.

In order to appease the Ruff Gods, I have swapped out print statements with loguru's logger.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#189  👈
#188
#187
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @chrisaddy and the rest of your teammates on  Graphite


Adds script to submit jobs

Adds api/dalton.py as a generic Dalton API client
Adds api/examples/job_submission.py to give an example on how to use the job submission and other methods from the API.
Adds documentation on how to submit a job

Addresses https://github.com/secureworks/dalton/issues/157

@whartond thanks for the review. This helped a lot to improve this contribution. As I was reading your comments, I realized that it would be worth to create an API client and use all these calls in an example. So I added:

api/dalton.py as a generic Dalton API client
api/examples/job_submission.py to give an example on how to use the job submission and other methods from the API.

I think with these two additions I have addressed all your comments.

Closes #158


[ENHANCEMENT] Please help me to advise to add feature of converting jira format to html

Hello.
I think this project is perfect solution viewing HTML on Power BI.
However, I want to add a feature of converting JIRA markdown to html .
I found npm project for this. (https://www.npmjs.com/package/jira2md)
But, I don't know where is original data for html.
below is my wrong code. Would you please how can i modify data?
public update(options: VisualUpdateOptions) {               // add to covert jira to html                 let dataView: DataView = options.dataViews[0];                                 this.textValue.text(j2m.jira_to_html(<string>dataView.single.value));

Hi there,
It's not clear from your question as to whether you're writing your own visual or looking to adapt this one, so I'll try and cover both bases.
This visual uses the table dataViewMapping so if you are trying to use single when accessing the visual's dataView, then you will not find any data in the snippet of code you've provided. single only provides one data point for the dataView, and as this visual needs more than that, it is not a suitable implementation unless you can guarantee that you'll only ever need a single datum.
Please refer to the official documentation on data view mappings for more detail with this, or if you can look in mapDataView() to see how it's extracted within this visual if you're looking to adapt it.
If you're developing your own visual to do this, then it's better to ask these kinds of questions over at the Power BI Community. Be sure to provide your capabilities.json as well as any specific snippets of code, as this will ensure you get help more quickly.
Regards,
Daniel

Hi there,
It's not clear from your question as to whether you're writing your own visual or looking to adapt this one, so I'll try and cover both bases.
This visual uses the table dataViewMapping so if you are trying to use single when accessing the visual's dataView, then you will not find any data in the snippet of code you've provided. single only provides one data point for the dataView, and as this visual needs more than that, it is not a suitable implementation unless you can guarantee that you'll only ever need a single datum.
Please refer to the official documentation on data view mappings for more detail with this, or if you can look in mapDataView() to see how it's extracted within this visual if you're looking to adapt it.
If you're developing your own visual to do this, then it's better to ask these kinds of questions over at the Power BI Community. Be sure to provide your capabilities.json as well as any specific snippets of code, as this will ensure you get help more quickly.
Regards,
Daniel

Thank you for kindly answer :) I resolve my question.
Kwon.


More useful badges?

Big collection can be found here: https://shields.io

What kind of thing are you looking for?

@Prouser123 This issue is more about improvisation. See PRs from another folks.

@greybax in regards to Pull #28  we can use the storage.js and count the keys to return the amount of movies documentaties and tv-series for badging a simple solution. I can implement that at the same time.

Fixed with commit https://github.com/greybax/awesome-IT-films/commit/cffc650cd7f3c0a57d2881c2cc4a32f8c8e5ff4b


Add documentation about using a statically provisioned Azure Files volume

I suppose instead of creating a StorageClass, an actual PersistentVolume resource has to be created that refers to an existing Azure Storage Account and a specific file share in it. If there is no definite documentation of the AzureFile plugin for PersistentVolume then it should be created. All I have found thus far are some random blogs on the internet.

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

ID: a57e48b4-dc33-0b9d-b773-42ce7d2bffd0
Version Independent ID: e912ac2d-cf6a-0b54-4697-1940b1270874
Content
Content Source
Service: container-service

@akunaatrium Thanks for the feedback. I have assigned this issue to the author to check if there is some documentation that he can refer to you or add to the backlog to create.

@akunaatrium - I will have something published tomorrow.
#in-progress

@akunaatrium - doc is here https://docs.microsoft.com/en-us/azure/aks/azure-files-volume
I am going to close this issue. If you have any additional questions or requests, feel free to re-open or submit a new issue.
Thanks
#pleas-close


Make more CSV record scalar properties into nullable

The SymbolPackageArchiveEntries table is full of 0 values because there are non-nullable scalars and they are not always set.

Done with https://github.com/NuGet/Insights/commit/fb4ab3245acfa14430045da983e4a9cdef9fdccc.


backbone request：RMNet

Hi, dear authors!
Thank you for your amazing job!
Could you support RMNet?
It like RepVgg but stronger than RepVgg. This network can convert Resnet( or other Resnet style Networks,for example, Mobilenet) to Vgg-style, which gets rid of the limitation of ReLU.
Paper & Code:
arXiv:https://arxiv.org/abs/2111.00687
code: https://github.com/fxmeng/RMNet

Of course, but the time is hard to guarantee with only our force. We welcome any interested community contributors to work on it to accelerate adding new models.

This issue will be closed as it is inactive, feel free to re-open it if necessary.


Minor integration

TODO:

Add notification/blurb that appears when a student has 4 engagement credits. Also, open the accordion if it has an engagement credit in it.
Summer Experience should have a term dropdown that contains only summer terms.
Connect the Summer Experience to the backend.
Add a "You have not participated in any qualifying activities" blurb in the Sustained Community Engagement section in that case.

The footer is not static.

The save button does not seem to work or does not indicate anything that shows that it works.

Please correct the spelling: this is consistently wrong throughout the repo; experience is not spelled with an "a".

Is this something celts staff should be able to change?

Can you add in your description who we can test ui elements with, if there's been any test data added for certain students.

 Create page for requesting other community engagement #990


Limit maximum count of private or public repositories for individual users

Gitea version (or commit ref): 1.4.0+rc1-17-g93f34fd
Git version:
Operating system: Ubuntu 17.10
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[x] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[x] Not relevant

Log gist:

Description
Hello,
At the moment it is possible to select the maximum count of repositories a user is allowed to create.
Can the admin specify the count for public or private repositories individually? What about managing how many forks, mirrors, etc... ?
If the admin cant do this right now would this be a good feature?
Thank you,
Adrian

This would be an important feature for hosted service providers.

It was discussed here

While technically it was discussed there, I don't think it's fair to say it was given proper attention. The scope of the discussion was very specific, getting gitea self-hosted, and it was determined to not be a requirement for that purpose, and the discussion ended with that. And here we are, months later, and no additional discussion has happened.

I'm taking a stab at this since @kasbah seems busy and I could use this too. :smile: Not too familiar with the Gitea code base so any pointers are welcome at PR #12705


Next.js v14 Bump

Hi there,
thanks for this package!
Opening this issue just to report Next.js v14 has been released and needs a bump :)
Thank you!

Thanks for the heads up! I tested the code against Next.js 14 and everything seems to be working. Here's a new version with v14 in the peer dependency list:
https://www.npmjs.com/package/edge-csrf/v/1.0.6-rc1
Let me know if everything is working and I can bump the edge-csrf version number. Here are some examples with Next.js 14:
https://github.com/amorey/edge-csrf/tree/next14/examples

Thanks for the heads up! I tested the code against Next.js 14 and everything seems to be working. Here's a new version with v14 in the peer dependency list: https://www.npmjs.com/package/edge-csrf/v/1.0.6-rc1
Let me know if everything is working and I can make a new stable release. Here are some examples with Next.js 14: https://github.com/amorey/edge-csrf/tree/next14/examples

Thank you so much for the quick release! Working all good here :)

Great! Bumped https://github.com/amorey/edge-csrf/releases/tag/v1.0.6


Avoid Inf Loop in Joint Tour Participation

The joint tour participation model works by assigning probabilities for each person in the household as to whether they participate in a joint tour.  The model then tries to satisfy the composition of the joint tour by iteratively drawing random numbers and seeing if each person participates.  Sometimes the probabilities are very small, and the joint tour participation model runs out of iterations.  The user has an option to specify to force participation after the specified number of iterations for anyone with a non-zero probability.
However, if forced participation still does not satisfy tour composition, the model is stuck in an infinite loop trying to force satisfaction even though its impossible. (Only ran into this in fringe cases in estimation mode.)
This PR will throw a runtime error if the forced participation is still unsuccessful at satisfying all joint tours.

@i-am-sijia, ready for your review. Thanks!


Logon to Cody is not saved

Type: Bug
I want to use vscodium on my Linux Mint, but it asks me to logon to souregraph Cody each time I start vscodium. Why doesn't it remember my logon?
In VS Code this works fine.
Extension version: 1.32.6
VSCodium version: VSCodium 1.92.2 (21b1e2955ddda36eeba3a94e643128e465285b93, 2024-08-15T18:27:27.910Z)
OS version: Linux x64 6.8.0-41-generic
Modes:

System Info

Item
Value

CPUs
AMD Ryzen 5 5600X 6-Core Processor (12 x 3718)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_offwebnn: disabled_off

Load (avg)
0, 0, 0

Memory (System)
15.54GB (6.06GB free)

Process Argv
--extensions-dir /home/tom/.var/app/com.vscodium.codium/data/codium/extensions --ozone-platform=x11

Screen Reader
no

VM
0%

DESKTOP_SESSION
cinnamon

XDG_CURRENT_DESKTOP
X-Cinnamon

XDG_SESSION_DESKTOP
cinnamon

XDG_SESSION_TYPE
x11

I suspect this is an issue caused by your local secret storage. The VS Code docs has some troubleshooting steps that might help: https://code.visualstudio.com/docs/editor/settings-sync#_linux

I don't understand... your answer refers to problems in VS Code but VS Code works fine and remembers the logon. The problem only is in VSCodium.

Same problem using VSCodium on Fedora.

Same problem using VSCodium on Fedora.
@TomTurtle VSCodium is a fork of VSCode so the same settings apply since it's an almost 1:1 match.
Ctrl+Shift+P and running the Preferences: Configure Runtime Arguments command. This will open the argv.json file where you can add the setting "password-store":"basic".

Thank you very much for your answer! But changing this setting would mean the password will be stored less secure I assume.  My question would be... what do I have to do to make the keyring store simply work as it does in VSCode?

Same problem using VSCodium on Fedora.

@TomTurtle VSCodium is a fork of VSCode so the same settings apply since it's an almost 1:1 match.

Ctrl+Shift+P and running the Preferences: Configure Runtime Arguments command. This will open the argv.json file where you can add the setting "password-store":"basic".

Thank you very much for your answer! But changing this setting would mean the password will be stored less secure I assume.  My question would be... what do I have to do to make the keyring store simply work as it does in VSCode?

I'm not sure can work in the same way as VSCode. Also, yes it is less secure but I presume it's stored somewhere on your local machine so the threat level is extremely low.