[sdk] Delegates alias computation to engine

Fixes #14
Removes AllAliases function and instead constructs aList<Pulumirpc.Alias> in PrepareAliases (linear time) which populates the RegisterResourceRequest accordingly:
if (prepareResult.SupportsAliasSpec)
{
    request.Aliases.AddRange(prepareResult.Aliases);
}
else
{
    var aliasUrns = prepareResult.Aliases.Select(a => a.Urn);
    request.AliasURNs.AddRange(aliasUrns);
}

Wasn't exactly sure how to test this other than constructing a lot (=1000) of aliases in AliasesMocks and observe that it doesn't just hang for a while.
All integration tests are succeeding locally except for TestProvider but that seems unrelated. Let's see what CI has to say about it.

Run dotnet format :) Also we should split that to it's own job so the unit tests can still run and give signal even if formatting is wrong.

@Frassle

Using dotnet run format-sdk changes every file I have, removing a whitespace at the end 😓
Integration test TestProvider is failing on the destroy step.

Using dotnet run format-sdk changes every file I have, removing a whitespace at the end 😓

Odd? Shouldn't this be consistent across machines?

Integration test TestProvider is failing on the destroy step.

OK leave the test off the test list for now, I'll get that fixed.

Odd? Shouldn't this be consistent across machines?

@Frassle I've added a minimal .editorconfig which is now formatting the same locally and on CI

OK leave the test off the test list for now, I'll get that fixed.

Removed that test the time being

I'm pretty sure the engine is happy to take an Alias object with type or name as "".

Alright, then using empty string as default, see last commit:
var aliasSpec = new Pulumirpc.Alias.Types.Spec
{
    Name = await Resolve(resolvedAlias.Name, ""),
    Type = await Resolve(resolvedAlias.Type, ""),
    Stack = await Resolve(resolvedAlias.Stack, Instance.StackName),
    Project = await Resolve(resolvedAlias.Project, Instance.ProjectName),
};


Do not forget to close filedescriptor

Fixes a leaking filedescriptor.

Hi, this is a great find @42wim! Thanks for the PR


Remove myself from maintainers

Because Zalando deleted the game from its 404 page, and I (the top contributor) don't work at Zalando anymore, I chose to support my own fork of the game here: https://github.com/w0rm/elm-street-404.
Depending on how interested is Zalando in this game, you may:

fully transfer the repo to my account, please get in touch with me on Twitter;
update README.md with a link to the active fork;
do nothing about this

Ping @aryszka @kolja @vigneshshanmugam can you merge this?

👍


Document local Artifactory proxy usage

The first step of dbuild run is analysis of project dependencies. For that to complete, dependencies of each project need to be resolved through Ivy. It means we have to hit remote repositories a lot and it takes time. The workaround for slow Ivy resolution that Typesafe uses when running Jenkins jobs is going through a local repository proxy. We are using Artifactory for that.
We should cleanup repository defintions in our config files and document how to set up local Artifactory proxy so it's practical to run dbuild with community build config outside of Typesafe jenkins machine.

there is nice doc on this at https://docs.google.com/document/d/18fGjMz21J4-JMHXfDH4OyGOXu8NvWfsG4q83S9RT64M/edit

I'm now much more knowledgeable on this. I now use a local Artifactory for everything (all community build work and all other work too) — so I can answer questions, at least. There is some discussion and lore at #408.

I've added my local config to the repo: https://github.com/scala/community-builds/blob/2.12.x/artifactory.xml

declaring the current state good enough


Add range formatting to the ruby-lsp

Range formatting is a request very similar to formatting, but it applies only to the selected range and not the entire document.
Currently, trying to format ranges with either RuboCop or SyntaxTree fails, because both believe they are always looking at whole files instead of ranges.
For RuboCop, this will be difficult to overcome, given that trying to format a range in the middle of the document will even add # frozen_string_literal comments.
However, we may be able to use SyntaxTree for this if we add the ability of informing the formatter about the current indentation (or nesting) level. In the current behaviour, the code inside the range will be considered as a whole file and everything is pushed to indentation level zero.
Documentation: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_rangeFormatting

This would be big!  Can't use formatOnSaveMode until this is introduced!

@vinistock use case of modifying  # frozen_string_literal: true
is about sending partial of the file for rubocop.
I said that you send whole file , parse rubocop output and keep only modified lines.
then frozen string literal will not be a problem as it would be added on top of the file and will be ignored as you did not change file top (it will work only on new files)
Maybe some problems will be with whole function definition indentation, but also better to have partial rubocop rules setup of linter in terms of modification range than nothing or whole file ?

My concern is whether that approach will be brittle or not and the performance of doing more work on top of the formatting (which is already not very fast).
Additionally, RuboCop allows for extensions (rubocop-performance, rubocop-rails, ...) and it's not clear to me that we can ensure all of the corrections will be only what's relevant for the selected range.
I put up #2657 to add the request implementation for Syntax Tree, which I added the bits needed for range formatting myself.
If you have an idea of how to make it work for RuboCop, then please propose a PR that will implement run_range_formatting in lib/ruby_lsp/requests/support/rubocop_formatter.rb.


HTML Injection in uptime-kuma Status page

DO NOT PROVIDE ANY DETAILS HERE. Please privately report to https://github.com/louislam/uptime-kuma/security/advisories/new.
Why need this issue? It is because GitHub Advisory do not send a notification to @louislam, it is a workaround to do so.
Your GitHub Advisory URL:
https://github.com/louislam/uptime-kuma/security/advisories/GHSA-ffvm-p92q-25c3

It is a feature that users can add html code. Also it can be edited after logged in only. No unauthorized attacker can do this.
The implementation here:
https://github.com/louislam/uptime-kuma/blob/88b7c047a859d83862f917b876b921ec026fef5a/src/pages/StatusPage.vue#L580-L602

It is also sanitised.
If you have found a sanitisation escape please report this to https://github.com/cure53/DOMPurify/security instead.
Given that no such advisory has been published by the cure54..

@muhammadahmad62 said:

Hi @louislam,
Thank you for your response. I understand that Markdown syntax is supported here, but HTML code, especially tags like <form>, should not be allowed. These can be exploited for Form Hijacking Vulnerabilities to harvest credentials from users. So the input should be further sanitized. Given this, I kindly request that you reconsider the assessment of this report.
Thank you for your attention to this matter.
Best regards,
@muhammadahmad62

But my point is everything can be done by admin only. I don't think admins would hack their own Uptime Kuma.
Also for examples, applications like Wordpress, GitHub (Code editor) also allow users to edit html code and deploy to production, are they exploited for Form Hijacking Vulnerabilities too?


feat: use uppercase acronyms in template functions

Description
See discussions in

#84

Changes
The functions are now using uppercase acronym, old ones are aliased, but marked as deprecated.
Fixes #84
Checklist

[X] I have read the CONTRIBUTING.md document.
[X] My code follows the code style of this project.
[?] I have added tests to cover my changes.
[X] All new and existing tests passed.
[X] I have updated the documentation accordingly.
[?] This change requires a change to the documentation on the website.

Additional Information

Please note, I didn't update some godoc that currently mentions the old syntax because you are working on updating them to url via

#97

I think you can review now the other PR is mergef

@ccoVeille that correct ! But we cannot apply suggestion when the pull request are merged, I will apply in a new pr


Validation rules as array cause Exception

Bug report
What I did:
Defined request rules as array (to make use of closures or custom rule objects) as described in the Laravel docs.
Example from any Request class:
...
    public function rules()
    {
        return [
            'name' => [
                'required',
                'min:5',
                'max:255',
            ]
        ];
    }
...

What I expected to happen:
Working validation of array rule set.
What happened:
ErrorException:
ErrorException(code: 0): strpos() expects parameter 1 to be string, array given at .../vendor/backpack/crud/src/PanelTraits/RequiredFields.php:30)
The problem is not usage of closures or rule objects, but to define a rule set as array, rather than pipe separated string.
What I've already tried to fix it:
Really simple fix in trait RequiredFields incoming via PR.
The only currently working workaround I figured out, is to write a second version of each request, in which rules() returns a rule set only containing required rules on required inputs. This second request can then be passed to $this->crud->setRequiredFields() while create() and update() hint the original request classes. Among workarounds, this is one of the worst :smile:
Backpack, Laravel, PHP, DB version:
backpack/base                         0.9.6
backpack/crud                         3.4.23
mysql                                       5.7.22
PHP                                         7.2.7

It's almost certainly a bug - #1543 would fix it but it should use ===. See the PR.


⚠ Spryr has degraded performance

In bbf50a5, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 5517 ms

Resolved: Spryr performance has improved in dd282b7 after 36 minutes.


Update pt.yml

Hi David,
I finished translating the pt branch. Let me know if there's anything missing.
cheers
Marianna

Oh, wow! This is fantastic!


[Feature Request] Enable a Checkbox For "Use Windows Authentication" for SQL Server Connections

When using the Microsoft JDBC Driver, authenticating to SQL Server using Windows/Domain credentials is cumbersome. The user has to open the driver properties, search for "integratedSecurity" and set it to "true", and be aware that they should leave the user/password inputs blank.
(Current instructions for connecting using the Microsoft driver here and jTDS driver here.)
The driver properties tab should be for advanced users, and general users shouldn't have to access it to create a connection.
My suggestions is to add a checkbox to the New Connection screen for Microsoft JDBC Driver connections that allows the user specify to use Windows Authentication. When checked, this would clear out and disable the username and password input boxes and set the integratedSecurity option to "true".
Screen mock-up (this was made on a Mac, but would obviously only apply to Windows machines since the auth library is a dll). Additionally maybe put "(Windows Only)" in the checkbox label.

Extra FR for #810

@efradkin 👍


Adding chrome_options argument "no-sandbox"

I couldn't get it to work on linux without this line.

Care to add this in?

just delete the executable path argument and use the default one. p.s. you should download the driver file to the current folder.


Remove LoggerT

Using another level of monad transformers in PureScript for what is essentially just a handle is an overkill. LoggerT is a specialized ReaderT, and we already have one in QueryM.

Also remove mentions of LoggerT from the docs


fix: correctly deserialize consecutive XML flat maps

This PR fixes a bug in the XML deserializer which fails to process consecutive flat maps properly. Before this change, the deserializer would seek forward until it found a matching map key. Consecutive flat maps sharing the same key names would be lumped together unintentionally.
The fix is to seek using XmlSerialName as a comparator since this is the only thing distinguishing different flat maps. A new deserialize method peekSeek is added which seeks forward and only consumes tokens if they are a match.
Issue #

https://github.com/awslabs/aws-sdk-kotlin/issues/962
Description of changes

This fixes a bug when deserializing consecutive flat maps. See the new "consecutive flat maps" test case for an example of an XML tree for which parsing previously failed.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Do we have similar problems in our other deserializers (e.g., JSON)?

Thankfully JSON doesn't have this problem because it only has one way to represent a map


fix: fix CI timing out test

Goals:

inspect and debug CI timing out test
fix the bug

CI was fixed by a release in jina upstream, I'm pinning the jina version in this PR

Pinning the jina version will break jina once a minor is released


Feat/cypress

To run cypress:
API_PORT=3100 yarn api
API_URL=http://localhost:3100 yarn dev
yarn e2e

Also fixes the yarn test command.

Thanks again for this! Enjoy your holiday, I'll work on this and merge while you're away. Great notes & great work!!


Generate Objective C NS_ENUM/NS_OPTIONS for enums and bitmaps.

Problem
We are not generating Objective C reflections of spec enums and bitmaps.
Change overview
Do that.
Testing
Read the generated code.

/rebase


Multi Core support similarly to AsyncTCP?

I was wondering whether multi core support is planned or not. The AsyncTCP library does this by using the xTaskCreateUniversal function that creates a task in a way that if there is free core to run the task on chooses that if not uses the xTaskCreate (like your code).
Currently the webserver on my dual core esp32 runs on the same core as the main loop, and I wanted to off load it to the second one to improve overall performance.
Thanks

See Zach's response to this in https://github.com/hoeken/PsychicHttp/issues/12#issuecomment-1868370757
Multi-threading is native in IDF 5.1.x on Arduino 3.0 (which is still in Alpha). We had issues getting it compiled. Feel free to hack around. I was using:
platform = https://github.com/platformio/platform-espressif32.git
; platform = https://github.com/Jason2866/platform-espressif32.git#Arduino/IDF5
platform_packages = https://github.com/espressif/arduino-esp32.git#3.0.0-alpha2

I think async TCP multi core is not the same. Async TCP just runs every request in a separate task on a core synchronously. The idf threaded solution would fire a new task for every request. Is my understanding right?

The current physic implementation does the same as async tcp

I think async TCP multi core is not the same. Async TCP just runs every request in a separate task on a core synchronously. The idf threaded solution would fire a new task for every request. Is my understanding right?

Yes you are correct. Basically AsyncTCP just offloads the server to a separate core and creates a loop there and the loop runs on that core. Its not creating a thread for each request.

ent physic implementation does the same as async tcp. One task on one core.

Yes but that task is on the "main" core i.e. core 1, while on a dual core esp32 core 0 does basically nothing. This is the reason for my question.

I think that the -1 which specified on task create for the core is not doing what you think. In my understanding its just picks an available core at create time and the task will run on that core which was available on creation. I dont think that the scheduler can pass the task to different cores at runtime.

I think that the -1 which specified on task create for the core is not doing what you think. In my understanding its just picks an available core at create time and the task will run on that core which was available on creation. I dont think that the scheduler can pass the task to different cores at runtime.

I assumed this, based on the docs:
xCoreID: If the value is tskNO_AFFINITY, the created task is not pinned to any CPU, and the scheduler can run it on any core available. Values 0 or 1 indicate the index number of the CPU which the task should be pinned to. Specifying values larger than (portNUM_PROCESSORS - 1) will cause the function to fail.
But its possible you are correct. Actually in my code I specifically pin it to core 0 and the callbacks e.g. on websocket or sending the page is executed from that core (my main code runs on core 1). So I never tested the run time behaviour.

In my tests the async tcp peflrformed the same with core 0 and -1. :/

In my tests the async tcp peflrformed the same with core 0 and -1. :/

That is very interesting as for me when I check the xPortGetCoreID() I get 0 if I initialize it with 0, showing that it is being run on core 0. If you check the implementation of the xTaskCreateUniversal, it shows that when the core ID is -1 xTaskCreate and when called with zero or 1, it calls xTaskCreatePinnedToCore

So it turn out there is a core_id property on the httpd_ssl_config_t httpd property that can set on which core server should run. If I set it to zero it runs on core 0.
Currently this can only be set from within the the class, but when I have more time I may submit a PR (there are other interesing settings like max_open_sockets, etc. that are non-accessible that could be exposed via setters)

Yeah, the whole config object is exposed

@Abasz  trying to catch up, responses below

we use esp-idf http server under the hood, and they start the server with this call.  It is pinned to the core you set with server.config.core_id

static inline int httpd_os_thread_create(othread_t *thread,
                                 const char *name, uint16_t stacksize, int prio,
                                 void (*thread_routine)(void *arg), void *arg,
                                 BaseType_t core_id)
{
    int ret = xTaskCreatePinnedToCore(thread_routine, name, stacksize, arg, prio, thread, core_id);
    if (ret == pdPASS) {
        return OS_SUCCESS;
    }
    return OS_FAIL;
}

as @zekageri pointed out, the config struct that is passed into esp-idf is a public member of the PsychicHttpServer class so you can adjust those parameters how you want.  Just make sure to make your changes before you call server.listen().
Also worth noting that if you use SSL, it changes to server.ssl_config with the server.ssl_config.httpd being the same as server.config.  This is an esp-idf thing so we just have to work with hit.
As noted in another post, we should be able to get true multi-threaded support working once Arduino is upgraded to the current esp-idf v5.1.2.  We will have more control over that too, so the possibility of running on all cores is there.

Thanks for the above, I totally missed that the settings struct is public property... That makes life easier of course.

old topic, but on point 4, Arduino 6.5.0 is out with IDF 5.1.2 so I tried ENABLE_ASYNC and played with task setting (see https://github.com/hoeken/PsychicHttp/issues/28#issuecomment-1872934088) but no luck yet


set "aes-128-ctr" as parameters for encryptDataToStorage function

Hi @runryan, why did in encryptDataToStorage function on BIP32keystore.swift you set cipher : "aes-128-cbc" static! I want use it as "aes-128-ctr" and I should edit pod library! Can I sent it via parameters?

Fixed in 0.9.0


Just a question

Can you explain the difference between this and np.saves_compressed -> writing the buffer to memory?

Thanks for the question.
With a memory map, you can easily access a random index very quickly (opening the memory map and __getitem__ are both very fast). With np.savez_compressed, then loading into memory, you have a very slow initial loading into memory if the dataset is big, and also you need to be able to fit the dataset into memory. For example, if you are training on a machine with 4 GPUs, and you want to train a different model with a different dataset for each GPU, you would quickly run out of memory if you load the whole dataset for every single model. Memory maps allow you to achieve ultra-fast, almost in-memory speed without actually taking up much memory, utilizing disk space instead.
I am closing the issue, but feel free to continue the discussion here :)

Thanks for the answer.
Can you tell me also how this compares to pyarrow?

pyarrow does not natively support samples of different shapes, to my knowledge, so you would have to write this logic yourself. Also, pyarrow does not support append/extend: https://github.com/apache/arrow/issues/3622

Thank you for your time.
Two more questions I think.

Is it fast/slow for storing TO memory compared to np.savez_compressed?
Is there any way to index it non-randomly?

I have the same questions about pyarrow actually, if you know.

And is it compatible with video!

Is it fast/slow for storing TO memory compared to np.savez_compressed?

Not comparable, because the memory map is never loaded into memory fully. Only the sample you need is loaded into memory. For example, if you are training with batch size of 16, then you only need the memory of those 16 images. You don't load the full dataset into memory.

Is there any way to index it non-randomly?

What do you mean here?
And is it compatible with video!
Yes, of course. The memory map is initialized from a generator that returns samples as numpy arrays. What is the source of these does not matter.  Check this notebook for an example: https://colab.research.google.com/drive/1xMEHbwntgpBfCGfTicXmdbA8UpEowXzW?usp=sharing


ovnkube-node DaemonSet: Tolerate Everything?

What would you like to know?
ovnkube-node DaemonSet: Tolerate Everything?
Currently, the daemonset.apps/ovnkube-node uses a "tolerate everything" approach, and I wonder if there is a valid reason for it.
It seems that OpenShift also follows this pattern: OpenShift OVN-Kubernetes YAML.
For DaemonSets specifically, Kubernetes automatically adds the following tolerations to all Pods:

node.kubernetes.io/not-ready
node.kubernetes.io/unreachable
node.kubernetes.io/disk-pressure
node.kubernetes.io/memory-pressure
node.kubernetes.io/pid-pressure
node.kubernetes.io/unschedulable
node.kubernetes.io/network-unavailable (host-networked Pods only)

This behavior is documented here: Kubernetes DaemonSet Taints and Tolerations.
Isn't that sufficient? Can you think of a specific taint that would pose a problem for Pods created by any of the ovn-kubernetes DaemonSets?
If not, the "tolerate everything" approach for DaemonSets might not be necessary. What do you think?
Anything else we need to know?
No response

Hey @flavio-fernandes!
I think we need to tolerate all taints as otherwise there would be no overlay networking available on excluded nodes.
Users can create custom taints that we won't be able to predict.

Hey @flavio-fernandes! I think we need to tolerate all taints as otherwise there would be no overlay networking available on excluded nodes. Users can create custom taints that we won't be able to predict.

I see, @kyrtapz. In clusters where users can create unpredictable taints, using tolerate anything makes a lot of sense for ovn-k8s to ensure the CNI remains functional.


Deploy classified aggregator for Databricks [skip ci]

Fixes #9213
Signed-off-by: Gera Shegalov<EMAIL_ADDRESS>

build

build


Stores are not consistently sync/async

Right now, the MemoryStore implements synchronous callbacks whereas other modules typically use asynchronous callbacks. In order to make it possible to reason about the code flow, these should be consistently asynchronous (eg. using process.nextTick or setImmediate).
More about this can be found in this article.

Right now MemoryStore is basically just a Mock that I use for testing, and it's easier to use in that manner if it's synchronous (although my test coverage is probably not technically as good). It's really just for testing during development, it doesn't work at all in clustered deployments so it's not really production ready in my mind.
The synchronous vs async callbacks issue is really a bigger deal for threaded environments. As a general rule of thumb I feel like code that this behavior would break is bad, I can't think of an example (in node) where you couldn't just change the order of statements in order to account for immediate execution of the callback, and I think the other order (callback at the end) is easier to read.
That said, fixing it doesn't really hurt anything, and does prevent some possible bugs in apps people write using this. I would welcome a pull request if you have one, not sure when I'll get around fixing it just because I would likely need to re-work the tests to account for the async execution.

Adam

Right now MemoryStore is basically just a Mock that I use for testing, and it's easier to use in that manner if it's synchronous (although my test coverage is probably not technically as good). It's really just for testing during development, it doesn't work at all in clustered deployments so it's not really production ready in my mind.

Right, but even then this matters - see the article I linked. If one uses the MemoryStore during development and then replaces it with a different store in production, their code could break in production due to the difference in code execution behaviour.

The synchronous vs async callbacks issue is really a bigger deal for threaded environments.

Quite the contrary! This gist demonstrates the issue. It is applicable to any asynchronous environment, threaded or not.

As a general rule of thumb I feel like code that this behavior would break is bad, I can't think of an example (in node) where you couldn't just change the order of statements in order to account for immediate execution of the callback, and I think the other order (callback at the end) is easier to read.

The stores are supposed to be a 'black box' - they store your data somehow, but you shouldn't have to care about specifically how they store it. Having to change your code to account for differences in sync/async operation between stores, just makes it a leaky abstraction.

That said, fixing it doesn't really hurt anything, and does prevent some possible bugs in apps people write using this. I would welcome a pull request if you have one, not sure when I'll get around fixing it just because I would likely need to re-work the tests to account for the async execution.

I could send a pull request, but as I don't normally write automated tests, I would be unable to include asynchronous tests :)

That said, fixing it doesn't really hurt anything, and does prevent some possible bugs in apps people write using this. I would welcome a pull request if you have one, not sure when I'll get around fixing it just because I would likely need to re-work the tests to account for the async execution.<

I could send a pull request, but as I don't normally write automated tests, I would be unable to include asynchronous tests :)<

I can do it once my current pull request is resolved.

So, I've looked into this a bit in the mean-time, and I have a few more thoughts. Whether or not MemoryStore is actually consistently sync/async doesn't really matter because it's only meant to be called by ExpressBrute internals anyway, so it shouldn't affect end users. Likewise, whether ExpressBrute, as a middleware, calls next() immediately or not shouldn't have any impact on end user code. The only place I can think of where we run into issues is with the reset methods (both the one attached to req.brute.reset and the one on the ExpressBrute instance itself).
Because changing all of the MemoryStore calls to be consistently async requires almost all of the unit tests to be re-written (they are relying on the fact that it isn't to make testing easier). So far I've taken the half-step of just ensuring reset is consistently async. I think this addresses most of the end-user impact.
Having the tests fully async (as would be required to change MemoryStore calls to async) would definitely be better - but it would add enough complexity to testing that I'm punting on it right now. This is especially true because between jasmine 1 and jasmine 2 they are re-working how async testing works - and because I'd really like to switch to Mocha/Chai/Sinon at some point (which uses the 2.0 syntax).


⚠ Bofrost.de has degraded performance

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

HTTP code: 200
Response time: 835 ms

Resolved: Bofrost.de performance has improved in 577e695.


Problems when transferring data to other DB

Description
I use data transfer, but it doesn't work after the 23.3.0 update.
The Data Transfer pop-up window did not close and DBeaver did not stop. If you look at information_schema.PROCESSLIST, there is this phrase in INFO: /* ApplicationName=DBeaver 23.3.0 - SQLEditor <Script.sql>~, and the TIME value continues to increase.
It was working fine before the 23.3.0 version was updated...but not exactly, I had this problem after the update

DBeaver Version
Community 23.3.0
Operating System
Windows 10 Pro
Database and driver
DB: mysql8
MySQL driver: JDBC Type 4 driver for MySQL
Steps to reproduce
1.Select Query
2.Data transfer
3. Export target Tab/Table select/Next
4. Tables mapping Tab/Target container/DB Select
5. Disable Button
Additional context
No response

Hello @x2game625
Could you please provide a video of the issue?

A popup window appears on my screen, but I can't see it on the recording screen.
The subsequent screens were performed in the order of "Steps to reproduce".
After reproduction, it will look like the picture above
https://github.com/dbeaver/dbeaver/assets/19172606/d0e2e90e-0ad4-4e53-b9a3-8019ef243976

Please, provide the log files. You can find instructions here https://dbeaver.com/docs/wiki/Log-files/.

Reproduce the problem sequence and send the log file
.log

Could you please try to generate a thread dump and attach it here? Here is the instruction: https://dbeaver.com/docs/wiki/Making-a-thread-dump/

It's been a while since no update here. If the issue is still actual please let me know and provide thread dump.


Add InformationStateString to Connect Four

Add InformationStateString to Connect Four to as it is required to run Fictitious Play

Thanks! Will import it now, should go in on the next update.


Hubot pack

This PR adds the initial fixings for Hubot management via StackStorm.
Actions
+---------------+-------+---------+---------------------------------------------------+
| ref           | pack  | name    | description                                       |
+---------------+-------+---------+---------------------------------------------------+
| hubot.branch  | hubot | branch  | Determine which branch Hubot is currently running |
| hubot.deploy  | hubot | deploy  | Manage Hubot installs on a per-pack basis         |
| hubot.restart | hubot | restart | Restart hubot                                     |
+---------------+-------+---------+---------------------------------------------------+

Ugh. Got hue pack in here too. :/


Having two commands where one is a substring of the other doesn't work

If the shorter one is entered it will say Command not found: ..; Candidates:.

Thanks for report, please check if https://github.com/jedrzejboczar/easy-repl/pull/9 works as expected.


Clean up/destroy sharp instances

Is it possible explicitly clean up/destroy a sharp instance (when it is not needed anymore)?

A sharp instance is a standard JavaScript Object and therefore will be subject to garbage collection when no references remain.
libvips cache can be cleared via sharp.cache(false) - see http://sharp.dimens.io/en/stable/api/#sharpcacheoptions

Feel free to re-open if there are still further questions related to this.

This

A sharp instance is a standard JavaScript Object and therefore will be subject to garbage collection when no references remain.

We may mention this in the documentation and readme. I was in doubt if I need to explicitly call the destroy() method to free up the resources. (And didn't saw mention on this method in the documentation website and the readme)


[10.x] Prevent cache command with closure to being written

When running caching commands that serializes closure, the generated file will contain empty php code of Closure::__set_state. Then on the subsequent cache clear command, the app will throw on parsing said file. The solution now is to manually remove the cached files (config, event, and route).
This PR will prevent the file being generated in the first place, by trying to execute the generated var_export before returning to the caller.

I hope it doesn't interferes with https://packagist.org/packages/henzeb/var-export-wrapper
Which allows you to do just that. I will monitor this PR and update it accordingly when needed.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


Deprecate support for Python 3.7

In order to give users following the main branch even more of a "heads up" about the pending removal of Python 3.7 support, we can merge this PR immediately, which will warn them if they are using Python 3.7.  Then, we can wait and merge #80 later (in a few weeks, most likely), just before we want to add code that supports only Python 3.8 and higher.
I did not add a release note here, because we have no plans to make another release before dropping Python 3.7 support.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

3 of 4 (75.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 84.692%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

circuit_knitting_toolbox/init.py
3
4
75.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
1527

Relevant Lines:
1803

💛  - Coveralls


Write test cases for isValidTitleForProject() in projectResolver.test.ts

@divine-comedian No tests for this function, leave open


Rate limit mirror

This is a PR for https://github.com/zulip/zulip/issues/2420
This rate limits the email mirror per realm using the same mechanism as the original rate limiter for views. Detailed explanation in the message in the first commit. This is implemented per-realm as Tim suggested this as a reasonable approach in a chat.
Testing: First of all test_mirror_worker_rate_limiting should be doing a decent job at testing this works as it should. Beyond that, with the aid of the second commit this can be tested manually in the dev environment, by setting RATE_LIMITING_MIRROR_REALM_RULES to something low, like "max 2 emails per 3 minutes" and then using send_to_email_mirror:
./manage.py send_to_email_mirror --fixture=zerver/tests/fixtures/email/1.txt
multiple times while the server is running and seeing that emails get blocked after the limit is reached, and then after the appropriate amount of time passes, they start going through again, and rate limiting works as it should.
NOTE: I have no idea what is a sensible default for this. I just set it to "50 emails max (per realm) every 5 minutes" in settings.py, but this should probably be adjusted by someone who has a better sense here.

Added a small commit to add coverage for an uncovered case in the original rate limiter in rate_limit_user. Not exactly very relevant to this PR, but maybe it's mergeable.

This is awesome, thanks @mateuszmandera!  I posted a batch of comments on changes needed to merge this PR.  And since you seem to understand our rate limiting system pretty well now, I think  https://github.com/zulip/zulip/issues/5677 would be a super awesome project for you to tackle next.  There's an old open PR for it, https://github.com/zulip/zulip/pull/5880, which as you can see was pretty troubled and we were unable to get into a good state (and I would not base your work directly on).  But there's a lot of great commentary Greg Price on what the right design for this is.

@timabbott I added the requested adjustments.

Nice, merged, thanks @mateuszmandera!


Python autocomplete seems to be messed up

I am writing in Python. When the autocomplete menu appears I used to navigate with the arrows, select the proper solution and hit enter to insert it.
This behavior has ceased now and I am unable to find a constant way to select the proper proposal and insert it.
TAB is a safe selector and more convenient, but when it comes to insertion, sometimes is achieved when I continue typing, some other times is achieved when I hit <ctrl>k, some others when I hit the right arrow. However, no one guarantees that the current working solution will work in the next menu appearance.
Is this an issue or just a new behavior in which I am not accustomed?

In my case https://github.com/spf13/spf13-vim/issues/784 removing jiangmiao/auto-pairs solved the problem. So try removing  jiangmiao/auto-pairs from bundle.

Thank you, it works!
I was aware of case #784 and I tried to remove auto-pairs before, but I did not succeed because:

After deletion, the folder .vimviews has to be cleaned manually
In my .vimrc I had imapped the arrows to scroll by visual lines.

Everything works great now. :+1:


update tape to v5 and fix a new broken case

1st test (I just updated tape, and then something started breaking, see the CI logs), 2nd fix

I will do a proper review of this a bit later. Will just add that I ran this on the tests in muxrpc and they are still parsing.


Bad rows, regex fails to parse user-agent.

I am seeing about 5% of my records marked as bad because the user agent parsing fails. Example:
{
    "line": {
        "timestamp":<PHONE_NUMBER>568,
        "collector": "ssc-0.1.0-kinesis",
        ...
        "headers": [..., "User-Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko", ...],
        "networkUserId": "7e98e0a0-e316-40ae-94f4-5a723264397c",
		....
        "setNetworkUserId": true
    },
    "errors": ["Exception parsing useragent [Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko]: [No group 1]"]
}

Can I close this? I think it's covered by #62 and #792.

Plus the underlying bug was fixed in user-agent utils 1.12, which @pkallos pulled in via #662. So yes let's close.

Cleared milestone too


Invalid --autoplay / -A in librespot

Compatible Device

[X] I'm running Raspotify on a compatible Device

Are you sure?

[X] I'm not trying to run Raspotify on a ARMv6 device

Compatible OS

[X] I'm running Raspotify on a compatible OS

Compatible Configuration

[X] I'm running Raspotify on a compatible Configuration

Latest Version

[X] I'm running the latest version of Raspotify

Are you sure?

[X] I'm not running Raspotify <IP_ADDRESS> on a Pi v1 or Pi Zero

Due Diligence

[X] I have done my due diligence

What happened?
Raspotify worked for years and stopped today.
service raspotify status shows:
set 18 09:38:08 raspberrypi systemd[1]: Started Raspotify (Spotify Connect Client).
set 18 09:38:08 raspberrypi librespot[7213]: [2024-09-18T12:38:08Z ERROR librespot] Invalid --autoplay / -A: ""
set 18 09:38:08 raspberrypi librespot[7213]: Valid --autoplay / -A values: on, off
set 18 09:38:08 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
set 18 09:38:08 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'.
set 18 09:38:08 raspberrypi systemd[1]: raspotify.service: Triggering OnFailure= dependencies.
Relevant log output and/or the contents of /etc/raspotify/crash_report if any ( sudo journalctl -u raspotify -b and sudo cat /etc/raspotify/crash_report )
-- System Info --

Linux raspberrypi 6.1.21-v7+ #1642 SMP Mon Apr  3 17:20:52 BST 2023 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

-- Logs --

set 18 09:37:10 raspberrypi librespot[5420]: [2024-09-18T12:37:05Z ERROR librespot] Invalid `--autoplay` / `-A`: ""
set 18 09:37:10 raspberrypi librespot[5420]: Valid `--autoplay` / `-A` values: on, off
set 18 09:37:05 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
set 18 09:37:05 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'.
set 18 09:37:05 raspberrypi systemd[1]: raspotify.service: Triggering OnFailure= dependencies.
set 18 09:37:21 raspberrypi systemd[1]: Started Raspotify (Spotify Connect Client).
set 18 09:37:21 raspberrypi librespot[5784]: [2024-09-18T12:37:21Z ERROR librespot] Invalid `--autoplay` / `-A`: ""
set 18 09:37:21 raspberrypi librespot[5784]: Valid `--autoplay` / `-A` values: on, off
set 18 09:37:21 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
set 18 09:37:21 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'.
set 18 09:37:21 raspberrypi systemd[1]: raspotify.service: Triggering OnFailure= dependencies.
set 18 09:37:33 raspberrypi systemd[1]: Started Raspotify (Spotify Connect Client).
set 18 09:37:33 raspberrypi librespot[6142]: [2024-09-18T12:37:33Z ERROR librespot] Invalid `--autoplay` / `-A`: ""
set 18 09:37:33 raspberrypi librespot[6142]: Valid `--autoplay` / `-A` values: on, off
set 18 09:37:33 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
set 18 09:37:33 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'.
set 18 09:37:33 raspberrypi systemd[1]: raspotify.service: Triggering OnFailure= dependencies.
set 18 09:37:44 raspberrypi systemd[1]: Started Raspotify (Spotify Connect Client).
set 18 09:37:44 raspberrypi librespot[6499]: [2024-09-18T12:37:44Z ERROR librespot] Invalid `--autoplay` / `-A`: ""
set 18 09:37:44 raspberrypi librespot[6499]: Valid `--autoplay` / `-A` values: on, off
set 18 09:37:44 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
set 18 09:37:44 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'.
set 18 09:37:44 raspberrypi systemd[1]: raspotify.service: Triggering OnFailure= dependencies.
set 18 09:37:56 raspberrypi systemd[1]: Started Raspotify (Spotify Connect Client).
set 18 09:37:56 raspberrypi librespot[6856]: [2024-09-18T12:37:56Z ERROR librespot] Invalid `--autoplay` / `-A`: ""
set 18 09:37:56 raspberrypi librespot[6856]: Valid `--autoplay` / `-A` values: on, off
set 18 09:37:56 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
set 18 09:37:56 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'.
set 18 09:37:56 raspberrypi systemd[1]: raspotify.service: Triggering OnFailure= dependencies.
set 18 09:38:08 raspberrypi systemd[1]: Started Raspotify (Spotify Connect Client).
set 18 09:38:08 raspberrypi librespot[7213]: [2024-09-18T12:38:08Z ERROR librespot] Invalid `--autoplay` / `-A`: ""
set 18 09:38:08 raspberrypi librespot[7213]: Valid `--autoplay` / `-A` values: on, off
set 18 09:38:08 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE
set 18 09:38:08 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'.
set 18 09:38:08 raspberrypi systemd[1]: raspotify.service: Triggering OnFailure= dependencies.

-- Config --

LIBRESPOT_QUIET=
LIBRESPOT_AUTOPLAY=
LIBRESPOT_DISABLE_AUDIO_CACHE=
LIBRESPOT_DISABLE_CREDENTIAL_CACHE=
LIBRESPOT_NAME="Raspotify (Boxe)"
LIBRESPOT_DEVICE="plughw:CARD=Headphones,DEV=0"
LIBRESPOT_INITIAL_VOLUME="100"

-- Ouput of aplay -l --

**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

-- Ouput of aplay -L --

null
    Discard all samples (playback) or generate zero samples (capture)
lavrate
    Rate Converter Plugin Using Libav/FFmpeg Library
samplerate
    Rate Converter Plugin Using Samplerate Library
speexrate
    Rate Converter Plugin Using Speex Resampler
jack
    JACK Audio Connection Kit
oss
    Open Sound System
pulse
    PulseAudio Sound Server
upmix
    Plugin for channel upmix (4,6,8)
vdownmix
    Plugin for channel downmix (stereo) with a simple spacialization
hw:CARD=Headphones,DEV=0
    bcm2835 Headphones, bcm2835 Headphones
    Direct hardware device without any conversions
plughw:CARD=Headphones,DEV=0
    bcm2835 Headphones, bcm2835 Headphones
    Hardware device with all software conversions
default:CARD=Headphones
    bcm2835 Headphones, bcm2835 Headphones
    Default Audio Device
sysdefault:CARD=Headphones
    bcm2835 Headphones, bcm2835 Headphones
    Default Audio Device
dmix:CARD=Headphones,DEV=0
    bcm2835 Headphones, bcm2835 Headphones
    Direct sample mixing device
usbstream:CARD=Headphones
    bcm2835 Headphones
    USB Stream Output
hw:CARD=vc4hdmi,DEV=0
    vc4-hdmi, MAI PCM i2s-hifi-0
    Direct hardware device without any conversions
plughw:CARD=vc4hdmi,DEV=0
    vc4-hdmi, MAI PCM i2s-hifi-0
    Hardware device with all software conversions
default:CARD=vc4hdmi
    vc4-hdmi, MAI PCM i2s-hifi-0
    Default Audio Device
sysdefault:CARD=vc4hdmi
    vc4-hdmi, MAI PCM i2s-hifi-0
    Default Audio Device
hdmi:CARD=vc4hdmi,DEV=0
    vc4-hdmi, MAI PCM i2s-hifi-0
    HDMI Audio Output
dmix:CARD=vc4hdmi,DEV=0
    vc4-hdmi, MAI PCM i2s-hifi-0
    Direct sample mixing device
usbstream:CARD=vc4hdmi
    vc4-hdmi
    USB Stream Output

-- Ouput of librespot -d ? --

        Compatible alsa device(s):

        ------------------------------------------------------

        Device:

                hw:CARD=Headphones,DEV=0

        Description:

                bcm2835 Headphones, bcm2835 Headphones
                Direct hardware device without any conversions

        Supported Format(s):

                S16

        ------------------------------------------------------

        Device:

                plughw:CARD=Headphones,DEV=0

        Description:

                bcm2835 Headphones, bcm2835 Headphones
                Hardware device with all software conversions

        Supported Format(s):

                S16 S24 S24_3 S32 F32 F64

        ------------------------------------------------------

        Device:

                default:CARD=Headphones

        Description:

                bcm2835 Headphones, bcm2835 Headphones
                Default Audio Device

        Supported Format(s):

                S16 S24 S24_3 S32 F32 F64

        ------------------------------------------------------

        Device:

                sysdefault:CARD=Headphones

        Description:

                bcm2835 Headphones, bcm2835 Headphones
                Default Audio Device

        Supported Format(s):

                S16 S24 S24_3 S32 F32 F64

        ------------------------------------------------------

        Device:

                default:CARD=vc4hdmi

        Description:

                vc4-hdmi, MAI PCM i2s-hifi-0
                Default Audio Device

        Supported Format(s):

                S16 S24 S24_3 S32 F32 F64

        ------------------------------------------------------

        Device:

                sysdefault:CARD=vc4hdmi

        Description:

                vc4-hdmi, MAI PCM i2s-hifi-0
                Default Audio Device

        Supported Format(s):

                S16 S24 S24_3 S32 F32 F64

        ------------------------------------------------------

        Device:

                hdmi:CARD=vc4hdmi,DEV=0

        Description:

                vc4-hdmi, MAI PCM i2s-hifi-0
                HDMI Audio Output

        Supported Format(s):

                S16 S24 S24_3 S32

        ------------------------------------------------------

Having the same issue on RPi 3b+ after the 0.44 update.
Sep 18 16:06:01 raspberrypi systemd[1]: raspotify-crash-report-generator.service: Consumed 1.562s CPU time. Sep 18 16:06:01 raspberrypi librespot[9095]: [2024-09-18T13:06:01Z ERROR librespot] Invalid --autoplay/-A: "" Sep 18 16:06:01 raspberrypi librespot[9095]: Valid --autoplay/-A values: on, off Sep 18 16:06:01 raspberrypi systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE Sep 18 16:06:01 raspberrypi systemd[1]: raspotify.service: Failed with result 'exit-code'. Sep 18 16:06:01 raspberrypi systemd[1]: raspotify.service: Triggering OnFailure= dependencies. Sep 18 16:06:01 raspberrypi systemd[1]: Starting Raspotify Crash Report Generator...

I can confirm I've got the same issue.
Also huge thanks for the effort non the less

If you want a quick fix for your local environment open /etc/raspotify/conf and just set LIBRESPORT_AUTOPLAY to on or off:
LIBRESPOT_AUTOPLAY=on

LIBRESPORT_AUTOPLAY

I confirm adding LIBRESPOT_AUTOPLAY="on" at the end of /etc/raspotify/conf fixed.

@bvdf0251 For me commenting it also works, you just need to run sudo systemctl restart raspotify in order for the config to be re-applied

With this addition it's showing me an error 'failed to register ipv6 receiver' and I can't connect from my phone.

I'm assuming that this is an issue with 0.44.0 after #672
As everything was working for me before upgrading from 0.43.x (can't remember the exact version)
If so, can we include this a requirement in the release notes.

With this addition it's showing me an error 'failed to register ipv6 receiver' and I can't connect from my phone.

Fixed by enabling ipv6
Still not working though. It's starting but unable to connect from phone.
Downgrade to latest 0.43 still working.


size_t / lua_Integer conversion problem

i'm trying to port some code from luabind to sol. however there's one issue where i'm not sure how to resolve: some of this code return size_t(-1) to represent "invalid" indices, similar to std::string::npos.
the problem is that unqualified_pusher::push performs a range check on the integer (stack_detail::integer_value_fits) and for my out-of-range values it would convert the value to lua_Number. i wonder what's a good approach for such a use-case? i could remove the std::is_signed_v<T> check from integer_value_fits, but maybe there's a better way to achieve this?
Originally posted by @timblechmann in https://github.com/ThePhD/sol2/discussions/1176

@ThePhD wrote:

By the time the number gets to me (is handed to sol2), it's an unsigned value. I can't tell that the "intent" is for it to be a sentinel value of -1; I just see a heckin' gigantic positive number.

yes, i know it's a tricky issue and there are good reasons for the current behaviour. unfortunately i cannot easily migrate the codebase away from using size_t(-1)

Lua since Lua 5.3 has LUA_MAXINTEGER and LUA_MININTEGER and a concept of 63-bit unsigned integers. What version of Lua are you using? Maybe there's something I can do to specialize for Lua 5.3 and above to give pass-through integer access here.

i'm trying to port from luabind/lua5.1 to sol/lua5.4. so lua-5.3 would possible. are you thinking about exposing LUA_UNSIGNED to sol?

my current approach:
diff --git a/include/sol/stack_push.hpp b/include/sol/stack_push.hpp
index afb9985..0c7a736 100644
--- a/include/sol/stack_push.hpp
+++ b/include/sol/stack_push.hpp
@@ -45,7 +45,11 @@ namespace sol { namespace stack {
        namespace stack_detail {
                template <typename T>
                inline bool integer_value_fits(const T& value) {
+#if defined(SOL_LUAINTEGER_SIZET_SUPPORT)
+                       if constexpr (sizeof(T) < sizeof(lua_Integer) || (sizeof(T) == sizeof(lua_Integer))) {
+#else
                        if constexpr (sizeof(T) < sizeof(lua_Integer) || (std::is_signed_v<T> && sizeof(T) == sizeof(lua_Integer))) {
+#endif
                                (void)value;
                                return true;
                        }

Seems reasonable enough, lemme push something out quickly before the end of today.

"I'll push something tonight" ahhahahahhahaaaaaaaaaaaaa
aah.... sorry.
It's fixed, define SOL_ALL_INTEGER_VALUES_FIT to 1 to get this turned up!


Correct path in console command

I signed it!

I think maybe your git checkout is stale?

Shouldn't be, I just hit the edit button on the repo here when the patch was created.  When browsing the docs at http://kubernetes.io/v1.0/docs/user-guide/downward-api/README.html the example refers to the docs path, but when a release is downloaded the docs folder isn't included but all of the referenced examples are in the examples folder.  So in a lot of places where I was copy/pasting things, I was getting file not found errors because of that path use.

Ahh, yeah. docs were updated after release of the binaries :(  Our bad.
On Thu, Jul 23, 2015 at 10:05 AM, Michael Babker<EMAIL_ADDRESS>wrote:

Shouldn't be, I just hit the edit button on the repo here when the patch
was created. When browsing the docs at
http://kubernetes.io/v1.0/docs/user-guide/downward-api/README.html the
example refers to the docs path, but when a release is downloaded the docs
folder isn't included but all of the referenced examples are in the
examples folder. So in a lot of places where I was copy/pasting things, I
was getting file not found errors because of that path use.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11753#issuecomment-124168450
.


Add schema validation on DeserializeFromFilePath

Add schema validation on DeserializeFromFilePath in order to get better error messages when the struxml does not load properly.

@Marco-Pellegrino Do you want to include this in 21.6.0?
https://github.com/strusoft/femdesign-api/blob/e297e4824f4a2d752e2f585f57da7c4d6e0d2d83/FemDesign.Core/Model/Model.cs#L204-L220

Sure (I believe you have tested it)

it will not be merged as the error raised by the xml validate is not clear for the user


Add netlify-pages and netlify-cms in docs

Thanks! (I will make minor changes before putting this online).

Your are welcome. Of course, maybe I did not respect your docs guideline very well

No everything is fine, I will just change url I think (and replace # (h1), by ## (h2) as the h1 is the 'title') ;)

Great, thank you


ZFP Compression

I just learned about a new compression library called ZFP: https://github.com/LLNL/zfp

zfp is an open source C/C++ library for compressed numerical arrays that support high throughput read and write random access. zfp also supports streaming compression of integer and floating-point data, e.g., for applications that read and write large data sets to and from disk.
zfp was developed at Lawrence Livermore National Laboratory and is loosely based on the algorithm described in the following paper:
Peter Lindstrom
"Fixed-Rate Compressed Floating-Point Arrays"
IEEE Transactions on Visualization and Computer Graphics
20(12):2674-2683, December 2014
doi:10.1109/TVCG.2014.2346458

zfp was originally designed for floating-point arrays only, but has been extended to also support integer data, and could for instance be used to compress images and quantized volumetric data. To achieve high compression ratios, zfp uses lossy but optionally error-bounded compression. Although bit-for-bit lossless compression of floating-point data is not always possible, zfp is usually accurate to within machine epsilon in near-lossless mode.
zfp works best for 2D and 3D arrays that exhibit spatial correlation, such as continuous fields from physics simulations, images, regularly sampled terrain surfaces, etc. Although zfp also provides a 1D array class that can be used for 1D signals such as audio, or even unstructured floating-point streams, the compression scheme has not been well optimized for this use case, and rate and quality may not be competitive with floating-point compressors designed specifically for 1D streams.
zfp is freely available as open source under a BSD license, as outlined in the file 'LICENSE'. For more information on zfp and comparisons with other compressors, please see the zfp website. For questions, comments, requests, and bug reports, please contact Peter Lindstrom.

It would be excellent to add ZFP compression to Zarr! What would be the best path towards this? Could it be added to numcodecs?

It looks like there are already some python/numpy bindings: https://github.com/seung-lab/fpzip

Hi Ryan, to implement a new codec you just need to implement the
numcodecs.abc.Codec interface:
https://numcodecs.readthedocs.io/en/latest/abc.html
...then register your new codec class with a call to register_codec():
https://numcodecs.readthedocs.io/en/latest/registry.html#numcodecs.registry.register_codec
If you want to just try this out as an experiment, you could just knock up
a codec implementation in a notebook or wherever, using the Python bindings
for zfp the codec implementation would be very simple. I'd suggest getting
some benchmark results showing useful speed and/or compression ratio, then
consider adding to numcodecs if it looks promising.
If this did look a useful addition to numcodecs, couple of things I noticed
from a quick glance at the source for the Python bindings. First it expects
arrays of at least 3 and at most 4 dimensions. Don't know if this is a
constraint might be good to relax. Also it converts data to Fortran order
before compression, which will mean an extra data copy for most users where
data is usually in C order. This may be a hard requirement of the zfp
library, and so unavoidable, but just something to note.
On Mon, 15 Oct 2018, 16:57 Joe Hamman<EMAIL_ADDRESS>wrote:

It looks like there are already some python/numpy bindings:
https://github.com/seung-lab/fpzip
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/zarr-developers/zarr/issues/307#issuecomment-429911840,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq8QkUZrTh_hJbm34GeyCQNcHiCPuV3ks5ulLCGgaJpZM4XceDs
.

Digging deeper, it looks like fpzip does not support missing data: https://zfp.readthedocs.io/en/release0.5.4/directions.html#directions
This is a dealbreaker for now (at least for me), but it looks like it might be addressed soon.

How do you handle missing data with Zarr currently?

@rabernat I'm the author of the fpzip python bindings. I think you may be conflating zfp and fpzip. fpzip is a lossless codec while zfp isn't. Try the following:
import fpzip
import numpy as np

x = np.array([[[ np.nan ]]], dtype=np.float32)
y = fpzip.compress(x)
z = fpzip.decompress(y)
print(z)

Also, if you guys find fpzip interesting, I'd be happy to add support for more flexible support for Fortran vs C order. I don't think it's a hard constraint, it's just what I got working for my use case.

Also, in case this was not clear, I am basically not getting any compression of either dataset with fpzip using the default precision:
>>> len(fpzip.compress(data_sst))/data_sst.nbytes
1.0000054012345678
>>> len(fpzip.compress(data_ssh))/data_ssh.nbytes
1.0000054012345678

Am I doing something wrong?

I just updated fpzip to version 1.1.1 that should have the trailing zeros problem fixed. Give it a try again!

@rabernat, I'm the developer of fpzip (and zfp).  Having worked a lot with climate scientists, I would certainly expect high-resolution ocean data like yours to compress quite well (definitely to less than 100%!).  @william-silversmith, who has done a great job adding a Python interface to fpzip, reports a reduction to 63% after his latest fix, which seems more plausible.  Perhaps you can give fpzip another try?
If you're willing to sacrifice some loss to within some acceptable error tolerance, then I would suggest checking zfp out.  It's a far faster and more advanced compressor than fpzip.

Hi @lindstro -- thanks for droping in here. And most of all, thanks for your important work on compression! As a computational oceanographer, I recognize that this is really crucial for the future sustainability of high-resolution modeling.
I updated my analysis with the latest version of fpzip. Indeed it actually compresses the data now! 😉
Here is a figure which summarizes the important results. In contrast to my previous figure, I have eliminated the precision argument for fpzip and am using it as intended: lossless mode (directly comparable to zstd).

In terms of compression ratio, fpzip beats zstd when there is no land mask (holds regardless of the zstd level). With a land mask, zstd is able to do a bit better. zstd is a lot faster, particularly on decoding, but that is not a dealbreaker for us. (50 MB/s is still fast compared to network transfer times.)
Based on this analysis, I think we definitely want to add fpzip support to numcodecs.

If you're willing to sacrifice some loss to within some acceptable error tolerance, then I would suggest checking zfp out. It's a far faster and more advanced compressor than fpzip.

Yes we would love to try zfp. Is there a python wrapper for it yet?

Another point about fpzip: compression ratio is considerably higher (0.4 vs 0.55) if I transpose the arrays from their native python / C order to Fortran order when I feed them in. @william-silversmith -- I notice you have added the order keyword to fpzip.decompress but not to fpzip.compress. Would it be possible to add support for compression of C-order arrays? This would allow us to avoid the manual transpose step at the numcodecs level.

If there are existing python wrappers then I'd suggest to use those, at
least as a first pass - can always optimise later if there is room for
improvement. PRs to numcodecs for fpzip and zfp would be welcome.
On Wed, 7 Nov 2018, 15:23 Ryan Abernathey<EMAIL_ADDRESS>wrote:

@alimanfoo https://github.com/alimanfoo - presuming we want to move
forward with adding fpzip and zfp to numcodecs, what would be the best
path. Would you want to use @william-silversmith
https://github.com/william-silversmith's python package, or would you
want to re-wrap the C code within numcodecs, as currently done for c-blosc?
The latter approach would also allow us to use zfp without an independent
python implementation. But it is a lot more work. Certainly not something I
can volunteer for.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zarr-developers/zarr/issues/307#issuecomment-436660574,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq8QqIqooHdlM0F2h0PHbVDubZlr1kqks5usvsOgaJpZM4XceDs
.

@rabernat, thanks fore rerunning your compression study.  fpzip was developed back in 2005-2006, when 5 MB/s was fast.  I've been meaning to rewrite and parallelize it, but I've got my hands full with zfp development.
Regarding transposition, clearly we'd want to avoid making a copy.  fpzip and zfp both use the convention that x varies faster than y, which varies faster than z.  So an array of size nx * ny * nz should have a C layout
float array[nz][ny][nx];
@william-silversmith's Python wrappers should ideally do nothing but pass the array dimensions to fpzip in the "correct" order and not physically move any data.  zfp (but not fpzip) also supports strided access to handle arrays of structs without having to make a copy.
As far as Python wrappers for zfp, we're just now starting on that and have an end-of-the-year milestone to deliver such a capability.  The developer working on this has suggested using cffi.  As I'm virtually Python illiterate, I'm not sure how that would interact with numcodecs.  Any suggestions are welcome.

For numcodecs it doesn't matter how you wrap zfp. As long as the zfp python
module provides a compress() function that accepts any python object that
implements the buffer protocol and returns a python object that implements
the buffer protocol (e.g., bytes), and similar for decompress(). And in
both cases minimises memory copies, i.e., use the buffer protocol to read
data directly from the buffers exposed by the python objects.
On Wed, 7 Nov 2018, 16:51 Peter Lindstrom<EMAIL_ADDRESS>wrote:

@rabernat https://github.com/rabernat, thanks fore rerunning your
compression study. fpzip was developed back in 2005-2006, when 5 MB/s was
fast. I've been meaning to rewrite and parallelize it, but I've got my
hands full with zfp development.
Regarding transposition, clearly we'd want to avoid making a copy. fpzip
and zfp both use the convention that x varies faster than y, which varies
faster than z. So an array of size nx * ny * nz should have a C layout
float array[nz][ny][nx];
@william-silversmith https://github.com/william-silversmith's Python
wrappers should ideally do nothing but pass the array dimensions to fpzip
in the "correct" order and not physically move any data. zfp (but not
fpzip) also supports strided access to handle arrays of structs without
having to make a copy.
As far as Python wrappers for zfp, we're just now starting on that and
have an end-of-the-year milestone to deliver such a capability. The
developer working on this has suggested using cffi. As I'm virtually Python
illiterate, I'm not sure how that would interact with numcodecs. Any
suggestions are welcome.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zarr-developers/zarr/issues/307#issuecomment-436694477,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq8QgLIbCWX8I2K6mObZKt9Mw_Ucum-ks5usw-YgaJpZM4XceDs
.


Lidar readings aren't plotted relative to the robot

The lidar works but the readings appear to plotted in global space, instead of relative to the robot. It means if you go too far away from the origin lidar readings are no longer plotted.

Instead of rotating the laser, rotate the cast to vector:
var point_laser = Vector3(max_range,0,0)
ray.set_cast_to(point_laser.rotated(Vector3(0,1,0),deg2rad(counter)))
However, the origin of the laser still looks off and needs to be fixed and weirder things happen when you try to move the robot.

Also counter is set to 0 after it reaches 360 deg; it would be good to use the value of counter (modulus 360) rather than setting it to zero as otherwise the laser could be going in a different direction for a short while (e.g. 365 -> 0).

Hi @kirstyaquilina and @blueicefrog, I've given @MihaiAnca13 this issue because he was looking for things to do but if either of you still wanted to contribute towards the LIDAR development let me know :)

head_location = $LidarBody/Head.global_transform.origin
This should be updated in the process as well.

@jhird11 I've just pushed some changes to the develop-fix-lidar branch. It's now working as intended thanks to @kirstyaquilina's comments.
I think there's still work to be done for the occupancy map texture, but I haven't had time to look into it for now.

Ah good stuff! I've just had a look and the weird spinning definitely seems to of been fixed, good job!
I just pushed a draft version of mission 1 onto the master branch to test the lidar in if you'd like to test its operation in a more realistic setting :)

The LIDAR readings should now be updating relative to the robot on the following PR:
https://github.com/FARSCOPE-UKRAS-Festival-Game-Dev/Robot-Explore-Game/pull/39


Automatically exclude spec.ts files from Nitro server bundling

Which scope/s are relevant/related to the feature request?
vite-plugin-nitro
Information
Background
If a user creates any unit test files (spec.ts or otherwise) under any paths in src/server that Nitro checks when bundling the server the unit test code will be bundled into the server application. This can lead to the built server crashing it attempts to run the unit test code. In my scenario, this happened when the vitest library identified that it was being imported / used without being invoked by the vitest executable.
Nitro does not check whether a file has a typical unit test file extension when scanning for files. They simply look for any valid JS or TS based file / module.. Unit test files by nature are valid modules.
Currently it is up to the user to configure Nitro to ignore any files to exclude during bundling. The Nitro config has an ignore property that accepts an array of glob patterns to ignore from scan results. Adding an exclude of **/*.spec.ts ignores bundling all spec.ts files under the server directory.
Proposal
Add an ignore pattern of **/*.spec.ts when configuring Nitro as a default configuration for all analog projects.
In addition to spec.ts files other common unit test related file names / extensions could be ignored, such as test.ts, mock.ts, and mocks.ts.
Rationale In Favor
Co-locating spec.ts files is a very common pattern used in the angular ecosystem.
New analog users do not have an understanding of all the technologies used in analog and how they integrate together. Due to this it is easy for someone to place unit test files within the Nitro server directory, causing their unit test code to be bundled into their application, and leading to the application crashing when run. The user then needs to analyze the analog stack to understand why the server is failing, why unit test code is being included in their application code, which library/framework dependency is responsible, and how the dependencies need to be configured to avoid bundling test code. This all may lead to a lot of confusion, technical overhead, and frustration for people new to analog and its technologies.
Defaulting to ignoring **/*.spec.ts files allows the common co-location pattern to be used without a second thought by new analog users.
Rationale Against
Co-locating unit test files is just one of many valid patterns for structuring/organizing tests. By no means is it the one and only way things could or should be done.
One key issue with adding this default ignore is that a valid route named e.g. /spec would not be able to be created. For this reason alone I question if setting a default is the right approach. However, I think the value may outweigh this route naming concern.
Additionally, just because a default ignore may be supplied doesn't mean analog cannot allow the user to remove the ignore and fully override what is ignored, similar to how the user can configure which routes to prerender.
Alternative 1 - Documentation
Listing this as an alternative, but it should be done in all paths. The analog site should clearly document how Nitro is used and may be configured an analog application. I see this being an extension of #812 which only mentions the analog and angular vite plugin currently.
Specific to this unit test scenario we should ensure the documentation calls out that unit test files will be bundled if co-located under the server directories Nitro scans and that configuration would be needed to exclude these files, whether via the default or as an added configuration on a per-project basis.
Alternative 2 - Different Test File Organization Pattern
This whole request / issue stems from the pattern of co-locating test code directly with the application code. Instead of this pattern analog could recommend a different pattern for organizing the server tests, possibly the angular app tests too.
One option would be to add a tests directory within the analog project that can mirror how src is organized, so tests/server, tests/server/routes, tests/app, and similar. Another is to place a tests directory under the server directory that can mirror the structure under the server directory, so server/tests, server/tests/routes, and similar.
Additional Thoughts
Experimenting with and learning how testing is set up in analog today, I have been thinking there would be value in having a different test setup for the server code compared to the app / frontend code.
The out-of-the-box test setup and execution is very angular / frontend focused, patching vitest for zone support and configuring the TestBed as well. Additionally, tests are run via the jsdom environment.
Testing Nitro server code does not require zone and TestBed. The server tests may be run in the jsdom environment without issue, but jsdom is inherently slower and has more overhead instantiating the DOM than using the node environment . This, along with the unit test file bundling, is enough to make me think testing in analog could/should be thought through further.
At minimum I'd like to see more documentation, details, and recommendations on how to go about testing an analog application. Additionally, I'd also love for the framework to make it as simple and "dumb" as possible to do things, including testing. If this means prescribing exactly how / what / where tests should be placed, developed, etc. then I think that would be a beneficial thing for analog.
I will caveat all this with saying this is my first venture into any meta-framework, and definitely my first time looking to develop tests for both frontend and backend code that do not have some logical separation, such as being different libraries or different repositories. I'm not sure if there are other common patterns in the ecosystem from other frameworks that may work well here in the analog space.
Describe any alternatives/workarounds you're currently using
No response
I would be willing to submit a PR to fix this issue

[X] Yes
[ ] No

I think adding defaults to the ignore configuration in Nitro would be ideal and commonly expected. A /spec folder should still be recognized, but any .spec.ts files within that folder should be ignored.


ESA codebase and AIO deployment fine-tuning

AIO:

Removed OPC simulator
Restored spn-obj-id
Adjusted single node size and specs (CPU, mem, ssd)

ESA

Started environment configuration (config.json and RP).

closed by #2454


feature: Store API: do not statically encode the attestation format

The attestation format must not be statically encoded in the protobuf definition because this forces all the attestation formats that a plugin may supply to be known at compile time.

Addressed by https://github.com/veraison/services/pull/100


Fix large allocations

This PR fixes an issue where large allocations are currently causing some arithmetic to wrap which caused a panic.
This was discovered by calling http_get on youtube.com from the http example in the Rust PDK

merging so I can get it in the latest release! (working on CI right now and this is a good one to roll out :) )

Oh wait I was about to push one more commit!

There is still time! 😆 sorry about that. new PR?

:+1: just made a new PR


Unable to apply remote (http) script from init.d after upgrade to 4.2

We apply some repository setup scripts from our git server to have a consistent setup and minimize duplication. This works in versions prior to 4.2, but fails after upgrading the wrapper.
Error output from 4.2 wrapper below:
λ gradlew clean

FAILURE: Build failed with an exception.

* Where:
Initialization script 'C:\Users\chris\.gradle\init.d\include-shared.gradle' line: 2

* What went wrong:
A problem occurred evaluating initialization script.
> Could not read 'http://git/dezide/gradle-shared/raw/master/init.d/include-shared-scripts.gradle' as it does not exist.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 1s

The script file is available and the error goes away if I revert back to 4.1 or 4.0

Looks like a known bug. Could you please try to remove ~/.gradle/caches/modules-2/metadata-2.24/artifact-at-url.bin and try with 4.2 again?

@cpoulsen-dezide Please provide the full stacktrace, otherwise it is hard to tell where the problem is coming from.

λ gradlew clean --stacktrace

FAILURE: Build failed with an exception.

* Where:
Initialization script 'C:\Users\chris\.gradle\init.d\include-shared.gradle' line: 2

* What went wrong:
A problem occurred evaluating initialization script.
> Could not read 'http://git/dezide/gradle-shared/raw/master/init.d/include-shared-scripts.gradle' as it does not exist.

* Try:
Run with --info or --debug option to get more log output.

* Exception is:
org.gradle.api.GradleScriptException: A problem occurred evaluating initialization script.
        at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:92)
        at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl$2.run(DefaultScriptPluginFactory.java:202)
        at org.gradle.configuration.DefaultScriptTarget.addConfiguration(DefaultScriptTarget.java:74)
        at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:207)
        at org.gradle.configuration.BuildOperationScriptPlugin$1.run(BuildOperationScriptPlugin.java:61)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.configuration.BuildOperationScriptPlugin.apply(BuildOperationScriptPlugin.java:58)
        at org.gradle.configuration.DefaultInitScriptProcessor.process(DefaultInitScriptProcessor.java:49)
        at org.gradle.initialization.InitScriptHandler$1.run(InitScriptHandler.java:55)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.initialization.InitScriptHandler.executeScripts(InitScriptHandler.java:49)
        at org.gradle.initialization.DefaultGradleLauncher$LoadBuild.run(DefaultGradleLauncher.java:232)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.initialization.DefaultGradleLauncher.loadSettings(DefaultGradleLauncher.java:159)
        at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:122)
        at org.gradle.initialization.DefaultGradleLauncher.executeTasks(DefaultGradleLauncher.java:109)
        at org.gradle.internal.invocation.GradleBuildController$1.call(GradleBuildController.java:78)
        at org.gradle.internal.invocation.GradleBuildController$1.call(GradleBuildController.java:75)
        at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:152)
        at org.gradle.internal.invocation.GradleBuildController.doBuild(GradleBuildController.java:100)
        at org.gradle.internal.invocation.GradleBuildController.run(GradleBuildController.java:75)
        at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
        at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
        at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$1.run(RunAsBuildOperationBuildActionRunner.java:43)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:40)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionRunner.run(SubscribableBuildActionRunner.java:51)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:47)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:39)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:25)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:80)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:53)
        at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:57)
        at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:32)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:36)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:25)
        at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:43)
        at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:29)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:64)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:29)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:59)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:44)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:45)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:30)
        at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:67)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
        at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
        at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
        at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
        at org.gradle.util.Swapper.swap(Swapper.java:38)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
        at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
        at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:62)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
        at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:82)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
        at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
        at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:295)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: org.gradle.api.resources.MissingResourceException: Could not read 'http://git/dezide/gradle-shared/raw/master/init.d/include-shared-scripts.gradle' as it does
 not exist.
        at org.gradle.internal.resource.ResourceExceptions.getMissing(ResourceExceptions.java:52)
        at org.gradle.internal.resource.transfer.DefaultUriTextResourceLoader.loadUri(DefaultUriTextResourceLoader.java:45)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(DefaultObjectConfigurationAction.java:103)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(DefaultObjectConfigurationAction.java:38)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$1.run(DefaultObjectConfigurationAction.java:68)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:143)
        at org.gradle.groovy.scripts.DefaultScript.apply(DefaultScript.java:126)
        at org.gradle.api.Script$apply.callCurrent(Unknown Source)
        at include_shared_2agusdf7ed5n9hap7yxhhixx9.run(C:\Users\chris\.gradle\init.d\include-shared.gradle:2)
        at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:90)
        ... 84 more

* Get more help at https://help.gradle.org

BUILD FAILED in 1s

I've tried to reproduce this by referencing a script on github from an init script. That works on my machine.
Can you reproduce this with a project that you can share? If not, do the --info or --debug logs provide more information about the "missing" resource?

I tried deleting the file as suggested earlier, that makes the build run once:
λ rm %USERPROFILE%\.gradle\caches\modules-2\metadata-2.24\artifact-at-url.bin

C:\code\java\web-author (master)
λ gradlew clean
Download http://git/dezide/gradle-shared/raw/master/init.d/include-shared-scripts.gradle
Download http://git/dezide/gradle-shared/raw/master/init.d/repository-setup.gradle

BUILD SUCCESSFUL in 1s
23 actionable tasks: 23 up-to-date
C:\code\java\web-author (master)
λ gradlew clean

FAILURE: Build failed with an exception.

* Where:
Initialization script 'C:\Users\chris\.gradle\init.d\include-shared.gradle' line: 2

* What went wrong:
A problem occurred evaluating initialization script.
> Could not read 'http://git/dezide/gradle-shared/raw/master/init.d/include-shared-scripts.gradle' as it does not exist.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 0s

A log from running gradlew clean --debug > debug-log.txt: debug-log.txt

For completeness can you also include the log of the first, successful build?

Can you try sending a HEAD request to http://git/dezide/gradle-shared/raw/master/init.d/include-shared-scripts.gradle ? Gradle's new URL caching (since 4.2) requires HEAD requests to work. Let's rule out a misconfigured server as a cause.

It seems that the HEAD command is not working:
λ curl -I http://git/dezide/gradle-shared/raw/master/init.d/include-shared-scripts.gradle
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8
Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
Set-Cookie: i_like_gogits=cba87b756e2263a2; Path=/; HttpOnly
Set-Cookie: _csrf=c8P4KnaZMUN1W8sfqpCSWKVWFko6MTUwNjA3NzU0NjI5MjIwMDQxMA%3D%3D; Path=/; Expires=Sat, 23 Sep 2017 10:52:26 GMT; HttpOnly
Date: Fri, 22 Sep 2017 10:52:26 GMT

I'm on my way out of the door right now, but I'll try to get our git server to behave on Monday.
It seems like the issue is related to the use of HEAD. Did this behavior change since 4.1?

Yes, we use HEAD requests now to determine if a resource is still up-to-date. That's not fully compatible with what we did before (doing a GET on every build, which was expensive). We'll discuss internally if there is a way to make it efficient and backwards compatible. We'll keep you updated.

We discussed this and think that the git server is misconfigured. It answers 200 on a GET request, but 404 on a HEAD request, which is inconsistent.
So far we assume that this is an uncommon scenario. If other users encounter this as well, we might insert some additional fallback behavior.

We face the same issue at our site, when we attempt to apply a plugin from the HTTPs side of our Git repository.
After digging some further inside our tooling, I discovered that the Git software use (i.e. Gogs) does not support a HEAD HTTP request, this also part of their issue tracker: https://github.com/gogits/gogs/issues/2857
Sadly though, we are now quite stuck. Gogs does not support the HEAD request, and Gradle requires it now.

I agree with the gradle folks on this one; This is not a gradle issue, it is reasonable to expect that HEAD requests work on the remote server.
We happen to are also use gogs and we are simply staying on a lower gradle version until I find the time to migrate to another git server implementation, as I have little faith in the gogs guy fixing this within a reasonable time frame.

As a workaround, you could try adding a query string to your URL, which forces Gradle to fallback to its old behavior (no caching, so no HEAD requests).


h5lock is private

Like we discussed, I wrote my own attribute reader because it's still not supported. Everything went OK, until I tried to use h5lock to make my low-level calls sync with the library. That didn't work from the outside, and I got the error:
error[E0603]: module `sync` is private
 --> <::hdf5::macros::h5lock macros>:5:53
  |
5 | ] # [ allow ( unused_unsafe ) ] unsafe { $ crate :: sync :: sync ( || $ expr )
  |                                                     ^^^^

Can you please make sync it public?

It's already done in my WIP summer branch :) (which is nearing completion, I'll push it in the current state tomorrow, but it will require a bit more work to finish).
commit 4cca17188c3707f76f4eef48e1a541c0c8e3c705
Author: Ivan Smirnov<EMAIL_ADDRESS>Date:   Sun Jul 21 15:15:43 2019 +0100

    Allow using h5{check,lock!,try!,call!} externally

... and, as a matter of fact, in the next version after that I'm planning to get rid of all the macros h5try! etc, and instead using functions and sync::sync directly everywhere and make it all completely public (partially due to completions and code analysis not working in IDEs, but it'd be nice to get macro-free).

Great! Thanks! Hopefully there won't be any other conflicts with the code I used from you so far.
I'm sorry, I don't understand.  That's the only macro I'm using for synchronization.
Btw, a macro has the benefit that it makes the code much shorter. For example, using a macro can also including unsafe blocks, which are used everywhere in HDF5 interfacing.

I'm sorry, I don't understand.  That's the only macro I'm using for synchronization.

So the current
pub fn selection_size(&self) -> usize {
    h5call!(H5Sget_select_npoints(self.id())).ok().map_or(0, |x| x as _)
}

will probably look like this (maybe we can add versions that take unsafe closures, so that unsafe can be omitted though, since it's going to be all over the place...):
use hdf5::{sync, h5, h5s};
// sync() = just sync whatever you want, declare unsafe yourself
// h5() = the current "h5check()", converts HDF5 results into hdf5::Result<...>
// h5s() = same as h5(), but synchronized

pub fn selection_size(&self) -> usize {
    sync(|| unsafe { h5(H5Sget_select_npoints(id)) }).ok().map_or(0, |x| x as _)
}

// or

h5s(|| unsafe { H5Sget_select_npoints(id) })

Another option is to make sync() and h5s() take unsafe closures, but then I think they need to be unsafe themselves (so you'll end up writing unsafe somewhere, I think). It's more verbose but not that bad. Still need to think a bit about it.

Btw, a macro has the benefit that it makes the code much shorter. For example, using a macro can also including unsafe blocks, which are used everywhere in HDF5 interfacing.

True.

I see. Actually I prefer the macros as they are now. I believe IDEs will have better support for all this in the future, and with macros it's already super-clean.
Even in C++, where I wrote this abstraction layer myself from scratch, I used a macro for the lock_guard. It's probably the natural way of doing things ;-)

Yea - we can probably leave those macros as is, but I still was looking forward to make the core codebase mainly macros-less, when you have 10K+ lines of code, without proper IDE support things get pretty painful :/
Anyways, this will be up for discussion a bit later.
Just occured to me... there's actually yet another option - allowing #[h5lock] attribute on functions, making it unsafe and sync, so the above could hypothetically be
#[h5lock]
pub fn selection_size(&self) -> usize {
    h5(H5Sget_select_npoints(self.id())).ok().map_or(0, |x| x as _)
}

// or even...

#[h5lock]
pub fn selection_size(&self) -> usize {
    H5Sget_select_npoints(self.id()).h5().ok().map_or(0, |x| x as _)
}

That's ^ actually the way it's done in h5py.
Man, I love bikeshedding :D

This looks very cool. However, consider that some people may not want to write another abstraction layer for every HDF5 C function, because such an attribute will exercise a full lock over the whole function. But for those with a huge code base, this can be very useful ;-)

Hey, man. Is this ready to be merged to master?


Fix WebGL renderer

The WebGL renderer renders things a bit skewed, or at least just scaled up from the reference canvas renderer. It's unknown what causes this.

Fixed by 042474a


Warnings/error break build for gcc 7

[x ] Programmer/board type: Stlink/v2, Stlink/v2-onboard, Stlink/V2-1 onboard
[X ] Operating system: Linux Fedora 26+
[X ] Stlink tools version v1.3.1/git-cc3a5705099019e01dc59f7907d0c5b1b85878d8

During compilation with gcc 7.0.1, some warnings about fall through (missing break)
is reported. This warnings is treated as errors, so make fails to build.
Output:
stlink-20170507/src/gdbserver/gdb-server.c:1626:31: error: this statement may fall through [-Werror=implicit-fallthrough=]
                     case '4': { // insert access watchpoint

stlink-20170507/src/gdbserver/gdb-server.c:1663:27: error: this statement may fall through [-Werror=implicit-fallthrough=]
                         if(delete_data_watchpoint(sl, addr) < 0) {

A patch is ready. Will try to submit it.

stlink-addbreak.patch.txt
Sorry for '.txt' suffix, github do not support '.patch' files from here.

Please submit a git pull request, we don't accept verbatim patches.


Knife: fix knife list_commands()

this was not supposed to be private
Fixes this:
/Users/lamont/.rvm/gems/ruby-2.3.1/gems/chef-12.14.77/lib/chef/application/knife.rb:212:in `print_help_and_exit': private method `list_commands' called for Chef::Knife:Class (NoMethodError)
Did you mean?  subcommands
	from /Users/lamont/.rvm/gems/ruby-2.3.1/gems/chef-12.14.77/lib/chef/application/knife.rb:176:in `validate_and_parse_options'
	from /Users/lamont/.rvm/gems/ruby-2.3.1/gems/chef-12.14.77/lib/chef/application/knife.rb:154:in `run'
	from /Users/lamont/.rvm/gems/ruby-2.3.1/gems/chef-12.14.77/bin/knife:25:in `<top (required)>'
	from /Users/lamont/.rvm/gems/ruby-2.3.1/bin/knife:23:in `load'
	from /Users/lamont/.rvm/gems/ruby-2.3.1/bin/knife:23:in `<main>'
	from /Users/lamont/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `eval'
	from /Users/lamont/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `<main>'

Signed-off-by: Lamont Granquist<EMAIL_ADDRESS>

added the error for SEO

Hi, can you give any indication when this fix will be available in an updated chefdk?

@JamesDawson should ship this week if we stay on schedule.

Great - many thanks for the quick reply.