profile
viewpoint

hacst/HTML5HASH 16

Local file hashing with CRC32, MD5 and SHA1 in a browser using modern HTML5 features

hacst/hfy2epub 5

A tool to turn post series from r/HFY to EPUB files in your browser

arrai/mumble-record 4

A temporary branch to implement recording in mumble

hacst/chess 2

Chess game with OpenGL GUI and AI

hacst/montecarlopi 2

Visualization of Pi calculation with the Monte Carlo method using Canvas and JavaScript

hacst/mumble 2

Mumble VoIP Client/Server

hacst/mumble_link 1

Python module for exercising Mumble's link postional audio plugin interface

hacst/rotcbot 1

A jabber bot that scans the TGE master server and announces new games of a specific type.

hacst/android-keyboard-gadget 0

Convert your Android device into USB keyboard/mouse, control your PC from your Android device remotely, including BIOS/bootloader.

issue commentquarkusio/quarkus

quarkus-universe-bom too large for Azure Artifacts in 1.6.0.Final

@aloubyansky Interesting. It will cause some confusion to switch this to something not in the docs but it is a much saner workaround than me messing with a released pom. If we encounter specific stuff missing we should still be able to "vendor" that part somehow (should hopefully be rare). Thanks a lot for making me aware of this.

@maxandersen The limit is per pom file. We have tons of other dependencies being pulled through the feed so if we hit some pom count limit it wouldn't be due to such a workaround ;)

hacst

comment created time in 2 days

issue commentquarkusio/quarkus

quarkus-universe-bom too large for Azure Artifacts in 1.6.0.Final

@aloubyansky I haven't. It is only 200k so would work. What is the difference to the universe bom? I only ever saw universe mentioned in documentation.

hacst

comment created time in 2 days

issue commentquarkusio/quarkus

quarkus-universe-bom too large for Azure Artifacts in 1.6.0.Final

@aloubyansky Thanks for your effort. @maxandersen Correct. We try to follow best practice described by MS for a cooperate setup which is to use a proxy repository for maven access through an artifact feed and prevent any direct access to upstreams (maven central). Besides the speedup you mentioned this keeps builds working if the upstream has issues, if packages are removed or if there are general connectivity issues.

Microsoft would definitely be the only party able to really fix this issue. Everyone else can only work around. Unfortunately even if they fix it tomorrow it would likely take a at least half a year to reach their on-premise product we are using (better then never ofc.). I'll probably have to start stripping out parts of the pom we don't use right now to kick the can down the road (which is just aweful).

hacst

comment created time in 2 days

issue commentquarkusio/quarkus

quarkus-universe-bom too large for Azure Artifacts in 1.6.0.Final

@aloubyansky As feared with Quarkus 1.8.1.Final my workaround is no longer possible. The "minified" pom.xml is now 389578 exceeding the limit of 384000. Do you have any other suggestions for a viable workaround?

hacst

comment created time in 2 days

startedmicrosoft/STL

started time in 3 days

startedrmh78/quarkus-performance

started time in 8 days

startedquarkusio/quarkus

started time in 8 days

issue commentmicrosoft/azure-pipelines-tasks

Interest in "Kubernetes Proxy" functionality?

@luzlozanothermo I did not publish it as there seemed to be no interest. If this is task would be useful to you I can check whether I can do so. The implementation itself is quite straight-forward.

As mentioned the idea is to spawn kubectl with port-forward and keep it running in the background for future steps in the build. For this we added

    // Spawns kubectl using child_process and forwards the arguments
    public spawnKubectl(args?: string[], options?: child_process.SpawnOptions) : child_process.ChildProcess {
        return child_process.spawn(this.kubectlPath, args, options);
    }

to the ClusterConnection as it knows the kubectl path. That can then be used to start kubectl port-forward in detached mode:

clusterConnection.spawnKubectl(['port-forward', "-n", namespace, target, localPort + ":" + targetPort], {
            detached: true,
            stdio: ['ignore', log, log]
      }
);

Everything around that is just the boilerplate to take in configuration options, figure out which port we actually launched on by tailing the log and so on. As soon as the port is know plugin execution ends and the proxy keeps running.

So basically a fancy kubectl port-forward ... & that can make use of the built-in authentication of the service connections.

The detached process is automatically killed at the end of the build by azure devops. No work needed in the plugin for that.

hacst

comment created time in 15 days

issue commentrest-assured/rest-assured

Don't append Accept-header if removed by a Filter.

Still an issue. From what I can tell there's still no obvious way to create a request without accept headers. Currently trying to fix a testcase that was intended to test things work without accept header. As it was still sent that tests didn't catch this actually being broken in the service. Very annoying.

thomlar

comment created time in 2 months

issue openedebullient/quarkus-micrometer-extension

Support micrometer annotations

micrometer-core contains @Timed and @Counted annotations in io.micrometer.core.annotation that can be used by frameworks to implement UX similar to what the equivalent MP Metrics provides in quarkus-smallrye-metrics.

It would be great if quarkus-micrometer-extension could also support these.

Imho having these annotations will make it easier for MP Metrics users to switch and will generally reduce the boilerplate for basic cases. E.g.

@Timed(histogram=true, description="Cool metric")
public String checkIfPrime(long number) {
  ...
}

vs

private Timer checkIfPrimeTimer = Timer.builder("checkIfPrime")
  .publishPercentileHistogram()
  .description("Cool metric")
  .register(Metrics.globalRegistry);

public String checkIfPrime(long number) {
  checkIfPrimeTimer.record(() -> {
     ...
   });
}

created time in 2 months

startedebullient/quarkus-micrometer-extension

started time in 2 months

issue commentopen-telemetry/opentelemetry-python

Enabling shared state across processes

@toumorokoshi Isn't the use-case is pretty much all of the standard production python web-service deployments (e.g. #365)? They mostly use processes (through gunicorn, uwsgi, ...) unless specifically designed around async. And even those tend to additionally use processes in production as far as I have seen (e.g. https://www.uvicorn.org/#running-with-gunicorn). The GIL makes it extremely hard to scale reliably using threads like you would in other languages.

W.r.t. opentelemetry-collector: Is it actually able to perform this task (and for all metric types/aggregations)? I'm a bit unclear how this would be configured (e.g. to get a histogram). Would this require something like https://github.com/open-telemetry/opentelemetry-collector/issues/1422 ?

toumorokoshi

comment created time in 2 months

issue openedquarkusio/quarkus

quarkus-universe-bom too large for Azure Artifacts in 1.6.0.Final

Describe the bug This isn't an actual Quarkus bug but @aloubyansky recommended to open one anyways.

With 1.6.0.Final quarkus-universe-bom is now 402KB. This exceeds the maximum pom.xml size limit of Azure Artifacts Feeds which is 384KB. This means trying to download Quarkus through such a feeds (same use-case as a nexus proxy upstream) will fail. I do realize that this is on Azure Artifacts. Unfortunately it doesn't look like they will fix this anytime soon (https://developercommunity.visualstudio.com/idea/809379/remove-or-increase-the-hard-limit-of-384000-bytes.html).

I do not really expect Quarkus to work around this - though Azure Artifact users would definitely be thankful - but I thought I still should raise the issue somewhere in case others hit it.

The current workaround I'm thinking of implementing is to remove the unneeded whitespace from the pom. That leaves it 305KB which I should then be able to publish to the feed directly. Not a great solution and if I mess it up the version is burned. Also has to be re-done for every new version and might ultimately fail if the "minified" pom becomes too large. If the project wants to work around this I think one potential way would be to split the pom by (ab)using parent poms.

Expected behavior Can use new Quarkus through an Azure Artifacts feed.

Actual behavior Maven fails down download dependencies with:

Could not transfer artifact io.quarkus:quarkus-universe-bom:pom:1.6.0.Final from/to *** (***/maven/v1): Transfer failed for ***/maven/v1/io/quarkus/quarkus-universe-bom/1.6.0.Final/quarkus-universe-bom-1.6.0.Final.pom 400 Bad Request - pom.xml file is too large; the limit is 384000 bytes (DevOps Activity ID: 08718F7F-368C-4378-BE8B-2829908129D1)

To Reproduce Steps to reproduce the behavior:

  1. Setup an azure artifact feed with upstream enabled
  2. Try to download the quarkus-universe-bom 1.6.0.Final from it

The feed I encountered this on was on an on-premise Azure DevOps Server 2019 though the issue should be the same for the cloud based Feeds.

created time in 3 months

issue commentquarkusio/quarkus

SmallRyeMetricsProcessor Unsupported api 524288

I see the same discrepancy when using maven. I don't think it's related to metrics (not using them). It also seems to be present in 1.6.0.Final:

...
[INFO] +- io.quarkus:quarkus-junit5:jar:1.6.0.Final:test
[INFO] |  +- io.quarkus:quarkus-bootstrap-core:jar:1.6.0.Final:test
[INFO] |  |  +- io.quarkus:quarkus-bootstrap-app-model:jar:1.6.0.Final:test
[INFO] |  |  \- io.quarkus:quarkus-bootstrap-maven-resolver:jar:1.6.0.Final:test
[INFO] |  |     +- org.ow2.asm:asm:jar:7.3.1:test
...
[INFO] |  +- io.quarkus:quarkus-test-common:jar:1.6.0.Final:test
[INFO] |  |  +- io.quarkus:quarkus-core-deployment:jar:1.6.0.Final:test
[INFO] |  |  |  +- io.quarkus.gizmo:gizmo:jar:1.0.3.Final:test
[INFO] |  |  |  |  \- org.ow2.asm:asm-util:jar:8.0.1:test
[INFO] |  |  |  |     +- org.ow2.asm:asm-tree:jar:8.0.1:test
[INFO] |  |  |  |     \- org.ow2.asm:asm-analysis:jar:8.0.1:test

For me:

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.ow2.asm</groupId>
                <artifactId>asm</artifactId>
                <version>8.0.1</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

Works around the issue for me.

The versions cannot be the whole story though as this workaround is not needed in 1.5.0.Final even though it shows the same version mismatches.

xmlking

comment created time in 3 months

more