Move Maps to CSV Based Method

This PR is associated with the corresponding PR on LSTGeometry: https://github.com/SegmentLinking/LSTGeometry/pull/10
I'll update this PR with more info tomorrow. I still want to make a cleanup commit.

/run standalone

I think there is an error on the master branch. The code expects that the centroid values are attached to the endcap orientation file, see below.
https://github.com/SegmentLinking/TrackLooper/blob/78d8d24c796d798353e17be68ee01a2cecbf15a0/SDL/EndcapGeometry.cc#L51-L62
But if you look at the file the master branch is using,
https://github.com/SegmentLinking/TrackLooper/blob/78d8d24c796d798353e17be68ee01a2cecbf15a0/SDL/LST.cc#L18
https://github.com/SegmentLinking/TrackLooper/blob/78d8d24c796d798353e17be68ee01a2cecbf15a0/data/endcap_orientation_data_CMSSW_12_2_0_pre2.txt#L1-L3
It doesn't have the centroid values appended and so it is filling those values with 0's. The centroid phi's are used in the endcap map, so those values are used by the algorithm. @VourMa I'll fix this in this PR.

/run cmssw

There was a problem while building and running with CMSSW. The logs can be found here.

Looks like the master branch failed?

Huh that's weird. I'm just gonna rerun the job and see if it works.

I'm not sure what's happening. I'll look into it.

Oh it's because since https://github.com/SegmentLinking/cmssw/pull/16 CMSSW uses the LST headers, including Constants.h. So, since some numbers changed there, it would have to be recompiled. I'll implement that since it might be good to always recompile the LST part between PRs and master runs. I'll let you know when it's done.

was there a good reason to put new txt files in data/output ? why not directly in data/ ?
output is not a particularly meaningful additional layer.

was there a good reason to put new txt files in data/output ? why not directly in data/ ? output is not a particularly meaningful additional layer.

also, with 2M lines proposed to be added, perhaps it's time to think of migrating to binary files from plain text for numbers.

was there a good reason to put new txt files in data/output ? why not directly in data/ ? output is not a particularly meaningful additional layer.

This and other stuff will get cleaned up in the next commit.

I removed all of the old geometry files in the /data/ folder and moved the new CSV files from /output/ to /OT800_IT615_pt0.8/ with a new README file in /data/.
I'll look now at @slava77's request of moving from .txt files to binary files.

/run standalone

/run standalone

/run cmssw CMSSW_13_3_0_pre3_LST_X
Just making sure that the CMSSW workflow works well for 100 events.
Also, just leaving an extra reminder to squash and merge since there are some very large intermediate diffs.

/run cmssw CMSSW_13_3_0_pre3_LST_X
Just making sure that the CMSSW workflow works well for 100 events.
Also, just leaving an extra reminder to squash and merge since there are some very large intermediate diffs.

Did you get rid of the comparison to master? Or is that in a different command.

Did you get rid of the comparison to master? Or is that in a different command.

Now everything is switched to CMSSW_14_1_0_pre0, so I had to specify the older branch CMSSW_13_3_0_pre3_LST_X. When running with a non-default branch it doesn't run comparisons with master since there might be many things that changed so pretty much everything would have to be done again.

@GNiendorf While I am starting to look into the PR, could you please update the PR description with the actual changes that go into this PR? It is a bit hard to understand when there are 53 files changed and issues and fixes are mentioned in a incoherent way across O(30) comments. Thank you.

Summary of changes @VourMa:

Deleted all files in the current /data/ directory.
Made a new README in the /data/ directory, and put the new module maps in the /OT800_IT615_pt0.8/  directory in /data/.
Moved any imports in the code (in trkCore.cc and LST.cc) to the new map's directory.
Improved the loading functions in TiltedGeometry.cc and EndcapGeometry.cc by getting rid of variables which were imported but never used, and made the import functions more robust to prevent similar issues described in #375.
Got rid of the if statement below, since I checked and confirmed it is never used and therefore not needed anymore (i.e. All endcap detid's are present in the endcap map now, as they should be).
https://github.com/SegmentLinking/TrackLooper/blob/1b7eccfb36338dd2766e51c001482a3a9ce827d9/SDL/Hit.h#L256-L258
Updated pix_tot and endcap_size in Constants.h as required by the new maps. endcap_size went down by 1 because in the previous maps there was a comment with the column names at the top of the file being incorrectly loaded in as actual data. pix_tot changed slightly because of new CSV based geometry leading to slightly different pixel maps.
Made naming improvement changes by changing the badly name "slope" variables to "dxdy" or something similar just like we have "drdz" variables.

Thanks, this looks good as well. Apart from the comments, I have a couple of general questions:

What is the plan on replacing the .txt with binary files? Is it something for this PR?
My very naive expectation would be no changes in physics performance, so I can't say it is clear to me why validation plots show differences. Could you please explain?

We talked about binary files in one of the weekly meetings and came to the conclusion that it should be left for a different PR in the future. Also for number 2, the performance changes are coming from the bug I fixed in #375, where the endcap maps expected that the centroid phi position was being loaded but it wasn't, so those values were all being set to 0's.

/run standalone
/run cmssw

A fatal system signal has occurred: segmentation violation
./run.sh: line 76:  4133 Segmentation fault      (core dumped) cmsRun step3_RAW2DIGI_RECO_VALIDATION_DQM.py

I'm not sure why there's a segfault. I'll take a look.

@VourMa I thought there was another commit I had to make, but it looks like this PR is ready to be merged in as well (unless I missed something).


Improve memory usage for image import and PortableCompressedTexture2D

When importing images, we store a compressed version of the image to a .ctex file with ResourceImporterTexture::save_to_ctex_format.  When importing many large images at once, this can use a large amount of memory, especially when the .ctex file uses WebP format.
This change is for ResourceImporterTexture::save_to_ctex_format to use the original Image object instead of p_image->get_image_from_mipmap(0), to avoid creating a copy of the full uncompressed image when looping through the base Image and mipmaps.  This reduces the import memory usage for large images by around 10% when using WebP, and 35-40% when Project Settings/Rendering/Textures/Lossless Compression/Force PNG is enabled, may vary depending on the image and number of import threads running.  Same change applied to PortableCompressedTexture2D::create_from_image, which has similar logic.
This helps with #92084, but does not fully resolve the issue on its own, as compressing with WebP on many threads can still use a large amount of memory - this just lowers that amount, and makes it more likely that enabling "Force PNG" will reduce memory usage enough to import the files.

What's a good dataset to test this on?

Any large image files should show a difference in memory usage (smaller files should use less memory too, but would probably be harder to see).  I mostly tested with a 3811x4081 and a 7700x6300 file, using a bunch of copies of one of them when testing multiple import threads.  Using the same file made memory comparisons easier, knowing that each thread was working on the same data, but it would probably be good to test with a larger set of files.
The PR that added lossless WebP encoding (https://github.com/godotengine/godot/pull/47835) mentioned a few projects that had images to test with, I can try testing with some of those tomorrow.  Even if they're too small to see a memory difference, would be good to confirm the resulting .ctex files are identical before/after the code change.

Thanks!


Release Google.Cloud.Firestore version 2.3.1

Changes in this release:

Commit 62182ca: fix: Propagate properties in FirestoreDbBuilder when using the emulator. Fixes issue 6313

(No API surface change, as expected in a patch release.)

Created release for Google.Cloud.Firestore-2.3.1


Fix build with -std=c11

When building with gcc or clang passing -std=c11 scanner.c fails to build (helix builds grammars with this argument):
gcc:
src/scanner.c: In function ‘match_escape’:
src/scanner.c:70:30: warning: implicit declaration of function ‘isascii’ [-Wimplicit-function-declaration]
   70 |                         if (!isascii(lexer->lookahead) ||
      |                              ^~~~~~~

clang:
src/scanner.c:70:9: error: call to undeclared function 'isascii'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
                        if (!isascii(lexer->lookahead) ||
                             ^
src/scanner.c:81:9: error: call to undeclared function 'isascii'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
                        if (!isascii(lexer->lookahead) ||
                             ^
src/scanner.c:92:9: error: call to undeclared function 'isascii'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
                        if (!isascii(lexer->lookahead) ||
                             ^
src/scanner.c:126:9: error: call to undeclared function 'isascii'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
                        if (!isascii(lexer->lookahead) ||
                             ^
4 errors generated.

It seems that isascii is deprecated and is not visible by default with -std=c11. This PR attempts to address that although I'm not 100% sure it's the right fix. A better option might be to define isascii in this project if it's not already defined. Open to suggestions

Note that there are no cases for Unicode where the above definition of isascii is incorrect.  There are very few other encodings that don't meet this, and we don't support any of them.  (E.g. EBCDIC or SHIFT-JIS.)  All the Latin-X versions for example meet this criteria.

Cool, happy to have a fix either way.


ptx: implement -b

GNU man pages says:
       -b, --break-file=FILE
              word break characters in this FILE

Code is in
https://github.com/uutils/coreutils/blob/8337179454d0c952746a980ee37a32340f510a46/src/uu/ptx/src/ptx.rs
Tests in
https://github.com/uutils/coreutils/blob/8337179454d0c952746a980ee37a32340f510a46/tests/by-util/test_ptx.rs

I gave this a shot, and I think my approach is working:
I read the break-file and create a regex (pseudocode: format!("[^{}]+", chars_from_breakfile)) from it.
Problem: output does not match GNU ptx. But I discovered neither does it for other custom regex, the algorithm is somehow broken elsewhere I think. This ptx implementation prepends spaces to after here which GNU ptx doesn't seem to do in every case.
target/debug/ptx -G -W '\w+' tests/fixtures/ptx/input > uu.out
ptx -G -W '\w+' tests/fixtures/ptx/input > gnu.out
diff uu.out gnu.out

1,2c1,2
< .xx "" "and some other like %" "a , b#, c$c" ""
< .xx "" "maybe" "also ~or^" ""
---
> .xx "" "and some other like %" "a, b#, c$c" ""
> .xx "" "maybe" "also~or^" ""

you can see the extra space before the comma and before the tilde above. These extra spaces seems to be the only differences in both cases, my break-file and the use of certain regexp passed by -W. I'd be motivated to check the algo in general, but I feel it'd be best to try that after PR #1602 was merged otherwise fundamental changes to the algo will get hard to integrate in both trees.
my break-file code, just to show my approach not ready for merge, is here:
https://github.com/uutils/coreutils/compare/master...mike-kfed:ptx_break_file
Please let me know how you prefer to continue from here.

Is this in progress currently? If not, can I take it ?

described problem maybe has went away?

The option is exists, but using it prints:
ptx: -b not implemented yet

@allan-silva, feel free to pick this up!

@tertsdiepraam the described problem has nothing to do with the -b option, it is a general problem with whitespace output when using regex. Which then of course also breaks implementing -b using a regex, like I tried in my fork.
But PR 1602 may have fixed that, and then it could be worth going that route.

Thanks @mike-kfed @tertsdiepraam , I'll take a look.

Hi @allan-silva I just found the time to look at my solution again. I merged master into my fork and It seems to work now with the new engine https://github.com/uutils/coreutils/compare/master...mike-kfed:ptx_break_file
my code also already fixes your #3142 bug
please take a look, if you're happy with it you can take my approach, or parts of it. Or of course I submit my branch as a PR, as you like.

@mike-kfed there is no master branch,

true that, sorry. I renamed the URL to main in my comment.

but if you finished this work and the tests are passing, it is better to open a PR to people review and comment.

and will prepare a PR according to the contributing guidelines, thx.


[Feature]: Add support for multi-channel ScanImage data

What would you like to see added to NeuroConv?
This is already supported in roiextractors with ScanImageTiffSinglePlaneImagingExtractor, looks like we just need to add the interface.
I'm happy work on it as it is going to be needed for Dombeck 2p conversion; just wanted to check-in with @pauladkisson @alessandratrapani before jumping on it.
Let me know what you think.
Is your feature request related to a problem?
No response
Do you have any interest in helping implement the feature?
Yes.
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] Have you ensured this bug was not already reported?

Thanks Szonja, that would be great!

        Parameters
        ----------
        start_frame: int, optional
            Start frame index (inclusive).
        end_frame: int, optional
            End frame index (exclusive).

        Returns
        -------
        video: numpy.ndarray
            The video frames.
        """
        if start_frame is None:
            start_frame = 0
        if end_frame is None:
            end_frame = self._num_frames
        end_frame_inclusive = end_frame - 1
        self.check_frame_inputs(end_frame_inclusive)
        self.check_frame_inputs(start_frame)
        raw_start = self.frame_to_raw_index(start_frame)
        raw_end_inclusive = self.frame_to_raw_index(end_frame_inclusive)  # frame_to_raw_index requires inclusive frame
        raw_end = raw_end_inclusive + 1

        ScanImageTiffReader = _get_scanimage_reader()
        with ScanImageTiffReader(filename=str(self.file_path)) as io:
            raw_video = io.data(beg=raw_start, end=raw_end)

        start_cycle = np.ceil(start_frame / self._frames_per_slice).astype("int")
        end_cycle = end_frame // self._frames_per_slice
        num_cycles = end_cycle - start_cycle
        start_frame_in_cycle = start_frame % self._frames_per_slice
        end_frame_in_cycle = end_frame % self._frames_per_slice
        start_left_in_cycle = (self._frames_per_slice - start_frame_in_cycle) % self._frames_per_slice
        end_left_in_cycle = (self._frames_per_slice - end_frame_in_cycle) % self._frames_per_slice
        index = []
        for j in range(start_left_in_cycle):  # Add remaining frames from first (incomplete) cycle
            index.append(j * self._num_channels)
        for i in range(num_cycles):
            for j in range(self._frames_per_slice):
                index.append(
                    (j - start_frame_in_cycle) * self._num_channels
                    + (i + bool(start_left_in_cycle)) * self._num_raw_per_cycle
                )
        for j in range(end_left_in_cycle):  # Add remaining frames from last (incomplete) cycle)
            index.append((j - start_frame_in_cycle) * self._num_channels + num_cycles * self._num_raw_per_cycle)
>       video = raw_video[index]
E       IndexError: index 1 is out of bounds for axis 0 with size 1

I see in roiextractors you're using a different file:
https://github.com/catalystneuro/roiextractors/blob/7aa2a63c1700075df45f377cc281f573aa1c30f8/tests/test_scanimagetiffimagingextractor.py#L11
for reason explained in https://github.com/catalystneuro/roiextractors/pull/241#issuecomment-1728409462
But I don't see why this file should not work with the new extractor, maybe I'm missing something here?

This was done in https://github.com/catalystneuro/neuroconv/pull/809


Fix SVG validation error

Attribute "xmlns" is not allowed to appear in element "symbol".

Funny trivia is that the stackoverflow icon isn't supported by Minima, because it was dropped for technical reasons at the last minute.  Its place in the SVG file was preserved in case it was revisited.  I can't explain why it didn't get the xmlns trimming that the others got.  Regardless, I'm sure the stackoverflow part needs to fixed to validate the entire file.


change ERROR traces; while true

Reviewers
@hmunfru @jframos
Description
solution: bug minor 4338, and removed a 'while true' in waiting for delete
Testing
Locally.

LGTM

LGTM


Feature request: better privacy

Please don't let the CMS link to third party services by default.
For example, the editing interface requires Google fonts. Most privacy blocking browser plugins block google form tracking you (since that it what they do, those fonts aren't free..)

Gravatar should also be removed to comply with GDPR. Third party tracking should not be a default part of a great project like this.

I would also love the option to completely disable the use of cookies for normal visitors to the site. The best way to deal with the cookie popup is to just not have cookies. I am willing to deal with the results of that, no problem.

From what I can tell, the latest version 1.1.3 doesn't seem to have improved when it comes to privacy? Microweber still loads third party scripts like there's no tomorrow.

fonts.googleapis.com
maps.googleapis.com
gosquared.com
etc

It would be great if MicroWeber could load these things from the local server by default.

By the way, my compliments that the sharing buttons have already been made privacy friendly. Great!


Pretrain data not found in AllaVA

Hi, the pretrained data used allava images both from laion nad vfan.
But the laion part image names are totally different from ALLava's images format.
I tried to found:
465440.jpeg
320609

they all used in minigemini_pretrain.json but can not be found in ALLava images folder.
ls -f images | grep 465440
46544031.jpeg
(base) ➜  allava_laion git:(main) ✗ ls -f images | grep 320609
132060956.jpeg
43206091.jpeg

why is that？

How to mapping this image file really?

I've also noticed this issue. It seems that after the existing allava was updated, some pictures were deleted. Can the repository owner take a look at the latest allava dataset and provide relevant information? @yanwei-li

It's not deleted, the index number doesn't really match the ALLava's images, besides, I think the minigemini data provided image name are trucked, where is jpeg suffix? This really shouldn't happen for them, make users very confused and missleading..

I try to use the url of minigemini pretrain dataset to match the url of allava dataset, minigemini pretrain dataset is missing about 6939 images.

Missing is normal, the question is, we have to using url to match the correct image id (filename)
this is rediculous.

@daicver @lucasjinreal Hi, thanks for using the ALLaVA data. I am from the ALLaVA group. We did have a silent update soon after we release the data. And it seems that the Mini-Gemini project was using the data before the update.
In the original version, the images entry looked like allava_laion/allava_laion_512763 and all image filenames were without a suffix either, which means they are mapped correctly.
In the current version, we made simultaneous adjustments to annotations and image filenames with suffix added.
We will fix this issue soon with the Mini-Gemini team. Stay tuned!

So, looks like minigemini were using older data, Just wonder, does the gpt repsonse also changed?

NO change in GPT-4V response.

Is the newer data is a super collection to older one?

No. In short, we only add postfixes to image filenames and annotation files so that one can preview it easily.

we can just mapping the name with url propabaly?

Sure you can do so, but we have uploaded the images in our repo as well which saves some effort for you.

Yes, I downloaded the images, here is a mapping script to adjust minigemini images back to new Allava image filename:
import json
import sys

minig = sys.argv[1]
allava = sys.argv[2]

# Load JSON file a
with open(minig, 'r') as f:
    data_a = json.load(f)

# Load JSON file b
with open(allava, 'r') as f:
    data_b = json.load(f)

# Convert list of dictionaries in b to a dictionary for easy lookup
dict_b = {item['url']: item['image'] for item in data_b}

# Iterate over items in a, replace 'image' value with value from b
for item in data_a:
    if 'url' in item.keys() and item['url'] in dict_b:
        item['image'] = dict_b[item['url']]

# Save the modified data back to a.json
with open('a_fix_gemini.json', 'w') as f:
    json.dump(data_a, f, indent=2)

For anyone to use directly.

Oh, I found using url to mapping ,still get some file unable to map correclty. Any solution?
For example:
/ALLaVA-4V/allava_laion/images/281029 not found

/allava_laion/images/387904

Hi, we @g-h-chen are working together to align the data and will update the data file soon, please stay tuned.

Looks like the truth is not exaclty said as @g-h-chen , the new Allava actually delete some images which minigemini used.

Hi, @lucasjinreal @daicver we have updated the ALLaVA data in our files, please download them in the original link Mini-Gemini-Pretrain and Mini-Gemini-Instruction. We will also re-train our model to find the effect of data change.

ok, thanks

Dudes, (hopefully) a final comment here:

The id entry of each item for allava_laion (caption and instruction) is not unique. The number of samples is 505588, and the number of unique ids is 484532. However, the contents are not the same for the samples sharing the same id. The reason is that when ALLaVA project started, we tried out some prompting strategies which led to our final version, but we accidentally re-generated those samples when performing large-scale distillation. However, we kept those samples anyway considering the cost.

Mini-Gemini team and us have updated the aligned data. Sorry for the inconvenience caused!

thank u for your guys immediate response.


Feature/httpcache response cookie exclusion

Making it possible to also exclude specific cookie keys in the http cache.

Pull Request Test Coverage Report for Build 4567

23 of 25 (92.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 52.894%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bundle/src/main/java/com/adobe/acs/commons/httpcache/config/HttpCacheConfig.java
0
1
0.0%

bundle/src/main/java/com/adobe/acs/commons/httpcache/config/impl/HttpCacheConfigImpl.java
1
2
50.0%

Totals

Change from base Build 4546:
0.03%

Covered Lines:
13498

Relevant Lines:
25519

💛  - Coveralls


⚠ Bofrost.de has degraded performance

In e305f1e, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1069 ms

Resolved: Bofrost.de performance has improved in ed3aa5d after 9 minutes.


OSError: [Errno 2] No such file or directory on Ubuntu

Running dmenu-extended, latest git pull, on awesome in ubuntu 17.04
Getting this error.
$ dmenu_extended_run --debug
Debugging enabled
Launch arguments: []
Frequently used items cache does not exist, will return nothing
Opening cache at /home/user/.config/dmenu-extended/cache/dmenuExtended_plugins.txt
Opening cache at /home/user/.config/dmenu-extended/cache/dmenuExtended_all.txt
First menu closed with user input: Chromium Web Browser (chromium-browser)
Loading plugins
This command is not related to a plugin
Converting 'Chromium Web Browser (chromium-browser)' into its aliased command
Chromium Web Browser (chromium-browser)
No suitable candidate was found
Executing user input as a command
Executing: Chromium Web Browser (chromium-browser)
Command converted into:
[u'Chromium', u'Web', u'Browser', u'(chromium-browser)']
Traceback (most recent call last):
  File "/usr/local/bin/dmenu_extended_run", line 7, in <module>
    dmenu_extended.run(*sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/dmenu_extended.py", line 1844, in run
    handle_command(d, out)
  File "/usr/local/lib/python2.7/dist-packages/dmenu_extended.py", line 1506, in handle_command
    d.execute(out)
  File "/usr/local/lib/python2.7/dist-packages/dmenu_extended.py", line 649, in execute
    return subprocess.call(command)
  File "/usr/lib/python2.7/subprocess.py", line 168, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

Hi there,
Try rebuilding your cache.
I see you're using a different alias display format: "{name} ({command})" as opposed to the default "{name}".
I can reproduce this error by setting the alias_display_format to "{name} ({command})", rebuilding the cache, then changing the alias_display_format back to "{name}" and attempting to run the Chromium Web Browser (chromium-browser).
Let me know if this doesn't fix your problem.

Thanks for getting back at me.
I could not fix the problem by changing the alias_display_format parameter and rebuilding the cache. The problem persisted.
I ended up backing up ~/.config/dmenu-extended/config/dmenuExtended_preferences.txt and removing the ~/.config/dmenu-extended directory, forcing dmenu to create new config (and cache?) files. This fixed the issue.
Comparing the old and new parameters with vimdiff did not show me anything out of the ordinary, so it must've been a problem with the cache, as you predicted.


Stashed ops

How contribute to this repo.
Guidelines for Pull Requests.
The sections included below are suggestions for what you may want to include.
Feel free to remove or alter parts of this template that do not offer value for your specific change.
Description

A concise description of the changes (bug or feature) and their impact/motivation.
If this description is short enough to be used as the title, delete this section and just use the title.

For bug fixes, also include specifics of how to reproduce it / confirm it is fixed.

If this Pull Request should close/resolve any issues when merged, use the special syntax for that here.

Breaking Changes

If this introduces a breaking change, please describe the impact and migration path for existing applications below.
See Breaking-vs-Non-breaking-Changes for details.
If there are no breaking changes, delete this section.

Reviewer Guidance
The review process is outlined on this wiki page.

List any specific things you want to get reviewer opinions on, and anything a reviewer would need to know to review this PR effectively.
Things you might want to include:

Questions about how to properly make automated tests for your changes.
Questions about design choices you made.
Descriptions of how to manually test the changes (and how much of that you have done).
etc.

If you have any questions in this section, consider making the PR a draft until all questions have been resolved.

Heads up: Curtis is working on changing some of the testing infrastructure (that we rely on) so that loads containers in read mode by default. Because the reconnect logic is in this PR is not yet merged in, the change he is making will break some of our tests. So one of two things will happen:

Curtis merges his work in main before this PR:

He will add an override flag so that our tests are unaffected by his change.
This PR will need to be updated to remove that/these flags.

This PR merges in main before Curtis':

We should let him know so he can remove the flags before merging.


Alleviate hspec-discover/cabal cache errors

Attempt to alleviate issues seen in CI (see associated ticket) by not caching cabal build artifacts between builds.

There's no guarantee that doing this will fix the issue, but not using the cache did not noticeably increase the time it took for the cabal build to run, so we don't lose anything for trying.

We'll need to "wait and see" to determine if the issue is fixed.

Issue Number
ADP-1724

bors r+


Multiple languages support

An ability to use multilingual models with directing language detection.
Saying I want to recognize English and Slovak language. Whisper has good language detector, but for shorter texts it sometimes mistakes similar language (Slovak, Czech, Slovenian), so allowing to narrow down the choice would be great.
It would be amazing to be able to use this project for those of us who routinely communicate in more than one language.

It's will be good to add more linguage support like french (for me) italian, etc

Yes, Whisper supports those languages and many more so they will all be supported (as long as Whisper does good enough on them) once this feature is implemented.


ocrfeeder: init at 0.8.3

Motivation for this change
Useful, gnome3 official application for interactive OCR.
NOTE: This depends on #84935 .
Things done

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

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

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

It'd be still nice to have, though another stale PR is a dependency for this one.

Result of nixpkgs-review pr 84939 1

4 packages built:

ocrfeeder
python37Packages.sane
python38Packages.sane
python39Packages.sane

Thanks for the review.


Formatting changes ending on \r result in an extra new line

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:  1.96
OS Version: Windows 10

Steps to Reproduce:

Install the clangd extension
Follow the steps from https://github.com/clangd/vscode-clangd/issues/759 :

Config:
IncludeBlocks: Regroup
SortIncludes: 'true'

The code:
#include "a.h"
#include "c.h"
#include "b.h"

using namespace NS;

Each time you format using clangd, a new line is added before the using namespace. I checked if I can remove the \r from the replacement in the formatting code, though it breaks other stuff while doing so. (clang-format.exe now reformats as it tries to remove the \r)
According to the maintainers of the clangd extension it is VS Code that applies these changes to the source.

Sorry for not including the patch level, I still have the issue in the latest version

Adding some details about the relevant protocol messages.
Client sends textDocument/didOpen with initial file contents:
{
  "jsonrpc": "2.0",
  "method": "textDocument/didOpen",
  "params": {
    "textDocument": {
      "languageId": "cpp",
      "text": "#include \"a.h\"\r\n#include \"c.h\"\r\n#include \"b.h\"\r\n\r\nusing namespace NS;\r\n",
      "uri": "file:///path/to/test.cpp",
      "version": 35
    }
  }
}

Client sends textDocument/formatting:
{
  "id": 8,
  "jsonrpc": "2.0",
  "method": "textDocument/formatting",
  "params": {
    "options": {
      "insertSpaces": true,
      "tabSize": 3
    },
    "textDocument": {
      "uri": "file:///path/to/test.cpp"
    }
  }
}

Server response to textDocument/formatting is:
{
  "id": 8,
  "jsonrpc": "2.0",
  "result": [
    {
      "newText": "#include \"a.h\"\r\n#include \"b.h\"\r\n#include \"c.h\"\r",
      "range": {
        "end": {
          "character": 15,
          "line": 2
        },
        "start": {
          "character": 0,
          "line": 0
        }
      }
    }
  ]
}

The replacement range and replaced text both include the \r at the end of line 2... but somehow this causes vscode to insert an additional newline.


Cypress test depends on content in knowledgebase

See this hotfix pull request:
https://github.com/kiwicom/smart-faq/pull/470
The cypress test in question failed because the title of the article was changed in knowledgebase. The hotfix fixes the issue, however it might be a good idea to replace this assertion with something that cannot be broken by changes outside that are not in the codebase.

We discussed this and came to a conclusion that this is ok because seeing the faq article is the most important thing in our app and hardcoding it should be ok for now.. they are not supposed to change that often and if they do we will change it 😊

Yes, as Dino said. If that happens more often than we though, we will reopen this.

:+1:

@vborszeki ran into this today. 1 hour later I did, too

ok, then just check if it exists ;)


scrcpy not working at all

[ ✅] I have read the FAQ.
[✅ ] I have searched in existing issues.

Environment

os: Windows 10
scrcpy version: 2.4
installation method: download zip file
device model: dell
Android version: 11

Describe the bug
As soon as I open the application it closes immediately
scrcpy 2.4 <https://github.com/Genymobile/scrcpy> * daemon not running; starting now at tcp:5037 could not read ok from ADB Server * failed to start daemon
error: cannot connect to daemon
ERROR: "adb start-server" exited unexpectedly
ERROR: Could not start adb server
 ERROR: Server connection failed
 Press Enter to continue...

Execute adb start-server (or even adb devices). What is the result?

C:\Users\dell\Desktop\scrcpy-win64-v2.4>adb devices

daemon not running; starting now at tcp:5037
could not read ok from ADB Server
failed to start daemon
adb.exe: failed to check server version: cannot connect to daemon

C:\Users\dell\Desktop\scrcpy-win64-v2.4>

C:\Users\dell\Desktop\scrcpy-win64-v2.4>adb start-server

daemon not running; starting now at tcp:5037
could not read ok from ADB Server
failed to start daemon
error: cannot connect to daemon

@X3R02002 Windows 7? https://github.com/Genymobile/scrcpy/issues/4391

11

@X3R02002ويندوز 7؟ #4391

11

It's an adb issue with your system (not a specific scrcpy issue).
Try with an older version of adb (see #4391, even if it's not exactly the same cause).


Feat/higher level erc20 helper

Changes:

added ERC-20 support to mock paymaster (+update mock paymaster contracts to singleton)
bump viem version to ^2.21.2 (getPaymasterData action isn't exposed before this version)
Added prepareUserOperation field to createSmartAccountClient
Added prepareUserOperationErc20 helper

Using the override
const pimlicoClient = createPimlicoClient({
    transport: http(PIMLICO_RPC),
    entryPoint: {
        address: entryPoint07Address,
        version: "0.7"
    }
})

const smartAccountClient = createSmartAccountClient({
    account: account,
    chain: chain,
    client: publicClient,
    paymaster: pimlicoClient,
    userOperation: {
        prepareUserOperation: prepareUserOperationErc20(pimlicoClient)
    },
    bundlerTransport: http(PIMLICO_RPC)
})

// sending a userOperation with `paymasterContext.token` set will use the
// custom prepareUserOperationErc20 under the hood.
const opHash = await smartAccountClient.sendUserOperation({
    calls: [
        {
            to: zeroAddress,
            data: "0x",
            value: 0n
        }
    ],
    paymasterContext: {
        token: ERC20_ADDRESS
    }
})

Should we use pimlicoErc20PaymasterPrepareUserOperation instead of prepareUserOperationErc20 as a name?

Encapsulate the implementation of prepareUserOperationErc20 to experimental/pimlico.


NO-ISSUE: Add cloud team to the OWNERS

Add cloud team in order to ease maintenance operations on this repo like
ocm branch cut-off.

/cc @osherdp @avishayt

/approve
/lgtm

/cc @CrystalChun


new install osrm-frontend npm build error

The error is appeared when tried to start local server:
nick@router:/opt/osrm-frontend$ npm start

<EMAIL_ADDRESS>start /opt/osrm-frontend
npm run build && npm run start-index

<EMAIL_ADDRESS>build /opt/osrm-frontend
npm run replace && npm run compile && cp node_modules/leaflet/dist/leaflet.css css/leaflet.css

<EMAIL_ADDRESS>replace /opt/osrm-frontend
node ./scripts/replace.js

/opt/osrm-frontend/scripts/replace.js:12
let options = fs.readFileSync(filepath, 'utf8')
^^^
SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:374:25)
at Object.Module._extensions..js (module.js:417:10)
at Module.load (module.js:344:32)
at Function.Module._load (module.js:301:12)
at Function.Module.runMain (module.js:442:10)
at startup (node.js:136:18)
at node.js:966:3

You're probably on node v4.
I fixed this in https://github.com/Project-OSRM/osrm-frontend/commit/1dc9d80df95309b3863ec377e9753db05477b61b#diff-5c005e23953f09d4a3dcc5bfc3b7113f
but seems like it got re-introduced in https://github.com/Project-OSRM/osrm-frontend/commit/ef453d934a38076579d31c94642b022b15995d49#diff-5c005e23953f09d4a3dcc5bfc3b7113f
You need the 'use strict'; at the top. Can you change that and open a pull request for it?


Merge branch 'master' of github.com:OHIF/Viewers into feat/preclinical-4d-base

Merged with master and fixed some issues after the merge. There are two commits that need to be reviewed as follow:

fixed some issues after merging with master branch
fixed merge issues (viewportIndex to viewportId)

Thanks a lot


there is a font package

there is font thing, which is not needed ;)

haha get good

still there


Split encoders into two packages to resolve layering issues

The core package has no external dependencies aside from NetFX-produced packages.
This allows low-level components which can't take DI or Options dependencies to use the core package.
/cc @davidfowl @Eilon

PR also contains some minor doc comment cleanup.

Seems like a good logical split. :shipit:

:shipit:


go probe needs some updates

at the least:

line up the environment variables that Go probe uses to what Swift probe uses
the run function still thinks the test function runs by calling the executable with a cmd line arg "test" (vs now the test function runs when there are no cmd line args)
nit: "cleanup" is now "clean" everywhere else

@khyberspache can you help on this one?


Add status page to the Author application.

What is the context of this PR?
This PR introduces a new /#/status route for the author application.
A Status component has been introduced which outputs simple text with a status of "OK" and the Git SHA-1 has if supplied.
How to review
Build a docker container on this branch using the following command:
docker build -t onsdigital/eq-author:latest --build-arg APPLICATION_VERSION=$(git rev-parse HEAD) .
Run the newly built author image pointing at a valid API url e.g.
docker run -ti -e REACT_APP_API_URL=http://docker.for.mac.localhost:4000/graphql 127328c9b756 (Replace 127328c9b756 with the image Id for onsdigital/eq-author:latest, which can be found by running docker images.
Navigate to the application running on port 3000. Browse to the /#/status endpoint.
You should see status OK and the Git SHA-1 hash for version.

 Add status pages (3)

What is the purpose of this page @jonnyshaw89? Is it to test the deploy happened? Or test the app is "running" (i.e. JS is not crashing)?

@WickyNilliams its mainly just a way to check is the app running and what version of the app is running

@jonnyshaw89, i think this now works as expected. The netlify deploy has the status page: https://deploy-preview-267--author.netlify.com/status.json
If you're happy, could you approve?


It runs, then in Minecraft it says "Shutting down internal server"

The screen blinks, then stabilizes, the bot takes a few steps then Minecraft reports "shutting down internal server" and it closes. There's no error output. Not sure what the issue is.

Same issue, running on Windows 11 WSL Ubuntu. Install validated. Can't run tasks, just get "shutting down internal server" in minecraft menu and it closes.


Updating broker/Interoperator docker image versions:0.16.0

Updating broker/Interoperator docker image versions:0.16.0

This change is merged in the PR: https://github.com/cloudfoundry-incubator/service-fabrik-broker/pull/1354


bug: builtin preview layout specified with up:*%, shows up incorrectly in vsplits

using minimal config:
fzf.setup({
      winopts = {
        split = 'horizontal new',
        fullscreen = false,
        preview = {
          layout = 'flex',
          horizontal = 'right:50%',
          vertical = 'up:50%',                                              -- example config shows use of down
        },
      }
})

https://user-images.githubusercontent.com/16427330/230258136-be553e97-9631-43c8-82be-cb497e2fe529.mov
explanation:

with vsplits, any buffer with a split to its right will show this bug, where the preview window is drawn in the incorrect location (always offset to the right side, occupying the split on the right.
this behavior IS NOT SHOWN when using vertical='down:50%' instead.

I never tested with horizontal new, the splits are assumed to be one of the four listed in the README:

local actions = require "fzf-lua.actions"
require'fzf-lua'.setup {
  winopts = {
    -- split         = "belowright new",-- open in a split instead?
                                        -- "belowright new"  : split below
                                        -- "aboveleft new"   : split above
                                        -- "belowright vnew" : split right
                                        -- "aboveleft vnew   : split left
     }
}

What behavior are you trying to achieve? Am I understanding correctly that you’re trying to open fzf-lua in a split below the current window with the same width?
The layout code is already one of my most unpleasant ones that I aim to refactor one day I don’t know if I want to add yet more complexity to it, isn’t one of the 4 listed splits sufficient for your workflow?

https://github.com/ibhagwan/fzf-lua/commit/ed41a475527f07a6e887146779e0ee6f0a779efd - should work now:


Terrain chunks lod testing

This includes a simple LOD system with terrain skirt generation. Terrain stitching code is included but not complete. It will currently only work for terrains of the same size One thing of note is that in the coordinate system as implemented the x axis positive direction is left of forward. So when you are setting up terrain neighbors the right neighbor is going to be in the x positive direction. Creating PR because I will be out for a bit if anyone wants to mess with it.

Merging to terrain_chunks


Add Assignment XOR  Token at translator frontend

Implement the ASSIGN_XOR token to recognize the ^= operator for performing bitwise XOR assignments.

@Proxihox will be working on this issue


Add linting and automated testing on CircleCi Remove empty line First rough version of the Jupyter Linter.

See the README of how to run and test it.

This change is

@ericboucher @akegan @tetraptych Please only from r2 on.

Review status: 0 of 6 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: 0 of 6 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion.

circle.yml, line 3 at r4 (raw file):

dependencies:
  pre:
    - pip install -r requirements.txt

Nit - Is that needed? I thought that CircleCI would detect that automatically.

Comments from Reviewable

Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion, some commit checks pending.

circle.yml, line 3 at r4 (raw file):
Previously, pcorpet (Pascal Corpet) wrote…
Nit - Is that needed? I thought that CircleCI would detect that automatically.

Done. Nice, I didn't know that.

Comments from Reviewable


Why is pytables in the requirements file?

I assumed it was needed for a development install, but I don't see where it is getting imported or used.

I believe it's a pandas optional dependency, specifically that's used for h5 stuff, so I think we're using it indirectly in the pandas cacher:
https://github.com/ORNL/curifactory/blob/fd803f7a0d054c897162e14e28d923fab217f875/curifactory/caching.py#L497
That said, we never actually added it to curifactory's setup.py, so I think I need to add it as an optional dependency on cf as well (reference for myself: https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#optional-dependencies)


Set current tokens remaining in constructor

In my case, I create the limiter object after the first call using the returned header.
So for now I create the object, then run a removeTokens function and ignore the result. It would be really fantastic if I could simply pass the remaining tokens for this interval into the constructor, that way I wouldn't have to make a simply removeTokens method with a blank callback.
Such as Limiter(120, 'minute', 119);

Yup. I have a somewhat similar use-case with a remote that allows quite agressive bursting and then a trickle of requests. So I have huge initial capacity and then a low-fill rate afterwards.
I tried hacking it, but it does seem the count is kept in a closure, so I can't get to it:
var limiter = new RateLimiter(1, 60 * 1000);
limiter.tokenBucket.content = 10;

The check for how many tokens are left in the bucket happens one level deeper, in the call to this.tokenBucket.removeTokens(). A proposed fix for this was submitted in https://github.com/jhurliman/node-rate-limiter/pull/41 but I'd prefer to add another parameter to the constructor as suggested here rather than changing the default behavior. If someone puts together a PR for this I'm happy to review and merge.

@hongkongkiwi , @jhurliman time to close this issue?

@SirR4T it's a valid request that no one has implemented yet; I think we can keep it open.

Sure, misunderstood the requirement first time round.
At first glance, this looks as simple as:

Accepting a new number parameter in constructor, say startWithTokens,
setting this.tokensThisInterval to (tokensPerInterval - startWithTokens) instead of 0, to ensure that this many tokens are already used up. (First call to removeTokens() will check that count is less than startWithTokens, until this interval is reset).

But then, this will not ensure that getTokensRemaining() returns startWithTokens.
Is that ok? Or should this be fixed at the TokenBucket level?

I'd find it helpful if the TokenBucket constructor took an initial bucket content, or had a flag to indicate the bucket should start full instead of the current start empty behavior.

TokenBucket content is now exposed in 2.0.0


Export custom colormaps in readable formats

I think it would be useful to have an export=bool command on plot.Colormap. Currently, save=True just saves it to ~/.proplot/cmaps as a json that seems to be readable to just proplot. It would be great to be able to export it as an xml, hex, etc. to then import into other tools and software.

You read my mind :)
In #57, I'm implementing all colormaps as subclasses of the matplotlib.colors.Colormap class. The subclass will add a save() method that can take optional arguments for the save format, save location, etc. Then passing save=True to plot.Colormap() will just call cmap.save(), where the default cmap.save() behavior will be to save in ~/.proplot/cmaps.

Done! See #57
Example usage:
import proplot as plot
cmap = plot.Colormap(('goldenrod',  'red')) # perceptually uniform transition between colors
cmap.save('file.txt') # saves RGB table in current directory

See the docs for details.

Awesome!

Also (thought this was cool) I changed __repr__ and __str__ for the new colormap classes, which makes it easy to work with them interactively. Examples:
>>> plot.Colormap('Blues') # colorbrewer
LinearSegmentedColormap({
 'name': 'Blues',
 'red': [0.969, ..., 0.031],
 'green': [0.984, ..., 0.188],
 'blue': [1.000, ..., 0.420],
 'alpha': [1.000, ..., 1.000],
})

>>> plot.Colormap('dark red') # arbitrary named color
PerceptuallyUniformColormap({
 'name': '_no_name',
 'space': 'hsl',
 'hue': [12.169, ..., 12.169],
 'saturation': [99.994, ..., 99.994],
 'luminance': [100.000, ..., 26.464],
 'alpha': [1.000, ..., 1.000],
})

>>> plot.Colormap('fire') # ProPlot map
PerceptuallyUniformColormap({
 'name': 'Fire',
 'space': 'hsl',
 'hue': [72.169, ..., -27.831],
 'saturation': [90.000, ..., 60.000],
 'luminance': [100.000, ..., 15.000],
 'alpha': [1.000, ..., 1.000],
})

>>> plot.Colormap('538') # "color cycle"
ListedColormap({
 'name': '538',
 'colors': ['#008fd5', '#fc4f30', '#e5ae38', '#6d904f', '#8b8b8b', '#810f7c'],
})


Scrolling to Element fails on Android

Describe the bug
When using the waitFor(element(by.id(targetElement))).toBeVisible().whileElement(by.id(bakcground)).scroll(pixels, direction')  both on a ScrollView and FlatList, the following error is returned:
Test Failed: 'at least 75 percent of the view's area is displayed to the user.' doesn't match the selected view.
    Expected: at least 75 percent of the view's area is displayed to the user.

Steps To Reproduce

Clone: https://github.com/j320/detox_scrolling
Build the app: yarn android:build
Run the test android:test:scrollToElement

2 tests will be executed, one attempting to reach an element out of view on a FlatList, and a second one attempting to do the same but on a normal ScrollView.
Expected behavior
Detox successfully scrolls to the element that's out of view.
Detox Trace-Logs

Detox logs

[ (paste logs here)](https://gist.github.com/j320/0824d1b0224d7aec187144c3c8880cb7)

Device logs (adb logcat)

Device logs

FlatList test: https://gist.github.com/j320/f644fbd7ee1ea7d86b33b65beba66240
ScrollView test: https://gist.github.com/j320/1b604941c651a8f7d6469f8131b85115

Environment

Detox: 19.0.0
React Native: 0.62.2
OS: Android
Test-runner (select one): jest-circus

Facing same issue

There are a few issues here with the tests:

The children of the flatlist are 0-based, therefore the third element to the right will be image-2 and not image-3
The name of the child has to be unique in the hierarchy, therefore the children of listBackground should be changed to something like listBackgroundImage-${index} to avoid an error of 'matches multiple views'
The first test attempts to scroll right to find listBackground-3, however this list is vertically below so it should be changed to scroll 'down'
The second test attempts to scroll down to find the image, but the flatlist is horizontal, so it should be changed to scroll 'right'


mold: 0.9.6 -> 1.0.0

Motivation for this change
https://github.com/rui314/mold/releases/tag/v1.0.0
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Tested with clang12:
clang --ld-path=mold -o main main.c


[Copyright] Update all copyright headers

We need to update all copyright headers as they currently say "Copyright 2020 - 2022..." and 2022 is in the past.
Is the CSA alliance having any prescriptions here? If not:
@andreilitvin mentioned the C++ SDK has a policy to put newer copyright only in the files they newly add (or change?) BUT I do not understand this policy at all.
Copyright headers of all files - old or new always need to be up to date. Always. Not a lawyer, but pretty sure about that. Otherwise it would look as if the copyright of the old files had expired, which is just not the case.
Two options I can think of:

Periodically update (with regexp) the copyright headers by bumping up the ending year. I.e. it would become "Copyright 2020 - 2024" if we do it now.
(I prefer this) Change all headers to read "Copyright since 2020 - ", i.e. remove the ending year.

What to do with the beginning year? Also two options:

Option 1: I suggest - we just use the year when the new file "lands" in the repo. And don't touch it afterwards. I don't feel like going through all of them and changing the beginning year though, as that is a lot of pointless work
Option 2: Remove the beginning year as well. Why do we need it? It is anyway a copyright since the very existence of the file and until eternity (or until we decide otherwise). So the final message should just be "Copyright (c) Project Chip Authors"

@kedars ^^^

@andreilitvin are there any project-chip-wide policies that are being followed by other repos?

Copyright generally applies at the time of creation. The year clarifies when that creation occurred. Updating the copyright year generally occurs when new creative input was made.

Copyright generally applies at the time of creation. The year clarifies when that creation occurred. Updating the copyright year generally occurs when new creative input was made.

That aligns with my understanding too.
So @ivmarkov the option to choose would be to update the year after the - whenever the particular file is updated.

@kedars  OK just to confirm on 100%:

Year before - is only updated once - on file creation time
Year after - is updated each time the file is modified (and we hopefully don't forget that)

Right?

Let's start with: new files should have the current year (unless copied and pasted file content or rename).
Beyond that, I would like to reduce developer churn work as much as possible while still making lawyers happy. Currently I am not commenting on year changes on existing files, only remarked that if we create a new file we can add the current year.

Let's start with: new files should have the current year (unless copied and pasted file content or rename).
Beyond that, I would like to reduce developer churn work as much as possible while still making lawyers happy. Currently I am not commenting on year changes on existing files, only remarked that if we create a new file we can add the current year.

Here's a plan forward:

Don't ad-hoc change some headers (yet)
Do a regexp replace as follows, on everything:

Start year: 2022 (it is 2020 now). The earliest commit in the repo seems to be from Dec 12 2022. Or shall we just do 2023? @kedars Is it true that you guys started in 2022, or do I have it wrong and you've worked in another repo before that?
End year: 2024 (it is 2022 now). I think we have touched almost every file either in 2023 (when I did the no-std thing) or in 2024 anyway

After the change, follow what @andy31415 suggests: bump the beginning/end year for new files. We can also retro-actively apply this for some files that we do know popped up in 2024 - mostly in the reworked transport, as well as BTP

Here's a plan forward:

Sounds good to me

Start year: 2022 (it is 2020 now). The earliest commit in the repo seems to be from Dec 12 2022. Or shall we just do 2023? @kedars Is it true that you guys started in 2022, or do I have it wrong and you've worked in another repo before that?

Let's keep it as 2021, I was working on a personal repo since 2021. The initial commit to this repo squashed everything since then into a single commit


"Error: interfaceToColumnValue failed for column 'on_premises_net_bios_name': found X, expected number"

Using this query:
select * from azuread.azuread_group

returns this error:
Error: interfaceToColumnValue failed for column 'on_premises_net_bios_name': found X, expected number

v0.8.0
Plugin version (steampipe plugin list)
❯ steampipe plugin list
+--------------------------------------------------+---------+-------------+
| Name                                             | Version | Connections |
+--------------------------------------------------+---------+-------------+
| hub.steampipe.io/plugins/turbot/azure@latest     | 0.18.0  | azure       |
| hub.steampipe.io/plugins/turbot/azuread@latest   | 0.0.1   | azuread     |
| hub.steampipe.io/plugins/turbot/github@latest    | 0.6.0   | github      |
| hub.steampipe.io/plugins/turbot/steampipe@latest | 0.1.3   | steampipe

To reproduce
Execute the query shown above
Expected behavior
Expected to get a list of groups from our Azure AD

Thanks for reporting this @yooakim - really appreciate your feedback and testing - it's hard to find all the edges of these environments in small, demo environments!
I suspect the column type is wrong:
https://github.com/turbot/steampipe-plugin-azuread/blob/main/azuread/table_azuread_group.go#L61
We should be expecting a STRING, not a TIMESTAMP.


[DF-43] User login

User login

Authentication Module on /src/common/authentication
Database Exception on src/common/exception

this PR will deprecated if non active in Monday

this PR will deprecated if non active in Monday

in active

in active


Grunticon gets stuck 'Coloring SVGs' Task

I'm converting some 90+ svg files to different colors. If the number of colors (defined using the filename notation) exceeds about two then grunticon gets stuck in 'Coloring SVGs' task for indefinitely. I've checked 'Activity Monitor' and it shows a number of phantomjs instances, all complete unresponsive. While the same files with one or two color options work fine.
Any response/alternative to this will be highly appreciated. Thanks :)

@jefflembeck  can someone please look into it? Kind of stuck at something and needs to resolve it asap. Thanks :)

Patience, friend. @jefflembeck does a very good job maintaining this project and comments like this do little to help with the stress of open source! Please please please keep it positive—thanks!

Looking into this over here: https://github.com/filamentgroup/directory-colorfy/issues/15

Should be updated and fixed in 2.1.5


11ty isn't picking up all CSS changes

Something's not quite working with its watch mode. It might be easier to just Rollup's watch mode for everything and just call out to 11ty. I don't know if that costs us some optimisations.

Somewhat fixed in https://github.com/GoogleChrome/devsummit/pull/122