Support Svelte

Please add support for sveltejs , a short description for it would be it is the daddy of React, Angular and Vue as it has no virtual DOM, am requesting both Intellisense support and a plugin support for running monaco editor in svelte

Strongly support this!

also supported

I would absolutely love this

Any movement on this? This would be a bit of a game changer!

I was going to open the same issue. Can this help with the migration? https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode


Updated version to 1.0.7

Hello,
The latest version, v1.0.6, will not build for Android.
This issue was fixed in 9012443afed22d4267650a4a184d4fad879e8268, however a new release has not been cut.
Thanks,
Kyle

I'm forced to always take the head of this repo, because my package manager will only let me use named references.  Any chances someone could merge this one in and add the tag for me?  Or if you're willing to share write access I can do it.  Thanks :)

Thanks, @DMcNamara !

No problem, sorry it took so long.


Add items with multiple states, item activation cycles through them

This doesn't seem to be very useful at the moment. I'm closing the issue, with the possibility of reopening in the future.


Extension causes high cpu load

Issue Type: Performance
Extension Name: vscode-logicapps
Extension Version: 0.2.32
OS Version: Windows_NT x64 10.0.18363
VSCode version: 1.43.0

:warning: Make sure to attach this file from your home-directory:
:warning:C:\Users\ejordao\ms-azuretools.vscode-logicapps-unresponsive.cpuprofile.txt
Find more details here: https://github.com/microsoft/vscode/wiki/Explain-extension-causes-high-cpu-load

Can you please attach the .cpuprofile.txt file to this issue?  Thanks.

ms-azuretools.vscode-logicapps-unresponsive.cpuprofile.txt

Thank you for sharing this profiler data.  I will take a look at this as soon as I can.

I took a look at the CPU profiler data. The unresponsiveness is caused by having to load and compile a large number of scripts from the azure-arm-resource dependency. We can address this by switching from azure-arm-logic and azure-arm-resource to @azure/arm-logic and @azure/arm-resources, which solves the problem by bundling the scripts into one file.

Ok, I need to change my settings.json for this?

This is a code change which will require updating the extension to use the newer modules instead of the older ones.

Closing all the enhancement requests. v2 is the future of Logic Apps on Visual Studio Code.


🎮 Game Request
One need to click left and right in order to make the Tinker to jump as high as possible.
Point down the features
Game points
Select program in which you are contributing
No response
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

//assign

Hey @chakrabortydeep !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Hey @chakrabortydeep ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Further branding Changes

Make it possible to change:

the favicon
optionally remove/replace the Github link

I think we should start with just removing the GitHub link, but as Discover usage grows it would be good to replace with a link to where end users can submit issues like some kind of e-HelpDesk

I agree with Clay we should remove the github link for now

@claycrosby @engwiri
Can we get the favicon image?  You can upload it here

https://drive.google.com/open?id=1mBObUoe2ldbrGkQu1raAlPoQ_SSOGTeo

Seems not needed any more.


Add support for LocalAuthenticator

Circumvent Touch ID when implemented using LocalAuthentication framework

Cool! Didn't know anyone was looking using this. Thanks for taking the time!


Fix piwik statistics

Items submitted after 2020-05-15 show no views in the piwik-statistics tab (and the item submitted  on 2020-05-15 (ud 2.6) shows views only until may 29th)
For lindat repository the fix must happen in https://github.com/ufal/lindat_piwik_reports as we use that for caching the results.
I suspect the issue is there also for the "non-cached" version. I believe the underlying issue is an update to piwik >=3.12.0, which "fixes" the behavior of segments (https://github.com/matomo-org/matomo/issues/11900, also see https://forum.matomo.org/t/filter-page-urls-by-segments/34859/8 and especially https://forum.matomo.org/t/filter-page-urls-by-segments/34859/2). 3.12 was released in Nov 2019; not sure when we've updated
I believe this non-cached version should* at least return some numbers, however, these will be meaningless (as it would sum the hits/visits across a segment**, not just filtered to one item page).
* it takes a lot of time to produce the result, so it may actually timeout.
** ie. it will be the visits/hits of all the pages a user, who visited repository item page in question, has visited

Bitstream downloads include bots (this is probably due to #438, the user agent is not send by dspace).
The numbers displayed in dspace might be meaningless anyway; as the piwik config currently has datatable_archiving_maximum_rows_subtable_actions = 100, see https://matomo.org/faq/how-to/faq_54/, in essence this means that if the item is not popular enough in particular year/month/week/day they will be archived in 'other' slot and won't be in the api response; this also means you might get different total numbers based on the period (y/m/w/d) you ask for (on the year level the "competition" for the available slots is much higher than on the day level). Maybe https://github.com/ufal/lindat_piwik_reports was meant to solve that, but does it?


Working with decimal points is atypical

Hi,
i think the way how you work with decimal points in your library is a bit confusing and I try to explain this by a small sample:
How it is:
Entered value for 100 + click on decimal separator + 99 results in: 10,000.99
How it should be:
Entered value for 100 + click on decimal separator + 99 results in: 100.99
Your formatter seems always to add new values to the decimal points and shift the main number to the left instead. This behaviour is compared to normal calculators very atypical and hard to maintain is you want to correct a number input.
Tested on 2.1.5

@0xPixelfrost Thank you so much!
If you have any idea. Feel free to contribute.

locale BR not working, decimal Separator is space

@john182 Thank you for the issue.
I will check it this weekend.

@john182
Could you share your code?
for me it is working.

@0xPixelfrost current version direction is only rtl. so cursor will change to right end.
I will add direction property ltr. it might be work what you want.

Someone solved this problem? I need the pennies to be entered last


Shadow rendering

Dear all
We observed some misleading visual effects with the shadow rendering using the virtualcitysystems 3D Suite for urban planning and would like to open an issue ticket. Virtualcitysystems informed us, that they are using the Cesium version 79 in the software. I attached some shadow samples to the ticket. Also I would like to share the link to my initial post on the community forum.
On this map example you can try it for yourself. On the upper right corner you can click on the shadow function.
Is there some way to avoid these problems? You can encounter the false rendering manner in every perspective, while zooming and panning. We found an old post (https://community.cesium.com/t/3d-tiles-shadows/4289) aiming at the same issue.
Browser: Firefox 94.0.1 (64-Bit), Chrome 95.0.4638.69 (64-Bit), Edge 95.0.1020.44 (64-Bit)
Operating System: Windows 10, 64-bit, The 3D hardware acceleration on this computer is activated.
If you have any Ideas what we can do to avoid or fix these issues we would appreciate it a lot.
Kind regards and many thanks in advance for taking the time to investigate this issue.
Philippe

Thank you @stphil1!

@stphil1 For now there's no definite workaround for shadow map artifacts. But, some of them can be mitigated with the maximumDistance and size properties (see the ShadowMap docs).

@stphil1 I totally agree. I've got the same feedback regarding the shadow artefacts from hundreds of users. Unfortunately changing the parameters of  maximumDistance and size  works just for certain situations and isn't that satisfying at all. A more sustainable global solution would be the right one with which we woud be grateful. Please keep us updated regarding the issue :)
Best,
Tim

Dear all,
Is there an update on this matter?
As for now the shadow artefacts persist, creating rather unpleasant results:

The occurrence and severity of these artefacts seem to depend on the selected date and time as well as the camera angle and distance in the 3D-map.
We would be very pleased if you could prioritize this issue.
Many thanks and best regards,
Seraina

Dear Cesium Team,
can you please give an update on this issue? Currently, we have our user conference in Berlin and are talking with the community about this issue and wondering if there is any progress.
Thank's a lot in advance,
Best,
Tim


Added multiline_regex_begin option for multiline parsing

I have log lines from log4j that sometimes have random line that is not space so I needed more strict method for multiline parsing like multiline_regex_begin.

If I read this correctly, you're trying to implement an option where you can only match on a single line and have all other lines after it merge into the same event. This can already be done, for example here's a config for a mysql slow query log:
[/var/log/mysql/mysql-slow.log]
multiline_regex_after: (^#\sTime:\s)
multiline_regex_before: (.*)

Hello Jesse,
Your example won't work, here is simple code batch to test it out:
#!/usr/bin/env python

import pprint
import re
def multiline_merge(lines, current_event, re_after, re_before, re_begin):
    events = []
    for line in lines:
        if re_before and re_before.match(line):
            current_event.append(line)
        elif re_after and current_event and re_after.match(current_event[-1]):
            current_event.append(line)
        elif re_begin and not re_begin.match(line):
            current_event.append(line)
        else:
            if current_event:
                events.append('\n'.join(current_event))
            current_event.clear()
            current_event.append(line)

    return events

lines = [
"# Time: 150421 23:12:45",
"# User@Host: hello[hello2] @ localhost []",
"# Query_time: 1.123456  Lock_time: 0.000174 Rows_sent: 30  Rows_examined: 111",
"SET timestamp=142966000;",
"SELECT *",
"FROM some_table",
"WHERE something",
"# Time: 150421 23:16:48",
"# User@Host: hello[hello2] @ localhost []",
"# Query_time: 1.123456  Lock_time: 0.000174 Rows_sent: 30  Rows_examined: 111",
"SET timestamp=142966000;",
"SELECT *",
"FROM some_table",
"WHERE something"]

current_event = []
multiline_regex_before="(.*)"
multiline_regex_after="(^#\sTime:\s)"

res = multiline_merge(lines, current_event, re.compile(multiline_regex_after), re.compile(multiline_regex_before), None)
pprint.pprint( res )

It's possible to work, if you make a regex after that will match everything except timestamp on beginning. That kind of magic is possible but I don't won't to use it. Instead I opted for regex that would only tag some line as event beginning and code would guess that all other should be appended.
Correct me if I'm wrong :)

@XooR Well, I can't necessarily explain the details of why it works - but I can say that it does appear to work in the test environment I had setup to do so. It seems to effectively do what you've set out to achieve, but it's quite possible that it may not work for some edge cases which I haven't tried yet.

@XooR is this still needed? Can you provide a use case where multiline_regex_after and multiline_regex_before are insufficient?


feat: components for requirements and objectives

Description
Right now, we manually style the objectives and requirements as side-by-side for every lab overview. New components encapsulates this behaviour away from the writers.
Reviewer Notes
If there are links or steps needed to test this work, add them here.
Related Issue(s) / Ticket(s)
If there are any related GitHub Issues or JIRA tickets, add links to them here.

issue

Screenshot(s)
If relevant, add screenshots here.
Use Conventional Commits
Please help the maintainers by leveraging the following conventional commit
standards in your pull request title and commit messages.
Use chore

for minor changes / additions / corrections to content.
for minor changes / additions / corrections to images.
for minor non-functional changes / additions to github actions, github templates, package or config updates, etc

git commit -m "chore: adjusting config and content"

Use fix

for minor functional corrections to code.

git commit -m "fix: typo and prop error in the code of conduct"

Use feat

for major functional changes or additions to code.

git commit -m "feat(media): creating a video landing page"

@kisielewskik Sorry for the delay on reviewing this PR, but I noticed there is now a conflict, could you resolve that, and I wanted to confirm if this was something you still had interest in us merging in?

@jpvajda Hello, i resolved conflict :) pleas merge it. This changes are requested by @alexronquillo.


Enable one-time bindings in PolymerExpressions

 Issue by justinfagnani
Originally opened as dart-lang/sdk#19218

[[ ]] bindings don't need to observe the model. This should give us a big performance boost.

 Comment by justinfagnani

Added Fixed label.

 Comment by justinfagnani

Fixed in https://codereview.chromium.org/313243003/


Hello, may I use regular expressions to ignore files or directories

Hello, may I use regular expressions to ignore files or directories

Hello, @zdwork.
Apparently, no, you can't use regular expressions as of now.
Right now the list of strings to be ignored are split and treated as literal strings - as you can see here. And then the paths are also used are literal strings, as seen here.
But I do think it could be useful to use regexes to ignore files.


LZ4 libraries being generated in Temp folder

The three libraries being generated dynamically in Temp folder - lz4cc, lz4pn and lz4mm - are being flagged as a potential risk by AppSense in Citrix environment. This causes our application to crash because having libraries in Temp folder is not allowed. Is it possible to package lz4net as a set of four assemblies, instead of one assembly dynamically generating assemblies in temp folder? We can have these assemblies included in our installion folder and certified by AppSense, avoiding the crash

Please note, this problem does not exist in K4os.Compression.LZ4. Please use new library.


Read stats.json from DB

It's would be really nice to have option to "upload" stats.json to project db, to avoid deploying static file to multiple servers.
We have multiple servers and want to avoid removing server from production for updating stats.json file w/ RPM (our deploy).

I deploy my production builds to a CDN, with a version I'd like to be able to just specify the version, and load the stats file from a known location on the CDN. The stats file can be configured to use a CDN location as the file location, so everything just loads from CDN, based on the 'version'.
The Version can be specified in the main configuration or the .env files

@kutenai like that?
WEBPACK_LOADER = {
    'DEFAULT': {
        'STATS_FILE': 'https://foo.aws3.com/bar/assets/webpack-stats.json'
    }
}

yes, something like that would work, but when I look at the current code (or, current version I have), it just uses the open method, which I don't think supports a url?
    def _load_assets(self):
        try:
            with open(self.config['STATS_FILE'], encoding="utf-8") as f:
                return json.load(f)

The code is in webpack_loader.loader.py

Yes, that's why I open this issue.
Also, having hashes in file on disk looks wrong for me.

Currently we don't support opening stats files from network and probably never will but I'm open to making the loader class more extensible so we can write simple plugins to load from anywhere. Would be great if someone comes up with the design of how it would work here.


Proposal: Drop legacy React support.

With the upcoming major release, we have the opportunity to drop support for old versions of React.
Currently, we support React 15+. In an ideal world, I would like to support only React 16.3+ because that is the release where the new Context API is introduced. At the moment, I'm having to use the clunky legacy context API. I could use the new 16.3 Context API with a polyfill (create-react-context) but want to avoid integrating that large package into the bundle if possible. So there are two options:
Option 1: Drop out-of-the-box support for React <16.3 but expose an API to patch it.
On the user's end, it would look like this:
/*
 * COPY + PASTE WARNING!!
 * This is a *proposal*, not real copy+pasteable code.
*/
import { patch } from 'react-accessible-accordion';
import createContext from 'create-react-context';

patch({ createContext });

Option 2: Drop out of the box support for React <16.3 and direct users to a pinned (2.X) version of react-accessible-accordion).
After all, 2.X is pretty stable - so we could just instruct legacy React users (in our README) to use it instead.

I'm leaning toward Option #2, but I'm interested in seeing some statistics on React version usage to help justify dropping support as far as 16.3!

Implemented on next branch. Watch here and here to track progress of the associated upcoming release.


Add DB metrics charts

Motivation
Add charts for https://github.com/ChainSafe/lodestar/pull/2741
Description
Last row in dashboard. Charts below are from Prater

Zoom in chart, clearly we are doing a lot of reads at epoch boundaries

Below with delta() function it shows the absolute value difference between scrapes. We read 2000-4000 blocks. Are the metrics right? Is our archiving function inefficient?


Change TeamAcceptInviteOrRequestAccess to return more info

cc @buoyad

I'll merge this after trying to launch gui from this branch to see if nothing broke

I'm going to borrow this branch

Changes:

downcase seitan tokens (ikeys) on the way in.
Change error handling to allow requesting access to 16 character teams. Which now unlocks further unpleasantness of sending the ikey up.

@mlsteele good catch about 16-character teams. thanks


Added environment wrapper for shortlimitholdem

It looks like ShortlimitholdemEnv is a copy of LimitholdemEnv, with the only difference being its name. It would make sense that ShortlimitholdemEnv inherits LimitholdemEnv. That way, the only change you would need is to make sure ShortlimitholdemEnv.name is 'short-limit-holdem'.
This will also be helpful for the incoming encoding changes in issue #11 as they effect how the _extract_state logic works.

Yeah that makes a lot more sense, I was just trying to hack something to make it work and wasn't really thinking. Let me clean this up.


System.Net.Http.UnsupportedMediaTypeException

Sometimes bot stops to response, and in log is the error:
Telegram.Bot.Exceptions.ApiRequestException: Invalid response received ---> System.Net.Http.UnsupportedMediaTypeException: No MediaTypeFormatter is available to read an object of type 'ApiResponse`1' from content with media type 'text/html'.
   at System.Net.Http.HttpContentExtensions.ReadAsAsync[T](HttpContent content, Type type, IEnumerable`1 formatters, IFormatterLogger formatterLogger, CancellationToken cancellationToken)
   at System.Net.Http.HttpContentExtensions.ReadAsAsync[T](HttpContent content, IEnumerable`1 formatters, CancellationToken cancellationToken)
   at System.Net.Http.HttpContentExtensions.ReadAsAsync[T](HttpContent content, CancellationToken cancellationToken)
   at Telegram.Bot.TelegramBotClient.<SendWebRequestAsync>d__139`1.MoveNext()
   --- End of inner exception stack trace ---
   at Telegram.Bot.TelegramBotClient.<SendWebRequestAsync>d__139`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Telegram.Bot.TelegramBotClient.<ReceiveAsync>d__68.MoveNext()

So it seems that Telegram server returns the answer that library can not parse. Is it possible to output the server response that causes this problem?

Very actually! I have this problem too.

Errors happen sometimes while waiting a reply from the server, it would be good to log the data sent by the server when that happens to reproduce it for your specific case.
In my code I do a stop, a delay and a start. As far as I know I've never lost a message send by the user:
this.bot.OnReceiveError += (sender, args) => this.HandleError(args.ApiRequestException, args.ApiRequestException.ErrorCode);

private async void HandleError(Exception ex, int error)
{
            if (error != 408)
            {
                // Only delay if there was no timeout
                await Task.Delay(this.retryConnectionTime);
            }

            this.bot.StartReceiving();
}

Notice that if there is a network disconnection probably your application crashes, as described here #143
And solved here #217 waiting for a merge to master.

Are there steps to reproduce this issue?
Kind regards,
Martijn Verbakel

CristianT, yes, it would be good to log the response from server, bur question was how to do that. Where are located these data in ApiRequestException? What property if the exception object should I log?

If you can compile and use the binaries from this branch:
https://github.com/CristianT/telegram.bot/tree/ParametersLog
Or use the binary I compiled: https://www.dropbox.com/s/6ah1r59qardwbgk/Telegram.Bot.zip?dl=0
When you run it, a file "telegramBot.log" will be written in the working directory with information about parameters where I think is the issue. That may help finding the problem.

CristianT, bot that uses this compiled version of library crashes with exception "Object reference not set to an instance of an object." at line
var me = Bot.GetMeAsync().Result;

If you could debug the code to know what is happening it would be great.
Otherwise we need some defined steps to reproduce the issue (the original one) more accurately so we can know what is happening.

The original issue happens seldom (and in release version published on server). And to understand its cause I must to see response of server.
About your branch. I can't compile the code on my computer because of C# versions diffrence. But as I can see, there are no null-checks for 'parameters', and I think there is the cause of "Object reference not set to an instance of an object." exception.

OK, I tried to correct the binary, haven't tested it though:
https://www.dropbox.com/s/37u86x4bcuewll5/Telegram.Bot.zip?dl=0

In each send request log is created anew. Old info will be lost :(
Also, has it sense to log parameters at begin of each request process? As I said, the original error happens seldom (one time in several days) and log will be very long.

ok this time I had some time to test it:
https://www.dropbox.com/s/x1b1v27h3cnmnqm/Telegram.Bot.zip?dl=0
if you want to catch the error there are not a lot of options, at least I don't know where the problem is.
The file should only log data sent so depending on the volume of your bot it may not be that much.
If you catch the error and post the relevant lines of the file here, may be someone could help you

I've recompiled the library from source with my logging and now i'm waiting that error happens in log. When I have new information, I'll post it here.


[Flaky test] EnqueueEventAsyncEnqueuesForAutomaticRouting

EnqueueEventAsyncEnqueuesForAutomaticRouting

Result Details
Failed Yesterday on 0989f368c000000
Duration0:05:00.100
Ownernot available
Date started11/17/2021, 4:33:10 PM
Date completed11/17/2021, 4:38:10 PM
Failing sinceYesterday
Failing since build20211117.4

Debug

Work items

Attachments

History

Attachments*

Error message
System.OperationCanceledException : The operation was canceled.

Stack trace
   at System.Threading.CancellationToken.ThrowOperationCanceledException()
   at Azure.Messaging.EventHubs.Tests.EventHubBufferedProducerClientTests.<EnqueueEventAsyncEnqueuesForAutomaticRouting>d__87.MoveNext() in D:\a\_work\1\s\sdk\eventhub\Azure.Messaging.EventHubs\tests\Producer\EventHubBufferedProducerClientTests.cs:line 2609
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Azure.Messaging.EventHubs.Tests.EventHubBufferedProducerClientTests.<EnqueueEventAsyncEnqueuesForAutomaticRouting>d__87.MoveNext() in D:\a\_work\1\s\sdk\eventhub\Azure.Messaging.EventHubs\tests\Producer\EventHubBufferedProducerClientTests.cs:line 2616
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
   at NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter awaiter)
   at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
   at NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext context)
   at NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext context)
   at NUnit.Framework.Internal.Execution.SimpleWorkItem.<>c__DisplayClass4_0.<PerformWork>b__0()
   at NUnit.Framework.Internal.ContextUtils.<>c__DisplayClass1_0`1.<DoIsolated>b__0(Object _)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at NUnit.Framework.Internal.ContextUtils.DoIsolated(ContextCallback callback, Object state)
   at NUnit.Framework.Internal.ContextUtils.DoIsolated[T](Func`1 func)
   at NUnit.Framework.Internal.Execution.SimpleWorkItem.PerformWork()

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1201057&view=ms.vss-test-web.build-test-results-tab&runId=25868902&resultId=105940&paneView=debug

Should be fixed by #25346, which got merged after this test run.   I'm going to close this out for now, please let me know if you see it continue to be flaky.

Still flaky https://dev.azure.com/azure-sdk/public/_build/results?buildId=1202428&view=ms.vss-test-web.build-test-results-tab&runId=25890446&resultId=101832&paneView=debug

I think it's really fixed for real now.


Description sorting is not case sensitive

Currently task description sorting is not case sensitive, but the intended behaviour is for it to be case sensitive.
Note that the other alphabetical sortings in contacts are case sensitive, so for consistency, either those should be case insensitive, or task alphabetical sorting should be case sensitive.

Fixed in #265


On how to specify the azhpc-images when allocating new VM

Because I have the same issue with 28, how do I specify the Canonical version VM? Or If I want the centos 8.1, how do I specify it when allocating the VM.
When I set OpenLogic:CentOS-HPC:8_1-gen2:latest there, it comes with the error

Platform Image id /subscriptions/f4b71ca8-2442-461d-ba11-c2b5bcb828cc/providers/Microsoft.Compute/locations/southcentralus/publishers/OpenLogic/artifacttypes/vmimage/offers/CentoOS-HPC/skus/8_1-gen2/versions/latest is invalid or does not exist

sorry, Make a reboot solve the problem.


Please merge revision 6bf86eacd7db5a4c183ec4ba006587c6d079c94d into dev channel

@whesse @mit-mit @kasperl
Bug: https://github.com/dart-lang/sdk/issues/23924
Commit: https://github.com/dart-lang/sdk/commit/6bf86eacd7db5a4c183ec4ba006587c6d079c94d

Merged in version 1.21.0-dev.11.2


chore: update listr2 version

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.
[x] The changes are appropriately documented (if applicable).
[x] The changes have sufficient test coverage (if applicable).
[x] The testsuite passes successfully on my local machine (if applicable).

Summarize your changes:
This PR updates the listr2 dependency such that the default renderer used in TTY environments will dump any output written to stdout and stderror at the end of a forge run. This was added as default behavior in listr2 after the current version we're using, so I figured I'd migrate us to the most recent stable release.
Some callouts here are:

Listr2 changed the default fallback renderer from verbose to simple. This means that when using the DEBUG environment variable, the output looks a little different
Previous

New

Logged content is not colocated with the Listr tasks that logged it, so it can be unclear where logged content is coming from. I think this is ok because authors can always add more details to the logged message itself to make this more clear (ie if console.logging from the generateAssets hook, prepend logged messages with [generateAssets] string).

Documentation PR: https://github.com/electron-forge/electron-forge-docs/pull/168
Testing example:
forge.config
hooks: {
    async generateAssets(_config, _platform, arch) {
      console.log('hello world');
      console.log(arch);
    }
  }

Output
yarn make                                                                                ─╯
yarn run v1.22.21
$ electron-forge make
✔ Checking your system
✔ Loading configuration
✔ Resolving make targets
› Making for the following targets:
✔ Running package command
✔ Preparing to package application
✔ Running packaging hooks
  ✔ Running generateAssets hook
    ✔ Running generateAssets hook from forgeConfig
  ✔ Running prePackage hook
✔ Packaging application
  ✔ Packaging for arm64 on darwin [2s]
✔ Running postPackage hook
✔ Running preMake hook
✔ Making distributables
✔ Making a zip distributable for darwin/arm64 [6s]
✔ Running postMake hook
› Artifacts available at: /Users/anny/code/opensource/my-app/out/make

hello world
arm64
✨  Done in 10.50s.

Test 2:
forge.config (built w webpack template)
packagerConfig: {
    asar: true,
    ignore: []
  },

Output
yarn make                                                                                ─╯
yarn run v1.22.21
$ electron-forge make
✔ Checking your system
✔ Loading configuration
✔ Resolving make targets
  › Making for the following targets:
✔ Running package command
  ✔ Preparing to package application
  ✔ Running packaging hooks
    ✔ Running generateAssets hook
    ✔ Running prePackage hook
      ✔ [plugin-webpack] Preparing webpack bundles
        ✔ Preparing native dependencies [0.2s]
        ✔ Building webpack bundles [0.7s]
  ✔ Packaging application
    ✔ Packaging for arm64 on darwin [1s]
  ✔ Running postPackage hook
✔ Running preMake hook
✔ Making distributables
  ✔ Making a zip distributable for darwin/arm64 [6s]
✔ Running postMake hook
  › Artifacts available at: /Users/anny/code/opensource/my-app/out/make

You have set packagerConfig.ignore, the Electron Forge webpack plugin normally sets this automatically.

Your packaged app may be larger than expected if you dont ignore everything other than the '.webpack' folder
You have set packagerConfig.ignore, the Electron Forge webpack plugin normally sets this automatically.

Your packaged app may be larger than expected if you dont ignore everything other than the '.webpack' folder
✨  Done in 10.55s.

Hi @yangannyx. I noticed that the output of the "test" command in CI is incorrect. Is it related to the current changes?

@BlackHole1 Yes, this definitely looks related to the changes in this PR. Taking a quick look, I'm seeing Listr printing output character by character in linux and mac on CI runs in this PR only. Going to investigate if there's any evidence that other Listr consumers are running into this issue

Hey @BlackHole1, was able to take a look here. It looks like after upgrading Listr, the default TTY renderer causes the newline outputs in CI. Since CI isn't a TTY environment, the fix here was to fallback to the non-TTY simple renderer when the CI env variable is on.

Makes sense! Happy to add to cut a new PR to move these Listr option defaults into @electron-forge/core-utils but don't want to over bloat this PR for now 👍


Fix relative symlinks

Fixes #100

I based this PR on Schoonology's fix (PR #235), removing the warning that is displayed when a symbolic link is created.

@freitagbr Could you check that this works under node v0.10? It seems to be failing on the CI.

Also, would you be able to squash the commits? See here

The Node.js v0.10 path module does not have the isAbsolute method (it was added in Node v0.11). That is what is causing the build to fail.

The usual method we use is to  check for its existence, and if it doesn't exist, use a workaround. Would that be feasible?

As long as the source string does not start with a /, it is absolute. Simply checking source.indexOf('/') !== 0 should do the same thing, correct?

Will that play well with Windows? I think that should be sufficient for *nix though (unless ~ is supported)

This should work as intended, though ~ is still not supported. It is trivial to add support, and I think it would be worthwhile. Thoughts?

I'm working on a PR for the tilde (currently unsupported), but there are some other big changes I want to get merged first. So don't add support for it just yet. Once we do, we'll have to add an "is absolute path" method that handles the tilde

Could you also add some invalid test cases toward the top?
# symlinks
mkdir -p tmp/
touch tmp/file1.txt
ln -sf tmp/file1.txt tmp/file2.txt
# make sure there was an error

mkdir -p tmp/
touch file1.txt
ln -sf file1.txt tmp/file2.txt
# make sure there was an error

# hardlinks
mkdir -p tmp/
touch tmp/file1.txt
ln -f file1.txt tmp/file2.txt
# make sure there was an error

@freitagbr: Any chance I could ask you to add the small changes? I'd really like to include this in the next release. Thanks!

@ariporad Will do! I'll have this done by the end of the day.

:+1: @freitagbr just ping this thread when you have the tests merged in and I'll review

@freitagbr: Thanks, but no rush!
Ari
On Sun, Jan 24, 2016 at 2:41 PM, Nate Fischer<EMAIL_ADDRESS>wrote:

[image: :+1:] @freitagbr https://github.com/freitagbr just ping this
thread when you have the tests merged in and I'll review
—
Reply to this email directly or view it on GitHub
https://github.com/shelljs/shelljs/pull/282#issuecomment-174348876.

@freitagbr then my only other comment is the invalid test cases (https://github.com/shelljs/shelljs/pull/282#issuecomment-174239702). Once those are in, this'll be good!

@freitagbr nice work!
LGTM

LGTM!

:+1:


Add common labels into alert definitions

We want to be able to list all kubevirt alerts so we added labels to
differentiate them.
Signed-off-by: assafad<EMAIL_ADDRESS>Release note:

Added common labels into alert definitions

/hold

@sradco Can you please review this PR?

/ok-to-test

/lgtm

/lgtm

/retest

/retest

/retest

/retest

/unhold

/lgtm

@sradco, @zcahana Can you please review it again?

/retest

I believe the review and discussions have been converged.
/approve
/lgtm

@assafad feel free to /unhold when you see fit.

/unhold


fix from_list bugs

Added some tests as i could not create a series with u64 value
s = Series.from_list([9_223_372_036_854_775_807, 9_223_372_036_854_775_806, 9_223_372_036_854_775_808], dtype: {:s, 32}) # error

s = Series.from_list([9_223_372_036_854_775_808]) # inferred as s64 and fails

s = Series.from_list([1, 2, 3, 9_223_372_036_854_775_808]) # mismatch s64 and u64

s = Series.from_list([9_223_372_036_854_775_808, 1, 2, 3]) # mismatch u64 and s64

s = Series.from_list([1, 2, 3], dtype: {:u, 64}) # as u64 fails

s = Series.from_list([-1, 2, 3], dtype: {:u, 64})

Finished in 6.2 seconds (6.2s async, 0.00s sync)
577 doctests, 1389 tests, 17 failures, 18 excluded, 1 skipped

https://github.com/elixir-explorer/explorer/actions/runs/7566406181/job/20603730541?pr=826

In my opinion, we should continue inferring those cases as s64 and continue raising if we overflow or underflow the dtype. The improvement we could do is to improve the error message.
The conversion to u64, s64, etc happens inside Rustler and I am not sure if Rustler let's us customize the error message.
@philss, do you know if we can customize the "argument error" bits here?
iex(1)> series = Explorer.Series.from_list([[1, 9_223_372_036_854_775_808]])
** (ArgumentError) argument error
    (explorer 0.8.0-dev) Explorer.PolarsBackend.Native.s_from_list_s64("", [1,<PHONE_NUMBER>854775808])

In case we cannot, I would wrap "Explorer.PolarsBackend.Shared.from_list" into a try/rescue ArgumentError and raise a better message there.

Btw, s = Series.from_list([1, 2, 3], dtype: {:u, 64}) # as u64 fails works for me (and it seems it works on CI too).

https://hexdocs.pm/explorer/Explorer.Series.html#from_list/2

:dtype - Cast the series to a given :dtype. By default this is nil, which means that Explorer will infer the type from the values in the list.

I have established the base line of  what is not working scenarios in https://github.com/elixir-explorer/explorer/actions/runs/7570277474/job/20615312348
from_list/2 does not handle u64 and dtypes  {:s, _} and {:u, _} well.
In this PR, I have attempted to address the below:

dtype is inferred properly especially {:u, 64}
descriptive error is thrown in case it fails.

Please review - I am pretty sure there is room for improvement . Also take a stab at it improving the PR. I can learn more if you can attempt to improvise thing by seeing how others do it in a better way.
I have tested these scenarios in Polars and it handles well - either it throws descriptive error, or creates series as expected.

As per above, I don’t think we should infer u64. Operations such as subtract can be confusing, especially coming from Elixir, and it should always be opt-in. For the cases listed here, we should improve the error message. I would not change the inference code.

I also think doing additional traversals on the list will be expensive. Hence my suggestion of wrapping around the calls to Rust. :)

@lkarthee I had the same temptation but I think @josevalim is right: we should keep the inference code as is.
We could follow the pattern you've established where we infer the "minimal" type that can represent the integers given to from_list. But the problem is that many operations are not closed under those types. Unsigned subtraction (as mentioned), but even addition: U8 + U8 is very likely to result in an overflow.
Also I got the following in Polars:

https://www.rustexplorer.com/b/psb7pj

let s1 = Series::new("s1", [1, 2]);
// shape: (2,)
// Series: 's1' [i32]
// [
// 	1
// 	2
// ]

So it looks like they too infer signed integers by default (their i32 is our s32).

Multiple parts to the story:

majority of new tests which are failing should pass (even with modifications) in explorer.
descriptive error which don't look like crashes.
from_lists/2 anything relating to {:u, 64} data type exclusive values results in error.
Inference of types - when dtype is nil.
Are we going to change existing behaviour which is documented about inference when dtype is nil, even though it might be broken . This might be a deviation from polars, we have deviated before.
Preferred type merging with inference type.

All code snippets are using  explorer/main SHA - 62e77160ec37445be47288b8bcf341dc1d96821e
from_list/2 bug in depth
1. Loss of information
Loss of information without any warning - -1 to nil. I suspect it has something to do with rustler (might be wrong). One thing to note is the numbers are {:s , 64} not valid or exclusive {:u 64} numbers.
alias Explorer.Series
Series.from_list([-1, 9_223_372_036_854_775_801], dtype: {:u, 64})
#Explorer.Series<
  Polars[2]
  u64 [nil,<PHONE_NUMBER>854775801]
>

2. Cannot create {:u, 64}, list of {:u, 64} and struct of {:u, 64}
Now let's pass atleast the values in range and attempt to create {:u, 64} series. It is invoking rustler func which accepts only s64 hence the error.
Series.from_list([1, 9_223_372_036_854_775_809], dtype: {:u, 64}).
** (ArgumentError) argument error
    (explorer 0.8.0-dev) Explorer.PolarsBackend.Native.s_from_list_s64("", [1,<PHONE_NUMBER>854775809])
    (explorer 0.8.0-dev) lib/explorer/polars_backend/series.ex:24: Explorer.PolarsBackend.Series.from_list/2
    (explorer 0.8.0-dev) lib/explorer/series.ex:387: Explorer.Series.from_list/2
    #cell:phle4en4dbmtgjco:1: (file)

Let's attempt to create a {:list, {:u, 64}}.
series = Series.from_list([[1], [9_223_372_036_854_775_809]], dtype: {:list, {:u, 64}})
** (ArgumentError) argument error
    (explorer 0.8.0-dev) Explorer.PolarsBackend.Native.s_from_list_s64("", [9223372036854775809])
    (elixir 1.15.7) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (elixir 1.15.7) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (explorer 0.8.0-dev) lib/explorer/polars_backend/shared.ex:114: Explorer.PolarsBackend.Shared.from_list/3
    (explorer 0.8.0-dev) lib/explorer/polars_backend/series.ex:24: Explorer.PolarsBackend.Series.from_list/2
    (explorer 0.8.0-dev) lib/explorer/series.ex:387: Explorer.Series.from_list/2
    #cell:aqfn6tqdn2be45yv:1: (file)

Lets attempt to create a struct with field of u64 using dtype {:struct, %{"a" => {:list, {:u, 64}}}}.
Series.from_list([%{"a" => [1]}, %{"a" => [9_223_372_036_854_775_809]}], dtype: {:struct, %{"a" => {:list, {:u, 64}}}})
** (ArgumentError) argument error
    (explorer 0.8.0-dev) Explorer.PolarsBackend.Native.s_from_list_s64("a", [9223372036854775809])
    (elixir 1.15.7) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (elixir 1.15.7) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (explorer 0.8.0-dev) lib/explorer/polars_backend/shared.ex:114: Explorer.PolarsBackend.Shared.from_list/3
    (explorer 0.8.0-dev) lib/explorer/polars_backend/shared.ex:126: anonymous fn/3 in Explorer.PolarsBackend.Shared.from_list/3
    (stdlib 5.1.1) maps.erl:416: :maps.fold_1/4
    (explorer 0.8.0-dev) lib/explorer/polars_backend/shared.ex:123: Explorer.PolarsBackend.Shared.from_list/3
    #cell:qcjmwzxpdlnvdsd4:1: (file)

3. Descriptive Error messages
Lets try to pass a wrong data type as dtype - instead of {:list, {:s, 8}}, pass {:s , 8}. Cryptic Polars Error.
series = Series.from_list([[1], [2]], dtype: {:s, 8})
** (RuntimeError) Polars Error: cannot cast List type (inner: 'Int64', to: 'Int8')
    (explorer 0.8.0-dev) lib/explorer/polars_backend/shared.ex:26: Explorer.PolarsBackend.Shared.apply_series/3
    #cell:7kssor3tml27to2y:1: (file)

Py Polars I get below
pl.Series([[1], [2]], dtype = pl.Int8)
... long stack trace omitted  but  has descriptive error message relating to problem.
TypeError: 'list' object cannot be interpreted as an integer

4. Inference
This is a documented behaviour in docs.  If we are changing it - documentation should be updated about divergence.
I feel the docs are correct and divergence is not needed. Let's look at the fix in PR  w.r.to inference. We are already iterating the list and if there was an integer we assume it is {:s, 64}.  I have changed it to return 3 tuples:

{:s, 64} for range 0 to 2**63-1
{:s, -64} if list contains negative integers
{:u, 64} if list has values greater than 2 ** 63 to 2 ** 64

Then normalized {:s, -64} to {:s, 64}. This is all I did w.r.to Inference. We can may be quantify overhead (using benchmarks)  approx 10 additional comparisons. These kick in only w.r.to integers.
5. Merge Preferred type
Even with explicit dtype: {:u, 64}, from_list/2 is failing or we are losing information. We are using previous information [{:s, 64}, {:s, -64}, {:u, 64}] to check valid ranges of various integers. Only for {:struct, } we are creating additional data - I am sure you can find some solution here. Rest all cases we are iterating list again. In some cases it just raises immediately like {:u, 64} to any thing other than {:U, 64}. This overhead only for cases of integers.
6. Additional tests
Current tests are inadequate as CI is passing. I have thoroughly tested add new test cases. What ever solution/fix may be majority of the test cases are valid tests. There may be modifications to error messages, but rest should pass. We can address what needs to be merged after a resolution or fix is finalised.
TLDR:
My take on it:

descriptive error messages are important. It will be very frustrating for users to figure out things and wasting time. How we are going to achieve it is an open question. This PR is not the only way.
merge preferred dtype with inferred dtype has some overhead especially w.r.to structs.
we can have a flag to disable merge preferred dtype validations.
we can defer structs  validations to polars errors
inference changes don't add much overhead and enable us to infer {:u, 64}
may be we should run benchmarks on how much overhead we are adding
majority test cases are very much valid
docs should be updated if we are diverging from documented behaviour
Py polars are doing it - should we look into how they are doing it ?

@lkarthee I'm totally with you when it comes to docs, error messages, and tests. The only part of this that's tripping me up is the change to the inference code. It's not about overhead, but ergonomics.
The stance we're taking is that :s64 is the most ergonomic integer dtype to infer. If you infer a list [1, 2, 3] as having that dtype, you can do most addition and subtraction operations without worrying about overflow. And because you can supply a more specific dtype if you need to, this seems like a reasonable trade-off. Without it, users would regularly experience overflow gotchas.
For the specifics:

Loss of information
[-1, 1] |> Series.from_list(dtype: :u8) |> Series.to_list() #=> [nil, 1]

I think this is the expected behavior. Is it documented as being different elsewhere?

Cannot create {:u, 64}, list of {:u, 64} and struct of {:u, 64}
Series.from_list([2**63], dtype: {:u, 64}) #=> raises

etc. ought to work. This does seem like a bug!

Descriptive Error messages
I agree we should have better error messages.

Inference
See above.

Merge Preferred type
No opinion yet. Will need to see the code after reverting the inference changes.

Additional tests
We should definitely add tests for the bugs. Though any which test the change to the inference code will need to be dropped.

@lkarthee I'm totally with you when it comes to docs, error messages, and tests.

Thank you @billylanchantin sharing your view and for reading such a long post - I made a mistake of pushing tests before writing cover. Perhaps that caused confusion. Even this PR is complex. I tend not mix multiple things, but I could not scope it any lesser.

The only part of this that's tripping me up is the change to the inference code. It's not about overhead, but ergonomics.

Just to be clear - We are still defaulting to {:s, 64} unless we have a {:u, 64} value in list. We are not going into subtypes of :s or :u. There won't be inference of {s, 8} when dtype is not passed.

Loss of information

[-1, 1] |> Series.from_list(dtype: :u8) |> Series.to_list() #=> [nil, 1]

I think this is the expected behavior. Is it documented as being different elsewhere?
https://hexdocs.pm/explorer/Explorer.Series.html#module-creating-series

The list must consist of a single data type and nils.

Option :dtype documentation.

:dtype - Cast the series to a given :dtype. By default this is nil, which means that Explorer will infer the type from the values in the list.

There is no word of defaulting to s64. It says it will infer - gives example of integers, floats, etc.
At the bottom of section it says:

Mixing non-numeric data types will raise an ArgumentError:
Explorer.Series.from_list([1, "a"])
** (ArgumentError) the value "a" does not match the inferred series dtype :integer

The precedent here is error w.r.to incompatible values not silent cast to nil.
Integer split to subtypes is not yet released (if I am not wrong).
We can look at Py Polars behaviour.
pl.Series([-1,1], dtype=pl.UInt8)
# throws incompatible types error.

I had personally faced a scenario where dates were not parsed - https://github.com/elixir-explorer/explorer/issues/566#issuecomment-1546508171 .
It's very frustrating when things fail silently.
If data is wrong or I am using wrong type, I want it to fail with a big error. Else what is the point having types?

Since there are many bugs here, we should probably try to fix them individually instead of all at once.
As a starter, I would look into:

[-1, 1] |> Series.from_list(dtype: :u8) |> Series.to_list() #=> [nil, 1]

The above should raise. It doesn't need to raise something good for now but it should raise.

Series.from_list([2**63], dtype: {:u, 64})

This should not raise.

There is no word of defaulting to s64. It says it will infer - gives example of integers, floats, etc.

Yeah, that's because s64 is new. We should say a list of integers are always inferred as s64. A list of floats (and integers) is always f64 by default.

Series.from_list([2**63], dtype: {:u, 64})

I have pushed a fix for this. Now it works accordingly. :)

Yeah, that's because s64 is new. We should say a list of integers are always inferred as s64. A list of floats (and integers) is always f64 by default.

Fixed in main too.

I have changed the pr to add strict flag to raise if there is an overflow or underflow. Py Polars has similar flag.
Default integer is still {:s, 64}.
If strict is false, which is default - there is no performance impact.
Just to be clear  - earlier implementation is scrapped. There is no merge logic. Only iterate list once which was already being done. No copy, no multiple iterations.
Currently overflow and underflow can occur.
Series.from_list([0, 256], dtype: {:u, 8})
#Explorer.Series<
  Polars[2]
  u8 [0, 0]
>

Benchmark script & results
datetime = DateTime.utc_now()
seed = DateTime.to_unix(datetime)
key = Nx.Random.key(seed)

{randints, _new_key} = Nx.Random.randint(key, -2**63, 2**63-1, shape: {100, 1000}, type: :s64)
list_1k = Nx.to_list(randints)

Benchee.run(
  %{
    "1_b_100x1000" => fn -> Enum.map(list_1k, fn x -> Explorer.Series.from_list(x) end) end,
    "3_d_100x1000_s64" => fn -> Enum.map(list_1k, fn x -> Explorer.Series.from_list(x, dtype: {:s, 64}) end) end,

    "2_b_100x1000_main" => fn -> Enum.map(list_1k, fn x -> Explorer.Series.from_list(x, old: true) end) end,
    "4_d_100x1000_s64_main" => fn -> Enum.map(list_1k, fn x -> Explorer.Series.from_list(x, dtype: {:s, 64}, old: true) end) end,

    "5_b_100x1000_strict" => fn -> Enum.map(list_1k, fn x -> Explorer.Series.from_list(x, strict: true) end) end,
    "6_d_100x1000_s64_strict" => fn -> Enum.map(list_1k, fn x -> Explorer.Series.from_list(x, dtype: {:s, 64}, strict: true) end) end,
  }
)

Here are the results. Don't see any abnormal increase in time.
Operating System: macOS
CPU Information: Apple M1 Pro
Number of Available Cores: 10
Available memory: 16 GB
Elixir 1.15.7
Erlang 26.1.2
JIT enabled: true

Benchmark suite executing with the following configuration:
warmup: 2 s
time: 5 s
memory time: 0 ns
reduction time: 0 ns
parallel: 1
inputs: none specified
Estimated total run time: 42 s

Benchmarking 1_b_100x1000 ...
Benchmarking 2_b_100x1000_main ...
Benchmarking 3_d_100x1000_s64 ...
Benchmarking 4_d_100x1000_s64_main ...
Benchmarking 5_b_100x1000_strict ...
Benchmarking 6_d_100x1000_s64_strict ...
Calculating statistics...
Formatting results...

Name                              ips        average  deviation         median         99th %
4_d_100x1000_s64_main           71.18       14.05 ms     ±3.29%       13.94 ms       16.04 ms
3_d_100x1000_s64                71.02       14.08 ms     ±3.44%       13.95 ms       16.24 ms
1_b_100x1000                    70.98       14.09 ms     ±3.84%       13.95 ms       16.50 ms
2_b_100x1000_main               70.85       14.11 ms     ±4.42%       13.95 ms       16.83 ms
5_b_100x1000_strict             64.73       15.45 ms     ±2.87%       15.33 ms       17.41 ms
6_d_100x1000_s64_strict         61.77       16.19 ms     ±2.76%       16.07 ms       18.07 ms

Comparison:
4_d_100x1000_s64_main           71.18
3_d_100x1000_s64                71.02 - 1.00x slower +0.0305 ms
1_b_100x1000                    70.98 - 1.00x slower +0.0401 ms
2_b_100x1000_main               70.85 - 1.00x slower +0.0643 ms
5_b_100x1000_strict             64.73 - 1.10x slower +1.40 ms
6_d_100x1000_s64_strict         61.77 - 1.15x slower +2.14 ms

You can close the PR if you don't feel we need strict.

Hi @lkarthee, I have dropped some comments, but I am still not ahead we should go with this. My understanding is that Rustler will raise anyway, so will strict: false even work as we expect? Or Rustler will convert them to nil on underflow/overflow?

@josevalim

My understanding is that Rustler will raise anyway, so will strict: false even work as we expect?

I am a bit confused because it seems Rustler will raise on overflow-underflow if strict: false.

I was confused about rustler's behaviour - figured out that argument error occurs only when there is mismatch between iX(i8, i16, i32, i64) and uX(u8, u16, u32, u64). My assumption is some kind of typecasting is done by Rustler.
iex(2)> Series.from_list([-129, 256], dtype: {:s, 8})
19:49:17.265 [info] dtype - {:s, 8} # <- Just to make sure we are passing before rustler is called
type_name of val is alloc::vec::Vec<core::option::Option<i8>> # <- log from rust that it is using i8
#Explorer.Series<
  Polars[2]
  s8 [127, 0]
>
iex(3)> Series.from_list([256], dtype: {:u, 8})
#Explorer.Series<
  Polars[1]
  u8 [0]
>
iex(4)> Series.from_list([-129, 256], dtype: {:u, 8})
** (ArgumentError) argument error
    (explorer 0.9.0-dev) Explorer.PolarsBackend.Native.s_from_list_u8("", [-129, 256])
    (explorer 0.9.0-dev) lib/explorer/polars_backend/series.ex:24: Explorer.PolarsBackend.Series.from_list/2
    (explorer 0.9.0-dev) lib/explorer/series.ex:417: Explorer.Series.from_list/2

Overflow of float 32 - results in crash  of VM:
iex(3)> Series.from_list([3.402823E+39])
#Explorer.Series<
  Polars[1]
  f64 [3.402823e39]
>
iex(4)> Series.from_list([3.402823E+39], dtype: {:f, 32})
thread '<unnamed>' panicked at src/series.rs:86:1:
    called `Result::unwrap()` on an `Err` value: {error, badarg}
stack backtrace:iex(4)> Series.from_list([3.402823E+39], dtype: {:f, 32})
libunwind: stepWithCompactEncoding - invalid compact unwind encoding
Abort trap: 6

Right, that’s why I think this pull request is a bit too early. We need to make sure that the default behavior can be not strict, nor seg fault the runtime. We need to understand why floating points crash and, if necessary, add casting on the Elixir side.
From the looks of it, strict: true may be the safest choice, specially as it happens by default. so my suggestion is to improve the messages and the segmentation fault before we add any new code or large change. What is the minimum work we can do to provide a good user experience with the current behavior?

Alright lets into look into f32 crashes and overflow/underflow first before proceeding any further.
We can figure out rest as we go.

float 32 crash is happening due to Some(item.decode::<$type>().unwrap()),  , it should be match item.decode::<$type>() {...}, ?
This solves the crash - but overflow I don't know how to handle it? Any suggestions @philss @josevalim @billylanchantin
macro_rules! from_list_float {
    ($name:ident, $type:ty, $module:ident) => {
        #[rustler::nif(schedule = "DirtyCpu")]
        pub fn $name(name: &str, val: Term) -> ExSeries {
            let nan = atoms::nan();
            let infinity = atoms::infinity();
            let neg_infinity = atoms::neg_infinity();
            ExSeries::new(Series::new(
                name,
                val.decode::<ListIterator>()
                    .unwrap()
                    .map(|item| {
                        match item.get_type() {
                        TermType::Number => match item.decode::<$type>() {Ok(f) => Some(f), Err(_) => None}, //Some(item.decode::<$type>().unwrap()),
                        TermType::Atom => {
                            if nan.eq(&item) {
                                Some($module::NAN)
                            } else if infinity.eq(&item) {
                                Some($module::INFINITY)
                            } else if neg_infinity.eq(&item) {
                                Some($module::NEG_INFINITY)
                            } else {
                                None
                            }
                        }
                        term_type => panic!("from_list/2 not implemented for {term_type:?}"),
                    }})
                    .collect::<Vec<Option<$type>>>(),
            ))
        }
    };
}

I think crashing is fine, but we need to crash exactly in the same way as the other ones, so we can rescue it accordingly in the elixir layer

https://github.com/elixir-explorer/explorer/pull/837 handles float issue.
What to do with integer overflow ?  https://doc.rust-lang.org/book/ch03-02-data-types.html#integer-overflow

When you’re compiling in release mode with the --release flag, Rust does not include checks for integer overflow that cause panics. Instead, if overflow occurs, Rust performs two’s complement wrapping. In short, values greater than the maximum value the type can hold “wrap around” to the minimum of the values the type can hold. In the case of a u8, the value 256 becomes 0, the value 257 becomes 1, and so on. The program won’t panic, but the variable will have a value that probably isn’t what you were expecting it to have. Relying on integer overflow’s wrapping behavior is considered an error.
To explicitly handle the possibility of overflow, you can use these families of methods provided by the standard library for primitive numeric types:

Wrap in all modes with the wrapping_* methods, such as wrapping_add.
Return the None value if there is overflow with the checked_* methods.
Return the value and a boolean indicating whether there was overflow with the overflowing_* methods.
Saturate at the value’s minimum or maximum values with the saturating_* methods.

Instead, if overflow occurs, Rust performs two’s complement wrapping.

This is exactly how Nx behaves. So I am glad to call it a day.

To be clear, Nx doesn't deal with overflows/underflows, they always happen across all operations, and I'd say it is fine to have the same behaviour here too. One of the main points of those libraries is to enable high performance, so the trade-off makes sense?

I will :

document overflow/underflow behaviour
wrap "Explorer.PolarsBackend.Shared.from_list" into a try/rescue ArgumentError and raise a better message there
close this pr


Add "RoguePixxel" to Users using Jest

Add RoguePixxel to Users using Jest

Codecov Report

Merging #5440 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #5440   +/-   ##
=======================================
  Coverage   62.18%   62.18%
=======================================
  Files         205      205
  Lines        6928     6928
  Branches        3        3
=======================================
  Hits         4308     4308
  Misses       2619     2619
  Partials        1        1

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 dea270b...e347c3a. Read the comment docs.

Hello,
we are currently only adding large well known global companies to the list. Thank you for your understanding :)


About the name...

Hephaestus.
It's hard to pronounce and spell. (I had to copy and paste it above, after I manually typed it wrong the first time.) Would you consider renaming this project to something simpler? Slightly tongue-in-cheek request, but in all sincerity, the name is a (mild) usability impediment. It makes it hard to discuss the library.

Also, the pronunciation between languages (for example English, Spanish and German) is wildly different. Intuitively as a German I'd say "he-fa-estus", without the "he" as a "hii".

I am in total agreement here having a difficult to pronounce name ultimately limits discussion and collaboration.
As per the discussion on Reddit, some developers have resorted to using a pronunciation guide in order to learn how to say the name. That particular guide rates the difficulty 4/5 for native English speakers let alone non-native, making this library extremely difficult for the vast majority of the development community.
I think the name is 'cute' in its nod to mythology but I would pick being widely-pronounceable and recognizable over being cute any day. As I said in my Reddit post, the fact most of us are talking about the name and not the actual library shows that, in my opinion, it was a poor choice and I hope you reconsider it.

I'm sorry to disappoint you, but we'll stick with the name. I guess a lot of people learnt today where the name comes from and a good history lesson is never wrong.

This is very disappointing - how the heck do we (as developers / society) expect to solve discrimination when a simple issue of a name can't even be discussed and improved upon.
It's hard enough being dyslexic in day to day life without developers being completely tone deaf when someone has genuine concern. The dismissive and tone deaf attitude turned this from a genuine concern for many alike into unintentional discrimination.

It's not my or Square's intention to discriminate anyone. The name originates from a historical figure and we didn't choose it to offend anyone. It involves more work than a global find-and-replace to rename the library.
We'll discuss this internally again, but at the same time I won't promise anything. I hope you can also understand that we won't open a poll for how we name our open source projects.

Completely understand this issue as a Spanish & probably dyslexic person (not the first dyslexic issue I had).
I had to repeat the name 4 times till the American counterpart could understand what I was talking about.
While it is a cool name a good modern history lesson is that society also drops political / complex names for simplified ones
If you want to be understood without hassle just type/say:
square dagger plugin

We discussed this internally and decided to rename the library. All arguments together convinced us. We appreciate the feedback. The new name will be "anvil".

This is awesome to hear. This is why Square leads the world in OSS.
If we ever get back to conferences again, drinks on me.

The project was renamed. Note that the artifact ID also changed. Keep that in mind when upgrading.
plugins {
  id 'com.squareup.anvil' version "${latest_version}"
}

Thanks again for all the feedback.


Specify SMD documentation and defaults for struct memebers through magic comments

Take the following example:
type MyService struct {} //zenrpc

type MyArg struct{
    A `json:"a"`
    B `json:"b"`
}

// DoSomething does something.
//zenrpc:arg specify a and b
func (MyService) DoSomehting(arg MyArg)

I don't see a documented way for providing documentaiton and/or defaults for argument MyArg.A and MyArg.B in the struct through magic comments or struct tags/comments.
It would be nice if it was somehow possible. Perhaps as method tags?
//zenrpc:arg.a="default" Let's you document a.

Please see https://github.com/semrush/zenrpc/blob/master/testdata/testdata_zenrpc.go#L103
from https://github.com/semrush/zenrpc/blob/master/testdata/model/model.go
Just add comments to fields like this:
type MyArg struct{
    A int `json:"a"` // comment 1
    B int `json:"b"` // comment 2
}


Link to Docker Hub says page not found in Chrome and Firefox

Bug Report
Note: The link shows content in Safari OK, so I don't think this is a Prometheus bug or a problem with the link really. The doc is in this repo, though, and published on https://prometheus.io, so I opened the issue here.
What did you do?
Followed the link to Docker Hub in the Prometheus INSTALLATION guide:

All Prometheus services are available as Docker images on Quay.io or Docker Hub.

In each browser I tried a regular window with all my extensions, also a incognito/private window with none of them.
What did you expect to see?
Prometheus services available on Docker Hub.
What did you see instead? Under which circumstances?
In Chrome and Firefox I get:

In Safari I get the expected list of projects.
Environment

System information:

$ uname -srm
Darwin 18.6.0 x86_64

Chrome Version 75.0.3770.100 (Official Build) (64-bit)
Firefox version 67.0.4 (64-bit)
Safari 12.1.1

Prometheus version:

n/a

Alertmanager version:

n/a

Prometheus configuration file:

n/a

Alertmanager configuration file:

n/a

Logs:

n/a

The change in https://github.com/prometheus/prometheus/pull/5722 would have avoided this 404 by linking directly to the prom/prometheus page.
Whatever was making the 404s for me and @bwplotka (https://github.com/prometheus/prometheus/pull/5722#pullrequestreview-256270645) at https://hub.docker.com/u/prom/ isn't happening today, so I'll close this out. ¯\_(ツ)_/¯


delete pipeline should stop all active and pending pipeline

when deleting pipeline the active and pending pipeline should be stopped

@tamir321 @yehiyam
fixed, waiting for PR

File:pipeline_tests.js
describe : "pause_resume_pipelineas (git 529 344)"

Test
description

delete pipeline stop all pipeline
delete pipeline stop all active pending pipeline


EXPERIMENTAL: Add --keep-cluster-id and --node-id to 'etcdctl backup'

This PR adds two flags to etcdctl backup:

--keep-cluster-id stop etcdctl from rewriting the cluster id with a random value
--node-id <id> sets an explicit node id in the WAL metadata (instead of using a random value again).

This allows to do disaster recoveries with copies of a data backup, following the idea in https://github.com/coreos/etcd/blame/master/contrib/systemd/etcd2-backup-coreos/README.md#L249. The latter is only a sketch which does not work with current etcd because the non-founder nodes will read their node id from the WAL and therefore all use the same node id as the founder.
This PR makes it possible to rewrite a WAL with a new node id. This allows the following disaster recovery procedure:

take a backup of a data-dir and anonymize it with

$ etcdctl backup --backup-dir restored.etcd -data-dir <data-dir-backup>
$ etcdctl --force-new-cluster --data-dir restored.etcd
<ctrl-c>
$ cp -avx restored.etcd /var/lib/etcd/data
$ systemctl start etcd2

add the non-founder node:

$ etcdctl member add non-founder http://non-founder:2380

giving a node id<PHONE_NUMBER>1234567890.

on the non-founder nodes:

$ rm -rf /var/lib/etcd/data/member
$ rsync founder:restored.etcd restored.etcd
$ etcdctl backup --backup-dir restored.etcd --data-dir /var/lib/etcd/data --keep-cluster-id --node-id<PHONE_NUMBER>1234567890
$ systemctl start etcd2

/cc @colhom

@sttts The main reason we decided to randomize the cluster id is to avoid accidental overlapping cluster. That happens A LOT when we do not have this feature enabled in etcd 0.4. User recreates a cluster and the members in that cluster might talk to the existing cluster. It would screw up everything.
Can you let us know your use case?

We'd like to be able to provision a new cluster member using an existing
member's backup rather than relying on transferring the database snapshot
over the wire. This is a very specific, purposeful operation for disaster
recovery.
On Tue, Jun 28, 2016 at 6:58 PM Xiang Li<EMAIL_ADDRESS>wrote:

@sttts https://github.com/sttts The main reason we decided to randomize
the cluster id is to avoid accidental overlapping cluster. That happens A
LOT when we do not have this feature enabled in etcd 0.4. User recreates a
cluster and the members in that cluster might talk to the existing cluster.
It would screw up everything.
Can you let us know your use case?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/coreos/etcd/pull/5397#issuecomment-229209237, or mute
the thread
https://github.com/notifications/unsubscribe/AAABYu3ZsiHbrFK_9UvdN7ZNcOeUEb8Uks5qQaccgaJpZM4IiRs6
.

relying on transferring the database snapshot over the wire.

Can you provide more details on this? Why do you want to do that. For etcd2, the snapshot size is limited to 100MB or so. The cost is not HUGE. For etcd3, we do want to enable that when users can have GB snapshot.

We have a setup with a 700mb database and we aren't able to add a new
member to the cluster. It has trouble sending the snapshot and times out. I
can provide more details if needed.
On Tue, Jun 28, 2016 at 7:09 PM Xiang Li<EMAIL_ADDRESS>wrote:

relying on transferring the database snapshot over the wire.
Can you provide more details on this? Why do you want to do that. For
etcd2, the snapshot size is limited to 100MB or so. The cost is not HUGE.
For etcd3, we do want to enable that when users can have GB snapshot.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/coreos/etcd/pull/5397#issuecomment-229211157, or mute
the thread
https://github.com/notifications/unsubscribe/AAABYlkNpdFBWpxhLfVEXwCO1oOiLETWks5qQamWgaJpZM4IiRs6
.

We have a setup with a 700mb database and we aren't able to add a new

Yea. etcd2 does not work when you have a snapshot larger than 200MB. Similar thing happens to zk or consul, which does full snapshot. My advice is to reduce snapshot size or switch to etcd3, which supports max 8GB snapshot by doing incremental snapshot.

Neither of those options is possible right now. This is an OpenShift /
Kubernetes deployment and we aren't ready to move to etcd3. Would this PR
be a possible temporary solution, given an existing member's backup and a
new server?
On Tue, Jun 28, 2016 at 7:15 PM Xiang Li<EMAIL_ADDRESS>wrote:

We have a setup with a 700mb database and we aren't able to add a new
Yea. etcd2 does not work when you have a snapshot larger than 200MB.
Similar thing happens to zk or consul, which does full snapshot. My advice
is to reduce snapshot size or switch to etcd3, which supports max 8GB
snapshot by doing incremental snapshot.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/coreos/etcd/pull/5397#issuecomment-229212267, or mute
the thread
https://github.com/notifications/unsubscribe/AAABYvt4javJnP87TbVHUGqnTyHQjj4Oks5qQasMgaJpZM4IiRs6
.

@ncdc I think this workaround might work for you if you strictly do what you described by just adding member. But we probably would not accept this patch. We do not expect etcd2 to work with 700MB snapshot at the first place; this patch has the risk as I mentioned above.

I am closing this based on the discussion above. Let me know (reopen or create an issue) if you have further concerns. Thanks.


Context dependent task offering

ID is simple to use due to the context-dependent offering of operations. The proposed taskbar #3123 seems to break with this concept, and would require the user to select more JOSM like from a growing list of tasks. This would be a badly scaling approch.
We can make it better scaling and more convienient to use by context-dependent task offering. To do this the taskbar needs to show:

normal icons for all active tasks
grayed-out icon for inactive task which are matching iD's current mode and/or selection
nothing for all other inactive tasks

Clicking icon should toggle active/inactive state of the task.
We can support two kinds of such tasks, a permanent one, which is active until toggled off, and a one-off task, which is automatically deactivated as soon as it is no longer matching mode and/or selection.
Examples:

An indoor tool can be offered for activation (show as inactive in the task bar) when an indoor element is selected.
A special drawing tool (e.g. orthogonal mode) for areas can be offered while the area drawing mode is active.
A task overriding a large-feature protection can be offered when a large feature is selected, and it can be made a one-off task to prevent staying in an unsafe task mode over a long time.

The matching of inactive tasks to current mode and/or selection should be made asynchronously, this allows a very specific (and therefore time-consuming) matching even of a large number of tasks (e.g. due to plugins) without impairing iD's performance for normal operations.

This isn't really what I had in mind for the taskbar.  I don't want it to be mode dependent or show greyed out icons at all.
It's possible that my explanation in #3123 is not clear, or it might just not be what you want me to build.  Either way, can you keep discussion on that issue, rather than opening issues for features that haven't been built yet?  Thanks!


Figure out how to handle the CT log proofs in clients

The simplest way seems to be the "precertificate" method, here: https://letsencrypt.org/2018/04/04/sct-encoding.html
We request two certs from the CA - a "precertificate" and the real one. The precertificate is "poisoned" with a special bit set: https://github.com/google/certificate-transparency-go/blob/v1.1.1/x509/x509.go#L1208
Then that is included in the log. When that is finished, the SCT (signed cert timestamp) is embedded in the final cert. The certs are identical, except the poison bit is removed and the SCT is added.
That way clients can verify the cert is in the log without making any requests.

So for this to work, the precert we get from the CA has to be identical to the cert we get from the CA except for the one extension. I closed #55 because it looks like the GCP CA doesn't let you specify the serial number of the cert, so the numbers on the precert and the cert can't match 😞
Closed the PR for now, but possible solutions:

If we set up an intermediary CA that allows us to specify serial numbers, we can probably get this to work

and that's pretty much it 😅  If anyone has any other ideas that would be great!
For future reference:

validation function I was using

cc @mmalone any ideas here? Might be time to read all that stuff you sent me about setting up the step CA :)

Priya, mind if I assign this to myself? I ended up writing a doc on embedding SCTs in certificate, and then found this issue and the CA Service problem.

For sure!

When we switch over to embedded SCTs, it's going to be a breaking change. I thought providing the SCT in both the header and embedded would be fine, but it's not sufficient. The SCT is generated using the precertificate, which doesn't contain the embedded SCT. The current version of Cosign doesn't know to reconstruct the certificate without the embedded SCT, so signature verification fails (it's just a flag in the verification function).
I just need to update Cosign to handle embedded SCTs, but users must update Cosign in order to call Fulcio once we start embedding SCTs.
fyi @dlorenc @bobcallaway - Any concerns? We'll just need to cut a new release of Cosign before switching Fulcio over to the new intermediate.


Update keras cv docs to the newest release

@fchollet rebased and addressed all comments.  Thanks!

@fchollet added the GenFiles!

@fchollet also added a models page


🐛 Update the dependency resolution mechanism in freeze

Fixes

https://github.com/chains-project/maven-lockfile/issues/687
https://github.com/chains-project/maven-lockfile/issues/686
https://github.com/chains-project/maven-lockfile/issues/683
Adds a new field "included" to the lockfile to track the dependency conflict resolution.

@yogyagamage It is surprising that no tests are failing which means this functionality was not well tested before. Could you please add a test case that exercises getNearestDependency?

@yogyagamage It is surprising that no tests are failing which means this functionality was not well tested before. Could you please add a test case that exercises getNearestDependency?

Added a test case https://github.com/chains-project/maven-lockfile/pull/702/commits/cb1aa05ba539276f2918f8e70b6ac092338fcc3a

Sorry couldn't review. But we had discussed this in meeting so it's okay.

From: Yogya Tulip Gamage @.>
Sent: Thursday, April 18, 2024 1:53:57 PM
To: chains-project/maven-lockfile @.>
Cc: Aman Sharma @.>; Review requested @.>
Subject: Re: [chains-project/maven-lockfile] 🐛 Update the dependency resolution mechanism in freeze (PR #702)
Merged #702https://github.com/chains-project/maven-lockfile/pull/702 into main.
—
Reply to this email directly, view it on GitHubhttps://github.com/chains-project/maven-lockfile/pull/702#event-12523037767, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIMPTOLPDTQO6JM6QRGJ7ADY5666LAVCNFSM6AAAAABGEMHXFGVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGUZDGMBTG43TMNY.
You are receiving this because your review was requested.Message ID: @.***>

No worries, I just merged it because I needed the changes to add a new PR.


Background Location Tracking

Hey there, awesome library!
Do you guys know, how to keep receiving location updates in kmp, while the app is running in the background?
Best regards, and thank you so much for your amazing work!

You would have to look on the respective platforms. I imagine for Android you would use WorkManager or something similar, no idea about iOS. It's out of the scope of this library.


qiskit-ibm-catalog version isn't correctly setup

Steps to reproduce the problem
While we have VERSION.txt, this version isn't propagated to PyPi
What is the current behavior?
Today, when running !pip freeze | grep qiskit, it only shows qiskit-ibm-catalog==0.0.0
What is the expected behavior?
It should correctly reference our version

Believe this was fixed in #15

Can't find 0.2.0 from pypi. I think #15 didn't fix the issue.
pip install qiskit-ibm-catalog==0.2.0
ERROR: Ignored the following versions that require a different python version: 0.1.0 Requires-Python >=3.11; 0.2.0 Requires-Python >=3.11
ERROR: Could not find a version that satisfies the requirement qiskit-ibm-catalog==0.2.0 (from versions: 0.0.0)
ERROR: No matching distribution found for qiskit-ibm-catalog==0.2.0

Updating to python 3.11 solved the issue. Please ignore my previous comments :D


HttpRequest.address doesn't contain the requested URL

I'd like to access the complete URL address inside the route callback. So here is an example code:
let server = HttpServer(0)
server["hello-world"] = { request in
    debugPrint(request.address)
    return HttpResponse.ok(.text("<html string>"))
}
server.start()

but after visiting the registered address (e.g. http://<IP_ADDRESS>:66577/hello-world?test=1), the  request.path, request.headers, request.queryParams properties are parsed and set correctly, just the request.address contains a strange string - something like ::c080:d00:60:0 instead of the visited URL (http://<IP_ADDRESS>:66577/hello-world?test=1 in my case).
Although the HttpRequest.address property is not documented, I'm assuming that it should contain the complete URL of the request. Am I right? Or if the HttpRequest.address is used for something different, how can I get the visited URL?

When starting your server you can do so like:  try server.start(9080, forceIPv4: true) For me this made the request.address show the IP address of the request i.e. <IP_ADDRESS>.  If you combine with request.path you should be able to start to rebuild the request.


Improve RTF for 3D Livox Lidar

Comment traceHandle on ASYNC for now, not sure if this should be removed

you should not just comment out but override in child class

@yuokamoto it is already overwritten but it calls Super::TickComponent(DeltaTime, TickType, ThisTickFunction);
Should I inherit directly RRLiVoxMid360Component from URRBaseLidarComponent

you should not just comment out but override in child class

@yuokamoto it is already overwritten but it calls Super::TickComponent(DeltaTime, TickType, ThisTickFunction); Should I inherit directly RRLiVoxMid360Component from URRBaseLidarComponent?

if most of the logic is not same, you can inherit from URRBaseLidarComponent
you can change it not call super Tick or call URRBaseLidarComponent::TickComponent instead of Super::TickComponent

you should not just comment out but override in child class

@yuokamoto it is already overwritten but it calls Super::TickComponent(DeltaTime, TickType, ThisTickFunction); Should I inherit directly RRLiVoxMid360Component from URRBaseLidarComponent?

if most of the logic is not same, you can inherit from URRBaseLidarComponent
you can change it not call super Tick or call URRBaseLidarComponent::TickComponent instead of Super::TickComponent

Thanks, I will go with call URRBaseLidarComponent::TickComponent instead of Super::TickComponent

We can close this PR as the changes can be done on RapyutaSimulationInternal


Support multiple AZs in the Operator

This is part of epic #385 which is part of epic #100.
An AZ (Availability Zone) is a boundary within cloud providers which, incidentally, we cannot move PVs (and hence PVCs) across. Each node is in an AZ, as is each PV; and the node can only bind PVs in the same AZ.

[ ] Decide how AZs appear in kubernetes-land. Are they separate Kubernetes clusters in a "federation"?
[ ] Find out from kubernetes what AZ each PVC and node is in, in the operator.
[ ] When creating a new dotmesh pod on a node in an AZ, consider the list of available PVCs in that AZ only; and create a new PVC in the AZ if there are no available ones.
[ ] When creating a new dotmesh pod on a node that already has one because we have a PVC needing a home, create it on a node in the AZ of the PVC.

Generally you can run a cross-AZ kube cluster, just not cross-region.

Need to take care to attach PVs in the right AZs, otherwise things will be terribly broken.


[actions] automatically handle release process

select title from tag
select description from changelog
add zenodo link

partly fixed in #225 and following commits.


Items missing

Hey :)
Thanks for your addon!
I noticed some items are missing so I'll just list them:
https://wowhead.com/item=211370
https://wowhead.com/item=211366
https://wowhead.com/item=210954
https://wowhead.com/item=211373
https://wowhead.com/item=211303
https://wowhead.com/item=211374
Thanks!

Got these added in 1.1.0. Thanks!


Equalizer setting in .ini file

Hi,
I need to slightly compensate the frequency response (+4 dB above 1 kHz) and I tried the following settings in the radio.ini file:
toneha = 4
tonehf = 1000
and
toneha = 4 dB
tonehf = 1000 Hz
and ( as raw SCI_BASS value should be)
toneha = 8
tonehf = 1
But none of these settings seems to be properly read from the radio.ini file at boot time. However, when I set the values in the web GUI, the setting is changed, but are not saved into the radio.ini file. What could be the problem or what is the correct format fore these two/four tone settings?
Thanks,
Primoz

In index.html you can find the acceptable values for the settings.  I will check later if the value are saved.

Tone settings from the webinterface are not automatically saved.  Settings in the ini-file will be used to set the initial values of the tone settings.

Thanks for checking how it is working. I'll edit the .ini file and use it this way.


Add notifications like Rider code cleanup (see notifications windows)

Moved to ideas https://github.com/dubreuia/intellij-plugin-save-actions/projects/2


RGB Conversion Functions

I was trying to add support for kmscon, but got stuck because it needs colors in RGB format, instead of Hex.
I think Stylix should provide a way to get the colors in RGB format, as opposed to Hex.
Inspiration from nix-colors: https://github.com/Misterio77/nix-colors/blob/main/lib/core/conversions.nix#L108

You can just reference baseXX-rgb-{r,g,b}


Migration to 3.0.3 PBEWITHHMACSHA512ANDAES_256

Hello Jasypt team,
I am a happy user of this plugin, cheering for you guys!
Recently, I migrated from version 2 to 3.0.3.
Looking at the update, I saw:
Changed default encryption to PBEWITHHMACSHA512ANDAES_256 (Thanks @rupert-madden-abbott)
This is very cool! And of course, things started to break. 😅
https://github.com/ulisesbocchio/jasypt-spring-boot/issues/189
https://github.com/ulisesbocchio/jasypt-spring-boot/issues/218
I understand I can set the properties
jasypt:
encryptor:
algorithm: PBEWithMD5AndDES
iv-generator-classname: org.jasypt.iv.NoIvGenerator
to keep it working. But actually, I would like to migrate to PBEWITHHMACSHA512ANDAES_256!
Since the plugin is now version 3, why not to update everything as well.
However, I'm having a hard time finding help on how to encrypt my passwords with PBEWITHHMACSHA512ANDAES_256 in the first place.
Maybe I did not look correctly (I only found how to keep using PBEWithMD5AndDES with 3.x.x, but not how to encrypt with PBEWITHHMACSHA512ANDAES_256 ). Are there any resources available using JASYPT, Jasypt spring boot, or the jasypt-maven-plugin to encrypt password directly PBEWITHHMACSHA512ANDAES_256 ?
Thank you for your help

Hi @patpatpat123,
The included jasypt-maven-plugin uses PBEWITHHMACSHA512ANDAES_256 by default also.
However, it now also has an upgrade goal which will handle the upgrade from the pre version 3 algorithm to the post version 3 algorithm for you:
https://github.com/ulisesbocchio/jasypt-spring-boot#upgrade
Does that help?

Hello Rupert,
Indeed, thank you for your help.
Confirmed jasypt-maven-plugin uses PBEWITHHMACSHA512ANDAES_256 by default for encryption, and jasypt-spring-boot also uses PBEWITHHMACSHA512ANDAES_256 by default for decryption.
I was stuck using https://github.com/jasypt/jasypt now I understand.
Thank you again for the cool project, closing, good day.


Please make a compile-option that has libxo just become printf()s

Hi!
For (very) embedded applications we absolutely don't need any of the libxo plumbing for spitting out XML, JSON, etc. We may also not need it for smaller footprint builds like the rescue image builds.
Would it be possible/OK to have a version of libxo's API that just becomes printf()s?

Fixed in develop; compiling with LIBXO_TEXT_ONLY will remove (via C optimizer) the generation of other formats.


Can not find make_grch38_snp_tran_gencode.sh script?

Hello, I want to use make_grch38_snp_tran_gencode.sh ${gtf_version} ${dbsnp_version} , but I donot find the script. and could you also give the location of ${dbsnp_version} in hg19?
Thank you

@barkasn do you know which script this is?
@tianxiahuihui apologies, we haven't used hg19 for our pipelines, so we may not have that available.


Fix for issue #37 and some OAI-PMH test refactoring

Fixing issue where embedded DOCTYPE declarations within resource_data broke lxml's parser.
New test case added to validate that published data with  and <!DOCTYPE> declarations in a variety of formats gets removed before processing.
Also refactored OAI-PMH tests by spliting into 2 classes:

TestOaiPmhControllerSpecialData - each test uses unique test data
TestOaiPmhController - all tests use the same test data which takes a long time to publish because of intentional time pauses inserted into tests.

And moved common validation functionality into it's own module in an effort to simplify the test implementation.
This also includes the fixes included in pull request #132

This looks good


TotalSegmentator fails to launch on Windows with Slicer 5.4

The script failed to launch the process TotalSegmentator on Windows.
On line 719 of TotalSegmentator.py (branch 5.4) https://github.com/lassoan/SlicerTotalSegmentator/blob/a0f8f686ef70f765243453f20d2511595f11870a/TotalSegmentator/TotalSegmentator.py#L719
totalSegmentatorPath = os.path.join(sysconfig.get_path('scripts'), "TotalSegmentator")
should be:
totalSegmentatorPath = os.path.join(sysconfig.get_path('scripts'), "TotalSegmentator")
if os.name == 'nt':
    totalSegmentatorPath += ".exe"

This change fixes the issue for me
EDIT: I see that the code in latest version handles this issue. But this is not what it is installed by default in Slicer.

Thanks, fixed in https://github.com/lassoan/SlicerTotalSegmentator/commit/66d377ffd14c8488e37982ca31458dd16d9a30c1


Update index.yml

Change author name.

Learn Build status updates of commit 4328df4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/azure-percept/index.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

#sign-off

@nkhuyent

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

Note that metadata changes are usually not allowed in the public repos.  You can make these changes in the private repo azure-docs-pr.

Read about authors working in the public repo for more information.
If you need help getting set up to work in the private repo, see Set up Git repository locally for documentation.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Learn Build status updates of commit 589f61b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/azure-percept/index.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Jak: @nkhuyent is on a leave of absence and I am the current author for this project.

#sign-off
PRTeam:  @nkhuyent is on a leave of absence and I am the current assigned author for this project.

@nkhuyenthttps://github.com/nkhuyent is on a leave of absence and I am the current author for this project.
If you need to confirm, please contact @Amira @.***>
Thank you,
Yvonne
Maria Yvonne de Quadros, Technical Writer
425-753-0786 | LinkedInhttps://www.linkedin.com/company/prime-8-consulting
@.***https://www.prime8consulting.com/
Awarded 'Best Companies To Work' for 7 Years!https://www.prime8consulting.com/press-releases/pressrelease/100best
@.***https://www.womenownedlogo.com/
From: Jak Koke @.>
Sent: Monday, October 3, 2022 2:00 PM
To: MicrosoftDocs/azure-docs @.>
Cc: Maria De Quadros (PRIME 8 LLC) @.>; Mention @.>
Subject: Re: [MicrosoftDocs/azure-docs] Update index.yml (PR #99402)
@nkhuyenthttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnkhuyent&data=05|01|v-mdequadros%40microsoft.com|fcf8eda6b06b4012469708daa5824498|72f988bf86f141af91ab2d7cd011db47|1|0|638004276163723213|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=sCuQzkEi%2F0HxcqS2xTTqSrZhGtdRlArb4eox2auQPvI%3D&reserved=0

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

Note that metadata changes are usually not allowed in the public repos. You can make these changes in the private repo azure-docs-pr.
Read about authors working in the public repohttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.docs.microsoft.com%2Fhelp%2Fcontribute%2Fcontribute-authors-in-public-repo%3Fbranch%3Dmain&data=05|01|v-mdequadros%40microsoft.com|fcf8eda6b06b4012469708daa5824498|72f988bf86f141af91ab2d7cd011db47|1|0|638004276163879454|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=ecGZ2zN5VLf%2BuLDLHHIdBDG867tld8t%2FD7AsdMGbteI%3D&reserved=0 for more information.
If you need help getting set up to work in the private repo, see Set up Git repository locally for documentationhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.docs.microsoft.com%2Fhelp%2Fcontribute%2Fcontribute-get-started-setup-local%3Fbranch%3Dmain&data=05|01|v-mdequadros%40microsoft.com|fcf8eda6b06b4012469708daa5824498|72f988bf86f141af91ab2d7cd011db47|1|0|638004276163879454|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=q1%2FAi5Bw0IWr8UE5Kvq5VA%2FhcQ50FrEefzOLey9oRXQ%3D&reserved=0.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-teamhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Forgs%2FMicrosoftDocs%2Fteams%2Fpublic-repo-pr-review-team&data=05|01|v-mdequadros%40microsoft.com|fcf8eda6b06b4012469708daa5824498|72f988bf86f141af91ab2d7cd011db47|1|0|638004276163879454|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=aPbCNr3uQwanW8GlpwDgBI2nkm9ZBz4eElYY6UFRXB4%3D&reserved=0

Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fpull%2F99402%23issuecomment-1266042902&data=05|01|v-mdequadros%40microsoft.com|fcf8eda6b06b4012469708daa5824498|72f988bf86f141af91ab2d7cd011db47|1|0|638004276163879454|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=rms8%2BDiZEFGV%2FzR%2BaygPOJuX2ehO8iQnQr8F0Y0QIzU%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAZGG2IVW43QJNVNT5CRRLMDWBNCN3ANCNFSM6AAAAAAQ36HM7A&data=05|01|v-mdequadros%40microsoft.com|fcf8eda6b06b4012469708daa5824498|72f988bf86f141af91ab2d7cd011db47|1|0|638004276164035694|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=T64X3UO0osLukjqNchegLeOFQniGwb%2FbdhLwM%2BFNHmQ%3D&reserved=0.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

@Yvonne-dQ
Thanks for reaching out! Changes to the author and ms.author metadata should be made in the private repo. Can you make these changes in azure-docs-pr instead?